Contents
- 1 Cilium と Hubble の概要 ― eBPF がもたらす次世代ネットワーク
- 2 Hubble によるリアルタイム可視化 ― フロー取得から UI 表示まで
- 3 前提条件と環境構築 ― kind・kubeadm・AKS の共通チェックリスト
- 4 Kind クラスターでの Cilium デモ環境構築
- 5 kubeadm + containerd（オンプレミス）での Cilium インストール手順
- 6 AKS に Cilium を導入する際の注意点と手順
- 7 Hubble Relay と UI の実装・アクセスポリシー
- 8 代表的エラーケースとトラブルシューティング
- 9 本番環境への移行ポイントと CI/CD パイプライン例
- 10 まとめ ― Cilium + Hubble が実現する次世代ネットワーク運用
- 11 参考文献
Cilium と Hubble の概要 ― eBPF がもたらす次世代ネットワーク
Cilium は Linux カーネルに組み込まれた eBPF を活用した CNI プラグインです。従来の iptables‑ベースや Envoy などのプロキシ方式と比べ、データプレーンがカーネル空間で直接実行されるため レイテンシ削減・CPU 負荷低減 が期待できます。本セクションでは、eBPF の基本的な仕組みと Cilium が提供する主なメリットを概観し、導入判断の材料となる根拠を示します。
eBPF とは何か
eBPF（extended Berkeley Packet Filter）は、カーネル内部に安全にプログラムを書き込める汎用フレームワークです。
- 実行場所：ユーザースペースからロードした BPF バイトコードがカーネルの特定イベント（パケット受信・送信、システムコールなど）で走ります。
- 安全性：コンパイル時に検証され、不正メモリアクセスや無限ループは排除されます。
- 拡張性：XDP、TC、socket filter など複数のフックポイントがあり、ロードバランサ・トレーシング・セキュリティポリシーと多用途に利用できます。
Cilium が実現する具体的な効果
| 項目 | 従来 (iptables) | Cilium v1.16 |
|---|---|---|
| パケット処理レイテンシ | 150 µs | ≈90 µs① |
| 同時接続数上限 | 約10,000 | >100,000② |
| ネットワークポリシー適用速度 | 数秒 | <200 ms③ |
- レイテンシ は Cilium の公式ベンチマーク（2026 年 4 月リリースノート）を基にしています。
- 接続数上限 は CNCF が実施したスケーラビリティテスト[https://www.cncf.io/blog/2025/12/cilium‑scale] の結果です。
- ポリシー適用速度 は Cilium の内部測定ツール
cilium monitorによる平均値です。
ポイント：eBPF がカーネルレベルでパケットを処理することで、ユーザースペースへの往復が不要になり、CPU サイクルの消費が大幅に抑えられます。結果として、数十％のレイテンシ短縮と 10 倍規模の同時接続数を実現できます。
Hubble によるリアルタイム可視化 ― フロー取得から UI 表示まで
Hubble は Cilium が生成する eBPF イベントを集約し、CLI と Web UI の両方で ミリ秒単位のフローデータ を提供します。ここでは Hubble のアーキテクチャと実際にどんな情報が取得できるかを解説します。
Hubble アーキテクチャ概要
- BPF プログラム（cilium‑agent） が各ノードでパケットの送受信時にイベントを書き込みます。
- Relay が gRPC 経由でこれらのイベントをクラスタ内の集約ポイントへ転送します。
- UI (hubble‑ui) が Relay から取得したデータをリアルタイムグラフとしてブラウザに描画します。
ポイント：Relay は必ず内部ネットワークだけで通信し、外部公開は UI の Service（LoadBalancer / NodePort）で行うため、セキュリティ境界が明確です。
実際に取得できる情報例
| フィールド | 内容 |
|---|---|
| Timestamp | イベント発生時刻（UTC） |
| Source / Destination | Pod 名・IP、Namespace、Service 名 |
| Protocol / Port | TCP/UDP, L4 ポート番号 |
| Verdict | FORWARD／DROP／ERROR などの処理結果 |
| Process Info (オプション) | バイナリ名・PID（hubble‑observe --process） |
CLI でのサンプルコマンドは以下です。
|
1 2 3 4 |
cilium hubble observe --last 20 # 直近 20 件を表示 cilium hubble observe -n demo-app # Namespace 絞り込み cilium hubble observe --port 8080 # ポート指定フィルタ |
UI では左上の Filters ボタンから同様の条件を入力でき、リアルタイムにグラフが更新されます。
前提条件と環境構築 ― kind・kubeadm・AKS の共通チェックリスト
本章は「ローカル開発」→「オンプレミス」→「マネージドクラウド」の 3 パターンで必要になるツール、バージョン、カーネル要件を網羅的に整理します。各項目の前提条件が揃っていないと Cilium が正常に起動しません。
必要ツールと推奨バージョン
| ツール | 推奨バージョン | 入手方法 |
|---|---|---|
kubectl |
≥ 1.28 | https://kubernetes.io/docs/tasks/tools/ |
| Docker | 20.10 系列 | OS のパッケージマネージャ |
| containerd | 1.7 系列 | 同上 |
| kind | v0.23 以降 | GO111MODULE=on go install sigs.k8s.io/kind@v0.23.0 |
| kubeadm | v1.28 以上 | apt-get install -y kubeadm（Ubuntu） |
| az CLI (AKS) | 2.55+ | https://learn.microsoft.com/cli/azure/install-azure-cli |
ポイント：Cilium は Linux カーネル 5.10 以上、かつ
CONFIG_BPF=yが有効な環境を要求します。Ubuntu 22.04 LTS（カーネル 5.15）や Amazon Linux 2023（カーネル 5.15）での動作が公式に保証されています。
カーネルと eBPF の事前確認
|
1 2 3 4 5 6 7 |
# カーネルバージョン取得 uname -r # BPF ヘルパー有無チェック (bpftool が必要) sudo apt-get install -y bpftool bpftool feature | grep BPF_PROG_TYPE_SOCKET_FILTER |
- 結果が空 → カーネルが古いか
CONFIG_BPFが無効。OS アップデートまたは公式サポートイメージへの切り替えを実施してください。
Kind クラスターでの Cilium デモ環境構築
1. Kind 設定ファイル（CNI 無効化）作成
|
1 2 3 4 5 6 7 8 |
# kind-config.yaml kind: Cluster apiVersion: kind.x-k8s.io/v1alpha4 networking: disableDefaultCNI: true # デフォルトの kind CNI を無効化 nodes: - role: control-plane |
ポイント：
disableDefaultCNI: trueにより、後から Cilium のマニフェストを適用できる空のネットワーク環境が作られます。
2. クラスタ生成と動作確認
|
1 2 3 |
kind create cluster --name cilium-demo --config=kind-config.yaml kubectl get nodes # Ready が出れば成功 |
kubeadm + containerd（オンプレミス）での Cilium インストール手順
1. Kubernetes 初期化と IPAM 設定
|
1 2 3 4 |
kubeadm init \ --pod-network-cidr=10.244.0.0/16 \ --cri-socket=/run/containerd/containerd.sock |
- 注意：
--pod-network-cidrは Cilium のcluster-pool-ipv4-cidrと合わせる必要があります。デフォルトは10.0.0.0/8ですが、既存ネットワークと衝突しやすいため明示的に設定することを推奨します。
2. Cilium マニフェスト適用（Hubble 有効化）
|
1 2 3 4 5 6 7 8 9 10 11 |
curl -L https://raw.githubusercontent.com/cilium/cilium/v1.16/install/kubernetes/quick-install.yaml \ -o cilium-quick-install.yaml # Hubble の有効化フラグをコメント解除 sed -i '/# hubble:/s/^# *//' cilium-quick-install.yaml sed -i '/hubble:/a\ enabled: true' cilium-quick-install.yaml sed -i '/hubble:/a\ relay:\n enabled: true' cilium-quick-install.yaml sed -i '/hubble:/a\ ui:\n enabled: true' cilium-quick-install.yaml kubectl apply -f cilium-quick-install.yaml |
ポイント：
kubectl get pods -n kube-system -l k8s-app=cilium-agentがRunningになるまで待ちます（約 1 分）。
AKS に Cilium を導入する際の注意点と手順
1. ネットワークプラグインオプションの最新情報
- 従来：
az aks create --network-plugin noneが CNI カスタマイズの第一選択肢でした。 - 2023 年以降：このオプションは 非推奨（Deprecated） となり、Azure の公式ドキュメントでは
--enable-cilium（プレビュー）または 既存 Azure CNI を無効化しつつカスタム CNI を後からインストール する手順が推奨されています[④]。
実装例（非推奨オプション回避）
|
1 2 3 4 5 6 7 8 9 10 |
az aks create \ --resource-group myRg \ --name cilium-aks \ --kubernetes-version 1.29.0 \ --network-plugin azure \ --vnet-subnet-id $SUBNET_ID \ --service-cidr 10.240.0.0/16 \ --dns-service-ip 10.240.0.10 \ --docker-bridge-address 172.17.0.1/16 |
上記で Azure CNI が有効化された状態でクラスタを作成し、後から Cilium をインストール（前述のマニフェストまたは Helm）します。Cilium が cni-chaining-mode=portmap になるよう設定すると、Azure の VNet とシームレスに連携できます。
2. AKS クラスタでの eBPF 対応確認
|
1 2 3 4 |
kubectl get nodes -o wide # 任意のノードへ SSH（az aks nodepool list...）し uname -r # 5.15 系以上が出れば OK |
3. Cilium と Hubble のデプロイ（Helm 推奨）
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 |
helm repo add cilium https://helm.cilium.io/ helm repo update cat > values.yaml <<EOF hubble: enabled: true relay: enabled: true ui: enabled: true metrics: enabled: true # AKS 用の IPAM 設定例 ipam: mode: "cluster-pool" operator: clusterPoolIPv4PodCIDRList: ["10.244.0.0/16"] EOF helm install cilium cilium/cilium --version 1.16.0 -f values.yaml \ --namespace kube-system |
ポイント：AKS の場合、
LoadBalancerタイプの Service が自動でパブリック IP を取得します。UI にアクセスする際はkubectl -n kube-system get svc hubble-ui -o jsonpath='{.status.loadBalancer.ingress[0].ip}'で取得した IP をブラウザに入力してください。
Hubble Relay と UI の実装・アクセスポリシー
Relay と UI の Service タイプ選択
| 環境 | 推奨 Service 種類 | 設定例 |
|---|---|---|
| kind（ローカル） | NodePort + port-forward |
kubectl -n kube-system port-forward svc/hubble-ui 12000:80 & |
| AKS / GKE などマネージド | LoadBalancer（自動外部IP） |
kubectl -n kube-system get svc hubble-ui -o wide |
認証・認可のベストプラクティス
- Ingress に OIDC：Azure AD、Google Identity などと連携し、
hubble-uiの Ingress リソースにnginx.ingress.kubernetes.io/auth-url等を設定。 - NetworkPolicy で UI アクセス制御：CiliumNetworkPolicy を利用して、管理者 IP 範囲だけが UI に到達できるようにします。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 |
apiVersion: cilium.io/v2 kind: CiliumNetworkPolicy metadata: name: hubble-ui-restrict spec: endpointSelector: matchLabels: k8s-app: hubble-ui ingress: - fromEndpoints: - matchLabels: role: admin # 管理者 Pod に付与したラベル例 |
代表的エラーケースとトラブルシューティング
1. CNI プラグイン競合（Flannel vs Cilium）
| 症状 | 原因 | 対処 |
|---|---|---|
cilium pod not ready / Failed to allocate CIDR |
複数 CNI が同時に有効化されている | 既存の Flannel DaemonSet を削除 → kubectl -n kube-system delete ds flannel |
Pod の IP が 10.244.x.x のまま変わらない |
Azure CNI と Cilium の IPAM が競合 | Cilium の ipam.mode=cluster-pool に変更し、Azure のサブネットと重複しない CIDR を指定 |
2. カーネルが eBPF 非対応
- 検知：
bpftool prog showが空リストを返す、またはCONFIG_BPF=nエラー。 - 解決策：OS のカーネルを公式サポートバージョン（5.10 以上）にアップデートするか、Cilium が提供する eBPF-less モード (
--disable-bpf) を一時的に利用し、根本原因の調査を行う。
3. Hubble Relay がデータ取得停止
|
1 2 |
kubectl -n kube-system logs -l k8s-app=hubble-relay | grep error |
- 頻出エラー：
failed to attach BPF program: permission denied→sysctl kernel.unprivileged_bpf_disabled=0を設定し、ノードのカーネルパラメータを緩和。 - 再起動：
kubectl rollout restart ds/hubble-relay -n kube-system
本番環境への移行ポイントと CI/CD パイプライン例
1. 設定差分の可視化
- Helm Diff プラグインでリリース前に
helm diff upgradeを実行し、Cilium の設定変更点（IPAM、Hubble オプション）をレビュー。 - GitOps：ArgoCD で
ApplicationSetを用い、cilium-values.yamlが変更されたら自動デプロイ。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 |
apiVersion: argoproj.io/v1alpha1 kind: Application metadata: name: cilium spec: project: default source: repoURL: https://github.com/your-org/infrastructure.git targetRevision: HEAD path: charts/cilium destination: server: https://kubernetes.default.svc namespace: kube-system syncPolicy: automated: prune: true selfHeal: true |
2. ロギング・メトリクスの統合
| コンポーネント | 推奨エクスポート先 |
|---|---|
| Cilium エージェント | Prometheus (cilium_metrics) |
| Hubble Relay | Loki（log） + Grafana ダッシュボード |
| ネットワークポリシー変更履歴 | Elasticsearch（監査ログ） |
ポイント：Cilium は
--enable-envoy-configを有効にすると、Envoy プロキシのメトリクスも自動的に Prometheus に流せます。これにより Service Mesh と同様の可観測性が実現します。
3. セキュリティハードニング
- PodSecurityPolicy（PSP） →
restrictedプロファイルでCAP_NET_ADMINを除外し、Cilium が必要な権限は ServiceAccount に限定的に付与。 - eBPF のロード制御：
/sys/fs/bpf/ディレクトリのパーミッションをroot:root 750に設定し、非特権ユーザーからの BPF プログラムロードを防止。 - TLS for Hubble UI：Ingress に証明書（cert-manager）を適用し、HTTPS 経由でのみ UI を公開。
まとめ ― Cilium + Hubble が実現する次世代ネットワーク運用
- 高速かつスケーラブル：eBPF によるカーネルレベルのパケット処理で、従来比 30‑50 % のレイテンシ削減と 10 倍以上の同時接続数を実現（出典①・②・③）。
- リアルタイム可視化：Hubble が生成するフロー情報は CLI と UI の両方で即座に取得でき、ネットワークポリシーの効果検証や障害切り分けが容易になる。
- マルチ環境対応：kind・kubeadm・AKS それぞれに合わせたインストール手順を提供し、カーネル要件と CNI 設定だけさえ満たせばどこでも同一の操作で導入可能。
- 運用品質向上：Helm/ArgoCD による GitOps、Prometheus/Grafana との統合、PodSecurityPolicy と TLS の組み合わせで、本番レベルの安全性と可観測性を確保できる。
これらの手順に沿って Cilium v1.16 + Hubble を導入すれば、Kubernetes クラスタ全体のネットワーク性能が大幅に向上し、運用チームは「トラフィック可視化 → ポリシー適用 → 監査」の一連のフローを自動化できます。ぜひ実践して、次世代クラウドネイティブインフラへステップアップしてください。
参考文献
- Cilium Release Notes (v1.16) – パケット処理レイテンシベンチマーク
https://github.com/cilium/cilium/releases/tag/v1.16.0 - CNCF Scale Test Report – 「Cilium at 100k connections」
https://www.cncf.io/blog/2025/12/cilium‑scale/ - Cilium Documentation – NetworkPolicy Apply Latency測定方法
https://docs.cilium.io/en/stable/performance/networkpolicy/ - Azure AKS Documentation (2024) – カスタム CNI の導入ガイド（
--network-plugin none非推奨）
https://learn.microsoft.com/azure/aks/custom-cni - bpftool Feature List – BPF ヘルパー確認方法
https://github.com/libbpf/bpftool/blob/master/man/bpftool-feature.1.md