지난 주에 진행했던 devops 스터디에서 오늘의 TMI로 kubectl apply가 kubectl create보다 똑똑하게 동작하는 이유에 대해 조사해보았다.
yaml 파일에 리소스를 정의하고 kubectl create -f {파일명} 명령어로 리소스를 생성한 다음, yaml 파일의 일부 스펙을 수정하고 다시 kubectl create -f {파일명} 명령어를 실행하면 이미 리소스가 존재한다는 ERROR가 발생하는 것을 확인할 수 있다.
반면에, 위와 동일한 상황에서 kubectl apply -f {파일명} 명령어를 사용할 경우, ERROR가 발생하지 않으며 변경된 파일 내용에 따라 리소스의 스펙이 변경된다.
이처럼 kubectl apply 명령어는 생성, 업데이트, 그리고 삭제 작업은 kubectl에 의해 오브젝트마다 자동으로 감지된다.
kubectl apply 명령어는 어떻게 kubectl create 명령어와 다르게 이미 존재하는 리소스를 인지하고 변경된 내용에 맞춰 리소스의 스펙을 변경해주는 걸까? 🧐
kubectl apply 커맨드는 구성 파일, 활성 구성(Live Object Configuration), 그리고 활성 구성(Live Object Configuration)에 저장된 last-applied-configuration어노테이션을 사용하여 이 패치 요청을 계산한다.
먼저, kubectl apply명령은 kubectl.kubernetes.io/last-applied-configuration
어노테이션에 구성 파일의 내용을 기록한다. 이것은 구성 파일로부터 제거되었고 활성 구성으로부터 지워질 필요가 있는 필드를 확인하는 데 사용된다.
그 다음, last-applied-configuration 와 yaml 구성 파일의 비교를 통해서 추가 또는 삭제해야 하는 필드를 계산한다. 계산한 것을 토대로 전체 필드를 교체하는 대신, 개별 하위 구성요소를 업데이트한다. 구성 파일의 값과 일치시키기 위해 last-applied-configuration 어노테이션을 설정하고 결과를 API 서버에 단일 패치 요청으로 병합한다.
[참고자료]
https://kubernetes.io/docs/tasks/manage-kubernetes-objects/declarative-config/
https://seongjin.me/kubernetes-imparative-vs-declarative/
