<aside>
CloudWave · W04 · 2/5 · 예상 읽기 7분
</aside>
새 버전을 배포할 때 잠깐의 중단을 허용할지, 두 버전을 겹쳐 실행할지부터 결정해야 했다.
Deployment는 애플리케이션의 원하는 버전과 복제본을 선언하고 ReplicaSet을 통해 롤아웃을 관리한다. Recreate는 기존 버전을 내린 뒤 새 버전을 시작하는 단순한 전략이고, RollingUpdate는 새 버전과 이전 버전을 일정 기간 함께 운용하며 교체한다. 전략의 선택은 호환성, 용량, 롤백 요구와 연결된다.
Kubernetes의 객체는 명령어 목록이라기보다 원하는 상태를 표현하는 문서에 가깝다. 컨트롤러는 그 문서와 현재 상태의 차이를 관찰하고 필요한 조정을 반복한다. 이 관점으로 보면 생성 명령 자체보다 선택자, 템플릿, 복제본, 실패 시 대체 행동을 읽는 일이 중요해진다. 이름이 비슷한 객체라도 책임 범위가 다르므로, 무엇이 상태를 보관하고 무엇이 연결을 제공하는지 나누어 읽었다.
Service는 Pod가 교체되어도 변하지 않는 접근점을 제공한다. 셀렉터가 라벨과 맞아야 하며, Service의 종류에 따라 클러스터 내부 접근과 외부 노출 방식이 달라진다. Ingress는 HTTP와 HTTPS 요청을 규칙에 따라 전달하는 API다. Ingress 자체가 라우터 구현체는 아니며, 실제 처리를 담당할 Ingress controller 같은 구현이 별도로 필요하다.
실무에서는 Deployment의 롤아웃 상태와 이전 ReplicaSet을 확인하고, Service가 의도한 Pod만 선택하는지 점검한다. 외부 공개가 필요할 때는 DNS, TLS, 구현체, 헬스 체크를 별도로 설계한다. 로컬 실습에서 요청이 통과한 경험을 프로덕션 가용성으로 확대하지 않는다.
작은 예제로 시작할 때도 리소스 이름은 example-app처럼 가상으로 두고, 실제 자격 증명이나 인프라 식별자는 문서에 넣지 않는다. 변경 전후의 상태를 비교하고, 실패했을 때 되돌릴 기준을 먼저 적어 두면 선언형 운영의 장점이 드러난다. 자동화는 사람의 판단을 없애는 것이 아니라 판단을 반복 가능한 절차로 바꾸는 일에 가깝다.
Recreate와 RollingUpdate를 무조건 좋고 나쁜 전략으로 나누면 안 된다. Service가 있으면 자동으로 외부에서 접근된다고 생각해서도 안 된다. Ingress는 안정화된 Kubernetes API이지만 구현체가 기본 포함된다고 단정할 수 없다.
또 하나의 오해는 Kubernetes가 모든 운영 결정을 대신한다는 생각이었다. Kubernetes는 객체와 컨트롤러의 공통 언어를 제공하지만, 데이터 보존, 권한, 비용, 백업, 장애 범위는 별도의 설계 대상이다. 그래서 실습 결과를 기록할 때도 성공 여부보다 어떤 조건에서 무엇이 관찰됐는지를 중심에 두려고 했다.
nn이 과정을 기록하며 확인한 기준은 세 가지였다. 먼저 객체의 이름과 라벨이 서로 의도한 대상을 가리키는지 확인한다. 다음으로 컨트롤러가 관찰하는 상태와 사용자가 보는 애플리케이션 상태를 나누어 본다. 마지막으로 변경을 적용하기 전에 실패했을 때 남는 자원과 되돌릴 방법을 생각한다. 이 기준은 로컬 클러스터에서 작은 예제를 읽을 때도, 관리형 클러스터의 배포 문서를 검토할 때도 같은 순서로 적용할 수 있다. 결국 중요한 것은 특정 명령을 외우는 일이 아니라, 선언한 내용이 어떤 객체를 통해 실행되고 어떤 신호로 정상 여부를 판단하는지 설명하는 능력이었다.nn## 오늘의 한 줄 정리
선언형 운영은 원하는 상태를 적는 데서 끝나지 않고, 그 상태를 계속 확인하고 안전하게 수렴시키는 설계다.