Cilium と eBPF を使ったマルチクラウド K8s デプロイ手順

Cilium と eBPF の基礎知識

Cilium は Kubernetes 向けに設計された次世代 CNI で、eBPF（Extended Berkeley Packet Filter） を活用してカーネルレベルで高速かつ柔軟なネットワーク制御を実現します。本節では、Cilium の主要機能と eBPF がもたらすメリットを概観し、以降のデプロイ手順で必要となる前提知識を整理します。

Cilium の概要と主な機能

Cilium が提供する代表的な機能は以下です。

• L3/L4/L7 トラフィック制御
  eBPF プログラムがパケット処理をカーネル空間で行うため、従来の iptables に比べて数十倍高速になります。

• 拡張可能な NetworkPolicy
  標準の NetworkPolicy に加えて DNS 名や HTTP パス単位でポリシーを記述でき、マイクロサービス間の細かいアクセス制御が可能です。

• 可視化・トラブルシューティング
  Hubble（フロー観測ツール）と UI により、リアルタイムフローや過去ログを簡単に取得できます。

eBPF が実現する高度なネットワーキング

eBPF はカーネル内部で安全にプログラムを動的にロードできる仕組みです。その主な利点は次の通りです。

1. 低レイテンシ – カーネル空間で直接パケット処理が完結し、ユーザースペースへの往復が不要です。
2. 動的アップデート – プログラムを再コンパイルせずにロード・アンロードできるため、運用中の変更が即座に反映されます。
3. 高度な計測とフィルタリング – 任意のカーネル関数にフックし、トラフィックやシステムコールを詳細に観測できます。

主要クラウドプロバイダー別導入前提条件

マルチクラウド環境で Cilium を統一的に運用するには、各プロバイダーが要求する Kubernetes バージョンと IAM/権限設定を正確に合わせる必要があります。本節では AWS (EKS)、GCP (GKE)、Azure (AKS) の最新要件と最小権限のベストプラクティスをまとめます。

AWS – EKS の要件と IAM 設定

EKS で Cilium を利用する際の重要ポイントは以下です。

• Kubernetes バージョン
  現在（2026 年時点）公式に推奨されているバージョンは 1.27 以上 です。Cilium の安定版は公式リポジトリで確認し、対応する K8s バージョンと合わせてください。

• 最小権限 IAM ポリシー（AWS のベストプラクティスに基づく）
  json
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"eks:DescribeCluster",
"ec2:DescribeInstances",
"elasticloadbalancing:DescribeLoadBalancers"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"ec2:CreateNetworkInterface",
"ec2:DeleteNetworkInterface",
"ec2:AssignPrivateIpAddresses",
"ec2:UnassignPrivateIpAddresses"
],
"Resource": "*"
}
]
}

• ENI モードを使用しない場合は、ec2:*NetworkInterface* 系の権限は不要です。

• 必要に応じて AmazonEKS_CNI_Policy（管理されたポリシー）を参照し、最小権限化を検討してください。

• ネットワーク設計
  VPC CIDR は /16 以上確保し、Pod IP が既存サブネットと衝突しないようにプランニングします。

GCP – GKE の要件とサービスアカウント権限

GKE で Cilium を動かす際の留意点は次の通りです。

• Kubernetes バージョン
  標準クラスターは 1.28 以上 がデフォルトです。Cilium の公式ドキュメントで対応バージョンを必ず確認してください。

• 最小権限サービスアカウント（Google Cloud のベストプラクティス）
  yaml
# roles/container.clusterAdmin と組み合わせて付与

• role: roles/compute.networkViewer # ネットワーク情報取得
• role: roles/compute.instanceAdmin.v1 # VPC ネイティブ / Alias IP 利用時に必要


• Autopilot 環境では roles/container.admin が自動で付与されますが、追加権限は最小化してください。

• ネットワーク
  VPC ネイティブ（Alias IP）を有効にし、サブネットは /20 以上確保します。Pod CIDR は GKE の自動割当か 10.0.0.0/14 系列を推奨します。

Azure – AKS の要件とロールベースアクセス制御

AKS に Cilium を導入する場合の重要ポイントは以下です。

• Kubernetes バージョン
  現行サポートは 1.27 以上 で、Cilium の最新安定版が対応していることを公式サイトで確認してください。

• 最小権限ロール（Azure のベストプラクティス）

• Azure Kubernetes Service Cluster User Role（クラスター操作）
• Network Contributor（VNet・サブネット管理）

• Azure VNET 統合（IP‑Based）を利用する場合は、追加で Microsoft.Network/virtualNetworks/subnets/join/action 権限が必要です。

