1
votes

Équilibreur de charge interne GCP

J'essaie d'accéder au cluster elasticsearch sur GKE à partir de mon projet dans GAE - flexible. Puisque je ne veux pas d'équilibreur de charge externe, je suis ce guide: https://cloud.google.com/kubernetes- engine / docs / how-to / internal-load-balancing GKE et GAE sont déployés dans la même région, mais les appels au cluster elasticsearch expirent constamment. Est-ce que quelqu'un a fait cela et peut partager quelques conseils serait très apprécié!

Mon fichier service.yaml ressemble à ceci:

apiVersion: v1
kind: Service
metadata:
  name: internalloadbalancerservice
  annotations:
    cloud.google.com/load-balancer-type: "Internal"
  labels:
    app.kubernetes.io/component: elasticsearch-server
    app.kubernetes.io/name: elasticsearch  #label selector service
spec:
  type: LoadBalancer
  loadBalancerSourceRanges:   # restrict access
  - xxxxxxxx
  ports:
  - name: myport
    port: 9000
    protocol: TCP # default; can also specify UDP
  selector:
    app.kubernetes.io/name : elasticsearch # label selector for Pods
    app.kubernetes.io/component: elasticsearch-server


0 commentaires

3 Réponses :


0
votes

En supposant que l'application GAE et le cluster GKE se trouvent dans la même région et dans le même réseau VPC, je vous suggère de vous assurer que vous avez créé Ingress autorise les règles de pare-feu qui s'appliquent aux nœuds GKE en tant que cibles avec les VM de l'application GAE en tant que sources.

N'oubliez pas que l'entrée sur les machines virtuelles est refusée par la règle implicite de refus d'entrée. Ainsi, à moins que vous ne créiez des règles de pare-feu Ingress, vous ne pourrez envoyer de paquets à aucune VM. Et pour utiliser un équilibrage de charge interne (ILB) , le client et les VM backend doivent être dans le même:
- Région
- Réseau VPC
- Projet


0 commentaires

2
votes

Pour sauver quelqu'un d'autre d'une situation similaire, je vais partager mes découvertes sur les raisons pour lesquelles je n'ai pas pu me connecter à mon application GKE depuis GAE. Le GAE était dans la région europe-west, tandis que GKE était dans la région europe-west-4a. Je pensais que ce serait la même région. Mais le changement de région GKE en europe-west-1b a fonctionné. Pas très évident mais à la lecture de la documentation GAE region europe-west et GKE region europe-west-1b sont toutes les deux en Belgique.


0 commentaires

3
votes

GCP propose désormais un Global Access avec des équilibreurs de charge internes qui permettront aux équilibreurs de charge internes d'être accessibles depuis n'importe quelle région du même réseau.

Cela sera également utile pour votre cas. Si deux services sont exposés à l'aide d'adresses IP internes mais situés dans des régions différentes.

MISE À JOUR

La fonctionnalité d'accès global est désormais stable (pour GKE 1.16.x strong> et au-dessus) et il peut être activé en ajoutant l'annotation ci-dessous à votre service.

apiVersion: v1
kind: Service
metadata:
  name: internalloadbalancerservice
  annotations:
    cloud.google.com/load-balancer-type: "Internal"

    # Required to enable global access
    networking.gke.io/internal-load-balancer-allow-global-access: "true"

  labels:
    app.kubernetes.io/component: elasticsearch-server
    app.kubernetes.io/name: elasticsearch  #label selector service
spec:
  type: LoadBalancer
  loadBalancerSourceRanges:   # restrict access
  - xxxxxxxx
  ports:
  - name: myport
    port: 9000
    protocol: TCP # default; can also specify UDP
  selector:
    app.kubernetes.io/name : elasticsearch # label selector for Pods
    app.kubernetes.io/component: elasticsearch-server

Par exemple : Le manifeste ci-dessous créera votre internalloadbalancerservice LoadBalancer avec une adresse IP interne et cette IP sera accessible depuis n'importe quelle région du même VPC.

networking.gke.io/internal-load-balancer-allow-global-access: "true"

Cela fonctionne bien pour GKE 1.16.x et les versions ultérieures. Pour les anciennes versions de GKE, vous pouvez consulter cette réponse .


0 commentaires