지원콘솔개발자평가판 시작연락처

2장. 클러스터 업데이트 준비

2.1. OpenShift Container Platform 4.16으로 업데이트 준비

클러스터 관리자가 업데이트를 성공적으로 초기화하기 위해 수행해야 하는 관리 작업과 성공적인 업데이트를 보장하기 위한 선택적 지침에 대해 자세히 알아보십시오.

2.1.1. RHEL 9.2 마이크로 아키텍처 요구 사항 변경

OpenShift Container Platform은 이제 RHEL 9.2 호스트 운영 체제를 기반으로 합니다. 마이크로 아키텍처 요구 사항이 x86_64-v2, Power9 및 Z14로 향상되었습니다. RHEL 마이크로 아키텍처 요구 사항 설명서를 참조하십시오. 이 KCS 문서에 설명된 절차를 따라 업데이트하여 호환성을 확인할 수 있습니다.

중요

올바른 마이크로 아키텍처 요구 사항이 없으면 업데이트 프로세스가 실패합니다. 각 아키텍처에 적합한 서브스크립션을 구매해야 합니다. 자세한 내용은 Red Hat Enterprise Linux 시작하기 - 추가 아키텍처를참조하십시오.

2.1.2. Kubernetes API 제거

OpenShift Container Platform 4.16에서는 더 이상 사용되지 않는 몇 가지 API를 제거한 Kubernetes 1.29를 사용합니다.

클러스터 관리자는 OpenShift Container Platform 4.15에서 4.16으로 클러스터를 업데이트하기 전에 수동 승인을 제공해야 합니다. 이는 OpenShift Container Platform 4.16으로 업그레이드한 후에도 문제를 방지하기 위한 것입니다. 여기서 제거된 API는 클러스터에서 실행되거나 클러스터와 상호 작용하는 워크로드, 툴 또는 기타 구성 요소에서 계속 사용되고 있습니다. 관리자는 제거될 모든 API에 대해 클러스터를 평가하고 영향을 받는 구성 요소를 마이그레이션하여 적절한 새 API 버전을 사용해야 합니다. 이 평가 및 마이그레이션이 완료되면 관리자는 승인을 제공할 수 있습니다.

OpenShift Container Platform 4.15 클러스터를 4.16으로 업데이트하려면 관리자 승인을 제공해야 합니다.

2.1.2.1. 제거된 Kubernetes API

OpenShift Container Platform 4.16에서는 더 이상 사용되지 않는 다음과 같은 API를 제거한 Kubernetes 1.29를 사용합니다. 적절한 API 버전을 사용하려면 매니페스트 및 API 클라이언트를 마이그레이션해야 합니다. 제거된 API 마이그레이션에 대한 자세한 내용은 Kubernetes 설명서 를 참조하십시오.

표 2.1. Kubernetes 1.29에서 제거된 API
리소스제거된 API마이그레이션 대상주요 변경 사항

FlowSchema

flowcontrol.apiserver.k8s.io/v1beta2

flowcontrol.apiserver.k8s.io/v1 또는 flowcontrol.apiserver.k8s.io/v1beta3

없음

PriorityLevelConfiguration

flowcontrol.apiserver.k8s.io/v1beta2

flowcontrol.apiserver.k8s.io/v1 또는 flowcontrol.apiserver.k8s.io/v1beta3

제공됨

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

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

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

다음 릴리스에서 제거될 API가 사용 중인 경우 두 개의 경고가 발생합니다.

  • APIRemovedInNextReleaseInUse - OpenShift Container Platform의 다음 릴리스에서 제거될 API의 경우
  • APIRemovedIn다음 EUSReleaseInUse - OpenShift Container Platform EUS (Extended Update Support) 릴리스에서 제거될 API의 경우

이러한 경고 중 하나가 클러스터에서 실행 중인 경우 경고를 검토하고 새 API 버전을 사용하도록 매니페스트 및 API 클라이언트를 마이그레이션하여 경고를 지우는 조치를 취합니다.