• ネットワークプラグイン選択
  Overlay モードを使用するなら Kubenet がシンプルです。Azure CNI と併用したい場合は、Cilium の Azure VNET 統合機能のベータステータスに留意し、テスト環境で十分検証してください。

Helm と Cilium CLI を用いたインストール手順（2026 年版）

本節では、Helm Chart と Cilium CLI の二通りのインストール方法を示します。どちらもバージョン固定とリポジトリ管理が重要ですので、最新リリースは必ず公式 GitHub リポジトリで確認してください。

Helm Chart の設定例とデプロイ手順

Helm を利用すると values.yaml でクラウド固有パラメータを一元管理でき、CI/CD パイプラインへの組み込みが容易になります。

1. リポジトリ追加とバージョン固定
   bash
helm repo add cilium https://helm.cilium.io/
helm repo update
# 例: 最新安定版を確認し、変数に格納
CILIUM_VER=$(helm search repo cilium --versions | grep -E 'v[0-9]+\.[0-9]+\.[0-9]+' | head -n1 | awk '{print $2}')

2. values.yaml の主要パラメータ（クラウド別設定を含む）
   yaml
# values.yaml
ipam:
mode: kubernetes
kubeProxyReplacement: strict
tunnelProtocol: disabled # ENI / VPC 連携時はオフ

hubble:
enabled: true
ui:
enabled: true
service:
type: LoadBalancer


1. デプロイ実行
   bash
helm install cilium cilium/cilium \
--version "${CILIUM_VER}" \
-f values.yaml \
--namespace kube-system \
--wait --timeout 10m0s

ポイント：--wait と --timeout を併用すると、Pod が正常に起動するまで CI が待機でき、失敗検知が正確になります。

Cilium CLI でのインストールフロー

CLI はシンプルなコマンドで環境自動検出とインストールを行えるため、PoC やスクリプト化に適しています。

1. CLI バイナリ取得（最新版は GitHub Releases を参照）
   bash
