8장. 카나리아 롤아웃 업데이트 수행
업데이트 프로세스로 인해 애플리케이션이 실패하더라도 전체 업데이트 중에 미션크리티컬 애플리케이션을 계속 사용할 수 있도록 작업자 노드에 대한 업데이트 롤아웃을 보다 제어해야 하는 몇 가지 시나리오가 있을 수 있습니다. 조직의 요구에 따라 작업자 노드의 작은 하위 집합을 업데이트하고 일정 기간 동안 클러스터 및 워크로드 상태를 평가한 다음 나머지 노드를 업데이트할 수 있습니다. 이를 카나리아 업데이트라고 합니다. 또는 호스트 재부팅이 필요한 작업자 노드 업데이트를 한 번에 전체 클러스터를 업데이트할 수 없는 경우 정의된 더 작은 유지 관리 기간으로 전환해야 할 수도 있습니다.
이러한 시나리오에서는 클러스터를 업데이트할 때 특정 작업자 노드가 업데이트되지 않도록 여러 MCP(사용자 정의 머신 구성 풀)를 생성할 수 있습니다. 나머지 클러스터가 업데이트되면 적절한 시간에 배치로 해당 작업자 노드를 업데이트할 수 있습니다.
예를 들어 초과 용량이 10%인 노드가 100개 있는 클러스터가 있는 경우 유지 관리 기간이 4시간을 넘지 않아야 하며 작업자 노드를 드레이닝하고 재부팅하는 데 8분이 걸리기 때문에 MCP를 활용하여 목표를 달성할 수 있습니다. 예를 들어 각각 10, 30개, 30개의 노드가 있는 workerpool-canary, workerpool-A, workerpool-B, workerpool-C라는 4개의 MCP를 정의할 수 있습니다.
첫 번째 유지 관리 기간 동안 workerpool-A, workerpool-B, workerpool-C에 대한 MCP를 일시 중지한 다음 클러스터 업데이트를 시작합니다. 이 경우 해당 풀이 일시 중지되지 않았기 때문에 OpenShift Container Platform에서 실행되는 구성 요소와 workerpool-canary MCP의 멤버인 10개의 노드가 업데이트되었습니다. 나머지 3개의 MCP는 일시 중지되었으므로 업데이트되지 않습니다. 어떠한 이유로 workerpool-canary 업데이트의 클러스터 또는 워크로드 상태가 부정적인 영향을 미치는 경우 문제를 진단할 때까지 충분한 용량을 유지 관리하면서 해당 풀의 모든 노드를 차단하고 드레이닝합니다. 모든 항목이 예상대로 작동하면 일시 중지 해제를 결정하기 전에 클러스터 및 워크로드 상태를 평가하여 각 추가 유지 관리 기간 동안 연속으로 workerpool-A, workerpool-B, workerpool-C를 업데이트합니다.
사용자 지정 MCP를 사용하여 작업자 노드 업데이트를 관리하는 것은 유연성을 제공하지만 여러 명령을 실행해야 하는 시간이 많이 걸리는 프로세스일 수 있습니다. 이러한 복잡성으로 인해 전체 클러스터에 영향을 줄 수 있는 오류가 발생할 수 있습니다. 시작하기 전에 조직의 요구 사항을 신중하게 고려하고 프로세스 구현을 신중하게 계획하는 것이 좋습니다.
MCP를 다른 OpenShift Container Platform 버전으로 업데이트하지 않는 것이 좋습니다. 예를 들어 한 MCP를 4.y.10에서 4.y.11로 다른 MCP를 4.y.12로 업데이트하지 마십시오. 이 시나리오는 테스트되지 않아 정의되지 않은 클러스터 상태가 될 수 있습니다.
머신 구성 풀을 일시 중지하면 Machine Config Operator가 연결된 노드에 구성 변경 사항을 적용할 수 없습니다. MCP를 일시 중지하면 자동으로 순환된 인증서가 kube-apiserver-to-kubelet-signer CA 인증서의 자동 CA 순환을 포함하여 관련 노드로 푸시되지 않습니다. kube-apiserver-to-kubelet-signer CA 인증서가 만료되고 MCO가 인증서를 자동으로 갱신하려고 하면 새 인증서가 생성되지만 해당 머신 구성 풀의 노드에 적용되지 않습니다. 이로 인해 oc debug, oc logs, oc exec, oc attach를 포함하여 여러 oc 명령이 실패합니다. MCP 일시 중지는 kube-apiserver-to-kubelet-signer CA 인증서 만료에 대해 신중하게 고려하여 단기간 동안만 수행해야 합니다.
8.1. 카나리아 롤아웃 업데이트 프로세스 및 MCP 정보
OpenShift Container Platform에서 노드는 개별적으로 간주되지 않습니다. 노드는 MCP(Machine config pool)로 그룹화됩니다. 기본 OpenShift Container Platform 클러스터에는 두 개의 MCP가 있습니다. 하나는 컨트롤 플레인 노드용이고 하나는 작업자 노드용입니다. OpenShift Container Platform 업데이트는 모든 MCP에 동시에 영향을 미칩니다.
업데이트 중에 MCO (Machine Config Operator)는 기본적으로 1에서 지정된 maxUnavailable 노드 수(지정된 경우)까지 MCP 내의 모든 노드를 드레이닝하고 차단합니다. 노드를 드레이닝하고 차단하면 노드의 모든 Pod 예약이 취소되고 노드가 예약 불가능으로 표시됩니다. 노드를 드레이닝한 후 Machine Config Daemon은 OS(운영 체제) 업데이트를 포함할 수 있는 새 머신 구성을 적용합니다. OS를 업데이트하려면 호스트가 재부팅해야 합니다.
특정 노드가 업데이트되지 않도록 하려면 드레이닝, 차단 및 업데이트되지 않도록 사용자 지정 MCP를 생성할 수 있습니다. 그런 다음 해당 MCP를 일시 중지하여 해당 MCP와 연결된 노드가 업데이트되지 않았는지 확인합니다. MCO는 일시 중지된 MCP를 업데이트하지 않습니다. 하나 이상의 사용자 지정 MCP를 생성하여 해당 노드를 업데이트하는 순서에 대해 더 많은 제어 권한을 부여할 수 있습니다. 첫 번째 MCP에서 노드를 업데이트한 후 애플리케이션 호환성을 확인한 다음 나머지 노드를 새 버전으로 점진적으로 업데이트할 수 있습니다.
컨트롤 플레인의 안정성을 보장하기 위해 컨트롤 플레인 노드에서 사용자 정의 MCP를 생성하는 것은 지원되지 않습니다. MCO(Machine Config Operator)는 컨트롤 플레인 노드에 대해 생성된 사용자 정의 MCP를 무시합니다.
워크로드 배포 토폴로지에 따라 생성하는 MCP 수와 각 MCP의 노드 수를 신중하게 고려해야 합니다. 예를 들어 특정 유지 관리 창에 업데이트를 조정해야 하는 경우 창 내에서 OpenShift Container Platform을 업데이트할 수 있는 노드 수를 알아야 합니다. 이 숫자는 고유한 클러스터 및 워크로드 특성에 따라 달라집니다.
또한 클러스터에서 사용할 수 있는 추가 용량을 고려해야 합니다. 예를 들어 업데이트된 노드에서 애플리케이션이 예상대로 작동하지 않는 경우 풀의 해당 노드를 차단하고 드레이닝하여 애플리케이션 pod를 다른 노드로 이동할 수 있습니다. 필요한 사용자 지정 MCP 수와 각 MCP에 있는 노드 수를 확인하기 위해 사용 가능한 추가 용량을 고려해야 합니다. 예를 들어 두 개의 사용자 지정 MCP를 사용하고 노드의 50%가 각 풀에 있는 경우 노드의 50%를 실행하면 애플리케이션에 충분한 QoS(Quality-of-service)를 제공하는지 확인해야 합니다.
이 업데이트 프로세스를 문서화된 모든 OpenShift Container Platform 업데이트 프로세스와 함께 사용할 수 있습니다. 그러나 이 프로세스는 Ansible 플레이북을 사용하여 업데이트되는 RHEL(Red Hat Enterprise Linux) 시스템에서는 작동하지 않습니다.
