Hva er Kubernetes?

Hva er Kubernetes? Og hva er arkitekturen?

Containerisering har kuttet ledningen mellom programvareutviklere og produksjonsmiljø. Ikke i den forstand at du ikke trenger et produksjonssystem i det hele tatt, men du trenger ikke å bekymre deg for produksjonsmiljøets spesifisitet.

Appene er nå samlet med avhengighetene de trenger, i en lett beholder i stedet for en VM. Det er flott! Det gir imidlertid ikke immunitet mot systemfeil, nettverkssvikt eller diskfeil. For eksempel, hvis datasenteret, der serverne dine kjører, er under vedlikehold av applikasjonen din vil gå offline.

Kubernetes kommer inn i bildet for å løse disse problemene. Det tar ideen om containere og utvider den til å fungere på tvers av flere beregningsnoder (som kan være skyhostede virtuelle maskiner eller bare metallservere). Tanken er å ha et distribuert system for containeriserte applikasjoner å kjøre på.

Hvorfor Kubernetes?

Nå, hvorfor må du ha et distribuert miljø i utgangspunktet?

Av flere grunner er først og fremst høy tilgjengelighet. Du vil at e-handelsnettstedet ditt skal være online 24/7, ellers mister du virksomheten, bruker Kubernetes til det. For det andre er skalerbarhet, der du vil skalere 'ut'. Skalering her innebærer å legge til mer beregne noder for å gi den voksende applikasjonen mer benrom for å betjene.

Design og arkitektur

Som ethvert distribuert system har en Kubernetes -klynge en mesternode og deretter en hel masse arbeidernoder, og det er her applikasjonene dine faktisk vil kjøre. Mesteren er ansvarlig for å planlegge oppgaver, administrere arbeidsmengder og sikkert legge til nye noder til klyngen.

Nå kan selvfølgelig selve mesternoden mislykkes og ta hele klyngen med den, så Kubernetes lar deg faktisk ha flere mesternoder for redundansens skyld.

En fugleperspektiv av en typisk distribusjon av Kubernetes

Kubernetes Master

Kubernetes -mesteren er det DevOps -teamet samhandler med og bruker for å tilby nye noder, distribuere nye apper og ressursovervåking og styring. Masternodens mest grunnleggende oppgave er å rute Arbeidsmengden effektivt blant alle arbeiderknuter for å maksimere ressursutnyttelsen, forbedre ytelsen og følg forskjellige retningslinjer valgt av DevOps -teamet for deres spesielle arbeidsmengde.

En annen viktig komponent er etcd som er en demon som holder rede på arbeidernoder og holder en database som lagrer hele klyngens tilstand. Det er en datalager for nøkkelverdier, som også kan kjøre på et distribuert miljø over flere masternoder. Innholdet i ETCD gir alle relevante data om hele klyngen. En arbeidernode ville se på innholdet i etcd fra tid til annen for å avgjøre hvordan den skal oppføre seg.

Kontroller er enheten som vil ta instruksjoner fra API -serveren (som vi vil dekke senere) og utføre nødvendige handlinger som oppretting, sletting og oppdatering av applikasjoner og pakker.

De API -server utsetter Kubernetes API, som bruker JSON -nyttelast over HTTPS, for å kommunisere med brukergrensesnittet som utviklerteamene eller DevOps -personellet til slutt vil ende opp med å samhandle med. Både Web UI og CLI forbruker dette API for å samhandle med Kubernetes -klyngen.

API -serveren er også ansvarlig for kommunikasjonen mellom arbeidernodene og forskjellige masternodekomponenter som osv.

Masternoden blir aldri utsatt for sluttbrukeren, da den vil risikere sikkerheten til hele klyngen.

Kubernetes noder

En maskin (fysisk eller virtuell) vil trenge noen viktige komponenter som en gang er installert og konfigurert ordentlig kan gjøre den serveren til et medlem av Kubernetes -klyngen.

Det første du trenger er en container kjøretid, som Docker, installert og kjører på den. Det vil være ansvarlig for å snurre opp og administrere containere, tydeligvis.

Sammen med Docker -runtime trenger vi også Kubelet Daemon. Den kommuniserer med hovedknutepunktene, via API -serveren og spør ETCD, og ​​gir tilbake helse- og bruksinformasjon om belgene som kjører på den noden.

Imidlertid er containere ganske begrenset av seg selv, så Kubernetes har en høyere abstraksjon bygget på toppen av en samling containere, kjent som Pods.

Hvorfor komme med pods?

Docker har en policy for å kjøre en applikasjon per container. Ofte beskrevet som “En prosess per container” Politikk. Dette betyr at hvis du trenger et WordPress -nettsted, blir du oppfordret til å ha to containere en for at databasen skal kjøres på og en annen for at webserveren skal kjøres på. Å pakke slike relaterte komponenter i en applikasjon i en pod sikrer at når du skaleres ut, sameksisterer de to interavhengige containerne på samme node, og snakker dermed med hverandre raskt og enkelt.

Pods er den grunnleggende distribusjonsenheten i Kubernetes. Når du skalerer ut, legger du til flere belg i klyngen. Hver pod får sin egen unike IP -adresse i det interne nettverket av klyngen.

Tilbake til Kubernetes -noden

Nå kan en node kjøre flere belg og det kan være mange slike noder. Dette er helt greit til du tenker på å prøve å kommunisere med den ytre verden. Hvis du har en enkel nettbasert tjeneste, hvordan vil du peke domenenavnet ditt på denne samlingen av pods med mange IP-adresser?

Du kan ikke, og du trenger ikke å gjøre det! Kube-proxy er den siste delen av puslespillet som gjør det mulig for operatører å eksponere visse belg for internett. For eksempel kan front-enden gjøres offentlig tilgjengelig, og kube-proxy vil distribuere trafikken mellom alle de forskjellige belgene som er ansvarlige for å være vert for frontend. Databasen din trenger imidlertid ikke bli offentliggjort og ku-proxy vil bare tillate intern kommunikasjon for slike back-end-relaterte arbeidsmengder.

Trenger du alt dette?

Hvis du nettopp begynner som hobbyist eller student, vil det være ineffektivt å bruke Kubernetes for en enkel applikasjon. Hele Rigmarole ville konsumere mer ressurser enn din faktiske applikasjon og ville tilføre mer forvirring for et enkelt individ.

Imidlertid, hvis du skal jobbe med et stort team og distribuere appene dine for alvorlig kommersiell bruk, er Kubernetes verdt tilleggsoverhead. Du kan stoppe ting fra å bli kaotisk. Gi rom for vedlikehold uten driftsstans. Oppsett Nifty A/B Testforhold og skaler gradvis uten å bruke for mye på infrastrukturen på forhånd.