Red Hat Blog를 보다가 관심 가는 글이 보여서 AI번역+약간 교정해 보았습니다.
출처: https://developers.redhat.com/articles/2025/10/10/splitting-openshift-machine-config-pool-without-node-reboots
이 문서 에서는 노드를 재부팅하지 않고도 기존 Red Hat OpenShift machine config pool (MCP)을 두 개의 별도 MCP로 분할하는 방법을 보여줍니다. 새 MCP가 기존 MCP와 정확히 동일한 머신 구성을 갖도록 하는 것이 목표입니다.
초기에는 많은 OpenShift 클러스터가 전체 클러스터에 대해 하나 또는 두 개의 MCP를 사용하여 구축되었습니다. 이는 작업자 노드가 10개 또는 20개뿐인 경우에는 유용합니다. 하지만 하나의 MCP에 작업자 노드가 100개 이상인 경우 업그레이드가 어려워질 수 있습니다. Red Hat OpenShift Container Platform 업그레이드 설명서 에서 설명한 대로 , 업그레이드가 끝날 때 MCP를 일시 중지하고 다시 시작함으로써 어떤 노드가 얼마나 재부팅될지 더 쉽게 제어할 수 있습니다.
분할 절차
이 섹션에서는 분할 절차를 시작하기 전에 필요한 전제 조건을 간략하게 설명합니다. 그런 다음 노드를 재부팅하지 않고 OpenShift 머신 구성 풀을 분할하는 단계별 절차를 안내합니다.
필수 조건:
- 클러스터 관리자 권한으로 OpenShift 클러스터에 액세스합니다.
- OpenShift 클러스터에 구성되고 연결된 oc CLI 도구입니다.
- 머신 구성 풀과 머신 구성에 대한 이해.
1단계: 현재 머신 구성 풀 식별
다음 명령을 사용하여 분할해야 할 현재 MCP를 식별합니다.
oc get mcp
출력 예:
NAME CONFIG UPDATED UPDATING DEGRADED MACHINECOUNT READYMACHINECOUNT UPDATEDMACHINECOUNT DEGRADEDMACHINECOUNT AGE master rendered-master-a5f35b903c8ad7c2c0175023f9909b05 True False False 3 3 3 0 13d mcp-1 rendered-mcp-1-f19092f2278430cc4d2cff6d9400f990 True False False 5 5 5 0 13d worker rendered-worker-f19092f2278430cc4d2f9909b05a5f3 True False False 0 0 0 0 13d
출력에서 두 가지 사항에 유의하세요. 첫째, 이 배포에는 OpenShift Container Platform 배포에서 표준이 아닌 MCP가 하나뿐이며, 바로 “mcp-1″입니다. 둘째, CONFIG 열에는 렌더링된 각 MCP 버전에 대한 특정 해시가 있습니다.
2단계: 머신 구성 식별
다음을 사용하여 현재 MCP와 연관된 머신 구성을 검색하여 머신 구성을 식별합니다.
oc get mcp mcp-1 -o json | jq .spec.configuration
출력 예:
{
"name": "rendered-mcp-1-f19092f2278430cc4d2cff6d9400f990",
"source": [
{
"apiVersion": "machineconfiguration.openshift.io/v1",
"kind": "MachineConfig",
"name": "00-worker"
},
{
"apiVersion": "machineconfiguration.openshift.io/v1",
"kind": "MachineConfig",
"name": "01-worker-container-runtime"
},
{
"apiVersion": "machineconfiguration.openshift.io/v1",
"kind": "MachineConfig",
"name": "01-worker-kubelet"
},
{
"apiVersion": "machineconfiguration.openshift.io/v1",
"kind": "MachineConfig",
"name": "50-workers-chrony-configuration"
},
{
"apiVersion": "machineconfiguration.openshift.io/v1",
"kind": "MachineConfig",
"name": "97-worker-generated-kubelet"
},
{
"apiVersion": "machineconfiguration.openshift.io/v1",
"kind": "MachineConfig",
"name": "98-worker-generated-kubelet"
},
{
"apiVersion": "machineconfiguration.openshift.io/v1",
"kind": "MachineConfig",
"name": "99-worker-generated-registries"
},
{
"apiVersion": "machineconfiguration.openshift.io/v1",
"kind": "MachineConfig",
"name": "99-worker-ssh"
}
]
}이렇게 하면 이 특정 MCP에 적용된 각 MachineConfig가 표시됩니다.
각 MachineConfig에 대한 세부 사항이 확실하지 않은 경우 다음 명령을 사용할 수 있습니다.
oc get mc
출력 예:
NAME GENERATEDBYCONTROLLER IGNITIONVERSION AGE 00-master 64460169e27091d8f8373b0952604ba2700d6d67 3.4.0 13d 00-worker 64460169e27091d8f8373b0952604ba2700d6d67 3.4.0 13d 01-master-container-runtime 64460169e27091d8f8373b0952604ba2700d6d67 3.4.0 13d 01-master-kubelet 64460169e27091d8f8373b0952604ba2700d6d67 3.4.0 13d 01-worker-container-runtime 64460169e27091d8f8373b0952604ba2700d6d67 3.4.0 13d 01-worker-kubelet 64460169e27091d8f8373b0952604ba2700d6d67 3.4.0 13d 50-masters-chrony-configuration 3.1.0 13d 50-workers-chrony-configuration 3.1.0 13d 97-master-generated-kubelet 64460169e27091d8f8373b0952604ba2700d6d67 3.4.0 13d 97-mcp-1-generated-kubelet 64460169e27091d8f8373b0952604ba2700d6d67 3.4.0 13d 97-worker-generated-kubelet 64460169e27091d8f8373b0952604ba2700d6d67 3.4.0 13d 98-master-generated-kubelet 64460169e27091d8f8373b0952604ba2700d6d67 3.4.0 13d 98-mcp-1-generated-kubelet 64460169e27091d8f8373b0952604ba2700d6d67 3.4.0 13d 98-worker-generated-kubelet 64460169e27091d8f8373b0952604ba2700d6d67 3.4.0 13d 99-assisted-installer-master-ssh 3.1.0 13d 99-master-generated-registries 64460169e27091d8f8373b0952604ba2700d6d67 3.4.0 13d 99-master-ssh 3.2.0 13d 99-mcp-1-generated-kubelet 64460169e27091d8f8373b0952604ba2700d6d67 3.4.0 4d5h 99-worker-generated-registries 64460169e27091d8f8373b0952604ba2700d6d67 3.4.0 13d 99-worker-ssh 3.2.0 13d rendered-master-a5f35b903c8ad7c2c0175023f9909b05 64460169e27091d8f8373b0952604ba2700d6d67 3.4.0 13d rendered-mcp-1-8f6a90f60f8d9db7d8c0e243c9bf4963 64460169e27091d8f8373b0952604ba2700d6d67 3.4.0 13d rendered-mcp-1-b9d21061d076437680290f5da831ada0 64460169e27091d8f8373b0952604ba2700d6d67 3.4.0 24h rendered-mcp-1-f19092f2278430cc4d2cff6d9400f990 64460169e27091d8f8373b0952604ba2700d6d67 3.4.0 13d rendered-mcp-1-f90b4a73043e3cec10a72075c4d9d9fb 64460169e27091d8f8373b0952604ba2700d6d67 3.4.0 4d5h rendered-worker-dcb907f73ccf964e6db1cf7db6cd45ab 64460169e27091d8f8373b0952604ba2700d6d67 3.4.0 13d rendered-worker-f19092f2278430cc4d2cff6d9400f990 64460169e27091d8f8373b0952604ba2700d6d67 3.4.0 13d
MachineConfig와 관련하여 추가 지원이 필요하면 OpenShift Container Platform 설명서 를 참조하세요 .
3단계: 새 머신 구성 풀 만들기
새 풀의 원하는 이름(예: mcp-new)을 사용하여 새 MCP 정의 YAML 파일 mcp-new.yaml을 만듭니다. 이 새 MCP의 machineConfigSelector는 다음 예시와 같이 원래 MCP와 정확히 동일해야 합니다.
apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfigPool
metadata:
name: mcp-new
spec:
machineConfigSelector:
matchExpressions:
- {
key: machineconfiguration.openshift.io/role,
operator: In,
values: [worker,mcp-1]
}
nodeSelector:
matchLabels:
node-role.kubernetes.io/mcp-new: "" # Label for nodes to move to this pool (nodes to be updated later)새로운 MCP를 다음과 같이 적용합니다.
oc apply -f mcp-new.yaml
4단계: 두 MCP 모두 동일한 렌더링 해시를 가지고 있는지 확인합니다.
노드가 한 MCP에서 다른 MCP로 이동할 때 재부팅되지 않도록 하려면 두 MCP의 해시가 동일해야 합니다. 즉, 두 MCP의 MachineConfig가 정확히 동일해야 합니다. 따라서 이러한 MCP 내의 Red Hat Enterprise Linux CoreOS 구성은 이동 시 호스트의 OS나 파일을 변경할 필요가 없습니다.
확인하려면 다음 명령을 실행하세요.
NAME CONFIG UPDATED UPDATING DEGRADED MACHINECOUNT READYMACHINECOUNT UPDATEDMACHINECOUNT DEGRADEDMACHINECOUNT AGE master rendered-master-a5f35b903c8ad7c2c0175023f9909b05 True False False 3 3 3 0 14d mcp-1 rendered-mcp-1-f19092f2278430cc4d2cff6d9400f990 True False False 5 5 5 0 14d mcp-new rendered-mcp-new-f19092f2278430cc4d2cff6d9400f990 True False False 0 0 0 0 42h worker rendered-worker-f19092f2278430cc4d2cff6d9400f990 True False False 0 0 0 0 14d
5단계: 노드에 레이블 지정
이 단계에서는 새 머신 구성 풀의 노드에 레이블을 지정합니다. 새 MCP로 이동할 노드를 식별하고 새 MCP의 nodeSelector에 정의된 노드 선택기 레이블을 사용하여 레이블을 지정합니다.
# oc get node NAME STATUS ROLES AGE VERSION ctrl-plane-0.nantahala.daytwops.bos2.lab Ready control-plane,master 14d v1.29.10+67d3387 ctrl-plane-1.nantahala.daytwops.bos2.lab Ready control-plane,master 14d v1.29.10+67d3387 ctrl-plane-2.nantahala.daytwops.bos2.lab Ready control-plane,master 14d v1.29.10+67d3387 worker-0.nantahala.daytwops.bos2.lab Ready mcp-1,worker 14d v1.29.10+67d3387 worker-1.nantahala.daytwops.bos2.lab Ready mcp-1,worker 14d v1.29.10+67d3387 worker-2.nantahala.daytwops.bos2.lab Ready mcp-1,worker 14d v1.29.10+67d3387 worker-3.nantahala.daytwops.bos2.lab Ready mcp-1,worker 14d v1.29.10+67d3387 worker-5.nantahala.daytwops.bos2.lab Ready mcp-1,worker 14d v1.29.10+67d3387
mcp-1에서 mcp-new로 노드를 이동하려면 다음 명령을 사용하여 원하는 노드에 패치를 적용하세요.
# oc patch node worker-5.nantahala.daytwops.bos2.lab --type=json -p '[{"op":"move","from": "/metadata/labels/node-role.kubernetes.io~1mcp-1", "path": "/metadata/labels/node-role.kubernetes.io~1mcp-new"}]'참고: patch 명령에서 ~1은 “/” 문자를 이스케이프하는 방식입니다. 이 예에서는 “/” 문자가 포함된 레이블을 참조할 수 있습니다.
다음 명령을 실행하여 변경 사항을 확인하세요.
# watch "oc get no; echo; oc get mcp; echo; oc get mc| grep -vE 'worker|master'"
출력 예:
NAME STATUS ROLES AGE VERSION ctrl-plane-0.nantahala.daytwops.bos2.lab Ready control-plane,master 14d v1.29.10+67d3387 ctrl-plane-1.nantahala.daytwops.bos2.lab Ready control-plane,master 14d v1.29.10+67d3387 ctrl-plane-2.nantahala.daytwops.bos2.lab Ready control-plane,master 14d v1.29.10+67d3387 worker-0.nantahala.daytwops.bos2.lab Ready mcp-1,worker 14d v1.29.10+67d3387 worker-1.nantahala.daytwops.bos2.lab Ready mcp-1,worker 14d v1.29.10+67d3387 worker-2.nantahala.daytwops.bos2.lab Ready mcp-1,worker 14d v1.29.10+67d3387 worker-3.nantahala.daytwops.bos2.lab Ready mcp-1,worker 14d v1.29.10+67d3387 worker-5.nantahala.daytwops.bos2.lab Ready mcp-new,worker 14d v1.29.10+67d3387 NAME CONFIG UPDATED UPDATING DEGRADED MACHINECOUNT READYMACHINECOUNT UPDATEDMACHINECOUNT DEGRADEDMACHINECOUNT AGE master rendered-master-a5f35b903c8ad7c2c0175023f9909b05 True False False 3 3 3 0 14d mcp-1 rendered-mcp-1-f19092f2278430cc4d2cff6d9400f990 True False False 4 4 4 0 14d mcp-new rendered-mcp-new-f19092f2278430cc4d2cff6d9400f990 True False False 1 1 1 0 42h worker rendered-worker-f19092f2278430cc4d2cff6d9400f990 True False False 0 0 0 0 14d NAME GENERATEDBYCONTROLLER IGNITIONVERSION AGE 97-mcp-1-generated-kubelet 64460169e27091d8f8373b0952604ba2700d6d67 3.4.0 14d 97-mcp-new-generated-kubelet 64460169e27091d8f8373b0952604ba2700d6d67 3.4.0 14d 98-mcp-1-generated-kubelet 64460169e27091d8f8373b0952604ba2700d6d67 3.4.0 14d 98-mcp-new-generated-kubelet 64460169e27091d8f8373b0952604ba2700d6d67 3.4.0 14d 99-mcp-1-generated-kubelet 64460169e27091d8f8373b0952604ba2700d6d67 3.4.0 5d rendered-mcp-1-8f6a90f60f8d9db7d8c0e243c9bf4963 64460169e27091d8f8373b0952604ba2700d6d67 3.4.0 14d rendered-mcp-1-b9d21061d076437680290f5da831ada0 64460169e27091d8f8373b0952604ba2700d6d67 3.4.0 43h rendered-mcp-1-f19092f2278430cc4d2cff6d9400f990 64460169e27091d8f8373b0952604ba2700d6d67 3.4.0 14d rendered-mcp-1-f90b4a73043e3cec10a72075c4d9d9fb 64460169e27091d8f8373b0952604ba2700d6d67 3.4.0 5d rendered-mcp-new-8f6a90f60f8d9db7d8c0e243c9bf4963 64460169e27091d8f8373b0952604ba2700d6d67 3.4.0 14d rendered-mcp-new-f19092f2278430cc4d2cff6d9400f990 64460169e27091d8f8373b0952604ba2700d6d67 3.4.0 14d ...
mcp-new가 updated = false , updating = true 로 변경되는 것을 볼 수 있습니다. 그런 다음 노드가 mcp-new로 이동하면 즉시 updated = true , updating = false 로 다시 변경됩니다 . MACHINECOUNT 도 변경되는 것을 볼 수 있습니다.
노드가 SchedulingDisabled 상태로 전환되는 것을 볼 수 없습니다. 이는 두 MCP 간의 구성이 잘못되었음을 나타내며, 해당 노드가 재부팅됩니다.
주의할 점
의도치 않은 구성 변경 및 잠재적인 중단을 방지하기 위해 새 MCP의 machineConfigSelector가 원본과 정확히 일치하는지 확인하십시오. 노드 레이블 패치는 새 MCP로의 이동을 트리거하는 작업입니다.
프로세스 진행 중과 이후에 노드 상태와 MCP 상태를 면밀히 모니터링하십시오. 재부팅이 예상되지 않더라도 유지 관리 기간 동안 이 작업을 계획하고 조정하십시오.
요약
이 절차는 기존 풀과 새 풀의 머신 구성이 동일하게 유지되는 한, 노드 재부팅 없이 머신 구성 풀을 분할할 수 있다는 점에서 상당한 이점을 제공합니다. 이를 통해 원활한 전환이 보장되고 서비스 중단을 방지하여 업그레이드 및 클러스터 관리의 효율성을 높일 수 있습니다.
