오늘은 Red Hat OpenShift Container Platform 4 (RHOCP 4) 클러스터에서 노드를 효과적으로 관리하는 방법에 대해 자세히 알아보겠습니다. OpenShift는 복잡한 컨테이너 환경을 효율적으로 운영할 수 있게 돕는 강력한 플랫폼이지만, 그만큼 노드 관리 기술도 중요합니다. 이 가이드는 RHOCP 4 클러스터의 핵심 노드 관리 명령어들을 엔지니어 여러분이 쉽게 따라 할 수 있도록 단계별로 설명해 드립니다. 클러스터의 안정성과 성능을 최적화하는 데 필요한 필수 명령어들을 지금 바로 확인해 보세요!
목차
- RHOCP 4 노드 역할(Role) 관리
- Master 노드 Worker Role 삭제 및 추가
- 노드 격리 및 Drain 작업
- 노드 상태 확인 및 문제 해결
- 노드 라벨 및 테인트 관리
- 노드 재부팅 및 유지보수
1. RHOCP 4 노드 역할(Role) 관리
Red Hat OpenShift Container Platform 4 (RHOCP 4)는 쿠버네티스를 기반으로 구축된 강력한 컨테이너 플랫폼입니다. OpenShift 클러스터의 각 노드는 특정 역할을 수행하며, 이러한 역할은 클러스터의 안정성과 워크로드 분산에 매우 중요합니다. 클러스터를 처음 구성하면, 마스터 노드에는 기본적으로 master와 worker 롤이 동시에 부여됩니다. 이는 마스터 노드가 클러스터 제어 평면의 핵심 역할을 수행하면서도, 동시에 컨테이너화된 애플리케이션(워크로드)을 스케줄링하고 실행할 수 있음을 의미합니다.
초기 배포 후, 현재 클러스터 내 노드들의 역할을 확인하려면 다음 oc get node 명령어를 사용합니다.
[root@bastion config]#oc get node
NAME STATUS ROLES AGE VERSION
master1.ocp-dc.hk.com Ready master,worker 20m v1.21.1+a620f50
master2.ocp-dc.hk.com Ready master,worker 76m v1.21.1+a620f50
master3.ocp-dc.hk.com Ready master,worker 91m v1.21.1+a620f50
worker1.ocp-dc.hk.com Ready worker 54m v1.21.1+a620f50위 출력에서 master1.ocp-dc.hk.com, master2.ocp-dc.hk.com, master3.ocp-dc.hk.com 노드가 모두 master,worker 롤을 가지고 있음을 확인할 수 있습니다. 반면 worker1.ocp-dc.hk.com은 worker 롤만 가지고 있습니다. 이처럼 OpenShift 노드 역할은 클러스터의 상태를 파악하는 데 중요한 정보입니다.
2. Master 노드 Worker Role 삭제 및 추가
프로덕션 환경에서는 클러스터의 안정성을 최우선으로 고려합니다. 이러한 이유로, 마스터 노드들이 오직 클러스터 제어 평면(Control Plane)의 역할만 수행하도록 하고 워크로드를 실행하지 않도록 설정하는 것이 일반적입니다. 이를 위해 마스터 노드에서 worker 롤을 제거하는 작업을 진행합니다.
마스터 노드에서 워커 롤을 삭제하려면 다음 oc patch 명령어를 사용합니다. 이 명령어는 스케줄러 설정을 변경하여 마스터 노드에 더 이상 워크로드를 스케줄링하지 않도록 지시합니다.
[root@bastion ~]#oc patch schedulers.config.openshift.io/cluster --type merge -p '{"spec":{"mastersSchedulable":false}}'
scheduler.config.openshift.io/cluster patched명령어 실행 후, 변경 사항이 올바르게 적용되었는지 oc get node 명령어를 다시 실행하여 확인합니다.
[root@bastion config]#oc get node
NAME STATUS ROLES AGE VERSION
master1.ocp-dc.hk.com Ready master 21m v1.21.1+a620f50
master2.ocp-dc.hk.com Ready master 77m v1.21.1+a620f50
master3.ocp-dc.hk.com Ready master 92m v1.21.1+a620f50
worker1.ocp-dc.hk.com Ready worker 55m v1.21.1+a620f50이제 마스터 노드들의 ROLES 컬럼에서 worker 롤이 사라지고, 오직 master 롤만 남아 있는 것을 볼 수 있습니다. 이는 OpenShift 마스터 노드가 전용 제어 평면 역할을 수행하도록 설정된 것입니다.
만약 특정 상황(예: 소규모 클러스터, 개발/테스트 환경에서 리소스 효율성 극대화)에서 마스터 노드에 다시 워커 롤을 추가하여 워크로드를 스케줄링하도록 설정해야 한다면, 다음 명령어를 통해 롤을 다시 부여할 수 있습니다.
[root@bastion ~]#oc patch schedulers.config.openshift.io/cluster --type merge -p '{"spec":{"mastersSchedulable":true}}'
scheduler.config.openshift.io/cluster patched이 명령어는 스케줄러 설정을 되돌려 마스터 노드에 워크로드를 다시 스케줄링할 수 있도록 합니다. 변경 사항을 확인합니다.
[root@bastion config]#oc get node
NAME STATUS ROLES AGE VERSION
master1.ocp-dc.hk.com Ready master,worker 22m v1.21.1+a620f50
master2.ocp-dc.hk.com Ready master,worker 78m v1.21.1+a620f50
master3.ocp-dc.hk.com Ready master,worker 93m v1.21.1+a620f50
worker1.ocp-dc.hk.com Ready worker 56m v1.21.1+a620f50다시 마스터 노드들이 master,worker 롤을 가지게 되었음을 확인할 수 있습니다. OpenShift 노드 역할 관리는 클러스터 운영 전략에 따라 유연하게 적용될 수 있습니다.
3. 노드 격리 및 Drain 작업
클러스터 내 특정 노드에서 유지보수 작업을 수행해야 할 때, 해당 노드에 새로운 워크로드가 스케줄링되는 것을 방지하고, 기존에 실행 중인 워크로드를 안전하게 다른 노드로 옮기는 과정이 필요합니다. 이 과정을 노드 격리(Cordon) 및 Drain(워크로드 비우기)이라고 합니다. 이는 OpenShift 유지보수의 핵심 단계입니다.
노드 격리 (Cordon)
노드를 격리(cordon)하면, 스케줄러가 해당 노드에 새로운 파드(Pod)를 스케줄링하지 않습니다. 하지만 이미 실행 중인 파드는 그대로 유지됩니다. 이는 특정 노드에 대한 사전 준비 단계로 사용됩니다.
[root@bastion ~]# oc adm cordon worker1.ocp-dc.hk.com
node/worker1.ocp-dc.hk.com cordoned노드 상태를 확인하여 SchedulingDisabled 상태로 변경되었는지 확인합니다.
[root@bastion ~]# oc get node worker1.ocp-dc.hk.com
NAME STATUS ROLES AGE VERSION
worker1.ocp-dc.hk.com Ready,SchedulingDisabled worker 58m v1.21.1+a620f50노드 Drain (워크로드 비우기)
노드를 Drain(비우기)하면, 해당 노드에 실행 중인 모든 파드가 Graceful Shutdown 과정을 거쳐 다른 노드로 이동됩니다. 이 과정에서 파드 Disruption Budget(PDB)이 준수되어 서비스 가용성을 유지합니다. Drain 작업은 유지보수를 위한 필수적인 단계입니다.
[root@bastion ~]# oc adm drain worker1.ocp-dc.hk.com --ignore-daemonsets --delete-local-data
node/worker1.ocp-dc.hk.com drained--ignore-daemonsets: DaemonSet에 의해 배포된 파드는 모든 노드에 배포되어야 하므로, 이 옵션을 사용하여 DaemonSet 파드를 무시합니다.--delete-local-data: 로컬 스토리지를 사용하는 파드(EmptyDir, HostPath 등)도 강제로 제거합니다. 데이터 손실에 유의해야 합니다.
Drain 작업이 완료되면, 해당 노드에서 실행 중이던 애플리케이션 파드들은 다른 가용 노드로 스케줄링되어 실행됩니다. OpenShift 노드 Drain은 서비스 중단을 최소화하기 위한 중요 작업입니다.
노드 복구 (Uncordon)
유지보수 작업이 완료되면, 노드를 다시 정상 상태로 되돌려 새로운 파드를 스케줄링할 수 있도록 해야 합니다. 다음 oc adm uncordon 명령어를 사용합니다.
[root@bastion ~]# oc adm uncordon worker1.ocp-dc.hk.com
node/worker1.ocp-dc.hk.com uncordoned노드 상태를 확인하여 SchedulingDisabled 상태가 해제되었는지 확인합니다.
[root@bastion ~]# oc get node worker1.ocp-dc.hk.com
NAME STATUS ROLES AGE VERSION
worker1.ocp-dc.hk.com Ready worker 1h v1.21.1+a620f50이제 worker1.ocp-dc.hk.com 노드는 다시 정상적으로 워크로드를 스케줄링할 수 있는 상태가 됩니다.
4. 노드 상태 확인 및 문제 해결
OpenShift 클러스터의 노드들은 항상 건강한 상태를 유지해야 합니다. 노드에 문제가 발생하면 워크로드의 가용성에 직접적인 영향을 미칠 수 있습니다. 따라서 정기적으로 OpenShift 노드 상태 확인을 수행하고, 문제가 발생했을 때 신속하게 해결하는 것이 중요합니다.
전체 노드 상태 확인
클러스터 내 모든 노드의 간략한 상태를 확인하려면 oc get node 명령어를 사용합니다. STATUS 컬럼이 Ready인지 확인하는 것이 중요합니다.
[root@bastion ~]# oc get node
NAME STATUS ROLES AGE VERSION
master1.ocp-dc.hk.com Ready master,worker 1d v1.21.1+a620f50
master2.ocp-dc.hk.com Ready master,worker 1d v1.21.1+a620f50
master3.ocp-dc.hk.com Ready master,worker 1d v1.21.1+a620f50
worker1.ocp-dc.hk.com Ready worker 1d v1.21.1+a620f50
worker2.ocp-dc.hk.com NotReady worker 5m v1.21.1+a620f50위 예시에서 worker2.ocp-dc.hk.com 노드의 STATUS가 NotReady인 것을 볼 수 있습니다. 이는 해당 노드에 문제가 발생했음을 의미합니다.
특정 노드 상세 정보 확인
문제가 있는 노드의 자세한 정보를 확인하려면 oc describe node <node-name> 명령어를 사용합니다. 이 명령어는 노드의 이벤트, 상태 조건, 할당된 리소스, 파드 목록 등 매우 상세한 정보를 제공하여 문제의 원인을 파악하는 데 도움을 줍니다.
[root@bastion ~]# oc describe node worker2.ocp-dc.hk.com
Name: worker2.ocp-dc.hk.com
Roles: worker
Labels: beta.kubernetes.io/arch=amd64
beta.kubernetes.io/os=linux
kubernetes.io/arch=amd64
kubernetes.io/hostname=worker2.ocp-dc.hk.com
kubernetes.io/os=linux
node-role.kubernetes.io/worker=
Annotations: kube-proxy.kubernetes.io/local-proxy-mode: iptables
volumes.kubernetes.io/controller-managed-attach-detach: true
CreationTimestamp: Mon, 27 May 2025 09:00:00 +0900
Taints: node.kubernetes.io/not-ready:NoExecute
node.kubernetes.io/not-ready:NoSchedule
node.kubernetes.io/unreachable:NoExecute
node.kubernetes.io/unreachable:NoSchedule
... (생략) ...
Conditions:
Type Status LastHeartbeatTime LastTransitionTime Reason Message
---- ------ ----------------- ------------------ ------ -------
MemoryPressure False Mon, 27 May 2025 10:00:00 +0900 Mon, 27 May 2025 09:05:00 +0900 KubeletHasSufficientMemory kubelet has sufficient memory available
DiskPressure False Mon, 27 May 2025 10:00:00 +0900 Mon, 27 May 2025 09:05:00 +0900 KubeletHasNoDiskPressure kubelet has no disk pressure
PIDPressure False Mon, 27 May 2025 10:00:00 +0900 Mon, 27 May 2025 09:05:00 +0900 KubeletHasSufficientPID kubelet has sufficient PID available
Ready False Mon, 27 May 2025 10:00:00 +0900 Mon, 27 May 2025 09:05:00 +0900 KubeletNotReady kubelet is not ready, container runtime is down or unhealthy.
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Warning KubeletNotReady 5m kubelet, worker2.ocp-dc.hk.com Kubelet is not ready.
Warning ContainerRuntimeDown 4m kubelet, worker2.ocp-dc.hk.com container runtime network not ready: NetworkReady=false reason:NetworkPluginNotReady message:Network plugin returns no or empty node IPs위 oc describe node 출력에서 Conditions 섹션의 Ready: False와 Message를 통해 kubelet is not ready, container runtime is down or unhealthy.라는 메시지를 확인할 수 있습니다. 또한 Events 섹션에서 ContainerRuntimeDown 등의 경고 메시지를 통해 컨테이너 런타임 또는 네트워크 문제로 인해 노드가 NotReady 상태가 되었음을 짐작할 수 있습니다. 이러한 정보는 OpenShift 노드 문제 해결의 중요한 단서가 됩니다.
Kubelet 로그 확인
노드 문제의 가장 흔한 원인은 Kubelet(노드 에이전트)의 문제입니다. Kubelet 로그를 확인하여 더 자세한 오류 메시지를 파악할 수 있습니다. journalctl 명령어를 사용합니다.
[root@worker2.ocp-dc.hk.com ~]# journalctl -u kubelet -f이 명령어는 Kubelet 서비스의 실시간 로그를 보여주어, 문제 발생 시 즉각적인 디버깅에 매우 유용합니다.
시스템 리소스 확인
때로는 디스크 부족, 메모리 부족, CPU 과부하 등으로 인해 노드에 문제가 발생할 수 있습니다. 다음과 같은 명령어를 사용하여 리소스 사용량을 확인합니다.
df -h: 디스크 사용량free -h: 메모리 사용량top또는htop: CPU 및 프로세스 사용량
이러한 도구들을 통해 OpenShift 노드 문제 해결의 근본적인 원인을 파악하고 적절한 조치를 취할 수 있습니다.
5. 노드 라벨 및 테인트 관리
OpenShift (Kubernetes)에서 노드 라벨(Label)과 테인트(Taint)는 파드(Pod)의 스케줄링을 제어하는 핵심 메커니즘입니다. 이를 통해 특정 워크로드가 특정 노드에만 배포되거나, 특정 노드에는 배포되지 않도록 설정할 수 있습니다. 이는 OpenShift 스케줄링의 중요한 부분입니다.
노드 라벨 추가
라벨은 노드에 키-값 쌍의 메타데이터를 추가하는 것으로, 파드의 Node Selector를 사용하여 특정 라벨이 있는 노드에만 파드를 스케줄링할 수 있습니다. 예를 들어, GPU가 장착된 노드에 hardware=gpu 라벨을 추가할 수 있습니다.
[root@bastion ~]# oc label node worker1.ocp-dc.hk.com hardware=gpu
node/worker1.ocp-dc.hk.com labeled라벨이 성공적으로 추가되었는지 확인합니다.
[root@bastion ~]# oc get node worker1.ocp-dc.hk.com --show-labels
NAME STATUS ROLES AGE VERSION LABELS
worker1.ocp-dc.hk.com Ready worker 1h v1.21.1+a620f50 beta.kubernetes.io/arch=amd64,beta.kubernetes.io/os=linux,hardware=gpu,kubernetes.io/arch=amd64,kubernetes.io/hostname=worker1.ocp-dc.hk.com,kubernetes.io/os=linux,node-role.kubernetes.io/worker=이제 파드 정의에 nodeSelector: hardware: gpu를 추가하면, 해당 파드는 worker1.ocp-dc.hk.com 노드에만 스케줄링될 수 있습니다.
노드 라벨 제거
추가했던 라벨을 제거하려면 키 뒤에 하이픈(-)을 붙입니다.
[root@bastion ~]# oc label node worker1.ocp-dc.hk.com hardware-
node/worker1.ocp-dc.hk.com unlabeled노드 테인트 추가
테인트는 노드에 '오염'을 부여하는 것으로, 파드는 해당 노드에 스케줄링될 수 없습니다. 하지만 파드에 해당 테인트에 대한 '톨러레이션(Toleration)'이 정의되어 있으면 스케줄링이 가능합니다. 이는 특정 종류의 파드만 특정 노드에 실행되도록 할 때 유용합니다.
예를 들어, 특정 노드를 테스트 전용으로 사용하고 싶다면 testing-only:NoSchedule 테인트를 추가할 수 있습니다.
[root@bastion ~]# oc taint node worker2.ocp-dc.hk.com dedicated=testing-only:NoSchedule
node/worker2.ocp-dc.hk.com tainteddedicated=testing-only: 테인트의 키-값 쌍입니다.NoSchedule: 테인트 효과(Taint Effect)입니다.NoSchedule은 해당 노드에 새로운 파드를 스케줄링하지 못하게 합니다. 다른 효과로는NoExecute(이미 실행 중인 파드도 제거) 및PreferNoSchedule이 있습니다.
노드 상세 정보에서 테인트를 확인할 수 있습니다.
[root@bastion ~]# oc describe node worker2.ocp-dc.hk.com | grep Taints
Taints: dedicated=testing-only:NoSchedule노드 테인트 제거
테인트를 제거하려면 키 뒤에 하이픈(-)과 효과(Effect)를 붙입니다.
[root@bastion ~]# oc taint node worker2.ocp-dc.hk.com dedicated:NoSchedule-
node/worker2.ocp-dc.hk.com untaintedOpenShift 노드 라벨과 OpenShift 테인트는 클러스터 리소스 관리에 매우 중요한 유연성을 제공합니다.
6. 노드 재부팅 및 유지보수
운영 중인 OpenShift 노드에 커널 업데이트, 하드웨어 교체 등 재부팅이 필요한 유지보수 작업을 수행해야 할 때가 있습니다. 이 경우, 클러스터의 서비스 가용성을 최대한 보장하면서 안전하게 노드를 재부팅하는 절차가 필요합니다. OpenShift 노드 재부팅은 단순히 서버를 끄고 켜는 것 이상으로 고려해야 할 사항이 있습니다.
안전한 노드 재부팅 절차
노드를 재부팅하기 전에는 반드시 해당 노드의 워크로드를 비우고(Drain), 새로운 워크로드가 스케줄링되지 않도록 격리(Cordon)해야 합니다. 이 과정은 3. 노드 격리 및 Drain 작업 섹션에서 설명한 내용과 동일합니다.
- 노드 격리 (Cordon): 새로운 파드가 해당 노드에 스케줄링되지 않도록 합니다.
[root@bastion ~]# oc adm cordon worker1.ocp-dc.hk.com - 노드 Drain (워크로드 비우기): 해당 노드에서 실행 중인 모든 파드를 안전하게 다른 노드로 이동시킵니다.
[root@bastion ~]# oc adm drain worker1.ocp-dc.hk.com --ignore-daemonsets --delete-local-data - 노드 재부팅: 이제 해당 노드에서 필요한 유지보수 작업을 수행하고 재부팅합니다.
[root@worker1.ocp-dc.hk.com ~]# sudo reboot - 노드 상태 확인: 재부팅 후 노드가 클러스터에 다시 조인되고
Ready상태가 되는지 확인합니다. 이 과정은 시스템 및 클러스터 설정에 따라 몇 분 정도 소요될 수 있습니다.[root@bastion ~]# oc get node worker1.ocp-dc.hk.com NAME STATUS ROLES AGE VERSION worker1.ocp-dc.hk.com Ready worker 1h v1.21.1+a620f50 - 노드 복구 (Uncordon): 노드가
Ready상태가 되면, 새로운 워크로드를 스케줄링할 수 있도록 격리 상태를 해제합니다.[root@bastion ~]# oc adm uncordon worker1.ocp-dc.hk.com
이 절차를 따르면 서비스 중단을 최소화하면서 OpenShift 노드 유지보수를 안전하게 수행할 수 있습니다. 특히 RHOCP 4 클러스터와 같이 고가용성이 요구되는 환경에서는 이러한 사전 작업이 필수적입니다.
이 가이드가 RHOCP 4 노드 관리에 대한 여러분의 이해를 돕고, 실제 운영 환경에서 직면하는 문제들을 해결하는 데 유용한 자료가 되기를 바랍니다. OpenShift는 지속적으로 발전하는 플랫폼이므로, Red Hat 공식 문서를 참고하여 최신 정보를 습득하는 것이 중요합니다. 효율적인 노드 관리를 통해 안정적이고 강력한 컨테이너 플랫폼을 구축하시길 응원합니다.
'컨테이너 플랫폼' 카테고리의 다른 글
| harbor 구성, 사용법 (0) | 2025.06.04 |
|---|---|
| RHEL 8 Harbor 컨테이너 레지스트리 설치하기 (1) | 2025.06.03 |
| Kubernetes Dashboard 설치 및 구성 가이드 (0) | 2025.05.15 |
| [RHOCP4] RHOCP4 (OpenShift) 설치 방법 (4.8.14) (2) | 2025.05.12 |
| Podman 설치 및 사용법 (2) | 2025.05.07 |