경고에서 이 정보를 제공하지 않기 때문에 APIRequestCount API를 사용하여 사용 중인 API와 제거된 API를 사용하는 워크로드에 대한 자세한 정보를 가져옵니다. 또한 일부 API는 이러한 경고를 트리거하지 않을 수 있지만 APIRequestCount 에서 캡처됩니다. 경고는 프로덕션 시스템에서 경고 피로를 피하기 위해 덜 민감하도록 조정됩니다.

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

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

사전 요구 사항

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

프로세스

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

    $ oc get apirequestcounts

    출력 예

    NAME                                                                 REMOVEDINRELEASE   REQUESTSINCURRENTHOUR   REQUESTSINLAST24H
...
flowschemas.v1beta2.flowcontrol.apiserver.k8s.io                     1.29               0                       3
...
prioritylevelconfigurations.v1beta2.flowcontrol.apiserver.k8s.io     1.29               0                       1
...

    중요

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

    • system:serviceaccount:kube-system:generic-garbage-collector 및 system:serviceaccount:kube-system:namespace-controller 사용자는 제거할 리소스를 검색할 때 등록된 API를 호출하므로 결과에 표시될 수 있습니다.
    • system:kube-controller-manager 및 system:cluster-policy-controller 사용자는 다양한 정책을 적용하는 동안 모든 리소스를 통과하기 때문에 결과에 표시될 수 있습니다.

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

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

    출력 예

    1.29	flowschemas.v1beta2.flowcontrol.apiserver.k8s.io
1.29	prioritylevelconfigurations.v1beta2.flowcontrol.apiserver.k8s.io

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

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

사전 요구 사항

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

프로세스

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

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

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

    $ oc get apirequestcounts flowschemas.v1beta2.flowcontrol.apiserver.k8s.io -o yaml

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

    $ oc get apirequestcounts flowschemas.v1beta2.flowcontrol.apiserver.k8s.io \
  -o jsonpath='{range .status.currentHour..byUser[*]}{..byVerb[*].verb}{","}{.username}{","}{.userAgent}{"\n"}{end}' \
  | sort -k 2 -t, -u | column -t -s, -NVERBS,USERNAME,USERAGENT

    출력 예

    VERBS     USERNAME                            USERAGENT
create    system:admin                        oc/4.13.0 (linux/amd64)
list get  system:serviceaccount:myns:default  oc/4.16.0 (linux/amd64)
watch     system:serviceaccount:myns:webhook  webhook/v1.0.0 (linux/amd64)

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

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

2.1.2.4. 관리자 확인 제공

제거된 API에 대해 클러스터를 평가하고 제거된 API를 마이그레이션한 후 클러스터가 OpenShift Container Platform 4.15에서 4.16으로 업그레이드할 준비가 되었음을 확인할 수 있습니다.

주의

이 관리자 승인을 제공하기 전에 제거된 API의 모든 사용이 해결되고 필요에 따라 마이그레이션되었는지 확인하는 모든 책임은 관리자에게 있음을 유의하십시오. OpenShift Container Platform은 평가를 지원할 수 있지만 제거된 API, 특히 유휴 워크로드 또는 외부 툴의 모든 사용을 식별할 수 없습니다.

사전 요구 사항

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

프로세스

  • 다음 명령을 실행하여 평가를 완료했으며 OpenShift Container Platform 4.16에서 Kubernetes API 제거를 수행할 준비가 되었는지 확인합니다. 

    $ oc -n openshift-config patch cm admin-acks --patch '{"data":{"ack-4.15-kube-1.29-api-removals-in-4.16":"true"}}' --type=merge

2.1.3. 조건부 업데이트의 위험 평가

조건부 업데이트는 클러스터에 적용되는 알려진 위험으로 인해 사용할 수 있지만 권장되지 않는 업데이트 대상입니다. CVO(Cluster Version Operator)는 업데이트 권장 사항에 대한 최신 데이터에 대해 OSUS(OpenShift Update Service)를 주기적으로 쿼리하고 일부 잠재적인 업데이트 대상에는 관련 위험이 있을 수 있습니다.

