web-dev-qa-db-ja.com

Kubernetes CNIとKube-proxy

CNIプラグインとKubernetesのKube-proxyの違いはわかりません。ドキュメントから得たものから、私は次のように結論します。

Kube-proxyは、マスターノードとの通信とルーティングを担当します。

CNIは、ポッドとサービスにIPアドレスを割り当てることで接続を提供し、ルーティングデーモンを介して到達可能性を提供します。

ルーティングは2つの間で重複する機能のようですが、それは本当ですか？

よろしく、チャールズ

kubernetescni
9
Charles Van Damme

オーバーレイネットワーク

Kubernetesは、すべてのポッドにIPアドレスがあり、そのIPアドレスを使用してそのポッド内のサービスと通信できることを前提としています。私が「オーバーレイネットワーク」と言うとき、これが私が意味することです（「ポッドをIPアドレスで参照できるようにするシステム」）。

他のすべてのKubernetesネットワーキング関連のものは、オーバーレイネットワーキングが正しく機能することに依存しています。

多くのオーバーレイネットワークバックエンド（calico、flannel、weave）があり、景観はかなり混乱しています。しかし、私に関する限り、オーバーレイネットワークには2つの役割があります。

  1. ポッドがクラスターの外部にネットワークリクエストを送信できることを確認してください
  2. ノードのサブネットへの安定したマッピングを維持し、クラスター内のすべてのノードをそのマッピングで更新し続けます。ノードが追加および削除されたときに正しいことを行います。

KUBE-PROXY

Kube-proxyを理解するために、Kubernetesサービスの仕組みを説明します。サービスはポッドのコレクションであり、それぞれに独自のIPアドレスがあります（10.1.0.3、10.2.3.5、10.3.5.6など）。

  1. すべてのKubernetesサービスはIPアドレス（10.23.1.2など）を取得します
  2. kube-dnsは、KubernetesサービスのDNS名をIPアドレスに解決します（したがって、my-svc.my-namespace.svc.cluster.localは10.23.1.2にマップされる場合があります）
  3. kube-proxyは、それらの間でランダムなロードバランシングを行うためにiptablesルールをセットアップします。

したがって、my-svc.my-namespace.svc.cluster.localにリクエストを送信すると、リクエストは10.23.1.2に解決され、ローカルホストのiptablesルール（kube-proxyによって生成されたもの）が10.1のいずれかにリダイレクトします。 0.3または10.2.3.5または10.3.5.6のランダム。

要するに、 overlay networks kubernetesのさまざまなコンポーネントとの通信に使用できる基本的なネットワークを定義します。 kube-proxyは、IPテーブルマジックを生成するツールであり、ポッドが存在するノードに関係なく、kubernetesの任意のポッド（サービスを使用）に接続できます。

この回答の一部は、このブログから引用されました。

https://jvns.ca/blog/2017/10/10/operating-a-kubernetes-network/

これにより、kubernetesネットワーキングについて簡単に説明できます。

12
Prafull Ladha

Kubernetesには、ClusterIPとPod IPの2種類のIPがあります。

CNI

CNIはポッドIPを気にします。

CNIプラグインは、ポッドが相互に通信できないオーバーレイネットワークの構築に重点を置いています。 CNIプラグインのタスクは、スケジュールされたときにポッドIPをポッドに割り当て、このIPの仮想デバイスを構築して、クラスターのすべてのノードからこのIPにアクセスできるようにすることです。

Calicoでは、これはN個のホストルート（N = cali vethデバイスの数）およびtun0上のM個の直接ルート（M = K8sクラスターノードの数）によって実装されます。

$ route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         10.130.29.1     0.0.0.0         UG    100    0        0 ens32
10.130.29.0     0.0.0.0         255.255.255.0   U     100    0        0 ens32
10.244.0.0      0.0.0.0         255.255.255.0   U     0      0        0 *
10.244.0.137    0.0.0.0         255.255.255.255 UH    0      0        0 calid3c6b0469a6
10.244.0.138    0.0.0.0         255.255.255.255 UH    0      0        0 calidbc2311f514
10.244.0.140    0.0.0.0         255.255.255.255 UH    0      0        0 califb4eac25ec6
10.244.1.0      10.130.29.81    255.255.255.0   UG    0      0        0 tunl0
10.244.2.0      10.130.29.82    255.255.255.0   UG    0      0        0 tunl0

この場合、10.244.0.0/16はポッドIP CIDRであり、10.130.29.81はクラスター内のノードです。 TCP 10.244.1.141へのリクエストがある場合、7番目のルールに従って10.130.29.81に送信されます。そして10.130.29.81では、このようなルートルールになります：

10.244.1.141    0.0.0.0         255.255.255.255 UH    0      0        0 cali4eac25ec62b

これにより、最終的にリクエストが正しいポッドに送信されます。

デーモンがなぜ必要なのかはわかりませんが、デーモン化によって、作成されたルートルールが手動で削除されないようになっていると思います。

kube-proxy

kube-proxyの仕事はかなりシンプルで、リクエストをクラスターIPからポッドIPにリダイレクトするだけです。

kube-proxyには、IPVSとiptablesの2つのモードがあります。 kube-proxyがIPVSモードで動作している場合、クラスター内の任意のノードで次のコマンドを実行すると、kube-proxyによって作成されたリダイレクトルールを確認できます。

ipvsadm -Ln
IP Virtual Server version 1.2.1 (size=4096)
Prot LocalAddress:Port Scheduler Flags
  -> RemoteAddress:Port           Forward Weight ActiveConn InActConn
TCP  10.96.0.1:443 rr
  -> 10.130.29.80:6443            Masq    1      6          0         
  -> 10.130.29.81:6443            Masq    1      1          0         
  -> 10.130.29.82:6443            Masq    1      0          0         
TCP  10.96.0.10:53 rr
  -> 10.244.0.137:53              Masq    1      0          0         
  -> 10.244.0.138:53              Masq    1      0          0   
...

この場合、CoreDNS 10.96.0.10のデフォルトのクラスターIPが表示され、その背後にポッドIPを備えた2つの実サーバー：10.244.0.137と10.244.0.138があります。

このルールは、kube-proxyが作成するものであり、kube-proxyが作成したものです。

追伸iptablesモードはほとんど同じですが、iptablesルールは醜く見えます。ここに貼り付けたくありません。 ：p

5
Lentil1016