Kubernetes CNIにCiliumが選ばれる理由｜Calicoとの違い

Kubernetes クラスタのノード数とサービス数が増えてくると、ネットワークまわりの悩みが一気に表面化します。NetworkPolicy を書いたはずなのに通信が止まらない、kube-proxy の iptables ルールが膨らんでサービス追加のたびに反映が遅れる、そして「どこでパケットが落ちたのか」を調べる手段が実質的に存在しない。こうした状況で CNI の見直しを検討し始めると、ほぼ確実に「Cilium」という名前に出会います。

ところが、いざ調べ始めると判断に必要な情報がなかなか揃いません。eBPF という言葉は出てくるものの仕組みの説明は抽象的で、機能一覧は豊富すぎて自社に必要な機能がどれなのか分からない。Calico との比較表を見ても「高速」「高機能」といった形容詞が並ぶだけで、代わりに何を背負うことになるのかは書かれていない。評判のよさは伝わるのに、採用判断の材料にはならないという状態に陥りがちです。

採用を判断するために本当に必要なのは、機能の多さではありません。「自社のクラスタ規模と変更頻度でこの設計が効くのか」「ノードのカーネルは要件を満たしているのか」「他の CNI と比べて何を得て何を手放すのか」「プロジェクトの保守体制とアップグレード運用に追従できるのか」という 4 点です。これらは機能紹介とは別のレイヤにある情報で、公式ドキュメントの中でも散らばった場所に書かれています。

本記事では、eBPF ベースの Kubernetes 向けネットワーキング・可観測性・セキュリティ OSS である Cilium について、仕組み・主要機能・アーキテクチャ・導入前の前提条件・他 CNI との比較軸・保守状況を順に整理します。最後に「選ぶ条件」と「選ばない条件」の両方を提示し、検証に進むか見送るかを自分で判断できる状態をゴールにします。

なお本記事の内容は、公式リポジトリの README・公式ドキュメント・公式サイト・CNCF の公開レポート、および GitHub API から取得したリポジトリメタデータに基づく整理です。筆者による動作検証やインストール検証は行っていません。数値は後述の取得日時点のものであり、実際の導入判断では必ず各自の環境で公式ドキュメントの最新版を確認してください。

Cilium とは｜eBPF でネットワーキング・可観測性・セキュリティを束ねる OSS

cilium/cilium は、README の説明によれば「eBPF ベースのデータプレーンを持つ、ネットワーキング・可観測性・セキュリティのソリューション」です。Kubernetes をはじめとするコンテナオーケストレーション環境に対して、シンプルでフラットな L3 ネットワークを提供し、ネイティブルーティングとオーバーレイのいずれの方式でも複数クラスタにまたがった接続性を実現します。

Cilium の特徴は、カバーする範囲が Pod 間の接続性だけにとどまらない点です。L7 プロトコルを認識し、ネットワークアドレスから切り離されたアイデンティティベースのセキュリティモデルで L3 から L7 までのポリシーを適用できます。さらに eBPF による分散ロードバランシングで Pod 間通信と外部サービス向け通信を処理し、効率的なハッシュテーブルによって kube-proxy を完全に置き換えることも可能です。ingress / egress ゲートウェイ、帯域管理、サービスメッシュも扱える範囲に含まれます。プロジェクトの全体像とユースケース別の解説は Cilium 公式サイト にまとまっています。

リポジトリの基本情報

採用判断の入口として、まずプロジェクトの規模と鮮度を確認しておきます。以下は GitHub API から 2026 年 10 月 5 日に取得した値です。

アーカイブ済みリポジトリではなく（archived=false）、他リポジトリからのフォークでもありません（fork=false）。最終 push は取得日の前日であり、本家のリポジトリが現在も活発に更新されていることが確認できます。スター 25,604 という規模は、後述する Kubernetes 向けネットワーキング OSS の中でも突出した水準です。

ライセンスは 2 系統に分かれている

