Sådan implementeres Nginx på en Kubernetes-klynge

I vores sidste artikel har vi diskuteret, hvordan man opretter og kører en Kubernetes Cluster, lad os diskutere, hvordan vi kan implementere NGINX-service på vores klynge.

Jeg kører denne implementering på en virtuel maskine, der er hostet af en offentlig skyudbyder. Som det er med mange offentlige skytjenester, opretholder mange generelt en offentlig og privat IP-ordning for deres virtuelle maskiner.

Master Node - Public IP: 104.197.170.99 and Private IP: 10.128.15.195
Worker Node 1 - Public IP: 34.67.149.37 and Private IP: 10.128.15.196
Worker Node 2 - Public IP: 35.232.161.178 and Private IP: 10.128.15.197

Implementering af NGINX på en Kubernetes-klynge

Vi kører denne implementering fra masternoden.

Lad os begynde med at kontrollere klyngens status. Alle dine noder skal være i KLAR tilstand.

# kubectl get nodes

Vi opretter en implementering af NGINX ved hjælp af NGINX-billedet.

# kubectl create deployment nginx --image=nginx

Du kan nu se tilstanden for din implementering.

# kubectl get deployments

Hvis du gerne vil se flere detaljer om din implementering, kan du køre beskriv kommandoen. For eksempel er det muligt at bestemme, hvor mange replikaer af implementeringen der kører. I vores tilfælde forventer vi at se en replika på 1 kører (dvs. 1/1 replikaer).

# kubectl describe deployment nginx

Nu din Nginx-implementering er aktiv, vil du muligvis udsætte NGINX-tjenesten for en offentlig IP, der kan nås på internettet.

Kubernetes tilbyder flere muligheder, når du udsætter din service baseret på en funktion kaldet Kubernetes Service-typer, og de er:

  1. ClusterIP - Denne servicetype eksponerer generelt tjenesten på en intern IP, der kun kan nås inden i klyngen og muligvis kun inden for klyngenoder.
  2. NodePort - Dette er den mest grundlæggende mulighed for at udsætte din tjeneste for at være tilgængelig uden for din klynge på en bestemt port (kaldet NodePort) på hver node i klyngen. Vi illustrerer denne mulighed snart.
  3. LoadBalancer - Denne mulighed udnytter eksterne Load-Balancing-tjenester, der tilbydes af forskellige udbydere for at give adgang til din tjeneste. Dette er en mere pålidelig mulighed, når du tænker på høj tilgængelighed for din tjeneste, og har flere funktioner ud over standardadgang.
  4. Eksternt navn - Denne tjeneste omdirigerer trafik til tjenester uden for klyngen. Som sådan kortlægges tjenesten således til et DNS-navn, der kan være vært ud af din klynge. Det er vigtigt at bemærke, at dette ikke bruger proxying.

Standardtjenestetypen er ClusterIP.

I vores scenarie ønsker vi at bruge NodePort-servicetypen, fordi vi har både en offentlig og privat IP-adresse, og vi har ikke brug for en ekstern belastningsafbalancering i øjeblikket. Med denne servicetype tildeler Kubernetes denne service på porte i området 30000+.

# kubectl create service nodeport nginx --tcp=80:80

Kør kommandoen get svc for at se et resumé af tjenesten og de eksponerede porte.

# kubectl get svc

Nu kan du kontrollere, at Nginx-siden er tilgængelig på alle noder ved hjælp af curl-kommandoen.

# curl master-node:30386
# curl node-1:30386
# curl node-2:30386

Som du kan se, "VELKOMMEN TIL NGINX!" siden kan nås.

Som du måske har bemærket, rapporterer Kubernetes, at jeg ikke har nogen aktiv offentlig IP-registreret eller rettere ingen EXTERNAL-IP-registreret.

# kubectl get svc

Lad os kontrollere, om det virkelig er sandt, at jeg ikke har nogen EKSTERN IP knyttet til mine grænseflader ved hjælp af IP-kommando.

# ip a

Ingen offentlig IP som du kan se.

Som nævnt tidligere kører jeg i øjeblikket denne implementering på en virtuel maskine, der tilbydes af en offentlig skyudbyder. Så selvom der ikke er nogen særlig grænseflade, der er tildelt en offentlig IP, har VM-udbyderen udstedt en flygtig ekstern IP-adresse.

En kortvarig ekstern IP-adresse er en midlertidig IP-adresse, der forbliver knyttet til VM, indtil den virtuelle forekomst stoppes. Når den virtuelle forekomst genstartes, tildeles en ny ekstern IP. Grundlæggende sagt er det en enkel måde for tjenesteudbydere at udnytte ledige offentlige IP-adresser.

Udfordringen her, bortset fra det faktum, at din offentlige IP ikke er statisk, er, at den flygtige offentlige IP simpelthen er en udvidelse (eller proxy) af den private IP, og af den grund vil man kun få adgang til tjenesten på port 30386. Det betyder, at der bliver adgang til tjenesten på URL , det vil sige 104.197.170.99:30386, som hvis du tjekker din browser, skal du kunne se velkomstsiden.

Med det har vi med succes implementeret NGINX på vores 3-node Kubernetes-klynge.