인프런 워밍업 클럽 4기 DevOps - 2주차 발자국
전체적으로 느낀 점Kubernetes는 단순히 "컨테이너를 관리하는 도구"가 아니라, 전체 인프라의 상태를 코드로 정의하고 자동화하는 시스템이라는 걸 알게 되었다. 복잡하게 보였던 구성 요소들이 실제로는 잘 분리된 역할을 가지고 있다는 점이 인상 깊었고, 배울수록 실전에서 유용하겠다는 확신이 들었다. 배운 내용 요약 컨트롤 플레인과 클러스터 구조Control Plane은 클러스터의 두뇌로, 모든 오브젝트를 정의하고 감시하고 조율한다.etcd는 상태 저장소, Scheduler는 파드를 노드에 배치, Controller Manager는 상태를 지속적으로 유지.워커 노드는 kubelet, kube-proxy, containerd 등의 구성 요소로 작동하며, 컨테이너 실행은 Kubernetes가 직접 하는 게 아니라 런타임에게 요청한다는 구조가 흥미로웠다. 오브젝트 vs 컨트롤러오브젝트는 Pod, Service, PVC, ConfigMap처럼 기능 단위의 리소스컨트롤러는 이들을 자동화·유지·복구하는 역할 (Deployment, HPA 등)두 개념을 명확히 나눈 덕분에 Kubernetes의 확장성과 유연성이 보였다. ConfigMap과 SecretConfigMap: 설정값을 파드 외부에서 관리 → 환경별로 유연하게 구성 가능Secret: 민감정보 저장 (Base64 인코딩, 메모리 마운트)특히 Secret이 노드 메모리에 저장되고, 수정 시 kubelet이 주기적으로 반영하는 구조는 실제 운영환경에서 고려할 보안 요소가 많다는 걸 보여줌 Service서비스는 파드 IP가 변해도 고정된 접근점을 제공하는 추상화 계층ClusterIP, NodePort, LoadBalancer, ExternalName 타입마다 용도가 다르고,내부 DNS 기반의 이름 접근(서비스 디스커버리)은 마이크로서비스 아키텍처의 핵심 Probe (Liveness, Readiness, Startup)컨테이너가 살아있는지(Liveness), 준비됐는지(Readiness), 시작 중인지(Startup) 체크 가능Kubernetes가 단순 배포 도구가 아닌, 운영과 회복 기능까지 내장하고 있다는 걸 실감함설정에 따라 서비스 유입 제한, 자동 재시작 등 운영자가 손 쓸 필요 없는 자동화 처리가 가능 HPA (Horizontal Pod Autoscaler)설정된 기준(CPU 등)에 따라 파드 수를 자동으로 조절이상적인 스케일링과 현실적인 지연 시나리오를 비교하면서, HPA는 전능한 도구가 아니라 보조적인 수단임을 인지하게 됨
