Kubernetesの深淵をちょこっとCNIから覗く

2025/12/17 (水) 19:00~20:00 開催のTech Playでの登壇資料です。
イベントURLはこちらです。https://techplay.jp/event/989006

KubernetesはLinuxの機能を利用していますが、Linux側の知識とKubernetes側の知識を適切に紐づけできていますか？
登壇者は「低レイヤーを抽象化していると言われているKubernetes」に対して、「そもそも低レイヤーを理解してKubernetesを利用しているのか？」と疑問に思い、プロジェクトで経験した障害事例をもとに、ネットワーク周りを解説しています。

Transcript

1. Kubernetesの深淵を ”ちょこっと”CNIから覗く 1
2. 自己紹介 受 賞 者 一 覧 Google Cloud Partner Top Engineer 2026 さ ん の 記 事 一 覧 terrako | Zenn 所属・氏名 ✓ NTTデータ 小野寺晃汰 経歴 ✓ 2022入社 (4年目) ✓ Google Cloud Partner Top Engineer 2026選出いただきました。 ✓ Google Cloud Partner Top Engineer 2026 受賞者一覧 ✓ 来年も選出いただけるように精進していきます。 好きな Google Cloud サービス ✓ Cloud Run (最近Sidecarも導入できるようになってうれしい) ✓ GKE (一番業務で使っているが、とても深淵) Xなど ✓ @teratech__ ✓ Zenn (terrakoさんの記事一覧 | Zenn) 2
3. Agenda 1. 発表の目的と背景 2. Kubernetesとは？ 3. CNIとは 4. Kubernetesの深淵を”ちょこっと” CNI から覗く 5. まとめ
4. 01 発表の目的と背景
5. 5 1. 発表の目的と背景 ある飲み会にて... 新卒から低レイヤーを抽象化したK8sを理 解しながら触ってるなんてすごいね！！！
6. 6 1. 発表の目的と背景 ある飲み会にて... 新卒から低レイヤーを抽象化したK8sを理 解しながら触ってるなんてすごいね！！！ 本当に理解して 触っているのか？？？？？
7. 7 1. 発表の目的と背景 「Kubernetesは低レイヤーを抽象化する」... しかし、その “低レイヤー” 知らないまま、クラウドエンジニアとして本当にこの技術を使いこなせているのだろうか？ • 自身がK8s(Google Cloud)を新卒から触っている状況で、「K8sは低レイヤーを抽象化しているものである」と言われたが、 そもそも低レイヤーを抽象化しているという感覚に危機感を覚えた。 • クラウドネイティブれに付随するコンテナやK8sの技術は高度化しているが、それらの技術によってより 低レイヤーのコンポーネントが隠蔽されていて、理解する機会がめっきり減っていると思っている。 • クラウドネイティブが叫ばれているが、そもそもの基盤の部分を本当に理解できているのか？ • 今まで、根本から理解する機会がないまま来てしまったが、そこまで困ったことはない。 • 一方で、今後さらに自身のエンジニア力を上げるためには、Linuxなどの低レイヤーの理解は必須に思える。(何度も書い ているが基盤となる技術であるため) • プロジェクト内のある障害が発生し、 低レイヤーの知識とKubernetesの理解が紐づいていないと、高度なトラブルシュートは実践できないと悟った。 • プロジェクト内の “つよつよ” エンジニアがさっと原因特定し、解決策を提示していた。
8. 8 1. 発表の目的と背景 Kubernetesのロゴの正体 (個人の見解)
9. 9 1. 発表の目的と背景 Kubernetesのロゴの正体 (個人の見解) Kubernetesを操縦することで、 Linuxという海を乗りこなせている(はず)。 しかし、海の全容は知っているのか？？？ プラットフォーム構築/運用者は隠蔽された コンポーネントを何も理解しなくてよいのか？ “井の中の蛙大海を知らず”状態になっていないか？
10. 02 Kubernetesとは？
11. 11 2. Kubernetesとは？ Kubernetesは何者であり解決するものは何か？ “ Kubernetes is a portable, extensible, open source platform for managing containerized workloads and services that facilitate both declarative configuration and automation. It has a large, rapidly growing ecosystem. Kubernetes services, support, and tools are widely available.” Overview | Kubernetes What is “Kubernetes”? Kubernetesは、宣言的な構成管理と自動化を促進し、コンテナ化されたワークロードやサービスを管理するための、ポータブルで拡張性の あるオープンソースのプラットフォーム。Kubernetesは巨大で急速に成長しているエコシステムを備えており、それらのサービス、サポート、ツール は幅広い形で利用可能。
12. 12 2. Kubernetesとは？ Kubernetesは何者であり解決するものは何か？ What is “Kubernetes”? Kubernetesは単なる「コンテナオーケストレーター」以上の存在。物理/仮想のコンピューティング、ネットワーク、ストレージインフラストラクチャの オーケストレーション負担を排除し、アプリケーション運用者や開発者がセルフサービス運用においてコンテナ中心のプリミティブに完全に集中 できるようにすることを目指す。 “ Kubernetes is more than just a “container orchestrator”. It aims to eliminate the burden of orchestrating physical/virtual compute, network, and storage infrastructure, and enable application operators and developers to focus entirely on container-centric primitives for self-service operation.” design-proposals-archive/architecture/architecture.md at main · kubernetes/design-proposals-archive
13. 13 2. Kubernetesとは？ Kubernetesの特徴とは？ 宣言的な構成管理 「何を」したいか宣言すれば、理想の状態を自動で実現してくれる。 ユーザーは “望ましい状態” を定義すれば、Kubernetesが自動で望ましい状態へ管理してくれる。 自動化 コンテナ運用に必要な多くの作業を自動化する。 自動化により、運用負荷が大幅に削減されたプラットフォームを実現する。 充実したエコシステム Kubernetes自体はコンテナのオーケストレーションというコア機能に特化したプラットフォームである。 実際のアプリケーション運用(DB/監視)に必要なミドルウェアやツールは3rd party製品を組み込む設計思想となっている。
14. 14 2. Kubernetesとは？ Kubernetesの特徴 アプリケーション開発者は Kubernetes以下のレイヤーを 気にすることなく開発に集中できる！！ (Kubernetes内のリソースやコンテナ開発) 完全に隠蔽されていることはないが、 かなり抽象化された状態で利用していることになる。
15. 03 CNIとは
16. 16 3. CNIとは Kubernetesにおける”抽象化”と”拡張性” Kubernetesでは定義されたインターフェースに則り、命令を下しており”実行”自体は各コンポーネントが実行している。 実行”方法”は各コンポーネントごとに実装が異なり、設計タイミングで選択することが可能。 ユーザーが “望ましい状態” を定義 定義された状態をもとに 各コンポーネントに命令 実際の実行は各コンポーネントに委任
17. 17 3. CNIとは Kubernetesにおける”抽象化”と”拡張性” Kubernetesでは定義されたインターフェースに則り、命令を下しており”実行”自体は各コンポーネントが実行している。 実行”方法”は各コンポーネントごとに実装が異なり、設計タイミングで選択することが可能。 CRI (Container Runtime Interface) インターフェースの仕様 (gRPCベースのAPI) に則り、 「Podを作成せよ」「コンテナを開始せよ」といった命令を出 すのみ。 CSI (Container Storage Interface) 「ボリュームを作成せよ」「Nodeへボリュームをアタッチせよ」 といった命令を出すのみ。 CNI (Container Network Interface) 「PodにIPを割り当てよ」「異なるNodeに通信できるように 設定せよ」といった命令を出すのみ。
18. 18 3. CNIとは Kubernetesにおける”抽象化”と”拡張性” Kubernetesでは定義されたインターフェースに則り、命令を下しており”実行”自体は各コンポーネントが実行している。 実行”方法”は各コンポーネントごとに実装が異なり、設計タイミングで選択することが可能。 CRI (Container Runtime Interface) インターフェースの仕様 (gRPCベースのAPI) に則り、 「Podを作成せよ」「コンテナを開始せよ」といった命令を出 すのみ。 CSI (Container Storage Interface) 「ボリュームを作成せよ」「Nodeへボリュームをアタッチせよ」 といった命令を出すのみ。 CNI (Container Network Interface) 「PodにIPを割り当てよ」「異なるNodeに通信できるように 設定せよ」といった命令を出すのみ。
19. 19 3. CNIとは Kubernetesにおける”抽象化”と”拡張性” Kubernetesでは定義されたインターフェースに則り、命令を下しており”実行”自体は各コンポーネントが実行している。 実行”方法”は各コンポーネントごとに実装が異なり、設計タイミングで選択することが可能。 CRI (Container Runtime Interface) インターフェースの仕様 (gRPCベースのAPI) に則り、 「Podを作成せよ」「コンテナを開始せよ」といった命令を出 すのみ。 CSI (Container Storage Interface) 「ボリュームを作成せよ」「Nodeへボリュームをアタッチせよ」 といった命令を出すのみ。 CNI (Container Network Interface) 「PodにIPを割り当てよ」「異なるNodeに通信できるように 設定せよ」といった命令を出すのみ。 本セクションでは CNI (Container Network Interface) について障害事例をもとに簡単に解説する。
20. 04 Kubernetesの深淵を ”ちょこっと” CNI から覗く
21. 4. Kubernetesの深淵を”ちょこっと” CNI から覗く プロジェクト超概要 21
22. 4. Kubernetesの深淵を”ちょこっと” CNI から覗く プロジェクト超概要 GKEをマルチテナントで利用おり、 様々なサービスが共通のGKE上で稼働している GKE内のメトリクス・トレースは Datadog Agentを経由して取得 22
23. 23 4. Kubernetesの深淵を”ちょこっと” CNI から覗く 事例紹介: トレースデータ欠損 (エグゼクティブサマリー) 事象 (Incident) 2024/05 Datadog Agentの アップグレード後、本番環境で稼働する GKE Nodeでトレースデータが取得不能 になった。 影響 (Impact) トレースデータを利用した監視・発報機能 が停止。直接的なサービス影響はなかった ものの、システム全体の可観測性が大幅 に低下した。 直接原因 (Direct Cause) GKE Nodeのiptablesに、削除されるべ き古いDatadog Agent PodのIPアドレ スへのDNATルールが残存。これにより、 新しいAgent Podへの通信が阻害された。 根本原因 (RootCause) 障害発生の約2週間前にcalico-node が自動アップグレードされ、一部のNodeの iptablesに不整合を引き起こしていた。 この潜在的な問題が、hostPortを利用 するDatadog Agentの再デプロイによっ てはじめて顕在化した。
24. 24 4. Kubernetesの深淵を”ちょこっと” CNI から覗く 障害対応タイムライン GKE/Calico 自動アップグレード (潜在的な問題の発生) Datadog Agent リリース →トレース情報欠損 (事象発生) Agent切り戻し実施 →事象解消せず 正常/異常Node間の `iptables`差分発見 (原因特定) QA/Stage環境で 再現・対策検証 本番環境へ対策適用 →完全復旧 約2週間 約2日
25. 25 4. Kubernetesの深淵を”ちょこっと” CNI から覗く 障害対応タイムライン GKE/Calico 自動アップグレード (潜在的な問題の発生) Datadog Agent リリース →トレース情報欠損 (事象発生) Agent切り戻し実施 →事象解消せず 正常/異常Node間の `iptables`差分発見 (原因特定) QA/Stage環境で 再現・対策検証 本番環境へ対策適用 →完全復旧 約2週間 約2日 Kubernetesにおける`iptables`について 簡単に解説しながら、原因を紐解いていく
26. 26 4. Kubernetesの深淵を”ちょこっと” CNI から覗く アップグレードと切り戻し 定型運用作業であるDatadog Agentのアップグレード • Datadog Agentを`3.54.1`→`3.59.6`へアップグレード • アップグレード直後、トレースデータが大幅に欠損 切り戻し • Datadog Agentのアップグレード直後に発生したため、アップグレード起因と判断し、バージョンの切り戻しを実施。
27. 27 4. Kubernetesの深淵を”ちょこっと” CNI から覗く アップグレードと切り戻し 定型運用作業であるDatadog Agentのアップグレード • Datadog Agentを`3.54.1`→`3.59.6`へアップグレード • アップグレード直後、トレースデータが大幅に欠損 切り戻し • Datadog Agentのアップグレード直後に発生したため、アップグレード起因と判断し、バージョンの切り戻しを実施。 事象は解消せず
28. 28 4. Kubernetesの深淵を”ちょこっと” CNI から覗く “Healthy”/”Unhealthy” Node ＊Node自体がUnhealthyでないことに注意。あくまでも、トレースが送信できないことを”Unhealth”としている。 • ほとんどのNodeでトレースデータが欠損していたが、特定の1つのNodeでは正常にトレースデータを取得できていることを確認。 • Datadog ではなく、インフラ側 (GKE Node) の障害である可能性が高まった。 • タイムアウトのログが出力されていることを確認。
29. 29 4. Kubernetesの深淵を”ちょこっと” CNI から覗く “Healthy”/”Unhealthy” Node ＊Node自体がUnhealthyでないことに注意。あくまでも、トレースが送信できないことを”Unhealth”としている。 • ほとんどのNodeでトレースデータが欠損していたが、特定の1つのNodeでは正常にトレースデータを取得できていることを確認。 • Datadog ではなく、インフラ側 (GKE Node) の障害である可能性が高まった。 • タイムアウトのログが出力されていることを確認。 「ネットワーク周りが怪しい」感覚はあったが、次のアクションに詰まっていた
30. 30 4. Kubernetesの深淵を”ちょこっと” CNI から覗く CNIによるネットワークの抽象化とLinux Kernel • CNIはコンテナネットワークの構成を標準化するAPIインターフェースである。 • Pod作成時、kubelet は /etc/cni/net.d 内の構成ファイルを読み込み、対応するCNIプラグインのバイナリを実行する。 • kubeletはネットワーク設定をCNIプラグインに完全に委任する。 これにより、ユーザーは環境や要件に応じて様々なネットワークソリューション (Calico/Funnel/Cilium)を自由に選択・交換でき る。 解説
31. 31 4. Kubernetesの深淵を”ちょこっと” CNI から覗く 「Podが作成された」場合でもう少し中身を見ていくと... • kubeletがCNIバイナリを実行することで、「PodがCluster Network」に参加するための処理を実行する。 • Podに仮想NICを作成する。 • Node上で必要な処理を行う。 • Calicoではiptablesルール、ルーティングテーブルへの書き込みや別NodeへのBGP広報をする。 • FunnelではLinux Brdgeにvethをアタッチする。 • Podの仮想NICにIPアドレスを割り当てる。 解説
32. 32 4. Kubernetesの深淵を”ちょこっと” CNI から覗く 「Podが作成された」場合でもう少し中身を見ていくと... iptablesルール、ルーティングテーブルへの書き込み • API Serverを監視し、NetworkPolicyやエンドポイント情報を解釈。 • その結果をiptablesルール、ルーティングテーブルに変換し、書き込む。 別NodeへのBGP広報 • 作成されたPodのルート情報を別Nodeに経路広報する。 • BGPビアリングすることで、別Nodeへ通信可能となる。 解説
33. 33 4. Kubernetesの深淵を”ちょこっと” CNI から覗く 結局Pod間通信はどうなってる？ 5. 物理NICから送出 1. アプリケーションが パケット生成(eth0) 2. ホストの ネットワーク空間へ 3. ルーティングテーブル 参照 (BGPで学習済み) 4. `iptables FORWARD` チェーンでポリシー適用 6. 宛先Nodeで受信後、同様に ルーティングとポリシーチェックが行われ、 `veth`経由で宛先Podに届けられる。 解説
34. 34 4. Kubernetesの深淵を”ちょこっと” CNI から覗く Datadogの通信方法
35. 35 4. Kubernetesの深淵を”ちょこっと” CNI から覗く Datadogの通信方法 DNATを定義するのは誰...？
36. 36 4. Kubernetesの深淵を”ちょこっと” CNI から覗く Datadogの通信方法 そうですCalico (CNI) です！！！ DNATを定義するのは誰...？
37. 37 4. Kubernetesの深淵を”ちょこっと” CNI から覗く Calicoの役割
38. 38 4. Kubernetesの深淵を”ちょこっと” CNI から覗く Calicoの役割 GKE/Calicoの自動アップグレードにより、 Calicoにバグが混入していた。 バグにより、古いDatadog Agentへの DNATルールが削除されず、存在しない IPへトレースデータを送信していた。
39. 39 4. Kubernetesの深淵を”ちょこっと” CNI から覗く 答え合わせ Iptables not updating correctly for HostPort when using CNI chaining Portmap · Issue #18227 · cilium/cilium CNI Chaining利用時にHostPortを再起動すると、 古いiptablesルールが削除されない同様の問題が報 告されていた。 Googleサポートも、CNI設定の不整合 (host-local IPAMデータストア内の古いIP情報) が原因であると特 定。 “When restarting a pod with a HostPort... we noticed that sometimes, the old iptables rule is not deleted” “根本原因はGKE Node上のCNI設定、特にhost- local IPAMのデータストアに古いIP情報が残っているこ とだと特定されました。”
40. 4. Kubernetesの深淵を”ちょこっと” CNI から覗く 障害を通して... 状況証拠からマネージドな部分でも原因を特定可能 マネージドでクラウドプロバイダー側で抽象化されていたとしても、状況証拠から原因を特定することは可能。 原因特定は可能だが、各領域の深い知識と”点”を繋いで”線”にする力が必要 原因を特定するには、その製品に関する知識だけではなく、その領域関連の多くの知識が必要。 各領域の知識の “点” を繋いで “線” にすることで、より高度なトラブルシューティングを可能にする。 OSSにはGitHub Issueを有効活用せよ 世界中には同じバグを踏んだ人がいて、その中にも “つよつよ” エンジニアがいるので、参考にすべし。 これらのGitHub Issueを見つけ、判断材料とするにはマネージドで隠蔽されている部分も理解しておく必要はある。 40
41. 05 まとめ
42. 42 5. まとめ みなさん、大海は知れましたか？ 今回のCNIは大海のほんの一部であり、CNIの中でも一部の内容です。 Kubernetesを通じて、各領域の知識という “点” を繋いで “線” にしていければと思います。 (今後はKubernetesという船からもっと降りて、大海を泳いでいきたいです)
43. Thank You !! 43