Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
Kubernetes Networking 101
Search
Sponsored
·
Ship Features Fearlessly
Turn features on and off without deploys. Used by thousands of Ruby developers.
→
Kohei Ota
August 25, 2020
Technology
2.2k
10
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
Kubernetes Networking 101
Kohei Ota
August 25, 2020
More Decks by Kohei Ota
See All by Kohei Ota
CloudNative Meets WebAssembly: Exploring Wasm's Potential to Replace Containers
inductor
4
3.5k
The Cloud Native Chronicles: 10 Years of Community Growth Inside and Outside Japan
inductor
0
180
Cracking the KubeCon CfP
inductor
2
880
KubeCon Recap -Platform migration at Scale-
inductor
1
1.1k
コンテナビルド最新事情 2022年度版 / Container Build 2022
inductor
3
600
データベースとストレージのレプリケーション入門 / Intro-of-database-and-storage-replication
inductor
28
6.6k
KubeConのケーススタディから振り返る、Platform for Platforms のあり方と その実践 / Lessons from KubeCon case studies: Platform for Platforms and its practice
inductor
3
980
オンラインの技術カンファレンスを安定稼働させるための取り組み / SRE activity for online conference platform
inductor
1
1.4k
Kubernetesネットワーキング初級者脱出ガイド / Kubernetes networking beginner's guide
inductor
22
7.6k
Other Decks in Technology
See All in Technology
200個のGitHubリポジトリを横断調査したかった
icck
0
130
「エンジニア進化論」2028年の開発完全自動化、エンジニアはどう進化するか
cyberagentdevelopers
PRO
6
5.3k
現地で盛り上がった WWDC26 Keynote
zozotech
PRO
1
250
Claude Codeをどのように キャッチアップしているか
oikon48
13
8.2k
プロダクト開発から業務改善コンサルまで。事業全体へ「染み出す」ことで広がるエンジニアの可能性
ham0215
0
130
SONiCのLinuxベースを活かしたZabbix監視
sonic
0
180
気づかぬうちにセキュリティ負債を生むAPIキー運用
sgwrmctk
0
140
あなたの知らないPDFのアクセシビリティ
lycorptech_jp
PRO
0
200
AWS Security Agent といっしょに脅威モデリングをやってみよう
amarelo_n24
0
100
【セミナー資料】Claude Code をセキュアに使うための考え方と設定の勘どころ / Claude Code Webinar 20260616
masahirokawahara
2
360
エンジニアリング戦略の作り方 / Crafting Engineering Strategy
iwashi86
21
7k
RAG を使わないという選択肢
tatsutaka
1
250
Featured
See All Featured
The SEO Collaboration Effect
kristinabergwall1
1
490
Color Theory Basics | Prateek | Gurzu
gurzu
0
360
What the history of the web can teach us about the future of AI
inesmontani
PRO
1
610
Applied NLP in the Age of Generative AI
inesmontani
PRO
4
2.3k
Crafting Experiences
bethany
1
180
Building Adaptive Systems
keathley
44
3.1k
Taking LLMs out of the black box: A practical guide to human-in-the-loop distillation
inesmontani
PRO
3
2.3k
Groundhog Day: Seeking Process in Gaming for Health
codingconduct
0
210
The Power of CSS Pseudo Elements
geoffreycrofte
82
6.3k
XXLCSS - How to scale CSS and keep your sanity
sugarenia
250
1.3M
HDC tutorial
michielstock
2
710
From Legacy to Launchpad: Building Startup-Ready Communities
dugsong
0
230
Transcript
Kubernetes Networking 101 Kubernetes Novice Tokyo #4 Presented by @inductor
自己紹介 名前: 太田 航平 (@inductor) 所属: HPE 役職: ソリューションアーキテクト Kubernetes
SIG-Docs Japanese localization owner Cloud Native Ambassador Docker Meetup Tokyo、CNDT2020運営
Kubernetesのネットワークは複雑
ていうか、そもそもコンテナの ネットワークが複雑!
今日のゴール • Dockerのネットワークがわかる • DockerとKubernetesのなりたちの違いがわかる ◦ DockerとKubernetesのネットワーク的な要件の違い • Kubernetesでネットワークをつなげる仕組みの登場人物がわかる →
コンテナネットワーク完全に理解した
アジェンダ • Dockerのネットワーク ◦ コンテナとネットワークの関係 • Kubernetesのネットワーク ◦ DockerとKubernetesのネットワーク要件の違い ▪
Docker→Kubernetesに思考を引き上げる場合に生まれるネットワークの問題 ▪ Kubernetesでの解決策 • Kubernetesのネットワークを形作るコンポーネントとその役割 ◦ kube-proxy ◦ CNI ▪ よく使われるCNIの特徴
Dockerのネットワーク
Dockerのよくあるユースケース Docker Compose 80:80 3000 3306
Dockerのよくあるユースケース Docker Compose 80:80 3000 3306 Webなので公開 アプリは 内部だけ DBは
内部だけ
Dockerとネットワーク、ボリューム Volume Volume Volume Docker Volume Docker Container Docker Network
docker0 bridge ローカルの80 仮想NIC 仮想NIC 仮想NIC 10.0.0.0/24 172.16.0.0/24
ネットワークとボリュームは外部割り当て? Volume Volume Volume Docker Volume Docker Container Docker Network
docker0 bridge ローカルの80 仮想NIC 仮想NIC 仮想NIC 10.0.0.0/24 172.16.0.0/24
ネットワークとボリュームは外部割り当て Volume Volume Volume Docker Volume Docker Container Docker Network
docker0 bridge ローカルの80 仮想NIC 仮想NIC 仮想NIC
ネットワークとボリュームは外部割り当て Volume Volume Volume Docker Volume Docker Container Docker Network
docker0 bridge ローカルの80 仮想NIC 仮想NIC 仮想NIC Kubernetes Novice Tokyo #2 のセッション資料が詳しいので 合わせてご覧ください
Dockerネットワークの種類 • bridge - 指定がない場合にデフォルトで使用 ◦ 所属するコンテナが直接通信でき、お手軽 • macvlan -
macvlanが使える ◦ 仮想NICにMACアドレスが持てる ◦ VMから移行したい場合などに使えるかも?ただし ホストのNICが使えなくなる制限有 • none - 「何も繋がない」ができる ◦ loopback(127.0.0.1)以外に仮想NICが繋がらないモード • Network plugins - その他サードパーティのプラグインを使う場合 ◦ プラグイン自体とても少なく利用例が ほとんどない
コンテナとネットワークの関係
を話す前にコンテナの仕組みを さらっと復習します
コンテナの仕組み / /home /var /tmp /var/a /var/b /var/c /tmp/d ここに、あるLinuxホストのファイルシステムがあります
コンテナの仕組み / /home /var /tmp /var/a /var/b /var/c /tmp/d /
/ / / pivot_root pivot_root pivot_root pivot_root あるディレクトリをルートに見せかける pivot_root
コンテナの仕組み / /home /var /tmp /var/a /var/b /var/c /tmp/d /
/ / / namespace namespace namespace namespace ユーザーIDやNW、プロセス空間などを分離する namespace root 10.0.0.1/24 root 10.0.0.2/24 root 10.0.0.3/24 root 10.0.0.3/24
コンテナの仕組み / /home /var /tmp /var/a /var/b /var/c /tmp/d /
/ / / 各領域のCPU、メモリリソースなどを cgroupで制限 root 10.0.0.1/24 root 10.0.0.2/24 root 10.0.0.3/24 root 10.0.0.3/24 1CPU 2GB 1CPU 2GB 1CPU 2GB 2CPU 4GB
コンテナの仕組み / /home /var /tmp /var/a /var/b /var/c /tmp/d /
/ / / アプリケーションが動作するために必要なファイルたちを tar.gz形式でパッケージングしてこいつらの上にのっけて ... root 10.0.0.1/24 root 10.0.0.2/24 root 10.0.0.3/24 root 10.0.0.3/24 1CPU 2GB 1CPU 2GB 1CPU 2GB 2CPU 4GB nginx on Ubuntu Node on Alpine Ruby on CentOS Debian
/var /tmp コンテナの仕組み / /home /var/a /var/b /var/c /tmp/d /
/ / / 展開したファイルシステムの実行ファイルをプロセスとして起動! 1CPU 2GB 1CPU 2GB 1CPU 2GB 2CPU 4GB nginx on Ubuntu Node on Alpine Ruby on CentOS Debian root 10.0.0.1/24 root 10.0.0.2/24 root 10.0.0.3/24 root 10.0.0.3/24 プロセス起動!
/var /tmp コンテナの仕組み / /home /var/a /var/b /var/c /tmp/d /
/ / / 展開したファイルシステムの実行ファイルをプロセスとして起動! 1CPU 2GB 1CPU 2GB 1CPU 2GB 2CPU 4GB nginx on Ubuntu Node on Alpine Ruby on CentOS Debian root 10.0.0.1/24 root 10.0.0.2/24 root 10.0.0.3/24 root 10.0.0.3/24 プロセス起動! これ1つ1つがコンテナ
/var /tmp コンテナの仕組み / /home /var/a /var/b /var/c /tmp/d /
/ / / 展開したファイルシステムの実行ファイルをプロセスとして起動! 1CPU 2GB 1CPU 2GB 1CPU 2GB 2CPU 4GB nginx on Ubuntu Node on Alpine Ruby on CentOS Debian root 10.0.0.1/24 root 10.0.0.2/24 root 10.0.0.3/24 root 10.0.0.3/24 プロセス起動! これ1つ1つがコンテナ これがコンテナイメージね
Dockerコンテナとネットワークの関係 • コンテナはさまざまなリソースを隔離した結果生まれるもの ◦ ネットワークもその1要素で、 NICは付けたり付けなかったりできる • Noneドライバーを用いた場合、ネットワーク的に隔離されたコンテナができあが る •
ブリッジの場合は仮想スイッチにどんどん接続されて相互に接続ができる ◦ Dockerの内部DNSも勝手に参加するので、コンテナ名がついていれば名前で DNSも引ける ◦ 設定ファイルでdb:3306とかweb:80とかapp:3000みたいなことが書けるのはそのおかげ ◦ 簡易的ではあるがいわゆる「サービスディスカバリ」の一種
ここまでのまとめ • Dockerのネットワークとボリュームは外からアタッチすることができる ◦ docker volume, docker networkコマンドで確認してみてね! • ネットワーク機構にはいくつかの種類がある
◦ 要件に合わせて選択することが可能
Kubernetesのネットワーク
手元のKubernetesの中身を覗いてみる • 外部に公開しているLonghornのWeb UIは、TCPの80番でLoadBalancerが アタッチされている • でも、Dockerではポートの割り当てが発生していない ◦ なんで?
手元のKubernetesの中身を覗いてみる • 外部に公開しているLonghornのWeb UIは、TCPの80番でLoadBalancerが アタッチされている • でも、Dockerではポートの割り当てが発生していない ◦ なんで? こたえ:
Dockerのネットワークを使っていないから!!!
Kubernetesの仕組み • コンテナを中心とした「分散システム」 ◦ 複数のマシンリソース (物理/仮想マシン)をクラスターにまとめて、アプリケーションをいい感じに 動かす ◦ (設定次第だけど)どのマシンでコンテナが動いても「同じように」動作する必要がある →
マシンの持つネットワークに依存しない透過的なネットワークが必要 それが理由で、Kubernetesのネットワークの基本はOverlay network構成
Kubernetesの仕組み Pod Pod Pod Pod network(overlay) Service Network(overlay) Node Network(not
overlay) 普通のサーバーがつながる ネットワーク ClusterIPなどサービス間の 通信で使うネットワーク コンテナ(Pod)自体に IPアドレスを持たせるためのネッ トワーク kube-proxy CNI
Kubernetesの仕組み Pod Pod Pod Node Network(not overlay) Pod network(overlay) Service
Network(overlay) 普通のサーバーがつながる ネットワーク ClusterIPなどサービス間の 通信で使うネットワーク コンテナ(Pod)自体に IPアドレスを持たせるためのネッ トワーク Podが入れ替わっても 同じように動作する Nodeが障害を起こすと Podは自動で退避 kube-proxy CNI
Kubernetesのネットワークコンポーネント • kube-proxy - 各ノードで動作 ◦ 各ノードでコンテナネットワークへの入り口を作る役割 ▪ 無いと、コンテナの外と中の経路が通らない ◦
Linuxのiptablesやipvsを利用(最近ではeBPFベースの実装もある ) ◦ Serviceの実装 ▪ https://github.com/kubernetes/kubernetes/blob/master/pkg/proxy/service.go • CNI(Container Network Interface) - クラスター全体で動作 ◦ Docker network driver相当のプラグイン機構を提供 ◦ Overlay Networkを提供 ◦ 外のネットワーク(プロトコル)とKubernetesのネットワークをつなげる ◦ 無いと、NodeのステータスがReadyにならない
Kubernetesのネットワークコンポーネント • kube-proxy ◦ 各ノードでコンテナネットワークへの入り口を作る役割 ◦ Linuxのiptablesやipvsを利用(最近ではeBPFベースの実装もある ) ◦ Serviceの実装
▪ https://github.com/kubernetes/kubernetes/blob/master/pkg/proxy/service.go • CNI(Container Network Interface) ◦ Docker network driver相当のプラグイン機構を提供 ◦ クラスター全体のOverlay Networkを提供 ◦ 外のネットワーク(プロトコル)とKubernetesのネットワークをつなげる ◦ 無いと、NodeのステータスがReadyにならない
Kubernetesのネットワークコンポーネント • kube-proxy ◦ 各ノードでコンテナネットワークへの入り口を作る役割 ◦ Linuxのiptablesやipvsを利用(最近ではeBPFベースの実装もある ) ◦ Serviceの実装
▪ https://github.com/kubernetes/kubernetes/blob/master/pkg/proxy/service.go • CNI(Container Network Interface) ◦ Docker network driver相当のプラグイン機構を提供 ◦ クラスター全体のOverlay Networkを提供 ◦ 外のネットワーク(プロトコル)とKubernetesのネットワークをつなげる ◦ 無いと、NodeのステータスがReadyにならない CNIでアタッチしたNIC kube-proxyでコンテナ外 からの通信を流す
いろいろなCNI • Calico ◦ 最も人気&歴史がある ◦ BGP(L3)ベースのネットワークでスケールしやすい • Cilium ◦
eBPFを用いた高パフォーマンス &スケーラブルなプラグイン ◦ 最近人気になってきた ◦ GKEでも最近導入がアナウンスされた • Weave Net • Amazon VPC CNI plugin
ここまでのまとめ • Kubernetesが複数マシンを束ねて動かすためにはOverlay networkが重要 • CNIはOverlay networkの構築と、Pod(コンテナ)にネットワークの機能を 与えるためのコンポーネント • kube-proxyは、ノードに流れてきたPod向け通信をPodに流す役割を持つ
ここまでのまとめ • Kubernetesが複数マシンを束ねて動かすためにはOverlay networkが重要 • CNIはOverlay networkの構築と、Pod(コンテナ)にネットワークの機能を 与えるためのコンポーネント • kube-proxyは、ノードに流れてきたPod向け通信をPodに流す役割を持つ
完全に理解できましたか?
(質問があれば)Q&Aタイム
おわり