ライセンスについては、GitHub のメタデータ上の表記（Apache-2.0）だけを見て判断しないほうがよい点があります。README の License 節では、ユーザースペースのコンポーネントが Apache License 2.0 である一方、BPF コードテンプレートは GPL-2.0(only) と 2-Clause BSD のデュアルライセンスであり、利用者がいずれかを選択する形になっていると明記されています。Cilium のコードを自社プロダクトに取り込む、あるいは BPF テンプレートを改変して配布するような使い方を検討している場合は、この区別を社内の法務確認の前提として押さえておく必要があります。

プロジェクトの後ろ盾とガバナンス

Cilium は CNCF（Cloud Native Computing Foundation）の Graduated プロジェクトです。CNCF の Project Journey Report によると、2021 年 10 月 13 日に CNCF へ参加し、2023 年 10 月 11 日に Graduated ステータスへ到達しています（出典: CNCF Cilium Project Journey Report）。Graduated は CNCF のプロジェクト成熟度で最上位の区分であり、採用判断において「プロジェクトが突然消える」リスクを評価する際の材料になります。

一方で、単一ベンダへの依存度も見ておく価値があります。Cilium の創業元である Isovalent が最大のコントリビュータであり、同社については 2023 年末に Cisco が買収の意向を発表しています（出典: Isovalent 公式ブログ）。ただし CNCF のレポートでは Google・Cisco・Red Hat・Datadog・Cloudflare・SUSE などもコントリビュータとして挙げられており、コントリビュータが 1 社に閉じているわけではありません。ガバナンスは Maintainers / Committers 体制で運営されています。

なぜ eBPF なのか｜iptables ベースの CNI が抱える限界

Cilium の設計を理解する最短ルートは、「従来の Linux ネットワークセキュリティが何に困っていたのか」から入ることです。Cilium の Introduction は、この課題設定を明確に述べています。

従来の Linux ネットワークセキュリティ（iptables を代表とする仕組み）は、IP アドレスと TCP/UDP ポートでトラフィックを絞り込みます。これはサーバの構成が静的だった時代には十分に機能しました。しかしコンテナベースのマイクロサービス環境では、デプロイのたびにコンテナが作られては捨てられ、IP アドレスが頻繁に入れ替わります。その結果、同じポリシーを維持するだけでも全ノードのフィルタリングルールを継続的に書き換える必要が生じ、規模が大きくなると数十万規模のルールを更新し続けることになります。公式ドキュメントはこれを、従来手法がスケールに追従できない根本原因として挙げています。

ここで eBPF が効いてきます。eBPF は、アプリケーションコードを変更することなく「Linux 自体の内部にセキュリティの可視化と制御ロジックを挿入する」ための仕組みです。カーネル内にロジックを置けるため、ポリシーをカーネルレベルで動的に更新でき、外部のプロキシを挟まずにパケット処理の経路上で判断を下せます。

もう一つの鍵がアイデンティティベースのセキュリティです。README の説明によれば、従来のコンテナファイアウォールは送信元 IP と宛先ポートでトラフィックを絞るため、クラスタ内でコンテナが起動するたびに全サーバのファイアウォールを操作する必要がありました。Cilium は代わりに、同一ポリシーを共有するコンテナ群へセキュリティアイデンティティを割り当て、そのアイデンティティをパケットに付随させて受信ノード側で検証します。IP アドレスの寿命とポリシーの寿命を切り離す設計であり、Pod の入れ替わりが激しい環境ほど効果が出る構造になっています。

この設計から、採用判断に直結する示唆が導けます。クラスタの規模が小さく、デプロイ頻度も低く、ポリシーもほとんど変わらない環境では、eBPF ベースの設計がもたらす差は体感しにくいということです。逆に、サービス数が増え続け、1 日に何度もデプロイが走り、egress 制御を細かく掛けたい環境では、従来手法のスケール限界が先に来ます。自社がどちら側にいるかを見極めることが、最初の判断軸になります。eBPF 自体の技術的背景は、README からも参照されている eBPF.io にまとまっています。

