44. Imperative v. Declarative

Imperative

어떠한 목표를 달성하기 위한 자세한 instruction을 작성함
(중간에 절차가 멈추고 뻗는다든가 했을 때에 resume하기가 귀찮아진다)

1. 'web-server'라는 이름으로 VM 생성
2. Nginx 설치
3. Nginx 설정파일 변경: 포트 8080 사용
4. Nginx 설정파일 변경: 웹 경로 /var/www/nginx 사용
5. Git Repo X에서 /var/www/nginx 경로에 pull
6. nginx 시작

Kubernetes에서의 imperative way

장점:

• 시험 볼 때같이 간단한 환경을 잠깐 쓸 때에는 좋음
  단점:
• 특정 Session에서 실행했을 때 해당 Session에서만 유효함.
• 기능이 제약되어 있음 (multi-container pod deployment 등은 불가)

Imperative command 이용 (yaml 파일을 건드리지 않는다)

Object 생성

• kubectl run --image=nginx nginx
• kubectl create deployment --image=nginx nginx
• kubectl expose deployment nginx --port 80

Object 수정

• kubectl edit deployment nginx

  • 이 명령어의 경우, Kubernetes 메모리상에 있는 Definition file을 연다.
    • 이것은 kubectl create에 썼던 yaml 파일과 비슷하지만 다른 파일으로, 예를 들어 status 필드같은 게 존재함을 볼 수 있다.
    • 이 파일에 수정하고 저장하면 살아있는 오브젝트에는 변경사항이 적용되지만, 실제 local file로 저장되어있는 설정 파일에는 적용되지 않는다.
      • 나중에 유지보수할 때 매우 골치가 아파질 수 있다!!
  • 따라서 kubectl edit을 쓰는 것보다는, 그냥 로컬 yaml 파일을 수정한 뒤 kubectl replace -f asdf.yaml를 사용하는 것이 권장된다.

• kubectl scale deployment nginx --replicas=5

• kubectl set image deployment nginx nginx=nginx:1.18

• kubectl create -f nginx.yaml
• kubectl replace -f nginx.yaml
• kubect delete -f nginx.yaml

하지만, 결국 이것들도 Imperative way인 것은 마찬가지이다 - 예를 들어 kubectl create로 Pod을 만들고자 하는 경우, 관리자는 그 Pod이 이미 존재하는지 등등을 미리 파악하고 있어야 한다.

Declarative

목표만 작성함, 실제 어떻게 수행할지는 시스템에 의해 결정됨 - Ansible, Puppet, Chef, Terraform 등

• VM-name: web-server
• Package: nginx
• Port: 8080
• Path: /var/www/nginx
• Code: Git repo X

Kubernentes에서의 Declarative way

• kubectl apply -f nginx.yaml로 알아서 confinuration을 읽고, 모든 것을 적용
  • 예를 들어 Pod 설정파일일 경우, 해당 Pod이 이미 있으면 생성하지 않고 없으면 생성함
  • -f 디렉토리로 경로를 주는 경우, 해당 디렉토리 아래의 모든 설정파일이 일괄 적용
  • 설정파일이 변경되었다고 해도, 같은 명령어로 update적용가능

Kubectl Apply 명령어

• 쿠버는 내부적으로 live 상태의 객체에 대한 Live object configuration을 가지고 있다

• 관리자가 만든 YAML 파일 형태의 로컬 설정파일 (-f 파일명을 해서 불러올)도 존재할것이다

• 하지만, 만약 kubectl apply를 하게 되면, "마지막으로 적용된 설정"이 하나 추가적으로 보관되게 된다

  • JSON 포맷으로 저장됨

• 예를 들어, 로컬 설정파일에서 spec > image를 nginx:latest에서 nginx:1.19로 바꾼 뒤에 kubectl apply -f을 했다고 해 보자

  • 그러면 일단 Live Object Configuration이 바뀌고
  • 그 다음 Last Applied Configuration이 바뀐다

• 하지만 로컬 설정파일에서 필드를 삭제한 뒤에 kubectl apply했다면, Last Applied Configuration과 비교해서 해당 필드가 사라졌음을 확인하고, Live Configuration에서 날린다

• https://kubernetes.io/docs/tasks/manage-kubernetes-objects/declarative-config/#merging-changes-to-map-fields 참조

• "마지막으로 적용된 설정"은 사실 Live Object Configuration의 Metadata칸에 저장된다

  • kubectl apply 시에만 생성되는 필드
  • 따라서 kubectl create / kubectl replace 명령어와 kubetl apply를 섞어서 쓰면 안 된다

시험 팁

• --dry-run=client 옵션을 주면 해당 리소스가 실제로 생성되는것이 아니라, 명령어의 문법이 맞는지, 생성이 가능할지만을 검증해줌
• -o yaml: Resource Definition을 YAML 형식으로 출력함