업그레이드

Red Hat OpenShift Service on AWS 4

AWS에서 Red Hat OpenShift Service의 업그레이드 옵션 이해

Red Hat OpenShift Documentation Team

초록

이 문서에서는 ROSA(Red Hat OpenShift Service on AWS) 클러스터 업그레이드에 대한 정보를 제공합니다.

1장. ROSA를 4.9로 업그레이드 준비

AWS 클러스터에서 OpenShift 4.9로 Red Hat OpenShift Service를 업그레이드하려면 최신 Kubernetes 버전에서 상당한 수의 API를 제거했기 때문에 API를 평가하고 마이그레이션해야 합니다.

AWS 클러스터에서 Red Hat OpenShift Service를 업그레이드하기 전에 필요한 툴을 적절한 버전으로 업데이트해야 합니다.

1.1. OpenShift 4.9로 업그레이드 요구사항

AWS STS(Security Token Service)를 버전 4.8에서 4.9로 사용하는 ROSA(Red Hat OpenShift Service on AWS) 클러스터를 업그레이드하기 전에 다음 요구 사항을 충족해야 합니다.

사전 요구 사항

  • 최신 AWS CLI를 설치 호스트에 설치했습니다.
  • 설치 호스트에 1.1.10 이상 ROSA CLI(rosa)를 설치했습니다.
  • 필요에 따라 워크스테이션에 버전 4.9 이상 (oc)을 설치했습니다.
  • AWS 계정 전체 역할 및 정책을 업데이트하는 데 필요한 권한이 있습니다.
  • cluster-admin 역할의 사용자로 클러스터에 액세스할 수 있어야 합니다.
  • Operator 정책을 버전 4.9로 포함하여 AWS IAM(Identity and Access Management) 계정 전체 역할 및 정책을 업데이트했습니다.

1.1.1. OpenShift 4.9로 업그레이드할 때 관리자 승인

AWS 4.9의 Red Hat OpenShift Service에서는 Kubernetes 1.22를 사용하며, 이 Kubernetes 1.22에서는 더 이상 사용되지 않는 v1beta1 API가 많이 제거되었습니다.

AWS 4.8.14의 Red Hat OpenShift Service에는 클러스터를 AWS 4.8에서 4.9로 업그레이드하기 전에 관리자가 수동으로 승인을 제공해야 한다는 요구 사항이 도입되었습니다. 이는 AWS 4.9의 Red Hat OpenShift Service로 업그레이드한 후에도 문제를 방지하기 위한 것입니다. 여기서 제거된 API는 클러스터에서 실행 중이거나 클러스터와 상호 작용하는 기타 구성 요소에서 여전히 사용 중입니다. 관리자는 제거될 모든 API에 대해 클러스터를 평가하고 영향을 받는 구성 요소를 마이그레이션하여 적절한 새 API 버전을 사용해야 합니다. 이 작업이 완료되면 관리자는 관리자 승인을 제공할 수 있습니다.

AWS 4.8 클러스터의 모든 Red Hat OpenShift Service에는 AWS 4.9에서 Red Hat OpenShift Service로 업그레이드하기 전에 이 관리자가 승인해야 합니다.

1.1.2. 제거된 Kubernetes API

AWS 4.9의 Red Hat OpenShift Service는 더 이상 사용되지 않는 v1beta1 API를 제거한 Kubernetes 1.22를 사용합니다. v1 API 버전을 사용하려면 매니페스트 및 API 클라이언트를 마이그레이션해야 합니다. 제거된 API 마이그레이션에 대한 자세한 내용은 Kubernetes 설명서를 참조하십시오.

표 1.1. Kubernetes 1.22에서 v1beta1 API 제거

리소스API주요 변경 사항

APIService

apiregistration.k8s.io/v1beta1

없음

CertificateSigningRequest

certificates.k8s.io/v1beta1

제공됨

ClusterRole

rbac.authorization.k8s.io/v1beta1

없음

ClusterRoleBinding

rbac.authorization.k8s.io/v1beta1

없음

CSIDriver

storage.k8s.io/v1beta1

없음

CSINode

storage.k8s.io/v1beta1

없음

CustomResourceDefinition

apiextensions.k8s.io/v1beta1

제공됨

Ingress

extensions/v1beta1

제공됨

Ingress

networking.k8s.io/v1beta1

제공됨

IngressClass

networking.k8s.io/v1beta1

없음

Lease

coordination.k8s.io/v1beta1

없음

LocalSubjectAccessReview

