Kubernetes のネットワーク構成として、Calico eBPF を使う場合の考え方を整理します。この記事は、単純な導入手順ではなく、kube-proxy 代替、DualStack、Control Plane 冗長化、CNI / CSI まで含めた設計メモです。
Calico eBPF は「速そうだから入れる」だけでは少し危うい機能です。Kubernetes の Service、NodePort、外部通信、送信元アドレス、ネットワークポリシーの扱いに関わるため、クラスタ全体のネットワーク設計として見る必要があります。
eBPF を Kubernetes ネットワークで使う意味
eBPF は Linux カーネル内で小さなプログラムを実行し、ネットワーク処理や観測、セキュリティ制御を行う仕組みです。Kubernetes の文脈では、Service 転送、Pod 間通信、ネットワークポリシー、可観測性の領域で使われます。
- カーネル空間で効率的にネットワーク処理できる
- kube-proxy の iptables / IPVS ベースの処理を置き換えられる
- 送信元アドレスや外部通信の扱いを設計し直せる
- ネットワークポリシーや観測との関係が深い
- CNI の単なるオプションではなくクラスタ設計の一部になる
Calico eBPF の位置づけ
Calico eBPF データプレーンでは、従来の kube-proxy による Service 転送を Calico 側で置き換えられます。これにより、iptables ルールの肥大化や転送経路の複雑さを抑えられる可能性があります。
ただし、kube-proxy を置き換えるということは、Service の挙動を担う責務が変わるということです。障害時の切り分けも、iptables や IPVS だけを見るのではなく、Calico 側の状態を含めて確認する必要があります。
kube-proxy 代替として見る
Calico eBPF を使う場合、重要なのは「kube-proxy を無効化するか」「Service 転送を誰が担当するか」です。ここが曖昧なまま導入すると、問題が発生したときに見るべき場所が分からなくなります。
kubectl -n kube-system get daemonset
kubectl -n kube-system get pods -o wide
kubectl get svc -Akube-proxy、Calico node、Service、Endpoint の状態をまとめて確認し、Service 通信がどの経路で処理されているかを意識します。
DualStack はアドレスが付けば終わりではない
IPv4 / IPv6 DualStack では、Pod と Service に IPv4 / IPv6 のアドレスが付くだけでは不十分です。Service、CNI、外部経路、DNS、ロードバランサー、NetworkPolicy が DualStack 前提で動くかを見る必要があります。
- Pod CIDR と Service CIDR の IPv4 / IPv6 を決める
- CNI が DualStack に対応しているか確認する
- Service の
ipFamilyPolicyとipFamiliesを確認する - 外部から IPv6 で到達する経路を確認する
- NetworkPolicy が IPv4 / IPv6 の両方で意図どおり効くか確認する
高可用性ネットワークとして見る
Control Plane を冗長化し、API endpoint をロードバランサー配下に置き、CNI を Calico eBPF にする構成は、単なる機能追加ではありません。Kubernetes ネットワークの責務をどこに置くかという設計です。
API server の入口、Pod ネットワーク、Service 転送、外部公開、ストレージ接続を分けて考えると、障害時の切り分けがしやすくなります。
CNI と CSI を混同しない
元の記事では CNI と CSI も並べて扱っていました。どちらも Kubernetes の基盤要素ですが、責務は違います。CNI はネットワーク、CSI はストレージです。
- CNI は Pod ネットワークと NetworkPolicy を担当する
- CSI は PersistentVolume などのストレージ接続を担当する
- どちらもクラスタの可用性に影響する
- ただし障害時の確認ポイントは別である
確認するポイント
kubectl get nodes -o wide
kubectl get pods -n kube-system -o wide
kubectl get svc -A
kubectl get endpoints -A
kubectl get networkpolicy -ACalico eBPF を使う場合は、Calico の状態確認も必要です。環境によっては calicoctl や Calico の CRD を使って状態を確認します。
kubectl get tigerastatus -A
kubectl get ippools.crd.projectcalico.org -Aまとめ
Calico eBPF は、Kubernetes ネットワークを高性能化するための単なる追加機能ではなく、Service 転送やネットワークポリシーの責務を変える設計要素です。導入する場合は、kube-proxy、CNI、DualStack、外部公開、Control Plane 冗長化をまとめて見る必要があります。
特に DualStack や高可用性構成では、アドレスが付くことと通信が設計どおり成立することは別です。Calico eBPF を使うなら、Kubernetes ネットワーク全体の責務分離と確認ポイントを明確にしてから導入する方が安全です。
書籍
Kubernetes完全ガイド 第2版
Kubernetes の仕組み、リソース、ネットワーク、運用観点を体系的に確認したい場合の参考書籍です。価格や在庫はリンク先で確認してください。
Amazon で見るこのリンクは Amazon アソシエイトリンクです。
関連記事
- Kubernetes クラスター構築 – kubeadm で controlPlaneEndpoint と CNI を整理する
- Ubuntu 22.04 Kubernetes クラスター構築の事前準備 – kubeadm ノードの前提を整える
- Ubuntu 22.04 containerd の設定 – Kubernetes ノード向けに SystemdCgroup を有効化する
- MicroK8s で IPv6/IPv4 デュアルスタックが動かない時に見ること
- Ubuntu 22.04 MicroK8s kube-ovn 有効化の検証
Related posts:
MicroK8s kube-ovn 有効化の検証 – CNI を後から切り替える難しさ
Docker プロキシ設定 – systemd drop-in で daemon に proxy を設定する
Proxy 環境で apt-key adv –recv-keys がタイムアウトする原因 – GPG 鍵取得と外部通信を切り分ける
Ubuntu 22.04 Kubernetes 管理ツールのインストール – kubectl / Helm / calicoctl を整理する
Kubernetes Helmの導入
Kubernetes MetalLB導入 Helm版
Kubernetes 1 つの Pod 内で複数の CentOS コンテナを実行する
Kubernetes Nginx コンテナと Service NodePort
Kubernetes Nginx コンテナと Service LoadBalancer
Kubernetes Multus がうまく動かない時に考えること – CNI を複数持つ難しさ
Kubernetes を前提とした仮想 アーキテクチャの考察
Kubernetes kubeconfig の管理