Équilibrage de charge et mise à l'échelle de connexions à longue durée de vie Kubernetes

Un peu sur la façon dont le trafic est redistribué dans Kubernetes 

1. Dans le diagramme ci-dessous, vous voyez trois instances de la même application et un équilibreur de charge:
   
   
   
2. L'équilibreur de charge est appelé le service, une adresse IP lui est attribuée. Toute demande entrante est redirigée vers l'un des pods:
   
   
   
3. Le script de déploiement détermine le nombre d'instances d'application. Vous n'aurez presque jamais à déployer directement sous:
   
   
   
4. Chaque pod se voit attribuer sa propre adresse IP:
   
   
   

1. Il y a une demande de curl 10.96.45.152 au service:
   
   
   
2. Le service sélectionne l'une des trois adresses de pod comme destination:
   
   
   
3. Le trafic est redirigé vers un pod spécifique:
   
   
   

1. Moins de 1 demande le composant interne backend. Au lieu d'en choisir un spécifique pour le backend, il effectue une demande de service:
   
   
   
2. Le service sélectionne l'un des modules backend comme adresse de destination:
   
   
   
3. Le trafic passe du foyer 1 au foyer 5 sélectionné par le service:
   
   
   
4. En dessous de 1, il ne sait pas exactement combien de foyers de moins de 5 ans sont cachés derrière le service:
   
   
   

Équilibrage dans les services Kubernetes

1. Prenons un cluster de trois nœuds. Il y a des pods sur chaque nœud:
   
   
   
2. Les foyers tricotés peints en beige font partie du service. Étant donné que le service n'existe pas en tant que processus, il est grisé:
   
   
   
3. Le premier demande le service et devrait tomber sur l'un des foyers associés:
   
   
   
4. Mais le service n'existe pas, il n'y a pas de processus. Comment ça marche?
   
   
   
5. Avant que la requête ne quitte le nœud, elle passe par les règles iptables:
   
   
   
6. Les règles iptables savent qu'il n'y a pas de service, et remplacez son adresse IP par l'une des adresses IP des pods associés à ce service:
   
   
   
7. La demande reçoit une adresse IP valide comme adresse de destination et est normalement traitée:
   
   
   
8. Selon la topologie du réseau, la demande parvient finalement au foyer:
   
   
   

Les iptables sont-ils capables d'équilibrer la charge?

1. Choisissez le premier avec une probabilité de 33%, sinon passez à la règle suivante.
2. Choisissez le second avec une probabilité de 50%, sinon passez à la règle suivante.
3. Choisissez le troisième sous.

Les connexions à longue durée de vie dans Kubernetes ne sont pas mises à l'échelle par défaut

• Restez en vie dans Node.js
• Keep-alive in spring boot
• Keep-alive en python
• Restez en vie dans .NET

1. Le premier sous envoie une demande au service:
   
   
   
2. Vous savez déjà ce qui va se passer ensuite. Le service n'existe pas, mais il existe des règles iptables qui traiteront la demande:
   
   
   
3. L'un des modules backend sera sélectionné comme adresse de destination:
   
   
   
4. La demande parvient au foyer. À ce stade, une connexion TCP permanente entre les deux pods sera établie:
   
   
   
5. Toute prochaine demande du premier pod passera par une connexion déjà établie:
   
   
   

1. Obtenez la liste des points de terminaison du service.
2. Pour chaque point de terminaison, ouvrez une connexion persistante.
3. Lorsque vous devez faire une demande, utilisez l'une des connexions ouvertes.
4. Mettez régulièrement à jour la liste des points de terminaison, créez-en de nouveaux ou fermez les anciennes connexions persistantes si la liste change.

1. Au lieu d'envoyer la première demande au service, vous pouvez équilibrer les demandes côté client:
   
   
   
2. Vous devez écrire du code qui demande quels pods font partie du service:
   
   
   
3. Dès que vous recevez la liste, enregistrez-la côté client et utilisez-la pour vous connecter aux pods:
   
   
   
4. Vous êtes vous-même responsable de l'algorithme d'équilibrage de charge:
   
   
   

Équilibrage de charge côté client

var mysql = require('mysql');
var poolCluster = mysql.createPoolCluster();

var endpoints = /* retrieve endpoints from the Service */

for (var [index, endpoint] of endpoints) {
  poolCluster.add(`mysql-replica-${index}`, endpoint);
}

// Make queries to the clustered MySQL database

• WebSockets et WebSockets sécurisés
• HTTP / 2
• gRPC
• RSockets
• AMQP

Équilibrer les connexions de longue durée dans Kubernetes

1. Clusterip
2. NodePort
3. Équilibreur de charge
4. Sans tête

1. La couche de gestion lui attribue une adresse IP.
2. Kube-proxy forme les règles iptables nécessaires.

Service Mesh vous aidera

1. Obtient une liste d'adresses IP du service.
2. Ouvre et gère un pool de connexions.
3. Met à jour périodiquement le pool, en ajoutant ou supprimant des points de terminaison.

1. Sélectionne une connexion disponible en utilisant une sorte de logique (par exemple round-robin).
2. Répond à la demande.

1. Recherche automatiquement les adresses IP des services.
2. Vérifie les connexions telles que WebSockets et gRPC.
3. Équilibre les demandes en utilisant le bon protocole.

Que se passe-t-il si vous ignorez les problèmes d'équilibrage?

Conclusion

1. Trois niveaux de mise à l'échelle automatique dans Kubernetes et comment les utiliser efficacement . 
2. Kubernetes dans l'esprit du piratage avec un modèle d'implémentation .
3. Kubernetes .