11.2. 카나리아 롤아웃 업데이트 프로세스 및 MCP 정보
OpenShift Container Platform에서 노드는 개별적으로 간주되지 않습니다. 대신 MCP(Machine config pool)로 그룹화됩니다. 기본적으로 OpenShift Container Platform 클러스터의 노드는 두 개의 MCP로 그룹화됩니다. 하나는 컨트롤 플레인 노드용이고 하나는 작업자 노드용입니다. OpenShift Container Platform 업데이트는 모든 MCP에 동시에 영향을 미칩니다.
업데이트 중에 최대 수가 지정된 경우 MCO(Machine Config Operator)는 MCP 내의 모든 노드를 지정된 maxUnavailable 노드 수까지 드레이닝하고 차단합니다. 기본적으로 maxUnavailable 은 1 로 설정됩니다. 노드를 드레이닝하고 차단하면 노드의 모든 Pod 예약이 취소되고 노드가 예약 불가능으로 표시됩니다.
노드를 드레이닝한 후 Machine Config Daemon은 OS(운영 체제) 업데이트를 포함할 수 있는 새 머신 구성을 적용합니다. OS를 업데이트하려면 호스트가 재부팅해야 합니다.
사용자 정의 머신 구성 풀 사용
특정 노드가 업데이트되지 않도록 사용자 지정 MCP를 생성할 수 있습니다. MCO는 일시 중지된 MCP 내에서 노드를 업데이트하지 않으므로 클러스터 업데이트를 시작하기 전에 업데이트하지 않으려는 노드가 포함된 MCP를 일시 중지할 수 있습니다.
하나 이상의 사용자 지정 MCP를 사용하면 작업자 노드를 업데이트하는 시퀀스를 더 많이 제어할 수 있습니다. 예를 들어 첫 번째 MCP에서 노드를 업데이트한 후 애플리케이션 호환성을 확인한 다음 나머지 노드를 새 버전으로 점진적으로 업데이트할 수 있습니다.
maxUnavailable 의 기본 설정은 OpenShift Container Platform의 모든 머신 구성 풀에 대해 1 입니다. 이 값을 변경하지 않고 한 번에 하나의 컨트롤 플레인 노드를 업데이트하는 것이 좋습니다. 컨트롤 플레인 풀의 경우 이 값을 3 으로 변경하지 마십시오.
컨트롤 플레인의 안정성을 보장하기 위해 컨트롤 플레인 노드에서 사용자 정의 MCP를 생성하는 것은 지원되지 않습니다. MCO(Machine Config Operator)는 컨트롤 플레인 노드에 대해 생성된 사용자 정의 MCP를 무시합니다.
사용자 정의 머신 구성 풀을 사용할 때 고려 사항
워크로드 배포 토폴로지에 따라 생성하는 MCP 수와 각 MCP의 노드 수를 신중하게 고려합니다. 예를 들어 특정 유지 관리 창에 업데이트를 조정해야 하는 경우 지정된 기간 내에 OpenShift Container Platform을 업데이트할 수 있는 노드 수를 알아야 합니다. 이 숫자는 고유한 클러스터 및 워크로드 특성에 따라 달라집니다.
또한 각 MCP 내의 사용자 지정 MCP 수와 노드 양을 결정하기 위해 클러스터에서 사용할 수 있는 추가 용량을 고려해야 합니다. 새로 업데이트된 노드에서 애플리케이션이 예상대로 작동하지 않는 경우 풀의 해당 노드를 차단하고 드레이닝하여 애플리케이션 Pod를 다른 노드로 이동할 수 있습니다. 그러나 나머지 MCP에서 사용 가능한 노드가 애플리케이션에 충분한 QoS(Quality of Service)를 제공할 수 있는지 확인해야 합니다.
이 업데이트 프로세스를 문서화된 모든 OpenShift Container Platform 업데이트 프로세스와 함께 사용할 수 있습니다. 그러나 이 프로세스는 Ansible 플레이북을 사용하여 업데이트되는 RHEL(Red Hat Enterprise Linux) 시스템에서는 작동하지 않습니다.
