https://kubernetes.io/ko/docs/concepts/services-networking/endpoint-slices/

서비스가 대규모 백엔드를 처리할 수 있도록 확장시켜주고, 클러스터가 정상적인 백엔드 리스트를 효율적으로 업데이트 할 수 있도록 쿠버네티스가 사용하는 메커니즘이라는데... 알아보자.

EndpointSlice API

k8s에서 endpointSlice는 일련의 네트워크 엔드포인트에 대한 참조를 포함하고 있다. service에 셀렉터가 지정되면(즉 파드와 매칭되면) 컨트롤 플레인은 자동으로 EPS(endpointSllice, 이하 EPS)를 생성한다.

EPS는 서비스 셀렉터와 매치되는 모든 파드들을 포함하고 참조한다. 프로토콜, 포트번호, 서비스 이름의 고유 조합을 통해 네트워크 엔드포인트들을 그룹화함.

엔드포인트와의 비교

당연히 엔드포인트 슬라이스를 이해하려면 엔드포인트를(사용하지 않는 레거시더라도) 이해하고 있어야 한다. 그래야 왜 필요한지, 무엇을 제공하는지 이해할 수 있다.

• 엔드포인트는 API 오브젝트의 일종으로, 서비스가 실제로 트래픽을 보낼 pod의 IP/Port 목록을 담고 있다.
• 따라서 서비스 오브젝트와 1:1로 존재함. 서비스와 이름이 동일하게 생성된다.
• kube-controller-manager내의 Endpoint Controller는 Service와 매칭되는 pod를 찾아 해당 pod의 ip를 Endpoint에 자동생성 / 갱신하도록 되어있음.
• 문제는 해당 서비스의 모든 엔드포인트를 단일 서비스에 몰아넣었기 때문에 엔드포인트 수가 많아지면 오브젝트가 비대해지고, 새 변경사항이 자주 롤 아웃 될 경우 API서버와 kube-proxy의 부하가 증가한다는 점이었음.

그래서 k8s는 서비스와 엔드포인트 사이에 엔드포인트슬라이스를 도입했다. 엔드포인트슬라이스는 쉽게 말해 엔드포인트를 여러 부분으로 나눠 서비스에 붙여둔 것. 대규모 구조에서 변경사항 발생 시 더 작은 단위로 변동을 전파해 부하를 더 줄이는게 목적이다.

슬라이스는 기본적으로 100개 단위로 잘려 생성된다. kube-controller-manger의 설정에 따라 최대 1000개까지 구성가능.