<aside>
CloudWave · W04 · 4/5 · 예상 읽기 7분
</aside>
Deployment만으로 데이터베이스 같은 워크로드를 다루려 하니, Pod와 저장소의 정체성을 어떻게 연결할지가 남았다.
StatefulSet은 순서가 있는 이름, 안정적인 네트워크 정체성, 개별 저장소 연결이 필요한 워크로드를 위한 컨트롤러다. 데이터베이스, 분산 캐시, 메시지 큐처럼 각 인스턴스의 역할이나 데이터 위치가 중요한 경우 검토한다. 그렇다고 StatefulSet이 데이터베이스 운영 문제를 자동 해결하는 것은 아니다.
Kubernetes의 객체는 명령어 목록이라기보다 원하는 상태를 표현하는 문서에 가깝다. 컨트롤러는 그 문서와 현재 상태의 차이를 관찰하고 필요한 조정을 반복한다. 이 관점으로 보면 생성 명령 자체보다 선택자, 템플릿, 복제본, 실패 시 대체 행동을 읽는 일이 중요해진다. 이름이 비슷한 객체라도 책임 범위가 다르므로, 무엇이 상태를 보관하고 무엇이 연결을 제공하는지 나누어 읽었다.
상태가 있는 Pod는 삭제와 재생성의 순서, PVC와 PV의 생명주기, 백업과 복구를 함께 설계해야 한다. 저장소의 접근 모드는 환경과 드라이버에 따라 다르며, 하나의 디스크를 여러 노드가 자유롭게 공유한다고 가정하면 안 된다. 복제와 일관성도 애플리케이션의 책임 영역이다.
Helm은 차트와 values를 이용해 Kubernetes 리소스를 패키징하고 환경별 값을 주입하는 도구로 이해했다. 공통 템플릿과 환경별 설정을 분리하면 반복을 줄일 수 있지만, 템플릿이 복잡해질수록 렌더링 결과를 확인하고 버전과 롤백을 관리해야 한다.
작은 예제로 시작할 때도 리소스 이름은 example-app처럼 가상으로 두고, 실제 자격 증명이나 인프라 식별자는 문서에 넣지 않는다. 변경 전후의 상태를 비교하고, 실패했을 때 되돌릴 기준을 먼저 적어 두면 선언형 운영의 장점이 드러난다. 자동화는 사람의 판단을 없애는 것이 아니라 판단을 반복 가능한 절차로 바꾸는 일에 가깝다.
StatefulSet은 무조건 Deployment보다 상위 개념이 아니다. 상태가 필요 없는 웹 서버에 억지로 사용하면 운영 복잡도만 늘 수 있다. Helm도 설치 명령 하나로 운영 준비가 끝나는 도구가 아니라, 결과 YAML과 리소스 생명주기를 검토하게 해 주는 패키징 계층이다.
또 하나의 오해는 Kubernetes가 모든 운영 결정을 대신한다는 생각이었다. Kubernetes는 객체와 컨트롤러의 공통 언어를 제공하지만, 데이터 보존, 권한, 비용, 백업, 장애 범위는 별도의 설계 대상이다. 그래서 실습 결과를 기록할 때도 성공 여부보다 어떤 조건에서 무엇이 관찰됐는지를 중심에 두려고 했다.
nn이 과정을 기록하며 확인한 기준은 세 가지였다. 먼저 객체의 이름과 라벨이 서로 의도한 대상을 가리키는지 확인한다. 다음으로 컨트롤러가 관찰하는 상태와 사용자가 보는 애플리케이션 상태를 나누어 본다. 마지막으로 변경을 적용하기 전에 실패했을 때 남는 자원과 되돌릴 방법을 생각한다. 이 기준은 로컬 클러스터에서 작은 예제를 읽을 때도, 관리형 클러스터의 배포 문서를 검토할 때도 같은 순서로 적용할 수 있다. 결국 중요한 것은 특정 명령을 외우는 일이 아니라, 선언한 내용이 어떤 객체를 통해 실행되고 어떤 신호로 정상 여부를 판단하는지 설명하는 능력이었다.nn## 오늘의 한 줄 정리
선언형 운영은 원하는 상태를 적는 데서 끝나지 않고, 그 상태를 계속 확인하고 안전하게 수렴시키는 설계다.