オンプレミス Kubernetes で Calico を使う場合、単に CNI を入れるだけでは設計が完結しません。Operator で Calico を導入する層、クラスタ全体の基本設定を持つ層、外部ネットワークへ経路を伝える BGP の層を分けて見る必要があります。
この記事では、Calico eBPF を kube-proxy 代替として見る時に、どの責務をどこで確認するかを扱います。具体的なクラスタ名や内部設定ではなく、運用時に判断しやすい分け方を中心にします。
Calico を 3 つの層で見る
Calico は Kubernetes の Pod ネットワークを作る部品ですが、実際の運用では複数の責務を持ちます。導入、基本設定、経路広告を一つの作業として扱うと、障害時にどこを疑うべきか分かりにくくなります。
| 層 | 主な役割 | 確認すること |
|---|---|---|
| 導入層 | Calico Operator、Installation、API Server を配置する | Operator が正常か、Installation が意図した状態か |
| 基本設定層 | IPPool、encapsulation、eBPF、kube-proxy 代替などのクラスタ方針を持つ | Pod CIDR、Service 処理、ノード間通信の前提 |
| BGP 層 | 外部ルーターや上位ネットワークへ経路を伝える | BGPPeer、BGPConfiguration、IPv4/IPv6 peer の定義 |
この分け方にすると、Pod 間通信の問題、Service 転送の問題、外部からの到達性の問題を同じ場所で追わずに済みます。Calico eBPF を有効にしている場合でも、BGP の peer 設定や外部経路広告は別の論点として見ます。
Operator と Installation で見ること
Operator ベースの Calico では、まず Operator 自体と Installation リソースを確認します。CNI の Pod が起動しているかだけでなく、Operator がクラスタにどの状態を作ろうとしているかを見ることが重要です。
kubectl get tigerastatus
kubectl get installation,apiserver -A
kubectl get pods -n tigera-operator
kubectl get pods -n calico-systemここで見るのは、Pod の数そのものよりも、Operator が期待するリソースを作れているか、Calico の各コンポーネントが degraded になっていないかです。特定ノードだけ問題が出る場合は、ノード側のカーネル設定、NIC、MTU、iptables/nftables の状態も合わせて確認します。
eBPF と kube-proxy 代替を分ける
Calico eBPF を使うと、Service のデータプレーンにも関わります。そのため、CNI の問題と Service 転送の問題を分けて考える必要があります。Pod 間通信は成立しているが Service 経由だけ失敗する場合、Pod ネットワークそのものではなく Service 処理側を疑います。
- Pod IP どうしの通信が成立するかを見る
- ClusterIP 経由の通信が成立するかを見る
- NodePort や LoadBalancer 経由で送信元アドレスがどう見えるかを見る
- kube-proxy を使う構成なのか、Calico eBPF に寄せる構成なのかを確認する
kube-proxy 代替は便利ですが、問題の見方も変わります。Service の負荷分散、NodePort、externalTrafficPolicy、送信元 IP の見え方は、CNI、Service、BGP の境界をまたぐため、どの層の話かを明確にしてから調べます。
BGP は外部公開のための別レイヤーとして見る
BGP は Pod ネットワークや Service 処理そのものとは別に、経路を外部へ伝えるための層です。Calico が BGP を扱えるからといって、MetalLB や LoadBalancer Service の役割が自動的に消えるわけではありません。
kubectl get bgpconfiguration,bgppeer -A
kubectl describe bgpconfiguration default
kubectl get nodes -o wideBGPPeer は、どの相手にどの AS 番号で接続するかを持ちます。IPv4 と IPv6 の peer を分けている場合は、それぞれに名前、peer IP、AS 番号、到達性が必要です。Service 公開で問題が出ている時は、Service オブジェクト、Calico の BGP 設定、上位ネットワーク側の経路受信を分けて確認します。
障害時に見る順番
Calico まわりの障害では、最初から BGP や eBPF を疑うより、層ごとに切り分ける方が早いです。Pod が起動しないのか、Pod 間通信だけが失敗するのか、Service 経由だけが失敗するのか、外部からだけ到達しないのかで見る場所が変わります。
- Operator と Installation が正常か確認する
- Calico の Pod が全ノードで期待どおり起動しているか確認する
- Pod IP どうしの通信を確認する
- ClusterIP、NodePort、LoadBalancer の順に入口を広げて確認する
- BGP peer と上位ネットワーク側の経路受信を確認する
この順番にすると、CNI の導入失敗、Service データプレーンの問題、外部経路広告の問題を混ぜずに扱えます。特にオンプレミス環境では、Kubernetes の中で見える状態と、物理ネットワーク側で見える経路が一致しているかを最後に確認する必要があります。
運用で固定しておきたい判断
Calico を運用する時は、設定値そのものよりも、どの判断を固定するかが重要です。eBPF を使うのか、kube-proxy を残すのか。BGP でどこまで経路広告するのか。IPv6 を同時に扱うのか。これらを記事や手順の中で曖昧にすると、障害時の確認順が揺れます。
- Calico Operator で管理する範囲を決める
- CNI の基本設定と BGP 設定を分けて管理する
- eBPF を Service データプレーンの選択として扱う
- 外部公開は Service、MetalLB、BGP、上位ネットワークの責務に分ける
- 変更後は Pod、Service、BGP の順に状態を確認する
Calico eBPF は Kubernetes ネットワークを高速化する機能としてだけ見るより、Service 処理と経路設計をどこに持たせるかという設計判断として見た方が運用しやすくなります。
Kubernetes完全ガイド 第2版
Kubernetes のネットワーク、Service、Pod、クラスタ運用を体系的に確認したい場合の参考書籍です。価格や在庫はリンク先で確認してください。
Amazon で見るこのリンクは Amazon アソシエイトリンクです。
関連記事
MicroK8s で kube-ovn を有効化する – CNI を後から切り替える難しさ
Kubernetes Multus がうまく動かない時に考えること – CNI を複数持つ難しさ
Kubernetes NetworkPolicy で Pod のアウトバウンド通信を制御する – egress と CNI を分けて考える
Kubernetes クラスター構築 – kubeadm で controlPlaneEndpoint と CNI を決める
Kubernetes に LoadBalancer はないのか – Service、MetalLB、CNI BGP を分けて考える
Kubernetes Multus の導入 – Pod に複数 NIC を接続する
Kubernetes で送信元アドレスが変わる問題 – externalTrafficPolicy、hostNetwork、BGP 経路広告で考える
MicroK8s で IPv6 / IPv4 デュアルスタックが動かない時に見ること