Kubernetes:kubectl apply 동작

kubectl apply는 객체가 없는 경우 명령을 작성하고 객체가 있는 경우 차이를 반영하는 편리한 명령입니다.그러나 차분한 반영은 단순한 덮어쓰기가 아니므로 주의해야 한다.이 글에서 우리는 Kubernetes Meetup Tokyo #5에 게재된 내용입니다.을 바탕으로 쿠벨 앱의 동작을 정리했다.Kubernetes v1.9.0을 확인하고 있습니다.

kubectl apply

kubectl 객체에 대한 피드 명령을 제공합니다.비apply의create,replace 등 하위 명령은 현재 대상의 상태를 인식하고 조작해야 합니다.예를 들어, kubectl create 에서는 이름이 있는 객체를 다시 만들려고 하면 오류가 발생하고, kubectl replace 에서는 존재하지 않는 객체를 덮어쓰려고 하면 오류가 발생합니다.
한편 kubectl apply 대상의 상태를 자동으로 보고 존재하지 않으면 제작하고 존재하면 차분을 계산하여 반영하고 자동으로 판단한다.따라서 kubectl apply를 잘 사용하면create/replace/patch 등 하위 명령을 구분하지 않고 선언만 하면 성명성 관리를 할 수 있다.이런 관리 방법은 Kubernetes의 공식 문서에서 Declarative object configuration 라고 부른다.
하위 명령
개체 없음
개체 존재apply 새로 만들기POST차분반영PATCH,DELETEcreate 새로 만들기POST 오류replace 오류
덮어쓰기PUTpatch 오류
차분 반영PATCHdelete 오류
삭제DELETE다음은kubectl apply의 동작 예입니다.

# apply はオブジェクトが存在しない場合は新規作成
$ kubectl apply -f nginx-dep.yml
deployment "nginx" created

# マニフェストを編集
$ vim nginx-dep.yaml

# create はオブジェクトが存在する場合エラーになる
$ kubectl create -f nginx-dep.yaml
Error from server (AlreadyExists): error when creating "nginx-dep.yaml": deployments.extensions "nginx" already exists

# apply はオブジェクトが存在する場合もエラーにならない。差分があれば差分を反映
$ kubectl apply -f nginx-dep.yaml
deployment "nginx" configured

선언문에서 객체를 삭제하려면 옵션--prune을 사용할 수도 있습니다.다음은 --prune의 동작 예입니다.삭제하려면 같은 탭(예: app=myapp)을 설정해야 합니다.

# 2 つのマニフェストがある
$ ls
myapp-api-dep.yaml myapp-web-dep.yaml

# ディレクトリ内の 2 つのマニフェストを適用
$ kubectl apply -f . --prune -l app=myapp
deployment "myapp-api" created
deployment "myapp-web" created

# myapp-api のマニフェストを削除
$ rm myapp-api-dep.yaml

# --prune が指定されているため削除したマニフェストに含まれる myapp-api が削除される
$ kubectl apply -f . --prune -l app=myapp
deployment "myapp-web" configured
# myapp-api が自動的に削除された
deployment "myapp-api" pruned

계산kubectl apply 패치

