既存の Kubernetes クラスタへ Multus CNI を導入しました。対象は管理系のクラスタだけで、Ansible や Git 管理している構成ファイルはまだ変更していません。まずは公式 manifest を release tag 固定で取得し、server dry-run、適用、DaemonSet の安定化、Pod 疎通確認までを実施しています。
この記事では、Multus を「Pod に追加ネットワークを付けるための機能」としてだけではなく、既存の Pod ネットワークを壊さずに導入できているかを確認する観点で整理します。重要なのは、Multus の DaemonSet が Running になることだけではありません。00-multus.conf が作成され、既存の Calico 設定が delegate として参照され、通常の Pod 通信、DNS、Kubernetes Service が引き続き動くことを確認する必要があります。
作業範囲
今回の作業範囲は、管理用クラスタへの Multus 導入と基本疎通確認です。永続的な構成管理への反映、追加ネットワークの設計、NetworkAttachmentDefinition の本格運用は別の段階で扱います。
| 項目 | 内容 |
|---|---|
| 対象クラスタ | 管理用クラスタのみ |
| 導入方法 | 公式 manifest を release tag 固定で取得して適用 |
| 構成管理 | Ansible / Git は未変更 |
| 既存 CNI | Calico を delegate として利用 |
| 確認内容 | DaemonSet、CNI 設定、Pod 間通信、DNS、Kubernetes Service |
公式 manifest を release tag 固定で取得する
Multus の manifest は、GitHub の release tag に固定して取得します。本文中のクラスタ名やノード名は例示名です。実環境では、対象クラスタの context とノード名に置き換えます。
ctx=k8s-mgmt.example.local
src=https://raw.githubusercontent.com/k8snetworkplumbingwg/multus-cni/v4.2.4/deployments/multus-daemonset.yml
manifest=/tmp/multus-daemonset-thin-v4.2.4.yaml
curl -fsSL "$src" | sed 's#ghcr.io/k8snetworkplumbingwg/multus-cni:snapshot#ghcr.io/k8snetworkplumbingwg/multus-cni:v4.2.4#g' > "$manifest"公式 manifest の URL を branch や snapshot ではなく release tag に固定することで、後から同じ内容を取得しやすくなります。また、イメージタグも snapshot のままにせず、導入した release tag と合わせています。
server dry-run で API サーバー側の検証を行う
適用前に、Kubernetes API サーバー側で受け付けられる manifest か確認します。ローカルで YAML として読めることと、対象クラスタの API として受理されることは別です。
kubectl --context "$ctx" apply --dry-run=server -f "$manifest"ここで通ることを確認してから適用します。
Multus DaemonSet を適用する
kubectl --context "$ctx" apply -f "$manifest"適用後、kube-system namespace に kube-multus-ds が作成されます。Multus は各ノードへ CNI バイナリや設定を配置するため、DaemonSet として動作します。
memory limit を調整する
公式 manifest の 50Mi では、起動直後に OOMKilled が出ました。そのため、kube-multus container の memory limit を引き上げています。
kubectl --context "$ctx" -n kube-system set resources ds/kube-multus-ds -c kube-multus --requests=cpu=100m,memory=50Mi --limits=cpu=200m,memory=200Mi
kubectl --context "$ctx" -n kube-system rollout restart ds/kube-multus-ds
kubectl --context "$ctx" -n kube-system rollout status ds/kube-multus-ds --timeout=180sこの調整は、Multus の機能要件というより、対象クラスタで安定して起動させるための実測に基づく補正です。公式 manifest をそのまま適用して終わりにせず、実際の Pod 状態と restart / OOM の有無を確認します。
導入状態を確認する
DaemonSet と Pod の状態を確認し、NetworkAttachmentDefinition の CRD が作成されていることも確認します。
kubectl --context "$ctx" -n kube-system get ds,pod -l app=multus -o wide
kubectl --context "$ctx" get crd network-attachment-definitions.k8s.cni.cncf.ioノード上では、CNI 設定と Multus 関連バイナリを確認します。
sudo ls -la /etc/cni/net.d
sudo sed -n '1,220p' /etc/cni/net.d/00-multus.conf
sudo find /opt/cni/bin -maxdepth 1 \( -name '*multus*' -o -name '*passthru*' \) -print| 確認結果 | 意味 |
|---|---|
/etc/cni/net.d/00-multus.conf が両ノードに作成 | Multus が CNI 設定の入口になっている |
10-calico.conflist が delegate として指定 | 既存の Calico Pod ネットワークへ委譲されている |
/opt/cni/bin/multus が存在 | Multus CNI バイナリが配置されている |
/opt/cni/bin/passthru が存在 | Multus 関連の補助バイナリが配置されている |
kube-multus-ds が 2/2 Running | 対象ノードで DaemonSet が稼働している |
ここで特に重要なのは、Multus が既存 CNI の代替として勝手に Pod ネットワークを作り直しているわけではないことです。00-multus.conf が先頭の CNI 設定になり、その delegate として既存の Calico 設定を呼び出す構成になっていることを確認します。
試験用 Pod を配置する
control plane node と worker node に 1 Pod ずつ配置し、既存 Pod ネットワークが維持されているか確認します。ここでは追加 NetworkAttachmentDefinition はまだ付けず、Multus 導入後も通常の Pod 通信が壊れていないことを確認しています。
cat >/tmp/multus-nettest.yaml <<EOF
apiVersion: v1
kind: Pod
metadata:
name: multus-nettest-cp
namespace: default
labels:
app: multus-nettest
spec:
nodeName: k8s-cp-01.example.local
containers:
- name: netshoot
image: nicolaka/netshoot:latest
command: ["sleep", "3600"]
---
apiVersion: v1
kind: Pod
metadata:
name: multus-nettest-worker
namespace: default
labels:
app: multus-nettest
spec:
nodeName: k8s-worker-01.example.local
containers:
- name: netshoot
image: nicolaka/netshoot:latest
command: ["sleep", "3600"]
EOF
kubectl --context "$ctx" apply -f /tmp/multus-nettest.yaml
kubectl --context "$ctx" -n default wait pod/multus-nettest-cp pod/multus-nettest-worker --for=condition=Ready --timeout=180s
kubectl --context "$ctx" -n default get pod -l app=multus-nettest -o widePod の network annotation と interface を確認する
Pod の IP と、CNI が付与した network annotation を確認します。
kubectl --context "$ctx" -n default get pod -l app=multus-nettest -o json | jq -r '.items[] | [.metadata.name,.status.podIP,([.status.podIPs[].ip]|join(",")),.metadata.annotations["k8s.v1.cni.cncf.io/network-status"]] | @tsv'Pod 内では、interface とアドレスを確認します。
kubectl --context "$ctx" -n default exec multus-nettest-cp -- ip -brief address
kubectl --context "$ctx" -n default exec multus-nettest-worker -- ip -brief address追加ネットワークをまだ付けていない段階では、確認対象は既存 Pod ネットワークの interface です。Multus 導入後も既存 delegate で Pod が通常どおり起動し、IP が付与されていることを確認します。
Pod 間通信を確認する
control plane node 上の Pod と worker node 上の Pod の間で、IPv4 と IPv6 の疎通を確認します。
kubectl --context "$ctx" -n default exec multus-nettest-cp -- ping -c 3 -W 2 <worker-pod-ipv4>
kubectl --context "$ctx" -n default exec multus-nettest-worker -- ping -c 3 -W 2 <cp-pod-ipv4>
kubectl --context "$ctx" -n default exec multus-nettest-cp -- ping -6 -c 3 -W 2 <worker-pod-ipv6>
kubectl --context "$ctx" -n default exec multus-nettest-worker -- ping -6 -c 3 -W 2 <cp-pod-ipv6>確認結果は、Pod 間 IPv4 / IPv6 ともに OK でした。DualStack の既存 Pod ネットワークが、Multus 導入後も維持されていることを確認できています。
DNS と Kubernetes Service を確認する
次に、CoreDNS による名前解決と、Kubernetes Service への到達性を確認します。
kubectl --context "$ctx" -n default exec multus-nettest-cp -- dig +short kubernetes.default.svc.cluster.local A
kubectl --context "$ctx" -n default exec multus-nettest-worker -- dig +short kube-dns.kube-system.svc.cluster.local A
kubectl --context "$ctx" -n default exec multus-nettest-cp -- nc -vz -w 3 10.201.0.1 443
kubectl --context "$ctx" -n default exec multus-nettest-worker -- nc -vz -w 3 10.201.0.1 443
kubectl --context "$ctx" -n default exec multus-nettest-cp -- curl -sk --max-time 5 https://kubernetes.default.svc/readyz
kubectl --context "$ctx" -n default exec multus-nettest-worker -- curl -sk --max-time 5 https://kubernetes.default.svc/readyz| 確認項目 | 結果 |
|---|---|
| Pod 間 IPv4 | OK |
| Pod 間 IPv6 | OK |
| CoreDNS 名前解決 | OK |
Kubernetes Service 10.201.0.1:443 | OK |
https://kubernetes.default.svc/readyz | ok |
| 外向きインターネット通信 | timeout。管理系 Pod egress を閉じているため想定どおり |
外向きインターネット通信の timeout は、今回の Multus 導入失敗を示すものではありません。管理系 Pod の egress を閉じている設計によるものです。疎通確認では、期待される通信が通ることだけでなく、閉じている通信が閉じたままであることも確認対象になります。
試験 Pod を削除する
kubectl --context "$ctx" -n default delete pod multus-nettest-cp multus-nettest-worker --wait=true削除後、Multus の cache 残りや異常 Pod がないことを確認します。
for n in k8s-cp-01.example.local k8s-worker-01.example.local
do
ssh "$n" 'sudo find /var/lib/cni/multus -maxdepth 3 -type f -print 2>/dev/null'
done
kubectl --context "$ctx" -n kube-system get pod -l app=multus -o wide
kubectl --context "$ctx" get pods -A --field-selector=status.phase!=Running,status.phase!=Succeeded --no-headers削除後も Multus cache の残りはなく、異常 Pod もありませんでした。導入対象の DaemonSet は継続して Running です。
今回確認できたこと
今回の確認で分かったことは、Multus が入ったことそのものより、既存 Pod ネットワークが Multus 経由で問題なく delegate されていることです。
| 観点 | 確認できたこと |
|---|---|
| CNI 設定 | 00-multus.conf が作成され、Calico が delegate として指定されている |
| DaemonSet | kube-multus-ds が対象ノードで Running |
| Pod 起動 | control plane node と worker node の両方で試験 Pod が Ready |
| Pod ネットワーク | IPv4 / IPv6 の Pod 間通信が成功 |
| クラスタ内部通信 | DNS と Kubernetes Service への到達が成功 |
| 閉じるべき通信 | 管理系 Pod egress は timeout のまま |
| 後片付け | Multus cache 残りなし、異常 Pod なし |
追加ネットワークを使う前に、この段階の確認を分けておくことは重要です。ここで通常の Pod ネットワークが壊れていると、後続の NetworkAttachmentDefinition や macvlan / ipvlan / SR-IOV の検証結果を正しく判断できません。
まとめ
Multus は、Pod に複数のネットワークを接続するための CNI meta plugin です。しかし導入時に最初に確認すべきなのは、追加ネットワークではなく、既存 CNI が正しく delegate され、通常の Pod ネットワークが維持されていることです。
今回は、公式 manifest を v4.2.4 の release tag に固定して取得し、server dry-run 後に適用しました。公式 manifest の memory limit では OOMKilled が出たため、kube-multus container の memory limit を引き上げ、DaemonSet を再起動しています。
導入後は、00-multus.conf、Calico delegate、Multus バイナリ、DaemonSet、Pod 間 IPv4 / IPv6、DNS、Kubernetes Service、削除後の cache 残りを確認しました。Ansible / Git へ反映する前の検証としては、導入によって既存 Pod ネットワークが壊れていないことを確認できた状態です。
参考書籍
書籍
Kubernetes 完全ガイド 第 2 版
Kubernetes の Pod、Service、CNI、運用設計を体系的に確認したい場合の参考書籍です。価格や在庫はリンク先で確認してください。
Amazon で見るこのリンクは Amazon アソシエイトリンクです。


