Distribuere apper på Kubernetes-klynger

I en tidligere artikkel distribuerte vi en Kubernetes-klynge med en master- og en arbeiderknute. Kubernetes-klynger handler hovedsakelig om to ting; Noder og bøtter. Pods er de containeriserte applikasjonene du vil distribuere på klyngen, og noder er de individuelle beregningsserverne som er ansvarlige for å administrere klyngen eller kjøre appene. For å gjøre saken enklere, begynner vi med et statsløst program og introduserer forskjellige konsepter som etiketter og velgere som brukes til å binde pods med hverandre.

Det er andre viktige konsepter som replikasett, tjenester og distribusjoner som vi skal lære i denne artikkelen.

Tradisjonell apputplassering

Hvis du ser på den tradisjonelle tilnærmingen for å distribuere en webapp, er skalerbarhet noe du må vurdere før du starter. Hvis du trenger en database som er skilt fra webgrensesnittet, er det bedre å gjøre det akkurat nå enn å gjøre det senere. Har du tenkt å kjøre mer enn én nettapp? Konfigurer en Reverse Proxy-server bedre på forhånd.

Med Kubernetes har tilnærmingen skiftet. Implementering kan gjøres med tanke på nåværende behov og kan senere skaleres når virksomheten din vokser. Containerization lar deg adskille viktige komponenter i webtjenestene dine, selv når de kjører på en enkelt node. Senere når du skalerer horisontalt (som betyr at du legger til flere servere i miljøet ditt), trenger du ganske enkelt å spinne opp flere containere, og Kubernetes vil planlegge det på passende noder for deg. Omvendt fullmektig? Kubernetes-tjenester ville komme inn for å løse det problemet.

Pods

Som et første trinn, la oss spinne opp en pod. For å gjøre det trenger vi en YAML-fil som definerer forskjellige attributter for pod.

apiVersion: v1
snill: Pod
metadata:
navn: nginx
spesifikasjon:
containere:
- navn: nginx
bilde: nginx: 1.7.9
porter:
- containerPort: 80

Legg til innholdet ovenfor i a pod.yaml filen og lagre den. Ser du på teksten ovenfor, kan du se at snill av ressursen vi skaper er en pod. Vi kalte den nginx, og bildet er nginx: 1.7.9 som som standard betyr at Kubernetes vil hente riktig nginx-bilde fra Docker-hubens offentlig tilgjengelige bilder.

I store organisasjoner er K8 ofte konfigurert til å peke på et privat register hvor det kan trekke de aktuelle containerbildene.

Nå for å starte podkjøringen:

$ kubectl create -f pod.yaml

Du kan ikke få tilgang til pod fra utenfor klyngen. Den er ikke utsatt ennå, og den eksisterer bare som en ensom pod. For å sikre at den faktisk blir distribuert, kjør:

$ kubectl få pods

Å kvitte seg med pod som heter nginx, kjør kommandoen:

$ kubectl slett pod nginx

Implementeringer

Å få bare en fungerende pod er ikke poenget med Kubernetes. Det vi helst vil, er flere kopier av en pod, ofte planlagt på forskjellige noder, så hvis en eller flere noder mislykkes, vil resten av podene fortsatt være der for å ta opp den ekstra arbeidsmengden.

Videre, fra et utviklingssynspunkt, trenger vi å ha en eller annen måte å rulle ut pods med en nyere versjon av programvaren og gjøre de eldre pods sovende. I tilfelle det er et problem med den nyere podden vi kan rulle tilbake ved å bringe tilbake eldre pods og slette den mislykkede versjonen. Implementeringer tillater oss å gjøre det.

Følgende er en veldig vanlig måte å definere en distribusjon på:

apiVersion: apps / v1beta1
snill: Implementering
metadata:
navn: nginx-distribusjon
spesifikasjon:
kopier: 2
mal:
metadata:
etiketter:
app: nginx
spesifikasjon:
containere:
- navn: nginx
bilde: nginx: 1.7.9
porter:
- containerPort: 80

Du vil blant annet merke et nøkkelverdipar som er:

etiketter:
app: nginx

Etiketter er viktige for klyngeadministrasjon, ettersom de hjelper med å holde orden på et stort antall pods med samme plikt. Pods opprettes på kommandoen til masternoden, og de kommuniserer med masternoden. Imidlertid trenger vi fortsatt en effektiv måte for dem å snakke med hverandre og jobbe sammen som et team.

Tjenester

Hver pod har sin egen interne IP-adresse, og et kommunikasjonslag som Flannel hjelper pods til å kommunisere med hverandre. Denne IP-adressen endres imidlertid ganske mye, og tross alt er poenget med å ha mange pods å la dem være disponible. Pod blir drept og gjenopplivet ofte.

Spørsmålet som nå oppstår er dette - Hvordan vil frontpodene snakke med backpodene når ting er så dynamiske i klyngen?

Tjenester kommer inn i bildet for å løse denne kompleksiteten. En tjeneste er enda en pod som fungerer som en lastbalanser mellom en delmengde av pods og resten av Kubernetes-klyngen. Den binder seg til alle pods som har en bestemt etikett knyttet til seg, for eksempel database, og deretter eksponerer den for resten av klyngen.

For eksempel hvis vi har en databasetjeneste med 10 databasepods, kan noen av databasepodene komme opp eller bli drept, men tjenesten vil sikre at resten av klyngen får "tjenesten" som er en database. Tjenester kan også brukes til å eksponere front-enden for resten av Internett.

Her er en typisk definisjon av en tjeneste.

apiVersion: v1
snill: Service
metadata:
navn: wordpress-mysql
etiketter:
app: wordpress
spesifikasjon:
porter:
- port: 3306
velger:
app: wordpress
tier: mysql
clusterIP: Ingen

Podene merket WordPress med det angitte mysql-nivået er de som blir plukket opp av denne tjenesten og utsatt for webserverpodene for et typisk WordPress-oppsett gjort på Kubernetes.

Ord av forsiktighet

Når du distribuerer en gigantisk app med flere nivåer rettet mot en stor forbrukerbase, blir det veldig fristende å skrive mange tjenester (eller mikrotjenester, som de er populært kjent). Selv om dette er en elegant løsning for de fleste brukssaker, kan ting raskt gå ut av hånden.

Tjenester, som pods, er utsatt for feil. Den eneste forskjellen er at når en tjeneste svikter, blir mange pods, som er perfekt funksjonelle, ubrukelige. Derfor, hvis du har en stor sammenkobling av tjenester (både interne og eksterne) og noe mislykkes, vil det være umulig å finne ut av feilpunktet.

Som en tommelfingerregel, hvis du har en grov visualisering av klyngen, eller hvis du kan bruke programvare som cockpit for å se på klyngen og gi mening, er oppsettet ditt greit. Kubernetes, på slutten av dagen, er designet for å redusere kompleksiteten, ikke forbedre den.