CNIプラグインとKubernetesのKube-proxyの違いはわかりません。ドキュメントから得たものから、私は次のように結論します。
Kube-proxyは、マスターノードとの通信とルーティングを担当します。
CNIは、ポッドとサービスにIPアドレスを割り当てることで接続を提供し、ルーティングデーモンを介して到達可能性を提供します。
ルーティングは2つの間で重複する機能のようですが、それは本当ですか?
よろしく、チャールズ
オーバーレイネットワーク
Kubernetesは、すべてのポッドにIPアドレスがあり、そのIPアドレスを使用してそのポッド内のサービスと通信できることを前提としています。私が「オーバーレイネットワーク」と言うとき、これが私が意味することです(「ポッドをIPアドレスで参照できるようにするシステム」)。
他のすべてのKubernetesネットワーキング関連のものは、オーバーレイネットワーキングが正しく機能することに依存しています。
多くのオーバーレイネットワークバックエンド(calico、flannel、weave)があり、景観はかなり混乱しています。しかし、私に関する限り、オーバーレイネットワークには2つの役割があります。
KUBE-PROXY
Kube-proxyを理解するために、Kubernetesサービスの仕組みを説明します。サービスはポッドのコレクションであり、それぞれに独自のIPアドレスがあります(10.1.0.3、10.2.3.5、10.3.5.6など)。
したがって、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ネットワーキングについて簡単に説明できます。
Kubernetesには、ClusterIPとPod IPの2種類のIPがあります。
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の仕事はかなりシンプルで、リクエストをクラスター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