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

20220525_k8sのNW構成

 20220525_k8sのNW構成

20220525_Dojo資料

D519d4bbd43bcfc05c2c39a1cf268b56?s=128

Yuya Iguchi

May 27, 2022
Tweet

Other Decks in Technology

Transcript

  1. k8sのNW構成

  2. Oracle https://www.linkedin.com/in/yuyaiguchi

  3. None
  4. ①K8s(Kubernetes)クラスタ構築時のコマンド kubeadm init --apiserver-advertise-address=192.168.56.21 --pod-network-cidr=10.100.0.0/16 ⇒Pod用に、Nodeとは異なるCIDRを指定する必要がある? ⇒Nodeと異なるNWセグメントなのに何故通信ができる? ②NWは面白い&必要不可欠

  5. Dockerが以下のようなNW構成であれば分かりやすいが… ※このような構成を取ることも可能ではある。 Node B NIC Node A NIC Pod A

    Pod B Pod C Pod D 192.168.56.0/24 NIC NIC NIC NIC .1 .11 .12 .2 .21 .22
  6. 実際には以下のような構成例であることが多い。 Node B NIC Node A NIC 192.168.56.1 Pod A

    veth 172.17.0.5 Pod B veth 172.17.0.6 192.168.56.2 Pod C veth 172.17.0.61 Pod D veth 172.17.0.62 192.168.56.0/24 R veth veth veth 仮想スイッチ veth 172.17.0.1 R veth veth veth 仮想スイッチ veth 172.17.0.51
  7. ・Node OSとしてLinuxがインストールされ、コンテナ(Pod)を提供する環境。 一般的にサーバ、ホストなど様々な表現がある。

  8. DockerのNW構成には大きく3タイプある。 ・none ・host ・bridge 本勉強会では最もメジャーなbridgeにフォーカスする。

  9. Bridgeを知るためのキーワード3つ ※①~③はLinuxカーネルの機能。 ①ネットワーク名前空間 (単なる)名前空間は「分離」する機能。 コンテナはサーバ仮想化ではない。 ネットワーク名前空間はNIC、IPアドレス、ルーティングテーブルなどを Nodeから「分離」する。 IPアドレスはPodごとに割り当てられる。

  10. ネットワーク名前空間 Node B NIC Node A NIC 192.168.56.1 Pod A

    veth 172.17.0.5 Pod B veth 172.17.0.6 192.168.56.2 Pod C veth 172.17.0.61 Pod D veth 172.17.0.62 192.168.56.0/24 R veth veth veth 仮想スイッチ veth 172.17.0.1 R veth veth veth 仮想スイッチ veth 172.17.0.51
  11. Bridgeを知るためのキーワード3つ ※①~③はLinuxカーネルの機能。 ②仮想ブリッジ(仮想スイッチ) Linux上に仮想的なL2スイッチを構成する機能。 NodeのホストOSとPod(コンテナ)が通信するためのI/Fとして利用。 ③veth(Virtual Ethernet) 仮想的なL2のNW I/F(仮想NIC)のこと。 2つのI/Fがペアで作成され、I/F間での通信が可能。

    一方がネットワーク名前空間へ接続され、 もう一方が仮想スイッチへ接続される。
  12. , veth, IP 仮想スイッチ, veth, IP転送 Node B NIC Node

    A NIC 192.168.56.1 Pod A veth 172.17.0.5 Pod B veth 172.17.0.6 192.168.56.2 Pod C veth 172.17.0.61 Pod D veth 172.17.0.62 192.168.56.0/24 R veth veth veth 仮想スイッチ veth 172.17.0.1 R veth veth veth 仮想スイッチ veth 172.17.0.51
  13. Nodeをまたいで通信するには、さらに把握すべき要素がある。 ④ネットワーク名前空間におけるデフォルトゲートウェイ ⑤IP転送 デフォルトではパケットをルーティングしない。 ⑥NAT(Network Address Translation) PodのIPアドレスは、Podが稼働しているNode内でしか使えない。 そのため、そのままではPodから別NodeへのPodへ通信できない。 そこで、iptablesでNATを行うことで通信を実現する。

  14. NATの様子(Pod A -> Pod C) ※説明の都合上、PortのTranslationは省略。 Node B NIC Node

    A NIC 192.168.56.1 Pod A veth 172.17.0.5 Pod B veth 172.17.0.6 192.168.56.2 Pod C veth 172.17.0.61 Pod D veth 172.17.0.62 192.168.56.0/24 R veth veth veth 仮想スイッチ veth 172.17.0.1 R veth veth veth 仮想スイッチ veth 172.17.0.51 Src: 172.17.0.5 Dst: 192.168.56.2 Src: 192.168.56.1 Dst: 192.168.56.2 Src: 192.168.56.1 Dst: 192.168.56.2 Src: 192.168.56.1 Dst: 172.17.0.61
  15. 【NATについて補足】 NATは「IPアドレスを別のIPアドレスに変換する技術」である。 良く「プライベートIPアドレスをグローバルIPアドレスに変換する技術」と 言われるが、違う。 プライベートIPアドレスからプライベートIPアドレスへの変換も行われる。 ※NWセグメントが重複している二拠点間におけるTwice NATなど。

  16. k8sのNodeにはMaster Node/Worker Nodeが存在し、それぞれ役割が異なる。 Master Node/Worker Nodeをまとめてクラスタと称する。 Worker Node Worker Node

    Pod Pod Pod Pod Master Node デモ範囲
  17. 【デモ①】 NodeのIP転送を無効化する。(デモ環境はDockerでなくk8s) k8s-node3 NIC k8s-node2 NIC Pod (httpd) veth Pod

    (nginx) veth R veth veth 仮想スイッチ veth R veth veth 仮想スイッチ veth
  18. Pod(コンテナ)が多いと、iptablesで管理しなければならない NATテーブルが膨大な量となってしまう。 また、k8sのNW実装の要件として以下が定義されていることからも、 k8sではNATを使わない。 Kubernetesのネットワークモデル https://kubernetes.io/ja/docs/concepts/cluster-administration/networking/ ・ノード上のPodが、NATなしですべてのノード上の すべてのPodと通信できること ・systemdやkubeletなどノード上にあるエージェントが、 そのノード上のすべてのPodと通信できること

  19. k8sのNW実装の要件も踏まえて、 NATを使用せずにPod間通信を実現する仕組みが必要となる。 ⇒k8sでは、実装方式としてCNIプラグインを使用することで実現している。 ・CNI(Container Network Interface) Pod(コンテナ)とNWを接続するI/Fを提供する物。 CNIプラグインには以下の3タイプがある。 ①Overlay(トンネル、カプセル化) 例)flannel

    ②Routing(BGPなど) 例)Calico ③Underlay
  20. ①オーバーレイネットワーク NW上に別のNWを構築すること(下位層の隠蔽) 例:インターネットVPN(インターネット上に仮想的な専用線を構築)

  21. オーバーレイネットワークを実現するためにVXLANが使用される。 ・VXLAN(Virtual eXtensible Local Area Network) L2 over L3の技術を利用している。 VXLANによりカプセル化/アンカプセル化することで、

    あたかも同一NWセグメント内のコンテナであるかのようにアクセス可能。 元のEthernetフレームに対しVXLANのヘッダを付与する。(カプセル化)
  22. Step1:Pod AからPod C宛へパケット送信 Step2:VTEP(※)が、EthernetフレームへVXLANヘッダを付与(カプセル化) Step3:Node AからNode Bへパケットをルーティング Step4:VTEPが、EthernetフレームからVXLANヘッダを解除(アンカプセル化) Step5:Pod Cへパケットが届く

    (※)VTEP:VXLAN Tunnel End Point
  23. Overlayの様子(Pod A -> Pod C) Node B NIC Node A

    NIC 192.168.56.1 Pod A veth 172.17.0.5 Pod B veth 172.17.0.6 192.168.56.2 Pod C veth 172.17.0.61 Pod D veth 172.17.0.62 192.168.56.0/24 R veth veth veth 仮想スイッチ veth 172.17.0.1 R veth veth veth 仮想スイッチ veth 172.17.0.51 Src: 172.17.0.5 Dst: 172.17.0.61 Src: 192.168.56.1 Dst: 192.168.56.2 Src: 192.168.56.1 Dst: 192.168.56.2 Src: 172.17.0.5 Dst: 172.17.0.61
  24. ②ルーティング BIRDがBGPクライアントとなり、 Node上のPodへの経路情報をBIRD同士が互いに交換する。 ※各NodeのBIRDがBGPピアリングを行う。 Node B NIC Node A NIC

    Pod A veth Pod B veth Pod C veth Pod D veth R veth veth veth 仮想スイッチ veth R veth veth veth 仮想スイッチ veth BIRD BIRD
  25. 【デモ②】 BGPのAS番号を変更する。 ※デモの手順による動作(環境への影響)は保証しない。 今回はデモが実現できれば良いため、今回の手順としている。 Node B Node A Pod A

    Pod B Pod C Pod D BIRD BIRD AS64512
  26. 【Kubernetes Networking】 https://ibm.github.io/kubernetes-networking/ IBMが公開している、Kubernetesのネットワーキングを まとめたサイトになります。 今回の勉強会でお話しできなかった項目についても記載がありますので、 良ければ参考としていただければと存じます。

  27. Q&A

  28. ワークショップ、セッション、および資料は、IBMまたはセッション発表者によって準備され、それぞれ独自の見解を反映したものです。それらは情報 提供の目的のみで提供されており、いかなる参加者に対しても法律的またはその他の指導や助言を意図したものではなく、またそのような結果を生むも のでもありません。本講演資料に含まれている情報については、完全性と正確性を期するよう努力しましたが、「現状のまま」提供され、明示または暗 示にかかわらずいかなる保証も伴わないものとします。本講演資料またはその他の資料の使用によって、あるいはその他の関連によって、いかなる損害 が生じた場合も、IBMは責任を負わないものとします。 本講演資料に含まれている内容は、IBMまたはそのサプライヤーやライセンス交付者からいかな る保証または表明を引きだすことを意図したものでも、IBMソフトウェアの使用を規定する適用ライセンス契約の条項を変更することを意図したもので もなく、またそのような結果を生むものでもありません。 本講演資料でIBM製品、プログラム、またはサービスに言及していても、IBMが営業活動を行っているすべての国でそれらが使用可能であることを暗示 するものではありません。本講演資料で言及している製品リリース日付や製品機能は、市場機会またはその他の要因に基づいてIBM独自の決定権をもっ

    ていつでも変更できるものとし、いかなる方法においても将来の製品または機能が使用可能になると確約することを意図したものではありません。本講 演資料に含まれている内容は、参加者が開始する活動によって特定の販売、売上高の向上、またはその他の結果が生じると述べる、または暗示すること を意図したものでも、またそのような結果を生むものでもありません。パフォーマンスは、管理された環境において標準的なIBMベンチマークを使用し た測定と予測に基づいています。ユーザーが経験する実際のスループットやパフォーマンスは、ユーザーのジョブ・ストリームにおけるマルチプログラ ミングの量、入出力構成、ストレージ構成、および処理されるワークロードなどの考慮事項を含む、数多くの要因に応じて変化します。したがって、 個々のユーザーがここで述べられているものと同様の結果を得られると確約するものではありません。 記述されているすべてのお客様事例は、それらのお客様がどのようにIBM製品を使用したか、またそれらのお客様が達成した結果の実例として示された ものです。実際の環境コストおよびパフォーマンス特性は、お客様ごとに異なる場合があります。 IBM、IBM ロゴ、ibm.com、IBM Cloud、IBM Cloud Paksは、 世界の多くの国で登録されたInternational Business Machines Corporationの商標です。他 の製品名およびサービス名等は、それぞれIBMまたは各社の商標である場合があります。現時点での IBM の商標リストについては、 www.ibm.com/legal/copytrade.shtmlをご覧ください。