📌 Imperative(명령형) vs Declarative(선언형)

• IaC 환경에서는 인프라 관리시 명령형, 선언형 등의 접근법이 있다.

📲 Imperative

# Create Objects

# 복잡한 유스케이스를 위해 길고 복잡한 명령을 만들어야하지만 빠름 (자격증 시험시 유리)
# 명령이 실행되면 명령어를 잊어버림 (명령어를 실행한 세션 히스토리에서만 조회가능)

$ kubectl run --image=nginx nginx
$ kubectl create deployment --image=nginx nginx
$ kubectl expose deployment nginx --port 80 // 서비스를 생성하는 포트를 노출

# Update Objects
$ kubectl edit deployment nginx // 기존 생성된 개체를 수정할 시 사용
# 쿠버네티스 메모리 내의 Pod 설정파일과 유사함
# edit 명령어로 설정파일을 변경, 수정하면 라이브 개체에 바로 적용됨
# 하지만 local 에 보유하고 있는 설정파일과 차이점이 생긴다
$ kubectl scale deployment nginx --replicas=3 // Pod 개수를 스케일링
$ kubect set image deployment nginx nginx=nginx1.18 // 배포된 이미지를 업데이트

$ kubectl create -f nginx.yaml
$ kubectl replace -f nginx.yaml // edit 명령으로 수정된 라이브 개체의 변경점을 로컬 구성 파일에 적용한다
# 대체할 Pod가 존재하지 않으면 오류 메시지가 발생한다 replace 명령어는 이미 존재하는 Pod의 설정을 구성이 정의된 파일로 옮기는 명령이기 때문이다.
$ kubectl replace --force -f nginx.yaml // 완전히 삭제하고 재생성

$ kubectl delete -f nginx.yaml

• 인프라를 요구에 정확히 어떻게 적용할지 명령하고 있음
• 항상 replace 명령으로 이미 생성된 Pod인지 확인하고
• create 명령으로 중복된 Pod 인지 확인해야 한다.
• 이는 관리자에게 까다롭다.

📑 Declarative

• ansibel, perpet, Chef, TerraForm 같은 도구
• 쿠버네티스 클러스터에서 애플리케이션과 서비스의 예상 상태를 정의하는 파일 집합 만듬
• yaml, manifest 파일등이 정확히 개체가 어떻게 생성 되었는지 확인하기 용이

$ kubectl apply -f nginx.yaml // 기존 구성을 보고 시스템에 어떤 변화가 있는지 알아냄
$ kubectl apply -f /path/to/config-files

• apply 커멘드는 이미 개체가 있으면 업데이트, 없으면 생성한다.
• 파일 경로를 입력해서 참조할 구성 파일을 명시 할 수 있다.

🔔 Tips

• 명령적 접근을 써서 시간을 절약
• 주어진 이미지로 포드나 배포를 생성하는 경우 빠르게 달성할 수 있음
• 명령적 접근을 연습
• 이미 생성된 개체를 수정하면 edit 명령어 등을 연습
• 복잡한 개체를 생성할땐 선언적 접근

공식 문서 참고 많이 하기

⌨️ Commands

$ kubectl expose pod redis --name=redis-service --port=6379 --type=ClusterIP
$ kubectl run httpd --image=httpd:alpine -n default --expose --port=80