Hoe over te schakelen van een NGINX Ingress Regional Load Balancer naar een Global HTTPS Load Balancer op GCP

Als je Gitlab gebruikt en je zet je cloud omgeving op GCP op met het cluster-management project van Gitlab, zul je vroeger of later merken dat er een paar dingen ontbreken die je misschien nodig hebt. Hier zullen we ons richten op de ontbrekende implementatie om een Global HTTPs Load Balancer in te stellen in plaats van een Regional HTTPs Load Balancer om Cloud Armor op het Cloud Project te gebruiken.

 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"}}}' 

Door deze instellingen toe te passen, overschrijven we het type van de ingang naar ClusterIP (dit was voor LoadBalancer standaard) en we annoteren die ingang ook met een NEG (Network Endpoint Group). De NEG zal dienen als de backend van de nieuwe Global Load Balancer die we moeten maken. Laat de pijplijn lopen, zodat de wijzigingen worden ingezet in je cluster. De ingang moet worden ingezet met het type ClusterIP.

Verander de noodzakelijke dingen aan GCP-zijde

Allereerst moet je verbinding maken met je GCP project en ervoor zorgen dat je op de juiste context zit als je er meerdere hebt. Je kunt dit controleren door kubectl config get-contexts te gebruiken (toont de huidige context door "star").Allereerst moet je enkele globale variabelen instellen. Ze kunnen er als volgt uitzien:

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

Merk op dat de meeste (misschien alle?) volgende configuraties gedaan kunnen worden via de GCP frontend. Ik heb dat echter niet getest en heb het bij de console-manier gehouden.

Een statisch IP maken

Als je geen eigen IP-adres hebt, moet je een statisch IP-adres maken met het volgende commando:

 gcloud compute addresses create ${CLUSTER_NAME}-loadbalancer-ip \
--globaal
--ip-versie IPV4 

Firewall regel aanmaken

Je moet een firewallregel maken om onze nieuwe Global Load Balancer toegang te geven tot en te laten communiceren met ons cluster. De IP-adressen die we toestaan worden gebruikt voor de gezondheidscontroles en zijn IP-adressen van de Google Front End (GFE) die verbonden is met de backend. Zonder deze adressen zullen de gezondheidscontroles niet slagen voor de neg (backend van LB). Je moet het volgende commando gebruiken om de benodigde firewall te maken:

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  

De gezondheidscontrole maken

We moeten een healthcheck maken voor de aankomende Backend Service om te zien of alles nog in orde is in ons systeem. Om de healthcheck te maken voeg je het volgende commando toe:

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

De ingang (NEG) toevoegen aan de backend service

De Backend-Service van de aankomende Loadbalancer krijgt nu de ingress, die nu een NEG is en geen LoadBalancer meer, gekoppeld. Gebruik het volgende commando:

gcloud compute backend-services add-backend ${CLUSTER_NAME}-backend-service \
  --network-eindpunt-groep=ingress-nginx-80-neg \
  --network-eindpunt-groep-zone=$ZONE \
  --balancing-mode=RATE \
  --capaciteits-scaler=1.0 \
  --max-snelheid-per-eindpunt=100 \
  --globaal

Maak de nieuwe Global HTTPs Load Balancer

Je kunt de nieuwe loadbalancer aanmaken met het volgende commando. Maar wees geduldig, want het kan een paar minuten duren voordat dit voltooid is of zichtbaar is in de GCP frontend.

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

Een zelfbeheerd certificaat maken

In de volgende blogpost zal ik dieper ingaan op het onderwerp certificaat op de loadbalancer. Omdat we een HTTPs loadbalancer gebruiken, hebben we een soort certificaat nodig. Ik heb een zelfbeheerd certificaat aangemaakt via OpenSSL en de inhoud van de bestanden geüpload naar GCP. Je kunt dit echter ook via de console doen:

gcloud compute ssl-certificates create $CERTIFICATE_NAME \
    --certificaat=mijn-cert.pem \
    --private-key=mijn-cert-key.pem \
    --globaal

Gebruik dit niet op productie omdat het certificaat dan niet geldig is en de verbinding niet beveiligd is. Raadpleeg de volgende blogpost over hoe om te gaan met certificering op de loadbalancer.

Bewerk de Loadbalancer in de GCP Frontend

De loadbalancer zou zichtbaar moeten zijn. Selecteer deze en klik op bewerken. Alles zou geconfigureerd moeten zijn behalve de frontend configuratie. Voer de volgende configuraties uit:
- Selecteer Add Frontend IP and Port
‍-Geef het een naam en selecteer HTTPs
- Als je een statisch ip-adres hebt, gebruik dit dan in het ip-adresveld. gebruik anders Ephemeral
- Selecteer het aangemaakte certificaat (je kunt ook een door google beheerd certificaat gebruiken)
- Als je een statisch IP-adres hebt, kun je HTTP naar HTTPS redirect inschakelen. Er wordt een nieuwe "loadbalancer" / "mapping" gemaakt, zonder backend. Ik ben er vrij zeker van (niet 100%) dat het min of meer een doorstuurregel is
- Sla de Loadbalancer op- Controleer of alles gezond is en werkt
- Gefeliciteerd, je loadbalancer werkt 🙂.

Aanvullende informatie over hoe dit werkt

Hoe wordt de NEG bijgewerkt?

De Load Balancer / Neg krijgt een melding als de inzet van de ingress de pod wijzigt. Daarom is het ook mogelijk om de ingress zelf op te schalen. De NEG werkt zichzelf bij als er iets gebeurt. Dit is standaard geconfigureerd in de implementatie van de ingress met --publish-service

Firewall Regel specifiek netwerklabel

De firewallregel voor de verbinding met het backend is alleen van toepassing op een specifieke tag, die eruitziet als een knooppunt. Bijvoorbeeld: "gke-staging-456b4340-node"Dit is echter een netwerk-tag, die op elke Compute Instance van het cluster staat. Daarom werken de healthchecks zelfs als er nieuwe nodes zijn of als de bestaande veranderen.

Kai Müller
Software-ingenieur