authorization.k8s.io/v1beta1

제공됨

MutatingWebhookConfiguration

admissionregistration.k8s.io/v1beta1

제공됨

PriorityClass

scheduling.k8s.io/v1beta1

없음

Role

rbac.authorization.k8s.io/v1beta1

없음

RoleBinding

rbac.authorization.k8s.io/v1beta1

없음

SelfSubjectAccessReview

authorization.k8s.io/v1beta1

제공됨

StorageClass

storage.k8s.io/v1beta1

없음

SubjectAccessReview

authorization.k8s.io/v1beta1

제공됨

TokenReview

authentication.k8s.io/v1beta1

없음

ValidatingWebhookConfiguration

admissionregistration.k8s.io/v1beta1

제공됨

VolumeAttachment

storage.k8s.io/v1beta1

없음

1.2. 제거된 API에 대한 클러스터 평가

관리자가 제거할 API 위치를 식별하는 데 도움이 되는 여러 가지 방법이 있습니다. 그러나 AWS의 Red Hat OpenShift Service는 모든 인스턴스, 특히 유휴 상태인 워크로드 또는 사용되는 외부 툴을 식별할 수 없습니다. 관리자가 제거된 API 인스턴스에 대한 모든 워크로드 및 기타 통합을 적절하게 평가해야 합니다.

1.2.1. 제거된 API의 사용 식별을 위한 경고 검토

APIRemovedInNextReleaseInUse 경고는 클러스터에서 사용 중인 제거된 API가 있음을 나타냅니다. 클러스터에서 이 경고가 실행되는 경우 경고를 검토합니다. 새 API 버전을 사용하도록 매니페스트 및 API 클라이언트를 마이그레이션하여 경고를 지우십시오. APIRequestCount API를 사용하여 사용 중인 API와 제거된 API를 사용하는 워크로드에 대한 자세한 정보를 얻을 수 있습니다.

1.2.2. APIRequestCount를 사용하여 제거된 API 사용 확인

APIRequestCount API를 사용하여 API 요청을 추적하고 제거된 API 중 하나를 사용하고 있는지 검토할 수 있습니다.

사전 요구 사항

  • cluster-admin 역할의 사용자로 클러스터에 액세스할 수 있어야 합니다.

프로세스

  • 다음 명령을 실행하고 출력의 REMOVEDINRELEASE 열을 검사하여 현재 사용 중인 제거된 API를 확인합니다. 

    $ oc get apirequestcounts

    출력 예

    NAME                                        REMOVEDINRELEASE   REQUESTSINCURRENTHOUR   REQUESTSINLAST24H
cloudcredentials.v1.operator.openshift.io                      32                      111
ingresses.v1.networking.k8s.io                                 28                      110
ingresses.v1beta1.extensions                1.22               16                      66
ingresses.v1beta1.networking.k8s.io         1.22               0                       1
installplans.v1alpha1.operators.coreos.com                     93                      167
...

    참고

    결과에 표시되는 다음 항목을 무시해도 됩니다.

    • system:serviceaccount:kube-system:generic-garbage-collector 는 제거할 리소스를 검색하는 모든 등록된 API를 통과하므로 결과에 나타납니다.
    • system:kube-controller-manager 는 할당량을 적용하는 동안 모든 리소스를 탐색하여 계산하기 때문에 결과에 나타납니다.

    -o jsonpath를 사용하여 결과를 필터링할 수도 있습니다. 

    $ oc get apirequestcounts -o jsonpath='{range .items[?(@.status.removedInRelease!="")]}{.status.removedInRelease}{"\t"}{.metadata.name}{"\n"}{end}'

    출력 예

    1.22    certificatesigningrequests.v1beta1.certificates.k8s.io
1.22    ingresses.v1beta1.extensions
1.22    ingresses.v1beta1.networking.k8s.io

1.2.3. APIRequestCount를 사용하여 제거된 API를 사용하는 워크로드 식별

지정된 API 버전에 대해 APIRequestCount 리소스를 검사하여 API를 사용하는 워크로드를 식별할 수 있습니다.

사전 요구 사항

  • cluster-admin 역할의 사용자로 클러스터에 액세스할 수 있어야 합니다.

