[K8S] Kubernetes Object Management 에 대해서 살펴보자.

Kubernetes를 사용하면서 자주 사용하는게 kubectl 명령어 이다. 그리고 그중에서 컨테이너를 생성할때 항상 kubectl create 명령어를 사용했다. 그런데 사용하다보니 어떤 글에는 create 를 사용하고 어디에서는 apply 를 사용하는 것을 보게 되었다. 그래서 이 차이점이 궁금해서 이렇게 정리하게 되었다. 

아래 내용들은 kubernetes document 에서 요약한 내용들이다. 

https://kubernetes.io/docs/concepts/overview/object-management-kubectl/overview/

Kubernetes 에서 Object Management 에는 3가지가 있다. 

Management technique	Operates on	Recommended environment	Supported writers
Imperative commands	Live objects	Development	1+
Imperative object configuration	Individual files	Production	1
Declarative object configuration	Directories of files	Production	1+

Imperative Commands

장점

- 클러스터에 특정 오브젝트를 한번에 실행하거나 시작할수 있는 가장 쉬운 방법이다. (실제 이미지 바로 실행 시킨다. )

단점

- 기존 설정에 대한 히스토리를 제공하지 않는다. (그래서 위에 권장 환경이 Development 인것 같다.)

- 변경사항이나 audit 내역, 템플릿등을 제공하지 않는다. 

ex)

kubectl run nginx --image nginx

Imperative object configuration

- 최소한 1개 이상의 YAML 이나 JSON 포맷의 파일을 이용해서 Object 를 생성한다. 

ex)

kubectl create -f nginx.yaml

Imperative object configuration vs Imperative Commands

장점

- 설정파일 내용을 Git 같은 곳에 저장이 가능하기 때문에 설정에 대한 변경 히스토리가 확인 가능하다. 

- 새로운 Object를 생성하기 위한 템플릿을 제공한다. 

단점

- YAML 파일 작성이 필요하며 템플릿 사용을 위해 Object schema 에 대해서 이해가 필요하다.

Imperative object configuration vs Declarative object configuration 

장점

- 더 간단하고 이해하기 쉽다.

단점

- 파일로 적용할때에만 동작한다. 디렉토리는 불가능.

- 실행중인 object 를 update 하기 위해서는 설정파일에 반영을 해야 한다. 

Declarative object configuration

- 모든 설정 파일들은 디렉토리 안에 들어있고 오브젝트를 생성하거나 패치 한다.

ex)

kubectl apply -f configs/

Declarative object configuration vs Imperative object configuration

장점

- 실행중인 오브젝트 직접 적용한 변경사항을 설정파일에 merge 하지 않더라도 유지된다.(???)

단점

- 디버깅 하기 어렵고 예상한 결과가 아닐 경우 이해하기 어렵다.

- diffs 를 사용한 부분 업데이트는 복잡한 병합과 패치를 만들게 된다.

Imperative commands 나  Imperative object configuration 는 이해가 되는데  Declarative object configuration 은 약간 이해가 안된다. 

https://kubernetes.io/docs/concepts/overview/object-management-kubectl/declarative-config/

여기 있는 샘플을 가지고 확인해보자.

sample_deployment.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  selector:
    matchLabels:
      app: nginx
  minReadySeconds: 5
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.7.9
        ports:
        - containerPort: 80

Create : kubectl apply -f sample_deployment.yaml 

Live configuration : kubectl get -f sample_deployment.yaml -o yaml

kind: Deployment
metadata:
  annotations:
    # ...
    # This is the json representation of simple_deployment.yaml
    # It was written by kubectl apply when the object was created
    kubectl.kubernetes.io/last-applied-configuration: |
      {"apiVersion":"apps/v1","kind":"Deployment",
      "metadata":{"annotations":{},"name":"nginx-deployment","namespace":"default"},
      "spec":{"minReadySeconds":5,"selector":{"matchLabels":{"app":nginx}},"template":{"metadata":{"labels":{"app":"nginx"}},
      "spec":{"containers":[{"image":"nginx:1.7.9","name":"nginx",
      "ports":[{"containerPort":80}]}]}}}}
  # ...
