Helló, Habr!
A nyár végén szeretnénk emlékeztetni, hogy továbbra is dolgozunk a témán, és úgy döntöttünk, hogy közzéteszünk egy cikket a Stackoverflow-ról, amely bemutatja a projekt állapotát június elején.
Jó olvasást!
A cikk írásának időpontjában a Kubernetes életkor körülbelül , és az elmúlt két évben olyan mértékben nőtt a népszerűsége, hogy folyamatosan a platformok közé tartozik. Idén a Kubernetes a harmadik helyet foglalja el. Emlékeztetőül: a Kubernetes egy platform, amelyet konténer alapú munkaterhelések futtatására és vezérlésére terveztek.
A konténerek a Linux rendszerekben a folyamatok elszigetelésére szolgáló különleges konstrukcióként születtek; a konténerek 2007 óta , míg 2002 óta névterek révén alakultak ki. A konténerek 2008-ra még jobban formálódtak, amikor elérhetővé vált , és a Google egy belső mechanizmust fejlesztett ki, amelyet , ahol "minden munka konténerekben folyik". Tehát ugrás 2013-ra, amikor megjelent a Docker első verziója, és a konténerek végleg a népszerű tömegmegoldások közé kerültek. Ekkor a konténerek vezérlésére a fő eszköz a volt, bár nem aratott elsöprő népszerűséget. A Kubernetes első verziója 2015-ben jelent meg, és ez az eszköz de facto standard lett a konténerek irányításában.
Hogy megpróbáljuk megérteni, miért olyan népszerű a Kubernetes, válaszoljunk néhány kérdésre. Mikor sikerült a fejlesztőknek legutóbb megegyezniük abban, hogy hogyan telepítsenek alkalmazásokat a termelésben? Hány fejlesztőt ismer, aki a "dobozból kivett" eszközöket használja? Hány felhőadminisztrátor van ma, aki nem érti, hogyan működnek az alkalmazások? A kérdésekre adott válaszokat ebben a cikkben fogjuk megvizsgálni.
Infrastruktúra mint YAML
A világban, amely a Puppet és Chef megoldásaitól jutott el a Kuberneteshez, az egyik legnagyobb változás a "kód mint infrastruktúra" megközelítésről a "data mint infrastruktúra" megközelítésre történő áttérés volt — konkrétan, mint YAML. Az összes Kubernetes-beli erőforrás, beleértve a podokat, konfigurációkat, telepített példányokat, köteteket és másokat, 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: 80Egy ilyen bemutatóval a DevOps vagy SRE szakembereknek sokkal könnyebb kifejezni munkaterheléseiket anélkül, hogy programozási nyelveken, például Pythonban vagy Javascriptben kellene kódot írniuk.
Az adatinfrastruktúra megszervezésének egyéb előnyei a következők:
- A GitOps vagy Git Operations Verziókezelés. Ez a megközelítés lehetővé teszi, hogy minden Kubernetes YAML fájlt git tárolókban tartsunk, pontosan nyomon tudva követni, mikor történt a változtatás, ki végezte el és mi pontosan változott. Ez növeli a műveletek átláthatóságát az egész szervezeten belül, javítja a munkavégzés hatékonyságát azáltal, hogy megszünteti a bizonytalanságot, különösen abban, hogy a munkatársak hol találják meg a szükséges erőforrásokat. Ugyanakkor egyszerűbbé válik a Kubernetes erőforrások automatikus módosítása is - egyszerű pull kérés összevonással.
- Skálázhatóság. Amikor az erőforrások YAML formában vannak definiálva, a klaszter operátorainak rendkívül egyszerű dolguk van egy vagy két szám megváltoztatásával a Kubernetes erőforrásaiban, ezáltal megváltoztatva a skálázási elveit. A Kubernetes rendelkezik egy mechanizmussal a podok vízszintes automatikus méretezésére, amely lehetővé teszi a minimális és maximális podszám könnyű meghatározását, amely szükséges az adott telepítési konfigurációban, hogy kezelje az alacsony és magas forgalmi szintet. Például, ha egy olyan konfigurációt telepített, amely további kapacitásokat igényel egy forgalmi robbanás miatt, a maxReplicas értékét 10-ről 20-ra lehet módosítani:
apiVersion: autoscaling/v2beta2
kind: HorizontalPodAutoscaler
metadata:
name: myapp
namespace: default
spec:
scaleTargetRef:
apiVersion: apps/v1
kind: Deployment
name: myapp-deployment
minReplicas: 1
maxReplicas: 20
metrics:
- type: Resource
resource:
name: cpu
target:
type: Utilization
averageUtilization: 50- Biztonság és irányítás. A YAML remekül alkalmas annak felmérésére, hogy különböző dolgok hogyan vannak telepítve a Kubernetesben. Például egy komoly biztonsági probléma az, hogy a munkaterhelések nem adminisztrátori jogokkal rendelkező felhasználóból futnak-e. Ebben az esetben olyan eszközökre lehet szükség, mint , YAML/JSON érvényesítő, plusz , politikai érvényesítő, amely biztosítja, hogy a kontextus A munkaterhelései nem engedik, hogy a konténer adminisztrátori jogosultságokkal működjön. Ha ezt biztosítani kell, a felhasználók egyszerű politikát alkalmazhatnak , így:
package main
deny[msg] {
input.kind = "Deployment"
not input.spec.template.spec.securityContext.runAsNonRoot = true
msg = "A konténereknek nem szabad root-ként futniuk"
}- Integrációs lehetőségek a felhőszolgáltatóval. Az egyik legszembetűnőbb tendencia a modern technológiai világban az, hogy a munkaterheléseket nyilvános felhőszolgáltatók infrastruktúráján futtatják. A A Kubernetes lehetővé teszi, hogy bármely klaszter integrálódjon azzal a felhőszolgáltatóval, amelyiknél működik. Például, ha a felhasználó egy alkalmazást indított a Kubernetes-en az AWS-en, és el akarja érni ezt az alkalmazást egy szolgáltatáson keresztül, a felhőszolgáltató automatikusan létrehozza a szolgáltatást
LoadBalancer, amely automatikusan biztosítja a terheléselosztót , hogy a forgalmat az alkalmazások podjaiba irányítsa.
Skálázhatóság
A Kubernetes nagyon jól skálázható, és ez tetszik a fejlesztőknek. Van egy kész erőforráskészlet, mint például a podok, telepítések, StatefulSets, titkok, ConfigMap-ek, stb. Valójában a felhasználók és a fejlesztők további erőforrásokat adhatnak hozzá .
Például, ha szeretnénk egy erőforrást meghatározni CronTab, akkor valami hasonlót tehetnénk:
apiVersion: apiextensions.k8s.io/v1
kind: CustomResourceDefinition
metadata:
name: crontabs.my.org
spec:
group: my.org
versions:
- name: v1
served: true
storage: true
Schema:
openAPIV3Schema:
type: object
properties:
spec:
type: object
properties:
cronSpec:
type: string
pattern: '^(d+|*)(/d+)?(s+(d+|*)(/d+)?){4}$'
replicas:
type: integer
minimum: 1
maximum: 10
scope: Namespaced
names:
plural: crontabs
singular: crontab
kind: CronTab
shortNames:
- ct
Később egy CronTab erőforrást körülbelül így hozhatunk létre:
apiVersion: "my.org/v1"
kind: CronTab
metadata:
name: my-cron-object
spec:
cronSpec: "* * * * */5"
image: my-cron-image
replicas: 5
A Kubernetes másik skálázási lehetősége az, hogy a fejlesztő saját operátorokat írhat. – egy speciális folyamat a Kubernetes klaszterben, amely a „„ mintán működik. Az operátor segítségével a felhasználó automatizálhatja a CRD (custom resource definitions) kezelését, információt cserélve a Kubernetes API-val.
A közösségben több eszköz is rendelkezésre áll, amelyek segítségével a fejlesztők könnyen létrehozhatják saját operátoraikat. Ezek közül az egyik — stabil ágai. . Ez az SDK alapot biztosít, amelyre támaszkodva a fejlesztő nagyon gyorsan elkezdheti az operátor létrehozását. Mondjuk, el lehet kezdeni a parancssorból valahogy így:
$ operator-sdk new my-operator --repo github.com/myuser/my-operatorÍgy áll elő a tipikus kód az operátorod számára, beleértve a YAML fájlokat és a Golang kódot:
.
|____cmd
| |____manager
| | |____main.go
|____go.mod
|____deploy
| |____role.yaml
| |____role_binding.yaml
| |____service_account.yaml
| |____operator.yaml
|____tools.go
|____go.sum
|____.gitignore
|____version
| |____version.go
|____build
| |____bin
| | |____user_setup
| | |____entrypoint
| |____Dockerfile
|____pkg
| |____apis
| | |____apis.go
| |____controller
| | |____controller.goEzután hozzá lehet adni a szükséges API-t és kontrollert, így:
$ operator-sdk add api --api-version=myapp.com/v1alpha1 --kind=MyAppService
$ operator-sdk add controller --api-version=myapp.com/v1alpha1 --kind=MyAppServiceAztán végül össze lehet állítani az operátort és elküldeni a tárolási regiszteredbe:
$ operator-sdk build your.container.registry/youruser/myapp-operator Ha a fejlesztőnek még nagyobb kontrollra van szüksége, akkor módosíthatja a tipikus kódot a Go fájlokban. Például, hogy megváltoztassa a kontrollert, módosításokat végezhet a controller.go.
Másik projekt, , lehetővé teszi az operátorok létrehozását kizárólag deklaratív YAML fájlok felhasználásával. Például, az Apache Kafka operátora körülbelül így lenne definiálva: . Ezzel mindössze néhány paranccsal telepíthető egy Kafka klaszter a Kubernetes fölé:
$ kubectl kudo install zookeeper
$ kubectl kudo install kafkaAztán pedig beállítható egy újabb parancs segítségével:
$ kubectl kudo install kafka --instance=my-kafka-name
-p ZOOKEEPER_URI=zk-zookeeper-0.zk-hs:2181
-p ZOOKEEPER_PATH=/my-path -p BROKER_CPUS=3000m
-p BROKER_COUNT=5 -p BROKER_MEM=4096m
-p DISK_SIZE=40Gi -p MIN_INSYNC_REPLICAS=3
-p NUM_NETWORK_THREADS=10 -p NUM_IO_THREADS=20
Innovációk
Az elmúlt néhány évben a Kubernetes nagyszabású kiadásai hónapról hónapra jelennek meg — vagyis évente három-négy nagy kiadás. Az új funkciók száma, amelyeket mindegyikben bevezetnek, nem csökken. Sőt, még a lassulás jelei sem érzékelhetők a nehéz idők ellenére – nézd meg, milyen most .
Az új lehetőségek lehetővé teszik a műveletek rugalmasabb klaszterezését különböző munkaterhelések esetén. Emellett a fejlesztők jobban kézben tarthatják az alkalmazások telepítését közvetlenül a termelésben.
A közösség
A Kubernetes népszerűségének egyik komoly aspektusa közössége ereje. 2015-ben, az 1.0-s verzió elérésével, a Kubernetes támogatást kapott .
Továbbá, léteznek különféle közösségek (érdeklődési körök szerinti speciális csoportok), amelyek célja különböző területek kidolgozása a Kubernetes fejlődésével. Ezek a csoportok folyamatosan újabb lehetőségeket adnak hozzá, így a Kubernetes használata egyre kényelmesebbé válik.
A Cloud Native Foundation szintén megrendezi a CloudNativeCon/KubeCon-t, amely a cikk írásának idején a legnagyobb nyílt forráskódú konferencia a világon. Általában évente háromszor kerül megrendezésre, és több ezer szakember gyűlik össze, hogy fejlessze a Kubernetes-t és annak ökoszisztémáját, valamint új lehetőségeket sajátítson el, amelyek háromhavonta jelentkeznek.
Továbbá, a Cloud Native Foundation-nál létezik , amely a SIG-ekkel együtt vizsgálja az új és meglévő a felhőalapú ökoszisztéma terén. Ezeknek a projekteknek a többsége hozzájárul a Kubernetes erősségeinek javításához.
Végül hiszem, hogy a Kubernetes nem érte volna el ezt a sikert a közösség tudatos erőfeszítései nélkül, ahol az emberek támogatják egymást, ugyanakkor örömmel fogadják az új belépőket.
Jövő
Az egyik fő kihívás, amellyel a fejlesztőknek a jövőben szembesülniük kell, az, hogy képesek legyenek a kód részleteire összpontosítani, nem pedig arra az infrastruktúrára, amelyen fut. E tendenciákra válaszol a , amely ma az egyik vezető megoldás. Már léteznek fejlett keretrendszerek, például, és , amelyek a Kubernetes-t használják az infrastruktúra elvonására a fejlesztőktől.
Ebben a cikkben csupán általánosan áttekintettük a Kubernetes jelenlegi állapotát – valójában ez csak a jéghegy csúcsa. A Kubernetes felhasználói számára számos egyéb erőforrás, lehetőség és konfiguráció áll rendelkezésre.
Forrás: habr.com
