Core Concepts - Imperative vs Declarative

개요

• 명령형(Imperative): “어떻게(How)”를 단계별 명령으로 지시한다. 예) kubectl run, kubectl create, kubectl scale, kubectl set image, kubectl edit
• 선언형(Declarative): “무엇을(What)”이 최종 상태인지 파일로 선언하고, 적용은 kubectl apply가 알아서 맞춘다. 예) YAML(매니페스트) + kubectl apply -f ...

---

1) 비유(스크립트 내용 유지)

명령형 = 택시 기사에게 경로를 하나하나 지시

• “B로 우회전 → C로 좌회전 → … → D에서 멈춰”
• 중간에 실패하면, 어디까지 했는지 확인하고 이어서 지시해야 함
• 이미 목적지에 도착한 상태에서 같은 지시를 다시 주면 충돌/오류/불필요 작업이 생김

선언형 = Uber에 “톰의 집”만 찍기

• 경로(방법)는 시스템이 결정
• 사용자는 최종 목적지(원하는 상태)만 선언
• 시스템이 현재 상태를 보고 “필요한 변경만” 적용해야 이상적

---

2) IaC(인프라 코드)에서의 대응

명령형 예시

• VM 만들고 → nginx 설치하고 → 포트/경로 설정 파일 수정하고 → 코드 내려받고 → 서비스 시작하고…
• 문제: 중간에 절반만 실행되면 “이미 했는지”를 매번 체크해야 함
  예) VM이 이미 존재하면? DB가 이미 있으면? 실패해야 하나? 계속해야 하나?

선언형 예시

• “웹서버 VM 하나 필요, nginx 설치, 포트 8080, 웹 경로, 소스 코드 위치…” 같은 요구 상태를 정의
• 도구가 알아서 “현재 상태 → 목표 상태”로 수렴시키도록 설계
• 강의에서 언급한 Ansible/Puppet/Chef/Terraform 등은 이 축에서 자주 비교됨(도구별로 명령형/선언형 혼합 정도는 다를 수 있음)

---

3) Kubernetes에서 명령형/선언형이 정확히 뭐냐

3-1) Kubernetes 명령형(Imperative) 방식

(A) “순수 명령”으로 생성/수정

• 생성:
  • kubectl run ... (Pod 등 빠르게)
  • kubectl create deployment ...
  • kubectl expose ... (서비스 노출)
• 수정:
  • kubectl edit ...
  • kubectl scale ...
  • kubectl set image ...

장점(스크립트 내용)

• YAML 없이 빠르게 만들고 고치기 좋음
• 시험에서 시간 절약에 유리

단점(스크립트 내용)

• 기능 한계: 멀티 컨테이너/복잡 요구사항은 명령이 길어짐
• “한 번 실행되고 끝”: 보통 히스토리(터미널 기록) 말고는 남지 않음
• 팀이 나중에 “이게 어떻게 만들어졌지?” 추적이 어려움

---

3-2) “파일 기반이지만” 여전히 명령형인 경우(create/replace/delete)

강의가 중요하게 말하는 포인트가 이거임:

• YAML 파일을 갖고 있더라도,
  • kubectl create -f ... 로 만들고
  • 수정 시 kubectl replace -f ... 로 바꾸고
  • 삭제는 kubectl delete -f ... 로 하는 방식은
    쿠버네티스에게 ‘뭘 할지’를 계속 지시하는 흐름이라 명령형에 가깝다는 관점

스크립트에서 강조한 문제

• create는 이미 있으면 실패
• replace는 없으면 실패
• 관리자가 “지금 존재하나?”를 계속 알고 있어야 해서 부담이 큼

---

3-3) Kubernetes 선언형(Declarative) 방식 = kubectl apply

• 목표 상태를 YAML 파일(들)로 만든다(“이렇게 되어 있어야 한다”)
• 그 다음은 항상:
  • kubectl apply -f <file-or-directory>

apply의 핵심 동작(스크립트 내용 그대로)

• 오브젝트가 없으면 생성할 만큼 “지능적”이어야 함
• 이미 있으면 현재 상태를 보고 필요한 변경만 업데이트
• 파일이 여러 개면 디렉터리 전체를 적용 가능: kubectl apply -f ./manifests

이게 왜 편하냐(스크립트 흐름 유지)

• 앞으로는 “로컬 디렉터리(매니페스트 묶음)”만 바꾸고 apply만 다시 때리면 됨
• 생성/업데이트를 구분해서 명령을 바꿀 필요가 크게 줄어듦

---

4) kubectl edit가 위험해지는 이유(스크립트 핵심)

• kubectl edit는 클러스터에 있는 “라이브 오브젝트”를 즉시 수정한다.
• 하지만 로컬 YAML 파일은 그대로일 수 있다.
• 팀원이 로컬 파일 기준으로 다시 apply/replace를 하면,
  edit로 바꿨던 변경이 덮여서 사라질 수 있다.
• 그래서 “파일을 소스 오브 트루스로 관리할 거면”
  로컬 파일을 수정하고 apply로 반영하는 흐름이 안전하다.

---

5) 시험 관점 팁(스크립트 유지 + 정리)

• 단순 생성(이름/이미지 정도) → 명령형 커맨드가 빠름
  • 예: kubectl run, kubectl create deployment
• 기존 오브젝트 속성 조금 수정 → kubectl edit가 가장 빠를 때가 많음
• 복잡 요구사항(멀티 컨테이너, env, command, initContainer 등) →
  YAML로 작성 후 kubectl apply가 실수를 줄이고 수정 재적용이 쉬움
• 결국 시험에서는 “명령형을 최대한 활용하되, 복잡하면 YAML+apply로 전환”이 효율적이라는 메시지

---

6) 이 강의 내용으로 헷갈리기 쉬운 포인트 2개

1. YAML을 쓴다고 자동으로 선언형이 아니다
   • create/replace/delete로 “단계별 지시”하면 명령형에 가까움
   • apply로 “상태 수렴”시키면 선언형
2. 선언형 = 무조건 완전 자동/무조건 안전은 아님
   • 선언형의 전제는 “파일이 진짜 소스 오브 트루스”여야 함
   • 클러스터를 edit로 따로 만지면 드리프트(파일과 실제 불일치)가 생김

---

Practice Test Link: https://uklabs.kodekloud.com/topic/practice-test-imperative-commands-3/