cilium 1.18.0 달라진점 정리

1.18.0이 릴리즈 되었는데 좀 관심가는 변경점이 생겨서 정리해보려고 한다.

 

iptablesRandomFully

서로 다른 파드(네트워크 네임스페이스)에서 쿠버네티스 밖에 있는 동일한 목적지로 연결을 하면 내부적으로 연결에 필요한 튜플이 겹쳐서 충돌할 수 있습니다. 아무래도 외부로 나가는 과정에서 nat가 되는데 같은 포트를 사용하게 되면 충돌이 나게 되기 때문입니다. 

 

 

 

커널이 출발지 포트를 자동으로 할당할 때, 커넥션을 만들기 전에는 어떤 포트가 사용중인지 알 수 없어서 비슷한 시기에 커넥션을 생성하면 동일한 포트를 사용하게 될 가능성이 있습니다. 

특히 UDP나 short-lived TCP 요청에서 더 자주 발생한다고 합니다. 

 

이번에 변경된건 --random-fully을 사용하게 되는건데 추가를 하게 되면 출발지 IP/포트 모두를 완전 무작위로 정해서 중복 확률을 훨씬 줄인다고 합니다. 기본 동작은 포트를 순차적 or 로컬 기준으로 랜덤하게 고릅니다.

 

 

k8sClientExponentialBackoff

Cilium 에이전트에서 사용하는 client-go 라이브러리에 대해 지수 백오프 설정을 구성할 수 있게 됩니다. 

최근 쿠버네티스 api서버 연결에 문제가 발생했던 적이 있습니다. 이때 컨트롤러들이 api 연결을 하기 위해 계속 해서 요청을 보내고 api서버의 메모리가 많이 올라서 oom이 지속적으로 발생했는데 이런 문제를 피하기 위한 설정입니다.

 

(참고 쿠버네티스 API 서버의 메모리 사용량이 높아지는것을 막기 위해 최근 버전에선 변경사항이 있었다고 합니다)

https://kubernetes.io/blog/2024/12/17/kube-apiserver-api-streaming/

Enhancing Kubernetes API Server Efficiency with API Streaming

 

bbrHostNamespaceOnly

2024.10.27 - [CS/network] - BBR(Bottleneck Bandwidth and RTT) 혼잡 제어 알고리즘

BBR(Bottleneck Bandwidth and RTT) 혼잡 제어 알고리즘

이전에 BBR 알고리즘에 대해서는 정리를 했었는데 사실 cilium에서도 이 기능을 제공합니다. cilium팀은 bbr 알고리즘 사용 및 커널 수정을 통해 나가는 트래픽의 성능개선을 했는데 legacy host routing (netfilter를 통해 라우팅을 하는 경우) host 네임스페이스를 사용하는 파드는 이 기능을 사용할 수 없었다고 합니다. 

legacy host routing에서는 파드 네트워크 네임스페이스에서 호스트 네트워크 네임스페이스로 패킷이 넘겨지는데 이 과정에서 소켓 연결 정보가 깨지게 되어 sk_pacing_rate라는 속도 제어 계산에 필요한 값이 사라지기 때문입니다. 

 

좀더 쉽게 정리해보기

https://isovalent.com/blog/post/accelerate-network-performance-with-cilium-bbr/

Accelerate network performance with Cilium BBR

• Pod 안에서 커넥션을 만듦 → 소켓은 Pod 네임스페이스 내부에 있음
• 패킷이 호스트로 넘어오면 → 커널은 호스트 네임스페이스 기준으로 처리하려고 함
• 이때 커널 입장에선:
  • "이 패킷은 내 소켓 목록에 없는데?"
  • → 소켓 연결을 못 찾음 or 끊음
  • → skb->sk = NULL

 

하지만 이번 1.18버전에서는 host 네트워크 넴스페이스에서는 사용가능하다고 합니다. 애초에 ebpf host routing 기능을 쓰는 사람은 상관없을 것 같습니다. 

 

 

identityManagementMode

Cilium에서는 identity 를 기반으로 네트워크 정책을 적용합니다. 이 identity는 Cilium 에이전트(Cilium Agent)  통해 생성이 됩니다.  1.18에서는 Cilium Operator에서도 생성이 되게 변경이 되었습니다. Identity는 파드에 있는 라벨 세트(Label Set)의 hash값을 id로 사용하는 것입니다. 라벨을 문자로 ebpf Map에 넣게 되면 메모리 사용량이 커지게 되기 때문입니다.

예) {"app": "frontend", "env": "prod"} → CID 12345

 

하지만 Agent에서 생성하게 되면 서로 다른 노드에 떠있는 같은 라벨을 갖은 파드에 대해 서로 ID를 생성하게 될 수 있어 중복 CID(Cilium Identity) 문제가 발생하게 됩니다. 그래서 Operator에서 생성하게 되면 중앙에서 관리하게 되기 때문에 이러한 문제가 줄어듭니다. 

 

Cilium Operator가 ID를 관리하도록 설정하면, ID 생성이 중앙 집중화됩니다. 이 방식은 동일한 라벨 세트를 기반으로 여러 에이전트가 동시에 ID를 생성할 때 발생할 수 있는 CID 중복 문제를 줄이는 데 도움이 됩니다. 클러스터에서 사용할 수 있는 ID 수와 eBPF 정책 맵 크기(eBPF Maps 참조)에는 제한이 있으므로, Operator가 ID를 관리하게 하면 네트워크 정책의 안정성과 클러스터의 확장성을 향상시킬 수 있습니다.