Cilium の主要機能｜CNI からサービスメッシュ・可観測性まで

Cilium の機能は、README と公式 Introduction で 6 つの領域に整理されています。ここでは機能名を並べるのではなく、「どの要件があるとこの機能が必要になるか」という観点を添えて見ていきます。

CNI とルーティングモード

Cilium は Kubernetes の CNI プラグインとして Pod 間のネットワークを構成します。方式は 2 系統あります。ひとつは VXLAN / Geneve によるオーバーレイで、下位ネットワークの構成に手を入れにくい環境でも導入しやすい選択です。もうひとつはネイティブルーティングで、Linux ホストの通常のルーティングテーブルを使うため、カプセル化のオーバーヘッドを避けられます。ただしネイティブルーティングはコンテナ IP をルーティングできるネットワークが前提になるため、採用できるかどうかは自社のネットワーク設計に依存します。

経路学習も柔軟です。同一 L2 ドメインに収まる構成なら L2 近隣探索で済み、L3 境界をまたぐ構成なら BGP による経路学習を使えます。オンプレミスのネットワークと統合したい場合に、この選択肢の幅が判断材料になります。

ロードバランシングと kube-proxy の置き換え

Cilium のロードバランシングは east-west（クラスタ内）と north-south（外部からの流入）で実装が分かれています。

east-west では、connect() のタイミングでソケットレベルの書き換えを行うことで、パケットごとの NAT 処理を回避します。これが kube-proxy を置き換えられる根拠であり、サービス数の増加に対する処理コストの立ち上がり方が iptables ベースとは変わってきます。kube-proxy の iptables ルール膨張が運用上の痛点になっている場合、ここが最も分かりやすい導入動機になります。

north-south では XDP によるアクセラレーション、DSR（Direct Server Return）、Maglev 一貫性ハッシュによる L4 ロードバランシングに対応します。クラスタ外からのトラフィック量が大きく、ロードバランサ層のコストを削りたい場合に検討対象となります。

L3〜L7 の NetworkPolicy

ポリシー機能は Cilium の中核です。前述のアイデンティティベースの仕組みを土台に、次の粒度で制御できます。

• L3/L4: ラベル・プロトコル・ポートによる許可 / 拒否
• DNS ベース: FQDN やワイルドカードドメインの指定（例: api.example.com、*.trusted.com）
• L7 認識: HTTP メソッド・URL パス・gRPC コール単位の制御（例: 「/public/.* への GET のみ許可」「X-Token: [0-9]+ ヘッダの存在を強制」）
• CIDR ベース: ingress / egress の IP レンジ指定

実務上、ここで効いてくるのは DNS ベースの egress 制御です。外部 SaaS との通信をドメイン単位で許可したいという要件は、IP ベースのポリシーでは管理が破綻しやすい領域です。この要件が社内にあるかどうかは、Cilium を候補に残すかどうかの強い判断材料になります。

Cluster Mesh によるクラスタ横断の接続

Cluster Mesh は、複数の Kubernetes クラスタ間でグローバルなサービスディスカバリを提供する機能です。別クラスタのバックエンドへの自動フェイルオーバー、クラスタ横断の統一されたアイデンティティモデルを備えます。

マルチリージョン構成やクラスタ分割を既に抱えている、あるいは今後予定している組織では、この機能が単独の採用理由になり得ます。逆に単一クラスタ運用が前提なら、評価の対象外として切り離して考えてよい領域です。

Hubble による可観測性

Hubble は Cilium に組み込まれた可観測性のコンポーネントで、eBPF が取得した情報をもとに次を提供します。

• リアルタイムのサービスマップ（サービス間の依存関係の可視化）
• アイデンティティとラベルが付与されたフローの可視化
• DNS 認識フィルタとプロトコル別のインサイト
• Prometheus / Grafana との連携
• ドロップ理由と監査記録（ポリシー違反・ポート違反・DNS 解決失敗など）

