“어떻게”가 아닌 “무엇을” 원하는지 말하는 새로운 방식, IaC와 GitOps의 시작
지난 여섯 편의 글을 통해, 우리는 쿠버네티스가 어떻게 애플리케이션을 자동으로 배치, 통신, 배포, 복구, 설정, 확장하는지 알아보았습니다. 이 모든 마법 같은 자동화는 어떻게 가능한 것일까요?
그 비밀은 바로 쿠버네티스의 가장 근본적인 설계 철학, ‘선언적 API 모델(Declarative API Model)’에 있습니다. 이번 글에서는 이 핵심 철학이 어떻게 쿠버네티스의 모든 기능을 뒷받침하고, 개발자가 인프라를 다루는 방식을 완전히 바꾸어 놓는지 알아보겠습니다.
💬 핵심 개념: 명령(Imperative) vs. 선언(Declarative)
먼저 두 가지 접근 방식의 차이를 이해해야 합니다.
- 명령적(Imperative) 방식: “서버 A에 접속해서, 이 파일을 복사하고, 저 스크립트를 실행해.” 처럼 ‘어떻게’ 할지 단계별로 지시하는 방식입니다.
- 선언적(Declarative) 방식: “나는 Nginx 컨테이너 3개가 실행되고 있는 상태를 원해.” 처럼 ‘무엇을’ 원하는지 최종 목표 상태만 선언하는 방식입니다.
쿠버네티스는 철저하게 선언적 모델을 따릅니다. 사용자는 원하는 시스템의 최종 모습(Desired State)을 설계도처럼 제출하기만 하면, 쿠버네티스가 알아서 그 상태를 만들고 유지하기 위해 노력합니다.
🔧 쿠버네티스는 어떻게 선언적 모델을 구현할까?
이 선언적 모델은 몇 가지 핵심 컴포넌트들의 유기적인 협력을 통해 동작합니다.
1. 설계도: YAML Manifest 파일
개발자는 YAML 파일을 통해 클러스터 리소스의 최종 목표 상태(Desired State)를 정의합니다. 이 YAML 파일은 마치 건물의 ‘설계도’와 같습니다.
kind: 어떤 종류의 리소스를 원하는가? (예:Deployment)metadata: 그 리소스의 이름은 무엇인가? (예:my-app)spec: 구체적인 명세는 어떻게 되는가? (예:replicas: 3)
# my-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: my-app
spec:
replicas: 3
# ... 이하 생략2. 설계도 제출: kubectl apply
이 명령은 단순히 “실행해!”가 아니라, “이 설계도(YAML)대로 클러스터를 만들어줘” 라는 요청을 쿠버네티스의 중앙 관제소로 보내는 행위입니다.
kubectl apply -f my-deployment.yaml3. 중앙 관제소이자 두뇌: API 서버(API Server)
API 서버는 클러스터의 유일한 소통 창구이자 중앙 두뇌입니다. kubectl로부터 전달받은 ‘설계도’를 받아서 다음과 같은 일을 합니다.
- 설계도의 유효성을 검증합니다.
- 이 ‘원하는 상태’를 클러스터의 영구 저장소인
etcd에 기록합니다.
4. 일꾼들: Controller와 Scheduler
Controller와 같은 컴포넌트들은 24시간 내내 API 서버를 통해 etcd에 기록된 ‘원하는 상태(Desired State)’를 감시합니다. 그리고 현재 클러스터의 ‘실제 상태(Actual State)’와 비교하여 차이가 있다면, 그 차이를 메우기 위해 끊임없이 일합니다.
replicas가 3인데 실제 Pod가 2개라면? → Controller가 Pod를 하나 더 생성합니다.- Node가 죽어서 Pod가 사라졌다면? → Controller가 다른 Node에 Pod를 다시 생성합니다. (자가 치유)
이것이 바로 쿠버네티스의 모든 자동화 기능이 작동하는 핵심 원리, ‘재조정 루프(Reconciliation Loop)’입니다.
🎁 개발자가 얻는 혁신적인 혜택
쿠버네티스의 선언적 모델은 단순히 편리한 기능을 넘어, 인프라 관리의 패러다임을 바꿉니다.
✅ 수동 관리에서 선언적 자동 관리로의 전환: 더 이상 서버에 접속해 명령어를 입력하는 대신, 원하는 상태를 YAML로 정의하고 제출하면 끝입니다. 운영 부담이 획기적으로 줄어듭니다.
✅ GitOps와 IaC(Infrastructure as Code)의 실현: 인프라의 모든 상태가 텍스트 파일(YAML)로 관리되므로, 애플리케이션 코드처럼 Git으로 버전 관리를 할 수 있게 됩니다. 변경 이력을 추적하고, 동료와 코드를 리뷰하며, 문제가 생기면 이전 버전으로 쉽게 되돌릴 수 있습니다.
✅ 안전하고 재현 가능한 클러스터 운영: 동일한 YAML 파일만 있으면 언제 어디서든 똑같은 환경을 재현할 수 있습니다. 이는 테스트, 스테이징, 운영 환경의 일관성을 보장하고, 재해 복구를 매우 용이하게 만듭니다.
결론적으로, 쿠버네티스의 ‘선언적 API 모델’을 이해하는 것은 단순히 기술을 배우는 것을 넘어, 더욱 안전하고, 예측 가능하며, 자동화된 방식으로 시스템을 운영하는 새로운 철학을 받아들이는 것입니다. 개발자는 더 이상 서버의 미세 관리자가 아닌, 원하는 시스템의 상태를 설계하는 건축가가 됩니다.
