서비스, 로드밸런싱, 네트워킹

쿠버네티스 네트워크 모델

모든 파드는 고유한 IP 주소를 갖는다. 이는 즉 파드간 연결을 명시적으로 만들 필요가 없으며 또한 컨테이너 포트를 호스트 포트에 매핑할 필요가 거의 없음을 의미한다. 이로 인해 포트 할당, 네이밍, 서비스 디스커버리, 로드 밸런싱, 애플리케이션 구성, 마이그레이션 관점에서 파드를 VM 또는 물리 호스트처럼 다룰 수 있는 깔끔하고 하위 호환성을 갖는 모델이 제시된다.

쿠버네티스는 모든 네트워킹 구현에 대해 다음과 같은 근본적인 요구사항을 만족할 것을 요구한다 (이로 인해 모든 의도적인 네트워크 분할 정책이 방지된다)

• 노드 상의 파드가 NAT 없이 모든 노드의 모든 파드와 통신할 수 있다
• 노드 상의 에이전트(예: 시스템 데몬, kubelet)가 해당 노드의 모든 파드와 통신할 수 있다

참고: 파드를 호스트 네트워크에서 구동하는 것도 지원하는 플랫폼(예: 리눅스)에 대해서는 다음의 요구사항도 존재한다.

• 한 노드의 호스트 네트워크에 있는 파드는 NAT 없이 모든 노드의 모든 파드와 통신할 수 있다

이 모델은 전반적으로 덜 복잡할 뿐만 아니라, 무엇보다도 VM에 있던 앱을 컨테이너로 손쉽게 포팅하려는 쿠버네티스 요구사항을 만족시킬 수 있다. 작업을 기존에는 VM에서 실행했었다면, VM은 IP주소를 가지며 프로젝트 내의 다른 VM과 통신할 수 있었을 것이다. 이는 동일한 기본 모델이다.

쿠버네티스 IP 주소는 파드 범주에 존재하며, 파드 내의 컨테이너들은 IP 주소, MAC 주소를 포함하는 네트워크 네임스페이스를 공유한다. 이는 곧 파드 내의 컨테이너들이 각자의 포트에 localhost로 접근할 수 있음을 의미한다. 또한 파드 내의 컨테이너들이 포트 사용에 있어 서로 협조해야 하는데, 이는 VM 내 프로세스 간에도 마찬가지이다. 이러한 모델은 "파드 별 IP" 모델로 불린다.

이것이 어떻게 구현되는지는 사용하는 컨테이너 런타임의 상세사항이다.

노드 자체의 포트를 파드로 포워드하도록 요청하는 것도 가능하지만(호스트 포트라고 불림), 이는 매우 비주류적인(niche) 동작이다. 포워딩이 어떻게 구현되는지도 컨테이너 런타임의 상세사항이다. 파드 자체는 호스트 포트 존재 유무를 인지할 수 없다.

쿠버네티스 네트워킹은 다음의 네 가지 문제를 해결한다.

• 파드 내의 컨테이너는 루프백(loopback)을 통한 네트워킹을 사용하여 통신한다.
• 클러스터 네트워킹은 서로 다른 파드 간의 통신을 제공한다.
• 서비스 리소스를 사용하면 파드에서 실행 중인 애플리케이션을 클러스터 외부에서 접근할 수 있다.
• 또한 서비스를 사용하여 서비스를 클러스터 내부에서만 사용할 수 있도록 게시할 수 있다.