공식 문서How apply calculates differences and merges changes의 정보를 참고했다.
앞에서 설명한 대로kubectl apply 객체가 있는 경우 변경 사항을 계산하여 반영합니다.차이점을 계산하려면 다음 세 객체를 비교해야 합니다.
대상
설명
적용할 객체
적용할 목록의 객체 가져오기
현재 객체
클러스터에 있는 객체의 현재 상태
마지막으로 적용된 객체
클러스터 객체에 마지막으로 적용된 정보
마지막으로 적용된 객체는 다음과 같이 객체의 메모kubectl apply에 저장됩니다.

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  annotations:
    deployment.kubernetes.io/revision: "1"
    # 前回適用したオブジェクトはアノテーションに JSON 形式で保存されている
    kubectl.kubernetes.io/last-applied-configuration: |
      {"apiVersion":"extensions/v1beta1","kind":"Deployment" ....

이 세 객체를 비교하여 다음과 같이 패치를 작성합니다.

섹션의 계산을 삭제합니다.객체는 마지막으로 적용된 객체에 존재하고 적용된 객체에서 삭제된 필드입니다.

추가 및 변경 사항을 계산합니다.적용할 객체 및 현재 객체에 추가하거나 변경할 필드가 포함되어 있습니다.

kubectl.kubernetes.io/last-applied-configuration 내부에 이 패치를 작성하여 다음과 같은 패치를 보냅니다.패치를 적용할 때 Kubernetese 자체 병합 알고리즘Strategic Merge Patch을 사용합니다.

kubectl apply의 장점

현재 객체에 대한 정보(이 경우 복사본 수)가 동적으로 Horizontal Pod Autoscaling 으로 변경될 경우 이 차이 패치 작업의 이점이 있습니다.목록에 지정되지 않은 필드는 그대로 계승되기 때문에 예를 들어 복사본 수를 기재하지 않으면 kubectl apply 배치 정보가 업데이트된 경우 현재 대상 정보의 복사본 수를 그대로 계승합니다.

목록에서 복사본 수를 관리하지 않는 예

이것은 부본 수량 관리를 Horizontal Pod Autoscaler 또는 kubectl apply 에 전달할 수 있는 예시입니다. 부본의 수량을 배치에 열거하지 않기 때문입니다.

복사본 수를 지정하지 않고 deployent 적용

복사본 수는 기본값 1

복제 복제본 수를 4로 직접 변경

kubectl scale 업데이트

컨테이너 레이블 버전 업데이트, 목록 재적용

차이점은 표시된 버전에 불과합니다.복사본 수가 기재되어 있지 않기 때문에 차분으로 나타나지 않는다

복제 복제본 수는 4를 유지하고 레이블 버전만 업데이트

응용 프로그램이 주의해야 할 모드

kubectl은 지난번에 적용된 대상에 따라 삭제할 필드를 계산하기 때문에 설정된 필드를 삭제하면 기본값이 됩니다.
위의 복사본 수 예시에서 복사본 수를 먼저 지정하면 다음에 복사본 수를 삭제하고 응용 프로그램을 실행할 때 기본값(1)이 반환됩니다.

deployent를 만들기 위해 복사본 수를 2로 지정

복제 복제본 수를 4로 직접 변경

kubectl scale --replicas 4 deployment nginx 업데이트

복사본 수량 지정 삭제, 컨테이너 태그 버전 업데이트, 목록 재반영

복제본 수 삭제 및 레이블 업데이트 차이

복사본 수는 기본값 1

Strategic Merge Patch

kubectl apply의 패치 합병은 Kubernetes 자체의 합병 방법을 사용합니다Strategic Merge Patch.
Declarative Management of Kubernetes Objects Using Configuration Files 이 정식 문서에primitive,map,list 각자의 합병 방법이 적혀 있습니다. 상세한 상황은 여기를 보십시오.
한편, Strategic Merge Patch의 미세한 움직임에 대해 CoreOS의 Aaron Levy가 Kubecon 2017에서 발표한 kubectl apply, and The Dark Art of Declarative Object Management 관련 비디오 세션은 매우 통일적이다.list의 합병 방법은 대상의 Go의 구조체 라벨kubectl scale --replicas 4 deployment nginx에 따라 지정된 동작의 변화와 같은 상세한 운동을 소개했다.

총결산

kubectl은 덮어쓰는 것이 아니라 차분 반영입니다.차이점은 적용 객체, 현재 객체 및 마지막으로 적용된 객체 세 객체에서 계산됩니다.이 구조에 따라 복사본수 등 일부분은 선언적인 관리에서 벗어나 Horizontal Pod Autoscaler에 의뢰하여 유연하게 운용할 수 있다.