web-dev-qa-db-fra.com

Kubernetes CNI vs Kube-proxy

Je ne sais pas quelle est la différence entre le plugin CNI et le proxy Kube dans Kubernetes. De ce que je retire de la documentation, je conclus ce qui suit:

Kube-proxy est responsable de la communication avec le nœud maître et du routage.

CNI fournit la connectivité en attribuant des adresses IP aux pods et aux services, et l'accessibilité via son démon de routage.

le routage semble être une fonction de chevauchement entre les deux, est-ce vrai?

Cordialement, Charles

kubernetescni
9
Charles Van Damme

RÉSEAU DE SUPERPOSITION

Kubernetes suppose que chaque pod a une adresse IP et que vous pouvez communiquer avec les services à l'intérieur de ce pod en utilisant cette adresse IP. Quand je dis "réseau de superposition", c'est ce que je veux dire ("le système qui vous permet de faire référence à un pod par son adresse IP").

Toutes les autres fonctionnalités de mise en réseau Kubernetes reposent sur le fonctionnement correct du réseau de superposition.

Il y a beaucoup de backends de réseau de superposition (calicot, flanelle, tissage) et le paysage est assez déroutant. Mais en ce qui me concerne, un réseau de superposition a 2 responsabilités:

  1. Assurez-vous que vos modules peuvent envoyer des demandes réseau en dehors de votre cluster
  2. Gardez un mappage stable des nœuds aux sous-réseaux et gardez chaque nœud de votre cluster mis à jour avec ce mappage. Faites ce qu'il faut lorsque des nœuds sont ajoutés et supprimés.

KUBE-PROXY

Juste pour comprendre kube-proxy, voici comment fonctionnent les services Kubernetes! Un service est une collection de pods, qui ont chacun leur propre adresse IP (comme 10.1.0.3, 10.2.3.5, 10.3.5.6)

  1. Chaque service Kubernetes obtient une adresse IP (comme 10.23.1.2)
  2. kube-dns résout les noms DNS du service Kubernetes en adresses IP (donc my-svc.my-namespace.svc.cluster.local peut correspondre à 10.23.1.2)
  3. kube-proxy configure des règles iptables afin de faire un équilibrage de charge aléatoire entre elles.

Ainsi, lorsque vous faites une demande à my-svc.my-namespace.svc.cluster.local, elle se résout en 10.23.1.2, puis les règles iptables sur votre hôte local (générées par kube-proxy) la redirigent vers l'un des 10.1. 0,3 ou 10.2.3.5 ou 10.3.5.6 au hasard.

En bref, overlay networks définit le réseau sous-jacent qui peut être utilisé pour communiquer les différents composants de kubernetes. Tandis que kube-proxy est un outil pour générer la magie des tables IP qui vous permet de vous connecter à n'importe quel pod (à l'aide de services) dans kubernetes, quel que soit le nœud sur lequel ce pod existe.

Certaines parties de cette réponse sont extraites de ce blog:

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

J'espère que cela vous donnera une brève idée de la mise en réseau kubernetes.

12
Prafull Ladha

Il existe deux types d'IP dans kubernetes: ClusterIP et Pod IP.

CNI

CNI se soucie de Pod IP.

Le plugin CNI se concentre sur la création d'un réseau de superposition, sans lequel les pods ne peuvent pas communiquer entre eux. La tâche du plug-in CNI consiste à attribuer l'IP du pod au pod lorsqu'il est planifié, à créer un périphérique virtuel pour cette IP et à rendre cette IP accessible à partir de chaque nœud du cluster.

Dans Calico, ceci est implémenté par N routes hôtes (N = le nombre de périphériques cali veth) et M routes directes sur tun0 (M = le nombre de nœuds de cluster 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

Dans ce cas, 10.244.0.0/16 est le Pod IP CIDR, et 10.130.29.81 est un nœud du cluster. Vous pouvez imaginer, si vous avez une demande TCP à 10.244.1.141, il sera envoyé à 10.130.29.81 suivant la 7ème règle. Et sur 10.130.29.81, il y aura une règle d'itinéraire comme celle-ci:

10.244.1.141    0.0.0.0         255.255.255.255 UH    0      0        0 cali4eac25ec62b

Cela enverra finalement la demande au bon pod.

Je ne sais pas pourquoi un démon est nécessaire, je suppose que le démon sert à empêcher la suppression manuelle des règles de route qu'il a créées.

kube-proxy

le travail de kube-proxy est plutôt simple, il redirige simplement les demandes de l'IP du cluster vers l'IP du pod.

kube-proxy a deux modes, IPVS et iptables. Si votre kube-proxy fonctionne en mode IPVS, vous pouvez voir les règles de redirection créées par kube-proxy en exécutant la commande suivante sur n'importe quel nœud du cluster:

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   
...

Dans ce cas, vous pouvez voir l'IP de cluster par défaut de CoreDNS 10.96.0.10, et derrière il y a deux vrais serveurs avec Pod IP: 10.244.0.137 et 10.244.0.138.

Cette règle est le kube-proxy à créer, et c'est ce que le kube-proxy a créé.

P.S. iptables le mode est presque le même, mais les règles iptables sont laides. Je ne veux pas le coller ici. : p

5
Lentil1016