// Cilium Agentの主要サブシステム（概念的構造）
type Daemon struct {
    // エンドポイント管理
    endpointManager  *endpoint.EndpointManager
    // ポリシーリポジトリ
    policy           *policy.Repository
    // Identityアロケータ
    identityAllocator *cache.CachingIdentityAllocator
    // IPAM
    ipam             *ipam.IPAM
    // データパス管理
    datapath         datapath.Datapath
    // KVStoreクライアント
    kvStore          kvstore.BackendOperations
    // モニタリング
    monitorAgent     monitorAgent.Agent
}

# Agent状態確認
cilium status --verbose

# Agent設定確認
cilium config

# Pod作成時のCilium CNI呼び出しフロー
# 1. kubeletがCRIを通じてコンテナランタイムにPod作成を要求
# 2. コンテナランタイムがCNIプラグイン（Cilium）を呼び出し
# 3. Cilium CNIがAgentにAPI呼び出し
# 4. Agentがveth pair作成、IP割り当て、BPFプログラムロード

# エンドポイント一覧確認
cilium endpoint list

# 特定エンドポイントの詳細情報
cilium endpoint get 12345

+------------------+      +-------------------+
|  Cilium Operator |      |   Cilium Agent    |
| (クラスタ範囲)    |      |   (ノード範囲)     |
+------------------+      +-------------------+
| - Cluster IPAM   |      | - エンドポイント管理 |
| - CRD GC         |      | - BPFプログラムロード|
| - ノードディスカバリ|      | - ポリシー適用      |
| - Ingress処理    |      | - conntrack管理    |
| - Identity GC    |      | - Identity割り当て  |
+------------------+      +-------------------+

apiVersion: apps/v1
kind: Deployment
metadata:
  name: cilium-operator
  namespace: kube-system
spec:
  replicas: 2
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 1
  template:
    spec:
      containers:
        - name: cilium-operator
          image: quay.io/cilium/operator-generic:v1.16.0
          args:
            - --config-dir=/tmp/cilium/config-map
            - --cluster-pool-ipv4-cidr=10.0.0.0/8
            - --cluster-pool-ipv4-mask-size=24

パケット受信フロー：
NIC -> [XDP] -> ドライバ -> [tc ingress] -> ネットワークスタック -> [tc egress] -> NIC

Cilium BPFプログラムアタッチ位置：
- lxc*（veth）：from-container、to-container
- cilium_host：to-host、from-host
- cilium_net：from-host（オーバーレイ）
- eth0（物理）：from-netdev、to-netdev

# XDPプログラム確認
ip link show dev eth0
# eth0: ... xdp/id:42 ...

# BPFプログラム一覧確認
bpftool prog list

connect() -> [BPF sock_ops] -> サービスIPをバックエンドIPに変換
sendmsg() -> [BPF sk_msg] -> ソケット間メッセージリダイレクション

