パート8: eBPFデータパス内部構造のクイズ

Cilium 1.20.2 · 2026-10-15

1. Cilium 1.20では、カーネルが対応している場合、デバイスごとのプログラムにどのattach方式を使いますか。対応していない場合はどうなりますか？

   • A) 常に従来のclsactフィルターを使う。tcxはnetkitでのみ使う
   • B) tcxのbpf_link（カーネル6.6以降）を使う。対応していない場合はclsact + cls_bpfのdirect-actionを使う
   • C) すべてのvethでXDPを使う。対応していない場合はagentの起動を拒否する
   • D) すべてのインターフェイスでcgroupフックを使う。対応していない場合はiptablesを使う
   回答を表示

   回答: B) tcxのbpf_link（カーネル6.6以降）を使う。対応していない場合はclsact + cls_bpfのdirect-actionを使う

   bpf.enableTCXのデフォルトはtrueです。リンクは/sys/fs/bpf/cilium/...以下にpinされ、reload時にアトミックに更新されます。tc-bpfもtcxも動作しない場合に限り、agentは失敗します。

2. 同じノード内のPod間トラフィックはBPFホストルーティングとbpf_redirect_peerを使います。宛先Podのingressポリシーはどこで適用されますか？

   • A) 送信元のbpf_lxcプログラムがcilium_call_policy[destination endpoint ID]をtail callする
   • B) 宛先vethのtc egressフックが、送信元エンドポイント用にpinされたポリシーマップを使って適用する
   • C) agentが各エンドポイントの宛先netnsに設定したiptablesチェーン
   • D) パケットがvethに到達する前に、ノードNICのXDPプログラムが適用する
   回答を表示

   回答: A) 送信元のbpf_lxcプログラムがcilium_call_policy[destination endpoint ID]をtail callする

   redirect_peerは宛先側のtc egressフックを通らないため、宛先のcil_lxc_policyはglobal prog arrayに保存され、送信側から呼び出されます。空のスロットはDROP_EP_NOT_READYになります。

3. エンドポイントごとのポリシーマップcilium_policy_v3_<id>の型とキー構造は何ですか？

   • A) リモートPodのIPアドレスと宛先ポートをキーとするHASH
   • B) ポート番号をインデックスとし、プロトコルごとに1スロットを持つARRAY
   • C) ポリシールール番号をインデックスとし、ルールごとのプログラムをtail callするPROG_ARRAY
   • D) ID、方向、プロトコル、ポートプレフィックスをキーとするLPM_TRIE
   回答を表示

   回答: D) ID、方向、プロトコル、ポートプレフィックスをキーとするLPM_TRIE

   キーにはsec_label、egressビット、protocol、dportが含まれます。ポートプレフィックスを使うと、ポート範囲を少数のエントリで保存できます。また、sec_labelが0の場合はL3のワイルドカードとして動作します。

4. チュートリアルに、Cilium 1.20でオーバーレイ宛先のリモートノードを調べるにはcilium_tunnel_mapを確認するとあります。正しい説明はどれですか？

   • A) cilium-dbg bpf tunnel listでノードからエンドポイントへのテーブルを表示する
   • B) マップは存在するが、IPsecまたはWireGuard暗号化を有効にした場合だけ使用される
   • C) マップはなくなり、トンネルエンドポイントはcilium_ipcache_v2の値のフィールドに格納されている
   • D) マップがエンドポイント単位のcilium_tunnel_map_<id>になり、ノードごとに1つのエントリを持つ
   回答を表示

   回答: C) マップはなくなり、トンネルエンドポイントはcilium_ipcache_v2の値のフィールドに格納されている

   1.20のBPFコードでcilium_tunnel_mapを参照する箇所はありません。cilium_ipcache_v2（LPM_TRIE）はflag_has_tunnel_epとともにsec_identityとtunnel_endpointを返します。cilium-dbg bpf ipcache listを使ってください。

5. 1.20.2における--bpf-map-dynamic-size-ratioのデフォルトと、サイズを決める対象のマップはどれですか？

   • A) RAMの0.0025。CT、NAT、NodePort neighbor、socket reverse-NATマップ
   • B) 0（無効）。--bpf-policy-map-maxでサイズが決まるポリシーマップだけ
   • C) RAMの0.25。LBマップとipcacheを含むすべてのBPFマップ
   • D) RAMの0.0025。ipcacheとポリシーマップだけ
   回答を表示

   回答: A) RAMの0.0025。CT、NAT、NodePort neighbor、socket reverse-NATマップ

   動的サイズ設定はデフォルトで有効です。--bpf-ct-global-tcp-maxなどのサイズ指定フラグを設定すると、そのマップだけ動的サイズ設定が無効になります。LBマップには代わりに--bpf-lb-map-maxを使います。

