<aside>
CloudWave · W04 · 1/5 · 예상 읽기 7분
</aside>
Pod 하나를 실행하면 끝이라고 생각했지만, 실제로는 장애와 교체를 누가 책임지는지가 더 큰 질문이었다.
Pod는 컨테이너를 함께 실행하는 최소 단위이고 네트워크와 저장 공간을 공유할 수 있다. 그러나 Pod는 일회성에 가까운 객체라서 수명과 애플리케이션의 안정성을 동일시하면 안 된다. 선언한 Pod가 사라졌을 때 다시 만들어 줄 상위 객체가 필요하다.
Kubernetes의 객체는 명령어 목록이라기보다 원하는 상태를 표현하는 문서에 가깝다. 컨트롤러는 그 문서와 현재 상태의 차이를 관찰하고 필요한 조정을 반복한다. 이 관점으로 보면 생성 명령 자체보다 선택자, 템플릿, 복제본, 실패 시 대체 행동을 읽는 일이 중요해진다. 이름이 비슷한 객체라도 책임 범위가 다르므로, 무엇이 상태를 보관하고 무엇이 연결을 제공하는지 나누어 읽었다.
ReplicaSet은 선택 조건과 복제본 수를 기준으로 원하는 수를 유지한다. 그래서 수동으로 Pod를 다시 만드는 대신 컨트롤러가 실제 상태를 관찰하고 차이를 줄인다. Probe도 하나의 건강 신호가 아니다. startup은 시작 완료를, readiness는 트래픽 수신 가능 여부를, liveness는 계속 살아 있는지를 묻는다.
실무에서는 라벨을 식별 기준으로 삼고, readiness가 실패한 Pod를 서비스 대상에서 제외하는 흐름을 먼저 그린다. liveness를 너무 공격적으로 설정하면 정상적인 초기화 중인 애플리케이션을 반복 재시작할 수 있다. ReplicaSet만 직접 다루기보다 보통 Deployment가 버전과 복제본을 함께 관리한다.
작은 예제로 시작할 때도 리소스 이름은 example-app처럼 가상으로 두고, 실제 자격 증명이나 인프라 식별자는 문서에 넣지 않는다. 변경 전후의 상태를 비교하고, 실패했을 때 되돌릴 기준을 먼저 적어 두면 선언형 운영의 장점이 드러난다. 자동화는 사람의 판단을 없애는 것이 아니라 판단을 반복 가능한 절차로 바꾸는 일에 가깝다.
가장 헷갈렸던 점은 컨테이너가 실행 중이라는 사실과 요청을 받을 준비가 됐다는 사실이 다르다는 점이다. 또 Pod가 재생성되어도 로컬 파일이 보존된다고 기대하면 안 된다. 상태 보존은 별도의 볼륨과 워크로드 설계 문제다.
또 하나의 오해는 Kubernetes가 모든 운영 결정을 대신한다는 생각이었다. Kubernetes는 객체와 컨트롤러의 공통 언어를 제공하지만, 데이터 보존, 권한, 비용, 백업, 장애 범위는 별도의 설계 대상이다. 그래서 실습 결과를 기록할 때도 성공 여부보다 어떤 조건에서 무엇이 관찰됐는지를 중심에 두려고 했다.
nn이 과정을 기록하며 확인한 기준은 세 가지였다. 먼저 객체의 이름과 라벨이 서로 의도한 대상을 가리키는지 확인한다. 다음으로 컨트롤러가 관찰하는 상태와 사용자가 보는 애플리케이션 상태를 나누어 본다. 마지막으로 변경을 적용하기 전에 실패했을 때 남는 자원과 되돌릴 방법을 생각한다. 이 기준은 로컬 클러스터에서 작은 예제를 읽을 때도, 관리형 클러스터의 배포 문서를 검토할 때도 같은 순서로 적용할 수 있다. 결국 중요한 것은 특정 명령을 외우는 일이 아니라, 선언한 내용이 어떤 객체를 통해 실행되고 어떤 신호로 정상 여부를 판단하는지 설명하는 능력이었다.nn## 오늘의 한 줄 정리
선언형 운영은 원하는 상태를 적는 데서 끝나지 않고, 그 상태를 계속 확인하고 안전하게 수렴시키는 설계다.