测验：Gateway API、无边车网格、BGP

Cilium 의 Ingress·Gateway API 구현이 다른 Ingress 컨트롤러와 가장 크게 다른 점은?

• Deployment 로 뜬 전용 프록시가 LoadBalancer 서비스 뒤에서 트래픽을 받아 백엔드로 전달한다
• 서비스 포트에 도착한 트래픽을 eBPF 가 가로채 TPROXY 로 노드당 Envoy 에 넘기므로 네트워크 정책이 인그레스 트래픽에도 적용된다
• Gateway API 리소스를 kube-proxy 의 iptables 규칙으로 바로 번역해 Envoy 없이 L7 라우팅을 수행한다
• 각 백엔드 파드에 사이드카 Envoy 를 자동 주입해 라우팅 규칙을 파드 안에서 처리한다

HTTPRoute 로 두 서비스에 트래픽을 99:1 로 나누려 할 때 쓰는 표준 필드는?

• rules[].matches[].weight 에 비율을 적고 각 match 가 다른 서비스를 가리키게 한다
• Gateway 의 listeners[].weight 로 리스너마다 다른 백엔드 비중을 준다
• rules[].backendRefs[].weight 에 각 Service 의 비중을 적는다
• nginx.ingress.kubernetes.io/canary-weight 어노테이션을 HTTPRoute 에 붙인다

Cilium WireGuard 투명 암호화의 동작으로 문서와 맞는 것은?

• 노드마다 키 쌍을 만들고 공개키를 CiliumNode 의 어노테이션으로 나누며, UDP 51871 로 터널을 맺고 같은 노드 안 트래픽은 암호화하지 않는다
• 클러스터 하나에 공용 키 하나를 시크릿으로 배포하고, 모든 파드 사이 트래픽을 같은 노드 안에서도 암호화한다
• SPIRE 가 발급한 SVID 로 파드마다 TLS 세션을 맺으므로 커널의 WireGuard 모듈은 필요하지 않다
• TCP 443 으로 노드 사이 터널을 맺고, Ingress 로 들어온 외부 트래픽까지 같은 터널로 암호화한다

BGP Control Plane 으로 PodCIDR 을 광고할 때 실제로 광고되는 범위는?

• 클러스터 전체 파드 CIDR 을 한 프리픽스로 광고해 어느 노드로 보내도 되게 한다
• 파드 IP 하나하나를 /32 경로로 광고해 라우터가 파드 단위로 경로를 갖게 한다
• 서비스 ClusterIP 범위를 함께 묶어 광고하고 파드 CIDR 은 광고하지 않는다
• 각 노드의 BGP 인스턴스가 그 노드에 할당된 파드 CIDR 만 광고한다

CiliumBGPClusterConfig 를 적용했는데 상대 라우터가 먼저 연결을 시도하면 세션이 맺히지 않는 이유는?

• BGP 인스턴스는 기본으로 수신 포트 없이 떠서 연결을 시작만 하므로, 받으려면 localPort 를 주어야 하고 179 번은 CAP_NET_BIND_SERVICE 가 필요하다
• peerConfigRef 가 없는 피어는 수동(passive) 모드로 동작하므로 CiliumBGPPeerConfig 를 만들어야 능동 연결이 켜진다
• Cilium agent 는 hostNetwork 로 뜨지 않아 노드 IP 의 179 번 포트를 열 수 없으므로 NodePort 서비스를 따로 만들어야 한다
• graceful restart 가 기본으로 켜져 있어 재시작 뒤 첫 세션은 항상 상대가 아니라 Cilium 이 시작해야 한다

Egress Gateway 를 켜기 위한 전제 조건과 제약으로 옳은 것은?

• Cluster Mesh 가 켜져 있어야 하며, 게이트웨이 노드는 다른 클러스터에 둘 수도 있다
• IPsec 암호화가 켜져 있어야 하며, 정책은 네임스페이스 범위 리소스라 metadata.namespace 가 필수다
• BGP Control Plane 이 켜져 있어야 하며, 게이트웨이 IP 는 CiliumBGPAdvertisement 로 광고해야 동작한다
• BPF 마스커레이드와 kube-proxy 대체가 모두 켜져 있어야 하며, Cluster Mesh 와는 함께 쓸 수 없다

BGP Control Plane과 Egress Gateway의 데이터패스 역할을 정확히 구분한 설명은?

• 두 기능 모두 외부 라우터에 경로만 알리며 패킷 전달과 출발지 주소 변환에는 관여하지 않는다
• BGP는 경로를 광고하고, Egress Gateway는 선택한 외부행 패킷을 게이트웨이로 보내 SNAT한다
• BGP가 외부행 패킷의 출발지를 변환하고, Egress Gateway는 파드 CIDR 광고만 담당한다
• 두 기능 모두 클러스터 내부 서비스 경로를 설치하므로 kube-proxy 대체와 별도로 쓸 수 없다

FRR 피어는 Established이고 PodCIDR이 BGP RIB에 있지만 커널 FIB에는 없다. Pod HTTP도 실패한다. 이 증거로 내릴 수 있는 결론은?

• 피어가 Established이므로 네트워크는 정상이며 HTTP 애플리케이션만 고치면 된다
• RIB에 경로가 있으므로 Cilium이 패킷의 출발지를 SNAT하지 않은 것이 확정된다
• 경로 학습은 확인됐지만 커널 전달 경로 설치는 확인되지 않아 해당 단계를 조사해야 한다
• Pod IP에 직접 접근하려면 항상 NAT가 필요하므로 BGP 광고의 성공 여부는 무관하다