CNI 選定の文脈でこの機能が重要になるのは、最後の項目です。「通信が通らない原因が分からない」という問題は、ポリシーを細かく運用し始めた環境で必ず発生します。ドロップ理由が記録される前提で設計できるかどうかは、障害対応にかかる時間を左右します。フロー単位の可視化が運用要件に含まれるなら、Cilium の優先度は上がります。

サービスメッシュと Gateway API

Cilium は、プロキシベース設計に伴うコストと複雑さを避けながら、細粒度のトラフィック制御・暗号化・可観測性・アクセス制御を提供する方針を取っています。透過的暗号化は IPsec・WireGuard・ztunnel に対応し、Kubernetes Gateway API 準拠のデータプレーンとしても動作します。

ここは Istio などのサービスメッシュと検討領域が重なる部分ですが、両者は単純な代替関係ではなく「L7 制御をどのレイヤに置くか」という設計判断になります。サービスメッシュそのものの選定軸についてはサービスメッシュとはで整理しているため、本記事では CNI としての観点に絞ります。

Cilium のアーキテクチャ構成要素

運用体制を見積もるには、監視・障害切り分けの対象となるコンポーネントを把握しておく必要があります。Component Overview の記述に沿って整理します。

この一覧から読み取れる運用上のポイントが 2 つあります。

1 つは、Operator の障害がデータプレーンを直接止めるわけではないという点です。公式ドキュメントが「パケット転送にとってクリティカルではない」と明示しているため、障害時の優先度判断（まず何を復旧すべきか）を設計に落とし込めます。

もう 1 つは、可観測性のために追加で運用するコンポーネントが存在する点です。Hubble Server はエージェント組み込みですが、クラスタ全体を見るには hubble-relay、GUI を使うには hubble-ui が加わります。可視化機能をフルに使う前提で見積もると、監視対象とリソース消費はその分増えます。「Cilium を入れる」という判断は、実質的にこれらの運用対象を引き受ける判断でもあります。

導入前に確認すべき前提条件｜カーネル・bpffs・kube-proxy 置き換え

ここが Cilium の採用判断で最も見落とされやすく、かつ検証を始めてから詰まりやすい領域です。eBPF をデータプレーンに使うという設計は、ノード側の OS・カーネルに対する要求として跳ね返ってきます。

カーネルとアーキテクチャの要件

System Requirements では、Linux kernel >= 5.10 もしくは同等（例として RHEL 8.10 の 4.18 が挙げられています）が要件とされています。さらに、一部の機能はより新しいカーネルを要求します。

対応アーキテクチャは AMD64 と AArch64 です。ここで確認すべきは、自社のノードイメージが使っているディストリビューションとカーネルバージョンです。マネージド Kubernetes を使っている場合はノードイメージの更新サイクルに依存し、オンプレミスで長期サポート版の OS を固定している場合は、使いたい機能がカーネル要件に引っかかることがあります。「Cilium を入れたいが、使いたかった機能だけ条件を満たさない」という状況は、この表を先に見ておけば回避できます。

bpffs のマウント

eBPF ファイルシステム（bpffs）は、cilium-agent が eBPF リソースを再起動をまたいで永続化するために使われます。これによりエージェントの更新中もデータパスが機能を保ちます。自動でマウントされない場合は、/etc/fstab に以下を追加して永続化します。

bpffs /sys/fs/bpf bpf defaults 0 0

（出典: Cilium System Requirements）

ノード間で開放が必要なポート

ネットワーク機器やセキュリティグループの設定変更が必要になるため、事前に関係チームと調整しておく項目です。公式ドキュメントが挙げる主なポートは次のとおりです。

