Aupa Habr!
Uda amaieran, gaia lantzen jarraitzen dugula gogorarazi nahi dizuegu eta proiektu honen egoera erakusten duen Stackoverflow-en artikulu bat argitaratzea erabaki zuen ekainaren hasieran.
Gozatu irakurketa!
Artikulu hau idazteko momentuan, Kubernetesen adina gutxi gorabehera. , eta azken bi urteetan bere ospea hainbeste hazi da, non etengabe sailkatzen baita plataformak. Kubernetes hirugarren postuan dago aurten. Berrikusteko: Kubernetes edukiontzidun lan-kargak exekutatzeko eta orkestratzeko diseinatutako plataforma da.
Ontziak Linux-en prozesuak isolatzeko diseinu berezi gisa hasi ziren; edukiontziak barne hartzen ditu 2007tik , eta 2002tik - izen-espazioak. Ontziak are hobeto diseinatu ziren 2008rako, eskuragarri egon zenean , eta Google-k bere barne-mekanismo korporatiboa garatu zuen , non "lan guztiak edukiontzietan egiten diren". Hemendik aurrera 2013. urtera arte, Docker-en lehen bertsioa egin zenean, azkenean ontziak masa irtenbide ezagun bihurtu ziren. Garai hartan, edukiontzien orkestraziorako tresna nagusia zen , oso ezaguna ez zen arren. Kubernetes 2015ean kaleratu zen lehen aldiz, eta ondoren tresna hau edukiontzien orkestrazioaren alorrean de facto estandarra bihurtu zen.
Kubernetes zergatik den hain ezaguna ulertzen saiatzeko, saia gaitezen galdera batzuk erantzuten. Noiz izan zen garatzaileek aplikazioak ekoizpenera nola zabaldu adosteko gai izan ziren azken aldia? Zenbat garatzaile ezagutzen dituzu tresnak erabiltzen dituztenak, kutxatik kanpo ematen diren heinean? Zenbat hodeiko administratzaile daude gaur aplikazioek nola funtzionatzen duten ulertzen ez dutenak? Galdera hauen erantzunak artikulu honetan ikusiko ditugu.
Azpiegitura YAML gisa
Puppet eta Chef-etik Kubernetesera joan zen munduan, aldaketa handienetako bat "azpiegitura kode gisa"tik "azpiegitura datu gisa" izatera pasa zen, zehazki, YAML bezala. Kubernetes-en baliabide guztiak, lekak, konfigurazioak, zabaldutako instantziak, bolumenak eta abar barne, erraz deskriba daitezke YAML fitxategi batean. Adibidez:
apiVersion: v1
kind: Pod
metadata:
name: site
labels:
app: web
spec:
containers:
- name: front-end
image: nginx
ports:
- containerPort: 80Ikuspegi honek DevOps edo SRE profesionalek beren lan-kargak guztiz adieraztea errazten dute Python edo Javascript bezalako lengoaietan kodea idatzi beharrik gabe.
Azpiegitura datu gisa antolatzearen beste abantaila batzuk hauek dira:
- GitOps edo Git Operations Bertsio Kontrola. Ikuspegi honi esker, Kubernetes YAML fitxategi guztiak git biltegietan gorde ditzakezu, aldaketa bat noiz egin den, nork egin duen eta zehazki zer aldatu den jarrai dezazun. Horrek erakunde osoan eragiketen gardentasuna areagotzen du eta eraginkortasun operatiboa hobetzen du anbiguotasuna ezabatuz, batez ere langileek behar dituzten baliabideak bilatu behar dituzten tokietan. Aldi berean, errazagoa da Kubernetes baliabideetan automatikoki aldaketak egitea, tira-eskaera bat batuz.
- Eskalagarritasuna. Baliabideak YAML gisa definitzen direnean, oso erraza da kluster-operadoreentzat Kubernetes baliabide batean zenbaki bat edo bi aldatzea, eta horrela eskalatzeko modua aldatuz. Kubernetes-ek ontzien eskalatze automatiko horizontalerako mekanismo bat eskaintzen du, eta inplementazio-konfigurazio jakin batean gutxieneko eta gehienezko pod-kopurua behar den zehazteko erabil daiteke trafiko-maila baxua eta altua kudeatzeko. Adibidez, trafikoaren bat-bateko gorakadaren ondorioz gaitasun gehigarria behar duen konfigurazio bat zabaldu baduzu, maxReplicas 10etik 20ra alda daiteke:
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- Segurtasuna eta kudeaketa. YAML bikaina da Kubernetesen gauzak nola inplementatzen diren ebaluatzeko. Adibidez, segurtasun-kezka handi bat zure lan-kargak administratzaile ez den erabiltzaile gisa exekutatzen ari diren ala ez da. Kasu honetan, horrelako tresnak behar ditugu , YAML/JSON baliozkotzailea, gehi , testuingurua dela ziurtatzeko politika balioztatzailea zure lan-kargak ez du onartzen edukiontzia administratzaile-pribilegioekin exekutatzen. Hala behar izanez gero, erabiltzaileek politika sinple bat aplika dezakete , horrela:
package main
deny[msg] {
input.kind = "Deployment"
not input.spec.template.spec.securityContext.runAsNonRoot = true
msg = "Containers must not run as root"
}- Hodeiko hornitzaile batekin integratzeko aukerak. Gaur egungo goi-teknologiako joera nabarmenetako bat hodei publikoko hornitzaileen lan-kargak exekutatzeko da. Osagaia erabiliz Kubernetes-ek edozein kluster exekutatzen duen hodeiko hornitzailearekin integratzeko aukera ematen du. Adibidez, erabiltzaile batek Kubernetes-en aplikazio bat exekutatzen badu AWS-n eta aplikazio hori zerbitzu baten bidez erakutsi nahi badu, hodeiko hornitzaileak automatikoki zerbitzua sortzen laguntzen du.
LoadBalancerkarga-orekatzailea automatikoki emango duena trafikoa aplikazioen podetara birbideratzeko.
Zabalgarritasuna
Kubernetes oso hedagarria da eta garatzaileek maite dute. Eskuragarri dauden baliabide multzo bat dago, hala nola pods, inplementazioak, StatefulSets, sekretuak, ConfigMaps, etab. Egia da, erabiltzaileek eta garatzaileek beste baliabide batzuk gehi ditzakete formularioan .
Adibidez, baliabide bat definitu nahi badugu CronTab, orduan honelako zerbait egin dezakezu:
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
Geroago CronTab baliabide bat sor dezakegu honelako zerbait:
apiVersion: "my.org/v1"
kind: CronTab
metadata:
name: my-cron-object
spec:
cronSpec: "* * * * */5"
image: my-cron-image
replicas: 5
Kubernetesen hedagarritasunerako beste aukera bat garatzaileak bere adierazpenak idatz ditzake. Kubernetes klusterreko prozesu berezi bat da, eta "" Operadore baten laguntzarekin, erabiltzaileak CRD (pertsonen baliabideen definizioak) kudeaketa automatizatu dezake Kubernetes APIarekin informazioa trukatuz.
Komunitatean hainbat tresna daude garatzaileei beren operadoreak sortzea errazten dietenak. Haien artean - eta . SDK honek oinarri bat eskaintzen du garatzaile batek operadore bat sortzen azkar hasteko. Demagun komando lerrotik honelako zerbait has dezakezula:
$ operator-sdk new my-operator --repo github.com/myuser/my-operatorHonek zure operadorearentzat boilerplate kode guztia sortzen du, YAML fitxategiak eta Golang kodea barne:
.
|____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.goOndoren, beharrezko APIak eta kontrolagailua gehi ditzakezu, honela:
$ operator-sdk add api --api-version=myapp.com/v1alpha1 --kind=MyAppService
$ operator-sdk add controller --api-version=myapp.com/v1alpha1 --kind=MyAppServiceOndoren, azkenik, muntatu operadorea eta bidali zure edukiontziaren erregistrora:
$ operator-sdk build your.container.registry/youruser/myapp-operator
Garatzaileak are kontrol gehiago nahi badu, Go fitxategietako boilerplate kodea alda daiteke. Adibidez, kontrolagailuaren xehetasunak aldatzeko, fitxategian aldaketak egin ditzakezu controller.go.
Beste proiektu bat , adierazpenak sortzeko aukera ematen du YAML fitxategi deklaratiboak soilik erabiliz. Adibidez, Apache Kafka-rako operadore bat definituko litzateke gutxi gorabehera . Harekin, Kafka kluster bat instalatu dezakezu Kubernetes-en gainean komando pare batekin:
$ kubectl kudo install zookeeper
$ kubectl kudo install kafkaEta gero konfiguratu beste komando batekin:
$ 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
berrikuntzak
Azken urteotan, Kubernetes-en bertsio nagusiak hilabete gutxiro ateratzen ari dira, hau da, urtean hiruzpalau bertsio nagusi. Horietako bakoitzean sartutako ezaugarri berrien kopurua ez da gutxitzen. Gainera, momentu zail hauetan ere ez dago moteltze zantzurik -begira zein den orain egoera .
Gaitasun berriek eragiketak malgutasun handiagoz multzokatzeko aukera ematen dute hainbat lan-kargatan. Gainera, programatzaileek kontrol handiagoa dute aplikazioak produkziora zuzenean zabaltzean.
Erkidegoko
Kubernetes-en ospearen beste alderdi garrantzitsu bat bere komunitatearen indarra da. 2015ean, 1.0 bertsiora iristean, Kubernetes-ek babestu zuen .
Hainbat komunitate ere badaude (Interes Bereziko Taldeak) Kubernetesen hainbat arlo lantzera bideratu ziren, proiektua garatzen doan heinean. Talde hauek etengabe funtzio berriak gehitzen ari dira, Kubernetesekin lan egitea erosoagoa eta erosoagoa bihurtuz.
Cloud Native Foundation-ek ere CloudNativeCon/KubeCon hartzen du, hau da, idazteko unean, munduko kode irekiko konferentziarik handiena da. Normalean urtean hiru aldiz egin ohi da, Kubernetes eta bere ekosistema hobetu nahi duten milaka profesional biltzen ditu, baita hiru hilean behin agertzen diren ezaugarri berriak ikasi ere.
Gainera, Cloud Native Foundation-ek ere badu , SIGekin batera berriak eta daudenak berrikusten dituena hodei ekosistemara bideratutako funtsak. Proiektu horietako gehienek Kubernetesen indarguneak hobetzen laguntzen dute.
Azkenik, uste dut Kubernetes-ek ez lukeela bezain arrakastarik izango komunitate osoaren ahalegin kontzienterik gabe, non jendea elkartzen den baina, aldi berean, etorri berriei ongi etorria emanez.
etorkizunean
Etorkizunean garatzaileek aurre egin beharko dioten erronka nagusietako bat kodearen beraren xehetasunetan zentratu ahal izatea da, eta ez exekutatzen duen azpiegituran. Joera horiek betetzen ditu , gaur egun nagusietako bat dena. Dagoeneko existitzen dira esparru aurreratuak, adibidez. ΠΈ , Kubernetes erabiltzen duena garatzailearen azpiegitura abstraitzeko.
Artikulu honetan, Kubernetesen egungo egoeraren gainazala urratu besterik ez dugu egin, hain zuzen ere, icebergaren punta besterik ez da. Kuberneteseko erabiltzaileek beste baliabide, gaitasun eta konfigurazio asko dituzte eskura.
Iturria: www.habr.com