Inflearn brand logo image

인프런 커뮤니티 질문&답변

odark님의 프로필 이미지
odark

작성한 질문수

쿠버네티스 어나더 클래스-Sprint4 (#Promethues #Grafana #Loki #OpenTelemetry)

📝 순차적 버전 업그레이드 - In-Place방식 (💻 실습)

server-side옵션에 대해 궁금합니다.

작성

·

32

1

annotations:  

         kubectl.kubernetes.io/last-applied-configuration 부분을 kubectl에서  내용을 업데이트해준다 .kubernetes에서 알아서 내용들을 업데이트 해준게 아니라.

         클라이언트가 동시에 리소스에 수정하게 될때 충돌을 관리하는데 유리하다.  그래서 server-side옵션을 주면 서버가 주도해서 이 리소스에 대한 모든 

         내용을  수정관리 해주기 때문에 리소스에 대한 충돌이 일어나지 않는다. . 모든 리소스가 이렇게 server-side로 관리하면 kubernetes가 부담되기 때문에

         클라이언트가 이런내용들은 알아서 계산해서 저장 할때 같이 반영한다.

이렇게 말씀하셨는데요...
저 annotation부분의 내용은 실제 아래 리소스 yaml내용을 반영을 했다 client가~~~ 이런의미인가요?
근데 저렇게 annotation 바로 밑에

kubectl.kubernetes.io/last-applied-configuration 항목에 저 내용들이 들어간들 무슨 의미가 있는지 궁금해요..실제 필요한건..그밑에 name,namespace 나 spec 이하부분들이 중요한거 아닌가요?

거기에 추가로 server-side로 하면 client다른 수정과 충돌을 피한다고 했는데
실무에서 운영인데 함부로 누가 같은 리소스를 따로 공유도 없이 수정할려고 들까요? 그런 상황이 있을리 만무하지 않나싶어요...

그래서 결론은 client에서 누군가 수정을 동일리소스에 할거 같아서 server-side옵션을 주는건 발생하기 희박할거 같단 생각이 들고.

그리고 yaml안에 last-applied-configuration이라 내용의 쓰임이...단순이 그냥 정보성정도아닌가 여쭤봅니다. 저 값들로 뭔가 하지않을것 같아서요

답변 1

0

일프로님의 프로필 이미지
일프로
지식공유자

kubectl apply는 기존 리소스와 현재 리소스를 비교하고, 바뀐 부분만 patch를 생성해서 적용합니다.

이때 필요한 기준이 바로 이 last-applied-configuration입니다. 그렇기 때문에 last-applied-configuration는 사용자를 위한 용도라기 보단 시스템 적으로 충돌을 피하고 변경 사항을 반영하기 위한 내용이라고 보시면 됩니다.

 

그리고 말씀하신 대로 일반적인 팀 내 협업이나 운영 환경에서는 리소스를 동시에 수정할 일이 많지 않을 수 있습니다. 하지만 배포 자동화를 시켜놨을 경우 GitOps 도구 (ArgoCD, Flux) 등 다양한 컨트롤러가 리소스를 수정할 수 있습니다. 또한 앞에서 배운 CRD(Custom Resource Definition)등를 썼을 때 필드가 복잡하고, 누가 뭘 수정했는지 구분이 어려워 지기도 합니다. 그래서 실제 그렇게 복잡한 패키지의 경우 server-side apply가 유리하고, 배포 가이드에서 server-side 옵션을 써서 배포하라는 경우를 많이 볼 수 있습니다.

 

 

odark님의 프로필 이미지
odark

작성한 질문수

질문하기