Përshëndetje, Habr!
Në fund të verës, dëshirojmë të kujtojmë se vazhdojmë të punojmë mbi temën dhe kemi vendosur të publikojmë një artikull nga Stackoverflow, që tregon gjendjen e projektit në fillim të qershorit.
Lexim të këndshëm!
Në momentin kur po shkruhej ky artikull, mosha e Kubernetes është rreth , dhe në dy vitet e fundit, popullariteti i tij është rritur aq shumë sa që ai vazhdimisht renditet në mesin e . Këtë vit, Kubernetes zë vendin e tretë. Kujtojmë: Kubernetes është një platformë e destinuar për ekzekutimin dhe orkestrimin e ngarkesave të punës në konteinerë.
Konteinerët kanë lindur si një konstrukt i veçantë për izolimin e proceseve në Linux; në përbërje të konteinerëve nga viti 2007 përfshihen , dhe nga viti 2002 – hapësirat emërore. Konteinerët u formësuan më mire deri në vitin 2008, kur u bë e mundur , dhe në Google zhvilluan një mekanizëm të brendshëm të quajtur , ku "të gjithë punët realizohen në konteinerë". Le të kalojmë në vitin 2013, kur u realizua publikimi i parë i Docker, dhe konteinerët përfundimisht kaluan në kategorinë e zgjidhjeve popullore masive. Në atë kohë, mjeti kryesor për orkestrimin e konteinerëve ishte , megjithatë, ai nuk ishte shumë i njohur. Publikimi i parë i Kubernetes u realizua në vitin 2015, pas të cilit ky mjet u bë de facto standard në fushën e orkestrimit të konteinerëve.
Për të përpiqen të kuptojnë se përse Kubernetes është kaq i njohur, le të mundohemi të përgjigjemi në disa pyetje. Kur ishte hera e fundit që zhvilluesit arritën me sukses të bien dakord për mënyrën e shtrirjes së aplikacioneve në prodhim? Sa shumë zhvillues njohin që përdorin mjetet ashtu siç ofrohen "nga kutia"? Sa shumë administrues të mjeteve në cloud sot nuk e kuptojnë se si funksionojnë aplikacionet? Të dhënat për këto pyetje do të shqyrtojmë në këtë artikull.
Infrastruktura si YAML
Në botën që kaloi nga Puppet dhe Chef 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, përfshirë pod-ët, konfigurimet, instancat e shpërndara, volumin e të tjerëve, 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ë paraqitje të tillë, specialistëve në DevOps ose SRE u është lehtësuar të shprehin plotësisht ngarkesat e tyre të punës, pa pasur nevojë të shkruajnë kod programimi në gjuhë si Python ose Javascript.
Avantazhet e tjera të organizimit të infrastrukturës si të dhëna janë, në veçanti:
- GitOps ose kontrolli i versioneve të Operacioneve Git. Kjo qasje lejon që të gjitha skedat YAML të Kubernetes të mbahen në repozita git, duke ju mundësuar të ndjekni me saktësi kohën kur është bërë një ndryshim, kush e ka bërë dhe çfarë është ndryshuar. Kjo rrit transparencën e operacioneve në të gjithë organizatën, rrit efikasitetin e punës për shkak të eliminimit të paqartësive, sidomos në atë se ku punonjësit duhet të kërkojnë burimet e nevojshme. Në të njëjtën kohë, bëhet më e lehtë të bëhen ndryshime automatikisht në burimet e Kubernetes — përmes bashkimit të zakonshëm të kërkesave pull.
- Shkallëzueshmëria. Kur burimet përcaktohen si YAML, operatorëve të klasterit u bëj shumë e lehtë të ndryshojnë një ose dy numra në burimin e Kubernetes, duke ndryshuar kështu parimet e tij të shkallëzimit. Në Kubernetes ka mekanizmin për shkallëzimin horizontal automatik të pod-eve, me të cilin lehtësisht përcaktohet sesi është numri minimal dhe maksimal i pod-eve që kërkohet në një konfigurim të veçantë për të përballuar nivelet e ulëta dhe të larta të trafikut. Për shembull, nëse keni shpërndarë një konfigurim që ka nevojë për mundësi shtesë për shkak të një rritjeje të papritur të trafikut, numri i 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ë mjaft e dobishme për të vlerësuar se si gjërat e caktuara janë të shpërndara në Kubernetes. Për shembull, një problem i rëndësishëm që ka të bëjë me sigurinë është, nëse ngarkesat tuaja të punës po ekzekutohen nga një përdorues që nuk ka të drejtat e administratorit. Në këtë rast, mund të na nevojiten mjete si , një validar i YAML/JSON, plus , një validar politikash, i cili siguron që konteksti ngarkesat e juaja nuk lejon që kontejneri të funksionojë me privilegje administratori. Nëse kërkohet kjo, përdoruesit mund të aplikojnë njëPolitikë të thjeshtë , 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 përdorues root"
}- Mundësitë e integrimit me ofruesin e shërbimit në cloud. Një nga tendencat më të dukshme në teknologjinë e sotme është të ekzekutoni ngarkesat e punës në kapacitetin e ofruesve të shërbimit në cloud. Me ndihmën e komponentit Kubernetes lejon çdo klaster të integrohet me ofruesin e shërbimeve në cloud me të cilin funksionon. Për shembull, nëse përdoruesi ka nisur një aplikacion në Kubernetes në AWS dhe dëshiron të hapë akses në këtë aplikacion nëpërmjet një shërbimi, ofruesi i shërbimit ndihmon automatikisht në krijimin e një shërbimi
LoadBalancer, i cili do të ofrojë automatikisht një balancues ngarkese , për të redirigjuar trafikun në pod-et e aplikacioneve.
Zgjerueshmëria
Kubernetes është shumë i zgjerueshëm, dhe kjo pëlqehet nga zhvilluesit. Ekziston një grup burimesh të disponueshme, si pod-et, deploy-et, StatefulSets, sekretet, ConfigMaps, etj. Megjithatë, përdoruesit dhe zhvilluesit mund të shtojnë burime të tjera në formën e .
Për shembull, nëse dëshirojmë të përcaktojmë një burim CronTab, do të mund të bënim 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ë, ne mund të krijojmë një burim CronTab në një 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ë tjetër mundësi për zgjerueshmërinë në Kubernetes është që zhvilluesi mund të shkruajë operatorë të vetë. – është një proces i veçantë në klasterin Kubernetes, që funksionon sipas modelit "". Me ndihmën e operatorit, përdoruesi mund të automatizojë menaxhimin e CRD-ve (definimeve të personalizuara të burimeve), duke shkëmbyer informacion me Kubernetes API.
Në komunitet ekzistojnë disa mjete, me ndihmën e të cilave është e lehtë për zhvilluesit të krijojnë operatorë të vetë. Ndër to është dhe . Ky SDK ofron një bazë, nga e cila, zhvilluesi mund të fillojë shumë shpejt të krijojë një operator. Le të themi, mund të filloni nga komandat e linjës në këtë mënyrë:
$ operator-sdk new my-operator --repo github.com/myuser/my-operatorKëtu krijohet gjithë kodi standard për operatorin tuaj, 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.goMë pas, mund të shtoni API dhe kontrollues të 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 ndjeni operatorin dhe dërgojeni në regjistrin e kontejnerëve tuaj:
$ operator-sdk build your.container.registry/youruser/myapp-operator Nëse zhvilluesi ka nevojë për më shumë kontroll, mund të modifikojë kodin standard në skedarët në Go. Për shembull, nëse dëshiron të ndryshojë specifikat e kontrolluesit, mund të bëjë ndryshime në skedarin controller.go.
Një projekt tjetër, , lejon të krijoni operatorë duke përdorur vetëm skedarë YAML deklarativë. Për shembull, një operator për Apache Kafka do të përcaktohej në këtë mënyrë . Me ndihmën e tij, mund të instaloni një klaster Kafka mbi Kubernetes me vetëm disa komanda:
$ kubectl kudo install zookeeper
$ kubectl kudo install kafkaDhe më pas ta konfiguroni 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, tri deri në katër lëshime të mëdha në vit. Numri i karakteristikave të reja që përfshihen në secilën nga ato nuk po zvogëlohet. Për më tepër, nuk ka shenja të ngadalësimit as në kohët tona të vështira – shihni se cila është tani .
Karakteristika të reja lejojnë një menaxhim më fleksibël të klasterëve me ngarkesa të ndryshme punë. Për më tepër, zhvilluesve u pëlqen kontrolli më i plotë gjatë përhapjes së aplikacioneve drejtpërdrejt në prodhim.
Komuniteti
Një aspekt tjetër serioz i popullaritetit të Kubernetes është fuqia e komunitetit të tij. Në vitin 2015, pas arritjes së versionit 1.0, Kubernetes u sponsorua .
Po ashtu, ekzistojnë disa komunitete (grupet e interesa të veçanta), të cilat janë të destinuara për të shqyrtuar fusha të ndryshme të Kubernetes ndërsa ky projekt zhvillohet. Këto grupe vazhdimisht shtojnë mundësi të reja, duke e bërë përdorimin e Kubernetes më të lehtë e më të rehatshëm.
Fondi Cloud Native Foundation gjithashtu organizon CloudNativeCon/KubeCon, që, në momentin e shkrimit të këtij teksti, është konferenca më e madhe open-source në botë. Në përgjithësi, ajo organizohet tre herë në vit dhe mbledh mijëra profesionistë të interesuar për të përmirësuar Kubernetes dhe ekosistemin e tij, si dhe për të përvetësuar mundësi të reja që shfaqen çdo tre muaj.
Madje, në Cloud Native Foundation ekziston , i cili, së bashku me SIG, shqyrton projektet e reja dhe ato ekzistuese të fondit, të orientuara drejt ekosistemës në cloud. Shumica e këtyre projekteve ndihmojnë në përmirësimin e forcave të Kubernetes.
Në fund, besoj se Kubernetes nuk do të kishte pasur një sukses të tillë pa përpjekjet e vetëdijshme të gjithë komunitetit, ku njerëzit mbështesin njëri-tjetrin, por në të njëjtën kohë, me kënaqësi pranojnë gjithashtu fillestarët në radhët e tyre.
E ardhmja
Një nga sfidat kryesore me të cilat zhvilluesit do të përballen në të ardhmen është aftësia për t'u përqendruar në detajet e kodit të vet, e jo në infrastrukturën në të cilën funksionon. Kjo tendencë përputhet me , e cila sot është një nga udhëheqëse. Tani ekzistojnë framework-e të avancuara, si p.sh., dhe , të cilat përdorin Kubernetes për të abstaraktuar infrastrukturën nga zhvilluesi.
Në këtë artikull ne shqyrtuam vetëm në pika të përgjithshme gjendjen aktuale të Kubernetes – në të vërtetë, kjo është vetëm maja e ajsbergut. Përdoruesit e Kubernetes kanë një sërë burimesh, mundësish dhe konfiguracionesh në dispozicion.
Burimi: habr.com
