整理しながら理解するKubernetesネットワークの仕組み / Kubernetes Network Fundamentals

Cloud Native Developers JP
整理しながら理解する
Kubernetesネットワークの仕組み
@hhiroshell
1

View Slide

宣伝
• COVID-19が収束したら遊舎⼯房に⾏くんだ…！
2
遊舎⼯房さんの店舗はこちら→
↓現在の@hhiroshellのキーボード #crkbd
⾃⼰紹介
@hhiroshell
早川博
（はやかわひろし）
• Cloud Nativeなインフラを開発
するエンジニア。
Yahoo Japan Corporation 所属
• エンジニアコミュニティ
「Cloud Native Developers JP」
オーガナイザー
• Developers Summit 2018
Japan Container Days 12.18
CloudNative Days Tokyo 2019 / 2020
登壇
• ⾃作キーボード沼

View Slide

⽬次
1. イントロダクション
2. Kubernetesのネットワークのアーキテクチャ
3. Cluster Network
4. kubeletとCNIプラグイン
5. Service Network
6. まとめ
3

View Slide

⽬次
3. Cluster Network
5. Service Network
6. まとめ
4

View Slide

Cloud Native Developers JP 5
いろいろな⽤語が出てきて把握しきれない…。
Kubernetesのネットワークは難しい
Services
Ingress
Endpoints
Endpoint Slices
iptables
Container Network Interface
CNI Plugin
veth
Bridge
Flannel
Calico kube-proxy
kubelet
User Space Proxy Mode
VXLAN
BGP
Cluster Networking Service Discovery
NIC
NAT
VPC
Network Namespace
IPAM
IP Address
Cluster IP
CoreDNS
Headless Service
Load Balancer
NodePort
IPVS proxy mode
Network Policy

View Slide

Cluster Networking …?
• Kubernetesのネットワークモデル
いきなり読んでもなかなか⾟い…。
6
Kubernetes imposes the following fundamental requirements on any networking implementation
(barring any intentional network segmentation policies):
1. pods on a node can communicate with all pods on all nodes without NAT
2. agents on a node (e.g. system daemons, kubelet) can communicate with all pods on that node
Note: For those platforms that support Pods running in the host network (e.g. Linux):
3. pods in the host network of a node can communicate with all pods on all nodes without NA
“
”
...

View Slide

