Explication détaillée du mode proxy kube-proxy
kube-proxy prend actuellement en charge les modes proxy suivants :
1. Espace utilisateur : La première solution d'équilibrage de charge, elle écoute un port dans l'espace utilisateur, et tous les services sont transmis à ce port via iptables, puis la charge interne est équilibrée sur le pod réel. Le principal problème de cette méthode est une faible efficacité et un goulot d'étranglement évident des performances, elle n'est donc plus recommandée.
Par exemple, pour créer un service, l'IP correspondant : 1.2.3.4, port : 8888, le port sélectionné aléatoirement par kube-proxy est 32890, il sera ajouté dans iptables
-A PREROUTING -j KUBE-PORTALS-CONTAINER
-A KUBE-PORTALS-CONTAINER -d 1.2.3.4/32 -p tcp --dport 8888 -j REDIRECT --to-ports 32890
KUBE-PORTALS-CONTAINER est la chaîne de règles créée par kube-proxy dans iptable, qui est exécutée dans la phase PREROUTING
Processus de mise en œuvre:
- Lorsqu'il y a une demande d'accès au service, dans l'étape PREROUTING, jumpKUBE-PORTALS-CONTAINER sera demandé ;
- Cet enregistrement dans KUBE-PORTALS-CONTAINER fonctionne, redirigeant la requête vers le port 32890 que kube-proxy vient d'écouter, et le paquet de données entre dans le processus kube-proxy ;
- Ensuite, kube-proxy en sélectionnera un à partir du point de terminaison correspondant au service en fonction de la SessionAffinity comme demande de réponse de service réelle.
2. iptables : la solution actuellement recommandée utilise les règles iptables pour réaliser l'équilibrage de charge des services. Le principal problème avec cette méthode est que trop de règles iptables sont générées lorsqu'il y a de nombreux services, et les mises à jour non incrémentielles introduiront un certain retard, et il y a des problèmes de performances évidents dans les cas à grande échelle.
Par exemple, si un service est créé, l'IP correspondante : 1.2.3.4, port:8888, et une adresse backend correspondante : 10.1.0.8:8080, il sera ajouté dans iptables (règles principales) :
-A PREROUTING -j KUBE-SERVICES
-A KUBE-SERVICES -d 1.2.3.4/32 -p tcp –dport 8888 -j KUBE-SVC-XXXXXXXXXXXXXXXX
-A KUBE-SVC-XXXXXXXXXXXXXXXX -j KUBE-SEP-XXXXXXXXXXXXXXXX
-A KUBE-SEP-XXXXXXXXXXXXXXXX -p tcp -j DNAT –to-destination 10.1.0.8:8080
KUBE-SERVICES est la chaîne de règles créée par kube-proxy dans iptable, qui est exécutée à l'étape PREROUTING
Processus de mise en œuvre:
- Lors de la demande d'accès au service, iptables passera à KUBE-SERVICES pendant l'étape de préroutage ;
- Faites correspondre le premier critère ci-dessus dans KUBE-SERVICES, continuez à passer à KUBE-SVC-XXXXXXXXXXXXXXX ;
- Aller à KUBE-SEP-XXXXXXXXXXXXXXXX selon cette règle ;
- Dans la règle KUBE-SEP-XXXXXXXXXXXXXXXX, accédez à l'adresse réelle du pod 10.1.0.8:8080 via l'action DNAT.
3. ipvs : afin de résoudre le problème de performances du mode iptables, la v1.11 a ajouté le mode ipvs (la v1.8 a commencé à prendre en charge la version bêta et la v1.11 GA), en utilisant une mise à jour incrémentielle, et peut garantir la connexion pendant le service. mise à jour Gardez-le.
En mode IPVS, kube-proxy observe les modifications des objets de service et de point de terminaison dans Kubernetes, crée les règles IPVS correspondantes en appelant l'interface netlink et synchronise périodiquement les règles de service, de point de terminaison et IPVS de Kubernetes. Lors de l'accès à un service, IPVS est chargé de sélectionner un véritable backend pour fournir des services.
Le mode IPVS est également basé sur la fonction de crochet de netfilter (étape INPUT), qui est identique au mode iptables, mais utilise la table de hachage de l'espace de travail du noyau comme structure de données stockée. Dans ce mode, iptables peut être vérifié par ipset. requête satisfait une règle. Lorsque le service change, seuls les enregistrements dans ipset doivent être mis à jour et la chaîne de règles d'iptables n'a pas besoin d'être modifiée. Par conséquent, il peut être garanti que les règles dans iptables n'augmenteront pas avec l'augmentation des services et fourniront performances constantes dans le cas de clusters de services à très grande échelle Effet.
Les performances lors de la synchronisation des règles sont également supérieures à celles d'iptables (seule une table de hachage spécifique est mise à jour, plutôt que de fonctionner sur l'ensemble de la table de règles en mode iptables), de sorte qu'elle peut fournir un trafic réseau plus élevé.
IPVS fournit également des algorithmes plus flexibles dans la sélection des services backend :
- rr : round-robin (algorithme round-robin)
- lc : moindre connexion (algorithme de numéro de connexion minimum)
- dh : hachage de destination (algorithme de hachage d'adresse de destination)
- sh : hachage de la source (algorithme de hachage de l'adresse d'origine)
- sed : délai le plus court attendu (algorithme de délai le plus court attendu)
- nq : jamais en file d'attente (algorithme jamais en file d'attente)
4. winuserspace : identique à l'espace utilisateur, mais ne fonctionne que sur les nœuds Windows.
C'est la fin du partage d'aujourd'hui
