<aside>
CloudWave · W04 · Kubernetes · 주차 회고와 글 모음 · 예상 읽기 6분
</aside>
이번 주에는 세 가지 질문을 붙잡았다. 첫째, 컨테이너가 죽거나 교체되어도 내가 원하는 상태를 어떻게 유지할까? 둘째, 애플리케이션을 새 버전으로 바꾸면서도 트래픽을 안전하게 연결하려면 무엇을 선언해야 할까? 셋째, 설정과 데이터처럼 이미지에 넣고 싶지 않은 것을 워크로드와 어떻게 분리할까?
1일차에는 Pod를 실행 단위로 보고, ReplicaSet과 Probe가 원하는 상태와 실제 상태를 어떻게 맞추는지 정리했다. 2일차에는 Deployment의 배포 전략을 거쳐 Service와 Ingress를 통해 트래픽이 어디로 흐르는지 연결했다. 3일차에는 ConfigMap과 Secret으로 설정의 성격을 나누었다. 4일차에는 StatefulSet과 Helm을 통해 상태가 있는 워크로드와 반복 가능한 패키징을 살폈다. 5일차에는 가상 이미지에서 레지스트리, EKS까지 이어지는 배포 경계를 그렸다.
첫날의 핵심은 명령을 한 번 실행하는 것이 아니라 원하는 상태를 기록하는 방식이었다. Pod는 컨테이너를 담는 가장 작은 실행 단위지만, Pod 하나만 만들면 교체와 확장을 지속적으로 책임져 줄 객체가 부족하다. ReplicaSet은 복제본 수와 선택 조건을 기준으로 부족한 Pod를 보충한다. Probe는 시작 가능 여부, 트래픽을 받을 준비, 살아 있는지를 서로 다른 질문으로 나눈다.
둘째 날에는 이 상태 관리가 배포와 네트워크로 확장됐다. Deployment는 ReplicaSet을 관리하며 버전 전환 정책을 표현한다. Service는 Pod의 수명과 별개인 안정적인 접근점을 제공한다. Ingress는 HTTP 라우팅을 선언하는 API이며, 실제 동작에는 별도의 Ingress 구현체가 필요하다는 점을 구분해야 한다. 이 흐름을 통해 애플리케이션의 실행, 발견, 외부 노출을 한 덩어리로 오해하지 않게 됐다.
셋째 날에는 설정을 코드와 이미지에서 떼어냈다. ConfigMap은 일반 설정을, Secret은 민감하게 다뤄야 하는 값을 전달하는 객체다. 다만 Secret의 base64 표현은 암호화가 아니다. 공개 글에서는 실제 값 대신 demo 같은 가상 값만 다룬다. 넷째 날에는 데이터베이스나 분산 캐시처럼 식별성과 저장 위치가 중요한 경우 StatefulSet을 검토하고, Helm은 여러 YAML을 환경별 값으로 재사용하는 패키징 도구로 이해했다. 다섯째 날에는 이 모든 선언을 이미지 빌드와 레지스트리, EKS 배포로 연결했다. EKS 실습에서 확인한 흐름을 곧바로 프로덕션 운영의 보증으로 확대하지 않는 것이 중요하다.
다음 주에는 Kubernetes 객체를 특정 클러스터의 자원과 연결해 보며 컴퓨팅, 네트워크, 스토리지의 선택이 운영 방식에 어떤 차이를 만드는지 살펴볼 예정이다. 이번 주의 선언이 클라우드의 관리형 기능과 만날 때 무엇이 자동화되고 무엇이 여전히 설계자의 책임인지가 다음 질문이다.