Kubernetes 심화 — 내부 동작 자가학습 (실험 중심)

선행: 03-00-Linux-내부동작-자가학습 Module 5·6 (netns·veth·iptables·cgroup) — 여기서 바로 이어받음

상위: 00-총괄-로드맵-Cloud-Architect · 자격증: 자격증-커리큘럼-LFCS-CKA-SAA · 지도: 00-MOC-Kubernetes 선행: 03-00-Linux-내부동작-자가학습 Module 5·6 (netns·veth·iptables·cgroup) — 여기서 바로 이어받음

목표: “kubectl 사용법”이 아니라 컴포넌트가 왜 그렇게 도는지. 리눅스 원시 기능이 K8s에서 어떻게 조립되는지 직접 뜯기. 방식: 모듈마다 개념 → 실험 → 리눅스 연결. managed 클러스터 금지, kubeadm으로 직접 구성. 환경: Proxmox VM 23대(컨트롤플레인 1 + 워커 12). 스냅샷 찍고 마음껏 부수기. 실험마다 실습-로그-템플릿.

[!tip] 학습 원칙

  1. 추상화 걷어내기: 파드 → 컨테이너 → 네임스페이스/cgroup까지 매번 내려가 본다.
  2. 부수고 복구해라. etcd 깨기, 인증서 만료, 컴포넌트 죽이기 → 복구가 곧 CKA 트러블슈팅(30%).
  3. YAML 암기 금지. kubectl create ... --dry-run=client -o yaml로 생성해서 이해.

Module 1 — 아키텍처 & 컨트롤 루프

개념: 선언적 모델, reconciliation loop, desired vs actual state, 컨트롤러 패턴. API Server / etcd / Scheduler / Controller Manager / kubelet / kube-proxy의 역할 분담.

실험

  • 객체 하나 만들고 kubectl get -o yaml로 spec(원하는 상태) vs status(실제) 비교
  • Deployment의 파드를 강제 삭제 → 컨트롤러가 자동 복구하는 것 관찰 (reconciliation 체감)
  • kubectl get events -w로 컨트롤 루프가 만들어내는 이벤트 흐름 추적

[!note] 리눅스 연결 컨트롤러 = 무한 루프 데몬. systemd 서비스가 상태를 유지하듯, 컨트롤러는 클러스터 상태를 수렴시킨다.

Module 2 — etcd & API Server

개념: etcd(분산 KV, 단일 진실원천), API Server(유일한 etcd 접근 관문), 인증→인가(RBAC)→admission 파이프라인, watch 메커니즘.

실험

  • etcdctl로 etcd 직접 들여다보기 — K8s 객체가 어떤 키로 저장되는지 확인
  • etcd 스냅샷 백업 & 복원 (CKA 단골) → 일부러 객체 지우고 복원으로 되살리기
  • admission webhook 흐름 이해: 요청이 인증→RBAC→mutating/validating 거치는 순서
  • API Server 죽여보고(kubectl 먹통) 복구 — 클러스터의 단일 관문임을 체감

[!note] 리눅스 연결 컴포넌트는 결국 노드 위 프로세스/static pod. crictl ps로 컨테이너 레벨까지 내려가 확인.

Module 3 — 스케줄링 & 워크로드

개념: 스케줄러 필터링/스코어링, requests/limits, QoS class, nodeSelector/affinity, taint/toleration, Deployment·StatefulSet·DaemonSet·Job 차이.

실험

  • requests/limits 바꿔가며 파드의 QoS class(Guaranteed/Burstable/BestEffort) 변화 확인
  • taint 걸고 toleration 없는 파드가 스케줄 안 되는 것 → toleration 추가로 해결
  • affinity/anti-affinity로 파드 배치 강제
  • 노드 자원 부족 상황 만들어 Pending + 스케줄 실패 이벤트 관찰

[!note] 리눅스 연결 limit 초과 → OOMKilled = 03-00-Linux-내부동작-자가학습 Module 3의 cgroup memory.max 그대로.

Module 4 — 네트워킹 ★

개념: 파드 네트워크 모델(파드마다 IP), CNI, Service(ClusterIP/NodePort/LoadBalancer), kube-proxy(iptables/IPVS), DNS(CoreDNS), Ingress, Gateway API, NetworkPolicy.

