Ahoj, Habr!
Na konci leta chceme pripomenúť, že naďalej pracujeme na téme a rozhodli sme sa publikovať článok zo Stackoverflow, ktorý demonštruje aktuálny stav tohto projektu na začiatku júna.
Príjemné čítanie!
V čase písania tohto článku má Kubernetes približne , a za posledné dva roky jeho popularita tak vzrástla, že stabilne patrí medzi platformy. Tento rok je Kubernetes na treťom mieste. Pripomíname: Kubernetes je platforma určená na spúšťanie a orchestráciu kontajnerových pracovných zaťažení.
Kontajnery sa zrodili ako špeciálna konštrukcia na izoláciu procesov v Linuxe; od roku 2007 obsahujú , a od roku 2002 – menné priestory. Kontajnery sa ešte lepšie utvorili do roku 2008, keď sa sprístupnila , a v Google vyvinuli svoj vnútrofiremný mechanizmus nazvaný , kde „celá práca prebieha v kontajneroch“. Presuňme sa do roku 2013, keď bol vydaný prvý Docker, a kontajnery sa definitívne dostali do kategórie populárnych hromadných riešení. V tej dobe bol hlavným nástrojom na orchestráciu kontajnerov , hoci nemal veľkú popularitu. Prvý release Kubernetes sa uskutočnil v roku 2015, po čom sa tento nástroj de facto stal štandardom v oblasti orchestrácie kontajnerov.
Aby sme sa pokúsili pochopiť, prečo je Kubernetes tak populárny, poďme si odpovedať na niekoľko otázok. Kedy sa naposledy vývojárom podarilo dosiahnuť dohodu o tom, ako nasadzovať aplikácie do produkcie? Koľko poznáte vývojárov, ktorí používajú nástroje v takej podobe, ako sú poskytované „z krabice“? Koľko dnes existuje cloudových administrátorov, ktorí nerozumejú, ako aplikácie fungujú? Odpovede na tieto otázky si prejdeme v tomto článku.
Infrastruktúra ako YAML
Vo svete, ktorý prešiel od Puppet a Chef k Kubernetes, jednou z najväčších zmien bolo prechod od „infrastruktúry ako kód“ k „infrastruktúre ako dáta“ — konkrétne, ako YAML. Všetky zdroje v Kubernetes, medzi ktoré patrí pod, konfigurácie, nasadené inštancie, objemy a pod., sa dajú ľahko opísať v súbore YAML. Napríklad:
apiVersion: v1
kind: Pod
metadata:
name: site
labels:
app: web
spec:
containers:
- name: front-end
image: nginx
ports:
- containerPort: 80S takýmto prístupom majú odborníci na DevOps alebo SRE možnosť plne zohľadniť svoje pracovné zaťaženia, bez potreby písania programového kódu v jazykoch ako Python alebo Javascript.
Ďalšie výhody organizácie infraštruktúry ako dát sú nasledujúce:
- GitOps alebo verzionovanie Git Operations Version. Tento prístup umožňuje uchovávať všetky YAML súbory Kubernetes v git repozitároch, vďaka čomu môžete presne sledovať, kedy bola vykonaná zmena, kto ju vykonal a čo presne sa zmenilo. Týmto sa zvyšuje transparentnosť operácií v celej organizácii a zefektívňuje sa práca, čím sa eliminuje nejednoznačnosť, najmä pokiaľ ide o to, kde by mali zamestnanci hľadať požadované zdroje. Zároveň sa zjednodušuje automatizované spravovanie zmien v zdrojoch Kubernetes prostredníctvom jednoduchého zlúčenia pull-requestu.
- Škálovateľnosť. Keď sú zdroje definované pomocou YAML, operátorom klastra je mimoriadne jednoduché zmeniť jedno alebo dve čísla v zdroji Kubernetes, čím sa menia pravidlá škálovania. V Kubernetes je implementovaný mechanizmus pre horizontálne automatické škálovanie podov, ktorý umožňuje pohodlne definovať minimálny a maximálny počet podov potrebných v konkrétnej nasadenej konfigurácii, aby sa zvládla nízka a vysoká úroveň prevádzky. Napríklad, ak ste nasadili konfiguráciu, ktorá vyžaduje dodatočný výkon kvôli náhlemu nárastu prevádzky, môžete zmeniť hodnotu maxReplicas z 10 na 20:
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- Bezpečnosť a správa. YAML je ideálny na posúdenie toho, ako sú jednotlivé prvky nasadené v Kubernetes. Napríklad, závažný problém, ktorý sa týka zabezpečenia, sa týka toho, či sa vaše pracovné zaťaženia spúšťajú pod používateľom, ktorý nemá administrátorské práva. V tomto prípade nám môžu pomôcť nástroje ako , validator YAML/JSON, plus , validator politík, ktorý umožňuje overiť, či kontext Pracovné záťaže vašich systémov neumožňujú kontajneru fungovať s administrátorskými právami. Ak je to potrebné, používatelia môžu aplikovať jednoduchú politiku , takto:
package main
deny[msg] {
input.kind = "Deployment"
not input.spec.template.spec.securityContext.runAsNonRoot = true
msg = "Kontajnery nesmú bežať ako root"
}- Možnosti integrácie s poskytovateľom cloudu. Jedným z najvýraznejších trendov v moderne technológiách je prevádzkovanie pracovných záťaží na zdrojoch verejných poskytovateľov cloudu. Pomocou komponentu Kubernetes umožňuje akémukoľvek klastru integrovať sa s tým poskytovateľom cloudu, na ktorom beží. Napríklad, ak používateľ spustí aplikáciu v Kubernetes na AWS a chce sprístupniť túto aplikáciu cez službu, poskytovateľ cloudu automaticky pomáha vytvoriť službu
LoadBalancer, ktorá automaticky poskytne vyrovnávač zaťaženia , aby presmeroval prenos do podov aplikácií.
Rozšíriteľnosť
Kubernetes sa veľmi dobre škáluje, čo sa páči vývojárom. Existuje súbor dostupných zdrojov, ako sú pady, nasadenia, StatefulSets, tajomstvá, ConfigMaps, atď. Je pravda, že používatelia a vývojári môžu pridávať aj ďalšie zdroje vo forme .
Napríklad, ak chceme definovať zdroj CronTab, mohli by sme urobiť niečo podobné:
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
Neskôr môžeme vytvoriť zdroj CronTab približne takto:
apiVersion: "my.org/v1"
kind: CronTab
metadata:
name: my-cron-object
spec:
cronSpec: "* * * * */5"
image: my-cron-image
replicas: 5
Ďalšou možnosťou rozšíriteľnosti v Kubernetes je, že vývojár môže písať vlastné operátory. je osobitný proces v klastri Kubernetes, ktorý funguje podľa vzoru „“. Pomocou operátora môže používateľ automatizovať správu CRD (vlastných definícií zdrojov), výmenou informácií s Kubernetes API.
V komunite existuje niekoľko nástrojov, pomocou ktorých môžu vývojári jednoducho vytvárať vlastné operátory. Medzi nimi je a jeho . Tento SDK poskytuje základ, od ktorého sa môže vývojár veľmi rýchlo pustiť do vytvárania operátora. Povedzme, že môžete začať z príkazového riadka asi takto:
$ operator-sdk new my-operator --repo github.com/myuser/my-operatorTakto sa vytvára celý stereotypný kód pre vášho operátora, vrátane YAML súborov a kódu v Golangu:
.
|____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.goPotom môžete pridať požadované API a kontrolér, takto:
$ operator-sdk add api --api-version=myapp.com/v1alpha1 --kind=MyAppService
$ operator-sdk add controller --api-version=myapp.com/v1alpha1 --kind=MyAppServiceNásledne môžete konečne zostaviť operátora a poslať ho do vášho kontajnerového registru:
$ operator-sdk build your.container.registry/youruser/myapp-operator Ak vývojárovi treba ešte väčšiu kontrolu, môže zmeniť stereotypný kód v súboroch Go. Napríklad, ak chcete prispôsobiť špecifiku kontroléra, môžete vykonať zmeny v súbore controller.go.
Iný projekt, , umožňuje vytvárať operátory len pomocou deklaratívnych YAML súborov. Napríklad, operátor pre Apache Kafka sa bude definovať asi takto: . S jeho pomocou môžete len pár príkazmi nainštalovať klaster Kafka nad Kubernetes:
$ kubectl kudo install zookeeper
$ kubectl kudo install kafkaA potom ho nakonfigurovať pomocou ešte jedného príkazu:
$ 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
Inovácie
V priebehu posledných niekoľkých rokov sa veľké vydania Kubernetes objavujú každé niekoľko mesiacov – to znamená, tri až štyri veľké vydania za rok. Počet nových funkcií zavádzaných v každom z nich sa nezmenšuje. Ba čo viac, nepozorujú sa žiadne znaky spomalenia ani v našich ťažkých časoch – pozrite sa, aká je teraz .
Nové možnosti umožňujú flexibilnejšie klastrovanie operácií pri rôznych pracovných záťažiach. Okrem toho programátorom vyhovuje väčšia kontrola pri nasadzovaní aplikácií priamo do produkcie.
Komunita
Ďalším vážnym aspektom popularity Kubernetes je sila jeho komunity. V roku 2015, po dosiahnutí verzie 1.0, bol Kubernetes sponzorovaný .
Existujú aj rôzne komunity (špeciálne záujmové skupiny), zamerané na rozpracovanie rôznych oblastí Kubernetes, keďže tento projekt sa vyvíja. Tieto skupiny neustále pridávajú nové funkcie, vďaka čomu je práca s Kubernetes čoraz pohodlnejšia.
Fond Cloud Native Foundation tiež organizuje CloudNativeCon/KubeCon, ktorá je, k času písania tohto textu, najväčšou open-source konferenciou na svete. Zvyčajne sa koná trikrát ročne a zhromažďuje tisíce odborníkov, ktorí sa snažia vylepšiť Kubernetes a jeho ekosystém, ako aj osvojiť si nové funkcie, ktoré sa objavujú každé tri mesiace.
Navyše, v Cloud Native Foundation existuje , ktorý spoločne so SIGs zvažuje nové a existujúce projekty zamerané na cloudovú ekosystému. Väčšina z týchto projektov pomáha zlepšiť silné stránky Kubernetes.
Nakoniec verím, že Kubernetes by nemal taký úspech bez vedomého úsilia celej komunity, kde sa ľudia navzájom podporujú, ale zároveň s radosťou prijímajú nováčikov.
Budúcnosť
Jednou z hlavných výziev, ktorým budú musieť vývojári čeliť v budúcnosti, je schopnosť zamerať sa na detaily samotného kódu, a nie na infraštruktúru, v ktorej funguje. Týmto trendom zodpovedá , ktorá je dnes jednou z vedúcich. Už existujú pokročilé frameworky, ako napríklad a , ktoré využívajú Kubernetes na abstrahovanie infraštruktúry od vývojára.
V tomto článku sme iba v stručnosti prešli súčasným stavom Kubernetes – v skutočnosti je to len špička ľadovca. Používateľom Kubernetes je k dispozícii mnoho ďalších zdrojov, príležitostí a konfigurácií.
Zdroj: habr.com
