3
votes

OpenShift Route n'équilibre pas la charge à partir des modules de service

J'ai déjà essayé OpenShift Origin 3.9 et Online. J'ai déployé une simple application php hello world sur OpenShift. Il a un service et une route.

Lorsque j'appelle la route, j'obtiens la sortie attendue avec Hello world et l'IP du pod. Appelons ce pod ip comme 1.1.1.1

J'ai maintenant déployé la même application avec un petit changement de texte avec la même étiquette sous le même service. Appelons ce pod ip comme 2.2.2.2

Je peux voir les deux pods s'exécuter dans un seul service. Maintenant, quand j'appelle la route, il montre toujours Podip 1.1.1.1 Mon itinéraire n'atteint jamais le deuxième pod.

Je crois comprendre que Route appellera le service et que le service équilibrera la charge entre les pods disponibles.

Mais cela ne se produit pas. Toute aide est appréciée.

kubernetes openshift openshift-origin openshift-3

0 commentaires

4 Réponses :

7
votes

Le comportement par défaut du routeur HAProxy est d'utiliser un cookie pour assurer un routage "collant". Cela permet aux sessions de rester avec le même pod. https://docs.openshift.com/container-platform/3.11 /architecture/networking/routes.html

Si vous définissez une annotation haproxy.router.openshift.io/disable_cookies sur l'itinéraire sur true , cela devrait désactiver ce comportement.

0 commentaires

2
votes

Je crois comprendre que Route appellera le service et que le service équilibrera la charge entre les pods disponibles.

En général, vos connaissances sont exactes. Testons-le sur votre environnement comme suit.
while :; do curl http://172.30.177.72:8080/index.html; sleep 1;  done
1.1.1.1:8080
2.2.2.2:8080
1.1.1.1:8080 
2.2.2.2:8080
...
Session Affinity est None comme valeur par défaut, cela signifie round robin pour les requêtes.

Vous pouvez vérifier l'accès aux requêtes de manière round robin en bouclant curl en surveillant le pods utilisant le corps de réponse oc logs ou index.html (si le contenu est différent).
# oc describe svc web
Name:              web
Namespace:         test
Labels:            app=web
Annotations:       openshift.io/generated-by=OpenShiftNewApp
Selector:          app=web,deploymentconfig=web
Type:              ClusterIP
IP:                172.30.6.8
Port:              8080-tcp  8080/TCP
TargetPort:        8080/TCP
Endpoints:         1.1.1.1:8080,2.2.2.2:8080
Session Affinity:  None
Events:            <none>
blockquote>

0 commentaires

2
votes

Pour ceux qui sont venus ici à la recherche d'une solution; Les deux réponses de Daein Park et Will Gordon sont vraies.

Voici une simple capture:

Si vous appelez votre pod en externe, il passe du routeur au service en passant par le pod. Si l'annotation haproxy.router.openshift.io/disable_cookies n'est pas définie sur true sur le routeur, le service est toujours transféré vers le même pod.

De plus, après avoir désactivé le routage permanent avec l'annotation ci-dessus, vous pouvez sélectionner un algorithme d'équilibrage de charge avec: haproxy.router.openshift.io/balance comme clé et l'un des [source, roundrobin, lessconn] comme valeur
Si vous appelez votre pod en interne depuis un autre pod. Cela va du service au pod. Le service effectue correctement l'équilibrage de charge circulaire avec la configuration par défaut.

Vous devriez donc:

Ajoutez ladite annotation à votre routeur si vous souhaitez que votre service soit exposé par un routeur.
Ne rien faire si vous souhaitez que votre service ne soit accessible qu'en interne

(Testé sur OpenShift 4.2.28)

0 commentaires

0
votes

Les services n'équilibrent PAS la charge entre les pods, c'est complètement aléatoire. Cela nous a été confirmé par le support RedHat. De plus, les réponses ci-dessus ne font que des tests avec différents appels sur curl.

Si vous faites des appels ultérieurs sur le même curl, vous verrez que cela réutilise les connexions. Essayez simplement:

curl http://172.30.177.72:8080/index.html http://172.30.177.72:8080/index.html

Au lieu de faire une interation et vous verrez que le keep-alive réutilisera la connexion et vous finirez sur le même pod à chaque fois

0 commentaires