프로세스

  • 다음 명령을 실행하고 username 및 userAgent 필드를 검사하여 API를 사용하는 워크로드를 식별할 수 있습니다. 

    $ oc get apirequestcounts <resource>.<version>.<group> -o yaml

    예를 들면 다음과 같습니다. 

    $ oc get apirequestcounts ingresses.v1beta1.networking.k8s.io -o yaml

    또한 -o jsonpath 를 사용하여 APIRequestCount 리소스에서 username 값을 추출할 수도 있습니다. 

    $ oc get apirequestcounts ingresses.v1beta1.networking.k8s.io -o jsonpath='{range ..username}{$}{"\n"}{end}' | sort | uniq

    출력 예

    user1
user2
app:serviceaccount:delta

1.3. 제거된 API의 인스턴스 마이그레이션

제거된 Kubernetes API 마이그레이션 방법에 대한 자세한 내용은 Kubernetes 문서의 더 이상 사용되지 않는 API 마이그레이션 가이드를 참조하십시오.

2장. STS를 사용하여 ROSA 클러스터 업그레이드

2.1. 라이프 사이클 정책 및 계획

업그레이드를 계획하려면 AWS의 Red Hat OpenShift Service on AWS 업데이트 라이프 사이클을 검토하십시오. 라이프 사이클 페이지에는 릴리스 정의, 지원 및 업그레이드 요구 사항, 설치 정책 정보 및 라이프 사이클 날짜가 포함됩니다.

업그레이드는 수동으로 시작되거나 자동으로 예약됩니다. Red Hat 사이트 안정성 엔지니어(SRE)는 업그레이드 진행 상황을 모니터링하고 발생한 문제를 해결합니다.

2.2. STS를 사용하는 ROSA 클러스터 업그레이드

AWS STS(보안 토큰 서비스)를 사용하는ROSA(Red Hat OpenShift Service on AWS) 클러스터에서 Red Hat OpenShift Service를 업그레이드하는 방법은 다음 두 가지가 있습니다.

  • ROSA CLI를 통한 개별 업그레이드 (rosa)
  • OpenShift Cluster Manager 콘솔을 통한 개별 업그레이드
참고

AWS STS(Security Token Service)를 사용하지 않는 ROSA 클러스터를 업그레이드하는 단계는 ROSA 클러스터 업그레이드를 참조하십시오.

2.2.1. ROSA CLI로 업그레이드

ROSA CLI(rosa)를 사용하여 AWS STS(보안 토큰 서비스)를 수동으로 사용하는 AWS(ROSA)에서 Red Hat OpenShift Service를 업그레이드할 수 있습니다.

이 방법은 최신 버전을 사용할 수 있는 경우 즉시 업그레이드를 위해 클러스터를 예약합니다.

사전 요구 사항

  • 설치 호스트에 최신 ROSA CLI를 설치하고 구성했습니다.
  • 클러스터를 4.7에서 4.8로 업그레이드하는 경우 AWS IAM(Identity and Access Management) 계정 전체 역할 및 정책을 버전 4.8로 업그레이드했습니다. CloudCredential 사용자 정의 리소스에서 cloudcredential.openshift.io/upgradeable-to 주석도 업데이트했습니다.

절차

  1. 현재 버전의 클러스터를 확인하려면 다음 명령을 입력합니다. 

    $ rosa describe cluster --cluster=<cluster_name|cluster_id> 1
    1
    & lt;cluster_name|cluster_id >를 클러스터 이름 또는 클러스터 ID로 바꿉니다.

  2. 업그레이드를 사용할 수 있는지 확인하려면 다음 명령을 입력합니다. 

    $ rosa list upgrade --cluster=<cluster_name|cluster_id>

    이 명령은 권장 버전을 포함하여 클러스터를 업그레이드할 수 있는 버전 목록을 반환합니다.

  3. 클러스터를 사용 가능한 최신 버전으로 업그레이드하려면 다음 명령을 입력합니다. 

    $ rosa upgrade cluster --cluster=<cluster_name|cluster_id>

    클러스터는 즉각적인 업그레이드를 위해 예약됩니다. 이 작업은 Pod 중단 예산과 같은 워크로드 구성에 따라 1시간 이상 걸릴 수 있습니다.

    업그레이드가 완료되면 이메일을 받습니다. ROSA CLI에서 rosa describe cluster 명령을 다시 실행하여 상태를 확인하거나 OpenShift Cluster Manager 콘솔에서 상태를 볼 수도 있습니다. :!sts:

문제 해결

2.2.2. OpenShift Cluster Manager 콘솔을 통해 개별 업그레이드 예약

OpenShift Cluster Manager 콘솔을 사용하여 AWS STS(Security Token Service)를 사용하는 AWS 클러스터에서 Red Hat OpenShift Service에 대한 업그레이드를 한 번 수동으로 예약할 수 있습니다.

