[Kubernetes] Core Concepts 2 ( kubelet ,Kube Proxy)

1.Kubelet 

kubelet은 각 노드에 설치된  에이전트로써 kubernetes안에 구성된 node위에서 실행되는 container들이 pod내의 실행되는걸 관리하는 역할을 한다.  하지만 노드안에 있는 container라고 하더라도 kubernetes를 통해서 생성되지 않은 container들은 관리하지 않는다 . 

kubelet에서 주의할 점은 우리가 kubernetes 를 구축할때 사용하는 bootstarp 솔루션 (kubeadm등) 에서 따로 설치를 해주지 않기에

항상 버전에 주의해야합니다. kubelet 은 kubeadm에서 설치하는 api server의 버전과 호환되어야하는데 예를 들면 아래와 같은 지원하는 버전 규칙이 있으며 

 

kubelet은 kube-apiserver보다 최신일 수 없으며, 2단계의 낮은 마이너 버전까지 지원한다.

예:

• kube-apiserver가 1.23 이다.
• kubelet은 1.23, 1.22 및 1.21 을 지원한다.

자세한 내용은 공식 document는 https://kubernetes.io/ko/releases/version-skew-policy/ 에서 확인 할 수 있다.

버전 차이(skew) 정책

2. Kube Proxy 

일단 기본적으로 우리는 Web application 서버에서 분리된 database 서버에 접근할때  ip 를 이용해 접근한다 . 

하지만 kubernetes 에서 service 로써 database를 사용할 때는 해당 service는 가상ip 를 부여받고 이 가상 ip 는 1년전이고 한달 전이고 하루전이고 매번 같은 IP를 쓴다는 보장 자체가 없다 . 

 

게다가 이 가상 ip 는 kubernetes 의 virtual component로 씰제로는 존재하지 않으며 오직 kubernetes 위의 memory에 정의 된 것이기 때문이다. ( kubernetes는 사실 실제 ip주소가 있고 각 pods 는 이 가상 ip 를 통해서 다른 pods들과 통신) 

아래와 같이 같은 서비스에 묶여 10.96.0.12 의 ip 를 가지더라도 해당 ip 를 바라보는 2대의 pods (각각 10.32.0.14, 10.32.0.15)는 실제 ip를 가지고 있으며 

출저  https://www.udemy.com/course/certified-kubernetes-administrator-with-practice-tests/learn/lecture/14298434#overview

이때 kube-proxy는 각노드에서 실행되는 process로  각 service의 대한 트래픽 전달을 위한 iptable 전달 규칙을 각노드에 생성하는 역할을 한다.

 

이부분이 매우..매우매우어렵다. 사실 개발하면서 에러 고치다가 머리뜯은 부분은 전부 이 pods ip 에 통신하는데 time out , connection refuse 나는 경우였다...

 

요약하자면 가상 ip 로도 실제 ip 를 찾아갈 수 있게 규칙 (iptables rules)를 지정하는 컴포넌트라고 알아두자.