Sådan konfigureres NGINX-indtrækscontroller på AWS-klynger

TL; DR Kopier blot indsæt kommandoerne for at få en fuldt funktionel NGINX-controller på enhver AWS Kubernetes-klynge

Ingress-controllere er gateway-administratorerne for netværkstrafik, der indgår i tjenester, der kører på dine Kubernetes-klynger. De beslutter, hvordan trafikken dirigeres ind i klyngen, og hvordan den formes, når den kommer ind i klyngen.

Det er vigtigt at bemærke den første erklæring, jeg fremsatte ovenfor.

Ingress-controllere er gateway-administratorerne for netværkstrafik

Årsagen til at jeg understregede manager er fordi den kun styrer, hvordan trafik kommer ind gennem gatewayen. Det er ikke selve porten.

Lad os forstå dette med et eksempel.

Overvej en AWS-opsætning med én EC2-instans, der understøtter en offentligt vendt Elastic Load Balancer (ELB). Porten til trafikken i dette tilfælde ville være ELB. Gateway manager er den enhed, der konfigurerer ELB og kører den.

Nginx er et godt valg af omvendt proxy til Kubernetes

Bemærk: Jeg har brugt det korte format til at repræsentere Kubernetes-ressourcer. Det er lettere på øjnene. Du kan finde mere information om det her.

Load Balancer Planning

Der er mange måder at tilvejebringe en belastningsafbalancering til en klynge. Med Kubernetes kan du automatisere og programmere det, så det passer perfekt til dine behov. Generelt bruges en af ​​følgende to modeller:

  1. Sæt en belastningsbalancer på klyngeniveau og brug SNI eller sti-baseret routing til tjenester
  2. Indstil en belastningsafbalancering for hver service, der har brug for den

Den første tilgang er den, der blev fulgt i dette blogindlæg. Jeg finder ud af, at de fleste hold, der opretholder belastningsbalancen, ikke er de samme som dem, der administrerer applikationer. Den første tilgang fungerer bedre til sådanne scenarier.

Management på AWS Kubernetes-klynger

I dette blogindlæg vil vi bruge den officielle nginx-indtrækscontroller, der er bosat på dette arkiv. Dette er en meget alsidig og konfigurerbar version af nginx ingress controller. Det kan konfigureres på enhver måde, hvor nginx selv kan konfigureres.

Denne indgangskontroller fungerer ved først at oprette en ELB-instans til klyngen. Denne egenskab giver os mulighed for let at forbinde nginx-indtrækscontrolleren til rute53.

Lad os forstå dette ved at indstille en fuldt funktionsdygtig nginx-indtrækscontroller og indtrædelsesinstanser.

Opsætning af NGINX-indtræksregulator

Start med at oprette et navneområde for indtrækscontrolleren til at køre i

$ kubectl create -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/master/deploy/namespace.yaml

Opret derefter klyngerollen og rollen for nginx-indtrængningskontrolleren

$ kubectl create -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/master/deploy/rbac.yaml

Dette skaber klyngerollen og rollen for indtrækscontrolleren. Skriv derefter en konfigurationsfil til konfiguration af din nginx-proxy

config_map:
  data:
    klient-krop-puffer-størrelse: 32M
    hsts: "sandt"
    proxy-kropsstørrelse: 1G
    proxy-buffering: "falsk"
    proxy-læse-timeout: "600"
    proxy-send-timeout: "600"
    server-tokens: "falsk"
    ssl-omdirigering: "falsk"
    upstream-keepalive-forbindelser: "50"
    use-proxy-protocol: "sandt"
  etiketter:
    app: ingress-nginx
  navn: nginx-konfiguration
  navneområde: ingress-nginx
  version: v1
---
config_map:
  navn: tcp-services
  navneområde: ingress-nginx
  version: v1
---
config_map:
  navn: udp-services
  navneområde: ingress-nginx
  version: v1

Bemærk konfigurationssættet ovenfor. Dette er en standardkonfiguration, der har fungeret godt for os.

Det anbefales at bruge HTTP Strict Transport Security (hsts). Dette sammen med SSL-omdirigeringer bruges til at omdirigere HTTP-anmodninger til HTTPS. Dette anses generelt for at være mere sikkert. Vi anbefaler det, medmindre din tjeneste specifikt skal afslutte SSL selv.

Den anden vigtige mulighed ovenfor er use-proxy-protokol. Da jeg opretter en L4 ELB loadbalancer (som ikke videresender SRC IP, SRC Port, SRC proto og andre muligvis vigtige oplysninger til de tjenester, der ligger bag), giver denne mulighed en mekanisme til at videresende disse L7 headere.

Lad os oprette dette konfigurationskort

$ kort -k -f configmap.short.yaml> configmap.yaml
$ kubectl create -f configmap.yaml

Nu, når konfigurationen er klar til brug, kan vi starte med at oprette standard backend. Standard backend fungerer som en opsamlingstjeneste. Den dirigeres til hver gang der anmodes om en ukendt URL fra denne proxy (dvs. den nginx-proxy, vi kører).