사전 요구 사항

  • 클러스터를 4.7에서 4.8로 업그레이드하는 경우 AWS IAM(Identity and Access Management) 계정 전체 역할 및 정책을 버전 4.8로 업그레이드했습니다. CloudCredential 사용자 정의 리소스에서 cloudcredential.openshift.io/upgradeable-to 주석도 업데이트했습니다. 자세한 내용은 4.7에서 4.8로 업그레이드 준비를 참조하십시오.

절차

  1. OpenShift Cluster Manager Hybrid Cloud Console 에 로그인합니다.
  2. 업그레이드할 클러스터를 선택합니다.
  3. 설정 탭을 클릭합니다.
  4. 업데이트 전략 창에서 개별 업데이트를 선택합니다.
  5. 클러스터를 업그레이드할 버전을 선택합니다. 권장되는 클러스터 업그레이드가 UI에 표시됩니다.

  6. 승인이 필요한 업데이트 버전을 선택하는 경우 관리자의 승인을 요청한 후 승인을 클릭하고 계속.

    관리자 승인에 대한 자세한 내용은 OpenShift 4.9로 업그레이드할 때 관리자 승인을 참조하십시오.

  7. 노드 드레이닝 창에서 목록에서 유예 기간을 선택합니다. 유예 기간을 사용하면 Pod 제거를 강제 적용하기 전에 노드가 정상적으로 드레인될 수 있습니다. 기본값은 1시간 입니다.
  8. 업데이트 전략 창에서 저장 을 클릭하여 업데이트 전략을 적용합니다.

  9. Update status 창에서 사용 가능한 업데이트 정보를 검토하고 업데이트를 클릭합니다.

    참고

    Update 버튼은 업그레이드를 사용할 수 있는 경우에만 활성화됩니다.

  10. 버전 선택 대화 상자에서 대상 업그레이드 버전을 선택하고 다음을 클릭합니다.

  11. 스케줄 업데이트 대화 상자에서 클러스터 업그레이드를 예약합니다.

    • 한 시간 내에 업그레이드하려면 지금 업데이트를 선택하고 다음을 클릭합니다.
    • 나중에 업그레이드하려면 일정을 다른 시간을 선택하고 업그레이드 시간 및 날짜를 설정합니다. 다음을 클릭하여 확인 대화 상자로 이동합니다.

  12. 버전 및 일정 요약을 검토한 후 업데이트 확인 을 선택합니다.

    클러스터는 대상 버전으로 업그레이드되도록 예약됩니다. 이 작업은 선택한 업그레이드 일정 및 Pod 중단 예산과 같은 워크로드 구성에 따라 1시간 이상 걸릴 수 있습니다.

    상태가 Update status 창에 표시됩니다.

문제 해결

3장. ROSA 클러스터 업그레이드

3.1. 라이프 사이클 정책 및 계획

업그레이드를 계획하려면 AWS의 Red Hat OpenShift Service on AWS 업데이트 라이프 사이클을 검토하십시오. 라이프 사이클 페이지에는 릴리스 정의, 지원 및 업그레이드 요구 사항, 설치 정책 정보 및 라이프 사이클 날짜가 포함됩니다.

업그레이드는 수동으로 시작되거나 자동으로 예약됩니다. Red Hat 사이트 안정성 엔지니어(SRE)는 업그레이드 진행 상황을 모니터링하고 발생한 문제를 해결합니다.

3.2. ROSA 클러스터 업그레이드

Red Hat OpenShift Service on AWS(ROSA) 클러스터를 업그레이드하는 방법은 세 가지가 있습니다.

참고

AWS STS(Security Token Service)를 사용하는 ROSA 클러스터를 업그레이드하는 단계는 STS를 사용하여 ROSA 클러스터 업그레이드를 참조하십시오.

참고

예약된 업그레이드 정책에 따라 즉시 업그레이드하더라도 업그레이드 프로세스가 시작되기 전에 1시간 이상 지연될 수 있습니다. 또한 업그레이드 기간은 워크로드 구성에 따라 다를 수 있습니다.

3.2.1. ROSA CLI로 업그레이드

ROSA CLI(rosa)를 사용하여 AWS(ROSA)의 Red Hat OpenShift Service를 수동으로 업그레이드할 수 있습니다.

이 방법은 최신 버전을 사용할 수 있는 경우 즉시 업그레이드를 위해 클러스터를 예약합니다.

