Hello, Habr!
Na koncu poletja želimo spomniti, da še naprej delamo na tej temi in smo se odločili objaviti članek iz Stackoverflow, ki prikazuje stanje projekta na začetku junija.
Uživajte v branju!
Ob pisanju tega članka starost Kubernetesa znaša približno , in v zadnjih dveh letih je njegova priljubljenost narasla do te mere, da je dosledno med platformami. Ta leto Kubernetes zaseda tretje mesto. Spomnimo: Kubernetes je platforma, namenjena zagonu in orkestraciji kontejnerskih delovnih obremenitev.
Kontejnerji so se razvili kot posebna struktura za izolacijo procesov v Linuxu; v kontejnerje od leta 2007 spadajo , od leta 2002 pa tudi imenska prostora. Kontejnerji so se še bolje oblikovali leta 2008, ko je postala na voljo , Google pa je razvil svoj notranji mehanizem, imenovan , kjer „vsa dela potekajo v kontejnerjih“. Potem se vrnemo v leto 2013, ko je izšel prvi Docker, in so kontejnerji končno prešli v razred priljubljenih množičnih rešitev. Takrat je bil glavna orodje za orkestracijo kontejnerjev , čeprav ni užival velike priljubljenosti. Prvi izid Kubernetesa je bil leta 2015, po katerem je to orodje dejansko postalo standard na področju orkestracije kontejnerjev.
Da bi poskušali razumeti, zakaj je Kubernetes tako priljubljen, poskusimo odgovoriti na nekaj vprašanj. Kdaj so se zadnjič razvijalci uspeli dogovoriti o tem, kako uvajati aplikacije v produkcijo? Koliko poznate razvijalcev uporablja orodja v obliki, kot jih ponujajo „iz škatle“? Koliko danes poznaš oblačnih administratorjev, ki ne razumejo, kako delujejo aplikacije? Odgovore na ta vprašanja bomo obravnavali v tem članku.
Infrastruktura kot YAML
V svetu, ki se je od Puppet in Chef preusmeril k Kubernetesu, je bila ena največjih sprememb prehod od „infrastrukture kot kode“ k „infrastrukturi kot podatkom“ — natančneje, kot YAML. Vse vire v Kubernetesu, ki obsegajo pod-e, konfiguracije, nameščene instance, volume itd., je mogoče enostavno opisati v YAML datoteki. Na primer:
apiVersion: v1
kind: Pod
metadata:
name: site
labels:
app: web
spec:
containers:
- name: front-end
image: nginx
ports:
- containerPort: 80S takim predstavitvijo je strokovnjakom za DevOps ali SRE lažje popolnoma izraziti svoje delovne obremenitve, ne da bi morali pisati programsko kodo v jezikih, kot sta Python ali Javascript.
Druge prednosti organizacije infrastrukture kot podatkov so naslednje:
- GitOps ali nadzor različic Git Operations Version. Takšen pristop omogoča, da so vsi YAML-datoteke Kubernetes v git repozitorijih, kar vam omogoča natančno sledenje spremembam, kdo je to spremembo izvedel in kaj je bilo spremenjeno. To povečuje preglednost operacij v celotni organizaciji, povečuje učinkovitost dela, ker odpravlja nejasnosti, zlasti pri iskanju potrebnih virov. Hkrati postane lažje samodejno uvajati spremembe v vire Kubernetes – z običajnim združevanjem pull-ponud.
- Razširljivost. Ko so viri definirani v obliki YAML, je operaterjem klastru izjemno enostavno spremeniti eno ali dve številki v viru Kubernetes, s čimer spremenijo pravila za njegovo razširitev. Kubernetes vključuje mehanizem za horizontalno samodejno razširitev podov, ki omogoča enostavno določanje, kakšno je minimalno in maksimum število podov, potrebnih v določeni nameščeni konfiguraciji, da se spopadejo z nizkim in visokim nivojem prometa. Na primer, če ste namestili konfiguracijo, ki zahteva dodatno zmogljivost zaradi nenadnega povečanja prometa, lahko spremeniš parameter maxReplicas z 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- Varnost in upravljanje. YAML je odličen za ocenjevanje, kako so določene stvari nameščene v Kubernetes. Na primer, resna težava, povezana z zagotavljanjem varnosti, se nanaša na to, ali se vaše delovne obremenitve izvajajo pod uporabnikom, ki nima skrbniških pravic. V tem primeru so lahko koristna orodja, kot so , validator YAML/JSON, plus , validator politik, ki omogoča, da se prepričate, da je kontekst delovne obremenitve ne dovoljujejo, da bi kontejner deloval s skrbniškimi pravicami. Če je to potrebno, lahko uporabniki uporabijo preprost pravilnik. , tako:
package main
deny[msg] {
input.kind = "Deployment"
not input.spec.template.spec.securityContext.runAsNonRoot = true
msg = "Kontejnerji ne smejo delovati kot root"
}- Možnosti integracije z oblačnim ponudnikom. Ena najbolj očitnih trendov v sodobnih visoko tehnoloških rešitvah je zagon delovnih obremenitev na virih javnih oblačnih ponudnikov. S komponento Kubernetes omogoča vsakemu klastru, da se integrira z oblačnim ponudnikom, s katerim deluje. Na primer, če uporabnik zažene aplikacijo v Kubernetesu na AWS in želi odpreti dostop do te aplikacije preko storitve, cloud provider samodejno pomaga pri ustvarjanju storitve
LoadBalancer, ki samodejno zagotovi uravnoteževalnik obremenitve , da preusmeri promet v pod aplikacij.
Scalability
Kubernetes se zelo dobro razširja, kar je razvijalcem všeč. Na voljo je sklop obstoječih virov, kot so podi, razporeditve, StatefulSets, skrivnosti, ConfigMaps, itd. V resnici pa lahko uporabniki in razvijalci dodajajo tudi druge vire v obliki .
Na primer, če želimo opredeliti vir CronTab, bi lahko naredili nekaj takega:
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
Kasneje lahko ustvarimo vir CronTab približno na naslednji način:
apiVersion: "my.org/v1"
kind: CronTab
metadata:
name: my-cron-object
spec:
cronSpec: "* * * * */5"
image: my-cron-image
replicas: 5
Še ena možnost razširljivosti v Kubernetesu je, da lahko razvijalec piše svoje lastne operaterje. je poseben proces v klastru Kubernetes, ki deluje po vzorcu "". S pomočjo operaterja lahko uporabnik avtomatizira upravljanje CRD (lastne opredelitve virov), izmenjuje informacije z Kubernetes API.
V skupnosti je nekaj orodij, s katerimi lahko razvijalci enostavno ustvarijo svoje lastne operaterje. Med njimi je і його . Ta SDK nudi osnovo, na kateri lahko razvijalec zelo hitro začne s kreiranjem operaterja. Recimo, da lahko začnete iz ukazne vrstice takole:
$ operator-sdk new my-operator --repo github.com/myuser/my-operatorTako se ustvari celotna stereotipna koda za vašega operaterja, vključno z datotekami YAML in kodo v Golangu:
.
|____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.goNato lahko dodate potrebne API-je in kontroler, takole:
$ operator-sdk add api --api-version=myapp.com/v1alpha1 --kind=MyAppService
$ operator-sdk add controller --api-version=myapp.com/v1alpha1 --kind=MyAppServiceNato pa končno zgradite operaterja in ga pošljete v register vašega kontejnerja:
$ operator-sdk build your.container.registry/youruser/myapp-operator Če razvijalec potrebuje še večji nadzor, lahko spremeni stereotipno kodo v datotekah na Go. Na primer, za prilagoditev specifikacije kontrolerja lahko spremenite datoteko controller.go.
Drugi projekt, , omogoča ustvarjanje operaterjev zgolj z deklarativnimi datotekami YAML. Na primer, operater za Apache Kafko bi bil opredeljen približno tako . Z njegovim pomočjo lahko v le nekaj ukazih namestite Kafka grozd na Kubernetes:
$ kubectl kudo install zookeeper
$ kubectl kudo install kafkaIn nato ga konfigurirate z enim samim ukazom:
$ 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
Inovacije
V zadnjih nekaj letih velike različice Kubernetes izhajajo vsakih nekaj mesecev – torej tri do štiri velike različice na leto. Število novih funkcij, ki se uvajajo v vsaki od njih, se ne zmanjšuje. Poleg tega ni opaziti znakov upočasnjevanja niti v naših težkih časih – poglejte, kakšna je sedaj .
Nova orodja omogočajo bolj prilagodljivo klasterizacijo operacij pri raznolikih delovnih obremenitvah. Poleg tega programerjem nudi večji nadzor pri uvajanju aplikacij neposredno v produkcijo.
Skupnost
Še en resen vidik priljubljenosti Kubernetes je moč njegove skupnosti. Leta 2015, ko je dosegel različico 1.0, je bil sponzoriran .
Obstajajo tudi različne skupnosti (posebne interesne skupine), ki se osredotočajo na raziskovanje različnih področij Kubernetes, medtem ko se projekt razvija. Te skupine nenehno dodajajo nove funkcionalnosti, kar pomeni, da je delo s Kubernetes vse prijetnejše.
Fundacija Cloud Native Foundation organizira tudi CloudNativeCon/KubeCon, ki je ob pisanju tega besedila največja konferenca z odprto kodo na svetu. Običajno se odvija trikrat na leto in zbere na tisoče strokovnjakov, ki želijo izboljšati Kubernetes in njegovo ekosistem ter osvojiti nove funkcionalnosti, ki se pojavljajo vsake tri mesece.
Poleg tega ima Cloud Native Foundation , ki skupaj s SIG-ji pregleduje nove in obstoječe fundacije, ki so usmerjeni v oblačno ekosistem. Večina teh projektov pomaga krepiti prednosti Kubernetes.
Na koncu verjamem, da Kubernetes ne bi dosegel takšnega uspeha brez zavestnih prizadevanj celotne skupnosti, kjer si ljudje medsebojno pomagajo, hkrati pa z veseljem sprejemajo novince.
Prihodnost
Eden od glavnih izzivov, s katerimi se bodo razvijalci morali spoprijeti v prihodnosti, je sposobnost osredotočanja na podrobnosti samega kode in ne infrastrukture, v kateri deluje. Natančno tem trendom ustreza , ki danes velja za eno izmed vodilnih. Že obstajajo napredni okviri, kot je in , ki uporabljajo Kubernetes za abstrakcijo infrastrukture od razvijalca.
V tem članku smo le na splošno obravnavali trenutno stanje Kubernetes – v resnici je to le vrh ledene gore. Uporabniki Kubernetes imajo na voljo še številne druge vire, možnosti in konfiguracije.
Izvor: habr.com