spec:
  # ...
  minReadySeconds: 5

kubectl.kubernetes.io/last-applied-configuration 어노테이션에 보면 sample_deployment.yaml  에 적용한 내용들이 나와있다. 

다시 아래와 같이 명령어를 실행해보고 확인해보자.

kubectl scale deployment/nginx-deployment --replicas=2

Live configuration : kubectl get -f sample_deployment.yaml -o yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  annotations:
    # ...
    # note that the annotation does not contain replicas
    # because it was not updated through apply
    kubectl.kubernetes.io/last-applied-configuration: |
      {"apiVersion":"apps/v1","kind":"Deployment",
      "metadata":{"annotations":{},"name":"nginx-deployment","namespace":"default"},
      "spec":{"minReadySeconds":5,"selector":{"matchLabels":{"app":nginx}},"template":{"metadata":{"labels":{"app":"nginx"}},
      "spec":{"containers":[{"image":"nginx:1.7.9","name":"nginx",
      "ports":[{"containerPort":80}]}]}}}}
  # ...
spec:
  replicas: 2 # written by scale
  # ...
  minReadySeconds: 5

이 경우에는 apply를 하지 않았기 때문에 kubectl.kubernetes.io/last-applied-configuration 어노테이션에 포함되지 않았다.

sample_deployment.yaml 파일을 수정해보자. 

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.11.9 # update the image
        ports:
        - containerPort: 80

nginx image 버전이 1.7.9 에서 1.11.9 로 변경 되었다.

Create : kubectl apply -f sample_deployment.yaml 

Live configuration : kubectl get -f sample_deployment.yaml -o yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  annotations:
    # ...
    # The annotation contains the updated image to nginx 1.11.9,
    # but does not contain the updated replicas to 2
    kubectl.kubernetes.io/last-applied-configuration: |
      {"apiVersion":"apps/v1","kind":"Deployment",
      "metadata":{"annotations":{},"name":"nginx-deployment","namespace":"default"},
      "spec":{"selector":{"matchLabels":{"app":nginx}},"template":{"metadata":{"labels":{"app":"nginx"}},
      "spec":{"containers":[{"image":"nginx:1.11.9","name":"nginx",
      "ports":[{"containerPort":80}]}]}}}}
    # ...
spec:
  replicas: 2 # Set by `kubectl scale`.  Ignored by `kubectl apply`.
  # minReadySeconds cleared by `kubectl apply`
  # ...
  selector:
    matchLabels:
      # ...
      app: nginx
  template:
    metadata:
      # ...
      labels:
        app: nginx
    spec:
      containers:
      - image: nginx:1.11.9 # Set by `kubectl apply`

확인을 해보면 apply 로 적용한 nginx 버전은 kubectl.kubernetes.io/last-applied-configuration 어노테이션에 포함 되어있다. 하지만 replicas 는 포함되지 않았다.

Warning: Mixing kubectl apply with the imperative object configuration commands create and replace is not supported. This is because create and replace do not retain the kubectl.kubernetes.io/last-applied-configuration that kubectl apply uses to compute updates

그리고 위와 같은 주의 사항도 있다. apply 는 create 나 replace 를 지원하지 않는다는 거다. 이유는 create 나 replace 는 kubectl.kubernetes.io/last-applied-configuration 어노테이션을 유지 하지 않기 때문이라고 한다. 

apply 와 create 의 차이점을 찾아보다가 여기까지 오게 되었다. 결과적으로 가장 큰 차이점은 apply 를 할 경우에는 기존 설정에 대한 정보를 가지고 있다는 점인것 같다. 

apply 이외에도 다른 명령어들이 있지만 우선은 이것만 이해하는걸로 하자.