クイズ: eBPFとCiliumのアーキテクチャ

eBPF 검증기(verifier)가 프로그램을 거부하는 대표적인 이유는?

• 프로그램 크기가 1MiB 를 넘어서
• C 가 아닌 언어로 작성돼서
• 루트 권한 없이 로드를 시도해서
• 종료가 보장되지 않는 반복문이나 유효하지 않은 메모리 접근이 있어서

Cilium 데이터패스에서 bpf_redirect_peer 가 절약하는 것은?

• 터널 캡슐화에 드는 50바이트 헤더
• veth 쌍을 통과할 때 발생하는 소프트IRQ 재스케줄링 한 사이클
• conntrack 테이블 조회 비용
• TLS 핸드셰이크 비용

iptables 방식 대비 eBPF 데이터패스의 이점 중 '규칙 갱신' 측면에서 옳은 설명은?

• iptables 는 사실상 테이블 전체를 다시 쓰지만 eBPF 는 맵 엔트리 단위로 증분 갱신한다
• 두 방식 모두 변경분만 반영하므로 차이가 없다
• eBPF 는 갱신 시 전체 프로그램을 재컴파일하므로 iptables 보다 느리다
• iptables 는 커널이 자동으로 인덱싱해 갱신이 상수 시간이다

Cilium 의 예약 아이덴티티 번호와 의미가 잘못 짝지어진 것은?

• 7 = ingress
• 1 = host (로컬 노드 자신)
• 2 = world (클러스터 외부 전부)
• 6 = remote-node (다른 노드들)

"Cilium 을 쓰면 모든 트래픽이 빨라진다"는 주장이 부정확한 이유로 가장 적절한 것은?

• eBPF 프로그램이 JIT 컴파일되지 않아 인터프리터로 동작하기 때문
• conntrack 을 커널 대신 사용자 공간에서 처리하기 때문
• L7 정책이 걸린 트래픽은 유저스페이스 Envoy 를 경유하고, 터널 모드는 약 50바이트 캡슐화 오버헤드를 더하기 때문
• 정책이 많아질수록 맵 조회가 선형으로 느려지기 때문

Cilium Operator 의 역할에 해당하는 것은?

• 각 노드에서 eBPF 프로그램을 로드하고 엔드포인트를 관리
• 클러스터 범위 IPAM 과 CRD 가비지 컬렉션, 노드 디스커버리
• 노드별 conntrack 테이블 유지
• Hubble 플로우를 노드 로컬 링버퍼에 수집