$ kubectl create -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/master/deploy/default-backend.yaml

Dette opretter en pod og en tilsvarende service, der fungerer som en "catch-all", når der anmodes om en URL, der ikke er tilgængelig.

Nu lancerer vi nginx-proxy-pods, der dirigerer trafik til standard backend, indtil en indtrængningsregel tilføjes.

kubectl create -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/master/deploy/with-rbac.yaml

Vi er næsten færdige. Proxy'en er til stede og kører. For at dirigere trafik uden for klyngen ved hjælp af en enkelt URL, er vi nødt til at oprette en ELB-instans. Dette kan gøres ved at oprette en Kubernetes-service af typen Loadbalancer.

apiVersion: v1
kind: Service
metadata:
  anmærkninger:
    service.beta.kubernetes.io/aws-load-balancer-backend-protocol: tcp
    service.beta.kubernetes.io/aws-load-balancer-connection-idle-timeout: "3600"
    service.beta.kubernetes.io/aws-load-balancer-proxy-protocol: '*'
    service.beta.kubernetes.io/aws-load-balancer-ssl-cert: arn: aws: acm: us-east-1: 1234567: Certificate / 1234294-232-4f89-bca8
    service.beta.kubernetes.io/aws-load-balancer-ssl-ports: https
  etiketter:
    k8s-addon: ingress-nginx.addons.k8s.io
  navn: ingress-nginx
  navneområde: ingress-nginx
spec:
  eksterneTrafficPolicy: Cluster
  havne:
  - navn: https
    havn: 443
    protokol: TCP
    targetPort: http
  - navn: http
    havn: 80
    protokol: TCP
    targetPort: http
  vælgeren:
    app: ingress-nginx
  type: LoadBalancer

Bemærk, at jeg har angivet et ssl-certifikat (fremhævet ovenfor). Dette er certifikatet for afslutning af SSL og skal høre til det domæne, du ejer. Vi vil se, hvordan du dirigerer trafik fra dette domæne til specifikke tjenester senere i denne artikel. Lad os betragte dette domæne for dette eksempel som:

kube-example.com

AWS certifikatadministrator kan bruges til at oprette et certifikat til dette domæne. Når det er oprettet, skal du notere arn for certifikatet og bruge det her til at afslutte SSL i ELB. Lad os nu implementere denne Loadbalancer-tjeneste

$ kort -k -f nginx-service.short.yaml> nginx-service.yaml
$ kubectl oprette -f nginx-service.yaml

Klyngen vil have en fuldt funktionsdygtig nginx belastningsbalancer foran med ELB.

Opsætning af rute 53 og omdirigering af trafik

Bemærk, at denne del ikke er påkrævet til enkel test. Du kan bruge de ELB-offentlige webadresser til at teste rutefunktionerne.

Nu, hvor ELB er i gang, kan du konfigurere et domæne / underdomæne i rute53 til at pege på denne belastningsbalancer. Instruktioner til dette kan findes her.

Når installationen er konfigureret, kan du oprette tjenester og omdirigere trafik til specifikke stier ved hjælp af indtrængningsressourcer.

Lad os forstå dette med et eksempel. Som en hurtig sammenfattning er det domæne, vi arbejder med, kube-eksempel.com

Overvej eksemplet med at udsætte Grafana-instrumentbrættet for din Kubenretes-klynge ved stien / skærmen. Dette kan opnås ved at oprette en indgangsressource:

indtrængning:
  anmærkninger:
    ingress.kubernetes.io/rewrite-target: /
    nginx.ingress.kubernetes.io/cors-allow-credentials: "sandt"
    nginx.ingress.kubernetes.io/cors-allow-headers: Autorisation, oprindelse, accept
    nginx.ingress.kubernetes.io/cors-allow-methods: GET, OPTIONS
    nginx.ingress.kubernetes.io/cors-allow-origin: kube-example.com/monitor
    nginx.ingress.kubernetes.io/enable-cors: "sandt"
  navn: kubernetes-grafana-ingress
  navneområde: kube-system
  regler:
  - vært: kube-eksempel.com
    stier:
    - sti: / monitor
      havn: 80
      service: overvågning-grafana
  tls:
  - værter:
    - kube-eksempel.com
  version: extensions / v1beta1

Bemærk den markerede annotation. Denne annotation fortæller indtrængen at omskrive stien, der sendes til grafana. Den indkommende anmodning omdirigeres som vist nedenfor.

Hvad bruger anmoder om: kube-example.com/monitor
Hvad Grafana får: kube-eksempel.com/

Grafana kræver også CORS-støtte. Konfigurationen til at tilføje dette vises i Ingress-kommentarerne ovenfor.

Konklusion

Denne opsætning af nginx-indtrængning kan bruges til at fronte dine Kubernetes-tjenester og udsætte dem for verden.

Der er meget mere konfiguration til nginx, og det kræver, at mange blogindlæg forklarer. Hvis du er interesseret i alle de interessante måder at konfigurere nginx, skal du kommentere nedenfor. Jeg opretter en blogserie om den.

Hold øje med flere dyberdykker fra Kubernetes!