LATEST=$(curl -s https://api.github.com/repos/cilium/cilium-cli/releases/latest | jq -r .tag_name)
curl -L -o cilium-cli.tar.gz "https://github.com/cilium/cilium-cli/releases/download/${LATEST}/cilium-linux-amd64.tar.gz"
tar xzf cilium-cli.tar.gz && sudo mv cilium /usr/local/bin/

2. インストール実行（例：EKS ENI モード）
   bash
cilium install \
--version "${CILIUM_VER}" \
--datapath-mode eni \
--set hubble.enabled=true \
--set hubble.ui.enabled=true

3. インストール結果の確認
   bash
cilium status --wait

まとめ：本番環境では Helm による宣言的管理、PoC やマルチクラウドスクリプト化には CLI が有効です。

CNI モード切替と既存プラグインからの移行ステップ

Cilium は Overlay (VXLAN) と ENI / VPC CNI 連携 の二つのデータプレーンモードを提供します。既存の Calico・Flannel 等から安全に置き換える手順を段階的に示します。

CNI モード選択（Overlay vs ENI/VPC CNI）

各モードの特性と利用シーンは次の通りです。

要点：マルチクラウド環境では Overlay を共通基盤とし、AWS だけ ENI モードをオプションとして有効化する構成が実務的です。

既存 CNI から Cilium への安全な置き換え手順

段階的にデプロイ・テスト・切替えることでダウンタイムをほぼゼロに抑えられます。

1. 事前検証
2. 現行の CNI ConfigMap（例：cni-config）と Pod CIDR をバックアップ。

3. テストクラスターで Overlay モードをデプロイし、kubectl get pods -n kube-system -o wide で IP 割当を確認。

4. Cilium の併置（既存 CNI と同時に稼働）
   bash
helm install cilium cilium/cilium \
--set eni.enabled=true \ # 必要な場合のみ有効化
-n kube-system \
--wait

5. Pod の再スケジュール

6. 既存 CNI の DaemonSet を一時停止:
   bash
kubectl rollout pause daemonset/calico-node -n kube-system # Calico の例

7. Cilium Pod が起動したことを確認後、対象アプリケーションの Pod を削除して再作成させます。

8. 旧 CNI の完全削除
   bash
helm uninstall calico -n kube-system # Flannel でも同様に DaemonSet 削除

9. ロールバック手順（障害時）

10. 停止した旧 CNI の DaemonSet を再開:
    bash
kubectl rollout resume daemonset/calico-node -n kube-system
11. すぐに Pod が旧 CNI に戻り、サービスは復旧します。

まとめ：デプロイ → 再スケジュール → 削除 の三フェーズで移行を完了し、障害時は旧 CNI を即座に再開できる点が安全性の鍵です。

Hubble UI の有効化とトラフィック可視化設定

Hubble は Cilium が提供するフロー観測エンジンで、リアルタイム解析や過去ログ検索を可能にします。本節では Hubble Server と UI のデプロイ手順、および実務で役立つクエリ例を紹介します。

Hubble Server と UI デプロイ方法

Helm の values.yaml に以下フラグを追加すれば、追加のマニフェスト操作は不要です。

デプロイコマンド例:

• アクセス方法：<LoadBalancer IP>:12000 が UI のエントリーポイントです。
• Grafana 連携（任意）: hubble.relay.enabled=true とし、Prometheus エンドポイント cilium-hubble-metrics をデータソースに設定すれば、公式ダッシュボード JSON をインポートして可視化できます。

実務で使えるトラフィック可視化クエリ例

ポイント：CLI と UI を組み合わせて日次レポート化すると、NetworkPolicy の微調整や障害切り分けが格段に楽になります。

マルチクラウド共通ベストプラクティスとデプロイ後の検証・トラブルシューティング

Cilium をマルチクラウドで安定稼働させるためには、Pod Security Standards (PSS) と CiliumNetworkPolicy の併用が重要です。また、デプロイ直後に実施すべきヘルスチェックと、eBPF 関連エラーの対処法をまとめます。

PodSecurity Standards（PSS）によるセキュリティ強化

Kubernetes 1.25 以降は PSP が非推奨となり、代わりに Pod Security Standards が採用されています。以下は restricted プロファイルの適用例です。

• enforce が実際のポリシー適用、audit と warn は監査・警告用です。
• 必要に応じて baseline や privileged へ調整できます。

CiliumNetworkPolicy のベストプラクティス

• 最小特権の原則 に従い、Ingress と Egress の両方を明示的に記述します。
• DNS 名で制御したい場合は toFQDNs フィールドを使用し、動的なサービス名解決にも対応できます。

デプロイ確認コマンド一覧

eBPF カーネル設定チェックとトラブルシューティング

必要なカーネルコンフィグ（例：Ubuntu、Amazon Linux）

/boot/config-$(uname -r) から以下項目が有効か確認してください。

• 不要項目（例：CONFIG_NETFILTER_XT_TARGET_NFLOG）は Cilium の動作に必須ではありませんので除外しました。

エラー発生時の対処フロー

1. カーネルバージョン確認
   bash
uname -r # Cilium 1.15 系は最低 5.10、推奨は 5.15 以上

2. ログ取得
   bash
journalctl -u cilium | grep bpf

3. 設定が欠如している場合

4. カスタム AMI／イメージでカーネルをアップデート（例：Amazon Linux 2023 の kernel-5.15 系）。

5. 必要なコンフィグがモジュール化されているなら、modprobe <module> と永続化設定 (/etc/modules-load.d/cilium.conf) を追加。

6. マネージドノードの場合

7. GKE は Node Image Type: COS_CONTAINERD、AKS は Ubuntu 22.04 LTS など eBPF 対応カーネルが選択できることを確認。
8. 必要に応じて Node Pool のイメージバージョン を最新へロールアップデートします。

まとめ：デプロイ後は上記コマンドで全体ヘルスチェックを行い、eBPF 関連エラーが出たらまずカーネルバージョンと設定項目の有無を確認することが最速の復旧手順です。

まとめ

• Cilium + eBPF は高速・柔軟なネットワーク制御を実現し、マルチクラウドでも一貫したポリシー管理が可能です。
• 各クラウドプロバイダーの Kubernetes バージョンと最小権限 IAM/ロール を公式ガイドで最新確認し、過剰権限を排除してください。
• Helm と Cilium CLI のどちらも最新版を取得し、バージョン固定でデプロイすることが運用の安定化に繋がります。
• 移行時は Overlay を共通基盤 とし、AWS だけ ENI モードをオプションで有効化すると管理負荷が最小です。
• セキュリティは Pod Security Standards (PSS) + CiliumNetworkPolicy の併用で実現し、restricted プロファイルの適用とポリシーの最小特権化を徹底します。
• デプロイ後は cilium status, hubble status, connectivity test 等でヘルスチェックし、カーネル設定や eBPF エラーログを迅速に確認してください。

これらのベストプラクティスと検証手順を踏めば、AWS・GCP・Azure のいずれでも 安全かつ高性能 な Cilium 環境を構築できるでしょう。