서비스의 다양한 측면들

쿠버네티스 서비스 리소스는 사람들이 흔히 인식하는 것보다 훨씬 복잡하다. 서비스를 생성할 때 일반적으로 클러스터 머신은 다음을 수행한다.

• 서비스 자체에 대한 클러스터 전역 IP 주소를 할당한다(클러스터 IP).
• 클러스터 IP로 해석되는 서비스용 DNS 이름을 할당한다(DNS 이름).
• 서비스의 셀렉터에 의해 선택된 각 파드에 할당된 개별 클러스터 전역 IP 주소(엔드포인트 IP들)를 수집하여 서비스의 Endpoints 또는 EndpointSlices에 포함시킨다.
• 클러스터 IP로의 트래픽이 모든 엔드포인트 IP에 걸쳐 로드 밸런싱되도록 네트워크를 구성한다.

불행히도 이러한 구현 세부사항들은 게이트웨이 API가 서비스 메시에서 어떻게 작동할 수 있는지를 고려할 때 매우 중요해진다!

GAMMA 이니셔티브 작업에서는 서비스를 두 개의 별도 측면 으로 구성된 것으로 간주하는 것이 유용하다는 것을 알게 되었다.

• 서비스의 프론트엔드는 클러스터 IP와 DNS 이름의 조합이다.

• 서비스의 백엔드는 엔드포인트 IP들의 집합이다. (파드들은 서비스 백엔드의 일부가 아니지만, 물론 엔드포인트 IP들과 강하게 연관되어 있다.)

측면 간의 구분이 중요한 이유는 게이트웨이와 메시 각각이 주어진 서비스를 언급하는 요청을 서비스의 프론트엔드로 보낼지 백엔드로 보낼지 결정해야 하기 때문이다.

• 요청을 서비스의 프론트엔드로 보내는 것(서비스 라우팅)은 어떤 엔드포인트 IP를 사용할지에 대한 결정을 기반 네트워크 인프라(kube-proxy, 서비스 메시, 또는 다른 것일 수 있음)에 맡긴다.

• 요청을 서비스의 백엔드로 보내는 것(엔드포인트 라우팅)은 보다 고급 로드 밸런싱 결정을 가능하게 하기 위해 종종 필요하다 (예를 들어, 스티키 세션을 구현하는 게이트웨이).

서비스 라우팅이 Ana의 라우팅 개념에 가장 직접적으로 맞을 수 있지만, 북/남과 동/서 트래픽 모두에 게이트웨이 API를 사용할 때는 엔드포인트 라우팅이 더 예측 가능할 수 있다. GAMMA 이니셔티브는 이 사용 사례에 대한 지침을 공식화하는 작업을 진행하고 있다.