Kubernetes Multus がうまく動かない時に考えること – CNI を複数持つ難しさ

Kubernetes に Multus を導入しようとしてうまく動かなかったときの検証メモです。Multus 自体は非常に良い実装だと思います。OpenShift や Tanzu のような環境では Multus を前提にした構成が検証されており、複数ネットワークを扱うための現実的な選択肢になります。

一方で、自前の Kubernetes クラスターへ後から Multus を入れる場合は話が変わります。CNI はクラスタの土台であり、Multus はその上に複数 CNI を扱う構造を作ります。うまく噛み合わないと、Multus の Pod だけでなく、通常のユーザー Pod まで起動しなくなることがあります。

発生した現象

• Multus のインストール自体は完了する
• 導入直後は Multus 関連 Pod が起動しているように見える
• ノード再起動後に Multus Pod が正常に起動しない
• サンプル Pod だけでなく、他のユーザー Pod まで起動しなくなる
• Calico を使っている環境で相性や初期化順序が疑わしい状態になる

このような状態になると、単なるアプリケーション Pod の問題ではありません。Pod ネットワークを作る仕組み自体が不安定になっているため、クラスタ全体の Pod 起動に影響します。

Multus の役割

Multus は、Kubernetes の Pod に複数のネットワークインターフェースを持たせるための CNI メタプラグインです。通常の Kubernetes では Pod に 1 つの主要な Pod ネットワークを与えますが、Multus を使うと追加ネットワークを付与できます。

• Pod に複数の NIC を持たせられる
• 通常の CNI に加えて追加ネットワークを扱える
• NFV、ストレージ、制御ネットワーク分離などで有用
• OpenShift などでは検証済みの構成として使われる
• 自前 Kubernetes では CNI の組み合わせと順序が重要になる

なぜ難しくなるのか

Multus は単独で Pod ネットワークを完結させるものではありません。既存の CNI、たとえば Calico、Flannel、Cilium などと組み合わせて使います。そのため、既存 CNI の状態、Multus の設定、NetworkAttachmentDefinition、ノード再起動時の初期化順序が絡みます。

導入直後だけ動いて、再起動後に崩れる場合は、インストール手順そのものよりも、ノード起動時に CNI 設定がどう並ぶか、kubelet がどの CNI 設定を拾うか、必要な設定ファイルが残っているかを見る必要があります。

確認するポイント

kubectl get pods -n kube-system -o wide
kubectl get pods -A -o wide
kubectl get events -A --sort-by=.lastTimestamp

CNI 設定ファイルの状態も確認します。ノード上で、どの CNI 設定が存在しているかを見ることが重要です。

ls -l /etc/cni/net.d
sudo find /etc/cni/net.d -maxdepth 1 -type f -print -exec sed -n '1,120p' {} \;

Multus、Calico、追加 CNI の設定がどう並んでいるかを確認します。Kubernetes 側の Pod 状態だけでは、CNI の初期化順序までは見えにくいです。

Calico との組み合わせ

Calico は好きな CNI ですが、Multus と組み合わせる場合は情報が散らばりやすく、環境依存の要素も増えます。Calico を主要 CNI として使い、Multus で追加ネットワークを扱う場合、Calico 側の Pod ネットワークと追加ネットワークの責務を分ける必要があります。

• Calico が主要 Pod ネットワークを担当する
• Multus が追加ネットワークを Pod に付与する
• 追加ネットワーク用 CNI の設定を別に用意する
• NetworkAttachmentDefinition を正しく定義する
• ノード再起動後も CNI 設定が同じ順序で読まれるようにする

OpenShift / Tanzu と自前 Kubernetes の違い

OpenShift や Tanzu のような製品環境では、Multus を含めた構成が検証され、運用上の前提も整理されています。つまり、Multus という部品だけでなく、その周辺の CNI、権限、設定、ノード初期化まで含めて製品側が面倒を見ています。

自前 Kubernetes では、その周辺を自分で揃える必要があります。Multus のマニフェストを入れるだけでは、製品環境と同じ安定性になるとは限りません。

判断としては保留もあり

今回の検証では、深く追えば原因を特定できた可能性はあります。ただ、CNI が不安定になるとクラスタ全体に影響します。自宅環境や実運用に近い環境であれば、無理にハックして使うより、安定している CNI 構成を優先する判断も妥当です。

Multus は魅力的ですが、複数ネットワークが本当に必要なワークロードがあるか、主要 CNI だけで足りないのか、クラスタを壊してまで検証する価値があるのかを考えるべきです。

まとめ

Multus は Kubernetes で複数ネットワークを扱うための強力な仕組みです。しかし、自前 Kubernetes に後から導入する場合、CNI の初期化順序、既存 CNI との相性、ノード再起動後の状態、追加ネットワーク定義まで含めて確認する必要があります。

今回のように、導入直後は動いても再起動後に Pod が起動しなくなる場合、Multus だけではなくクラスタの CNI 基盤全体の問題として見るべきです。複数 CNI は便利ですが、Kubernetes ネットワークの土台を複雑にする選択でもあります。

関連記事

• MicroK8s kube-ovn 有効化の検証 – CNI を後から切り替える難しさ
• Kubernetes Calico eBPF の設計メモ – kube-proxy 代替、DualStack、高可用性をどう見るか
• Kubernetes で送信元アドレスが変わる問題 – externalTrafficPolicy、hostNetwork、BGP 経路広告で考える
• MicroK8s MetalLB speaker が socket permission denied を出す原因 – L2 / 権限 / ホストネットワークを切り分ける
• Kubernetes クラスター構築 – kubeadm で controlPlaneEndpoint と CNI を整理する

Related posts:

Kubernetes クラスター構築 – kubeadm で controlPlaneEndpoint と CNI を整理する MicroK8s kube-ovn 有効化の検証 – CNI を後から切り替える難しさ Kubernetes Multus の導入 – Pod に複数 NIC を接続する Ubuntu 20.04 Kubernetes Multus（準備中） Ubuntu 22.04 Kubernetes Cilium 導入の事前確認 古い Kubernetes クラスター構築メモ – kubeadm 手順を現在の記事へ読み替える Kubernetes マニフェストを理解する apiVersion Kubernetes Nginx コンテナの実行 Kubernetes Nginx コンテナと Service ClusterIP Kubernetes MetalLB を Helm で導入する – Harbor で Chart を管理する考え方 Kubernetes を前提とした仮想 アーキテクチャの考察 Kubernetes コントロールプレーンノードを追加できない場合