Kubernetes on suosittu avoimen lähdekoodin foorumi konttiorkesteri - toisin sanoen sovellusten hallintaan, jotka on rakennettu useista, suurimmaksi osaksi itsenäisiksi kutsutuiksi ajoiksi astiat. Kontit ovat tulleet yhä suositummiksi Docker-konttihankkeen käynnistämisen jälkeen vuonna 2013, mutta suuria, hajautettuja konttisovelluksia voi olla entistä vaikeampaa koordinoida. Tekemällä konttisovellusten dramaattisen helpomman hallinnan mittakaavassa Kubernetesistä on tullut keskeinen osa konttirevoluutiota.
Mikä on konttiorkesteri?
Säiliöt tukevat VM: n kaltaista huolenaiheiden erottamista, mutta huomattavasti vähemmän yleiskustannuksia ja paljon enemmän joustavuutta. Tämän seurauksena kontit ovat muuttaneet tapaa, jolla ihmiset ajattelevat ohjelmistojen kehittämistä, käyttöönottoa ja ylläpitoa. Säilöityyn arkkitehtuuriin sovelluksen muodostavat eri palvelut pakataan erillisiin säilöihin ja otetaan käyttöön fyysisten tai virtuaalisten koneiden joukossa. Mutta tämä herättää tarpeen konttiorkesteri—Työkalu, joka automatisoi säilöpohjaisten sovellusten käyttöönoton, hallinnan, skaalauksen, verkostoitumisen ja saatavuuden.
Mikä on Kubernetes?
Kubernetes on avoimen lähdekoodin projekti, josta on tullut yksi suosituimmista kontti-orkesterointityökaluista; sen avulla voit ottaa käyttöön ja hallita monisäiliösovelluksia laajamittaisesti. Vaikka käytännössä Kubernetesia käytetään useimmiten Dockerin, suosituimman konttialustan, kanssa, se voi toimia myös minkä tahansa konttijärjestelmän kanssa, joka täyttää Open Container Initiative (OCI) -standardit konttien kuvamuotoja ja ajonaikoja varten. Ja koska Kubernetes on avoimen lähdekoodin ja suhteellisen vähän rajoituksia sen käytölle, sitä voivat käyttää vapaasti kaikki, jotka haluavat käyttää kontteja, enimmäkseen missä tahansa he haluavat käyttää niitä - paikan päällä, julkisessa pilvessä tai molemmissa .
Google ja Kubernetes
Kubernetes aloitti elämänsä projektina Googlessa. Se on jatkoa Google Borgille, joka on aikaisempi konttienhallintatyökalu, jota Google käytti sisäisesti, vaikkakaan ei suoraan. Google avasi Kubernetesin vuonna 2014 osittain siksi, että Kubernetesin helpottamat hajautetut mikropalveluarkkitehtuurit helpottavat sovellusten ajamista pilvessä. Google näkee konttien, mikropalvelujen ja Kubernetesin käyttöönoton mahdollistavan asiakkaita pilvipalveluihinsa (vaikka Kubernetes toimii varmasti myös Azureen ja AWS: ään). Kubernetesia ylläpitää tällä hetkellä Cloud Native Computing Foundation, joka itse on Linux Foundationin sateenvarjon alla.
Kubernetes vs. Docker ja Kubernetes vs. Docker Swarm
Kubernetes ei korvaa Dockeria, mutta lisää sitä. Kuitenkin Kubernetes tekee korvata joitain korkeamman tason tekniikoita, jotka ovat tulleet esille Dockerin ympärillä.
Yksi tällainen tekniikka on Docker Swarm, Dockerin mukana toimitettu orkesterinjohtaja. Docker Swarmia on edelleen mahdollista käyttää Kubernetesin sijaan, mutta Docker Inc. on päättänyt tehdä Kubernetesistä Docker Community- ja Docker Enterprise -versiot jatkossa.
Ei, että Kubernetes on drop-in korvike Docker Swarmille. Kubernetes on huomattavasti monimutkaisempi kuin Swarm, ja sen käyttöönotto vaatii enemmän työtä. Mutta jälleen kerran työn tarkoituksena on tarjota suuri hyöty pitkällä aikavälillä - hallittavampi ja joustavampi sovellusinfrastruktuuri. Kehitystyöhön ja pienempiin konttijoukkoihin Docker Swarm tarjoaa yksinkertaisemman valinnan.
Kubernetes vs. Mesos
Toinen projekti, josta olet ehkä kuullut Kubernetesin kilpailijana, on Mesos. Mesos on Apache-projekti, joka syntyi alun perin Twitterin kehittäjiltä; sitä pidettiin itse asiassa vastauksena Google Borg -projektiin.
Mesos tarjoaa itse asiassa konttien orkestrointipalveluja, mutta sen tavoitteet menevät paljon pidemmälle: se pyrkii olemaan eräänlainen pilvi-käyttöjärjestelmä, joka voi koordinoida sekä kontti- että ei-konttikomponentteja. Tätä tarkoitusta varten Mesosissa voi toimia paljon erilaisia alustoja, mukaan lukien itse Kubernetes.
Kubernetes-arkkitehtuuri: Kuinka Kubernetes toimii
Kubernetesin arkkitehtuurissa hyödynnetään erilaisia käsitteitä ja abstrakteja. Jotkut näistä ovat muunnelmia olemassa olevista, tutuista käsityksistä, mutta toiset ovat nimenomaan Kubernetesille.
Kubernetes-klusterit
Korkeimman tason Kubernetes-abstraktio, klusteri, viittaa Kubernetesia (itse klusteroitua sovellusta) käyttävien koneiden ryhmään ja sen hallinnoimiin kontteihin. Kubernetes-klusterilla on oltava hallita, järjestelmä, joka komentaa ja ohjaa kaikkia muita klusterin Kubernetes-koneita. Erittäin saatavilla oleva Kubernetes-klusteri kopioi päällikön tilat useille koneille. Mutta vain yksi päällikkö kerrallaan ajaa työn ajoitusta ja ohjain-päällikköä.
Kubernetes-solmut ja palot
Jokainen klusteri sisältää Kubernetes solmut. Solmut voivat olla fyysisiä koneita tai virtuaalikoneita. Jälleen ajatus on abstraktio: riippumatta sovelluksesta, joka on käynnissä, Kubernetes hoitaa käyttöönoton tällä alustalla. Kubernetes mahdollistaa jopa sen varmistamisen, että tietyt kontit toimivat vain virtuaalikoneilla tai vain paljaalla metallilla.
Solmut toimivat palot, kaikkein perustavimmat Kubernetes-objektit, joita voidaan luoda tai hallita. Jokainen pod edustaa yhtä sovelluksen tai käynnissä olevan prosessin esiintymää Kubernetesissä ja koostuu yhdestä tai useammasta säilöstä. Kubernetes käynnistää, pysäyttää ja kopioi kaikki podin säiliöt ryhmänä. Palkit pitävät käyttäjän huomion sovelluksessa pikemminkin kuin itse säiliöissä. Tiedot siitä, kuinka Kubernetes on määritettävä, palkojen tilasta ylöspäin, säilytetään Jne, hajautettu avainarvosäilö.
Podit luodaan ja tuhotaan solmuissa tarpeen mukaan käyttäjän määrittelemän toivotun tilan mukauttamiseksi. Kubernetes tarjoaa abstraktin, jota kutsutaan a ohjain logistiikan käsittelemiseksi siitä, kuinka palkoja kehrätään, rullataan ja kehrätään alas. Ohjaimilla on muutama erilainen maku riippuen hallittavan sovelluksen tyypistä. Esimerkiksi äskettäin käyttöönotettua ”StatefulSet” -ohjainta käytetään pysyvää tilaa tarvitsevien sovellusten käsittelyyn. Toinen eräänlainen ohjain, käyttöönotto, käytetään sovelluksen skaalaamiseen ylös tai alas, päivittämään sovellus uuteen versioon tai palauttamaan sovellus tunnetuksi hyväksi versioksi ongelman sattuessa.
Kubernetes-palvelut
Koska palot elävät ja kuolevat tarpeen mukaan, tarvitsemme toisen abstraktion sovelluksen elinkaaren käsittelemiseksi. Sovelluksen oletetaan olevan pysyvä kokonaisuus, vaikka sovelluksen muodostavat säiliöt käyttävät palkit eivät itse olisikaan pysyviä. Tätä varten Kubernetes tarjoaa abstraktin, jota kutsutaan a palvelu.
Kubernetes-palvelussa kuvataan, kuinka tiettyä pod-ryhmää (tai muita Kubernetes-objekteja) voidaan käyttää verkon kautta. Kuten Kubernetes-dokumentaatiossa sanotaan, sovelluksen takaosan muodostavat palkit saattavat muuttua, mutta käyttöliittymän ei tarvitse olla tieto siitä tai seurata sitä. Palvelut mahdollistavat tämän.
Muutama muut Kubernetesin sisäiset kappaleet pyöristävät kuvaa. ajastin jakelee solmujen työmäärät niin, että ne ovat tasapainossa resurssien kesken ja jotta käyttöönotto täyttää sovelluksen määritelmien vaatimukset. ohjaimen johtaja varmistaa, että järjestelmän tila - sovellukset, työmäärät jne. - vastaa Etcd: n kokoonpanoasetuksissa määriteltyä haluttua tilaa.
On tärkeää pitää mielessä, että mikään konttien, kuten itse Dockerin, käyttämistä matalan tason mekanismeista ei ole vaihdettu kirjoittanut Kubernetes. Pikemminkin Kubernetes tarjoaa suuremman joukon abstraktioita näiden mekanismien käyttämiseksi sovellusten pitämiseksi käynnissä mittakaavassa.
Kubernetesin sisäänpääsy
Kubernetes-palveluiden ajatellaan toimivan sisällä klusteri. Mutta sinun kannattaa pystyä käyttämään näitä palveluja ulkomaailmasta. Kubernetesilla on useita komponentteja, jotka helpottavat tätä vaihtelevalla yksinkertaisuudella ja kestävyydellä, mukaan lukien NodePort ja LoadBalancer, mutta eniten joustavuutta omaava komponentti on Ingress. Ingress on sovellusliittymä, joka hallinnoi klusterin palveluiden ulkoista pääsyä, yleensä HTTP: n kautta.
Ingress vaatii vähän kokoonpanoa, jotta se voidaan asentaa oikein - Matthew Palmer, joka kirjoitti kirjan Kubernetesin kehityksestä, opastaa sinut läpi verkkosivustollaan.
Kubernetes-kojelauta
Yksi Kubernetes-komponentti, joka auttaa pitämään yllä näitä kaikkia muita komponentteja, on Dashboard, verkkopohjainen käyttöliittymä, jolla voit ottaa käyttöön sovelluksia ja suorittaa vianmääritystä ja hallita klusteriresursseja. Kojelautaa ei ole asennettu oletuksena, mutta sen lisääminen ei ole liikaa vaivaa.
Liittyvä video: Mikä on Kubernetes?
Tässä 90 sekunnin videossa saat tietoa Kubernetesista, avoimen lähdekoodin järjestelmästä konttisovellusten automatisointiin, yhdeltä tekniikan keksijältä, Joe Bedalta, Heption perustajalta ja CTO: lta.
Kubernetesin edut
Koska Kubernetes esittelee uusia abstraktioita ja käsitteitä ja koska Kubernetesin oppimiskäyrä on korkea, on vain normaalia kysyä, mitkä ovat Kubernetesin käytön pitkän aikavälin kannattavuudet. Tässä on luettelo joistakin erityisistä tavoista, joilla sovellusten käyttäminen Kubernetes-sovelluksessa helpottuu.
Kubernetes hallinnoi sovellusten kuntoa, replikointia, kuormituksen tasapainottamista ja laitteistoresurssien kohdentamista puolestasi
Yksi tärkeimmistä tehtävistä, joita Kubernetes ottaa käsistäsi, on kiireinen työ pitää sovellus yllä, käynnissä ja vastata käyttäjien vaatimuksiin. Sovellukset, joista tulee "epäterveellisiä" tai jotka eivät vastaa sinulle kuvaamaasi terveyden määritelmää, voidaan parantaa automaattisesti.
Toinen Kubernetesin tarjoama etu on maksimoida laitteistoresurssien käyttö, mukaan lukien muisti, tallennuksen I / O ja verkon kaistanleveys. Sovellusten resurssien käytölle voidaan asettaa pehmeät ja kovat rajat. Monet vähäisiä resursseja käyttävät sovellukset voidaan pakata yhteen samaan laitteistoon. ojennettavien sovellusten voi sijoittaa järjestelmiin, joissa niillä on tilaa kasvaa. Jälleen voidaan automatisoida päivitysten levittäminen klusterissa tai palauttaminen, jos päivitykset rikkoutuvat.
Kubernetes helpottaa esimääritettyjen sovellusten käyttöönottoa Helm-kaavioilla
Pakettien hallinta, kuten Debian Linuxin APT ja Python's Pip, säästävät käyttäjiltä ongelmia manuaalisesti asentaa ja määrittää sovelluksia. Tämä on erityisen kätevää, kun sovelluksella on useita ulkoisia riippuvuuksia.
Helm on lähinnä Kubernetesin paketinhallintaohjelma. Monien suosittujen ohjelmistosovellusten on oltava käynnissä Kubernetes-ryhmässä toisistaan riippuvaisina säilöinä. Helm tarjoaa määrittelymekanismin, "kaavion", joka kuvaa kuinka sovellusta tai palvelua voidaan käyttää ryhmänä kontteja Kubernetesin sisällä.
Voit luoda omia Helm-kaavioita tyhjästä, ja sinun on ehkä tehtävä, jos rakennat mukautettua sovellusta sisäisesti käyttöönottoa varten. Mutta jos käytät suosittua sovellusta, jolla on yhteinen käyttöönottomalli, on hyvät mahdollisuudet, että joku on jo laatinut Helm-kaavion sille ja julkaissut sen virallisessa Helm-kaavio-arkistossa. Toinen paikka etsiä virallisia Helm-kaavioita on Kubeapps.com-hakemisto.
Kubernetes yksinkertaistaa tallennustilan, salaisuuksien ja muiden sovelluksiin liittyvien resurssien hallintaa
Konttien on tarkoitus olla muuttumattomia; mitä tahansa niihin laitat, sen ei pitäisi muuttaa. Mutta sovellukset tarvitsevat tilan, eli ne tarvitsevat luotettavan tavan käsitellä ulkoisia tallennusvälineitä. Tämän tekee monimutkaisemmaksi tapa, jolla kontit elävät, kuolevat ja syntyvät uudelleen sovelluksen elinkaaren ajan.
Kubernetes tarjoaa abstraktioita, jotta kontit ja sovellukset voivat käsitellä tallennustilaa samalla tavalla kuin muut resurssit. Moniin tavallisiin tallennustyyppeihin, Amazon EBS -levyistä tavallisiin vanhoihin NFS-jakoihin, pääsee Kubernetes-tallennusajureilla, joita kutsutaan volyymeiksi. Normaalisti äänenvoimakkuudet on sidottu tiettyyn podiin, mutta "pysyväksi äänenvoimakkuudeksi" kutsuttua äänenvoimakkuuden alatyyppiä voidaan käyttää tietoihin, joiden on elettävä mistä tahansa podista riippumatta.
Säiliöiden on usein työskenneltävä "salaisuuksien" - tunnistetietojen, kuten API-avainten tai palvelusalasanojen, kanssa, joita et halua kovakoodattuina säilöihin tai piilottaa avoimesti levyn taltiolle. Vaikka tähän on saatavana kolmansien osapuolten ratkaisuja, kuten Docker-salaisuudet ja HashiCorp Vault, Kuberneteksellä on oma mekanismin salaisuuksien luonnolliseen käsittelyyn, vaikka se onkin määritettävä huolella. Esimerkiksi Etcd on määritettävä käyttämään SSL / TLS: ää lähetettäessä salaisuuksia solmujen välillä eikä pelkkänä tekstinä.
Kubernetes-sovellukset voivat toimia hybridi- ja multi-cloud-ympäristöissä
Yksi pilvipalvelujen pitkäaikaisista unelmista on pystyä käyttämään mitä tahansa sovellusta missä tahansa pilvessä tai missä tahansa julkisten tai yksityisten pilvien sekoituksessa. Tämä ei ole vain välttää toimittajan lukittumista, vaan myös hyödyntää yksittäisten pilvien ominaisuuksia.
Kubernetes tarjoaa joukon primitiivejä, jotka tunnetaan yhdessä nimellä federaatio, pitämään useita klustereita synkronoituna toistensa kanssa useilla alueilla ja pilvissä. Esimerkiksi tietyn sovelluksen käyttöönotto voidaan pitää yhdenmukaisena useiden klustereiden välillä, ja eri klusterit voivat jakaa palvelujen löytämisen siten, että taustaresursseja voidaan käyttää mistä tahansa klusterista. Yhdistämistä voidaan käyttää myös erittäin saatavilla olevien tai vikasietäisten Kubernetes-käyttöönottojen luomiseen riippumatta siitä, oletko eri pilviympäristöissä vai ei.
Federaatio on Kubernetesille vielä suhteellisen uusi. Kaikkia API-resursseja ei vielä tueta yhdistetyissä instansseissa, eikä päivityksissä ole vielä automaattista testausinfrastruktuuria. Mutta nämä puutteet on tarkoitus korjata tulevissa Kubernetes-versioissa.