CVO는 조건부 위험을 평가하고 위험이 클러스터에 적용되지 않으면 대상 버전을 클러스터에 권장되는 업데이트 경로로 사용할 수 있습니다. 위험이 적용 가능한 것으로 확인되거나 어떤 이유로 CVO가 위험을 평가할 수 없는 경우 업데이트 대상을 조건부 업데이트로 클러스터에 사용할 수 있습니다.

대상 버전으로 업데이트하려는 동안 조건부 업데이트가 발생하면 클러스터를 해당 버전으로 업데이트할 위험을 평가해야 합니다. 일반적으로 해당 대상 버전으로 업데이트할 특정 필요가 없는 경우 Red Hat에서 권장 업데이트 경로를 기다리는 것이 좋습니다.

그러나 중요한 CVE를 수정해야 하는 경우와 같이 해당 버전으로 업데이트해야 하는 강력한 이유가 있는 경우 CVE를 수정할 때 클러스터에 문제가 발생할 위험이 발생할 수 있습니다. 다음 작업을 완료하여 업데이트 위험에 대한 Red Hat 평가에 동의했는지 여부를 확인할 수 있습니다.

  • 프로덕션 환경에서 업데이트를 쉽게 완료할 수 있도록 비프로덕션 환경에서 광범위한 테스트를 완료합니다.
  • 조건부 업데이트 설명에 제공된 링크를 따르고 버그를 조사하고 클러스터에 문제가 발생할 가능성이 있는지 확인합니다. 위험을 이해하는 데 도움이 필요하면 Red Hat 지원에 문의하십시오.

추가 리소스

2.1.4. 클러스터 업데이트 전 etcd 백업

etcd 백업은 클러스터의 상태와 모든 리소스 오브젝트를 기록합니다. 백업을 사용하여 현재 기능 상태의 클러스터를 복구할 수 없는 재해 시나리오에서 클러스터 상태를 복원할 수 있습니다.

업데이트 컨텍스트에서 업데이트로 인해 이전 클러스터 버전으로 되돌리지 않고 수정할 수 없는 치명적인 조건이 포함된 경우 클러스터의 etcd 복원을 시도할 수 있습니다. etcd 복원은 파괴적이고 실행 중인 클러스터로 불안정할 수 있으며 이를 마지막 수단으로만 사용합니다.

주의

결과적으로 etcd 복원은 롤백 솔루션으로 사용되지 않습니다. 클러스터를 이전 버전으로 롤백하는 것은 지원되지 않습니다. 업데이트가 완료되지 않으면 Red Hat 지원에 문의하십시오.

etcd 복원의 실행 가능성에 영향을 미치는 몇 가지 요소가 있습니다. 자세한 내용은 " etcd 데이터 백업" 및 "이전 클러스터 상태로 복구"를 참조하십시오.

추가 리소스

2.1.5. 클러스터 업데이트 모범 사례

OpenShift Container Platform은 업데이트 중에 워크로드 중단을 최소화하는 강력한 업데이트 환경을 제공합니다. 업데이트 요청 시 클러스터가 업그레이드 가능 상태가 되지 않으면 업데이트가 시작되지 않습니다.

이 설계에서는 업데이트를 시작하기 전에 몇 가지 주요 조건을 적용하지만 클러스터 업데이트가 성공할 가능성을 높이기 위해 수행할 수 있는 여러 작업이 있습니다.

2.1.5.2. 클러스터의 모든 심각한 경고 해결

중요한 경고는 항상 가능한 한 빨리 처리해야 하지만 클러스터 업데이트를 시작하기 전에 이러한 경고를 해결하고 문제를 해결하는 것이 특히 중요합니다. 업데이트를 시작하기 전에 중요한 경고를 해결하지 못하면 클러스터에 문제가 발생할 수 있습니다.

웹 콘솔의 관리자 화면에서 모니터링 경고로 이동하여 중요한 경고를 찾습니다.

2.1.5.3. 클러스터가 Upgradable 상태인지 확인합니다.

