12.2. Quay Operator 업그레이드
OpenShift에서 설치된 Operator를 업그레이드하는 표준 방법은 설치된 Operator 업그레이드에 설명되어 있습니다.
일반적으로 Red Hat Quay는 이전 (N-1) 마이너 버전의 업그레이드만 지원합니다. 예를 들어 Red Hat Quay 3.0.5에서 최신 3.5 버전으로 직접 업그레이드할 수 없습니다. 대신 사용자는 다음과 같이 업그레이드해야 합니다.
-
3.0.5
3.1.3 -
3.1.3
3.2.2 -
3.2.2
3.3.4 -
3.3.4
3.4.z -
3.4.z
3.5.z
이는 업그레이드 중에 필요한 모든 데이터베이스 마이그레이션을 올바르게 수행하고 올바른 순서로 수행해야 합니다.
경우에 따라 Red Hat Quay는 이전 (N-2, N-3) 마이너 버전에서 직접 단일 단계 업그레이드를 지원합니다. 이 예외는 이전 마이너 버전 전용의 일반 버전만 제외하고 업그레이드하면 이전 릴리스 고객의 업그레이드 절차를 단순화합니다. 다음과 같은 업그레이드 경로가 지원됩니다.
-
3.3.z
3.6.z -
3.4.z
3.6.z -
3.4.z
3.7.z -
3.5.z
3.7.z
3.7로 업그레이드하려는 Quay의 독립 실행형 배포에 있는 사용자는 독립 실행형 업그레이드 가이드를 참조하십시오.
12.2.1. Quay 업그레이드 링크 복사링크가 클립보드에 복사되었습니다!
Quay를 하나의 마이너 버전에서 다음 버전으로 업데이트하려면 (예: 3.4
z 스트림 업그레이드(예: 3.4.2 z 스트림 업그레이드를 수행하는 절차는 위에 설명된 approvalStrategy 에 따라 다릅니다. 승인 전략이 자동으로 설정된 경우 Quay Operator는 최신 z 스트림으로 자동 업그레이드됩니다. 이로 인해 Quay가 다운타임 없이 최신 z 스트림으로 자동으로 업데이트됩니다. 그렇지 않으면 설치를 시작하기 전에 업데이트를 수동으로 승인해야 합니다.
12.2.2. 3.3.z 또는 3.4.z에서 3.6으로 직접 업그레이드하는 방법에 대한 참고 사항 링크 복사링크가 클립보드에 복사되었습니다!
12.2.2.1. 엣지 라우팅 활성화로 업그레이드 링크 복사링크가 클립보드에 복사되었습니다!
- 이전에는 엣지 라우팅이 활성화된 Red Hat Quay의 3.3.z 버전을 실행할 때 사용자는 Red Hat Quay의 3.4.z 버전으로 업그레이드할 수 없었습니다. 이 문제는 Red Hat Quay 3.6 릴리스와 함께 해결되었습니다.
3.3.z에서 3.6으로 업그레이드할 때 Red Hat Quay 3.3.z 배포에서
tls.termination이none으로 설정되어 TLS 엣지 종료를 통해 HTTPS로 변경되고 기본 클러스터 와일드카드 인증서를 사용합니다. 예를 들면 다음과 같습니다.apiVersion: redhatcop.redhat.io/v1alpha1 kind: QuayEcosystem metadata: name: quay33 spec: quay: imagePullSecretName: redhat-pull-secret enableRepoMirroring: true image: quay.io/quay/quay:v3.3.4-2 ... externalAccess: hostname: quayv33.apps.devcluster.openshift.com tls: termination: none database: ...
12.2.2.2. 주체 대체 이름 없이 사용자 정의 TLS 인증서/키 쌍으로 업그레이드 링크 복사링크가 클립보드에 복사되었습니다!
Red Hat Quay 3.3.4에서 Red Hat Quay 3.6으로 직접 업그레이드할 때 SAN(Subject Alternative Names) 없이 자체 TLS 인증서/키 쌍을 사용하는 고객은 문제가 있습니다. Red Hat Quay 3.6으로 업그레이드하는 동안 배포가 차단되며 Quay TLS 인증서에 SAN이 있어야 함을 나타내는 Quay Operator pod 로그의 오류 메시지가 표시됩니다.
가능하면 SAN에서 올바른 호스트 이름을 사용하여 TLS 인증서를 다시 생성해야 합니다. 가능한 해결 방법은 CommonName 일치를 사용하도록 업그레이드한 후 quay-app,quay-upgrade 및 quay-config-editor Pod에서 환경 변수를 정의하는 것입니다.
GODEBUG=x509ignoreCN=0
GODEBUG=x509ignoreCN=0 플래그를 사용하면 SAN이 없을 때 X.509 인증서의 CommonName 필드를 호스트 이름으로 처리하는 기존 동작을 활성화합니다. 그러나 재배포 시 유지되지 않으므로 이 해결방법은 권장되지 않습니다.
12.2.2.3. Quay Operator를 사용하여 3.3.z 또는 3.4.z에서 3.6으로 업그레이드할 때 Clair v4 구성 링크 복사링크가 클립보드에 복사되었습니다!
OpenShift에 새로운 Red Hat Quay 배포에 Clair v4를 설정하려면 Quay Operator를 사용하는 것이 좋습니다. 기본적으로 Quay Operator는 Red Hat Quay 배포와 함께 Clair 배포를 설치 또는 업그레이드하고 Clair 보안 검사를 자동으로 구성합니다.
OpenShift에서 Clair v4를 설정하는 방법에 대한 자세한 내용은 Red Hat Quay OpenShift 배포에서 Clair 설정을 참조하십시오.
12.2.3. 3.3.z에서 3.6으로 업그레이드할 때 Swift 구성 링크 복사링크가 클립보드에 복사되었습니다!
Red Hat Quay 3.3.z에서 3.6.z로 업그레이드하는 경우 일부 사용자에게 다음 오류가 발생할 수 있습니다. Switch auth v3 requires tenant_id (string) in os_options. 이 문제를 해결하려면 DISTRIBUTED_STORAGE_CONFIG 를 수동으로 업데이트하여 os_options 및 tenant_id 매개변수를 추가할 수 있습니다.
DISTRIBUTED_STORAGE_CONFIG:
brscale:
- SwiftStorage
- auth_url: http://****/v3
auth_version: "3"
os_options:
tenant_id: ****
project_name: ocp-base
user_domain_name: Default
storage_path: /datastorage/registry
swift_container: ocp-svc-quay-ha
swift_password: *****
swift_user: *****
12.2.4. Operator의 업데이트 채널 변경 링크 복사링크가 클립보드에 복사되었습니다!
설치된 Operator의 서브스크립션은 Operator의 업데이트를 추적하고 수신하는 데 사용되는 업데이트 채널을 지정합니다. Quay Operator를 업그레이드하여 최신 채널에서 업데이트를 추적하고 받으려면 설치된 Quay Operator의 서브스크립션 탭에서 업데이트 채널을 변경합니다. 자동 승인 전략이 있는 서브스크립션의 경우 업그레이드가 자동으로 시작되고 설치된 Operator가 나열된 페이지에서 모니터링할 수 있습니다.
12.2.5. 보류 중인 Operator 업그레이드 수동 승인 링크 복사링크가 클립보드에 복사되었습니다!
설치된 Operator의 서브스크립션에 있는 승인 전략이 Manual 로 설정된 경우 새 업데이트가 현재 업데이트 채널에 릴리스되면 업데이트를 수동으로 승인해야 설치가 시작됩니다. Quay Operator에 업그레이드가 보류 중인 경우 이 상태가 Installed Operator 목록에 표시됩니다. Quay Operator의 서브스크립션 탭에서 설치 계획을 미리 보고 업그레이드할 수 있는 것으로 나열된 리소스를 검토할 수 있습니다. 문제가 발생할 경우 승인을 클릭하고 Installed Operators를 나열하는 페이지로 돌아가 업그레이드 진행 상황을 모니터링합니다.
다음 이미지는 업데이트 채널, 승인 전략, 업그레이드 상태 및 InstallPlan 을 포함하여 UI의 Subscription 탭을 보여줍니다.
설치된 Operator 목록은 현재 Quay 설치에 대한 상위 수준 요약을 제공합니다.