• 8472/UDP: VXLAN オーバーレイ
• 6081/UDP: Geneve オーバーレイ
• 4240/TCP: ヘルスチェック（cilium-health）
• 51871/UDP: WireGuard による暗号化を有効にする場合
• ICMP 8/0: ヘルスモニタリング（任意だが推奨）
• ESP トラフィック: IPsec を使う場合

データストアとして etcd を選択する場合は、etcd 向けのポート（2379-2380/TCP）も対象になります。

kube-proxy 置き換えの追加要件と制約

kube-proxy の置き換えは Cilium の代表的な導入動機ですが、独自の前提条件を持ちます。kube-proxy 置き換えのドキュメントによると、この機能は socket-LB に依存し、カーネル config として CONFIG_INET_DIAG / CONFIG_INET_UDP_DIAG / CONFIG_INET_DIAG_DESTROY が有効である必要があります。lb-sock-terminate-all-protos を有効にする場合は CONFIG_INET_TCP_DIAG も必要です。また cgroup v2 が既定で /run/cilium/cgroupv2 に自動マウントされます（無効化も可能）。

有効化そのものは Helm で行えます。公式ドキュメントのクイックスタート例を以下に引用します。

helm install cilium cilium/cilium --version 1.20.2 \
   --namespace kube-system \
   --set kubeProxyReplacement=true \
   --set k8sServiceHost=${API_SERVER_IP} \
   --set k8sServicePort=${API_SERVER_PORT}

（出典: Kubernetes Without kube-proxy — Cilium Documentation。上記は公式ドキュメントの例を改変せずに引用したものです）

同じドキュメントには、Maglev（loadBalancer.algorithm=maglev）、DSR（routingMode=native と loadBalancer.mode=dsr の組み合わせ）、TCP は DSR・UDP は SNAT とする hybrid、XDP アクセラレーション（loadBalancer.acceleration=native）といったモード別の設定例も掲載されています。

そして、採用判断に直結する制約が同ドキュメントに明記されています。

• トランスポートとして完全にサポートされるのは TCP / UDP のみで、SCTP のサポートは限定的です
• socket-LB が有効な環境では、サービスの ClusterIP に対する NFS / SMB マウントが壊れる可能性があります。回避にはカーネルパッチがバックポートされたバージョン（Ubuntu 5.4.0-187 以降、RHEL 8.10 以降、RHEL 9.4 以降）が必要です
• DSR モードは TCP Fast Open と相性が悪く、その場合は SNAT モードが推奨されます
• 同一のバックエンドを複数の VIP で公開しないことが強く推奨されています（コネクション衝突の回避）
• 未接続の UDP ソケットでは、reverse SK マップの枯渇によってソケット終了の挙動が不安定になる可能性があります

これらは「導入後に気づくと手戻りが大きい」種類の条件です。とくに ClusterIP に対する NFS / SMB マウントは、ストレージを共有する既存ワークロードを抱えている環境で踏みやすい箇所です。検証環境を立てる前に、自社のワークロードがこれらに該当しないかを確認しておく価値があります。

Calico・Flannel との違い｜Kubernetes CNI の比較軸

Kubernetes の CNI には複数の有力な選択肢があります。以下は GitHub API から 2026 年 10 月 5 日に取得した値をもとにした比較です。

比較軸ごとに違いを言語化すると、判断に落としやすくなります。

データプレーン実装: Cilium は eBPF 一本、Calico は iptables が既定で eBPF データプレーンも選択可、Antrea は Open vSwitch です。eBPF を使う構成はカーネルバージョンへの依存が強くなり、OVS を使う構成は別種の運用知識を要求します。「どの技術スタックをチームで扱えるか」が選定を左右します。

NetworkPolicy の範囲: Flannel は NetworkPolicy を提供しないため、ポリシー制御が要件に入るなら候補から外れます。Calico はポリシー適用の実績が豊富で、標準の NetworkPolicy に加えて独自の拡張を備えます。Cilium は DNS ベース・HTTP メソッド / パス・gRPC といった L7 粒度まで同じ枠組みで扱える点が差分になります。

