Node to Control Plane

여기에는 hub-and-spoke 라는 API 패턴이 사용된다. 노드(또는 그 내부의 파드들)의 모든 API 사용은 API 서버에서 종결된다. 다른 컨트롤 플래인 컴포넌트 중 어느 것도 원격 서비스가 노출되어서 노드와 연결되지 않는다.

💡 hub-and-spoke는 물류에서 자주 쓰이는 용어로 아래와 같은 시스템을 생각하면 된다.

반대되는 토폴로지는 point to point. 각 노드가 서로 다 연결되어있음. (네트워크)

API서버는 https 형식으로 원격 연결을 수신하도록 구성되어있다. 노드는 유효한 클라이언트임을 자격증명함과 동시에 클러스터에 대한 공개 루트 인증서로 프로비저닝 되어있어야 함. 클라이언트 인증서 형식으로 kubelet의 클라이언트 자격증명을 보통 사용한다. 관련 자동 프로비저닝은 여기를 참고 https://kubernetes.io/docs/reference/access-authn-authz/kubelet-tls-bootstrapping/

Control Plane to Node

두 가지 기본 통신 경로가 있다. 하나는 각 노드에서 실행되는 kubelet 프로세스를 통하는 것과, 두번째는 API서버의 프록시 기능을 통해 API 서버에서 모든 노드, 파드 또는 서비스에 이르는 것.

APIserver to kubelet

다음의 용도로 사용된다. → 파드에 대한 로그를 가져오기, 실행중인 파드에 연결하기, kubelet에 포트포워딩 제공하기

위와같은 연결은 보통 kubelet의 https 엔드포인트에서 종결됨. API 서버는 통신간 kubelet의 serving 인증서를 확인하지 않음. 때문에 신뢰할 수 없는 공용 네트워크 상에서는 안전하지 않을 수 있다.

안전하게 만드려면 , --kubelet-certificate-authority 플래그를 사용하여 API 서버에 kubelet의 제공(serving) 인증서를 확인하는데 사용할 루트 인증서 번들을 제공하거나,

이것이 가능하지 않은 경우 API 서버와 kubelet 간 SSH 터널링을 사용한다.

마지막으로, kubelet API를 보호하려면 kubelet 인증/인가를 활성화해야 한다.