📌 kubectl apply 명령어의 내부 동작 방식

이 강의에서는 kubectl apply 명령이 선언형(declarative) 방식으로 객체를 관리할 때 내부적으로 어떻게 동작하는지 알아봄.

1. kubectl apply 명령의 기본 동작

• kubectl apply는 세 가지 요소를 비교·분석한 후 변경 사항을 반영:

  1. Local Configuration File
     • 우리가 로컬에서 작성한 객체 정의 YAML 파일.
  2. Live Object Configuration
     • 현재 Kubernetes 클러스터 내부 메모리에 저장된 "실제 객체 상태".
  3. Last Applied Configuration

     • 마지막으로 apply 명령이 실행되었을 때 사용한 객체 정의의 JSON 버전.

       (Kubernetes가 객체의 annotation에 저장)

• 객체가 존재하지 않으면 → 새로 생성

• 객체가 이미 존재하면 → 세 요소를 비교해 필요한 부분만 수정

2. 객체 생성 시 일어나는 일

• 우리가 로컬에서 만든 YAML 파일을 기반으로 Kubernetes가 객체를 생성.
• 생성된 객체에는 추가 필드(예: 상태 정보 status)가 포함되며, 이것이 Live Configuration.
• kubectl apply를 사용하면:
  • 로컬 YAML이 JSON으로 변환됨.
  • 변환된 JSON은 Last Applied Configuration으로 저장됨.
  • 저장 위치: Kubernetes 객체 내부의 annotation 필드 (last-applied-configuration).

3. 업데이트 시 비교 방식

• 이후에 객체를 수정하고 kubectl apply를 실행하면:
  • 로컬 파일 값 vs Live Configuration 값 비교
  • 변경이 있으면 Live Configuration 업데이트
  • Last Applied Configuration도 새 버전으로 갱신

4. 삭제된 필드 감지

• 예: 이전에는 label "type"이 있었는데, 로컬 파일에서 삭제한 경우

  • Last Applied에는 "type"이 존재

  • Local에는 "type"이 없음

    → 필드 삭제 요청으로 간주하여 Live Configuration에서 해당 필드 제거

• 반대로:

  • Live Configuration에는 있는데

  • Local과 Last Applied에 모두 없는 경우

    → 그대로 유지 (삭제 안 함)