1.2. 클러스터 업데이트 작동 방식
다음 섹션에서는 OpenShift Container Platform(OCP) 업데이트 프로세스의 각 주요 측면을 자세히 설명합니다. 업데이트가 작동하는 방법에 대한 일반적인 개요는 OpenShift 업데이트 소개를 참조하십시오.
1.2.1. 클러스터 버전 연산자 링크 복사링크가 클립보드에 복사되었습니다!
클러스터 버전 운영자(CVO)는 OpenShift 컨테이너 플랫폼 업데이트 프로세스를 조율하고 원활하게 하는 주요 구성 요소입니다. 설치 및 표준 클러스터 운영 중에 CVO는 관리되는 클러스터 운영자의 매니페스트를 클러스터 내 리소스와 지속적으로 비교하고, 불일치 사항을 조정하여 이러한 리소스의 실제 상태가 원하는 상태와 일치하는지 확인합니다.
1.2.1.1. ClusterVersion 오브젝트 링크 복사링크가 클립보드에 복사되었습니다!
CVO(Cluster Version Operator)가 모니터링하는 리소스 중 하나는 ClusterVersion
리소스입니다.
관리자와 OpenShift 구성 요소는 ClusterVersion
객체를 통해 CVO와 통신하거나 상호 작용할 수 있습니다. 원하는 CVO 상태는 ClusterVersion
객체를 통해 선언되고 현재 CVO 상태는 객체의 상태에 반영됩니다.
ClusterVersion
객체를 직접 수정하지 마세요. 대신 oc
CLI나 웹 콘솔과 같은 인터페이스를 사용하여 업데이트 대상을 선언하세요.
CVO는 ClusterVersion
리소스의 spec
속성에 선언된 대상 상태와 클러스터를 지속적으로 조정합니다. 원하는 릴리스가 실제 릴리스와 다른 경우 해당 조정을 통해 클러스터가 업데이트됩니다.
가용성 데이터 업데이트
ClusterVersion
리소스에는 클러스터에서 사용할 수 있는 업데이트에 대한 정보도 포함되어 있습니다. 여기에는 클러스터에 적용되는 알려진 위험으로 인해 사용 가능하지만 권장되지 않는 업데이트가 포함됩니다. 이러한 업데이트는 조건부 업데이트라고 합니다. CVO가 ClusterVersion
리소스에서 사용 가능한 업데이트에 대한 정보를 어떻게 유지 관리하는지 알아보려면 "업데이트 가용성 평가" 섹션을 참조하세요.
다음 명령을 사용하면 사용 가능한 모든 업데이트를 검사할 수 있습니다.
oc adm upgrade --include-not-recommended
$ oc adm upgrade --include-not-recommended
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 참고추가
--include-not-recommended
매개변수에는 클러스터에 적용되는 알려진 문제가 있는 업데이트가 포함됩니다.출력 예
Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc adm upgrade
명령은 사용 가능한 업데이트에 대한 정보를ClusterVersion
리소스에 쿼리하여 사람이 읽을 수 있는 형식으로 표시합니다.CVO가 생성한 기본 가용성 데이터를 직접 검사하는 한 가지 방법은 다음 명령을 사용하여
ClusterVersion
리소스를 쿼리하는 것입니다.oc get clusterversion version -o json | jq '.status.availableUpdates'
$ oc get clusterversion version -o json | jq '.status.availableUpdates'
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 비슷한 명령을 사용하여 조건부 업데이트를 확인할 수 있습니다.
oc get clusterversion version -o json | jq '.status.conditionalUpdates'
$ oc get clusterversion version -o json | jq '.status.conditionalUpdates'
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
1.2.1.2. 업데이트 가용성 평가 링크 복사링크가 클립보드에 복사되었습니다!
클러스터 버전 운영자(CVO)는 업데이트 가능성에 대한 최신 데이터를 얻기 위해 OpenShift 업데이트 서비스(OSUS)에 주기적으로 쿼리를 보냅니다. 이 데이터는 클러스터의 구독 채널을 기반으로 합니다. 그런 다음 CVO는 ClusterVersion
리소스의 availableUpdates
또는 conditionalUpdates
필드에 업데이트 권장 사항에 대한 정보를 저장합니다.
CVO는 업데이트 위험에 대한 조건부 업데이트를 주기적으로 확인합니다. 이러한 위험은 OSUS에서 제공하는 데이터를 통해 전달됩니다. 이 데이터에는 해당 버전으로 업데이트된 클러스터에 영향을 미칠 수 있는 알려진 문제에 대한 정보가 각 버전별로 포함되어 있습니다. 대부분의 위험은 특정 규모의 클러스터나 특정 클라우드 플랫폼에 배포된 클러스터 등 특정한 특성을 지닌 클러스터에 국한됩니다.
CVO는 각 조건부 업데이트에 대한 조건부 위험 정보에 대해 클러스터 특성을 지속적으로 평가합니다. CVO가 클러스터가 기준에 부합한다고 판단하면 CVO는 이 정보를 ClusterVersion
리소스의 conditionalUpdates
필드에 저장합니다. CVO가 클러스터가 업데이트 위험에 맞지 않거나 업데이트와 관련된 위험이 없다고 판단하는 경우, ClusterVersion
리소스의 availableUpdates
필드에 대상 버전을 저장합니다.
사용자 인터페이스(웹 콘솔 또는 OpenShift CLI( oc
))는 이 정보를 섹션별 제목으로 관리자에게 표시합니다. 업데이트 경로와 관련된 각 알려진 문제에는 해당 위험에 대한 추가 리소스에 대한 링크가 포함되어 있어 관리자가 업데이트에 대한 정보에 입각한 결정을 내릴 수 있습니다.
1.2.2. 릴리스 이미지 링크 복사링크가 클립보드에 복사되었습니다!
릴리스 이미지는 특정 OpenShift Container Platform(OCP) 버전을 제공하는 메커니즘입니다. 여기에는 릴리스 메타데이터, 릴리스 버전과 일치하는 클러스터 버전 운영자(CVO) 바이너리, 개별 OpenShift 클러스터 운영자를 배포하는 데 필요한 모든 매니페스트, 이 OpenShift 버전을 구성하는 모든 컨테이너 이미지에 대한 SHA 다이제스트 버전 참조 목록이 포함됩니다.
다음 명령을 실행하여 특정 릴리스 이미지의 내용을 검사할 수 있습니다.
oc adm release extract <release image>
$ oc adm release extract <release image>
출력 예
1.2.3. 프로세스 워크플로 업데이트 링크 복사링크가 클립보드에 복사되었습니다!
다음 단계는 OpenShift Container Platform(OCP) 업데이트 프로세스의 자세한 워크플로를 나타냅니다.
-
대상 버전은
ClusterVersion
리소스의spec.desiredUpdate.version
필드에 저장되며, 웹 콘솔이나 CLI를 통해 관리할 수 있습니다. -
클러스터 버전 운영자(CVO)는
ClusterVersion
리소스의desiredUpdate
가 현재 클러스터 버전과 다르다는 것을 감지합니다. CVO는 OpenShift 업데이트 서비스의 그래프 데이터를 사용하여 원하는 클러스터 버전을 릴리스 이미지에 대한 풀 사양으로 변환합니다. - CVO는 릴리스 이미지의 무결성과 진위성을 검증합니다. Red Hat은 이미지 SHA 다이제스트를 고유하고 변경할 수 없는 릴리스 이미지 식별자로 사용하여 사전 정의된 위치에 게시된 릴리스 이미지에 대한 암호화된 서명된 진술을 게시합니다. CVO는 내장된 공개 키 목록을 활용하여 검사된 릴리스 이미지와 일치하는 진술의 존재와 서명을 검증합니다.
-
CVO는
openshift-cluster-version
네임스페이스에version-$version-$hash라는
이름의 작업을 생성합니다. 이 작업은 릴리스 이미지를 실행하는 컨테이너를 사용하므로 클러스터는 컨테이너 런타임을 통해 이미지를 다운로드합니다. 그런 다음 작업은 릴리스 이미지에서 매니페스트와 메타데이터를 추출하여 CVO에서 액세스할 수 있는 공유 볼륨으로 보냅니다. - CVO는 추출된 매니페스트 및 메타데이터의 유효성을 검사합니다.
- CVO는 클러스터에서 문제 조건이 감지되지 않는지 확인하기 위해 몇 가지 전제 조건을 확인합니다. 특정 조건으로 인해 업데이트가 진행되지 않을 수 있습니다. 이러한 조건은 CVO 자체에서 결정하거나, 클러스터 운영자가 업데이트를 위해 문제가 있다고 생각하는 클러스터에 대한 세부 정보를 감지하여 보고합니다.
-
CVO는 승인된 릴리스를
status.desired
에 기록하고 새 업데이트에 대한status.history
항목을 만듭니다. - CVO가 릴리스 이미지에서 매니페스트를 조정하기 시작합니다. 클러스터 연산자는 런레벨이라고 하는 별도의 단계로 업데이트되며, CVO는 런레벨에 있는 모든 연산자가 다음 레벨로 넘어가기 전에 업데이트를 완료하도록 보장합니다.
- CVO 자체에 대한 매니페스트는 프로세스 초기에 적용됩니다. CVO 배포가 적용되면 현재 CVO 포드가 중지되고 새 버전을 사용하는 CVO 포드가 시작됩니다. 새 CVO는 나머지 매니페스트를 조정합니다.
-
업데이트는 전체 제어 평면이 새 버전으로 업데이트될 때까지 진행됩니다. 개별 클러스터 운영자는 클러스터의 해당 도메인에서 업데이트 작업을 수행할 수 있으며, 작업을 수행하는 동안
Progressing=True
조건을 통해 상태를 보고합니다. - MCO(Machine Config Operator) 매니페스트는 프로세스의 마지막에 적용됩니다. 업데이트된 MCO는 모든 노드의 시스템 구성과 운영 체제 업데이트를 시작합니다. 각 노드는 다시 작업 부하를 수용하기 전에 비워지고, 업데이트되고, 재부팅될 수 있습니다.
클러스터는 제어 평면 업데이트가 완료된 후, 일반적으로 모든 노드가 업데이트되기 전에 업데이트된 것으로 보고합니다. 업데이트 후 CVO는 모든 클러스터 리소스를 릴리스 이미지에서 제공된 상태와 일치하도록 유지 관리합니다.
1.2.4. 업데이트 중에 매니페스트가 적용되는 방식 이해 링크 복사링크가 클립보드에 복사되었습니다!
릴리스 이미지에 제공된 일부 매니페스트는 매니페스트 간의 종속성으로 인해 특정 순서로 적용해야 합니다. 예를 들어, CustomResourceDefinition
리소스는 일치하는 사용자 지정 리소스보다 먼저 생성되어야 합니다. 또한, 클러스터의 중단을 최소화하기 위해 개별 클러스터 운영자를 업데이트하는 데에는 논리적 순서가 있습니다. 클러스터 버전 운영자(CVO)는 실행 수준이라는 개념을 통해 이러한 논리적 순서를 구현합니다.
이러한 종속성은 릴리스 이미지의 매니페스트 파일 이름에 인코딩되어 있습니다.
0000_<runlevel>_<component>_<manifest-name>.yaml
0000_<runlevel>_<component>_<manifest-name>.yaml
예를 들면 다음과 같습니다.
0000_03_config-operator_01_proxy.crd.yaml
0000_03_config-operator_01_proxy.crd.yaml
CVO는 매니페스트에 대한 종속성 그래프를 내부적으로 구축하며, CVO는 다음 규칙을 따릅니다.
- 업데이트 중에는 낮은 Runlevel의 매니페스트가 높은 Runlevel의 매니페스트보다 먼저 적용됩니다.
- 하나의 Runlevel 내에서 다양한 구성 요소에 대한 매니페스트를 병렬로 적용할 수 있습니다.
- 하나의 Runlevel 내에서는 단일 구성 요소에 대한 매니페스트가 사전식 순서로 적용됩니다.
그런 다음 CVO는 생성된 종속성 그래프에 따라 매니페스트를 적용합니다.
일부 리소스 유형의 경우 CVO는 매니페스트가 적용된 후 리소스를 모니터링하고 리소스가 안정적인 상태에 도달한 후에만 업데이트가 성공적으로 완료된 것으로 간주합니다. 이 상태에 도달하는 데는 시간이 걸릴 수 있습니다. 이는 ClusterOperator
리소스의 경우 특히 그렇습니다. CVO는 클러스터 운영자가 자신을 업데이트한 다음 해당 ClusterOperator
상태를 업데이트할 때까지 기다립니다.
CVO는 다음 Runlevel로 진행하기 전에 Runlevel의 모든 클러스터 운영자가 다음 조건을 충족할 때까지 기다립니다.
-
클러스터 연산자에는
Available=True
조건이 있습니다. -
클러스터 연산자에는
Degraded=False
조건이 있습니다.
- 클러스터 운영자는 ClusterOperator 리소스에서 원하는 버전을 달성했다고 선언합니다.
일부 작업은 완료하는 데 상당한 시간이 걸릴 수 있습니다. CVO는 후속 실행 레벨이 안전하게 진행될 수 있도록 작업이 완료될 때까지 기다립니다. 새로운 릴리스의 매니페스트를 처음에 조정하는 데는 총 60~120분이 걸릴 것으로 예상됩니다. 업데이트 기간에 영향을 미치는 요소에 대한 자세한 내용은 OpenShift Container Platform 업데이트 기간 이해를 참조하세요.
이전 예제 다이어그램에서 CVO는 Runlevel 20에서 모든 작업이 완료될 때까지 기다리고 있습니다. CVO는 Runlevel의 Operator에 모든 매니페스트를 적용했지만 kube-apiserver-operator ClusterOperator는
새 버전이 배포된 후 일부 작업을 수행합니다. kube-apiserver-operator ClusterOperator는
Progressing=True
조건을 통해 이 진행 상황을 선언하고 status.versions
에서 새 버전을 조정된 것으로 선언하지 않습니다. CVO는 ClusterOperator가 허용 가능한 상태를 보고할 때까지 기다린 다음 Runlevel 25에서 매니페스트 조정을 시작합니다.
1.2.5. Machine Config Operator가 노드를 업데이트하는 방법 이해 링크 복사링크가 클립보드에 복사되었습니다!
MCO(Machine Config Operator)는 각 제어 평면 노드와 컴퓨팅 노드에 새로운 머신 구성을 적용합니다. 머신 구성 업데이트 동안 제어 플레인 노드와 컴퓨트 노드는 자체 머신 구성 풀로 구성되며, 머신 풀은 병렬로 업데이트됩니다. 기본값이 1
인 .spec.maxUnavailable
매개변수는 머신 구성 풀에서 동시에 업데이트 프로세스를 거칠 수 있는 노드 수를 결정합니다.
OpenShift Container Platform의 모든 머신 구성 풀에 대한 maxUnavailable
의 기본 설정은 1
입니다. 이 값은 변경하지 말고 한 번에 하나의 제어 평면 노드만 업데이트하는 것이 좋습니다. 제어 평면 풀의 경우 이 값을 3
으로 변경하지 마세요.
머신 구성 업데이트 프로세스가 시작되면 MCO는 풀에서 현재 사용할 수 없는 노드의 양을 확인합니다. 사용할 수 없는 노드가 .spec.maxUnavailable
값보다 적으면 MCO는 풀에서 사용 가능한 노드에 대해 다음과 같은 일련의 작업을 시작합니다.
노드를 봉쇄하고 배수합니다.
참고노드가 격리되면 해당 노드에 작업 부하를 예약할 수 없습니다.
- 노드의 시스템 구성 및 운영 체제(OS)를 업데이트합니다.
- 노드를 재부팅하세요
- 노드를 차단 해제합니다
이 프로세스를 거치는 노드는 격리가 해제되고 작업 부하가 다시 예약될 때까지 사용할 수 없습니다. MCO는 사용할 수 없는 노드 수가 .spec.maxUnavailable
값과 같아질 때까지 노드 업데이트를 시작합니다.
노드가 업데이트를 완료하고 사용 가능해지면 머신 구성 풀에서 사용할 수 없는 노드의 수는 다시 .spec.maxUnavailable
보다 적어집니다. 업데이트가 필요한 노드가 남아 있는 경우 MCO는 .spec.maxUnavailable
한도에 다시 도달할 때까지 노드에서 업데이트 프로세스를 시작합니다. 이 프로세스는 각 제어 평면 노드와 컴퓨팅 노드가 업데이트될 때까지 반복됩니다.
다음 예제 워크플로는 5개의 노드가 있는 머신 구성 풀에서 이 프로세스가 어떻게 발생하는지 설명합니다. 여기서 .spec.maxUnavailable
은 3이고 모든 노드가 처음에 사용 가능합니다.
- MCO는 노드 1, 2, 3을 봉쇄하고 배수를 시작합니다.
- 노드 2의 배수가 완료되고 재부팅되어 다시 사용 가능해집니다. MCO가 노드 4를 봉쇄하고 배수를 시작합니다.
- 노드 1의 드레이닝이 완료되고 재부팅되어 다시 사용 가능해집니다. MCO가 노드 5를 봉쇄하고 배수를 시작합니다.
- 노드 3의 배수가 완료되고 재부팅되어 다시 사용 가능해집니다.
- 노드 5의 배수가 완료되고 재부팅되어 다시 사용 가능해집니다.
- 노드 4의 배수가 완료되고 재부팅되어 다시 사용 가능해집니다.
각 노드의 업데이트 프로세스는 다른 노드와 독립적이므로 위의 예에서 일부 노드는 MCO에서 차단된 순서에 관계없이 업데이트를 완료합니다.
다음 명령을 실행하여 머신 구성 업데이트 상태를 확인할 수 있습니다.
oc get mcp
$ oc get mcp
출력 예
NAME CONFIG UPDATED UPDATING DEGRADED MACHINECOUNT READYMACHINECOUNT UPDATEDMACHINECOUNT DEGRADEDMACHINECOUNT AGE master rendered-master-acd1358917e9f98cbdb599aea622d78b True False False 3 3 3 0 22h worker rendered-worker-1d871ac76e1951d32b2fe92369879826 False True False 2 1 1 0 22h
NAME CONFIG UPDATED UPDATING DEGRADED MACHINECOUNT READYMACHINECOUNT UPDATEDMACHINECOUNT DEGRADEDMACHINECOUNT AGE
master rendered-master-acd1358917e9f98cbdb599aea622d78b True False False 3 3 3 0 22h
worker rendered-worker-1d871ac76e1951d32b2fe92369879826 False True False 2 1 1 0 22h