1.4. OpenShift Container Platform 업데이트 기간 이해
OpenShift Container Platform 업데이트 기간은 배포 토폴로지에 따라 다릅니다. 이 페이지에서는 업데이트 기간에 영향을 미치는 요인을 이해하고 환경에서 클러스터 업데이트가 걸리는 시간을 추정할 수 있습니다.
1.4.1. 업데이트 기간에 영향을 미치는 요소
다음 요인은 클러스터 업데이트 기간에 영향을 줄 수 있습니다.
MCO(Machine Config Operator)의 새 머신 구성으로 컴퓨팅 노드를 재부팅
머신 구성 풀에서
MaxUnavailable의 값주의maxUnavailable의 기본 설정은 OpenShift Container Platform의 모든 머신 구성 풀에 대해1입니다. 이 값을 변경하지 않고 한 번에 하나의 컨트롤 플레인 노드를 업데이트하는 것이 좋습니다. 컨트롤 플레인 풀의 경우 이 값을3으로 변경하지 마십시오.- PDB(Pod 중단 예산)에서 설정된 최소 복제본 수 또는 백분율
- 클러스터의 노드 수
- 클러스터 노드의 상태
1.4.2. 클러스터 업데이트 단계
OpenShift Container Platform에서 클러스터 업데이트는 다음 두 단계로 수행됩니다.
- CVO(Cluster Version Operator) 대상 업데이트 페이로드 배포
- MCO(Machine Config Operator) 노드 업데이트
1.4.2.1. Cluster Version Operator 대상 업데이트 페이로드 배포
CVO(Cluster Version Operator)는 대상 업데이트 릴리스 이미지를 검색하고 클러스터에 적용합니다. Pod로 실행되는 모든 구성 요소는 이 단계에서 업데이트되는 반면 호스트 구성 요소는 MCO(Machine Config Operator)에 의해 업데이트됩니다. 이 프로세스는 60~120분 정도 걸릴 수 있습니다.
업데이트의 CVO 단계는 노드를 재시작하지 않습니다.
1.4.2.2. Machine Config Operator 노드 업데이트
MCO(Machine Config Operator)는 각 컨트롤 플레인 및 컴퓨팅 노드에 새 머신 구성을 적용합니다. 이 프로세스 중에 MCO는 클러스터의 각 노드에서 다음 순차적 작업을 수행합니다.
- 모든 노드를 차단 및 드레이닝
- 운영 체제 업데이트 (OS)
- 노드 재부팅
- 모든 노드 차단 해제 및 노드에서 워크로드 예약
노드가 차단되면 워크로드를 예약할 수 없습니다.
이 프로세스를 완료하는 시간은 노드 및 인프라 구성을 포함한 여러 요인에 따라 달라집니다. 이 프로세스를 노드당 완료하는 데 5분 이상 걸릴 수 있습니다.
MCO 외에도 다음 매개변수의 영향을 고려해야 합니다.
- 컨트롤 플레인 워크로드는 정상적인 업데이트 및 빠른 드레이닝을 위해 조정되기 때문에 컨트롤 플레인 노드 업데이트 기간은 예측 가능하고 컴퓨팅 노드보다 짧은 경우가 많습니다.
-
MCP(Machine Config Pool)에서
maxUnavailable필드를1이상으로 설정하여 병렬로 컴퓨팅 노드를 업데이트할 수 있습니다. MCO는maxUnavailable에 지정된 노드 수를 제한하고 업데이트할 수 없음을 표시합니다. -
MCP에서
maxUnavailable을 늘리면 풀이 더 빨리 업데이트하는 데 도움이 될 수 있습니다. 그러나maxUnavailable을 너무 많이 설정하고 여러 노드가 동시에 차단되고 여러 노드가 동시에 차단되는 경우 복제본을 실행하는 데 예약 가능한 노드를 찾을 수 없기 때문에 Pod 중단 예산 (PDB) 보호 워크로드가 드레이닝되지 않을 수 있습니다. MCP에 대해maxUnavailable을 늘리면 PDB 보호 워크로드가 드레인할 수 있는 충분한 스케줄링 가능한 노드가 있는지 확인합니다. 업데이트를 시작하기 전에 모든 노드를 사용할 수 있는지 확인해야 합니다. 노드를 사용할 수 없는 경우
maxUnavailable및 Pod 중단 예산에 영향을 미치므로 사용할 수 없는 노드는 업데이트 기간에 큰 영향을 미칠 수 있습니다.터미널에서 노드 상태를 확인하려면 다음 명령을 실행합니다.
$ oc get node
출력 예
NAME STATUS ROLES AGE VERSION ip-10-0-137-31.us-east-2.compute.internal Ready,SchedulingDisabled worker 12d v1.23.5+3afdacb ip-10-0-151-208.us-east-2.compute.internal Ready master 12d v1.23.5+3afdacb ip-10-0-176-138.us-east-2.compute.internal Ready master 12d v1.23.5+3afdacb ip-10-0-183-194.us-east-2.compute.internal Ready worker 12d v1.23.5+3afdacb ip-10-0-204-102.us-east-2.compute.internal Ready master 12d v1.23.5+3afdacb ip-10-0-207-224.us-east-2.compute.internal Ready worker 12d v1.23.5+3afdacb
노드 상태가
NotReady또는SchedulingDisabled인 경우 노드를 사용할 수 없으며 업데이트 기간에 영향을 미칩니다.컴퓨팅
노드를 확장하여 웹 콘솔의 관리자 화면에서 노드 상태를 확인할 수 있습니다.
1.4.2.3. 클러스터 Operator 업데이트 기간의 예
이전 다이어그램에서는 클러스터 Operator가 새 버전으로 업데이트하는 데 사용할 수 있는 시간의 예를 보여줍니다. 이 예제에서는 정상 컴퓨팅 MachineConfigPool 이 있고 4.13에서 4.14로 업데이트하는 데 오래 걸리는 워크로드가 없는 3-노드 AWS OVN 클러스터를 기반으로 합니다.
- 클러스터 및 Operator의 특정 업데이트 기간은 대상 버전, 노드 양, 노드에 예약된 워크로드 유형과 같은 여러 클러스터 특성에 따라 달라질 수 있습니다.
- Cluster Version Operator와 같은 일부 Operator는 짧은 시간 내에 자체적으로 업데이트합니다. 이러한 Operator는 다이어그램에서 생략되었거나 "Other Operators in parallel"이라는 광범위한 Operator 그룹에 포함되어 있습니다.
각 클러스터 Operator에는 자체 업데이트하는 데 걸리는 시간에 영향을 미치는 특성이 있습니다. 예를 들어 kube-apiserver 가 정상 종료 지원을 제공하므로 이 예제의 Kube API Server Operator는 업데이트하는 데 11분 이상 걸렸습니다. 즉 기존의 in-flight 요청이 정상적으로 완료될 수 있습니다. 이로 인해 kube-apiserver 가 더 오래 종료될 수 있습니다. 이 Operator의 경우 업데이트 속도가 향상되어 업데이트 중에 클러스터 기능 중단을 방지하고 제한하는 데 도움이 됩니다.
Operator의 업데이트 기간에 영향을 미치는 또 다른 특성은 Operator가 DaemonSets를 사용하는지 여부입니다. 네트워크 및 DNS Operator는 전체 클러스터 DaemonSet을 사용하므로 버전 변경 사항을 롤아웃하는 데 시간이 걸릴 수 있으며 이러한 Operator가 자체 업데이트하는 데 시간이 더 오래 걸릴 수 있는 몇 가지 이유 중 하나입니다.
일부 Operator의 업데이트 기간은 클러스터 자체의 특성에 따라 크게 달라집니다. 예를 들어 Machine Config Operator 업데이트는 클러스터의 각 노드에 머신 구성 변경 사항을 적용합니다. 많은 노드가 있는 클러스터에는 노드가 적은 클러스터에 비해 Machine Config Operator의 업데이트 기간이 길어집니다.
각 클러스터 Operator에는 업데이트할 수 있는 단계가 할당됩니다. 동일한 단계 내의 Operator는 동시에 업데이트할 수 있으며 지정된 단계의 Operator는 이전 단계가 모두 완료될 때까지 업데이트를 시작할 수 없습니다. 자세한 내용은 "추가 리소스" 섹션의 "업데이트 중에 매니페스트를 적용하는 방법 이해"를 참조하십시오.
1.4.3. 클러스터 업데이트 시간 추정
유사한 클러스터의 이전 업데이트 기간은 향후 클러스터 업데이트에 가장 적합한 추정치를 제공합니다. 그러나 기록 데이터를 사용할 수 없는 경우 다음 규칙을 사용하여 클러스터 업데이트 시간을 추정할 수 있습니다.
Cluster update time = CVO target update payload deployment time + (# node update iterations x MCO node update time)
노드 업데이트 반복은 병렬로 업데이트되는 하나 이상의 노드로 구성됩니다. 컨트롤 플레인 노드는 항상 컴퓨팅 노드와 병렬로 업데이트됩니다. 또한 maxUnavailable 값에 따라 하나 이상의 컴퓨팅 노드를 병렬로 업데이트할 수 있습니다.
maxUnavailable 의 기본 설정은 OpenShift Container Platform의 모든 머신 구성 풀에 대해 1 입니다. 이 값을 변경하지 않고 한 번에 하나의 컨트롤 플레인 노드를 업데이트하는 것이 좋습니다. 컨트롤 플레인 풀의 경우 이 값을 3 으로 변경하지 마십시오.
예를 들어 업데이트 시간을 추정하려면 컨트롤 플레인 노드와 컴퓨팅 노드 6개가 있는 OpenShift Container Platform 클러스터를 고려하고 각 호스트를 재부팅하는 데 약 5분이 걸립니다.
특정 노드를 재부팅하는 데 걸리는 시간은 크게 다릅니다. 클라우드 인스턴스에서 재부팅에 약 1~2분이 걸릴 수 있지만 물리적 베어 메탈 호스트에서 재부팅 시간이 15분 이상 걸릴 수 있습니다.
scenario-1
컨트롤 플레인 및 컴퓨팅 노드 MCP(Machine Config Pool) 모두에 maxUnavailable 을 1 로 설정하면 각 반복에서 6개의 컴퓨팅 노드가 각각 하나씩 업데이트됩니다.
Cluster update time = 60 + (6 x 5) = 90 minutes
scenario-2
컴퓨팅 노드 MCP에 maxUnavailable 을 2 로 설정하면 각 반복에서 두 개의 컴퓨팅 노드가 병렬로 업데이트됩니다. 따라서 모든 노드를 업데이트하려면 총 세 번의 반복이 필요합니다.
Cluster update time = 60 + (3 x 5) = 75 minutes
maxUnavailable 의 기본 설정은 OpenShift Container Platform의 모든 MCP에 대해 1 입니다. 컨트롤 플레인 MCP에서 maxUnavailable 을 변경하지 않는 것이 좋습니다.
1.4.4. RHEL(Red Hat Enterprise Linux) 컴퓨팅 노드
RHEL(Red Hat Enterprise Linux) 컴퓨팅 노드에는 노드 바이너리 구성 요소를 업데이트하기 위해 openshift-ansible 을 추가로 사용해야 합니다. RHEL 컴퓨팅 노드를 업데이트하는 데 걸리는 실제 시간은 RHCOS(Red Hat Enterprise Linux CoreOS) 컴퓨팅 노드와 크게 달라서는 안 됩니다.
추가 리소스