6. --bpf-lb-map-max（デフォルト65536）は何を制御しますか？

   • A) cilium_lb4_services_v2マップだけを制御し、バックエンドとrev-NATはそれぞれのデフォルト値のままにする
   • B) Serviceごとのバックエンド数を制御し、上限を超えたエンドポイントを拒否する
   • C) 固定リストから素数を選ぶ必要があるMaglev検索テーブルのサイズ
   • D) LBマップごとにある6つのフラグ（services、backends、rev-NAT、affinity、source-range、Maglev）で使うフォールバックサイズ
   回答を表示

   回答: D) LBマップごとにある6つのフラグ（services、backends、rev-NAT、affinity、source-range、Maglev）で使うフォールバックサイズ

   マップごとの6つのフラグはそれぞれデフォルトが0であり、「lb-map-maxを使う」という意味です。Maglevテーブルのサイズは別のフラグで指定します。サイズ変更ではマップを再作成するため、再投入されるまで接続が中断します。

7. socket-LBが有効な場合、ClusterIPはどこで変換されますか。また、応答でアプリケーションからServiceアドレスが見えるのはなぜですか？

   • A) すべてのパケットでveth上のDNATによって変換され、応答経路ではcilium_lb4_reverse_natが元に戻す
   • B) cgroupフックがconnect()/sendmsg()で変換し、recvmsg/getpeernameフックがcilium_lb4_reverse_skを使って元に戻す
   • C) ホストnetnsのkube-proxy iptables DNATで変換し、conntrackが元のアドレスに戻す
   • D) パケットがスタックに到達する前にNICのXDPで変換し、Hubble relayが元に戻す
   回答を表示

   回答: B) cgroupフックがconnect()/sendmsg()で変換し、recvmsg/getpeernameフックがcilium_lb4_reverse_skを使って元に戻す

   ネットワーク上ではDNATが行われないため、Pod内のtcpdumpにはバックエンドIPが表示されます。cilium_lb4_reverse_natを使うパケット単位の経路は、socket-LBが適用されない場合（たとえばhost-namespace-onlyモード、L7 LB、SCTP）に限り使われます。

8. オーバーレイモードでパケットがcilium_vxlanに到着すると、cil_from_overlayはどのように送信元IDを取得しますか？

   • A) 送信元IDを設定した送信側が付与したトンネルID（VNI）を、bpf_skb_get_tunnel_keyで読み取る
   • B) 外側の送信元IPをcilium_lxcで検索する。このマップはノードIPとIDを対応付ける
   • C) ローカルEnvoyプロキシがリクエストへ追加したHTTPヘッダーを読む
   • D) エンドポイントラベルキャッシュを使って送信元Pod名からIDを解析する
   回答を表示

   回答: A) 送信元IDを設定した送信側が付与したトンネルID（VNI）を、bpf_skb_get_tunnel_keyで読み取る

   トンネルIDにhost IDが入っている場合はDROP_INVALID_IDENTITYで拒否されます。ネイティブルーティングにはVNIがないため、送信元IPからcilium_ipcache_v2を使って送信元IDを取得します（またはIPsec/WireGuard利用時にはmarkから取得します）。

9. 管理者がCiliumNetworkPolicyを編集すると、agentはデータパスに何を行いますか？

   • A) 影響するエンドポイントごとにclangでbpf_lxc.cを再コンパイルし、そのveth上のプログラムを再読み込みする
   • B) 新しいポリシーをアトミックに反映するため、すべてのデバイスでpin済みtcxリンクを置き換える
   • C) cilium_policy_v3_<id>のエントリを更新する。プログラムを再読み込みするのは、エンドポイントまたはノード設定のハッシュが変わった場合だけ
   • D) すべてのエンドポイントでプログラムを再生成するため、Cilium agent Podを再起動する
   回答を表示

   回答: C) cilium_policy_v3_<id>のエントリを更新する。プログラムを再読み込みするのは、エンドポイントまたはノード設定のハッシュが変わった場合だけ

   ポリシーの変更はマップ操作（RegenerateWithoutDatapath）です。テンプレートオブジェクトはtemplate-config hashごとにキャッシュされ、エンドポイントごとの値は.rodata.configに保存されます。

10. 1.20のHubbleイベントパイプラインに関する正しい説明はどれですか？

    • A) BPFがring bufferへ書き込み、Hubble Relayが各ノードのBPF filesystemから直接読み取る
    • B) イベントはcilium_events（perf array）に入り、agent monitorとHubble queueを経由して4095 flowを保持するメモリ内ringに入る
    • C) agentがflowをディスクに保存し、再起動後にHubble Relayへ再生する
    • D) L7イベントはプロキシリダイレクトマップが一致した際に、bpf_lxc tailプログラムが生成する
    回答を表示

    回答: B) イベントはcilium_events（perf array）に入り、agent monitorとHubble queueを経由して4095 flowを保持するメモリ内ringに入る

    perf_event_ring_bufferでの損失やobserver_events_queueでの損失が発生することがあります。L7レコードはBPFではなく、EnvoyとDNSプロキシからagentイベントとして送られます。