사전 요구 사항

  • 설치 호스트에 최신 ROSA CLI를 설치하고 구성했습니다.

절차

  1. 현재 버전의 클러스터를 확인하려면 다음 명령을 입력합니다. 

    $ rosa describe cluster --cluster=<cluster_name|cluster_id> 1
    1
    & lt;cluster_name|cluster_id >를 클러스터 이름 또는 클러스터 ID로 바꿉니다.

  2. 업그레이드를 사용할 수 있는지 확인하려면 다음 명령을 입력합니다. 

    $ rosa list upgrade --cluster=<cluster_name|cluster_id>

    이 명령은 권장 버전을 포함하여 클러스터를 업그레이드할 수 있는 버전 목록을 반환합니다.

  3. 클러스터를 사용 가능한 최신 버전으로 업그레이드하려면 다음 명령을 입력합니다. 

    $ rosa upgrade cluster --cluster=<cluster_name|cluster_id>

    클러스터는 즉각적인 업그레이드를 위해 예약됩니다. 이 작업은 Pod 중단 예산과 같은 워크로드 구성에 따라 1시간 이상 걸릴 수 있습니다.

    업그레이드가 완료되면 이메일을 받습니다. ROSA CLI에서 rosa describe cluster 명령을 다시 실행하거나 OpenShift Cluster Manager 콘솔에서 상태를 확인하여 상태를 확인할 수도 있습니다.

문제 해결

3.2.2. OpenShift Cluster Manager 콘솔을 통해 개별 업그레이드 예약

OpenShift Cluster Manager 콘솔을 사용하여 AWS 클러스터에서 Red Hat OpenShift Service의 업그레이드를 한 번 수동으로 예약할 수 있습니다.

절차

  1. OpenShift Cluster Manager Hybrid Cloud Console 에 로그인합니다.
  2. 업그레이드할 클러스터를 선택합니다.
  3. 설정 탭을 클릭합니다.
  4. 업데이트 전략 창에서 개별 업데이트를 선택합니다.
  5. 클러스터를 업그레이드할 버전을 선택합니다. 권장되는 클러스터 업그레이드가 UI에 표시됩니다.

  6. 승인이 필요한 업데이트 버전을 선택하는 경우 관리자의 승인을 요청한 후 승인을 클릭하고 계속.

    관리자 승인에 대한 자세한 내용은 OpenShift 4.9로 업그레이드할 때 관리자 승인을 참조하십시오.

  7. 노드 드레이닝 창에서 목록에서 유예 기간을 선택합니다. 유예 기간을 사용하면 Pod 제거를 강제 적용하기 전에 노드가 정상적으로 드레인될 수 있습니다. 기본값은 1시간 입니다.
  8. 업데이트 전략 창에서 저장 을 클릭하여 업데이트 전략을 적용합니다.

  9. Update status 창에서 사용 가능한 업데이트 정보를 검토하고 업데이트를 클릭합니다.

    참고

    Update 버튼은 업그레이드를 사용할 수 있는 경우에만 활성화됩니다.

  10. 버전 선택 대화 상자에서 대상 업그레이드 버전을 선택하고 다음을 클릭합니다.

  11. 스케줄 업데이트 대화 상자에서 클러스터 업그레이드를 예약합니다.

    • 한 시간 내에 업그레이드하려면 지금 업데이트를 선택하고 다음을 클릭합니다.
    • 나중에 업그레이드하려면 일정을 다른 시간을 선택하고 업그레이드 시간 및 날짜를 설정합니다. 다음을 클릭하여 확인 대화 상자로 이동합니다.

  12. 버전 및 일정 요약을 검토한 후 업데이트 확인 을 선택합니다.

    클러스터는 대상 버전으로 업그레이드되도록 예약됩니다. 이 작업은 선택한 업그레이드 일정 및 Pod 중단 예산과 같은 워크로드 구성에 따라 1시간 이상 걸릴 수 있습니다.

    상태가 Update status 창에 표시됩니다.

문제 해결

3.2.3. 클러스터에 대한 반복 업그레이드 예약

OpenShift Cluster Manager 콘솔을 통해 AWS 클러스터에서 Red Hat OpenShift Service의 z-stream 패치 버전에 대한 반복적인 자동 업그레이드를 예약할 수 있습니다.

