본문 바로가기

DevOps/쿠버네티스(Kubernetes)

[CKA] Kubernetes kubectl apply 명령어

Kubernetes kubectl apply 명령어

 

# nginx.yaml
apiVersion: v1
kind: Pod
metadata:
  name: myapp-pod
  labels:
  	app: myapp
    type: front-end-service
spec:
  containers:
  - name: nginx-container
    image: nginx:1.18
    
    
 # Live object configuration (Last applied Configuration)
 apiVersion: v1
 kind: Pod
 metadata:
   name: myapp-pod
   annotations:
     kubectl.kubernetes.io/last-applied-configuration:
   {"apiVersion": "v1","kind": "Pod","metadata": {"annotations"; {},"labels: {"run": "myapp-pod","type": "front-end-service"}, "name": "myapp-pod"},"spec": {"containers": {"image": "nginx:1.18","name": "nginx-container"}}}
   labels:
     app: myapp
     type: front-end-service
spec:
  containers:
  - name: nginx-container
    image: nginx:1.18
status:
  conditions:
  - lastProbeTime: null
    status: "True"
    type: Initialized

kubectl apply 명령어가 내부적으로 어떻게 작동하는지 자세히 알아보자. apply 명령어는 변경 사항을 결정하기 전에 로컬 구성 파일, Kubernetes의 수명 개체 정의 및 마지막으로 적용된 구성을 고려한다. 따라서 apply 명령을 실행하면 개체가 아직 존재하지 않는 경우 개체가 생성된다.

 

개체가 생성될 때 로컬에서 만든 것과 유사한 개체 구성이 Kubernetes 내에서 생성되지만 개체의 상태를 저장하기 위한 추가 필드가 있다. 이것은 쿠버네테스 클러스터에 있는 개체의 수명 구성입니다. 이것은 쿠버네티스가 객체를 만들기 위해 사용하는 접근 방식에 관계없이 객체에 대한 정보를 내부적으로 저장하는 방법이다.

그러나 kubectl apply 명령어를 사용하여 개체를 만들 때는 더 많은 작업을 수행한다. 우리가 작성한 로컬 개체 구성 파일의 YAML 버전을 JSON 형식으로 변환된 다음 개체에 대한 업데이트를 위해 마지막으로 적용된 구성으로 저장된다. 이 세 가지를 모두 비교하여 활성 개체에 대해 어떤 변경을 수행해야 하는지 확인한다. 예를 들어, Nginx 이미지가 로컬 파일에서 1.19로 업데이트되고 apply 명령을 실행하는 경우를 가정해 보자. 이 값은 라이브 구성의 값과 비교되며 차이가 있는 경우 수명 구성이 새 값으로 업데이트된다. 변경 후 마지막으로 적용된 JSON 형식은 항상 최신 상태로 업데이트되므로 항상 최신 상태로 유지된다.

그렇다면 왜 마지막으로 적용된 구성이 실제로 필요한 이유는 무엇일까? 맞다. 예를 들어, 필드가 삭제된 경우 유형 레이블이 삭제되었다. 이제 명령을 실행하면 마지막으로 적용한 구성에 레이블이 있지만 로컬 구성에 없다. 즉, 실시간 구성에서 필드를 제거해야 한다. 따라서 필드가 라이브 구성에 있고 로컬 또는 마지막으로 적용된 구성에 없는 경우, 해당 필드는 그대로 유지된다. 그러나 로컬 파일에서 필드가 누락되어 있고 해당 필드가 마지막으로 적용된 구성에 있는 경우, 이전 단계에서 또는 마지막으로 적용된 명령을 실행할 때마다 해당 필드가 있었고 현재 제거되어야 함을 의미한다. 마지막으로 적용한 구성이 어떤 필드가 로컬파일에서 제거되었는지 알아내는 데 도움이 된다. 그러면 해당 필드가 실제 라이브 구성에서 제거된다.

그래서 우리는 세 세트의 파일을 보았고, 우리는 로컬 시스템에 저장된 로컬 파일이라는 것을 알고 있다. 라이브 개체 구성은 쿠버네티스 메모리에 있지만 마지막으로 적용된 구성이 저장된 이 JSON 파일은 어디에 있을까? 마지막 적용 구성(annotations: kubectl.kubernetes.io/last-applied-configuration)이라는 주석으로 쿠버네티스 클러스터의 라이브 개체 구성(Live object configuration)에 저장된다. 따라서 이 작업은 kubectl apply 명령을 사용할 때만 수행된다는 것을 기억하라. 코드가 명령을 생성하거나 대체한다.

마지막으로 적용한 구성을 저장하지 마라. 쿠버네티스 개체를 관리하는 동안 명령적 접근과 선언적 접근 방식을 혼합하지 않도록 명심해야 한다. 따라서 적용된 명령을 사용하면 변경이 이루어질 때마다 apply 명령은 세 가지 섹션을 모두 비교한다. 로컬 pod 정의 파일, 라이브 개체 구성 및 라이브 개체 구성 파일에 저장된 마지막 적용 구성을 비교함으로써 라이브 구성에 대해 어떤 변경을 수행할지 결정한다.

 

 

 

 

 

출처:

https://www.udemy.com/course/certified-kubernetes-administrator-with-practice-tests/learn/lecture/21500826#overview