Imperative vs Declarative

택시를 통한 비유

명령형(Imperative) 접근 방식

• 설명:
  • 목적지에 도달하기 위해 단계별로 구체적인 지시를 내리는 방식.
  • 예: 친구 집(Street B)에 가기 위해 택시 기사에게 다음과 같이 지시:
    1. Street B로 우회전.
    2. Street C로 좌회전.
    3. Street D로 다시 좌회전 후 우회전.
    4. 도착하면 멈춤.
• 특징:
  • 어떻게(How) 도달할지를 명확히 지시.
  • 사용자가 모든 단계를 직접 제어.
  • 과정이 복잡하고, 오류 발생 가능성 증가.

선언형(Declarative) 접근 방식

• 설명:
  • 목적지에 도달하기 위해 최종 상태만 명시하는 방식.
  • 예: Uber를 호출하여 "Tom의 집으로 가 주세요"라고 요청.
    • 사용자는 최종 목적지(Tom의 집)만 제공.
    • 시스템(Uber)은 최적의 경로를 계산하여 목적지에 도달.
• 특징:
  • *무엇(What)*을 원하는지만 명확히 정의.
  • 시스템이 경로와 방법을 자동으로 결정.
  • 사용자는 결과만 신경 쓰면 됨.

---

Kubernetes에서

접근  방식	명령형(Imperative)	선언형(Declarative)
작업 방식	단계별로 구체적인 명령 실행	최종 상태만 정의
사용 도구	CLI 명령어 (kubectl run, create)	YAML/JSON 파일과 kubectl apply
복잡한 작업 처리	어렵고 비효율적	효율적
변경 사항 추적	불가능	가능 (Git 등과 통합)
협업 및 관리	비효율적	효율적

---

1. 개요

• Kubernetes에서 리소스를 생성하고 관리하는 방법에는 **명령형(Imperative)**과 선언형(Declarative) 두 가지 접근 방식이 있음.
• 이 두 가지 접근 방식은 인프라를 코드로 관리하는 방법론에서 중요한 개념으로, 각각의 특징과 사용 사례가 다름.

2. 명령형(Imperative) 접근 방식

정의

• 명령형 접근 방식은 무엇을 해야 하는지와 어떻게 해야 하는지를 명시적으로 지정.
• 단계별로 작업을 수행하며, 사용자가 직접 명령어를 실행하여 리소스를 생성, 수정, 삭제.

특징

1. 직접 명령 실행:
   • 예: kubectl run, kubectl create, kubectl expose 등의 명령어 사용.
   • Pod 생성:

kubectl run nginx-pod --image=nginx

1. 단순하고 빠른 작업:
   • 간단한 리소스 생성이나 수정 작업에 적합.
   • YAML 파일 없이 CLI 명령어만으로 작업 가능.
2. 한 번 실행 후 기록 없음:
   • 실행된 명령은 기록되지 않으며, 다른 사용자와 공유하기 어려움.
   • 복잡한 환경에서는 관리가 어려움.
3. 예제:
   • Deployment 생성:

kubectl create deployment my-deployment --image=nginx

• Deployment 확장:

kubectl scale deployment my-deployment --replicas=3

한계

• 복잡한 작업(예: 다중 컨테이너 Pod 생성)은 긴 명령어가 필요하며 오류 발생 가능성 증가.
• 변경 사항 추적 및 협업 어려움.

3. 선언형(Declarative) 접근 방식

정의

• 선언형 접근 방식은 무엇을 원하는지만 정의하고, 시스템이 이를 달성하는 방법을 자동으로 결정.
• YAML 또는 JSON 파일로 리소스의 상태를 정의하고 이를 적용.

특징

1. 상태 정의:
   • YAML 파일에 원하는 리소스 상태를 정의.
   • 예: Pod 정의 파일

#yaml
apiVersion: v1
kind: Pod
metadata:
  name: nginx-pod
spec:
  containers:
  - name: nginx-container
    image: nginx

2. kubectl apply 사용:

• 선언된 상태를 클러스터에 적용.

kubectl apply -f pod-definition.yaml

3. 자동 업데이트 및 변경 관리:

• 기존 상태와 비교하여 필요한 변경 사항만 적용.
• 예: 이미지 버전 업데이트 시 YAML 파일 수정 후 재적용.

containers:
  - name: nginx-container
    image: nginx:1.18 #nginx:latest에서 1.18로 수정

kubectl apply -f pod-definition.yaml

4. 추적 가능성:

• YAML 파일을 Git과 같은 버전 관리 시스템에 저장하여 변경 사항 추적 및 협업 가능.

장점

• 복잡한 작업을 효율적으로 처리 가능.
• 변경 사항 기록 및 협업에 유리.
• 시스템이 현재 상태와 원하는 상태를 비교하여 필요한 작업만 수행.

 Imperative vs Declarative 비교

특징	Imperative	Declarative
작업 방식	단계별 명령 실행	최종 상태 정의
사용 도구	CLI 명령어(kubectl run, create)	YAML/JSON 파일과 kubectl apply
복잡한 작업 처리	어렵고 비효율적	효율적
변경 사항 추적	불가능	가능 (Git 등과 통합)
협업 및 관리	비효율적	효율적

실무 팁

1. 시험에서는 시간 절약을 위해 명령형 접근 방식을 연습할 것.
2. 프로덕션 환경에서는 선언형 접근 방식을 권장하며, Git과 같은 버전 관리 시스템에 YAML 파일 저장.
3. kubectl edit 명령어는 빠른 수정에 유용하지만, YAML 파일과 동기화되지 않으므로 주의 필요.