kubelet과 API 서버 사이의 동작방식

안녕하세요 

kubelet은 서비스 데몬 형태이기 때문에 위와 같이 얘기한 게 맞습니다만...

API 서버는 쿠버네티스의 구성 요소에 맞게 선언적인 방식입니다. 

(다른 구성 요소에 비해서 더 많은 일들을 하지만요)

그리고 kubelet에 문제가 있으면 해당 노드에 문제가 생기는 것은 맞으나, 그걸 쿠버네티스와 같은 클러스터 시스템에서 전체라고 표현하기는...주어에 따라 좀 다를 것 같습니다.  

앞선 쿠버네티스 구조 부분에서는 강사님께서 kubelet이 API 서버가 선언한 부분을 읽어서 컨테이너 런타임에게 컨테이너를 만들어주라고 명령하는 방식으로 파드가 생성된다고 하셔서 kubelet과 API 서버 사이의 동작방식에 대해 약간 헷갈려서 질문 드립니다!

또한 위와 같이 혼동이 생기신 것은..

1차적으로는 kubelet이 API 서버는 직접 연결을 시도하지 않는 구조입니다. 선언적으로 하기 위해서는 누군가는 선언을 하고 이를 관리해야 하는데, 해당 역할이 API 서버입니다.  

이 부분은 쿠버네티스의 기본 철학의 파드가 배포되면? (파드 라이프 사이클)을 보고 다시 정리하시는게 좋으실꺼 같습니다. 

kubelet이 API 서버가 선언적인 방식으로 동작하지 않는 것이 맞는지, 맞다면 둘 사이에서는 어떤 방식으로 동작하는 것인지 궁금합니다!

이 부분도 쿠버네티스의 기본 철학의 파드가 배포되면? (파드 라이프 사이클)을 보시는게 나으실꺼 같습니다. API가 선언한 것을 주기적으로 kubelet이 watch 하는 구조입니다. 아마도 watch가 먼저 들어가는 부분이 혼동이 있었을 수 있는데, kubelet도 다른 구성 요소처럼 API 서버에 선언되어 있는 것을 보고 파드를 올릴지 말지를 결정합니다. 다만 여기서 복잡성이 있는 부분은 중복해서 파드를 올리지 않게 하기 위해서 내부적으로 노드 같은 경쟁(race)를 방지해야 하는 것이 필요하긴 합니다. 

어쨌든 쉽게 설명하자면 kubelet도 선언적에 가깝게 API 서버를 바라봅니다. 

한가지 제안이 있는데, 지금 내용을 이해하고 해석하시려는 것은 매우 좋은데, 다른 분과 함께 의논해 가면서 정리하시면 아마 학습 효과가 더 올라가실 것 같습니다. 

왜냐면 나의 생각을 정리하고 다른 사람과 나누고 설명하는 과정에서 다시 정리가 되거든요. 

이에 가능하시다면, 내가 이해한게 맞나? 라는 질문도 좋지만 스터디 그룹을 만들고 이를 활용해 보시는 것도 추천드리고 싶네요. 

어짜피 쿠버는...가볍게 보기에는 한없이 가볍지만 무겁게 보려면 꽤 무거운거라서요. 

필요하신 내용이라면 참고하시기 바랍니다. 

좀 더 구체적으로 알고 싶으시다면, 아래의 라이프 사이클을 참고하시는 것도 좋으실 것 같습니다. 

https://dzone.com/articles/kubernetes-lifecycle-of-a-pod

https://velog.io/@idnnbi/Kubernetes-lifecycle-of-pod