Cilium에서 **CID (Cilium Identity)**는 라벨(Label) 기반 보안 정책을 효율적으로 구현하기 위해 생성되는 고유 ID입니다.

 

Multiple Egress Gateways

cilium에서는 egress gateway 기능을 지원합니다. 1.18 이전에는 노드를 라벨로 선택하여 인터페이스 명을 지정하거나 IP를 지정해서 egressgateway를 선택할 수 있었습니다. 

1.18 부터는 여러 egress gateway 노드를 선택할 수 있게 되었습니다. 기존에는 여러 노드를 선택할 수 있지만 노드별로 다른 인터페이스 이름을 사용한다면 여러 egress gateway policy를 작성해야했어 번거로움이 있었습니다. 이제는 하나의 정책으로도 round-robin으로 여러 노드를 선택할 수 있게 됩니다. 

 

 

Policy Names in Hubble-CLI

기존에는 hubble observe 명령어로 트래픽 흐름을 확인할 때 어떤 네트워크 정책(CiliumNetworkPolicy or CiliumClusterwideNetworkPolicy)이 해당 트래픽을 허용/차단했는지 알수 없었습니다. 1.18.0 이후부터는 --print-policy-names 옵션을 사용해서 어떤 정책에 의해 트래픽이 차단된것인지 확인할 수 있습니다. 

 

API Server Connections at Scale

 

여러 API 서버로 설정 가능 

Cilium을 kube-proxy replacement 모드로 사용하는 경우, 클러스터의 네트워크 제어는 Cilium 에이전트가 직접 수행하게 됩니다. 이때 중요한 점은, 에이전트가 kube-apiserver와 직접 통신해야만 BPF 경로를 설정할 수 있다는 것입니다.

하지만 이 구조는 기존에 고가용성(HA) 환경에서는 한계가 있었습니다.

 

그동안 Cilium은 하나의 API 서버 주소만 받을 수 있었습니다. API_SERVER_IP와 API_SERVER_PORT를 설정하면, 에이전트는 해당 주소로만 kube-apiserver에 연결을 시도합니다.

 

이 방식은 소규모 테스트 환경에서는 잘 작동하지만, 실제 운영 환경에서는 다음과 같은 문제가 발생할 수 있습니다

• 하나의 kube-apiserver에 장애가 생기면 Cilium 에이전트는 복구되지 않음
• 클라우드 환경에서 노드가 교체되거나, IP가 변경되면 사전에 설정한 고정 주소는 무용지물
• Cilium 에이전트가 kube-apiserver와 연결되지 않으면, BPF 맵을 구성하지 못해 네트워크 기능이 중단됨

결과적으로, 운영자가 수동으로 문제를 진단하고 조치해야 하는 상황이 자주 발생했습니다.

 

이제 Cilium v1.18부터는 이러한 문제를 해결하기 위해 여러 kube-apiserver 주소를 동시에 설정할 수 있는 기능이 도입되었습니다.

--set k8s.apiServerURLs=https://api1.example.com,https://api2.example.com,https://api3.example.com

 

에이전트는 초기 시작 시 이 리스트를 순회하면서 응답 가능한 활성 API 서버에 자동 연결하며, 연결 중 문제가 생기면 클러스터 내부의 Kubernetes 서비스(ClusterIP)를 fallback 경로로 사용하게 됩니다.

 

또한, 에이전트를 재시작하더라도 이 동작은 그대로 유지되며, 운영자가 별도로 복구 작업을 하지 않아도 됩니다.

 

네임스페이스의 라벨 변경시 API서버에 부하 발생

Cilium은 네트워크 정책을 적용하기 위해 각 Pod의 라벨을 기반으로 CiliumIdentity라는 객체를 생성합니다. 이 Identity는 라벨 조합이 달라질 때마다 새로 생성되며, 이를 통해 eBPF 정책이 정확하게 적용됩니다. 문제는 네임스페이스 라벨도 CiliumIdentity에 영향을 준다는 점입니다.

 

문제 발생 시나리오

• 사용자가 네임스페이스 라벨을 하나 바꿉니다.
• 이 네임스페이스에 속한 모든 Pod의 Identity가 다시 계산됩니다.
• 만약 그 안에 있는 Pod들이 서로 다른 라벨을 가지고 있다면 → 각기 다른 Identity들이 대량으로 신규 생성됩니다.
• 생성된 Identity는 클러스터 내 모든 노드로 전파됩니다.
• Identity가 바뀌었기 때문에, 관련된 모든 Pod의 CiliumEndpoint도 업데이트됩니다.
• 이 모든 이벤트가 API 서버로 몰리게 됩니다.

클러스터에 노드가 많고 파드 수도 많다면 수천, 수만 건의 Identity 및 Endpoint 변경 이벤트가 한번에 API로 보내지게 됩니다. 당연 API서버에 문제가 발생할 수 있겠죠

 

Cilium v1.18에서는 이 문제를 해결하기 위해 네임스페이스 라벨 변경 시, Identity 변경 이벤트를 무작위로 지연(delay)시키는 기능이 도입되었습니다.

 

--identity-max-jitter