OCP 학습 5일차 · 노드와 역할: Control Plane·Worker
학습 기준: OpenShift Container Platform(OCP) 4.20 · 학습 시간: 20~30분
4일차에서는 OCP가 Kubernetes를 기반으로 한다는 관계를 확인했습니다. 오늘은 클러스터를 이루는 컴퓨터인 노드(node)를 역할별로 구분합니다.
오늘의 학습 목표
- Control Plane과 Worker의 역할을 구분합니다.
- 노드 목록의 NAME·STATUS·ROLES를 읽습니다.
- 노드가 Ready라는 사실과 애플리케이션 정상 동작을 구분합니다.
1. 관리하는 역할과 실행하는 역할
클러스터를 여러 사람이 함께 일하는 작업장에 비유해 보겠습니다. 무엇을 어디에 배치할지 조정하는 일과 실제 작업을 수행하는 일이 모두 필요합니다.
Control Plane(컨트롤 플레인)은 클러스터를 관리하는 역할입니다. API server는 요청을 받는 창구, scheduler는 아직 노드가 정해지지 않은 Pod의 배치 대상을 고르는 구성 요소입니다. Controller manager는 지정한 상태를 유지하도록 조정하며, etcd는 클러스터 상태를 저장합니다. 지금은 이름을 모두 외우기보다 역할을 연결해 보세요.
Worker(워커)는 애플리케이션 워크로드를 실행하는 역할입니다. OCP 문서에서는 compute machine이라고도 부릅니다. kubelet은 해당 노드의 컨테이너 워크로드 실행·중지 요청을 처리하고, CRI-O는 컨테이너 실행을 담당합니다. Pod는 컨테이너를 담는 Kubernetes의 실행 단위이며 다음 차시에 자세히 배웁니다.
OCP의 역할 표기에서 control plane에 해당하는 master라는 이름도 만납니다. 이름이 다르다고 별도의 제3 역할로 오해하지 마세요. 역할 구분은 이해를 위한 것이며 노드 수나 배치 방식까지 하나로 고정하는 규칙은 아닙니다.
2. 실제로 확인한 공식 문서 내용
실습 환경: 브라우저와 OCP 4.20 공식 문서 · 아래 oc 조회 예시는 클러스터 접근이 확인되지 않아 미실행
이번 글에서는 공식 문서 본문을 직접 읽고 다음 내용을 대조했습니다.
- Control plane architecture: control plane이 클러스터를 관리하고 worker의 워크로드를 관리한다는 설명을 확인했습니다.
- Machine roles: master와 worker 역할, scheduler와 worker 구성 요소를 확인했습니다.
- Working with nodes: 노드 목록 조회 명령과 Ready·NotReady 예시를 확인했습니다.
이 확인은 제품 문서에 대한 검증입니다. 앞선 Podman VM을 OCP 클러스터로 간주하거나, 아래 명령을 실제 클러스터에서 실행한 결과로 제시하지 않습니다.
3. 미니 실습: 역할과 목록 연결하기
단계 1 — 역할 카드 만들기 (5분)
종이에 Control Plane과 Worker를 적고 아래 네 작업을 연결해 보세요.
- 새 Pod를 어느 노드에 배치할지 선택한다.
- 클러스터 상태를 저장한다.
- 애플리케이션 컨테이너를 실행한다.
- 사용자의 API 요청을 받는다.
답은 1 scheduler, 2 etcd, 4 API server는 Control Plane, 3은 Worker의 핵심 역할입니다. 다만 control plane 노드에서도 자체 관리용 컨테이너가 실행되므로 “컨테이너는 worker에서만 실행된다”라는 절대 규칙으로 외우지는 마세요.
단계 2 — 승인된 클러스터가 있다면 목록 조회 (5분)
이미 설치된 OpenShift CLI인 oc, 의도한 학습 클러스터의 기존 로그인, 노드 조회 권한이 있을 때만 실행합니다. 이 글을 따라 하기 위해 새 클러스터를 설치하거나 권한을 바꿀 필요는 없습니다.
목적은 현재 접속한 클러스터의 노드 목록을 읽는 것입니다.
oc get nodes
- oc: OpenShift 명령줄 도구
- get: 자원 조회
- nodes: 조회할 노드 자원
예시 출력(미실행) — 아래는 읽기 연습용 가상 이름과 값입니다. 실제 기본 출력의 AGE·VERSION 열은 생략해 세 열만 보여 줍니다. 클러스터 구성 권장안이 아닙니다.
NAME STATUS ROLES
cp-demo Ready master
work-a Ready worker
work-b NotReady worker
NAME은 노드 이름, ROLES는 역할, STATUS는 관측한 상태입니다. 이 예시에서는 cp-demo가 control plane 역할이고, work-b는 worker이면서 Ready 상태가 아닙니다. 실제 이름과 행 수, 역할 표시는 환경에 따라 다를 수 있습니다.
Ready만으로 모든 애플리케이션이 정상이라고 판단하지 않습니다. 노드 상태와 애플리케이션 상태는 따로 확인할 대상입니다. 또한 STATUS와 ROLES를 바꿔 읽지 마세요. worker는 건강 상태가 아닙니다.
단계 3 — 특정 노드 상세 읽기 (5분)
노드 하나의 상세 상태를 살펴보려면 다음 형식을 사용합니다. 꺾쇠괄호 부분은 앞서 확인한 실제 학습용 노드 이름으로 바꾸고, 괄호는 입력하지 않습니다.
oc describe node <노드이름>
describe는 상세 정보를 조회합니다. 공식 문서에 따르면 현재 상태의 원인을 확인할 때도 사용합니다. 이번 글에는 이 명령의 가짜 상세 로그를 싣지 않았습니다. 실행한 독자는 Conditions와 상태 설명을 읽고, 모르는 항목을 메모하는 데서 마무리하세요.
오늘은 조회 연습입니다. NotReady를 봤다고 노드를 재시작하거나 삭제하지 않습니다. 실제 업무 클러스터라면 운영 담당자의 절차를 따릅니다.
클러스터가 없다면 (5~10분)
위 가상 목록만 보고 다음 답을 직접 적으세요.
- control plane 역할의 노드: cp-demo
- worker 역할이면서 상태 확인이 필요한 노드: work-b
- 이 자료만으로 알 수 없는 것: NotReady의 원인과 애플리케이션 정상 여부
마지막으로 공식 문서의 Machine roles와 Working with nodes를 열어 자신의 해석을 대조합니다. 환경이 없어도 역할을 구분하고, 관측하지 않은 사실을 단정하지 않는 연습은 할 수 있습니다.
4. 성공 판단과 흔한 실패
조회에 성공했다면 명령이 오류 없이 목록을 반환했는지 확인하고, 각 행의 역할과 상태를 구분해 설명해 보세요. 목록이 나왔다는 사실을 클러스터 전체 정상 판정으로 확대하지 않습니다.
- command not found: oc 설치 여부를 확인합니다. Podman 명령으로 대신하지 않습니다.
- 로그인 필요 또는 Unauthorized: 기존 로그인 상태를 확인하고, 승인된 접속 절차를 따릅니다.
- Forbidden: 노드 조회 권한이 없을 수 있습니다. 권한을 임의로 넓히지 말고 관리자에게 필요한 조회 범위를 확인합니다.
- 연결 시간 초과·이름 해석 오류: 접속 대상과 네트워크·DNS를 확인합니다. 인증서 검증을 끄는 방식으로 진행하지 않습니다.
5. 확인 문제와 해설
문제 1. 새 Pod의 배치 노드를 고르는 scheduler는 어느 쪽 역할일까요?
Control Plane입니다. 실제 워크로드를 실행하는 worker와 역할을 나눠 생각합니다.
문제 2. ROLES가 worker이면 노드가 정상인가요?
그 정보만으로는 모릅니다. 역할과 상태는 서로 다른 열입니다.
문제 3. 개인 VM에서 podman images가 성공하면 OCP 노드도 Ready인가요?
아닙니다. 로컬 이미지 목록 조회는 OCP 노드 상태의 증거가 아닙니다.
오늘의 세 줄 정리
- Control Plane은 클러스터를 관리하고 Worker는 워크로드를 실행합니다.
- 노드 조회에서는 이름·역할·상태를 구분해 읽습니다.
- 문서 설명, 예시 출력, 내 환경의 실제 관측을 구분합니다.
다음 6일차에서는 Pod는 무엇인가?를 알아봅니다.