Salut, Habr!
La sfârșitul verii dorim să vă reamintim că continuăm să lucrăm la acest subiect și am decis să publicăm un articol de pe Stackoverflow, care demonstrează starea actuală a acestui proiect la începutul lunii iunie.
Lectură plăcută!
La momentul redactării acestui articol, Kubernetes are aproximativ , iar în ultimii doi ani popularitatea sa a crescut atât de mult încât este constant printre platforme. Anul acesta, Kubernetes ocupă locul trei. Să ne amintim: Kubernetes este o platformă destinată rulării și orchestrării sarcinilor de lucru în containere.
Containerele au apărut ca o construcție specială pentru izolarea proceselor în Linux; începând din 2007, containerele includ , iar din 2002 — spații de nume. Containerele s-au conturat și mai bine în 2008, când a devenit disponibil , iar Google a dezvoltat un mecanism intern numit , unde „toată munca este realizată în containere”. Să ne întoarcem în 2013, când a avut loc prima lansare a Docker, iar containerele au trecut definitiv în categoria soluțiilor populare. Pe atunci, principalul instrument pentru orchestrarea containerelor era , deși nu avea o popularitate nebunească. Prima lansare a Kubernetes a avut loc în 2015, după care acest instrument a devenit de facto standard în domeniul orchestrării containerelor.
Pentru a încerca să înțelegem de ce Kubernetes este atât de popular, haideți să încercăm să răspundem la câteva întrebări. Când a fost ultima dată când dezvoltatorii au reușit să ajungă la un acord despre cum să desfășoare aplicațiile în producție? Câți dezvoltatori cunoașteți care folosesc instrumentele așa cum sunt furnizate „din cutie”? Câți administratori de cloud există astăzi care nu înțeleg cum funcționează aplicațiile? Răspunsurile la aceste întrebări le vom analiza în acest articol.
Infrastructura ca YAML
Într-o lume care a trecut de la Puppet și Chef la Kubernetes, una dintre cele mai mari schimbări a fost trecerea de la „infrastructura ca și cod” la „infrastructura ca și date” — în special, ca YAML. Toate resursele din Kubernetes, inclusiv pod-urile, configurațiile, instanțele desfășurate, volumele etc. pot fi ușor descrise într-un fișier YAML. De exemplu:
apiVersion: v1
kind: Pod
metadata:
name: site
labels:
app: web
spec:
containers:
- name: front-end
image: nginx
ports:
- containerPort: 80Cu o astfel de reprezentare, specialiștii DevOps sau SRE pot exprima mai ușor sarcinile de lucru, fără a fi nevoie să scrie cod în limbaje precum Python sau Javascript.
Alte avantaje ale organizării infrastructurii datelor sunt următoarele:
- GitOps sau controlul versiunilor Git Operations Version. Această abordare permite păstrarea tuturor fișierelor YAML Kubernetes în repozitorii git, ceea ce vă permite să urmăriți exact când a fost făcută o modificare, cine a făcut-o și ce anume s-a schimbat. Datorită acestui lucru, transparența operațiunilor în întreaga organizație este crescută, iar eficiența muncii este îmbunătățită prin eliminarea ambiguităților, în special în ceea ce privește locul unde angajații trebuie să caute resursele de care au nevoie. În același timp, devine mai ușor să faceți modificări automate în resursele Kubernetes – printr-o simplă fuziune de pull request.
- Scalabilitate. Când resursele sunt definite sub formă de YAML, operatorilor de cluster le devine extrem de ușor să schimbe unul sau două numere în resursa Kubernetes, schimbând astfel principiile de scalare ale acesteia. Kubernetes prevede un mecanism pentru scalarea automată orizontală a pod-urilor, prin care este ușor de definit care este numărul minim și maxim de pod-uri necesare într-o configurație particulară implementată, pentru a face față unor niveluri de trafic scăzute sau ridicate. De exemplu, dacă ați implementat o configurație care necesită putere suplimentară din cauza unei creșteri bruște a traficului, atunci indicatorul maxReplicas poate fi modificat de la 10 la 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- Securitate și gestionare. YAML este excelent pentru evaluarea modului în care diferitele lucruri sunt implementate în Kubernetes. De exemplu, o problemă serioasă legată de securitate se referă la faptul că sarcinile de lucru sunt lansate dintr-un cont de utilizator care nu are drepturi de administrator. În acest caz, ne-ar putea fi de folos instrumente precum , validator YAML/JSON, plus , validator de politici, care permite verificarea faptului că contextul sarcom workload-urile nu permit containerului să funcționeze cu privilegii de administrator. Dacă este necesar, utilizatorii pot aplica o politică simplă chain, like this:
package main
deny[msg] {
input.kind = "Deployment"
not input.spec.template.spec.securityContext.runAsNonRoot = true
msg = "Containerele nu trebuie să ruleze ca root"
}- Opțiuni de integrare cu furnizorul de cloud. Una dintre cele mai notabile tendințe în tehnologiile moderne este rularea sarcinilor de lucru pe resursele furnizorilor de cloud public. Prin intermediul componentului Kubernetes permite oricărui cluster să se integreze cu furnizorul de cloud pe care rulează. De exemplu, dacă un utilizator a lansat o aplicație în Kubernetes pe AWS și dorește să deschidă accesul la această aplicație printr-un serviciu, furnizorul de cloud ajută la crearea automată a serviciului
LoadBalancer, care va oferi automat un echilibror de încărcare , pentru a redirecționa traficul către podurile aplicațiilor.
Scalabilitate
Kubernetes este foarte scalabil, ceea ce le place dezvoltatorilor. Există un set de resurse existente, cum ar fi poduri, desfășurări, StatefulSets, secrete, ConfigMaps, etc. Totuși, utilizatorii și dezvoltatorii pot adăuga și alte resurse sub formă de .
De exemplu, dacă dorim să definim o resursă CronTab, am putea face ceva de genul:
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
Ulterior, putem crea o resursă CronTab aproximativ în acest fel:
apiVersion: "my.org/v1"
kind: CronTab
metadata:
name: my-cron-object
spec:
cronSpec: "* * * * *\/5"
image: my-cron-image
replicas: 5
O altă opțiune de scalabilitate în Kubernetes este că dezvoltatorul poate scrie operatori proprii. – este un proces special în clusterul Kubernetes care funcționează după modelul „”. Cu ajutorul operatorului, utilizatorul poate automatiza gestionarea CRD (definiții personalizate de resurse) schimbând informații cu API-ul Kubernetes.
În comunitate există câteva instrumente care le permit dezvoltatorilor să creeze propriile operatori. Între acestea se numără și acesta . Acest SDK oferă o bază de la care dezvoltatorul poate începe rapid să creeze un operator. De exemplu, se poate începe din linia de comandă astfel:
$ operator-sdk new my-operator --repo github.com/myuser/my-operatorAstfel se generează întreg codul standard pentru operatorul dvs., inclusiv fișierele YAML și codul în Golang:
.
|____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.goApoi, se pot adăuga API-urile și controlerul necesare, astfel:
$ operator-sdk add api --api-version=myapp.com/v1alpha1 --kind=MyAppService
$ operator-sdk add controller --api-version=myapp.com/v1alpha1 --kind=MyAppServiceDupă care, în cele din urmă, construiți operatorul și îl publicați în registrul containerului dvs.:
$ operator-sdk build your.container.registry/youruser/myapp-operator Dacă dezvoltatorul necesită un control și mai complet, poate modifica codul standard din fișierele Go. De exemplu, pentru a modifica specificul controlerului, se pot aduce modificări în fișierul controller.go.
Un alt proiect, , permite crearea de operatori, folosind doar fișiere YAML declarative. De exemplu, operatorul pentru Apache Kafka va fi definit cam astfel $ kubectl kudo install zookeeper $ kubectl kudo install kafka
Și apoi se poate configura cu ajutorul unei alte comenzi:$ 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
Inovații
În ultimii câțiva ani, lansările mari ale Kubernetes apar la fiecare câteva luni – adică, de trei-patru ori pe an. Numărul de caracteristici noi implementate în fiecare dintre acestea nu scade. Mai mult, nu există semne de încetinire, chiar și în aceste vremuri complicate – priviți câtă
este activitatea proiectului Kubernetes pe Github .
Noile posibilități permit o mai mare flexibilitate în clusterizarea operațiunilor atunci când există diverse sarcini de lucru. În plus, programatorilor le oferă un control mai complet la desfășurarea aplicațiilor direct în producție.
Comunitatea
Un alt aspect important al popularității Kubernetes este puterea comunității sale. În 2015, odată cu atingerea versiunii 1.0, Kubernetes a fost sponsorizat .
Există, de asemenea, diverse comunități (grupuri speciale de interes), dedicate abordării diferitelor domenii ale Kubernetes pe măsură ce acest proiect evoluează. Aceste grupuri adaugă constant funcționalități noi, făcând lucrul cu Kubernetes din ce în ce mai convenabil.
Fundația Cloud Native organizează de asemenea CloudNativeCon/KubeCon, care, la momentul scrierii acestui text, este cea mai mare conferință open source din lume. De obicei, se desfășoară de trei ori pe an și reunește mii de profesioniști care doresc să îmbunătățească Kubernetes și ecosistemul acestuia, precum și să învețe noi posibilități care apar la fiecare trei luni.
În plus, Fundația Cloud Native are , care, împreună cu SIG-urile, examinează noi și existente ale fundației, orientate spre ecosistemul cloud. Majoritatea acestor proiecte contribuie la îmbunătățirea punctelor forte ale Kubernetes.
În cele din urmă, cred că Kubernetes nu ar fi avut atât de mult succes fără eforturile conștiente ale întregii comunități, unde oamenii se sprijină reciproc, dar, în același timp, primesc cu bucurie noi membri.
Viitorul
Una dintre principalele provocări cu care se vor confrunta dezvoltatorii în viitor este abilitatea de a se concentra asupra detaliilor codului în sine, mai degrabă decât asupra infrastructurii în care acesta funcționează. Aceste tendințe sunt abordate de , care este astăzi una dintre cele mai de frunte. Există deja cadre avansate, de exemplu, și , care utilizează Kubernetes pentru a abstractiza infrastructura de dezvoltator.
În acest articol am analizat doar pe scurt starea actuală a Kubernetes – de fapt, aceasta este doar vârful icebergului. Utilizatorii Kubernetes au la dispoziție multe alte resurse, posibilități și configurații.
Sursa: habr.com
