Document ID: /fineweb-2-swissfilter-quality_10-filterrobots/filtered/06960.jsonl.gz/842

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.
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.
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 :
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.
Si vous n'avez pas votre propre adresse IP, vous devez créer une adresse IP statique avec la commande suivante :
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 :
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 :
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 :
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.
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 :
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.
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 🙂
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
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