Comment passer d'un équilibreur de charge régional NGINX Ingress à un équilibreur de charge HTTPS global sur GCP

Si vous utilisez Gitlab et que vous mettez en place votre environnement cloud sur GCP avec le projet de gestion de clusters de Gitlab, vous remarquerez tôt ou tard qu'il manque quelques éléments dont vous pourriez avoir besoin. Nous nous concentrerons ici sur l'implémentation manquante pour configurer un équilibreur de charge HTTP global au lieu d'un équilibreur de charge HTTP régional afin d'utiliser Cloud Armor sur le projet Cloud.

 controller:
  stats:
    enabled: true
  podAnnotations:
    prometheus.io/scrape: "true"
    prometheus.io/port: "10254"
  service:
      type: ClusterIP
      annotations:
        cloud.google.com/neg: '{"exposed_ports": {"80":{"name": "ingress-nginx-80-neg"}}}'

En appliquant ces paramètres, nous remplaçons le type d'accès au ClusterIP (ce qui était le cas par défaut avant LoadBalancer ) et nous annotons également cet accès avec un NEG (Network Endpoint Group). Le NEG servira de backend au nouvel équilibreur de charge global que nous devons créer. Faites tourner le pipeline pour que les changements soient déployés dans votre cluster. L'intrusion doit être déployée avec le type ClusterIP.

Changement des choses nécessaires du côté des BPC

Tout d'abord, vous devez vous connecter à votre projet BPC et vous assurer que vous êtes sur le bon contexte si vous en avez plusieurs. Vous pouvez le vérifier en utilisant kubectl config get-contexts (indique le contexte actuel par "star"). Elles peuvent ressembler à ceci :

ZONE=europe-west6-c
CLUSTER_NAME=cluster my-gke
HEALTH_CHECK_NAME=nginx-ingress-controller-health-check
NETWORK_NAME=my-review-default-vpc
NETWORK_TAGS=$(gcloud compute instances describe \
    $(kubectl get nodes -o jsonpath='{.items[0].metadata.name}') \There is the node.
    --zone=$ZONE --format="value(tags.items[0])")

Veuillez noter que la plupart (peut-être toutes ?) les configurations suivantes peuvent être effectuées via le frontal GCP. Cependant, je n'ai pas testé cela et j'ai choisi la voie de la console.

Créer une IP statique

Si vous n'avez pas votre propre adresse IP, vous devez créer une adresse IP statique avec la commande suivante :

 gcloud compute addresses create ${CLUSTER_NAME}-loadbalancer-ip \
--global \
--ip-version IPV4

Créer une règle de pare-feu

Vous devez créer une règle de pare-feu pour autoriser notre nouvel équilibreur de charge global à accéder et à communiquer avec notre cluster. Les adresses IP que nous autorisons sont utilisées pour les contrôles de santé et sont les adresses IP du Google Front End (GFE) qui est connecté au backend. Sans elles, les contrôles de santé ne réussiront pas pour le neg (backend de LB). Vous devez utiliser la commande suivante pour créer le pare-feu nécessaire :

gcloud compute firewall-rules create ${CLUSTER_NAME}-allow-tcp-loadbalancer \
    --allow tcp:80 \
    --source-ranges 130.211.0.0/22,35.191.0.0/16 \
    --target-tags $NETWORK_TAGS \
    --network $NETWORK_NAME

Créer le bilan de santé

Nous avons besoin de créer un bilan de santé pour le service backend à venir afin de voir si tout va bien dans notre système. Pour créer le bilan de santé, ajoutez la commande suivante :

gcloud compute backend-services create ${CLUSTER_NAME}-backend-service \
    --load-balancing-scheme=EXTERNAL \
    --protocol=HTTP \
    --port-name=http \
    --health-checks=${CLUSTER_NAME}-nginx-health-check \
    --global

Ajouter l'ingress (NEG) au service de gestion

Le service de backend de l'équilibreur de charge à venir va maintenant recevoir l'ingress, qui est maintenant un NEG et non plus un LoadBalancer, attaché. Utilisez la commande suivante :

gcloud compute backend-services add-backend ${CLUSTER_NAME}-backend-service \
  --network-endpoint-group=ingress-nginx-80-neg \\
  --network-endpoint-group-zone=$ZONE \\
  --balancing-mode=RATE \\
  -capacity-scaler=1.0 \N
  --max-rate-per-endpoint=100 \
  --global

Créer le nouvel équilibreur de charge global HTTPs

Vous pouvez créer le nouvel équilibreur de charge en utilisant la commande suivante. Mais soyez patient, car cela peut prendre quelques minutes pour se terminer ou pour être visible dans le frontend du BPC.

gcloud compute url-maps create ${CLUSTER_NAME}-loadbalancer \
    --default-service ${CLUSTER_NAME}-backend-service

Créer un certificat autogéré

Je vais m'intéresser de plus près à la question des certificats sur l'équilibreur de charge dans le prochain billet de blog. Comme nous utilisons un équilibreur de charge HTTPs, nous avons besoin d'un certain type de certificat. J'ai créé un certificat auto-géré via OpenSSL et j'ai téléchargé le contenu des fichiers dans GCP. Toutefois, vous pouvez également le faire via la console :

gcloud compute ssl-certificates create $CERTIFICATE_NAME \
    --certificate=my-cert.pem \\N
    --private-key=my-cert-key.pem \\N
    --global

Veuillez ne pas l'utiliser en production, car le certificat ne sera pas valable et la connexion ne sera pas sécurisée. Consultez le prochain blog post sur la manière de gérer la certification sur l'équilibreur de charge.

Modifier l'équilibreur de charge dans le frontal BPC

L'équilibreur de charge devrait être visible. Sélectionnez-le et cliquez sur edit. Tout devrait être configuré, sauf la configuration du frontal. Effectuez les configurations suivantes :
- Sélectionnez Add Frontend IP and Port
‍-Nommez-le et sélectionnez HTTPs
- Si vous avez une adresse ip statique, utilisez-la dans le champ ip address. sinon, utilisez Ephemeral
- Sélectionnez le certificat créé (Vous pouvez aussi utiliser un certificat géré par google)
- Si vous avez une adresse IP statique, vous pouvez activer la redirection HTTP vers HTTPS. Il y aura un nouveau "loadbalancer" / "mapping" créé, sans backend. Je suis assez sûr (pas à 100%) que c'est plus ou moins une règle de redirection
- Save the Loadbalancer- Vérifie que tout est sain et fonctionne
- Félicitations, ton loadbalancer est en place et fonctionne 🙂

Informations supplémentaires sur le fonctionnement de ce système

Comment la NEG est-elle mise à jour ?

L'équilibreur de charge / le Neg est informé si le déploiement de l'ingress modifie le pod. Il est donc également possible d'augmenter l'ingression elle-même. Le NEG se met à jour lui-même si quelque chose se passe. Ceci est configuré par défaut dans le déploiement de l'ingress avec --publish-service

Règle de pare-feu spécifique à la balise réseau

La règle de pare-feu pour la connexion au backend s'applique uniquement à une balise spécifique, qui ressemble à un nœud. Par exemple : "gke-staging-456b4340-node "Toutefois, il s'agit d'une balise réseau, qui se trouve sur chaque instance de calcul du cluster. Ainsi, les bilans de santé fonctionnent même s'il y a de nouveaux nœuds ou si les existants changent.

Kai Müller
Ingénieur logiciel