Haai Habr!
Aan die einde van die somer wil ons u daaraan herinner dat ons voortgaan om aan die onderwerp te werk en het besluit om aan die begin van Junie 'n artikel van Stackoverflow te publiseer wat die stand van sake in hierdie projek demonstreer.
Geniet dit om te lees!
Ten tyde van die skryf van hierdie artikel is die ouderdom van Kubernetes ongeveer. , en oor die afgelope twee jaar het sy gewildheid so gegroei dat dit konsekwent onder die ranglys is platforms. Kubernetes beklee die derde plek vanjaar. Om saam te vat: Kubernetes is 'n platform wat ontwerp is vir die bestuur en orkestrasie van houerwerkladings.
Houers het begin as 'n spesiale ontwerp om prosesse in Linux te isoleer; houers is sedert 2007 ingesluit , en sedert 2002 – naamruimtes. Houers is selfs beter ontwerp teen 2008, toe dit beskikbaar geword het , en Google het sy eie interne korporatiewe meganisme genaamd ontwikkel , waar "alle werk in houers gedoen word." Van hier af vinnig vorentoe na 2013, toe die eerste vrystelling van Docker plaasgevind het, en houers uiteindelik 'n gewilde massa-oplossing geword het. Destyds was die hoofinstrument vir houerorkestrasie , hoewel hy nie baie gewild was nie. Kubernetes is die eerste keer in 2015 vrygestel, waarna hierdie instrument die de facto standaard op die gebied van houerorkestrasie geword het.
Om te probeer verstaan hoekom Kubernetes so gewild is, kom ons probeer om 'n paar vrae te beantwoord. Wanneer laas kon ontwikkelaars ooreenkom oor hoe om toepassings na produksie te ontplooi? Hoeveel ontwikkelaars ken jy wat die gereedskap gebruik soos dit uit die boks verskaf word? Hoeveel wolkadministrateurs is daar vandag wat nie verstaan hoe toepassings werk nie? Ons sal in hierdie artikel na die antwoorde op hierdie vrae kyk.
Infrastruktuur as YAML
In die wêreld wat van Puppet and Chef na Kubernetes gegaan het, was een van die grootste veranderinge die skuif van "infrastruktuur as kode" na "infrastruktuur as data" - spesifiek soos YAML. Alle hulpbronne in Kubernetes, wat peule, konfigurasies, ontplooide gevalle, volumes, ens. insluit, kan maklik in 'n YAML-lêer beskryf word. Byvoorbeeld:
apiVersion: v1
kind: Pod
metadata:
name: site
labels:
app: web
spec:
containers:
- name: front-end
image: nginx
ports:
- containerPort: 80Hierdie siening maak dit makliker vir DevOps- of SRE-professionals om hul werkladings volledig uit te druk sonder om kode in tale soos Python of Javascript te hoef te skryf.
Ander voordele van die organisering van infrastruktuur as data sluit in:
- GitOps of Git Operations Weergawebeheer. Hierdie benadering laat jou toe om alle Kubernetes YAML-lêers in git-bewaarplekke te hou, sodat jy presies kan opspoor wanneer 'n verandering gemaak is, wie dit gemaak het en wat presies verander het. Dit verhoog die deursigtigheid van bedrywighede regdeur die organisasie en verbeter bedryfsdoeltreffendheid deur onduidelikheid uit te skakel, veral oor waar werknemers die hulpbronne moet soek wat hulle benodig. Terselfdertyd word dit makliker om outomaties veranderinge aan Kubernetes-hulpbronne aan te bring deur bloot 'n trekversoek saam te voeg.
- Skaalbaarheid. Wanneer hulpbronne as YAML gedefinieer word, word dit uiters maklik vir groepoperateurs om een of twee getalle in 'n Kubernetes-hulpbron te verander, en sodoende te verander hoe dit skaal. Kubernetes verskaf 'n meganisme vir horisontale outoskaling van peule, wat gebruik kan word om gerieflik te bepaal wat die minimum en maksimum aantal peule benodig word in 'n spesifieke ontplooiingskonfigurasie om lae en hoë vlakke van verkeer te hanteer. Byvoorbeeld, as jy 'n konfigurasie ontplooi het wat addisionele kapasiteit vereis as gevolg van 'n skielike toename in verkeer, dan kan maxReplicas verander word van 10 na 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- Sekuriteit en bestuur. YAML is wonderlik om te evalueer hoe dinge in Kubernetes ontplooi word. Byvoorbeeld, 'n groot sekuriteitsprobleem is of jou werkladings as 'n nie-administrateurgebruiker loop. In hierdie geval kan ons gereedskap benodig soos , YAML/JSON valideerder, plus , 'n beleidsvalideerder om te verseker dat die konteks jou werkladings laat nie toe dat die houer met administrateurvoorregte loop nie. Indien dit vereis word, kan gebruikers 'n eenvoudige beleid toepas , soos hierdie:
package main
deny[msg] {
input.kind = "Deployment"
not input.spec.template.spec.securityContext.runAsNonRoot = true
msg = "Containers must not run as root"
}- Opsies vir integrasie met 'n wolkverskaffer. Een van die mees noemenswaardige neigings in vandag se hoë tegnologie is om werkladings op openbare wolkverskaffers uit te voer. Die gebruik van die komponent Kubernetes laat enige groepering toe om te integreer met die wolkverskaffer waarop dit loop. Byvoorbeeld, as 'n gebruiker 'n toepassing in Kubernetes op AWS bestuur en daardie toepassing deur 'n diens wil blootstel, help die wolkverskaffer om die diens outomaties te skep
LoadBalancerwat outomaties die lasbalanseerder sal verskaf om verkeer na toepassingpeule te herlei.
Uitbreidbaarheid
Kubernetes is baie uitbreidbaar en ontwikkelaars is mal daaroor. Daar is 'n stel beskikbare hulpbronne soos peule, ontplooiings, StatefulSets, geheime, ConfigMaps, ens. Dit is waar, gebruikers en ontwikkelaars kan ander hulpbronne in die vorm byvoeg .
Byvoorbeeld, as ons 'n hulpbron wil definieer CronTab, dan kan jy iets soos hierdie doen:
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
Later kan ons 'n CronTab-hulpbron so iets skep:
apiVersion: "my.org/v1"
kind: CronTab
metadata:
name: my-cron-object
spec:
cronSpec: "* * * * */5"
image: my-cron-image
replicas: 5
Nog 'n opsie vir uitbreidbaarheid in Kubernetes is dat die ontwikkelaar sy eie stellings kan skryf. is 'n spesiale proses in die Kubernetes-kluster wat volgens die "" Met die hulp van 'n operateur kan die gebruiker die bestuur van CRD's (pasgemaakte hulpbrondefinisies) outomatiseer deur inligting met die Kubernetes API uit te ruil.
Daar is verskeie nutsmiddels in die gemeenskap wat dit vir ontwikkelaars maklik maak om hul eie operateurs te skep. Tussen hulle - en . Hierdie SDK bied 'n grondslag waaruit 'n ontwikkelaar vinnig 'n operateur kan begin skep. Kom ons sê jy kan iets soos hierdie vanaf die opdragreël begin:
$ operator-sdk new my-operator --repo github.com/myuser/my-operatorDit skep al die boilerplate-kode vir jou operateur, insluitend YAML-lêers en Golang-kode:
.
|____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.goDan kan jy die vereiste API's en kontroleerder soos volg byvoeg:
$ operator-sdk add api --api-version=myapp.com/v1alpha1 --kind=MyAppService
$ operator-sdk add controller --api-version=myapp.com/v1alpha1 --kind=MyAppServiceDan, uiteindelik, versamel die operateur en stuur dit na die register van jou houer:
$ operator-sdk build your.container.registry/youruser/myapp-operator
As die ontwikkelaar nog meer beheer wil hê, kan die boilerplate-kode in Go-lêers verander word. Byvoorbeeld, om die besonderhede van die kontroleerder te verander, kan jy veranderinge aan die lêer maak controller.go.
Nog 'n projek , laat jou toe om stellings te skep deur slegs verklarende YAML-lêers te gebruik. Byvoorbeeld, 'n operateur vir Apache Kafka sal ongeveer gedefinieer word . Daarmee kan u 'n Kafka-kluster bo-op Kubernetes installeer met slegs 'n paar opdragte:
$ kubectl kudo install zookeeper
$ kubectl kudo install kafkaEn stel dit dan op met 'n ander opdrag:
$ 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
innovasies
Oor die afgelope paar jaar het groot Kubernetes-vrystellings elke paar maande verskyn - dit wil sê drie tot vier groot vrystellings per jaar. Die aantal nuwe kenmerke wat in elk van hulle bekendgestel word, neem nie af nie. Boonop is daar geen tekens van verlangsaming selfs in hierdie moeilike tye nie – kyk wat is die situasie nou .
Nuwe vermoëns laat jou toe om bedrywighede meer buigsaam oor diverse werkladings te groepeer. Boonop geniet programmeerders groter beheer wanneer toepassings direk na produksie ontplooi word.
Gemeenskap
Nog 'n belangrike aspek van Kubernetes se gewildheid is die sterkte van sy gemeenskap. In 2015, met die bereiking van weergawe 1.0, is Kubernetes geborg deur .
Daar is ook verskeie gemeenskappe (Spesiale Belangegroepe) het daarop gefokus om op verskillende areas van Kubernetes te werk soos die projek ontwikkel. Hierdie groepe voeg voortdurend nuwe kenmerke by, wat die werk met Kubernetes geriefliker en geriefliker maak.
Die Cloud Native-stigting huisves ook CloudNativeCon/KubeCon, wat ten tyde van die skryf hiervan die grootste oopbronkonferensie ter wêreld is. Dit word tipies drie keer per jaar gehou en bring duisende professionele persone bymekaar wat Kubernetes en sy ekosisteem wil verbeter, asook nuwe kenmerke wil leer wat elke drie maande verskyn.
Boonop het Cloud Native Foundation , wat saam met SIG's nuwe en bestaande hersien fondse gefokus op die wolk-ekosisteem. Die meeste van hierdie projekte help om die sterk punte van Kubernetes te verbeter.
Ten slotte glo ek dat Kubernetes nie so suksesvol sou wees as wat dit is sonder die doelbewuste pogings van die hele gemeenskap, waar mense saamstaan maar terselfdertyd nuwelinge in die groep verwelkom nie.
Die toekoms
Een van die hoofuitdagings wat ontwikkelaars in die toekoms sal moet hanteer, is die vermoë om op die besonderhede van die kode self te fokus, en nie op die infrastruktuur waarin dit loop nie. Dit voldoen aan hierdie tendense , wat vandag een van die voorste is. Gevorderde raamwerke bestaan reeds, bv. и , wat Kubernetes gebruik om die infrastruktuur van die ontwikkelaar te onttrek.
In hierdie artikel het ons net die oppervlak van die huidige toestand van Kubernetes gekrap—in werklikheid is dit net die punt van die ysberg. Kubernetes-gebruikers het baie ander hulpbronne, vermoëns en konfigurasies tot hul beskikking.
Bron: will.com