Hej Habr!
Në fund të verës, duam t'ju kujtojmë se ne vazhdojmë të punojmë në këtë temë dhe vendosi të publikojë një artikull nga Stackoverflow që demonstron gjendjen e punëve në këtë projekt në fillim të qershorit.
Gëzoni leximin!
Në kohën e shkrimit të këtij artikulli, mosha e Kubernetes është përafërsisht. , dhe gjatë dy viteve të fundit popullariteti i saj është rritur aq shumë sa që renditet vazhdimisht ndër platformat. Kubernetes renditet i treti këtë vit. Për të përmbledhur: Kubernetes është një platformë e krijuar për ekzekutimin dhe orkestrimin e ngarkesave të punës me kontejnerë.
Kontejnerët filluan si një dizajn i veçantë për izolimin e proceseve në Linux; kontejnerët janë përfshirë që nga viti 2007 , dhe që nga viti 2002 – hapësirat e emrave. Kontejnerët u projektuan edhe më mirë në vitin 2008, kur u bë i disponueshëm , dhe Google zhvilloi mekanizmin e vet të brendshëm të korporatës të quajtur , ku "e gjithë puna kryhet në kontejnerë." Prej këtu ne shpejtojmë përpara në 2013, kur u publikua për herë të parë Docker, dhe kontejnerët më në fund u bënë një zgjidhje masive popullore. Në atë kohë, mjeti kryesor për orkestrimin e kontejnerëve ishte , edhe pse ai nuk ishte shumë popullor. Kubernetes u lëshua për herë të parë në 2015, pas së cilës ky mjet u bë standardi de fakto në fushën e orkestrimin e kontejnerëve.
Për t'u përpjekur të kuptojmë pse Kubernetes është kaq popullor, le të përpiqemi t'u përgjigjemi disa pyetjeve. Kur ishte hera e fundit që zhvilluesit ishin në gjendje të bien dakord se si të vendosnin aplikacionet në prodhim? Sa zhvillues njihni që përdorin mjetet pasi ato ofrohen jashtë kutisë? Sa administratorë të cloud ka sot që nuk e kuptojnë se si funksionojnë aplikacionet? Ne do t'i shohim përgjigjet e këtyre pyetjeve 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" - veçanërisht, si YAML. Të gjitha burimet në Kubernetes, të cilat përfshijnë pods, konfigurime, instanca të vendosura, vëllime, etj., mund të përshkruhen lehtësisht në një skedar YAML. Për shembull:
apiVersion: v1
kind: Pod
metadata:
name: site
labels:
app: web
spec:
containers:
- name: front-end
image: nginx
ports:
- containerPort: 80Kjo pamje e bën më të lehtë për profesionistët e DevOps ose SRE që të shprehin plotësisht ngarkesat e tyre të punës pa pasur nevojë të shkruajnë kode në gjuhë si Python ose Javascript.
Përparësi të tjera të organizimit të infrastrukturës si të dhëna përfshijnë:
- Kontrolli i versionit të GitOps ose Git Operations. Kjo qasje ju lejon të mbani të gjithë skedarët e Kubernetes YAML në depot e git, në mënyrë që të mund të gjurmoni saktësisht kur është bërë një ndryshim, kush e bëri atë dhe çfarë ndryshoi saktësisht. Kjo rrit transparencën e operacioneve në të gjithë organizatën dhe përmirëson efikasitetin operacional duke eliminuar paqartësitë, veçanërisht në ato ku punonjësit duhet të kërkojnë burimet që u nevojiten. Në të njëjtën kohë, bëhet më e lehtë të bësh automatikisht ndryshime në burimet e Kubernetes duke bashkuar thjesht një kërkesë tërheqjeje.
- Shkallëzueshmëria. Kur burimet përcaktohen si YAML, bëhet jashtëzakonisht e lehtë për operatorët e grupimeve të ndryshojnë një ose dy numra në një burim Kubernetes, duke ndryshuar kështu shkallën e tij. Kubernetes ofron një mekanizëm për shkallëzimin automatik horizontal të pods, i cili mund të përdoret për të përcaktuar me lehtësi se cili është numri minimal dhe maksimal i pods-eve në një konfigurim të veçantë vendosjeje për të trajtuar nivele të ulëta dhe të larta të trafikut. Për shembull, nëse keni vendosur një konfigurim që kërkon kapacitet shtesë për shkak të një rritjeje të papritur në trafik, atëherë 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ë e shkëlqyeshme për të vlerësuar se si vendosen gjërat në Kubernetes. Për shembull, një shqetësim i madh sigurie ka të bëjë nëse ngarkesat tuaja të punës po funksionojnë si përdorues jo administrator. Në këtë rast, mund të na duhen mjete si p.sh , vërtetues YAML/JSON, plus , një vërtetues i politikës për të siguruar që konteksti ngarkesat tuaja të punës nuk lejojnë që kontejneri të funksionojë me privilegje administratori. Nëse kjo kërkohet, përdoruesit mund të aplikojnë një politikë të thjeshtë , si kjo:
package main
deny[msg] {
input.kind = "Deployment"
not input.spec.template.spec.securityContext.runAsNonRoot = true
msg = "Containers must not run as root"
}- Opsionet për integrimin me një ofrues cloud. Një nga tendencat më të dukshme në teknologjinë e lartë të sotme është ekzekutimi i ngarkesave të punës në ofruesit publikë të cloud. Duke përdorur komponentin Kubernetes lejon çdo grup të integrohet me ofruesin e cloud në të cilin funksionon. Për shembull, nëse një përdorues ekzekuton një aplikacion në Kubernetes në AWS dhe dëshiron ta ekspozojë atë aplikacion përmes një shërbimi, ofruesi i resë kompjuterike ndihmon në krijimin automatikisht të shërbimit
LoadBalanceri cili automatikisht do të sigurojë balancuesin e ngarkesës për të ridrejtuar trafikun në podat e aplikacionit.
Zgjerimi
Kubernetes është shumë i zgjerueshëm dhe zhvilluesit e duan atë. Ekziston një grup burimesh të disponueshme si pods, vendosjet, StatefulSets, sekretet, ConfigMaps, etj. Vërtetë, përdoruesit dhe zhvilluesit mund të shtojnë burime të tjera në formë .
Për shembull, nëse duam të përcaktojmë një burim CronTab, atëherë mund të bëni 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 diçka si kjo:
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 shtrirjen në Kubernetes është që zhvilluesi të mund të shkruajë deklaratat e tij. është një proces i veçantë në grupin Kubernetes që funksionon sipas "" Me ndihmën e një operatori, përdoruesi mund të automatizojë menaxhimin e CRD-ve (përkufizimet e burimeve me porosi) duke shkëmbyer informacione me Kubernetes API.
Ka disa mjete në komunitet që e bëjnë të lehtë për zhvilluesit të krijojnë operatorët e tyre. Midis tyre - dhe . Kjo SDK ofron një bazë nga e cila një zhvillues mund të fillojë shpejt krijimin e një operatori. Le të themi se mund të filloni nga linja e komandës diçka si kjo:
$ operator-sdk new my-operator --repo github.com/myuser/my-operatorKjo krijon të gjithë kodin e bojlerplate për operatorin tuaj, duke përfshirë skedarët YAML dhe kodin 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 kërkuar, si kjo:
$ operator-sdk add api --api-version=myapp.com/v1alpha1 --kind=MyAppService
$ operator-sdk add controller --api-version=myapp.com/v1alpha1 --kind=MyAppServiceMë pas, së fundi, montoni operatorin dhe dërgojeni në regjistrin e kontejnerit tuaj:
$ operator-sdk build your.container.registry/youruser/myapp-operator
Nëse zhvilluesi dëshiron edhe më shumë kontroll, kodi i bojlerplate në skedarët Go mund të ndryshohet. Për shembull, për të modifikuar specifikat e kontrolluesit, mund të bëni ndryshime në skedar controller.go.
Një tjetër projekt , ju lejon të krijoni deklarata duke përdorur vetëm skedarë deklarativë YAML. Për shembull, një operator për Apache Kafka do të përcaktohej afërsisht . Me të, ju mund të instaloni një grup Kafka në krye të Kubernetes me vetëm disa komanda:
$ kubectl kudo install zookeeper
$ kubectl kudo install kafkaDhe pastaj konfiguroni atë 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
risitë
Gjatë viteve të fundit, publikimet kryesore të Kubernetes kanë dalë çdo disa muaj - domethënë, tre deri në katër lëshime kryesore në vit. Numri i veçorive të reja të prezantuara në secilën prej tyre nuk zvogëlohet. Për më tepër, nuk ka shenja të ngadalësimit edhe në këto kohë të vështira - shikoni se si është situata tani .
Aftësitë e reja ju lejojnë të grumbulloni në mënyrë më fleksibël operacionet në ngarkesa të ndryshme pune. Përveç kësaj, programuesit gëzojnë kontroll më të madh kur vendosin aplikacione drejtpërdrejt në prodhim.
Komuniteti
Një tjetër aspekt kryesor i popullaritetit të Kubernetes është forca e komunitetit të tij. Në vitin 2015, me arritjen e versionit 1.0, Kubernetes u sponsorizua nga .
Ka edhe komunitete të ndryshme (Grupet e Interesit Special) u përqendruan në punën në fusha të ndryshme të Kubernetes ndërsa projekti evoluon. Këto grupe po shtojnë vazhdimisht veçori të reja, duke e bërë punën me Kubernetes më të përshtatshme dhe të përshtatshme.
Fondacioni Cloud Native gjithashtu pret CloudNativeCon/KubeCon, i cili, në kohën e shkrimit, është konferenca më e madhe me burim të hapur në botë. Zakonisht mbahet tre herë në vit, ai bashkon mijëra profesionistë që duan të përmirësojnë Kubernetes dhe ekosistemin e tij, si dhe të mësojnë veçori të reja që shfaqen çdo tre muaj.
Për më tepër, Cloud Native Foundation ka , i cili, së bashku me SIG-të, shqyrton të rejat dhe ekzistueset fondet e fokusuara në ekosistemin cloud. Shumica e këtyre projekteve ndihmojnë në përmirësimin e pikave të forta të Kubernetes.
Së fundi, unë besoj se Kubernetes nuk do të ishte aq i suksesshëm sa është pa përpjekjet e ndërgjegjshme të të gjithë komunitetit, ku njerëzit qëndrojnë së bashku, por në të njëjtën kohë mirëpresin të ardhurit në grup.
e ardhmja
Një nga sfidat kryesore me të cilat zhvilluesit do të duhet të përballen në të ardhmen është aftësia për t'u fokusuar në detajet e vetë kodit dhe jo në infrastrukturën në të cilën ai funksionon. Ajo plotëson këto tendenca , e cila është një nga liderët sot. Kornizat e avancuara tashmë ekzistojnë, p.sh. и , të cilat përdorin Kubernetes për të abstraguar infrastrukturën nga zhvilluesi.
Në këtë artikull, ne kemi gërvishtur vetëm sipërfaqen e gjendjes aktuale të Kubernetes - në fakt, është vetëm maja e ajsbergut. Përdoruesit e Kubernetes kanë në dispozicion shumë burime, aftësi dhe konfigurime të tjera.
Burimi: www.habr.com