L7 の可視化: Cilium は Hubble をプロジェクト内に持ち、フロー単位の可視化とドロップ理由の記録が CNI の延長線上で使えます。ここは Cilium が明確に広い領域をカバーしている部分です。

kube-proxy の置き換え: Cilium は socket-LB による置き換えを主要機能として掲げています。この要件が選定理由の中心にある場合、候補は実質的に絞られます。

カーネル要件: 既述のとおり Cilium は kernel >= 5.10 もしくは同等を要求します。Flannel のようにシンプルな構成の CNI と比べると、ノード側の前提条件は厳しくなります。

コミュニティ規模: スター数で見ると Cilium が 25,604 で最大です。情報の見つけやすさ、サードパーティツールの対応状況、採用事例の多さといった間接的な要素に影響します。

Istio と cilium/hubble の位置づけ: istio/istio はスター 38,429 と規模は大きいものの、CNI ではなくサービスメッシュです。Cilium がサービスメッシュ機能を持つため領域は重なりますが、選択肢として並べるものではなく「サイドカープロキシ前提の構成を取るかどうか」という設計判断になります。また cilium/hubble（スター 4,357）は Hubble CLI のリポジトリで、Hubble Server 自体は cilium/cilium のエージェントに組み込まれています。検索で両者が出てきた際は別物として扱ってください。

Cilium を選ぶ・選ばないの判断軸とメンテナンス状況

ここまでの整理を、採用判断の形にまとめます。

選ぶ判断が立ちやすい条件

• マルチクラスタ構成を抱えている / 予定している: Cluster Mesh によるグローバルサービスディスカバリと自動フェイルオーバーが、他の選択肢では代替しにくい価値になります
• L7 ポリシーや DNS ベースの egress 制御が要件にある: 外部 SaaS との通信をドメイン単位で許可したいといった要件は、Cilium の設計と素直に噛み合います
• kube-proxy のスケール限界に当たっている: サービス数の増加に伴う iptables ルール膨張が運用上の痛点になっている場合、socket-LB による置き換えが直接の解決策になります
• フロー単位の可観測性が求められている: 通信が落ちた理由を記録として残したい、サービス間の依存関係を可視化したいという要求に Hubble が応えます
• ノードのカーネルが要件を満たしている: kernel >= 5.10 もしくは同等を満たし、使いたい機能の追加要件もクリアできる環境であること

選ばない判断が妥当な条件

• 数ノード規模の単一クラスタで、既定の CNI が問題なく機能している: eBPF ベースの設計が解く問題がそもそも発生していない状態では、機能の多さが運用負荷として跳ね返ります
• カーネル要件を満たせないディストリビューションを使っている: ノードイメージを変更できない制約があるなら、要件を満たす CNI を選ぶほうが素直です
• ClusterIP 経由の NFS / SMB マウントなど、既述の制約に該当するワークロードがある: 回避に必要な OS バージョンへ上げられない場合は、制約が運用リスクとして残ります
• eBPF とカーネルまわりを扱える運用体制がない: 障害時の切り分けには eBPF の挙動とカーネルの知識が求められます。可視化コンポーネント（hubble-relay / hubble-ui）の運用も加わるため、人員と習熟のコストを見込めない状況では見送る判断も合理的です

Kubernetes 周辺の管理ツール群をどう組み合わせるかという観点では、Kubernetes管理ツールにMesheryが選ばれる理由も判断材料になります。

メンテナンス状況とアップグレード運用

採用判断で軽視されがちですが、継続コストに最も直結するのがリリース保守ポリシーです。README の Stable Releases 節によると、Cilium のコミュニティは直近 3 マイナーバージョンのみ安定版を保守し、それより前のマイナーは EOL（End of Life）扱いになります。

README に記載されているメンテナンス対象ブランチは次のとおりです（いずれも 2026 年 9 月 15 日リリース）。