하나 이상의 Operator에서 업그레이드 가능 조건을 1시간 이상 True 로 보고하지 않으면 클러스터에서 ClusterNotUpgradeable 경고 경고가 트리거됩니다. 대부분의 경우 이 경고는 패치 업데이트를 차단하지 않지만 이 경고를 해결하고 모든 Operator에서 Upgradeable 을 True 로 보고할 때까지 마이너 버전 업데이트를 수행할 수 없습니다.

Upgradeable 조건에 대한 자세한 내용은 추가 리소스 섹션의 "클러스터 Operator 상태 유형 이해"를 참조하십시오.

2.1.5.4. 충분한 예비 노드를 사용할 수 있는지 확인

특히 클러스터 업데이트를 시작할 때 예비 노드 용량이 거의 없는 클러스터를 실행하지 않아야 합니다. 실행 중이 아니며 사용 불가능한 노드는 클러스터 워크로드에 대한 중단을 최소화하여 클러스터 업데이트를 수행할 수 있는 기능을 제한할 수 있습니다.

클러스터의 maxUnavailable 사양의 구성된 값에 따라 사용 가능한 노드가 있는 경우 클러스터에서 머신 구성 변경 사항을 노드에 적용하지 못할 수 있습니다. 또한 컴퓨팅 노드에 여유 용량이 충분하지 않으면 첫 번째 노드가 오프라인 상태로 전환되는 동안 워크로드를 일시적으로 다른 노드로 전환하지 못할 수 있습니다.

노드 업데이트 가능성을 늘리려면 각 작업자 풀에 사용 가능한 노드와 컴퓨팅 노드에 충분한 예비 용량이 있는지 확인합니다.

주의

maxUnavailable 의 기본 설정은 OpenShift Container Platform의 모든 머신 구성 풀에 대해 1 입니다. 이 값을 변경하지 않고 한 번에 하나의 컨트롤 플레인 노드를 업데이트하는 것이 좋습니다. 컨트롤 플레인 풀의 경우 이 값을 3 으로 변경하지 마십시오.

2.1.5.5. 클러스터의 PodDisruptionBudget이 올바르게 구성되었는지 확인합니다.

PodDisruptionBudget 오브젝트를 사용하여 언제든지 사용할 수 있어야 하는 최소 Pod 복제본 수 또는 백분율을 정의할 수 있습니다. 이 구성은 클러스터 업데이트와 같은 유지 관리 작업 중에 워크로드가 중단되지 않도록 보호합니다.

그러나 클러스터 업데이트 중에 노드가 드레이닝 및 업데이트되지 않도록 지정된 토폴로지에 대해 PodDisruptionBudget 을 구성할 수 있습니다.

클러스터 업데이트를 계획할 때 다음 요인에 대해 PodDisruptionBudget 오브젝트의 구성을 확인합니다.

  • 고가용성 워크로드의 경우 PodDisruptionBudget 에서 금지하지 않고 일시적으로 오프라인으로 전환할 수 있는 복제본이 있는지 확인합니다.
  • 고가용성이 아닌 워크로드의 경우 PodDisruptionBudget 에 의해 보호되지 않았는지 확인하거나 정기적인 재시작 또는 보장된 최종 종료와 같이 이러한 워크로드를 드레이닝하기 위한 몇 가지 대체 메커니즘이 있는지 확인하십시오.

추가 리소스

Red Hat logoGithubRedditYoutubeTwitter

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

Red Hat을 사용하는 고객은 신뢰할 수 있는 콘텐츠가 포함된 제품과 서비스를 통해 혁신하고 목표를 달성할 수 있습니다.

보다 포괄적 수용을 위한 오픈 소스 용어 교체

Red Hat은 코드, 문서, 웹 속성에서 문제가 있는 언어를 교체하기 위해 최선을 다하고 있습니다. 자세한 내용은 다음을 참조하세요.Red Hat 블로그.

Red Hat 소개

Red Hat은 기업이 핵심 데이터 센터에서 네트워크 에지에 이르기까지 플랫폼과 환경 전반에서 더 쉽게 작업할 수 있도록 강화된 솔루션을 제공합니다.

© 2024 Red Hat, Inc.