kubectl apply로 리소스를 업데이트할 때 실제로 어떤 정보가 어떻게 바뀌는가?(apply, patch)

📌 kubectl apply로 리소스를 업데이트할 때 실제로 어떤 정보가 어떻게 바뀌는가?

kubectl apply는 사용자가 마지막으로 적용한 YAML의 내용을 쿠버네티스 리소스 메타데이터에 저장해두고, 클러스터 상태와 비교하여 변경된 부분만 반영하는 방식입니다.

📌 핵심 동작 원리

• apply는 리소스 메타데이터에 kubectl.kubernetes.io/last-applied-configuration 주석을 저장함
• 새로운 YAML이 들어오면 이 주석과 현재 클러스터 상태를 비교함
• 변경된 필드만 Kubernetes 리소스를 업데이트함

🔍 예시

kubectl apply -f deployment.yaml

spec:
  replicas: 3

만약 이전에 replicas: 2였다면, apply는 이 필드만 변경합니다.

✅ 요약

• 전체를 덮어쓰는 것이 아니라, 이전에 저장한 구성과 비교하여 변경된 필드만 업데이트
• kubectl create는 비교 없이 리소스를 새로 만들지만, apply는 상태 추적 기반으로 동작함

---

📌 이미 수동으로 수정한 리소스를 apply 하면 충돌이 생길 수 있는데, 그 해결법은?

kubectl apply는 이전에 적용했던 YAML을 기준으로 변경점을 계산합니다.
하지만 사용자가 kubectl edit이나 API로 직접 리소스를 수정하면 기준과 실제 상태가 달라져 충돌이 발생할 수 있습니다.

⚠️ 충돌 시나리오

• 사용자가 kubectl edit으로 직접 리소스를 변경
• 이후 기존 YAML을 apply하면, 수동 변경 사항이 덮어씌워짐

🔧 해결 방법

1. YAML 파일을 Git에서 관리하고 직접 수정하지 않기
2. kubectl apply view-last-applied로 마지막 적용된 구성 확인
3. 현재 상태를 기준으로 YAML 추출:

   kubectl get deployment nginx -o yaml > latest.yaml

4. 수동 변경 후엔 꼭 YAML도 반영해서 apply 해야 함

✅ 요약

• apply는 YAML 중심의 선언적 관리 방식이므로, 수동 변경은 위험
• 일관성을 위해 모든 변경을 YAML로 통합 관리해야 안전함

---

📌 kubectl patch는 apply와 어떤 차이가 있고, 언제 쓰면 좋을까?

kubectl patch는 전체 YAML이 아닌 일부 필드만 빠르게 수정하고 싶을 때 사용됩니다.

🔄 주요 차이점

항목	kubectl apply	kubectl patch
방식	선언적 (전체 YAML)	명령적 (필드 단일 변경)
추적 정보	last-applied 저장	없음
대상	전체 리소스 구조	특정 필드만 변경
사용 예	GitOps, 버전관리	긴급 설정 변경, 스크립트용

💡 patch 예시

kubectl patch deployment nginx -p '{"spec":{"replicas":2}}'

→ nginx 배포의 replica 수를 2로 변경

📌 언제 patch를 써야 하나?

• 간단한 값만 변경할 때 (replica, image, env 등)
• CI/CD 스크립트에서 빠르게 조정할 때
• 실시간 설정 반영이 필요할 때 (긴급 대응)

✅ 요약

• apply는 전체 YAML을 기준으로 상태를 관리하는 방식
• patch는 짧고 빠르게 한두 필드만 바꿔야 할 때 유용함