Cソースコード（bpf/*.c）
    |
    v
LLVM/Clang（BPFバックエンド）
    |
    v
BPF ELFオブジェクトファイル（.o）
    |
    v
BPFローダー（bpfシステムコール）
    |
    v
カーネルBPF検証器
    |
    v
JITコンパイル -> ネイティブ機械語
    |
    v
カーネルで実行

bpf/
  bpf_lxc.c          # Pod（エンドポイント）データパス
  bpf_host.c          # ホストネットワークデータパス
  bpf_overlay.c       # オーバーレイ（VXLAN/Geneve）データパス
  bpf_network.c       # 物理ネットワークインターフェース
  bpf_xdp.c           # XDPプログラム
  bpf_sock.c          # ソケットレベルプログラム
  lib/
    common.h          # 共通ヘッダーとマクロ
    maps.h            # BPFマップ定義
    policy.h           # ポリシー関連関数
    conntrack.h        # コネクショントラッキング
    nat.h              # NATエンジン
    lb.h               # ロードバランサー

# すべてのBPFマップ一覧確認
bpftool map list

# 特定マップの内容確認（ipcache）
cilium bpf ipcache list

# コネクショントラッキングテーブル
cilium bpf ct list global

# サービスロードバランサーテーブル
cilium bpf lb list

# ポリシーマップ確認
cilium bpf policy get 12345

# トンネルマップ確認
cilium bpf tunnel list

IP Cache構造：
10.0.0.0/8    -> Identity: 1（world）
10.244.0.0/16 -> Identity: 100（cluster）
10.244.1.0/24 -> Identity: 200（特定の名前空間）
10.244.1.5/32 -> Identity: 300（特定のPod）

ルックアップ：10.244.1.5 -> Identity 300（最も具体的なマッチ）

# conntrackエントリ例
cilium bpf ct list global
# SRC: 10.244.1.5:34567 DST: 10.96.0.1:443
# Flags: rx+tx closing
# Lifetime: 120s
# RxPackets: 42 RxBytes: 3456
# TxPackets: 38 TxBytes: 2890

Podラベル：
  app: frontend
  env: production
  team: web

  |
  v（セキュリティ関連ラベルの抽出）

セキュリティ関連ラベル：
  k8s:app=frontend
  k8s:io.kubernetes.pod.namespace=default

  |
  v（ハッシュ計算）

Identity: 48291（数値識別子）

# Identity一覧確認
cilium identity list

# 特定Identityの詳細情報
cilium identity get 48291

# Identityに含まれるラベル例：
# - k8s:app=...
# - k8s:io.kubernetes.pod.namespace=...
# - k8s:io.cilium.k8s.policy.cluster=...

# Identityから除外されるラベル例：
# - k8s:controller-revision-hash=...
# - k8s:pod-template-hash=...
# - k8s:pod-template-generation=...

ノードA：Pod作成 -> ラベルベースのIdentity要求
    |
    v
KVStore（CRDまたはetcd）
    |
    v（Identity割り当て/照会）
CiliumIdentity CRD：
  metadata:
    name: "48291"
  security-labels:
    k8s:app: frontend
    k8s:io.kubernetes.pod.namespace: default
    |
    v
ノードB：ipcacheにIP-to-Identityマッピングを更新

1. Pod作成イベント受信
   |
   v
2. CNI ADD呼び出し -> veth pair作成
   |
   v
3. IPアドレス割り当て（IPAM）
   |
   v
4. Identity割り当て
   |
   v
5. ポリシー計算（Identityベース）
   |
   v
6. BPFプログラムコンパイル
   （ポリシー + Identity + 設定 -> カスタムBPFコード）
   |
   v
7. BPFプログラムロード（tc ingress/egress）
   |
   v
8. BPFマップ更新
   （ipcache、endpointマップ、policyマップ）
   |
   v
9. エンドポイント状態：Ready

# エンドポイント再生成トリガー理由
# - ネットワークポリシーの変更
# - Identityの変更
# - Cilium設定の変更
# - ポリシーで参照されるFQDNのIP変更

# 再生成状態のモニタリング
cilium endpoint list
# ID    IDENTITY   POLICY   ENDPOINT STATUS
# 1234  48291      OK       ready
# 1235  48292      OK       regenerating  <-- 再生成中

1. Pod削除イベント受信
   |
   v
2. CNI DEL呼び出し
   |
   v
3. BPFプログラムの分離と削除
   |
   v
4. BPFマップから関連エントリを削除
   |
   v
5. veth pair削除
   |
   v
6. IPアドレス返却（IPAM）
   |
   v
7. エンドポイントメタデータのクリーンアップ

# 詳細エンドポイント情報
cilium endpoint get 1234

# エンドポイントヘルスチェック
cilium endpoint health 1234

# エンドポイントごとのBPFプログラム確認
cilium bpf prog list

# エンドポイントログ確認
cilium endpoint log 1234

# CRDベース（デフォルト）
# - CiliumIdentity、CiliumEndpoint、CiliumNodeなどのCRDを使用
# - etcd依存性なし
# - Kubernetes APIサーバーを通じた状態管理

# etcdベース
# - 別途のetcdクラスタが必要
# - 大規模クラスタでのパフォーマンス優位
# - ClusterMesh時に必須（clustermesh-apiserver）

Agent再起動
    |
    v
BPFマップ復元（マップはカーネルに保持）
    |
    v
既存エンドポイント検索（vethインターフェーススキャン）
    |
    v
エンドポイント状態復元（CRDからロード）
    |
    v
Identityキャッシュのウォーミング
    |
    v
ポリシー再計算と適用
    |
    v
通常運用再開

# 全体状態確認
cilium status --verbose

# BPFプログラミング状態
cilium bpf prog list

# データパス設定確認
cilium debuginfo

# モニタリング（リアルタイムパケットイベント）
cilium monitor --type trace
cilium monitor --type drop
cilium monitor --type policy-verdict

# メトリクス確認
cilium metrics list