Kubernetes 실습
kubeadm 기반 클러스터 구축과 장애 확인
멀티노드 Kubernetes 환경에서 네트워크, 스토리지, RBAC, 스케일링을 구성했습니다. 문제가 생기면 설정부터 바꾸기보다 Event와 리소스 상태를 먼저 확인했습니다.
Control Plane / Worker 구성
Service · Ingress · NetworkPolicy
리소스 상태와 함께 원인 범위 확인
개인 실습으로 클러스터를 구성하고 리소스 상태와 이벤트를 점검했습니다.
구성 항목별 설정과 문제 진단 시 확인한 값을 정리했습니다.
kubeadm으로 Control Plane과 Worker Node를 구성하고, CNI와 DNS가 붙은 뒤 Pod가 실제로 통신하는지 확인했습니다.
Node 상태, System Pod 상태, CNI 적용 여부, CoreDNS 동작을 순서대로 확인했습니다.
설치가 끝난 상태가 아니라 Pod가 스케줄되고 서로 통신하는 것까지 확인했습니다.
요청이 Pod까지 도달하는 경로를 한 단계씩 나눠, 어느 구간에서 끊기는지 확인했습니다.
Selector와 Endpoint가 실제 Pod를 가리키는지 확인했습니다.
Host/Path Rule과 Service Port가 맞는지 확인했습니다.
Service 이름 기반 통신이 CoreDNS를 통해 해석되는지 확인했습니다.
PV/PVC, Local PV, NFS, StatefulSet을 구성하고 PVC가 Pending일 때 바인딩 조건을 확인했습니다.
요청 용량과 Access Mode가 맞는지 확인했습니다.
어떤 방식으로 PV를 제공하는지 확인했습니다.
Node와 Storage가 강하게 묶일 때 Scheduling 제약을 확인했습니다.
공유 Storage를 PVC에 연결해 상태 저장 워크로드를 구성했습니다.
PVC가 Pending이면 Storage 하나만 보지 않고 PVC·PV·StorageClass·Access Mode·Event를 함께 확인했습니다.
Identity, API 권한, Pod 간 통신 범위를 각각 나눠 구성했습니다.
Pod가 사용하는 Kubernetes Identity
Role / RoleBinding으로 API 권한 제한
Pod 간 통신 허용 범위 제한
ServiceAccount와 Role / RoleBinding을 대조해 어떤 API 동작에 권한이 부족한지 확인했습니다.
Secret과 ConfigMap을 사용해 민감 정보와 일반 설정을 분리했습니다.
Replica 수가 임의로 바뀌는 것이 아니라 어떤 Metric/Event를 보고 Controller가 결정하는지 확인했습니다.
CPU/Memory 기준 Scaling
외부 Event/Metric 기준 Scaling
리소스 상태와 지표 확인
Scaling 전후 Replica 변화와 Metrics를 함께 봤습니다.
Scaling을 설정값이 아니라 지표와 Controller의 결정 결과로 확인했습니다.
증상마다 명령어를 외우기보다 상태와 Event를 먼저 보고 확인할 범위를 좁혔습니다.
Pod Event를 보고 Image 이름, Registry 접근, Pull 조건 중 어디서 실패했는지 좁혔습니다.
Selector, Endpoint, Port, Rule을 순서대로 확인했습니다.
ServiceAccount와 Role/RoleBinding을 대조했습니다.
PVC·PV·StorageClass 상태와 Event를 함께 확인했습니다.
설정을 바로 바꾸기보다 상태 확인 → 가설 → 확인 → 변경 → 재확인 순서로 접근했습니다.
08 / CKA 준비 기록
CKA는 준비 중이며, 아직 취득하지 않았습니다.아래는 어디서 무엇을 어떻게 연습하는지에 대한 기록입니다.
| 항목 | 내용 |
|---|---|
| 약한 영역 | Troubleshooting · Cluster Architecture · Services & Networking |
| 연습 클러스터 | VirtualBox VM 3대에 kubeadm으로 구성한 클러스터 (Control Plane 1 · Worker 2 · Calico) |
| 문항 | 85문항을 이 클러스터에서 그대로 풀 수 있게 준비한 연습 환경 |
| 파괴형 문항 | VM 스냅샷을 먼저 찍고, 깨뜨린 뒤 복구하고, 못 고치면 스냅샷으로 되돌림 |
지난 풀이를 영역별로 되짚어, 같은 종류의 실수가 반복된 세 영역을 약한 영역으로 정했습니다.그 영역의 문항을 85문항 연습 환경에서 반복해 푼 경험이 있습니다.
노드를 NotReady로 만들거나 etcd·업그레이드를 다루는 문항은 되돌리기 어려워 건너뛰기 쉽습니다.스냅샷을 먼저 찍어 두고, 깨뜨린 뒤 복구하고, 끝나면 스냅샷으로 되돌리는 순서로 반복한 경험이 있습니다.
Ingress는 CLASS와 ADDRESS 칸, PVC는 VOLUME 칸, 이름을 지정하는 문항은 jsonpath로 이름을 다시 읽습니다.파일에 쓰기 전에는 화면에서 먼저 결과를 봅니다.
| 경로 | 실행 환경 | 다루는 것 |
|---|---|---|
| CKA 연습 · 노드 수준 실습 | kubeadm 3노드 VM | kubelet, etcd 복구, 클러스터 업그레이드처럼 실제 노드가 필요한 연습 |
| Incident Lab (진행 중) | kind (2026-10-02부터) | 배포 변경으로 생기는 워크로드 수준 장애를 매번 같은 상태에서 다시 시작해 재현 |
kind는 노드가 컨테이너라 kubelet·런타임을 깨뜨리는 연습이나 kubeadm 설치 연습에는 맞지 않습니다.그래서 노드가 필요한 연습은 VM에, 빠르게 다시 만들어야 하는 재현은 kind에 두었습니다.
기여 범위 — VM 클러스터와 문제 연습 환경은 AI Agent가 구성했고, 풀이와 복구 연습은 제가 직접 합니다. 문항 원문은 공개하지 않습니다.
검증 범위
연습 방식과 환경을 적은 기록입니다.자격 취득이나 실무 클러스터 운영 경험으로 확대하지 않습니다.