Kubernetes 실습
kubeadm 기반 클러스터 구축과 장애 확인
멀티노드 Kubernetes 환경을 직접 구성하고 Network, Storage, RBAC, Scaling을 연결해 구성했습니다. 문제가 생기면 설정부터 바꾸기보다 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를 함께 확인했습니다.
설정을 바로 바꾸기보다 상태 확인 → 가설 → 확인 → 변경 → 재확인 순서로 접근했습니다.