このセッションのゴール
• Kubernetesのネットワークの全体像を理解する
• 様々な構成要素の役割と関係性を整理して把握する
• ネットワーク周りの挙動について、裏の仕組みをなんとなくでも説
明できるようになる
• ネットワーク周りのドキュメントの⾔っていることが理解できる様
になる。⾃⼒で学習を進められるようになる
Kubernetesのネットワークの仕組みを完全に理解する [^1]
7
[^1]:
ネットスラング的な意味の「完全に理解」の意 (c.f. https://twitter.com/ito_yusaku/status/1042604780718157824)

View Slide

⽬次
3. Cluster Network
5. Service Network
6. まとめ
8

View Slide

Kubernetesのネットワークを俯瞰して⾒てみる
1. Node Network
2. Pod Network / Cluster Network
4. Service Network
⼤雑把に4つに分けて考えるとよさそう
9
Node Node Node
NIC
NIC
NIC
Pod Pod Pod
VNIC VNIC VNIC
Pod Pod Pod
VNIC VNIC VNIC
Pod Pod Pod
VNIC VNIC VNIC
kubelet + CNI Plugin

View Slide

1/4: Node Network
• Kubernetesを構成するNodeが接続するネットワーク
– インフラによって実態は異なる
• ベアメタル、クラウドプロバイダが提供する仮想ネットワーク、...etc
10
Node Node Node
NIC
NIC
NIC
Pod Pod
VNIC VNIC
Pod Pod Pod
VNIC VNIC VNIC
Pod Pod Pod
VNIC VNIC VNIC

View Slide

2/4: Pod Network / Cluster Network
• Node Network上にソフトウェア的に構成される論理ネットワーク
– クラスター内の全Podが、互いのIPアドレスでNATなしで通信可能
• 他にも要件がある（後述）
11
Node Node Node
NIC
NIC
NIC
Pod Pod
VNIC VNIC
Pod Pod Pod
VNIC VNIC VNIC
Pod Pod Pod
VNIC VNIC VNIC

View Slide

3/4: kubeletとCNIプラグイン
• PodをCluster Networkに接続(?)させる役割を持つコンポーネント
– kubeletがPodを起動するときにCNIプラグインを実⾏することでこれを⾏って
いる
12
Node Node Node
NIC
NIC
NIC
Pod Pod Pod
VNIC VNIC VNIC
Pod Pod Pod
VNIC VNIC VNIC
Pod Pod Pod
VNIC VNIC VNIC
接続 !

View Slide

Node Node Node
NIC
NIC
NIC
Pod Pod
VNIC VNIC
Pod Pod Pod
VNIC VNIC VNIC
Pod Pod Pod
VNIC VNIC VNIC
Pod
VNIC
?
4/4: Service Network
• Podに対する通信において、以下のような機能を提供する
– 名前解決
– ロードバランシング
– サービスディスカバリ
13
例:ホスト名を名前解決。複数のPodにロードバランシング
ホスト名: backend.sockshop.svc にアクセス

View Slide

いったんまとめ: Kubernetesネットワークの4つの要素
1. Node Network
– Kubernetesを構成するNodeが接続するネットワーク
– Node Network上にソフトウェア的に構成される論理ネットワーク
– PodをCluster Networkに接続(?)させる役割を持つコンポーネント
4. Service Network
– 名前解決、ロードバランシング、サービスディスカバリ
⼤雑把に4つに分けて考えるとよさそう
14

View Slide

⽬次
3. Cluster Network
5. Service Network
6. まとめ
15

View Slide

Cluster Network
• Node Network上にソフトウェア的に構成される論理ネットワーク
– 公式ドキュメントの中で “Cluster Networking” と呼ばれているモノ
– クラスターを⾃⼒構築する場合、Flannel, Calicoなどのソフトウェアを使って構
築するのが⼀般的（Kubernetesの指定のものがあるわけではない）
16
Node Node Node
NIC
NIC
NIC
Pod Pod
VNIC VNIC
Pod Pod Pod
VNIC VNIC VNIC
Pod Pod Pod
VNIC VNIC VNIC
Pod
VNIC

View Slide

【再掲】Cluster Networking …!
• Kubernetesのネットワークモデル
少しわかったような気がしてくる…？
17
Kubernetes imposes the following fundamental requirements on any networking implementation
(barring any intentional network segmentation policies):
1. pods on a node can communicate with all pods on all nodes without NAT
2. agents on a node (e.g. system daemons, kubelet) can communicate with all pods on that node
Note: For those platforms that support Pods running in the host network (e.g. Linux):
3. pods in the host network of a node can communicate with all pods on all nodes without NAT
“
”
...

View Slide

• Flannel
– Linux BridgeとVXLANによるカプセル化を組
み合わせて、Nodeをまたぐ通信を抽象化
– シンプルな実装⽅式だが、カプセル化の
オーバーヘッドが性能に不利に働く
– Network Policyには⾮対応
– 現RedHat / CoreOS主体で開発されている
• https://github.com/coreos/flannel
• https://coreos.com/flannel/docs/latest/
• Calico
– BGPを利⽤するなどしてNodeをまたぐ通信
を実現
– パケットのカプセル化を⾏わない
– Network Policyに対応
– ⽶Tigera社メインで開発
• https://github.com/projectcalico/calico
• https://docs.projectcalico.org/about/about-calico
18
Cluster Networkの代表的な実装（個⼈の⾒解です）

View Slide

FlannelがどのようにCluster Networkを実現しているか
• 全てのPodの仮想NICをLinux Bridgeに接続
• 各NodeでLinux Bridgeによってサブネットが構成される
• Nodeをまたがる通信は、Flannelのデーモンプロセスによってカプセ
ル化されて他Nodeに透過的に送信される
19
Node
NIC
Pod Pod
veth0
Linux Bridge
veth1
veth0 veth1
Pod
veth3
veth3
Flannel
daemon
Node
NIC
Pod Pod
veth0
Linux Bridge
veth1
veth0 veth1
Pod
veth3
veth3
Flannel
daemon
Node
NIC
Pod Pod
veth0
Linux Bridge
veth1
veth0 veth1
Pod
veth3
veth3
Flannel
daemon
kubelet + CNI Plugin kubelet + CNI Plugin kubelet + CNI Plugin

View Slide

Nodeをまたがる通信の流れ
• 別のNode上のPodのIPアドレスに向けてパケットを送信
20
Node
NIC
Pod Pod
veth0
Linux Bridge
veth1
veth0 veth1
Pod
veth3
veth3
Flannel
daemon
Node
NIC
Pod Pod
veth0
Linux Bridge
veth1
veth0 veth1
Pod
veth3
veth3
Flannel
daemon
Node
NIC
Pod Pod
veth0
Linux Bridge
veth1
veth0 veth1
Pod
veth3
veth3
Flannel
daemon
192.168.1.2 192.168.2.2
192.168.2.2

View Slide

• Flannelのデーモンプロセスによって、宛先のPodが起動している
Node宛てとなるようにヘッダを追加する（VXLANのカプセル化）
21
Node
NIC
Pod Pod
veth0
Linux Bridge
veth1
veth0 veth1
Pod
veth3
veth3
Flannel
daemon
Node
NIC
Pod Pod
veth0
Linux Bridge
veth1
veth0 veth1
Pod
veth3
veth3
Flannel
daemon
Node
NIC
Pod Pod
veth0
Linux Bridge
veth1
veth0 veth1
Pod
veth3
veth3
Flannel
daemon
192.168.1.2 192.168.2.2
192.168.2.2
192.168.254.12

View Slide

• 宛先のノードにパケットが送られる
22
Node
NIC
Pod Pod
veth0
Linux Bridge
veth1
veth0 veth1
Pod
veth3
veth3
Flannel
daemon
Node
NIC
Pod Pod
veth0
Linux Bridge
veth1
veth0 veth1
Pod
veth3
veth3
Flannel
daemon
Node
NIC
Pod Pod
veth0
Linux Bridge
veth1
veth0 veth1
Pod
veth3
veth3
Flannel
daemon
192.168.1.2 192.168.2.2
192.168.2.2
192.168.254.12

View Slide

• 宛先Node側のFlannelのデーモンプロセスによって、カプセル化が解
除される
23
Node
NIC
Pod Pod
veth0
Linux Bridge
veth1
veth0 veth1
Pod
veth3
veth3
Flannel
daemon
Node
NIC
Pod Pod
veth0
Linux Bridge
veth1
veth0 veth1
Pod
veth3
veth3
Flannel
daemon
Node
NIC
Pod Pod
veth0
Linux Bridge
veth1
veth0 veth1
Pod
veth3
veth3
Flannel
daemon
192.168.1.2 192.168.2.2
192.168.2.2

View Slide

• パケットが⽬的のPodに届く
24
Node
NIC
Pod Pod
veth0
Linux Bridge
veth1
veth0 veth1
Pod
veth3
veth3
Flannel
daemon
Node
NIC
Pod Pod
veth0
Linux Bridge
veth1
veth0 veth1
Pod
veth3
veth3
Flannel
daemon
Node
NIC
Pod Pod
veth0
Linux Bridge
veth1
veth0 veth1
Pod
veth3
veth3
Flannel
daemon
192.168.1.2 192.168.2.2
192.168.2.2

View Slide

Cluster Networkのまとめ
• Cluster Networkは、Node Network上に構成される論理ネットワーク
• Flannel, CalicoなどのCluster Networkソリューションを利⽤して実現
• フラットにクラスター内のPodが接続された状態を作るなど、いくつかの
Kubernetesの要件を満たす必要がある
25
Node Node Node
NIC
NIC
NIC
Pod Pod
VNIC VNIC
Pod Pod Pod
VNIC VNIC VNIC
Pod Pod Pod
VNIC VNIC VNIC
Pod
VNIC

View Slide

⽬次
3. Cluster Network
5. Service Network
6. まとめ
26

View Slide

kubeletとCNIプラグイン
• PodをCluster Networkに接続(?)させる役割を持つコンポーネント
– kubeletがPodを起動するときにCNIプラグインを実⾏することでこれを⾏って
いる
27
Node Node Node
NIC
NIC
NIC
Pod Pod Pod
VNIC VNIC VNIC
Pod Pod Pod
VNIC VNIC VNIC
Pod Pod Pod
VNIC VNIC VNIC
接続 !

View Slide

kubeletとCNIプラグインについてもう少し詳しく
• kubelet
– Podの起動/停⽌処理を担う、Worker Node内で稼働するデーモン
– 与えられた設定ファイルの内容に従って、Pod起動/停⽌時などに同じNode上
にあるCNIプラグインを実⾏する
• CNIプラグイン
– Container Network Interface(CNI)仕様を満たすバイナリ
– PodをCluster Networkに参加させるために必要な処理（後述）を実⾏する
– CNIプラグインを実装することによって、Kubernetesクラスターを任意の
Cluster Networkで構築できる（Cluster Networkソリューションを交換可能にする）
kuberletがCNIプラグインを実⾏することで、PodがCluster Networkに参加する
28

View Slide

kubelet、CNIプラグイン、Cluster Networkの関係
• kubelet
– 与えられた設定ファイルの内容に従って、
所定のCNIプラグインを実⾏
• CNIプラグイン
– PodがCluster Networkに参加するために必要
な処理を実⾏
– Cluster Networkソリューションに対応した
プラグインがある
• Flannelにはflannel plugin、Calicoにはcalico plugin...
• Cluster Networkに対応しないgeneralなプラグインも
（例: bridge plugin（後述））
29
Node
NIC
Pod Pod Pod
VNIC VNIC VNIC
k kubelet
例:
flannel plugin
設定ファイル
実行！
Flannelで構成された
Cluster Network
PodをCluster Networkに参加させる

View Slide

CNIプラグインが⾏う処理をもう少し具体的に
• CNIのドキュメントの“Overview”より
30
A CNI plugin is responsible for inserting a network interface into the container network namespace
(e.g. one end of a veth pair) and making any necessary changes on the host (e.g. attaching the
other end of the veth into a bridge). It should then assign the IP to the interface and setup the
routes consistent with the IP Address Management section by invoking appropriate IPAM plugin.
“
”
• つまり、だいたい以下のようなことをやっている
– PodにNICをinsertする
– Node上で必要な処理を⾏う（FlannelではLinux Bridgeにvethをアタッチする）
– NICにIPアドレスを割り当てる（PodのIPアドレス）

View Slide

とあるKubernetesクラスタの中を⾒てみる 1/3
• kubeletの起動フラグで設定ファイルとCNIプラグインの場所を指定
31
# Node内で実行
jitomee@k8s-node:~$ ps -fA | grep kubelet
root 17055 1 1 11:33 ? 00:05:31 /usr/bin/kubelet ...(snip)... ¥
--network-plugin=cni ¥ # ←cniプラグインを使う場合に指定。デフォルトは”docker”
--cni-conf-dir=/etc/cni/net.d ¥ # ←デフォルト値と同じ
--cni-bin-dir=/opt/cni/bin # ←デフォルト値と同じ
jitomee@k8s-node:~$ ls /etc/cni/net.d
10-flannel.conflist
jitomee@k8s-node:~$ ls /opt/cni/bin
bandwidth bridge dhcp firewall flannel host-device host-local ipvlan loopback macvlan portmap ptp sbr static
tuning vlan

View Slide

2/3
• kubeletの設定ファイル
– flannelプラグインの実⾏を指⽰
– flannelプラグインは、Flannel
Daemonの構成情報を読み込んで、
その内容に基づいて他のプラグイ
ンを実⾏する
– デフォルトではbridge pluginに
delegateされる
32
jitomee@k8s-node:~$ cat /etc/cni/net.d/10-flannel.conflist
{
"name": "cbr0",
"cniVersion": "0.3.1",
"plugins": [
{
“type”: “flannel”, # flannel pluginを実行
“delegate”: { # delegate先に渡す追加パラメータ
# typeがないのでbridge pluginを実行
"hairpinMode": true,
"isDefaultGateway": true
}
},
{
"type": "portmap",
"capabilities": {
"portMappings": true
}
}
]
}

View Slide

3/3
• flannel pluginがbridge pluginに
渡している設定ファイル
– デフォルトで/var/lib/cni/flannel/
に出⼒
– bridge pluginはPodにNICを払い出
してLinux Bridgeにアタッチする
– 更にipamプラグインをよんでIPア
ドレスの割当を⾏っている
33
jitomee@k8s-node:~$ cat sudo cat /var/lib/cni/flannel/8b..25
{
"cniVersion": "0.3.1",
“type”: “bridge” # bridge pluginを実行する
"ipMasq": false,
“ipam”: { # IPアドレスの割当て。内容はFlannel Daemonの
# 構成情報をflannel pluginが渡してきたもの
"routes": [
{
"dst": "192.168.0.0/16"
}
],
"subnet": "192.168.1.0/24",
"type": "host-local"
},
“hairpinMode”: true,
"isDefaultGateway": true,
"isGateway": true,
"mtu": 1450,
"name": "cbr0",
}

View Slide

Flannelプラグインの動き（ここまでの話を図解）
• flannel pluginは、Flannel
Daemonの設定を渡しながら、
他のCNIプラグインを実⾏して
いくことでその役割を果たし
ている
34
Node
NIC
Pod Pod Pod
k kubelet
flannel plugin
設定ファイル
実行！
bridge plugin ipam plugin
(host-local)
実行! 実行!
VNICを払い出して
Bridgeに接続
Linux Bridge
veth0 veth1 veth3
Flannel
daemon
IPアドレスを
割当て
設定ファイル
設定を
参照
veth0 veth1 veth3

View Slide

KubeletとCNIプラグインのまとめ
• kubeletは与えられた設定ファイルの内容に
従って、所定のCNIプラグインを実⾏する
• CNIプラグインはPodがCluster Networkに参加
するために必要な処理を実⾏
• Cluster Networkソリューションに対応したプ
ラグインがある
– Flannelにはflannel plugin
– Calicoにはcalico plugin
– 他にbridge pluginのようにGeneralなものも
• 複数のプラグインが連鎖することで全機能が
実現される
35
Node
NIC
Pod Pod Pod
VNIC VNIC VNIC
k kubelet
例:
flannel plugin
設定ファイル
実行！
Flannelで構成された
Cluster Network
PodをCluster Networkに参加させる

View Slide

⽬次
3. Cluster Network
5. Service Network
6. まとめ
36

View Slide

Service Network
• Service Networkがやってくれること
– 所定のホスト名に対して名前解決して、ServiceのIPアドレスを得る
– ServiceのIPアドレスに対してリクエストを送信するとロードバランスされる
– ロードバランシングのメンバーは⾃動で追加・除外される
37
Node Node Node
NIC
NIC
NIC
Pod Pod
VNIC VNIC
Pod Pod Pod
VNIC VNIC VNIC
Pod Pod Pod
VNIC VNIC VNIC
Pod
VNIC
ホスト名: backend.sockshop.svc にアクセス
?

View Slide

Service Network
• KubernetesのServiceリソース(Type: ClusterIP)によって以下のようなこ
とが起きる
1. Serviceに対応するIPアドレスが払い出される
2. ServiceのIPアドレスに対して、所定のルールでホスト名が割り当てられ、ク
ラスター内DNSにレコードが登録される
3. Serviceに対するアクセスが複数のPodに対してロードバランスされる
4. 配送先の追加、除外が⾃動的に⾏われる
38
[^1]:
この資料中ではHeadless Service（ {.spec.clusterIP} に “none” を指定したService）は対象外としますmm

View Slide

Serviceによる配送の実態（iptablesプロキシモード）1/2
• kube-proxyがAPI Serverにある
Endpoint / EndpointSliceリソース
をウォッチ
• Serviceリソースの記述内容に合
わせてNode上のiptablesを更新
– Service IPを、ロードバランス対象の
PodのいずれかのIPに変換するように
ルールを記述する
– ロードバランスメンバーの追加・除
外もiptablesの更新で実現
kube-proxyとiptablesによってロードバランシングとサービスディスカバリを実現
39
Node
NIC
Pod Pod
veth0
Linux Bridge
veth1
veth0 veth1
Pod
veth3
veth3
Flannel
daemon
kp
kube-proxy
iptables
API
Server
edit
宛先変換ルール
Endpoint
or EndpointSlice
watch

View Slide

Serviceによる配送の実態（iptablesプロキシモード）2/2
• Birdgeでiptableの宛先変換ルール
が適⽤され、いずれかのPodに配
送される
kube-proxyとiptablesによってロードバランシングとサービスディスカバリを実現
40
Node
NIC
Pod Pod
veth0
Linux Bridge
veth1
veth0 veth1
Pod
veth3
veth3
Flannel
daemon
kp
kube-proxy
iptables
API
Server
watch
edit
10.106.232.14 -> 192.168.2.2
Endpoint
or EndpointSlice

View Slide

【参考】Proxy mode
• usersupace プロキシモード:
– v1.1までのデフォルト
– kube-proxyがトラフィックの配送に割り込む
– userspace / kernelspaceのスイッチが発⽣するので、パフォーマンスと信頼性において
iptableに⽐べて不利とされている
• iptables プロキシモード:
– v1.2+のデフォルト
– iptablesを更新しておいて、あとのルーティングはカーネルに任せる
• ipvs プロキシモード:
– IPVSカーネルモジュールを利⽤する
– iptablesに⽐べ⾼スループットで、⾼度なルーティングアルゴリズムをサポートする
41

View Slide

Node
クラスター内DNSによる名前解決
• Kubernetesクラスターにはアドオ
ンとしてDNSサーバーがデプロイ
される
• Serviceリソースを作成すると所
定のDNSレコードが作成される
• Pod内のコンテナは、クラスター
内DNSで名前解決するように設定
されている（この設定はkubelet
が⾏っている）
Kubernetesクラスター内で起動しているDNSサーバーを利⽤
42
Node
NIC
Pod Pod
Pod
VNIC VNIC
VNIC
CoreDNS
VNIC
NIC
k
kubelet
container
/etc/resolv.conf

View Slide

【参考】Pod内のコンテナの名前解決設定
• /etc/resolv.conf にクラスター内DNSを使うように設定される
43
# クラスター内のコンテナ上で /ect/resolv.conf を確認
jitomee@k8s-node:~$ kubectl exec -it busybox-example – ash
/ # cat /etc/resolv.conf
nameserver 10.96.0.10
search default.svc.cluster.local svc.cluster.local cluster.local
options ndots:5

View Slide

ホスト名の命名規則
• [Service].[Namespace].svc.cluster.local.
– .svc.cluster.local.は省略可 [^1]
– 同じNamespace内から通信する場合は、[Namespace] 以降をすべて省略可 [^1]
– クラスタ内DNSにはAレコード（IPv6の場合AAAAレコード）が作成される
• _[Port]._[Protocol].[Service].[Namespace].svc.cluster.local.
– Serviceの {spec.ports.name} を指定した場合に、そのPort毎に作成される
– クラスタ内DNSにはSRVレコードが作成される
44
[^1]:
省略は可能ですが、パフォーマンスの観点では完全修飾名を指定するのが良いと⾔われています。
(c.f. https://pracucci.com/kubernetes-dns-resolution-ndots-options-and-why-it-may-affect-application-performances.html)

View Slide

Service Networkのまとめ
• Serviceを経由する通信では、ク
ラスター内DNSで名前解決する
• kube-proxyがiptablesを更新する
ことで、ロードバランシングと
サービスディスカバリを実現
45
Node
NIC
Pod Pod
veth0
Linux Bridge
veth1
veth0 veth1
Pod
veth3
veth3
Flannel
daemon
kp
kube-proxy
iptables
API
Server
Service / Endpoint
watch
edit
10.106.232.14 -> 192.168.2.2

View Slide

⽬次
3. Cluster Network
5. Service Network
6. まとめ
46

View Slide

今⽇話したかったけど話せなかったこと
• クラスター外からの通信の受け⼊れ
– Service
• Type: NodePort
• Type: LoadBalancer
– Ingress
• Network Policyによるクラスター内通信の制御
• 道のりは⻑い。
• Kubernetesのネットワークを完全に理解したい⼈⽣だった…。
47

View Slide

まとめ
1. Node Network
4. Service Network
Kubernetesの⼤雑把に4つに分けて考えるとよさそう
48
Node Node Node
NIC
NIC
NIC
Pod Pod Pod
VNIC VNIC VNIC
Pod Pod Pod
VNIC VNIC VNIC
Pod Pod Pod
VNIC VNIC VNIC

View Slide

Appendix.
参考⽂献
49

View Slide

【参考⽂献 1/3】
• Kubernetes公式ドキュメント
– Cluster Networking
• https://kubernetes.io/docs/concepts/cluster-administration/networking/
– Service
• https://kubernetes.io/docs/concepts/services-networking/service/
– DNS for Services and Pods
• https://kubernetes.io/docs/concepts/services-networking/dns-pod-service/
– Network Plugins
• https://kubernetes.io/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/
50

View Slide

【参考⽂献 2/3】
• CNI 関連
– CNI Documentation
• https://www.cni.dev/docs/
– CNI Spec
• https://github.com/containernetworking/cni/blob/spec-v0.4.0/SPEC.md
– CNI Plugins
• https://github.com/containernetworking/plugins
51

View Slide

【参考⽂献 3/3】
• 有志のブログなど
– Kubernetes pods /etc/resolv.conf ndots:5 option and why it may negatively affect your
application performances
• https://pracucci.com/kubernetes-dns-resolution-ndots-options-and-why-it-may-affect-application-
performances.html
– わかった気になるflannelの仕組み
• https://qiita.com/bbrfkr/items/0b0a787f2e3c81009c28
– Kubernetesネットワーク徹底解説
• https://zenn.dev/taisho6339/books/fc6facfb640d242dc7ec/viewer/166890
– 拡張性の⾼いCNIプラグインCoil v2の紹介
• https://speakerdeck.com/ymmt2005/kuo-zhang-xing-falsegao-i-cni-puraguin-coil-v2-falseshao-jie
– Kubernetes CNI 結局どれを使えばいいのか
• https://speakerdeck.com/line_developers/kubernetes-cni-which-should-we-choose
52

View Slide

整理しながら理解するKubernetesネットワークの仕組み / Kubernetes Network Fundamentals

整理しながら理解するKubernetesネットワークの仕組み / Kubernetes Network Fundamentals

hhiroshell

More Decks by hhiroshell

Other Decks in Technology

Featured

Transcript