Quiz: Networking and kube-proxy Replacement

파드가 다른 노드로 재스케줄되어 IP 가 바뀌었습니다. Cilium 에서 갱신되는 것은?

• 모든 노드의 정책 맵을 다시 계산한다
• ipcache 의 IP-아이덴티티 매핑만 갱신되고 정책 맵은 그대로다
• 해당 파드의 아이덴티티가 새로 발급된다
• conntrack 테이블 전체가 초기화된다

pod-template-hash 같은 라벨이 아이덴티티 계산에서 제외되는 이유는?

• 라벨 키가 너무 길어 맵 크기를 키우기 때문
• 쿠버네티스가 이 라벨을 파드에 붙이지 않기 때문
• 네임스페이스 정보와 중복되기 때문
• 디플로이먼트를 재배포할 때마다 값이 바뀌어 모든 파드가 새 아이덴티티를 받게 되기 때문

Cilium 의 소켓 수준 로드밸런싱이 갖는 특징은?

• 모든 패킷마다 XDP 훅에서 목적지를 다시 계산한다
• connect() 시점에 서비스 IP 를 백엔드 IP 로 바꿔 패킷 단위 NAT 과 conntrack 항목이 필요 없다
• L7 프로토콜까지 파싱해 요청 경로별로 서로 다른 백엔드를 고른다
• DNS 응답을 조작해 백엔드를 분산한다

kubeProxyReplacement 를 켜면서 k8sServiceHost 와 k8sServicePort 를 반드시 지정해야 하는 이유는?

• kubernetes 서비스의 ClusterIP 를 실제 주소로 바꿔 줄 주체가 Cilium 자신인데, 부트스트랩 시점에는 아직 뜨지 않았기 때문
• Cilium 이 API 서버 인증서를 검증하는 데 필요해서
• kube-proxy 가 남긴 iptables 규칙을 지우기 위해 필요해서
• Hubble relay 가 API 서버에 접속할 때 쓰기 때문

네이티브 라우팅 대신 터널(VXLAN) 모드를 선택해야 하는 상황은?

• 노드 간 대역폭이 매우 큰 환경
• DSR 모드를 반드시 써야 하는 환경
• MTU 를 최대한 크게 유지해야 하는 환경
• 언더레이 네트워크가 PodCIDR 경로를 알지 못하고 통제할 수도 없는 환경

Maglev 일관 해싱이 Cilium 서비스 로드밸런싱에서 해결하는 문제는?

• 백엔드가 늘거나 줄 때 기존 플로우 대부분이 같은 백엔드에 유지되도록 재배치를 최소화한다
• L7 경로별로 서로 다른 백엔드를 선택한다
• 백엔드의 CPU 사용률에 따라 가중치를 자동 조정한다
• DNS TTL 을 조절해 클라이언트 캐시를 무효화한다