MicroK8s kube-ovn 有効化の検証 – CNI を後から切り替える難しさ

Ubuntu 22.04 上の MicroK8s で kube-ovn を有効化しようとした検証メモです。当時は期待どおりに有効化できなかったため、この記事では「何を期待したのか」「どこで難しくなったのか」「MicroK8s で CNI を後から切り替えるときに何を見るべきか」を整理します。

結論から言うと、MicroK8s は手軽に Kubernetes を始められる一方で、CNI、DualStack、Service、MetalLB のようなネットワーク基盤を後から差し替える検証には注意が必要です。CNI はアドオンの一つではありますが、実際にはクラスタの土台です。

kube-ovn に期待したこと

• MicroK8s で IPv4 / IPv6 DualStack を扱いやすくする
• Pod / Service ネットワークを OVN ベースで制御する
• Calico 以外の CNI を検証する
• ネットワークポリシーや経路制御の見通しを良くする
• 将来的な高可用性ネットワークの選択肢を確認する

kube-ovn 自体は、Kubernetes ネットワークを OVN / OVS ベースで扱うための CNI です。興味深い選択肢ですが、MicroK8s の既定 CNI やアドオン構成との関係を軽く見ない方がよいです。

addon の確認

まず、MicroK8s 側で利用できる addon と現在の状態を確認します。

microk8s status
microk8s kubectl get pods -A
microk8s kubectl get nodes -o wide

CNI は Pod ネットワークの根幹なので、既にクラスタが動いている状態で切り替えると、Pod、Service、DNS、MetalLB などに影響が出る可能性があります。

kube-ovn を有効化する前に見ること

• 現在の CNI が何か
• Pod CIDR と Service CIDR がどう設定されているか
• DualStack を有効化しているか
• MetalLB や Ingress を既に使っているか
• 既存 Pod を退避・再作成できる検証環境か

MicroK8s のネットワークは、通常の kubeadm クラスターと同じ感覚で差し替えられるとは限りません。特に DualStack や MetalLB を絡める場合、CNI だけでなく Service と外部公開の設計も一緒に見ます。

有効化で詰まった場合の切り分け

kube-ovn を有効化して期待どおりに動かない場合は、まず Pod とイベントを確認します。

microk8s kubectl get pods -A -o wide
microk8s kubectl get events -A --sort-by=.lastTimestamp
microk8s kubectl get nodes -o wide

CNI 関連 Pod が起動しない、CoreDNS が不安定になる、Service に到達できない、といった場合は、CNI の導入状態だけでなく、既存 CNI の残り方や kubelet 側のネットワーク設定も見ます。

CNI は後から気軽に切り替えるものではない

この検証で一番大きい教訓は、CNI は Kubernetes の部品ではなく土台だという点です。アプリケーションの addon のように追加・削除する感覚で扱うと、原因切り分けが難しくなります。

• CNI は Pod の IP アドレス割り当てに関わる
• Service 通信や DNS に影響する
• NetworkPolicy の実装主体になる
• DualStack の成立条件に関わる
• MetalLB や外部公開の挙動にも影響する

検証するならクリーンな環境がよい

MicroK8s で kube-ovn を検証するなら、既存クラスタに後付けするより、最初から検証用クラスタを作り、CNI をどうするかを決めてから進める方が安全です。

microk8s inspect
microk8s kubectl cluster-info
microk8s kubectl get svc -A

検証で何度も CNI を切り替える場合は、状態が残ることを前提にします。原因不明の挙動になったら、無理に復旧するよりクリーンな環境で再現する方が早いことがあります。

まとめ

MicroK8s で kube-ovn を有効化する検証は、単に addon を有効にする話ではなく、Kubernetes の CNI をどう設計するかという話です。特に DualStack、MetalLB、Service、NetworkPolicy を含めると、CNI の選択はクラスタ全体の設計に直結します。

当時の検証では期待どおりに進みませんでしたが、その失敗自体は意味があります。MicroK8s は手軽ですが、ネットワーク基盤を深く触る場合は、最初から CNI と IP 設計を決めたクリーンな環境で検証する方がよいです。

関連記事

• MicroK8s で IPv6/IPv4 デュアルスタックが動かない時に見ること
• MicroK8s MetalLB speaker が socket permission denied を出す場合の確認
• Kubernetes Calico eBPF の設計メモ – kube-proxy 代替、DualStack、高可用性をどう見るか
• Kubernetes クラスター構築 – kubeadm で controlPlaneEndpoint と CNI を整理する
• Ubuntu 22.04 Kubernetes クラスター構築の事前準備 – kubeadm ノードの前提を整える

Related posts:

Kubernetes クラスター構築 – kubeadm で controlPlaneEndpoint と CNI を整理する Kubernetes Calico eBPF の設計メモ – kube-proxy 代替、DualStack、高可用性をどう見るか Ubuntu 20.04 MicroK8s の初期設定と DNS addon の確認 Ubuntu 20.04 MicroK8s MicroK8s MetalLB speaker が socket permission denied を出す原因 – L2 / 権限 / ホストネットワークを切り分ける Ubuntu 26.04 MicroK8s の基本 MicroK8s で IPv6/IPv4 デュアルスタックが動かない時に見ること Ubuntu 22.04 Kubernetes 管理ツールのインストール – kubectl / Helm / calicoctl を整理する Ubuntu 22.04 Kubernetes Cilium 導入の事前確認 Kubernetes で systemd を実行可能な CentOS コンテナを動かす Ubuntu 22.04 Kubernetes クラスター構築の事前準備 – kubeadm ノードの前提を整える Helm は Apt や DNF のようにはならない