CiliumEndpointSlice

CiliumEndpointSlice (CES)

CiliumEndpointSlice(CES)는 클러스터의 CiliumEndpoint(CEP) 객체를 배치로 묶어 더 나은 확장성을 얻는 기능이에요. Cilium Operator가 CEP를 그룹화해 CES로 만들어 API-server 부하를 줄여줘요.

출처: CiliumEndpointSlice

본문

Note 이 기능은 베타 단계예요. 문제가 발생하면 피드백을 주고 GitHub issue를 제출해 주세요. 이 기능을 "Stable"로 승격시키기 위해 필요한 작업은 GitHub issue 31904에 정리되어 있어요.

이 문서는 클러스터의 CiliumEndpoint(CEP) 객체를 배치로 묶어 더 나은 확장성을 얻을 수 있게 하는 CiliumEndpointSlices(CES)를 설명해요.

활성화하면 Cilium Operator가 CEP 객체를 관찰하고, 그 slim 버전을 그룹화/배치해서 CES 객체로 만들어요. 이 모드에서 Cilium Agent는 원격 엔드포인트를 알기 위해 CES 객체를 관찰해요. 이 경우 원격 엔드포인트 정보 전파로 인한 API-server 부하가 줄어 확장성이 좋아지는 대신, 새 엔드포인트의 identity가 클러스터 전체에서 인식되기까지 지연이 더 길어질 수 있어요.

Note CiliumEndpointSlice는 Cilium 고유의 개념으로 Kubernetes의 EndpointSlice와는 관련이 없어요. 이름이 비슷하고 각 기능의 slice 개념이 유사한 확장성 개선을 가져다주지만, 이 둘은 서로 다른 문제를 해결해요. Kubernetes의 Endpoints와 EndpointSlices는 Cilium이 특정 Service 객체에 대한 로드 밸런싱 결정을 내릴 수 있게 해주며, Kubernetes EndpointSlices는 클러스터 내 Service 백엔드를 확장 가능한 방식으로 추적하는 방법을 제공해요. 반면 CiliumEndpoints와 CiliumEndpointSlices는 네트워크 라우팅과 정책 결정을 내리는 데 사용돼요. 따라서 CiliumEndpointSlices는 파드 추적에 초점을 맞추며, 대규모 클러스터에서 API-server를 통해 전파할 업데이트 수를 줄이기 위해 CEP를 배치로 묶어요. 하나를 활성화한다고 다른 하나에 영향을 주지는 않아요.

CES로 Cilium 배포 (Deploy Cilium with CES)

CES는 기본적으로 비활성화되어 있어요. 이 섹션은 활성화하기 위해 필요한 단계를 설명해요.

사전 요구 사항 (Pre-Requisites)

  • CEP가 활성화되어 있는지 확인하세요 (--disable-endpoint-crd 플래그가 true로 설정되어 있지 않은지).
  • CES와 호환되지 않는 Egress Gateway에 의존하지 않는지 확인하세요 (Egress Gateway 다른 기능과의 비호환성 참고).

마이그레이션 절차 (Migration Procedure)

엔드포인트 전파 지연을 최소화하려면 Operator를 먼저 업그레이드하고, 모든 CES 객체를 만들게 한 다음, Agent들을 나중에 업그레이드하는 것이 좋아요.

  1. Helm 차트에서 ciliumEndpointSlice.enabled 값을 true로 설정하거나 Operator에서 --enable-cilium-endpoint-slice 플래그를 true로 설정해 Operator에서 CES를 활성화하세요. Operator를 재배포하세요.

  2. Operator가 실행 중이면 CiliumEndpointSlice CRD가 성공적으로 등록됐는지 확인하세요:

    $ kubectl get crd ciliumendpointslices.cilium.io
NAME                                         CREATED AT
ciliumendpointslices.cilium.io               2021-11-05T05:41:28Z

  3. Operator가 CES 객체 생성을 시작했는지 확인하세요:

    $ kubectl get ces
NAME                  AGE
ces-2fvynpvzn-4ncg9   1m17s
ces-2jyqj8pfl-tdfm8   1m20s

  4. Operator가 클러스터의 모든 기존 CEP에 대해 CES 객체를 만들도록 하세요. 이는 클러스터 크기에 따라 시간이 걸릴 수 있어요. 클러스터의 CES 객체 생성 속도를 확인해 진행 상황을 모니터링할 수 있어요. 예를 들어 apiserver_storage_objects Kubernetes 메트릭을 보거나 Kubernetes Audit Logs에서 ciliumendpointslices 리소스 생성 요청을 확인하면 돼요. 또한 Operator가 내보내는 cilium_operator_ces_sync_total 같은 메트릭을 모니터링할 수도 있어요. 모든 CES 관련 메트릭은 메트릭 문서의 CiliumEndpointSlices (CES) 섹션에 문서화되어 있어요.

  5. 메트릭이 안정화되면(즉, Operator가 모든 기존 CEP에 대한 CES 객체를 만들었으면) 모든 노드에서 --enable-cilium-endpoint-slice 플래그를 true로 설정하고 재배포해 Cilium Agent를 업그레이드하세요.

다운그레이드 절차 (Downgrade Procedure)

연결성 중단을 피하려면, CES를 비활성화하고 CEP로 돌아가야 한다면 먼저 Cilium Agent에서 CES를 비활성화해 agent가 CEP를 다시 관찰하도록 해야 해요. --enable-cilium-endpoint-slice 플래그를 false로 설정하고 agent를 재배포하면 돼요. 그런 다음 모든 agent가 업데이트되면 operator에서 CES를 비활성화하면 새 CES 객체 생성을 중단하고 기존 객체를 삭제해요.

구성 옵션 (Configuration Options)

CES 기능의 성능과 동작을 조정할 수 있는 여러 옵션이 있어요:

  • 하나의 CES에 포함될 CEP 최대 수를 바꿔 CEP가 CES로 배치되는 방식을 구성할 수 있어요 (--ces-max-cilium-endpoints-per-ces).
  • Operator와 API-server 통신에 대한 rate-limiting 설정을 세밀하게 조정할 수도 있어요. cilium-operator 바이너리의 --ces-* 플래그를 참고하세요.
  • 네임스페이스에 cilium.io/ces-namespace 어노테이션을 "priority" 값으로 설정하면 우선순위 네임스페이스로 지정할 수 있어요. 대규모 클러스터에서는 Network Policy 업데이트 중 변경 전파가 크게 지연될 수 있어요. 네임스페이스의 cilium.io/ces-namespace 어노테이션이 "priority"로 설정되면, 이 네임스페이스의 업데이트가 우선순위가 아닌 업데이트보다 먼저 처리돼요. 이를 통해 중요한 네임스페이스에서 업데이트된 네트워크 정책을 더 빠르게 적용할 수 있어요.

더 알아보기 (Learn more)