절차

  1. OpenShift Cluster Manager Hybrid Cloud Console 에 로그인합니다.
  2. 업그레이드할 클러스터를 선택합니다.
  3. 설정 탭을 클릭합니다.
  4. 업데이트 전략 창에서 업데이트 취소를 선택합니다.
  5. 업데이트를 사용할 수 있는 경우 원하는 요일과 업그레이드 시작 시간을 선택합니다.

  6. 관리자의 승인을 제공하고 승인을 클릭한 후 계속합니다. OpenShift Cluster Manager는 관리자의 승인을 받지 않고 마이너 버전에 대해 예정된 y-stream 업데이트를 시작하지 않습니다.

    관리자 승인에 대한 자세한 내용은 OpenShift 4.9로 업그레이드할 때 관리자 승인을 참조하십시오.

  7. 노드 드레이닝 창에서 목록에서 유예 기간을 선택합니다. 유예 기간을 사용하면 Pod 제거를 강제 적용하기 전에 노드가 정상적으로 드레인될 수 있습니다. 기본값은 1시간 입니다.

  8. 업데이트 전략 창에서 저장 을 클릭하여 업데이트 전략을 적용합니다.

    업그레이드를 사용할 수 있는 경우 기본 요일과 시작 시간에 클러스터에 자동으로 적용됩니다.

4장. HCP를 사용하여 ROSA 업그레이드

4.1. 라이프 사이클 정책 및 계획

업그레이드를 계획하려면 AWS의 Red Hat OpenShift Service on AWS 업데이트 라이프 사이클을 검토하십시오. 라이프 사이클 페이지에는 릴리스 정의, 지원 및 업그레이드 요구 사항, 설치 정책 정보 및 라이프 사이클 날짜가 포함됩니다.

클러스터를 수동으로 업그레이드할 수 있습니다. Red Hat 사이트 안정성 엔지니어(SRE)는 업그레이드 진행 상황을 모니터링하고 발생한 문제를 해결합니다.

4.2. ROSA 클러스터 업그레이드

ROSA(Red Hat OpenShift Service on AWS) CLI를 통해 개별 업그레이드를 사용하여 호스팅되는 컨트롤 플레인(HCP) 클러스터로 Red Hat OpenShift Service on AWS (ROSA)를 업그레이드할 수 있습니다.

참고

예약된 업그레이드 정책에 따라 즉시 업그레이드하더라도 업그레이드 프로세스가 시작되기 30분 이상 지연될 수 있습니다. 또한 업그레이드 기간은 워크로드 구성 및 머신 풀 업그레이드, 작업자 노드 수에 따라 달라질 수 있습니다.

4.2.1. ROSA CLI로 업그레이드

ROSA CLI(rosa)를 사용하여 AWS(ROSA)의 Red Hat OpenShift Service를 수동으로 업그레이드할 수 있습니다.

이 방법은 최신 버전을 사용할 수 있는 경우 즉시 업그레이드를 위해 클러스터를 예약합니다.

사전 요구 사항

  • 설치 호스트에 최신 ROSA CLI를 설치하고 구성했습니다.

절차

  1. 현재 버전의 클러스터를 확인하려면 다음 명령을 입력합니다. 

    $ rosa describe cluster --cluster=<cluster_name|cluster_id> 1
    1
    & lt;cluster_name|cluster_id >를 클러스터 이름 또는 클러스터 ID로 바꿉니다.

  2. 업그레이드를 사용할 수 있는지 확인하려면 다음 명령을 입력합니다. 

    $ rosa list upgrade --cluster=<cluster_name|cluster_id>

    이 명령은 권장 버전을 포함하여 클러스터를 업그레이드할 수 있는 버전 목록을 반환합니다.

  3. 클러스터를 사용 가능한 최신 버전으로 업그레이드하려면 다음 명령을 입력합니다. 

    $ rosa upgrade cluster --cluster=<cluster_name|cluster_id> --control-plane

    클러스터는 즉각적인 업그레이드를 위해 예약됩니다. 이 작업은 Pod 중단 예산과 같은 워크로드 구성에 따라 1시간 이상 걸릴 수 있습니다.

    업그레이드가 완료되면 이메일을 받습니다. ROSA CLI에서 rosa describe cluster 명령을 다시 실행하거나 OpenShift Cluster Manager 콘솔에서 상태를 확인하여 상태를 확인할 수도 있습니다.

문제 해결

법적 공지

Copyright © 2023 Red Hat, Inc.
The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/. In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version.
Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.
Red Hat, Red Hat Enterprise Linux, the Shadowman logo, the Red Hat logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
Node.js® is an official trademark of Joyent. Red Hat is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.
The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation's permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.
All other trademarks are the property of their respective owners.