La situation est que j'ai 2 applications: A et B qui sont dans le même espace de noms d'un cluster sur gke. A est sur 1 pod et B sur 2 pods.
Chaque fois qu'un client communique avec notre service. Il se connecte d'abord sur A avec des websockets. A envoie ensuite une requête http à B. Puisqu'il y a 2 pods de B, je voudrais avoir une affinité de session entre le client de l'extérieur et avec mon application B afin que chaque fois qu'un client se connecte à A, il traitera toujours ses demandes via le même gousse de B.
Chaque option d'affinité de session que j'ai vue est basée sur la passerelle ou les services Ingress, mais comme je suis déjà dans le cluster, je n'ai pas besoin d'une entrée.
J'ai également vu qu'il existe des services qui fournissent un support pour les cookies http. Ce serait bien mais c'est toujours un service externe comme Nginx ou Istio et comme je travaille dans un environnement de développement très restreint, c'est un peu pénible d'ajouter ces services dans le cluster.
Y a-t-il quelque chose de natif de gke qui peut me fournir une affinité de session de cookie http ou quelque chose de similaire?
3 Réponses :
Chaque fois qu'un client communique avec notre service. Il se connecte d'abord sur A avec des websockets. A envoie ensuite une requête http à B. Puisqu'il y a 2 pods de B, je voudrais avoir une affinité de session entre le client de l'extérieur et avec mon application B afin que chaque fois qu'un client se connecte à A, il traitera toujours ses demandes via le même gousse de B.
A communique avec B. A doit se connecter à une instance spécifique de B en fonction de l'utilisateur final connecté à B.
Il s'agit de partitionnement et non d ' affinité de session mais je comprends ce que vous voulez dire. Cela signifie que votre service B a besoin d'une identité réseau stable.
Le service B doit être déployé en tant que StatefulSet < / a> pour obtenir une identité réseau stable. Ensuite, le service A peut effectuer un partage , par exemple basé sur nom d'utilisateur ou une plage d'adresses IP ou quelque chose, les demandes pour l ' utilisateur X sont toujours traitées par l'instance Y .
Avec le service B déployé en tant que StatefulSet, les instances seront nommées par ex. app-b-0 et app-b-1 afin que chaque instance puisse être adressée à partir du service A avec une identité stable.
La deuxième demande est de A à B (dans le même cluster). La seule demande provenant de l'extérieur du cluster utilisant une entrée est la connexion initiale à A par websockets
J'ai vu le lien que vous avez envoyé dans votre réponse. J'ai déjà essayé de l'implémenter et cela n'a pas fonctionné, mais après avoir examiné plus en détail, je pense que cela n'est pas destiné à GKE mais plus à une autre partie de la plate-forme cloud Google.
Oui, l'équilibreur de charge est en dehors de GKE, mais utilise des objets Ingress
Vous auriez pu définir l'affinité de session basée sur l'adresse IP du client, ce qui se produit au niveau du service, comme celui-ci:
apiVersion: v1
kind: Service
metadata:
name: svc-sa
spec:
ports:
- port: 80
targetPort: 80
protocol: TCP
name: http
selector:
app: nginx
sessionAffinity: ClientIP
sessionAffinityConfig:
clientIP:
timeoutSeconds: 3600
Donc, ce service acheminerait la demande vers le même backend (Pod), en fonction de l'adresse IP source si la demande.
Vous devez quand même définir un service devant l'application B ciblant les deux pods. Maintenant, le problème ici est que votre application A agit en tant que proxy, donc toutes les requêtes seront prises en compte à partir de l'application A.
Je sais que c'est maintenant une réponse complète, mais vous pourrez peut-être faire quelque chose dans l'application A, par en-tête (X-Forwarded-For), pour contourner l'adresse IP du pod A, par l'adresse IP de la demande d'origine.
L'affinité ClientIP ne fonctionnerait pas dans mon environnement car il existe de nombreuses couches de proxy et de sécurité entre le client et A. Faire de l'IP non pas l'IP du client mais l'ip du proxy
Ouais, c'était aussi mon point, à moins que vous ne puissiez conserver l'adresse IP du client d'origine. Avec les cookies, vous devez obtenir une entrée.
Dans un cluster GKE, lorsque vous créez un objet Kubernetes Ingress, le contrôleur d'entrée GKE se réveille et crée un équilibreur de charge HTTP (S) Google Cloud Platform. Le contrôleur d'entrée configure l'équilibreur de charge et configure également un ou plusieurs services de backend associés à l'équilibreur de charge.
À partir de la version 1.11.3-gke.18 de GKE, vous pouvez utiliser une entrée pour configurer ces propriétés d'un service backend:
Ce sera utile pour vous et natif de GKE Ingress.