Kubernetes er en populær open source-plattform for container orkestrering - det vil si for administrasjon av applikasjoner som er bygd ut av flere, stort sett selvstendige kjøretider containere. Containere har blitt stadig mer populære siden Docker-containeriseringsprosjektet ble lansert i 2013, men store, distribuerte containeriserte applikasjoner kan bli stadig vanskeligere å koordinere. Ved å gjøre containeriserte applikasjoner dramatisk enklere å administrere i stor skala, har Kubernetes blitt en viktig del av containerrevolusjonen.
Hva er containerorkestrering?
Beholdere støtter VM-lignende separasjon av bekymringer, men med langt mindre overhead og langt større fleksibilitet. Som et resultat har containere omformet måten folk tenker på å utvikle, distribuere og vedlikeholde programvare. I en containerisert arkitektur pakkes de forskjellige tjenestene som utgjør en applikasjon i separate containere og distribueres over en klynge av fysiske eller virtuelle maskiner. Men dette gir opphav til behovet for container orkestrering—En verktøy som automatiserer distribusjon, administrasjon, skalering, nettverksbygging og tilgjengelighet av containerbaserte applikasjoner.
Hva er Kubernetes?
Kubernetes er et open source-prosjekt som har blitt et av de mest populære containerorkesteringsverktøyene rundt; det lar deg distribuere og administrere applikasjoner med flere containere i stor skala. Mens i praksis Kubernetes oftest brukes med Docker, den mest populære containeriseringsplattformen, kan den også fungere med ethvert containersystem som samsvarer med Open Container Initiative (OCI) standarder for containerformater og kjøretider. Og fordi Kubernetes er åpen kildekode, med relativt få begrensninger for hvordan den kan brukes, kan den brukes fritt av alle som ønsker å kjøre containere, mest hvor som helst de vil kjøre dem - lokalt, i den offentlige skyen eller begge deler .
Google og Kubernetes
Kubernetes begynte livet som et prosjekt i Google. Det er en etterfølger til - men ikke en direkte etterkommer av - Google Borg, et tidligere verktøy for containeradministrasjon som Google brukte internt. Google åpnet Kubernetes i 2014, delvis fordi de distribuerte mikrotjenestearkitekturene som Kubernetes letter, gjør det enkelt å kjøre applikasjoner i skyen. Google ser på bruk av containere, mikrotjenester og Kubernetes som potensielt å føre kunder til sine skytjenester (selv om Kubernetes absolutt fungerer med Azure og AWS også). Kubernetes vedlikeholdes for tiden av Cloud Native Computing Foundation, som selv er under paraplyen til Linux Foundation.
Kubernetes vs Docker og Kubernetes vs Docker Swarm
Kubernetes erstatter ikke Docker, men utvider det. Imidlertid Kubernetes gjør erstatte noen av de høyere teknologiene som har dukket opp rundt Docker.
En slik teknologi er Docker Swarm, en orkestrator som følger med Docker. Det er fortsatt mulig å bruke Docker Swarm i stedet for Kubernetes, men Docker Inc. har valgt å gjøre Kubernetes til en del av Docker Community og Docker Enterprise-utgavene fremover.
Ikke at Kubernetes er en drop-in erstatning for Docker Swarm. Kubernetes er betydelig mer kompleks enn Swarm, og krever mer arbeid å distribuere. Men igjen, arbeidet er ment å gi et stort utbytte på sikt - en mer håndterbar, spenstig applikasjonsinfrastruktur. For utviklingsarbeid og mindre containerklynger presenterer Docker Swarm et enklere valg.
Kubernetes vs. Mesos
Et annet prosjekt du kanskje har hørt om som en konkurrent til Kubernetes er Mesos. Mesos er et Apache-prosjekt som opprinnelig kom fra utviklere på Twitter; det ble faktisk sett på som et svar på Google Borg-prosjektet.
Mesos tilbyr faktisk container orkestreringstjenester, men ambisjonene går langt utover det: det tar sikte på å være et slags skyoperativsystem som kan koordinere både containeriserte og ikke-containeriserte komponenter. For det formål kan mange forskjellige plattformer kjøre i Mesos - inkludert Kubernetes selv.
Kubernetes arkitektur: Hvordan Kubernetes fungerer
Kubernetes arkitektur bruker forskjellige konsepter og abstraksjoner. Noen av disse er variasjoner på eksisterende, kjente forestillinger, men andre er spesifikke for Kubernetes.
Kubernetes klynger
Kubernetes abstraksjon på høyeste nivå, klynge, refererer til gruppen maskiner som kjører Kubernetes (i seg selv et klynget program) og containerne som administreres av den. En Kubernetes-klynge må ha en herre, systemet som kommanderer og kontrollerer alle de andre Kubernetes-maskinene i klyngen. En høyt tilgjengelig Kubernetes-klynge replikerer mesterens fasiliteter på flere maskiner. Men bare en mester av gangen kjører jobbplanleggeren og kontrolleren.
Kubernetes noder og bøtter
Hver klynge inneholder Kubernetes noder. Noder kan være fysiske maskiner eller virtuelle maskiner. Igjen er ideen abstraksjon: Uansett hva appen kjører på, håndterer Kubernetes distribusjon på det substratet. Kubernetes gjør det til og med mulig å sikre at visse containere bare kjører på virtuelle maskiner eller bare på bart metall.
Noder kjører belger, de mest grunnleggende Kubernetes-objektene som kan opprettes eller administreres. Hver pod representerer en enkelt forekomst av en applikasjon eller kjører prosess i Kubernetes, og består av en eller flere containere. Kubernetes starter, stopper og replikerer alle containere i en pod som en gruppe. Pods holder brukerens oppmerksomhet på applikasjonen, i stedet for på containerne selv. Detaljer om hvordan Kubernetes må konfigureres, fra tilstanden til pods og oppover, holdes inne Etcd, en distribuert butikk med nøkkelverdi.
Pods blir opprettet og ødelagt på noder etter behov for å tilpasse seg ønsket tilstand spesifisert av brukeren i poddefinisjonen. Kubernetes gir en abstraksjon kalt a kontrolleren for å håndtere logistikken for hvordan belger blir spunnet opp, rullet ut og spunnet ned. Kontrollere kommer i noen få forskjellige smaker, avhengig av hvilken type applikasjon som administreres. For eksempel brukes den nylig introduserte "StatefulSet" -kontrolleren til å håndtere applikasjoner som trenger vedvarende tilstand. En annen type kontroller, den utplassering, brukes til å skalere en app opp eller ned, oppdatere en app til en ny versjon eller rulle tilbake en app til en kjent versjon hvis det er et problem.
Kubernetes tjenester
Fordi pods lever og dør etter behov, trenger vi en annen abstraksjon for å håndtere applikasjonens livssyklus. En applikasjon skal være en vedvarende enhet, selv når belgene som kjører beholderne som inneholder applikasjonen ikke i seg selv er vedvarende. For det formål gir Kubernetes en abstraksjon kalt a service.
En tjeneste i Kubernetes beskriver hvordan en gitt gruppe pods (eller andre Kubernetes-objekter) kan nås via nettverket. Som Kubernetes-dokumentasjonen uttrykker det, kan podene som utgjør bakenden av en applikasjon endres, men fronten trenger ikke å vite om det eller spore det. Tjenester gjør dette mulig.
Noen flere stykker interne til Kubernetes avrunder bildet. De planlegger pakker ut arbeidsmengder til noder slik at de balanseres på tvers av ressurser og slik at distribusjoner oppfyller kravene i applikasjonsdefinisjonene. De kontrolleransvarlig sørger for at tilstanden til systemet - applikasjoner, arbeidsmengder osv. - samsvarer med ønsket tilstand definert i Etcds konfigurasjonsinnstillinger.
Det er viktig å huske på at ingen av lavnivåmekanismene som brukes av containere, som for eksempel Docker, er det erstattet av Kubernetes. Snarere gir Kubernetes et større sett med abstraksjoner for å bruke disse mekanismene for å holde appene i gang i skala.
Kubernetes Ingress
Kubernetes tjenester er tenkt å kjøre innenfor en klynge. Men du vil ha tilgang til disse tjenestene fra omverdenen. Kubernetes har flere komponenter som letter dette med varierende grad av enkelhet og robusthet, inkludert NodePort og LoadBalancer, men komponenten med mest fleksibilitet er Ingress. Ingress er et API som administrerer ekstern tilgang til en klynges tjenester, vanligvis via HTTP.
Ingress krever litt konfigurasjon for å sette opp riktig - Matthew Palmer, som skrev en bok om Kubernetes-utvikling, gir deg en prosess på nettsiden sin.
Kubernetes Dashboard
En Kubernetes-komponent som hjelper deg å holde oversikt over alle disse andre komponentene, er Dashboard, et nettbasert brukergrensesnitt som du kan distribuere og feilsøke apper med og administrere klyngeressurser. Dashbordet er ikke installert som standard, men det er ikke så mye problemer å legge til det.
Relatert video: Hva er Kubernetes?
I denne 90 sekunders videoen kan du lære om Kubernetes, open source-systemet for automatisering av containeriserte applikasjoner, fra en av teknologiens oppfinnere, Joe Beda, grunnlegger og CTO i Heptio.
Fordeler med Kubernetes
Fordi Kubernetes introduserer nye abstraksjoner og konsepter, og fordi læringskurven for Kubernetes er høy, er det bare normalt å spørre hva de langsiktige utbyttene er for å bruke Kubernetes. Her er en oversikt over noen av de spesifikke måtene å kjøre apper i Kubernetes blir enklere.
Kubernetes administrerer apphelse, replikering, belastningsbalansering og tildeling av maskinvareressurser for deg
En av de mest grunnleggende oppgavene Kubernetes tar av deg hendene, er det travle arbeidet med å holde en applikasjon oppe, kjøre og lydhør overfor brukernes krav. Apper som blir “usunne” eller som ikke samsvarer med definisjonen av helse du beskriver for dem, kan bli helbredet automatisk.
En annen fordel Kubernetes gir er å maksimere bruken av maskinvareressurser, inkludert minne, lagring I / U og nettverksbåndbredde. Programmer kan ha myke og harde begrensninger for ressursbruk. Mange apper som bruker minimale ressurser kan pakkes sammen på samme maskinvare; apper som må strekkes ut, kan plasseres på systemer der de har rom for å vokse. Og igjen kan utrulling av oppdateringer over en klynge, eller rullering tilbake hvis oppdateringer går i stykker, automatiseres.
Kubernetes letter distribusjonen av forhåndskonfigurerte applikasjoner med Helm-diagrammer
Pakkeforvaltere som Debian Linuxs APT og Pythons Pip sparer brukere bryet med å installere og konfigurere et program manuelt. Dette er spesielt nyttig når et program har flere eksterne avhengigheter.
Helm er egentlig en pakkeleder for Kubernetes. Mange populære programvareapplikasjoner må kjøre i Kubernetes som en gruppe avhengige containere. Helm gir en definisjonsmekanisme, et "diagram", som beskriver hvordan et program eller en tjeneste kan kjøres som en gruppe containere inne i Kubernetes.
Du kan lage dine egne Helm-diagrammer fra bunnen av, og det må du kanskje hvis du bygger en tilpasset app som skal distribueres internt. Men hvis du bruker et populært program som har et felles distribusjonsmønster, er det stor sjanse for at noen allerede har laget et Helm-diagram for det og publisert det i det offisielle Helm charts-depotet. Et annet sted å lete etter offisielle Helm-diagrammer er Kubeapps.com-katalogen.
Kubernetes forenkler administrasjon av lagring, hemmeligheter og andre applikasjonsrelaterte ressurser
Beholdere er ment å være uforanderlige; hva du legger i dem, er ikke ment å endre seg. Men applikasjoner trenger tilstand, noe som betyr at de trenger en pålitelig måte å håndtere eksterne lagringsvolumer på. Dette blir desto mer komplisert av måten containere lever, dør og blir gjenfødt i løpet av appens levetid.
Kubernetes tilbyr abstraksjoner for å la containere og apper håndtere lagring på samme frakoblet måte som andre ressurser. Mange vanlige typer lagring, fra Amazon EBS-volumer til vanlige gamle NFS-aksjer, kan nås via Kubernetes lagringsdrivere, kalt volumer. Normalt er volumer bundet til en bestemt pod, men en volumundertype kalt et "vedvarende volum" kan brukes til data som trenger å leve på uavhengig av hvilken som helst pod.
Beholdere trenger ofte å jobbe med "hemmeligheter" - legitimasjon som API-nøkler eller tjenestepassord som du ikke vil ha hardkodet i en container eller stengt åpent på et diskvolum. Mens tredjepartsløsninger er tilgjengelige for dette, som Docker-hemmeligheter og HashiCorp Vault, har Kubernetes sin egen mekanisme for naturlig håndtering av hemmeligheter, selv om den trenger å konfigureres med omhu. For eksempel må Etcd være konfigurert til å bruke SSL / TLS når du sender hemmeligheter mellom noder, i stedet for i ren tekst.
Kubernetes-applikasjoner kan kjøres i hybrid- og multi-cloud-miljøer
En av de mangeårige drømmene om cloud computing er å kunne kjøre en hvilken som helst app i hvilken som helst sky eller i en hvilken som helst blanding av skyer som er offentlige eller private. Dette er ikke bare for å unngå låsning av leverandører, men også for å utnytte funksjoner som er spesifikke for individuelle skyer.
Kubernetes tilbyr et sett med primitiver, samlet kjent som føderasjon, for å holde flere klynger synkronisert med hverandre over flere regioner og skyer. For eksempel kan en gitt app-distribusjon holdes konsistent mellom flere klynger, og forskjellige klynger kan dele tjenesteoppdagelse slik at en back-end-ressurs kan nås fra hvilken som helst klynge. Federation kan også brukes til å lage svært tilgjengelige eller feiltolerante Kubernetes-distribusjoner, uansett om du spenner over flere skymiljøer eller ikke.
Federation er fortsatt relativt nytt for Kubernetes. Ikke alle API-ressurser støttes på tvers av forente forekomster ennå, og oppgraderinger har ennå ikke automatisk testinfrastruktur. Men disse manglene er bestemt for å bli løst i fremtidige versjoner av Kubernetes.
