<aside>
CloudWave · W04 · 5/5 · 예상 읽기 7분
</aside>
로컬에서 만든 이미지가 실제 클러스터의 Pod가 되기까지 어떤 경계를 통과하는지 정리하고 싶었다.
첫 단계는 애플리케이션을 안전한 예시 이름으로 빌드하고 태그를 붙이는 일이다. 이미지 태그는 배포할 버전을 식별하는 단서이므로 재현 가능한 빌드와 변경 이력을 함께 관리해야 한다. 레지스트리는 이미지를 저장하고 클러스터가 가져오는 경계가 된다.
Kubernetes의 객체는 명령어 목록이라기보다 원하는 상태를 표현하는 문서에 가깝다. 컨트롤러는 그 문서와 현재 상태의 차이를 관찰하고 필요한 조정을 반복한다. 이 관점으로 보면 생성 명령 자체보다 선택자, 템플릿, 복제본, 실패 시 대체 행동을 읽는 일이 중요해진다. 이름이 비슷한 객체라도 책임 범위가 다르므로, 무엇이 상태를 보관하고 무엇이 연결을 제공하는지 나누어 읽었다.
EKS는 AWS가 Kubernetes 클러스터의 제어 영역 운영을 관리형으로 제공하는 서비스다. 그러나 애플리케이션의 이미지, Deployment, Service, 설정, 권한, 관측과 비용까지 자동으로 책임져 주는 것은 아니다. 실습에서 확인한 이미지 배포 흐름과 프로덕션 운영 기준을 분리해서 기록해야 한다.
Git 기반 자동화에서는 변경된 선언을 검토하고, 빌드와 테스트가 통과한 이미지가 레지스트리에 올라간 뒤 클러스터에 반영되는 순서를 명확히 한다. GitOps 도구를 사용하더라도 실제 적용 권한과 승인, 롤백 기준은 별도로 정해야 한다. 태그만 바뀌었다고 무중단이 보장되는 것도 아니다.
작은 예제로 시작할 때도 리소스 이름은 example-app처럼 가상으로 두고, 실제 자격 증명이나 인프라 식별자는 문서에 넣지 않는다. 변경 전후의 상태를 비교하고, 실패했을 때 되돌릴 기준을 먼저 적어 두면 선언형 운영의 장점이 드러난다. 자동화는 사람의 판단을 없애는 것이 아니라 판단을 반복 가능한 절차로 바꾸는 일에 가깝다.
EKS라는 이름만으로 네트워크와 보안이 완성된다고 생각하면 안 된다. 특정 계정, 주소, ARN, 엔드포인트를 문서에 남기지 않고, example.com과 demo 이미지처럼 가상 값으로 흐름만 보여 주는 것이 공개 글의 기본선이다. 운영 환경에서는 리소스 정책과 비밀 관리, 관측 가능성을 추가로 검증해야 한다.
또 하나의 오해는 Kubernetes가 모든 운영 결정을 대신한다는 생각이었다. Kubernetes는 객체와 컨트롤러의 공통 언어를 제공하지만, 데이터 보존, 권한, 비용, 백업, 장애 범위는 별도의 설계 대상이다. 그래서 실습 결과를 기록할 때도 성공 여부보다 어떤 조건에서 무엇이 관찰됐는지를 중심에 두려고 했다.
nn이 과정을 기록하며 확인한 기준은 세 가지였다. 먼저 객체의 이름과 라벨이 서로 의도한 대상을 가리키는지 확인한다. 다음으로 컨트롤러가 관찰하는 상태와 사용자가 보는 애플리케이션 상태를 나누어 본다. 마지막으로 변경을 적용하기 전에 실패했을 때 남는 자원과 되돌릴 방법을 생각한다. 이 기준은 로컬 클러스터에서 작은 예제를 읽을 때도, 관리형 클러스터의 배포 문서를 검토할 때도 같은 순서로 적용할 수 있다. 결국 중요한 것은 특정 명령을 외우는 일이 아니라, 선언한 내용이 어떤 객체를 통해 실행되고 어떤 신호로 정상 여부를 판단하는지 설명하는 능력이었다.nn## 오늘의 한 줄 정리
선언형 운영은 원하는 상태를 적는 데서 끝나지 않고, 그 상태를 계속 확인하고 안전하게 수렴시키는 설계다.