Évolutivité du proxy-kube

Question

J'ai rencontré un problème d'évolutivité lors de l'essai du cluster kubernetes. Pour simplifier la topologie de mon ordinateur de test, le type NodePort est utilisé pour exposer le service individuel en externe. Le baremetal pour héberger le noeud et le maître est un RHEL 7 avec 24 CPU et 32G RAM; Je n'ai pas encore d'équilibreur de charge dédié, ni de fournisseur de cloud comme infrastructure. Un extrait de la définition du service ressemble ci-dessous

"spec": {  
     "ports": [{ 
      "port": 10443,    
      "targetPort": 10443,    
      "protocol": "TCP",         
      "nodePort": 30443 
    } ], 
    "type": "NodePort", 

Grâce à cette façon, l'application peut être accessible via https://[node_machine]:30443/[a_service]

tel service est seulement soutenu par un Pod. Idéalement, je voudrais avoir plusieurs services déployés sur le même nœud (mais en utilisant différents NodePort), et en cours d'exécution simultanément. Les choses fonctionnaient bien jusqu'à ce qu'il devienne évident que pour une charge de travail similaire, augmenter le nombre de services déployés (donc les pods backend) fait que les applications se dégradent en performance. De façon surprenante, en décomposant le temps de chargement du service, j'ai remarqué une dégradation dramatique du 'temps de connexion' qui semble indiquer qu'il y a un ralentissement quelque part dans la couche 'réseau'. Veuillez noter que la charge n'est pas assez élevée pour conduire une grande partie du CPU sur le nœud pour le moment. J'ai lu sur le shortcomings dans le document, mais je ne sais pas si ce que je frappe est exactement la limitation de la Kube-proxy/Service décrit là-bas.

Les questions sont les suivantes:

1. Y at-il suggéré sur la façon de le rendre plus évolutif? C'est à dire. être capable de supporter plus de services/Pods sans scarifier les performances des applications? Le type NodePort est le moyen le plus simple de configurer l'adresse publique pour nos services, mais y a-t-il des limites à l'évolutivité ou aux performances si tous les services et modules sont configurés de cette façon?

2. Y aurait-il une différence si nous changions le type en LoadBalancer? "type": "LoadBalancer"

3. En outre, existe-t-il un avantage d'avoir un LoadBalancer ou un proxy inverse dédié pour améliorer l'évolutivité, par ex. HAProxy ou similaire, qui achemine le trafic des Pods externes (ou Services)? J'ai remarqué qu'il y a du travail pour Nginx darkgaro/kubernetes-reverseproxy - malheureusement le document semble incomplet et il n'y a pas d'exemple concret. Dans certains des autres sujets, les gens ont parlé de Vulcan - est-ce l'outil LB recommandé pour les kubernetes?

Votre recommandation et aide sont très appréciées!

Answer 1

Bonjour je suis un peu nouveau à kubernetes mais j'ai des questions et des préoccupations similaires. J'essaierai de répondre à certaines d'entre elles ou de vous rediriger vers les sections pertinentes du guide de l'utilisateur. Si vous déployez Kubernetes sur un fournisseur non compatible avec le cloud comme par exemple vagabond/local, alors certaines fonctionnalités ne sont actuellement pas offertes ou automatisées par la plate-forme pour u.

Une de ces choses est le type de service 'LoadBalancer'. La fourniture automatique et l'attribution d'une IP PUBLIQUE au service (agissant un L.B) se produit actuellement uniquement dans des plates-formes comme Google Container Engine.

Voir le numéro here et here.

La documentation officielle indique

Sur les fournisseurs de cloud qui prennent en charge les équilibreurs de charge externes, le réglage du champ de type à disposition de volonté « LoadBalancer » un équilibreur de charge pour votre service .

Actuellement une alternative est en cours d'élaboration et documenté, voir here en utilisant HAProxy. Dans un proche avenir, kubernetes pourra éventuellement prendre en charge ce type de fonctionnalité sur toutes les plates-formes disponibles pouvant être déployées et exploitées. Par conséquent, vérifiez toujours leurs fonctionnalités mises à jour. Ce que vous appelez dégradation de la performance est probablement dû au fait que la fonctionnalité PublicIP (NodePort à partir de la version 1.0 et suivante) fonctionne. Cela signifie qu'avec l'utilisation du type de service NodePort, kubernetes affecte un port sur TOUS les nœuds du cluster pour ce type de service. Ensuite, les intercepts de Kube-proxy les appels vers ces ports au service réel, etc.

Un exemple sur l'utilisation haproxy essayer de résoudre le problème même se trouvent here.

J'espère que cela a aidé un peu.

Answer 2

Je suis confronté aux mêmes problèmes. Il semble que le proxy kube interne ne soit pas destiné à être un équilibreur de charge externe. Plus précisément, nous voulions configurer un certain délai sur Kube-proxy ou faire des ré-essais, etc

J'ai trouvé this article qui décrit des problèmes similaires. Il recommande de regarder vulcan car il utilise en interne etcd et probablement la direction de ce projet est de fournir LB complet pour les k8 à l'avenir.