開発版として main（日次ビルドの quay.io/cilium/cilium-ci:latest）と v1.21.0-pre.2（2026 年 9 月 9 日）がありますが、README では本番利用は非推奨と明記されています。

ここから導ける運用上の示唆は明確です。マイナーバージョンが 3 つ進むとサポートが切れるため、定期的なアップグレードを運用計画に組み込む必要があるということです。クラスタのネットワークを担うコンポーネントのアップグレードは慎重な作業になるため、「入れたら終わり」ではなく継続的な作業枠として見積もるべき項目です。手順は Cilium Upgrade Guide にまとまっています。なお v1.13.0 以降は全イメージに SPDX 形式の SBOM が同梱されており、サプライチェーンセキュリティの要件がある組織では確認対象になります。

コミュニティと情報源

判断材料を集める段階で使える公式の窓口も押さえておきます。Slack ワークスペース（slack.cilium.io）、SIG 一覧、開発者ミーティングが公開されています。開発者ミーティングは毎週水曜 17:00（Europe/Zurich）に開催され、加えて毎月第 3 水曜 13:30 JST に APAC 向けの回が設けられています。日本時間で参加できる経路が公式に用意されている点は、情報収集のしやすさとして評価できます。週次のライブ配信 eCHO（eBPF & Cilium Office Hours）も YouTube で公開されています。

どの企業がどのユースケースで本番採用しているかは、リポジトリの USERS.md に一覧があります。自社と近い規模・業種の採用事例を探すことで、判断の確度を上げられます。

まとめ｜Cilium 採用判断のチェックポイント

Cilium は、eBPF をデータプレーンに据えることで、Pod 間接続・ロードバランシング・L3〜L7 ポリシー・クラスタ横断接続・可観測性・サービスメッシュまでを 1 つのプロジェクトでカバーする OSS です。CNCF Graduated プロジェクトであり、スター 25,604・最終 push 2026 年 10 月 4 日という活発な開発状況にあります。

採用を判断する際は、以下を順に確認すると漏れがありません。

• 機能要件: マルチクラスタ、L7 / DNS ベースのポリシー、kube-proxy 置き換え、フロー単位の可観測性のうち、自社に該当するものがあるか
• カーネル要件: ノードのカーネルが kernel >= 5.10 もしくは同等を満たすか。使いたい機能の追加要件（BIG TCP や netkit 等）もクリアできるか
• 制約の該当有無: ClusterIP 経由の NFS / SMB マウント、TCP Fast Open と DSR の組み合わせなど、公式ドキュメントが挙げる制約に触れるワークロードがないか
• 運用体制: eBPF とカーネルまわりの切り分けができるか。hubble-relay / hubble-ui を含む運用対象の増加を受け入れられるか
• アップグレード運用: 直近 3 マイナーのみ保守という方針に追従できる定期アップグレード枠を確保できるか
• 他 CNI との比較: Flannel で足りる規模なのか、Calico の素直な構成のほうが運用に合うのか

これらのうち機能要件に該当がなく、クラスタ規模も小さいのであれば、見送る判断が合理的です。逆に複数が該当するなら、検証に進む価値は十分にあります。次のステップとしては、Cilium 公式サイトのユースケース別ページで自社要件に近い構成を確認し、System Requirements で手元のノード環境との適合を突き合わせるところから始めるとよいでしょう。

次のアクション

Kubernetes の基盤設計やコンテナ環境の運用体制づくりについてご検討中の方は、お問い合わせフォーム からご相談いただけます。要件の整理段階からのご相談にも対応しています。

参考リンク

• cilium/cilium（GitHub）
• Cilium 公式サイト
• Introduction to Cilium & Hubble
• Component Overview
• System Requirements
• Kubernetes Without kube-proxy
• Cilium Upgrade Guide
• USERS.md（本番採用事例）
• eBPF.io
• CNCF Cilium Project Journey Report