Nyár végén szeretnénk emlékeztetni, hogy továbbra is dolgozunk a témán Kubernetes és úgy döntött, hogy június elején közzétesz egy cikket a Stackoverflow-tól, amely bemutatja a projekt helyzetét.
Élvezd az olvasást!
A cikk írásakor Kubernetes életkora kb. hat éves, és az elmúlt két évben annyira megnőtt a népszerűsége, hogy folyamatosan a közé sorolják legkedveltebb platformok. A Kubernetes idén a harmadik helyen áll. Összefoglalva: A Kubernetes egy konténeres munkaterhelések futtatására és összehangolására tervezett platform.
A konténerek a Linux folyamatainak elkülönítésére szolgáló speciális tervezésként indultak; konténerek 2007 óta tartalmazzák csoportok, 2002 óta pedig – névterek. A konténereket 2008-ra még jobban tervezték, amikor elérhetővé vált évi LXC, a Google pedig kifejlesztette saját belső vállalati mechanizmusát, az úgynevezett Borg, ahol „minden munka konténerekben történik”. Innentől 2013-ig haladunk előre, amikor a Docker első kiadása megtörtént, és a konténerek végre népszerű tömegmegoldássá váltak. Abban az időben a konténerhangszerelés fő eszköze az volt Mesos, bár nem volt vadul népszerű. A Kubernetes először 2015-ben jelent meg, majd ez az eszköz de facto szabvány lett a konténerhangszerelés területén.
Hogy megértsük, miért olyan népszerű a Kubernetes, próbáljunk meg válaszolni néhány kérdésre. Mikor tudtak a fejlesztők utoljára megegyezni az alkalmazások éles üzembe helyezésének módjáról? Hány fejlesztőt ismer, aki használja az azonnali eszközöket? Hány felhőrendszergazda van ma, aki nem érti az alkalmazások működését? Ezekre a kérdésekre keressük a választ ebben a cikkben.
Az infrastruktúra YAML-ként
Abban a világban, amely a Puppet and Chef-től a Kubernetes-ig terjedt, az egyik legnagyobb változás az „infrastruktúra mint kód” helyett az „infrastruktúra mint adat” felé való elmozdulás volt – konkrétan, mint a YAML. A Kubernetes összes erőforrása, beleértve a podokat, konfigurációkat, telepített példányokat, köteteket stb., könnyen leírható egy YAML-fájlban. Például:
apiVersion: v1
kind: Pod
metadata:
name: site
labels:
app: web
spec:
containers:
- name: front-end
image: nginx
ports:
- containerPort: 80
Ez a nézet megkönnyíti a DevOps vagy SRE szakemberek számára, hogy teljes mértékben kifejezzék munkaterhelésüket anélkül, hogy olyan nyelveken kellene kódot írniuk, mint a Python vagy a Javascript.
Az infrastruktúra adatként való megszervezésének további előnyei a következők:
GitOps vagy Git Operations Version Control. Ez a megközelítés lehetővé teszi, hogy az összes Kubernetes YAML-fájlt git-tárolókban tartsa, így pontosan nyomon követheti, hogy mikor történt változtatás, ki hajtotta végre azt, és pontosan mi változott. Ez növeli a műveletek átláthatóságát a szervezet egészében, és javítja a működési hatékonyságot azáltal, hogy kiküszöböli a kétértelműséget, különösen ott, ahol az alkalmazottaknak meg kell keresniük a szükséges erőforrásokat. Ugyanakkor egyszerűbbé válik a Kubernetes-erőforrások automatikus módosítása egy lekérési kérelem egyszerű összevonásával.
Méretezhetőség. Ha az erőforrásokat YAML-ként definiálják, a fürtoperátorok rendkívül könnyen módosíthatnak egy vagy két számot egy Kubernetes-erőforrásban, ezáltal megváltoztatva a skálázás módját. A Kubernetes egy mechanizmust biztosít a pod-ok vízszintes automatikus skálázásához, amellyel kényelmesen meghatározható, hogy egy adott telepítési konfigurációban mekkora minimális és maximális számú pod szükséges az alacsony és nagy forgalom kezelésére. Például, ha olyan konfigurációt telepített, amely a forgalom hirtelen megugrása miatt további kapacitást igényel, akkor a maxReplicas 10-ről 20-ra módosítható:
Biztonság és menedzsment. A YAML kiválóan alkalmas arra, hogy kiértékelje a dolgok Kubernetesben történő telepítését. Például egy komoly biztonsági probléma az, hogy a munkaterhelései nem rendszergazdaként futnak-e. Ebben az esetben szükségünk lehet olyan eszközökre, mint pl vetélkedő, YAML/JSON érvényesítő, plusz Nyílt házirend-ügynök, egy irányelv érvényesítő, amely biztosítja, hogy a kontextus SecurityContext a munkaterhelések nem teszik lehetővé a tároló rendszergazdai jogosultságokkal való futtatását. Ha ez szükséges, a felhasználók egyszerű házirendet alkalmazhatnak imádkozom, mint ez:
package main
deny[msg] {
input.kind = "Deployment"
not input.spec.template.spec.securityContext.runAsNonRoot = true
msg = "Containers must not run as root"
}
A felhőszolgáltatóval való integráció lehetőségei. Napjaink csúcstechnológiájának egyik legfigyelemreméltóbb trendje a nyilvános felhőszolgáltatók terhelése. A komponens használata felhő-szolgáltató A Kubernetes lehetővé teszi, hogy bármely fürt integrálódjon azzal a felhőszolgáltatóval, amelyen fut. Például, ha a felhasználó egy alkalmazást futtat a Kubernetesben az AWS-en, és egy szolgáltatáson keresztül szeretné közzétenni az alkalmazást, a felhőszolgáltató segít automatikusan létrehozni a szolgáltatást. LoadBalanceramely automatikusan biztosítja a terheléselosztót Amazon rugalmas terheléselosztóa forgalom átirányítása az alkalmazásdobozokra.
Bővíthetőség
A Kubernetes nagyon bővíthető, és a fejlesztők szeretik. Van egy sor rendelkezésre álló erőforrás, például pod-ok, telepítések, StatefulSets, titkok, ConfigMapsstb. Igaz, a felhasználók és a fejlesztők más erőforrásokat is hozzáadhatnak az űrlaphoz egyéni erőforrás-definíciók.
Például, ha meg akarunk határozni egy erőforrást CronTab, akkor valami ilyesmit tehet:
A Kubernetes bővíthetőségének másik lehetősége az, hogy a fejlesztő saját nyilatkozatokat írhat. operátor egy speciális folyamat a Kubernetes klaszterben, amely a „vezérlő áramkör" Egy operátor segítségével a felhasználó automatizálhatja a CRD-k (egyéni erőforrás-definíciók) kezelését a Kubernetes API-val történő információcserével.
A közösségben számos eszköz található, amelyek megkönnyítik a fejlesztők számára saját operátorok létrehozását. Közöttük - Operátori keretrendszer és Operator SDK. Ez az SDK olyan alapot biztosít, amelyből a fejlesztő gyorsan hozzáláthat egy operátor létrehozásához. Tegyük fel, hogy elindíthatja a parancssorból, ilyesmi:
$ operator-sdk new my-operator --repo github.com/myuser/my-operator
Ez létrehozza az összes alapkódot a kezelő számára, beleértve a YAML fájlokat és a Golang kódot:
Ha a fejlesztő még nagyobb irányítást szeretne, a Go-fájlok alapkódja módosítható. Például a vezérlő sajátosságainak módosításához módosíthatja a fájlt controller.go.
Egy másik projekt MINDENHOL, lehetővé teszi utasítások létrehozását csak deklaratív YAML-fájlok használatával. Például az Apache Kafka operátora hozzávetőlegesen lenne meghatározva így. Ezzel néhány paranccsal telepíthet egy Kafka-fürtöt a Kubernetes tetejére:
Az elmúlt néhány évben néhány havonta jelentek meg a nagyobb Kubernetes-kiadások – vagyis évente három-négy nagyobb kiadás. Az egyikben bevezetett újdonságok száma nem csökken. Ráadásul még ezekben a nehéz időkben sem mutatkoznak a lassulás jelei – nézd meg, mi a helyzet most Kubernetes projekt tevékenység a Githubon.
Az új képességek lehetővé teszik a műveletek rugalmasabb fürtözését a különböző munkaterhelések között. Ezenkívül a programozók nagyobb irányítást élveznek, amikor az alkalmazásokat közvetlenül a termelésbe helyezik.
Közösség
A Kubernetes népszerűségének másik fő szempontja a közösség ereje. 2015-ben az 1.0-s verzió elérésekor a Kubernetes szponzorált Cloud Native Computing Foundation.
Különféle közösségek is léteznek SIG (Special Interest Groups) a Kubernetes különböző területein végzett munkára összpontosított a projekt fejlődése során. Ezek a csoportok folyamatosan új funkciókat adnak hozzá, kényelmesebbé és kényelmesebbé téve a Kubernetes-szel való munkát.
A Cloud Native Foundation ad otthont a CloudNativeCon/KubeConnak is, amely a cikk írásakor a legnagyobb nyílt forráskódú konferencia a világon. Általában évente háromszor rendezik meg, és több ezer szakembert hoz össze, akik szeretnék fejleszteni a Kuberneteset és ökoszisztémáját, valamint elsajátítani a háromhavonta megjelenő új funkciókat.
Ezenkívül a Cloud Native Foundation rendelkezik Műszaki Felügyelő Bizottság, amely a SIG-ekkel együtt felülvizsgálja az újakat és a meglévőket Projektek források a felhő ökoszisztémára összpontosítottak. A legtöbb ilyen projekt segít a Kubernetes erősségeinek javításában.
Végül úgy gondolom, hogy a Kubernetes nem lenne olyan sikeres, mint amilyen az egész közösség tudatos erőfeszítései nélkül, ahol az emberek összetartanak, de ugyanakkor szívesen látják az újonnan érkezőket is.
a jövőben
Az egyik fő kihívás, amellyel a fejlesztőknek meg kell küzdeniük a jövőben, az az, hogy magára a kódra kell összpontosítani, nem pedig az infrastruktúrára, amelyben fut. Ez megfelel ezeknek a trendeknek szerver nélküli építészeti paradigma, amely ma az egyik vezető. Fejlett keretrendszerek már léteznek, pl. Kíváló и OpenFaas, amelyek Kubernetes segítségével vonják el az infrastruktúrát a fejlesztőtől.
Ebben a cikkben csak a felszínét kapargattuk Kubernetes jelenlegi állapotának – valójában ez csak a jéghegy csúcsa. A Kubernetes-felhasználók számos egyéb erőforrással, képességgel és konfigurációval rendelkeznek.