실험

  • 파드 안에서 ip addr/ip route → netns·veth 구조가 리눅스 실험과 동일함 확인
  • Service 만들고 노드에서 iptables-save | grep <svc> → kube-proxy가 만든 규칙 직접 읽기
  • CoreDNS로 서비스 디스커버리 동작 확인 (nslookup <svc>.<ns>.svc)
  • NetworkPolicy로 파드 간 통신 차단 → 격리 검증
  • Ingress / Gateway API로 외부 노출 구성

[!note] 리눅스 연결 kube-proxy = 03-00-Linux-내부동작-자가학습 Module 5의 iptables NAT를 자동화한 것. 손으로 해봤으면 여기서 “아, 그거구나” 가 온다.

Module 5 — 스토리지

개념: Volume, PV/PVC 바인딩, StorageClass, 동적 프로비저닝, CSI, 접근모드, StatefulSet의 볼륨.

실험

  • hostPath / emptyDir로 볼륨 생명주기 차이 관찰
  • StorageClass + PVC로 동적 프로비저닝 동작
  • StatefulSet에 volumeClaimTemplate 붙여 파드별 영속 볼륨 확인
  • PV 수동 생성 → PVC 바인딩 → reclaim policy(Retain/Delete) 동작 테스트

[!note] 리눅스 연결 컨테이너 rootfs = overlayfs(03-00-Linux-내부동작-자가학습 Module 4). 볼륨은 그 위에 마운트되는 별도 스토리지.

Module 6 — 보안

개념: RBAC(Role/ClusterRole/Binding), ServiceAccount, SecurityContext, capabilities drop, Pod Security Standards, seccomp, Secret 관리.

실험

  • 제한된 RBAC를 가진 ServiceAccount 만들어 kubectl auth can-i로 권한 검증
  • SecurityContext로 non-root 강제 + capabilities 떨구기 → 위반 파드 거부 확인
  • Pod Security Standard(restricted) 적용한 네임스페이스에 위반 파드 배포 시도 → 차단 관찰
  • Secret 마운트 vs 환경변수 주입 차이

[!note] 리눅스 연결 03-00-Linux-내부동작-자가학습 Module 7(capabilities·seccomp) 그대로. CKS 직결.

Module 7 — 트러블슈팅 ★ (CKA 최대 비중 30%)

개념: 컴포넌트 로그 위치(static pod / journald / crictl logs), 노드 NotReady 원인, 파드 Pending/CrashLoopBackOff/ImagePullBackOff 분류, 네트워크/DNS 장애, 인증서 만료.

실험 (전부 일부러 고장 → 진단 → 복구)

  • kubelet 죽이기 → 노드 NotReady → 원인 추적 후 복구
  • 잘못된 이미지/명령으로 CrashLoopBackOff 만들고 kubectl describe/logs로 진단
  • CoreDNS 망가뜨려 DNS 장애 재현 → 복구
  • kubeadm 인증서 만료 상황 → kubeadm certs renew
  • etcd 손상 → Module 2의 스냅샷으로 복원

[!note] 핵심 트러블슈팅은 결국 “추상화를 내려가며 리눅스 레벨에서 원인 찾기”. 심화 Linux Module 8(관측·성능)이 여기서 다 쓰인다.

진행 순서 & 자격증 매핑

권장 순서: 1 → 2 → 3 → 4 → 5 → 6 → 7

  • 4(네트워킹) · 7(트러블슈팅)이 CKA 비중 최상위(20%+30%) → 가장 공들이기.
  • CKA 도메인 매핑: M1·M2 → Cluster Architecture(25%) / M3 → Workloads(15%) / M4 → Networking(20%) / M5 → Storage(10%) / M7 → Troubleshooting(30%) / M6 → CKS 선행.

실습 로그

다음 단계

  • CKA 합격 후 → GitOps(ArgoCD)·관측성(Prometheus)·Helm으로 확장 (시스템엔지니어-아키텍트-커리큘럼 Phase 2)
  • 보안 깊이 원하면 → CKS, Module 6 확장

모듈 완료 시 체크박스 갱신. 고장→복구 사례는 트러블슈팅 노트로 따로 남기면 CKA 직전 복습 자산이 된다.