Kubernetes er en populær open source-platform til container orkestrering - det vil sige til styring af applikationer, der er bygget op af flere, stort set selvstændige driftstider kaldet containere. Containere er blevet mere og mere populære siden Docker-containeriseringsprojektet blev lanceret i 2013, men store, distribuerede containeriserede applikationer kan blive stadig sværere at koordinere. Ved at gøre containeriserede applikationer dramatisk nemmere at administrere i stor skala er Kubernetes blevet en vigtig del af containerrevolutionen.
Hvad er containerorkestrering?
Containere understøtter VM-lignende adskillelse af bekymringer, men med langt mindre omkostninger og langt større fleksibilitet. Som et resultat har containere omformet den måde, folk tænker på at udvikle, implementere og vedligeholde software. I en containeriseret arkitektur pakkes de forskellige tjenester, der udgør en applikation, i separate containere og distribueres på tværs af en klynge af fysiske eller virtuelle maskiner. Men dette giver anledning til behovet for container orkestrering—Et værktøj, der automatiserer implementering, styring, skalering, netværk og tilgængelighed af containerbaserede applikationer.
Hvad er Kubernetes?
Kubernetes er et open source-projekt, der er blevet et af de mest populære containerorkestreringsværktøjer rundt omkring. det giver dig mulighed for at implementere og administrere applikationer med flere containere i stor skala. Mens i praksis Kubernetes oftest bruges med Docker, den mest populære containeriseringsplatform, kan den også arbejde med ethvert containersystem, der overholder Open Container Initiative (OCI) standarder for containerbilledformater og driftstider. Og fordi Kubernetes er open source med relativt få begrænsninger for, hvordan det kan bruges, kan det bruges frit af alle, der ønsker at køre containere, de fleste steder hvor de vil køre dem - lokalt, i den offentlige sky eller begge dele .
Google og Kubernetes
Kubernetes begyndte livet som et projekt inden for Google. Det er en efterfølger til - men ikke en direkte efterkommer af - Google Borg, et tidligere containeradministrationsværktøj, som Google brugte internt. Google åbnede Kubernetes i 2014, dels fordi de distribuerede mikrotjenestearkitekturer, som Kubernetes letter, gør det let at køre applikationer i skyen. Google ser vedtagelsen af containere, mikrotjenester og Kubernetes som potentielt at køre kunder til sine skytjenester (selvom Kubernetes helt sikkert også fungerer med Azure og AWS). Kubernetes vedligeholdes i øjeblikket af Cloud Native Computing Foundation, som selv er under paraplyen af Linux Foundation.
Kubernetes vs. Docker og Kubernetes mod Docker Swarm
Kubernetes erstatter ikke Docker, men supplerer det. Dog Kubernetes gør erstatte nogle af de højere teknologier, der er opstået omkring Docker.
En sådan teknologi er Docker Swarm, en orkestrator bundtet med Docker. Det er stadig muligt at bruge Docker Swarm i stedet for Kubernetes, men Docker Inc. har valgt at gøre Kubernetes til en del af Docker Community og Docker Enterprise-udgaverne fremover.
Ikke at Kubernetes er en drop-in erstatning for Docker Swarm. Kubernetes er betydeligt mere kompleks end Swarm og kræver mere arbejde at implementere. Men igen er arbejdet beregnet til at give et stort udbytte på lang sigt - en mere håndterbar, modstandsdygtig applikationsinfrastruktur. Til udviklingsarbejde og mindre containerklynger præsenterer Docker Swarm et enklere valg.
Kubernetes vs. Mesos
Et andet projekt, som du måske har hørt om som en konkurrent til Kubernetes, er Mesos. Mesos er et Apache-projekt, der oprindeligt opstod fra udviklere på Twitter; det blev faktisk set som et svar på Google Borg-projektet.
Mesos tilbyder faktisk container orkestreringstjenester, men dets ambitioner går langt ud over det: Det sigter mod at være en slags cloud-operativsystem, der kan koordinere både containeriserede og ikke-containeriserede komponenter. Til det formål kan mange forskellige platforme køre inden for Mesos - inklusive Kubernetes selv.
Kubernetes arkitektur: Sådan fungerer Kubernetes
Kubernetes arkitektur gør brug af forskellige begreber og abstraktioner. Nogle af disse er variationer på eksisterende, velkendte forestillinger, men andre er specifikke for Kubernetes.
Kubernetes klynger
Det højeste niveau Kubernetes abstraktion, klynge, henviser til gruppen af maskiner, der kører Kubernetes (i sig selv en klynget applikation) og de containere, der administreres af den. En Kubernetes-klynge skal have en mestre, systemet, der kommanderer og styrer alle de andre Kubernetes-maskiner i klyngen. En meget tilgængelig Kubernetes-klynge replikerer masterfaciliteterne på tværs af flere maskiner. Men kun en mester ad gangen kører jobplanlæggeren og controller-manager.
Kubernetes noder og bælg
Hver klynge indeholder Kubernetes noder. Noder kan være fysiske maskiner eller virtuelle maskiner. Igen er ideen abstraktion: Uanset hvilken app der kører på, håndterer Kubernetes implementering på det substrat. Kubernetes gør det endda muligt at sikre, at visse containere kun kører på VM'er eller kun på bart metal.
Noder kører bælg, de mest basale Kubernetes-objekter, der kan oprettes eller styres. Hver pod repræsenterer en enkelt forekomst af en applikation eller en kørende proces i Kubernetes og består af en eller flere containere. Kubernetes starter, stopper og replikerer alle containere i en pod som en gruppe. Bælg holder brugerens opmærksomhed på applikationen snarere end på selve containerne. Detaljer om, hvordan Kubernetes skal konfigureres, fra tilstanden af bælg og op, holdes inde Osv, en distribueret nøgleværdibutik.
Pods oprettes og destrueres på noder efter behov for at overholde den ønskede tilstand, der er angivet af brugeren i poddefinitionen. Kubernetes giver en abstraktion kaldet a controller for at håndtere logistikken om, hvordan bælg spindes op, rulles ud og spindes ned. Controllere findes i et par forskellige varianter, afhængigt af hvilken type applikation der administreres. For eksempel bruges den nyligt introducerede “StatefulSet” controller til at håndtere applikationer, der har brug for vedvarende tilstand. En anden slags controller, den implementering, bruges til at skalere en app op eller ned, opdatere en app til en ny version eller rulle en app tilbage til en kendt version, hvis der er et problem.
Kubernetes tjenester
Fordi bælg lever og dør efter behov, har vi brug for en anden abstraktion for at håndtere applikationens livscyklus. En applikation formodes at være en vedvarende enhed, selv når bælgene, der kører containerne, der omfatter applikationen, ikke selv er vedholdende. Til dette formål giver Kubernetes en abstraktion kaldet a service.
En tjeneste i Kubernetes beskriver, hvordan en given gruppe bælg (eller andre Kubernetes-objekter) kan tilgås via netværket. Som Kubernetes-dokumentationen udtrykker det, kan de bælg, der udgør back-enden af en applikation, ændre sig, men front-enden behøver ikke at vide om det eller spore det. Tjenester gør dette muligt.
Et par flere stykker internt i Kubernetes afrunder billedet. Det planlægning pakker arbejdsbelastninger ud til noder, så de er afbalancerede på tværs af ressourcer, og så implementeringer opfylder kravene i applikationsdefinitionerne. Det controller manager sikrer, at systemets tilstand - applikationer, arbejdsbelastninger osv. - matcher den ønskede tilstand, der er defineret i Etcds konfigurationsindstillinger.
Det er vigtigt at huske, at ingen af de mekanismer på lavt niveau, der bruges af containere, såsom Docker selv, er erstattet af Kubernetes. Snarere giver Kubernetes et større sæt abstraktioner til brug af disse mekanismer for at holde apps kørende i skala.
Kubernetes Ingress
Kubernetes-tjenester betragtes som kørende inden for en klynge. Men du vil være i stand til at få adgang til disse tjenester fra omverdenen. Kubernetes har flere komponenter, der letter dette med varierende grad af enkelhed og robusthed, herunder NodePort og LoadBalancer, men komponenten med mest fleksibilitet er Ingress. Ingress er en API, der administrerer ekstern adgang til en klynges tjenester, typisk via HTTP.
Indtrængning kræver en smule konfiguration for at kunne konfigureres ordentligt - Matthew Palmer, der skrev en bog om Kubernetes udvikling, træder dig igennem processen på sin hjemmeside.
Kubernetes Dashboard
En Kubernetes-komponent, der hjælper dig med at holde styr på alle disse andre komponenter, er Dashboard, et webbaseret brugergrænseflade, som du kan implementere og fejlfinde apps med og administrere klyngeressourcer. Dashboard er ikke installeret som standard, men tilføjelse er ikke for meget besvær.
Relateret video: Hvad er Kubernetes?
I denne 90-sekunders video lærer du om Kubernetes, open source-systemet til automatisering af containeriserede applikationer, fra en af teknologiens opfindere, Joe Beda, grundlægger og CTO hos Heptio.
Fordele ved Kubernetes
Fordi Kubernetes introducerer nye abstraktioner og koncepter, og fordi læringskurven for Kubernetes er høj, er det kun normalt at spørge, hvad de langsigtede udbetalinger er for at bruge Kubernetes. Her er en oversigt over nogle af de specifikke måder at køre apps inde i Kubernetes bliver lettere.
Kubernetes administrerer app-sundhed, replikering, belastningsbalancering og allokering af hardware-ressourcer til dig
En af de mest grundlæggende opgaver, som Kubernetes tager dine hænder af, er det travle arbejde med at holde en applikation oppe, køre og reagere på brugernes krav. Apps, der bliver "usunde" eller ikke svarer til den definition af sundhed, du beskriver for dem, kan automatisk heles.
En anden fordel, som Kubernetes giver, er at maksimere brugen af hardwarressourcer, herunder hukommelse, lager I / O og netværksbåndbredde. Applikationer kan have bløde og hårde grænser for deres ressourceforbrug. Mange apps, der bruger minimale ressourcer, kan pakkes sammen på den samme hardware; apps, der skal strækkes ud, kan placeres på systemer, hvor de har plads til at vokse. Og igen kan udrulning af opdateringer på tværs af en klynge eller rulle tilbage, hvis opdateringer går i stykker, automatiseres.
Kubernetes letter implementeringen af forudkonfigurerede applikationer med Helm charts
Pakkeforvaltere som Debian Linux's APT og Pythons Pip sparer brugerne besværet med manuelt at installere og konfigurere et program. Dette er især praktisk, når et program har flere eksterne afhængigheder.
Helm er i det væsentlige en pakkehåndtering for Kubernetes. Mange populære softwareapplikationer skal køre i Kubernetes som en gruppe af indbyrdes afhængige containere. Helm giver en definitionsmekanisme, et "diagram", der beskriver, hvordan en applikation eller tjeneste kan køres som en gruppe containere inde i Kubernetes.
Du kan oprette dine egne Helm-diagrammer fra bunden, og det bliver du muligvis, hvis du bygger en brugerdefineret app, der skal implementeres internt. Men hvis du bruger et populært program, der har et fælles implementeringsmønster, er der en god chance for, at nogen allerede har komponeret et Helm-diagram til det og offentliggjort det i det officielle Helm charts-arkiv. Et andet sted at kigge efter officielle Helm-diagrammer er Kubeapps.com-biblioteket.
Kubernetes forenkler styring af opbevaring, hemmeligheder og andre applikationsrelaterede ressourcer
Beholdere er beregnet til at være uforanderlige; uanset hvad du lægger i dem, skal det ikke ændre sig. Men applikationer har brug for tilstand, hvilket betyder, at de har brug for en pålidelig måde at håndtere eksterne lagringsvolumener på. Det bliver desto mere kompliceret af den måde, containere lever, dør og genfødes i hele en apps levetid.
Kubernetes leverer abstraktioner, der gør det muligt for containere og apps at håndtere lagerplads på samme afkoblede måde som andre ressourcer. Mange almindelige typer opbevaring, fra Amazon EBS-volumener til almindelige gamle NFS-aktier, kan tilgås via Kubernetes-lagringsdrivere, kaldet volumener. Normalt er volumener bundet til en bestemt pod, men en volumenundertype kaldet en "Persistent Volume" kan bruges til data, der skal leve uafhængigt af enhver pod.
Containere har ofte brug for at arbejde med "hemmeligheder" - legitimationsoplysninger som API-nøgler eller serviceadgangskoder, som du ikke vil have hårdkodet i en container eller stashes åbent på en diskvolumen. Mens tredjepartsløsninger er tilgængelige for dette, som Docker-hemmeligheder og HashiCorp Vault, har Kubernetes sin egen mekanisme til naturlig håndtering af hemmeligheder, selvom det skal konfigureres med omhu. For eksempel skal Etcd konfigureres til at bruge SSL / TLS, når der sendes hemmeligheder mellem noder, snarere end i almindelig tekst.
Kubernetes-applikationer kan køre i hybrid- og multi-cloud-miljøer
En af de mangeårige drømme om cloud computing er at være i stand til at køre enhver app i enhver sky eller i en hvilken som helst blanding af skyer, der er offentlige eller private. Dette er ikke kun for at undgå leverandørlås, men også for at udnytte funktioner, der er specifikke for individuelle skyer.
Kubernetes leverer et sæt primitiver, kollektivt kendt som føderation, til at holde flere klynger synkroniseret med hinanden på tværs af flere regioner og skyer. For eksempel kan en given appinstallation holdes konsistent mellem flere klynger, og forskellige klynger kan dele serviceopdagelse, så der kan fås adgang til en back-end-ressource fra enhver klynge. Federation kan også bruges til at oprette meget tilgængelige eller fejltolerante Kubernetes-implementeringer, uanset om du spænder over flere skymiljøer.
Forbund er stadig relativt nyt for Kubernetes. Ikke alle API-ressourcer understøttes på tværs af forenede forekomster endnu, og opgraderinger har endnu ikke automatisk testinfrastruktur. Men disse mangler er bestemt til at blive afhjulpet i fremtidige versioner af Kubernetes.
