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

Kubernetes に Multus を導入しようとしてうまく動かなかったときの検証メモです。Multus 自体は非常に良い実装ですが、自前の Kubernetes へ後から入れる場合は、primary CNI、secondary CNI、NetworkAttachmentDefinition、IPAM、ノード再起動時の初期化順序まで含めて見る必要があります。

一方で、自前の 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 を使うと追加ネットワークを付与できます。

• primary CNI は通常の Pod ネットワークを担当する
• Multus は追加ネットワークを Pod に付与する入口になる
• secondary CNI は追加 NIC の実体を作る
• NetworkAttachmentDefinition で追加ネットワークを宣言する
• IPAM、経路、名前解決、NetworkPolicy の責務を分けて見る必要がある

なぜ難しくなるのか

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

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

NetworkAttachmentDefinition を見る

Multus では、追加ネットワークを NetworkAttachmentDefinition として定義します。Pod annotation でどの追加ネットワークを使うかを指定するため、NAD、Pod annotation、secondary CNI の設定が一致しているかを確認します。

kubectl get network-attachment-definitions -A
kubectl describe network-attachment-definition -n <namespace> <name>

確認するポイント

まず Kubernetes 側で Multus、ユーザー Pod、イベントを確認し、その後ノード上の CNI 設定ファイルを確認します。

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

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

ls -l /etc/cni/net.d
sudo find /etc/cni/net.d -maxdepth 1 -type f -print

設定ファイルの中身を確認する場合は、実運用では内容に認証情報や環境依存値が含まれる可能性もあるため、公開記事やログへそのまま貼らないようにします。

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

まとめ

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

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

関連する記事

次に進む

参考書籍

関連記事

Kubernetes Multus の導入 – Pod に複数 NIC を接続する Kubernetes NetworkPolicy で Pod のアウトバウンド通信を制御する – egress と CNI を分けて考える Kubernetes クラスター構築 – kubeadm で controlPlaneEndpoint と CNI を決める Kubernetes に LoadBalancer はないのか – Service、MetalLB、CNI BGP を分けて考える MicroK8s で kube-ovn を有効化する – CNI を後から切り替える難しさ Kubernetes Calico eBPF の設計メモ – kube-proxy 代替、DualStack、高可用性をどう見るか Kubernetes disk-pressure で Pod が起動しない場合 Kubernetes クラスタの初期化 – kubeadm reset の基本