Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Kubernetesネットワーキング初級者脱出ガイド / Kubernetes networking beginner's guide

Kohei Ota
November 04, 2021

Kubernetesネットワーキング初級者脱出ガイド / Kubernetes networking beginner's guide

A talk at CloudNative Days Tokyo 2021

Kohei Ota

November 04, 2021
Tweet

More Decks by Kohei Ota

Other Decks in Technology

Transcript

  1. Kubernetesネットワーキング初級者脱
    出ガイド -基本から最新動向まで-
    Kohei Ota, Architect at HPE/CNCF Ambassador

    View full-size slide

  2. © 2021 Cloud Native Computing Foundation
    2
    自己紹介
    Kohei Ota (@inductor)
    •アーキテクト@HPE
    •CNCF Ambassador
    •Google Developer Expert (GCP)
    •CloudNative Days Tokyo 運営
    •Container Runtime Meetup 運営
    •Kubernetes SIG-Docs Japanese owner
    •Docker Meetup Tokyo 運営

    View full-size slide

  3. © 2021 Cloud Native Computing Foundation
    3
    Table of Contents
    Dockerネットワークの基本
    DockerとKubernetesのネットワーク的な違い
    Kubernetesネットワークの構成要素
    kube-proxyのはたらきと、Kubernetes Networkingの
    スケーラビリティに関する議論
    Service APIとCloud Provider
    コンテナネイティブ・ロードバランシング
    Gateway APIについて

    View full-size slide

  4. Dockerネットワークの基本

    View full-size slide

  5. © 2021 Cloud Native Computing Foundation
    5
    Dockerのよくあるユースケース
    Docker Compose
    80:80
    3000
    3306

    View full-size slide

  6. © 2021 Cloud Native Computing Foundation
    6
    Dockerのよくあるユースケース
    Docker Compose
    80:80
    3000
    3306
    Webなので公開
    アプリは
    内部だけ
    DBは
    内部だけ

    View full-size slide

  7. © 2021 Cloud Native Computing Foundation
    7
    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

    View full-size slide

  8. © 2021 Cloud Native Computing Foundation
    8
    ネットワークとボリュームは外部割り当て?
    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

    View full-size slide

  9. © 2021 Cloud Native Computing Foundation
    9
    ネットワークとボリュームは外部割り当て?
    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
    主に2つのモードがある
    - bridge - 指定がない場合にデフォルトで使用
    - 所属するコンテナが直接通信でき、お手軽
    - none - 「何も繋がない」ができる
    - loopback(127.0.0.1)デバイス以外に仮想
    NICが
    繋がらないモード

    View full-size slide

  10. © 2021 Cloud Native Computing Foundation
    10
    Dockerコンテナとネットワークの関係
    ● コンテナはさまざまなリソースを隔離した結果生まれるもの
    ○ ネットワークもその1要素で、NICは付けたり付けなかったりできる
    ● Noneドライバーを用いた場合、ネットワーク的に隔離された
    コンテナができあがる
    ● ブリッジの場合は仮想スイッチに順次接続されて相互接続ができる
    ○ Dockerの内部DNSも勝手に参加するので、コンテナ名がついていれば
    名前でDNSも引ける
    ○ 設定ファイルでdb:3306とかweb:80とかapp:3000みたいなことが
    書けるのはそのおかげ
    ○ 簡易的ではあるがいわゆる「サービスディスカバリ」の一種

    View full-size slide

  11. DockerとKubernetesのネットワーク的な違い

    View full-size slide

  12. © 2021 Cloud Native Computing Foundation
    12
    手元のKubernetesの中身を覗いてみる
    ● 外部に公開しているLonghornのWeb UIは、TCPの80番で
    LoadBalancerがアタッチされている
    ● でも、Dockerではポートの割り当てが発生していない
    ○ なんで?

    View full-size slide

  13. © 2021 Cloud Native Computing Foundation
    13
    手元のKubernetesの中身を覗いてみる
    ● 外部に公開しているLonghornのWeb UIは、TCPの80番で
    LoadBalancerがアタッチされている
    ● でも、Dockerではポートの割り当てが発生していない
    ○ なんで?
    こたえ:
    Dockerのネットワークを使っていないから!!!

    View full-size slide

  14. © 2021 Cloud Native Computing Foundation
    14
    Kubernetesの3つの顔
    Marketing Committee
    Technical
    Oversight
    Committee
    Governing
    Board
    End User
    Community
    Container
    Orchestration
    Distributed
    system
    Platform
    for
    Platforms
    • 複数の「ノード」を束ねる
    クラスタリング
    • 柔軟なジョブスケジューリング
    • Raftベースの分散KVS
    • 高速で簡単なスケーリング
    • ロードバランサーとの統合
    • 柔軟で簡単なデプロイ手段
    • インフラ基盤との強力な連携
    • 拡張を前提に作られた APIやリソース
    • 大きなコミュニティとエコシステム

    View full-size slide

  15. © 2021 Cloud Native Computing Foundation
    15
    Kubernetesの3つの顔
    Marketing Committee
    Technical
    Oversight
    Committee
    Governing
    Board
    End User
    Community
    Container
    Orchestration
    Distributed
    system
    Platform
    for
    Platforms
    • 複数の「ノード」を束ねる
    クラスタリング
    • 柔軟なジョブスケジューリング
    • Raftベースの分散KVS
    • 高速で簡単なスケーリング
    • ロードバランサーとの統合
    • 柔軟で簡単なデプロイ手段
    • インフラ基盤との強力な連携
    • 拡張を前提に作られた APIやリソース
    • 大きなコミュニティとエコシステム
    自立型の分散システム

    View full-size slide

  16. © 2021 Cloud Native Computing Foundation
    16
    Kubernetesにおける自己復旧の仕組み
    Pod Pod Pod
    Pod network(overlay)
    Service Network(overlay)
    Node Network(not overlay)
    普通のサーバーがつながる
    ネットワーク
    ClusterIPなどサービス間の
    通信で使うネットワーク
    コンテナ(Pod)自体に
    IPアドレスを持たせるためのネッ
    トワーク

    View full-size slide

  17. © 2021 Cloud Native Computing Foundation
    17
    Kubernetesにおける自己復旧の仕組み
    Pod Pod
    Service Network(overlay)
    Node Network(not overlay)
    普通のサーバーがつながる
    ネットワーク
    ClusterIPなどサービス間の
    通信で使うネットワーク
    Nodeが障害を起こすと
    Podは自動で退避
    Pod
    Podが入れ替わっても
    同じように動作する
    Pod network(overlay)
    コンテナ(Pod)自体に
    IPアドレスを持たせるためのネッ
    トワーク

    View full-size slide

  18. © 2021 Cloud Native Computing Foundation
    18
    Kubernetesにおける自己復旧の仕組み
    Pod Pod
    Service Network(overlay)
    Node Network(not overlay)
    普通のサーバーがつながる
    ネットワーク
    ClusterIPなどサービス間の
    通信で使うネットワーク
    コンテナ(Pod)自体に
    IPアドレスを持たせるためのネッ
    トワーク
    Nodeが障害を起こすと
    Podは自動で退避
    Pod
    Podが入れ替わっても
    同じように動作する
    Pod network(overlay)
    どのノードで動いても同じように動作
    するためには、オーバーレイネット
    ワークの存在がとても重要なので
    す!

    View full-size slide

  19. © 2021 Cloud Native Computing Foundation
    19
    DockerとKubernetesのネットワーク的な違い
    ● Dockerのネットワークはシングルホスト前提
    ● Kubernetesは複数ホストをまとめ上げて動作する事が前提の
    「分散システム」である
    ● コンテナや内部ロードバランサが透過的に動くための「オーバーレイネッ
    トワーク」が重要

    View full-size slide

  20. Kubernetesネットワークの構成要素

    View full-size slide

  21. © 2021 Cloud Native Computing Foundation
    21
    Node Node
    Node
    Pod Pod Pod Pod
    Kubernetesネットワークの構成要素
    Pod network(overlay)
    Service Network(overlay)
    Node Network(not overlay)
    普通のサーバーがつながる
    ネットワーク
    ClusterIPなどサービス間の
    通信で使うネットワーク
    コンテナ(Pod)自体に
    IPアドレスを持たせるためのネッ
    トワーク
    veth veth veth veth
    eth0 eth0 eth0

    View full-size slide

  22. © 2021 Cloud Native Computing Foundation
    22
    Node Node
    Node
    Pod Pod Pod Pod
    Kubernetesネットワークの構成要素
    Pod network(overlay)
    Service Network(overlay)
    Node Network(not overlay)
    普通のサーバーがつながる
    ネットワーク
    ClusterIPなどサービス間の
    通信で使うネットワーク
    コンテナ(Pod)自体に
    IPアドレスを持たせるためのネッ
    トワーク
    veth veth veth veth
    eth0 eth0 eth0
    ここからどうやって中に繋がっていく
    のかよくわからんな🤔🤔🤔🤔

    View full-size slide

  23. © 2021 Cloud Native Computing Foundation
    23
    AWS VPC
    LB経由のユーザートラフィックの流れ
    Node Node
    Node
    Pod Pod Pod Pod
    Pod network(overlay)
    Service Network(overlay)
    Load Balancer
    veth veth veth veth
    eth0 eth0 eth0
    kube-proxy kube-proxy
    kube-proxy
    Service type: LoadBalancerで作成
    赤色のPodに行
    きたい
    CNI

    View full-size slide

  24. © 2021 Cloud Native Computing Foundation
    24
    Node Node
    Node
    Pod Pod Pod Pod
    Kubernetesネットワークの構成要素: CNI
    Pod network(overlay)
    Service Network(overlay)
    Node Network(not overlay)
    veth veth veth veth
    eth0 eth0 eth0
    CNI (Container Network Interface)
    1. ノードネットワークの疎通性を担保
    (VXLAN/BGP/クラウドのVPCなどのSDN)
    2. Podに仮想NICを割当
    3. PodのIPアドレスを割当

    View full-size slide

  25. © 2021 Cloud Native Computing Foundation
    25
    CNIについて
    ● 外の世界のネットワークとKubernetesのネットワークをつなげる役割
    ○ クラウドのVPCやノードの制御に使うBGP、あるいはVXLANなどのホストレベルの
    ネットワークを認識できる
    ● 各Podに割り当てる仮想NICの管理
    ○ コンテナ作成時にランタイムが作ったNW namespaceに対してvNICをアタッチ
    ● 各PodのIPアドレス管理(要するにIPAM)
    ○ コンテナは揮発性が高いので、CNIがIPAMのデーモンを管理してIPアドレスを管理し、Service
    のエンドポイント情報を書き換える

    View full-size slide

  26. © 2021 Cloud Native Computing Foundation
    26
    いろいろなCNI
    ● kubenet
    ○ 参照実装なので利用例はまずない
    ● Flannel
    ○ VXLANによるオーバーレイネットワーク
    ○ 本番で使われるCNIの中では一番シンプル
    ○ NetworkPolicyの実装がない
    ● Calico
    ○ 最も人気&歴史がある
    ○ BGP(L3)ベースのネットワークでスケールしやすい
    ● Cilium
    ○ eBPFを用いた高パフォーマンス&スケーラブルなCNI
    ○ GKEでもサポートされている
    ● Amazon VPC CNI plugin

    View full-size slide

  27. © 2021 Cloud Native Computing Foundation
    27
    Node Node
    Node
    Pod Pod Pod Pod
    Kubernetesネットワークの構成要素: kube-proxy
    Pod network(overlay)
    Service Network(overlay)
    Node Network(not overlay)
    veth veth veth veth
    eth0 eth0 eth0
    kube-proxy kube-proxy
    kube-proxy
    コンテナ間の通信を制御する
    kube-proxy(iptables/ipvs/eBPF実装)

    View full-size slide

  28. © 2021 Cloud Native Computing Foundation
    28
    kube-proxyについて
    ● ClusterIP Service(Kubernetesの内部LB)の実態
    ○ Linuxの機能であるiptables/ipvsのいずれかを使ってNWを制御する
    ● 各ホスト(ノード)に流入した通信をPodに通すかどうかの経路制御
    ○ iptables実装の場合はフィルタや転送を組み合わせて使う
    ● NodePortやLoadBalancerによって外部から流入してきた通信を
    Endpoints(EndpointSlice)リソースに登録されたPod IPに転送
    ○ kubectl describe svcで引くとサービスに紐付いたEndpointsの情報が
    出てくる

    View full-size slide

  29. kube-proxyに関する議論

    View full-size slide

  30. © 2021 Cloud Native Computing Foundation
    30
    kube-proxyはボトルネックになることが知られている
    ● kube-proxyで主流のiptables modeは、
    クラスター規模に比例してパフォーマンスが劣
    化することが知られている
    ● IPVSはハッシュテーブルのためスケーラビリ
    ティの問題は解消される
    ● eBPFによる代替実装が提案され、実際に
    一部のCNIで利用が始まっている

    View full-size slide

  31. © 2021 Cloud Native Computing Foundation
    31
    eBPFによるkube-proxyの代替実装
    ● Calico
    ○ リソース消費が減り、レイテンシが抑えられることが示されている
    ○ kube-proxyなしでDSRなどが実現できる
    ○ ただし現状はx86-64のみ利用可能でIPv6は未対応
    ○ floating IPやSCTPなども使えない
    Ref. Enable the eBPF dataplane - Calico
    ● Cilium
    ○ カーネルのXDPを用いた高速化や、LoadBalancer Serviceのビルトインサポートがある
    ○ SCTPは使えない
    ○ kube-proxy代替実装を有効にするとClusterIPを外部に公開することができない
    ■ 最新版ではいけた
    Ref. Kubernetes Without kube-proxy — Cilium
    Ref. Replacing iptables with eBPF in Kubernetes with Cilium

    View full-size slide

  32. Service APIとクラウドプロバイダー

    View full-size slide

  33. © 2021 Cloud Native Computing Foundation
    33
    Kubernetesにおけるクラウドリソースの管理

    View full-size slide

  34. © 2021 Cloud Native Computing Foundation
    34
    Kubernetesにおけるクラウドリソースの管理
    クラウドのAPIと通信して、LBaaSやIaaSなどを
    管理するためのコントローラー

    View full-size slide

  35. © 2021 Cloud Native Computing Foundation
    35
    c-c-mのわかりやすい利用例
    ● LoadBalancer ServiceをAmazon EKS上で作成すると、内部でCloud Provider
    AWSが作用してELBが作成される

    View full-size slide

  36. © 2021 Cloud Native Computing Foundation
    36
    AWS VPC
    LB経由のユーザートラフィックの流れ
    Node Node
    Node
    Pod Pod Pod Pod
    Pod network(overlay)
    Service Network(overlay)
    ELB
    veth veth veth veth
    eth0 eth0 eth0
    kube-proxy kube-proxy
    kube-proxy
    Service type: LoadBalancerで作成
    1. LBに到達し任意のノー
    ドに振り分け
    赤色のPodに行
    きたい

    View full-size slide

  37. © 2021 Cloud Native Computing Foundation
    37
    AWS VPC
    LB経由のユーザートラフィックの流れ
    Node Node
    Node
    Pod Pod Pod Pod
    Pod network(overlay)
    Service Network(overlay)
    ELB
    veth veth veth veth
    eth0 eth0 eth0
    kube-proxy kube-proxy
    kube-proxy
    Service type: LoadBalancerで作成
    2. kube-proxyに振り分けられ
    Podの所在を確認
    赤色のPodに行
    きたい

    View full-size slide

  38. © 2021 Cloud Native Computing Foundation
    38
    AWS VPC
    LB経由のユーザートラフィックの流れ
    Node Node
    Node
    Pod Pod Pod Pod
    Pod network(overlay)
    Service Network(overlay)
    ELB
    veth veth veth veth
    eth0 eth0 eth0
    kube-proxy kube-proxy
    kube-proxy
    Service type: LoadBalancerで作成
    3. kube-proxyが通信を許可し
    Podに到達
    赤色のPodに行
    きたい

    View full-size slide

  39. © 2021 Cloud Native Computing Foundation
    39
    AWS VPC
    LB経由のユーザートラフィックの流れ
    Node Node
    Node
    Pod Pod Pod Pod
    Pod network(overlay)
    Service Network(overlay)
    ELB
    veth veth veth veth
    eth0 eth0 eth0
    kube-proxy kube-proxy
    kube-proxy
    Service type: LoadBalancerで作成
    3. kube-proxyが通信を許可し
    Podに到達
    赤色のPodに行
    きたい
    Serviceリソースの
    type: LoadBalancer(外部LBとの連携)
    type: NodePort(どのノードからアクセスしても目的の Pod
    にアクセスできる)
    type: ClusterIP(kube-proxyによる経路制御/フィルタ)
    を順番にたどっていることがわかる

    View full-size slide

  40. コンテナネイティブ・ロードバランシング

    View full-size slide

  41. © 2021 Cloud Native Computing Foundation
    41
    AWS VPC
    LB経由のユーザートラフィックの流れ
    Node Node
    Node
    Pod Pod Pod Pod
    Pod network(overlay)
    Service Network(overlay)
    ELB
    veth veth veth veth
    eth0 eth0 eth0
    kube-proxy kube-proxy
    kube-proxy
    Service type: LoadBalancerで作成
    さっきのこれ
    赤色のPodに行
    きたい

    View full-size slide

  42. © 2021 Cloud Native Computing Foundation
    42
    AWS VPC
    LB経由のユーザートラフィックの流れ
    Node Node
    Node
    Pod Pod Pod Pod
    Pod network(overlay)
    Service Network(overlay)
    ELB
    veth veth veth veth
    eth0 eth0 eth0
    kube-proxy kube-proxy
    kube-proxy
    Service type: LoadBalancerで作成
    本当だったらこうありたいですよね!
    赤色のPodに行
    きたい

    View full-size slide

  43. © 2021 Cloud Native Computing Foundation
    43
    type: LoadBalancer標準実装の問題点
    ● Node NetworkとService/Pod Networkが論理的に分断されている
    ○ ホップが余計に発生する
    ○ ロードバランサーがPodの所在を認識しないので、常に最適な経路を選択するのはムリ
    ● 外部LBを利用するケースの場合、Cluster IPによるルーティングを介さずに
    外部ネットワークからPodの所在が直接認識できるような経路制御が
    したい・・・

    View full-size slide

  44. © 2021 Cloud Native Computing Foundation
    44
    type: LoadBalancer標準実装の問題点
    ● Node NetworkとService/Pod Networkが論理的に分断されている
    ○ ホップが余計に発生する
    ○ ロードバランサーがPodの所在を認識しないので、常に最適な経路を選択するのはムリ
    ● 外部LBを利用するケースの場合、Cluster IPによるルーティングを介さずに
    外部ネットワークからPodの所在が直接認識できるような経路制御が
    したい・・・
    そこでコンテナネイティブ・ロードバランシングですよ奥
    さん!

    View full-size slide

  45. © 2021 Cloud Native Computing Foundation
    45
    コンテナネイティブ・ロードバランシングとは
    ● クラウドのVPCが持つCIDRブロックを用いてService Network範囲とPod
    Network範囲を管理
    ● それぞれのルーティングテーブルもクラウド側で管理
    ○ ロードバランサーから直接Podに通信を向けることができる
    ● でもそんなのKubernetesのアーキテクチャ的に可能なの?
    ○ CNIの図を思い出してみてください

    View full-size slide

  46. © 2021 Cloud Native Computing Foundation
    46
    コンテナネイティブ・ロードバランシングとは
    ● クラウドのVPCが持つCIDRブロックを用いてService Network範囲とPod
    Network範囲を管理
    ● それぞれのルーティングテーブルもクラウド側で管理
    ○ ロードバランサーから直接Podに通信を向けることができる
    ● でもそんなのKubernetesのアーキテクチャ的に可能なの?
    ○ CNIの図を思い出してみてください

    View full-size slide

  47. © 2021 Cloud Native Computing Foundation
    47
    コンテナネイティブ・ロードバランシングとは
    ● クラウドのVPCが持つCIDRブロックを用いてService Network範囲とPod
    Network範囲を管理
    ● それぞれのルーティングテーブルもクラウド側で管理
    ○ ロードバランサーから直接Podに通信を向けることができる
    ● でもそんなのKubernetesのアーキテクチャ的に可能なの?
    ○ CNIの図を思い出してみてください
    できそう

    View full-size slide

  48. パブリッククラウドにおける
    コンテナネイティブ・ロードバランシングの実装例

    View full-size slide

  49. © 2021 Cloud Native Computing Foundation
    49
    AWSでの実装
    ● AWSのVPC CNIが持つL-IPAMがPodのIP CIDRを管理してENIのセカンダリ
    アドレスプールにアタッチ
    ● ALB(L7)とNLB(L4)のIPモードを使うとVPCのアドレスに直接ターゲット
    グループを向けられる
    ○ AWS LoadBalancer Controllerによる拡張

    View full-size slide

  50. © 2021 Cloud Native Computing Foundation
    50
    GCPでの実装
    ● GKEのCNIは公開されていないが、IPAMの仕組みを持っている
    ○ VPC Native clusterを指定して作るとVPCのサブネット範囲からService/Pod addressを割り
    当てられる
    ● LoadBalancer利用時にGCPのNEGを指定することでPodの向き先をNEGに管理
    させることができる

    View full-size slide

  51. © 2021 Cloud Native Computing Foundation
    51
    オンプレではどうなの?
    ● SDNによるOverlay networkを使えば技術的には可能
    ○ 現実的にできるとは言ってない
    ● 現状やろうとしているベンダーがいるのか未調査
    ○ F5 + Nginx ingressとかだといけるんだろうか・・・?

    View full-size slide

  52. Gateway APIについて

    View full-size slide

  53. © 2021 Cloud Native Computing Foundation
    53
    Gateway APIとは
    ● 外部からのアクセスやトラフィックを管理するためのネットワークモデルを
    定義したKubernetesの拡張仕様
    ● SIG-Networkが主導となって現在進行系で仕様を決めている
    ● イメージとしては既存のServiceリソース、Ingressリソースをより分かりやすく体系化
    しまとめなおしたもの
    ○ GatewayClass、Gateway、TCPRoute、HTTPRoute、Service などからなり、Istioなどが
    作ってきた仕組みもふまえつつKubernetesの外部ネットワーク周りを再整理

    View full-size slide

  54. © 2021 Cloud Native Computing Foundation
    54
    Gateway APIとは
    ● 外部からのアクセスやトラフィックを管理するためのネットワークモデルを
    定義したKubernetesの拡張仕様
    ● SIG-Networkが主導となって現在進行系で仕様を決めている
    ● イメージとしては既存のServiceリソース、Ingressリソースをより分かりやすく体系化
    しまとめなおしたもの
    ○ GatewayClass、Gateway、TCPRoute、HTTPRoute、Service などからなり、Istioなどが
    作ってきた仕組みもふまえつつKubernetesの外部ネットワーク周りを再整理

    View full-size slide

  55. © 2021 Cloud Native Computing Foundation
    55
    なぜ再定義?
    ● 既存のIngress、Serviceは基盤運用者と利用者(開発者やSRE)の棲み分けが曖昧
    ○ 基盤運用者: トラフィックの入り口であるLoadBalancer自体の管理
    ○ 利用者: 利用可能なLBを使って特定プロトコルでサービスへ流入したい
    ● IngressClassだけではロードバランサーのライフサイクルや細かいプロトコルの制御
    まで柔軟に管理していくのが難しい
    ○ そもそもIngressだけデフォでまともに使えないということ自体が今となっては厄介
    → そこで、SIG-Networkを率いるGoogleのエンジニアなどを中心にGateway APIとい
    う名前でより拡張性の高い機能を提供できるようにしているのがこれ

    View full-size slide

  56. © 2021 Cloud Native Computing Foundation
    56
    Gateway API利用の流れ
    基盤の運用者がGatewayClassをプロバイダと
    して提供
    (既存のIngress controllerやCCMに含まれる
    Service controllerが等価)
    クラスタ管理者が、そのクラスタで利用可能な
    Gatewayを定義し作っておく(LBの
    フロントエンド部分だけ生やしておく)
    開発者が利用可能なGatewayから特定のホスト名
    やパスに該当する通信をTCP/HTTPなどの
    プロトコルで自分のサービスに向ける

    View full-size slide

  57. © 2021 Cloud Native Computing Foundation
    57
    Gateway APIはService/Ingress v2なのか?
    ● 現時点でGateway APIが既存のService/Ingressを置き換える予定はない
    ○ ただし、GKEではAlphaのGateway APIを既に導入しており、かなり利用のモチベーションが
    高そうであることが分かる
    ○ Ingress実装の一つであるContourもGateway APIに追従している
    ○ その他いくつかのIngress controllerなどでも実装予定がありそう
    ● 現状すぐに導入しないといけないというわけではない
    ○ そもそもまだAlphaなので・・・
    ○ Ingressとしては最大手のNginx Ingressでは未対応
    ○ ただし、大規模組織では導入のメリットも大きいので、デザインについて知るのは大事

    View full-size slide

  58. © 2021 Cloud Native Computing Foundation
    58
    Gateway APIはService/Ingress v2なのか?
    ● 現時点でGateway APIが既存のService/Ingressを置き換える予定はない
    ○ ただし、GKEではAlphaのGateway APIを既に導入しており、かなり利用のモチベーションが
    高そうであることが分かる
    ○ Ingress実装の一つであるContourもGateway APIに追従している
    ○ その他いくつかのIngress controllerなどでも実装予定がありそう
    ● 現状すぐに導入しないといけないというわけではない
    ○ そもそもまだAlphaなので・・・
    ○ Ingressとしては最大手のNginx Ingressでは未対応
    ○ ただし、大規模組織では導入のメリットも大きいので、デザインについて知るのは大事

    View full-size slide

  59. © 2021 Cloud Native Computing Foundation
    60
    まとめ
    ● Kubernetesは分散システムを実現するために様々なコンポーネントを組み合わせ
    て使っている
    ● Kubernetes側と基盤技術側で関心の分離を行うための仕組みがネットワークにも
    用意されている
    ● アップデートとともに、ボトルネックになる部分を解消すべく様々な取り組みが行われ
    ている
    ● 既存規格の再設計は難しい

    View full-size slide

  60. © 2021 Cloud Native Computing Foundation
    61
    参考資料
    ● Kubernetes The Hard Way
    ○ https://github.com/kelseyhightower/kubernetes-the-hard-way
    ○ 主にNodeごとにPod CIDRを分けないとiptables的にまずいみたいなところとか
    ● Kubernetesネットワーク 徹底解説
    ○ https://zenn.dev/taisho6339/books/fc6facfb640d242dc7ec
    ○ 主にGKEのネットワーク周り
    ● Kubernetes完全ガイド
    ○ 主にEndpointリソース周り
    ● SIG-Network Intro & Deep-dive
    ○ https://static.sched.com/hosted_files/kccncna20/57/KubeCon_NA_Virtual_2020-si
    g-net.pdf
    ○ https://static.sched.com/hosted_files/kccncna2021/ea/%5BPUBLIC%5D%20KubeC
    on_NA_2021_%20SIG-NETWORK%20update%20and%20directions.pdf
    ○ 主にGateway API周り

    View full-size slide

  61. Thank you for your attention!
    The CNCF aims to help end users connect with other end users, recruit talent, and adopt
    cloud native successfully in a vendor neutral environment.

    View full-size slide