Përshëndetje, Habr!
Në fund të verës, dëshirojmë të kujtojmë se po vazhdojmë me punën e temës dhe vendosëm të publikojmë një artikull nga Stackoverflow që tregon gjendjen e projektit në fillim të qershorit.
Lexim të këndshëm!
Në momentin e shkruarjes së këtij artikulli, mosha e Kubernetes është rreth , dhe në dy vitet e fundit popullariteti i tij është rritur aq shumë sa që ai vazhdimisht është në mesin e Këtë vit, Kubernetes zë vendin e tretë. Kujtojmë: Kubernetes është një platformë e destinuar për të drejtuar dhe orkestruar ngarkesat pune në konteiner.
Konteinerët kanë lindur si një strukturë e veçantë për izolimin e proceseve në Linux; që nga viti 2007 ata përmbajnë , dhe që nga viti 2002 - hapësirat emërtuese. Konteinerët u formuan edhe më mirë në vitin 2008, kur u bë e disponueshme , dhe në Google zhvilluan një mekanizëm të brendshëm të quajtur , ku "të gjithë punët bëhen në konteinerë". Nga aty do të kalojmë në vitin 2013, kur u publikua versioni i parë i Docker, dhe konteinerët kaluan përfundimisht në kategorinë e zgjidhjeve popullore masive. Në atë kohë, mjeti kryesor për orkestrimin e konteinerëve ishte , megjithatë ai nuk gëzonte popullaritet të madh. Publikimi i parë i Kubernetes ndodhi në vitin 2015, pas të cilit ky mjet në fakt u bë standard në fushën e orkestrimit të konteinerëve.
Për të përpiquar të kuptojmë se përse Kubernetes është kaq i populllar, le të përpiqemi të përgjigjemi në disa pyetje. Kur ishte hera e fundit që zhvilluesit arritën të binin dakord për mënyrën e shpërndarjes së aplikacioneve në prodhim? Sa zhvillues njohni që përdorin mjetet në formën siç ofrohen "nga kuti"? Sa administratorë cloud keni sot që nuk e kuptojnë se si funksionojnë aplikacionet? Përshtypjet për këto pyetje do t’i shqyrtojmë në këtë artikull.
Infrastruktura si YAML
Në një botë që kaloi nga Puppet dhe Chef për në Kubernetes, një nga ndryshimet më të mëdha ishte kalimi nga "infrastruktura si kod" në "infrastruktura si të dhëna" — konkretisht, si YAML. Të gjitha burimet në Kubernetes, që përfshijnë pod-et, konfigurimet, instancat e shpërndara, vjetët dhe të tjera, mund të përshkruhen lehtësisht në një skedë YAML. Për shembull:
apiVersion: v1
kind: Pod
metadata:
name: site
labels:
app: web
spec:
containers:
- name: front-end
image: nginx
ports:
- containerPort: 80Me një prezantim të tillë, specialistëve të DevOps ose SRE u lehtësohet të shprehin plotësisht ngarkesat e punës së tyre, pa pasur nevojë të shkruajnë kod programimi në gjuhë si Python ose Javascript.
Avantazhet e tjera të organizimit të infrastrukturës së të dhënave, veçanërisht, janë si më poshtë:
- GitOps ose versionimi i operacioneve Git. Ky qasje lejon mbajtjen e të gjithë skedarëve YAML të Kubernetes në depo git, duke mundësuar të gjurmohet saktësisht se kur është bërë një ndryshim, kush e bëri atë dhe çfarë ka ndryshuar. Këtu rritet transparenca e operacioneve brenda tërë organizatës, dhe rritet efikasiteti nëpërmjet eliminimit të paqartësive, veçanërisht në lidhje me vendndodhjen e burimeve që kërkojnë punonjësit. Në të njëjtën kohë, bëhet më e lehtë që të bëhen ndryshime automatike në burimet e Kubernetes - përmes bashkimit të zakonshëm të kërkesave për tërheqje.
- Shkallëzueshmëria. Kur burimet janë të definuara në formë YAML, operatorëve të grumbullit u bëhet jashtëzakonisht e lehtë të ndryshojnë një ose dy numra në burimin Kubernetes, duke ndryshuar kështu parimet e shkallëzimit të tij. Kubernetes ka një mekanizëm për automatik shkallëzimin horizontal të pod-eve, me anë të të cilit përcaktohet lehtësisht se cili është numri minimal dhe maksimal i pod-eve që nevojiten në një konfigurim të caktuar të implementuar, për të përballuar nivele të ulëta dhe të larta të trafikut. Për shembull, nëse keni implementuar një konfigurim për të cilin kërkohen kapacitete shtesë për shkak të një shpërthimi të papritur të trafikut, atëherë treguesi maxReplicas mund të ndryshohet nga 10 në 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- Siguria dhe menaxhimi. YAML është një format i shkëlqyer për të vlerësuar se si implementohen gjërat në Kubernetes. Për shembull, një problem serioz i sigurisë lidhet me faktin nëse ngarkesat tuaja të punës ekzekutohen nga një përdorues pa privilegje administratorësh. Në këtë rast, mjetet si , validues i YAML/JSON, përveç , validues politikash, që siguron se konteksti ngarkat e punës suaj nuk i lejojnë kontejnerit të punojë me privilegje administratori. Nëse kjo kërkohet, përdoruesit mund të zbatojnë një politikë të thjeshtë , ndryshe kështu:
package main
deny[msg] {
input.kind = "Deployment"
not input.spec.template.spec.securityContext.runAsNonRoot = true
msg = "Kontejnerët nuk duhet të punojnë si root"
}- Opsionet e integrimit me ofruesin e cloud. Një nga tendencat më të dukshme në teknologjitë moderne është të запускаш ngarkesat e punës në kapacitetet e ofruesve publikë të cloud. Me ndihmën e komponentit Kubernetes lejon çdo klaster të integrohet me ofruesin e cloud me të cilin punon. Për shembull, nëse një përdorues ka nisur një aplikacion në Kubernetes në AWS dhe dëshiron të hapë qasje në këtë aplikacion përmes një shërbimi, ofruesi i cloud ndihmon automatikisht në krijimin e një shërbimi
LoadBalancer, i cili do të ofrojë automatikisht një balancues ngarkese , për të shpërndarë trafikun në podet e aplikacioneve.
Zgjerueshmëria
Kubernetes është shumë i zgjerueshëm, dhe kjo pëlqehet nga zhvilluesit. Ekziston një grup burimesh të disponueshme, si podet, deploymet, StatefulSets, sekretet, ConfigMaps, etj. E vërtetë, përdoruesit dhe zhvilluesit mund të shtojnë burime të tjera në formën e .
Për shembull, nëse duam të definim një burim CronTab, mund të bëjmë diçka të tillë:
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
Më vonë, mund të krijojmë një burim CronTab në mënyrë të ngjashme:
apiVersion: "my.org/v1"
kind: CronTab
metadata:
name: my-cron-object
spec:
cronSpec: "* * * * */5"
image: my-cron-image
replicas: 5
Një mundësi tjetër zgjerueshmërie në Kubernetes është se zhvilluesi mund të shkruajë operatorë të tij. – është një proces i veçantë në klasterin Kubernetes, që punon sipas modelit "". Me ndihmën e operatorit, përdoruesi mund të automatizojë menaxhimin e CRD (definimeve të burimeve të personalizuara), duke shkëmbyer informacion me Kubernetes API.
Në komunitet ka disa mjete, me anë të të cilave zhvilluesit mund ta krijojnë lehtë operatorin e tyre. Ndër to janë dhe degëve të tij . Ky SDK ofron një bazë, nga e cila zhvilluesi mund të fillojë shpejt të krijojë një operator. Për shembull, mund të filloni nga komanda e linjës kështu:
$ operator-sdk new my-operator --repo github.com/myuser/my-operatorKështu krijohet e gjithë kodi stereotipik për operatorin tuaj, duke përfshirë, skedarët YAML dhe kodin 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.goPastaj, mund të shtoni API-të dhe kontrolluesin e nevojshëm, kështu:
$ operator-sdk add api --api-version=myapp.com/v1alpha1 --kind=MyAppService
$ operator-sdk add controller --api-version=myapp.com/v1alpha1 --kind=MyAppServicePas kësaj, përfundimisht, ndërtoni operatorin dhe dërgojeni në regjistrin e kontejnerit tuaj:
$ operator-sdk build your.container.registry/youruser/myapp-operator Nëse zhvilluesi kërkon më shumë kontroll, mund të modifikojë kodin stereotipik në skedarët Go. Për shembull, për të ndryshuar specifikën e kontrolluesit, mund të bëni ndryshime në skedarin controller.go.
Një projekt tjetër, , lejon krijimin e operatorëve duke përdorur vetëm skedarë deklarativë YAML. Për shembull, një operator për Apache Kafka do të përcaktohej më ose më pak . Me të mund të instaloni një kluster Kafka mbi Kubernetes me vetëm disa komanda:
$ kubectl kudo install zookeeper
$ kubectl kudo install kafkaDhe pastaj ta konfiguronit me një komandë tjetër:
$ 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
Inovacionet
Gjatë disa viteve të fundit, lëshimet e mëdha të Kubernetes dalin çdo disa muaj – dmth, tre-katër lëshime të mëdha në vit. Numri i karakteristikave të reja të implementuara në secilin prej tyre nuk po zvogëlohet. Për më tepër, nuk ka shenja ngadalësimi edhe në këto kohë të komplikuara – shikoni se sa është aktualisht .
Mundësitë e reja lejojnë një klasterizim më fleksibël të operacioneve kur ka ngarkesa të ndryshme pune. Për më tepër, programuesve u pëlqen një kontroll më i plotë gjatë implementimit të aplikacioneve direkt në prodhim.
Komuniteti
Një aspekt tjetër serioz i popullaritetit të Kubernetes është forca e komunitetit të tij. Në vitin 2015, me arritjen e versionit 1.0, Kubernetes u sponzorua .
Gjithashtu ekzistojnë komunitete të ndryshme (grupet speciale të interesit), të fokusuar në zhvillimin e fushave të ndryshme të Kubernetes ndërsa ky projekt evoluon. Këto grupe vazhdimisht shtojnë mundësi të reja, duke e bërë përdorimin e Kubernetes më të lehtë dhe më të ndjerë.
Fondacioni Cloud Native gjithashtu organizon CloudNativeCon/KubeCon, e cila, në momentin e shkrimit të këtij teksti, është konferenca më e madhe open source në botë. Si rregull, ajo zhvillohet tri herë në vit dhe mbledh mijëra profesionistë që dëshirojnë të përmirësojnë Kubernetes dhe ekosistemin e tij, si dhe të mësojnë mundësitë e reja që shfaqen çdo tre muaj.
Më tej, në Fondacionin Cloud Native ka , i cili, së bashku me SIG-të shqyrton projektet e reja dhe ato ekzistuese të fondit, të fokusuara në ekosistemin cloud. Shumica e këtyre projekteve ndihmojnë në përmirësimin e pikave të forta të Kubernetes.
Së fundmi, unë besoj se Kubernetes nuk do të kishte arritur suksesin e tij pa përpjekjet e vetëdijshme të tërë komunitetit, ku njerëzit mbështesin njëri-tjetrin, por si njëkohësisht mirëpresin me kënaqësi të rinjtë në radhët e tyre.
E ardhmja
Një nga sfidat kryesore që zhvilluesit do të kenë përballë në të ardhmen është aftësia për t'u përqendruar në detajet e kodit të vet, dhe jo në infrastrukturën në të cilën ai operon. Këto tendenca janë në përgjigje të , e cila sot është një nga më të njohurat. Tashmë ekzistojnë korniza të avancuara, për shembull, dhe , që përdorin Kubernetes për të abstruar infrastrukturën nga zhvilluesi.
Në këtë artikull ne vetëm përmbledhim gjendjen aktuale të Kubernetes – në të vërtetë, kjo është vetëm maja e ajsbergut. Përdoruesit e Kubernetes kanë gjithashtu shumë burime, mundësi dhe konfiguracione të tjera në dispozicion.
Burimi: habr.com
