Tere, Habr!
Suve lõpus tahame meenutada, et jätkame teema käsitlemist ja otsustasime avaldada Stackoverflow artikli, mis demonstreerib projekti hetkeseisu juuni alguses.
Head lugemist!
Käesoleva artikli kirjutamise ajal on Kubernetes umbes , ja viimase kahe aasta jooksul on tema populaarsus kasvanud nii, et ta on pidevalt olnud platvormiks. Sel aastal on Kubernetes kolmandal kohal. Meenutame: Kubernetes on platvorm, mis on mõeldud konteinerite töökoormuste käivitamiseks ja orkestreerimiseks.
Konteinerid tekkisid kui spetsiaalne konstruktsioon protsesside isoleerimiseks Linuxis; konteinerite koosseisus on alates 2007. aastast , ja alates 2002. aastast – nimitsoonid. Konteinerid hakkasid veelgi paremini välja kujunema 2008. aastaks, kui said kätte , ja Google töötas välja oma sisemised mehhanismid nimega , kus "kogu töö toimub konteinerites". Siit liigume 2013. aastasse, kui toimus esimene Docker'i väljaanne, ja konteinerid muutusid tõeliselt populaarseks massilahenduseks. Toona oli peamine tööriist konteinerite orkestreerimiseks , kuigi, ta ei olnud hullult populaarne. Kubernetes'i esimene väljaanne toimus 2015. aastal, pärast mida sai see tööriist de facto konteinerite orkestreerimise standardiks.
Katsume mõista, miks Kubernetes on nii populaarne, vastates mõnele küsimusele. Millal viimati suudeti arendajatel kokku leppida, kuidas rakendusi tootmises käivitada? Kui palju te teate arendajatest, kes kasutavad tööriistu täpselt sellisena, nagu need „kastist välja” pakutakse? Kui palju on täna selliseid pilvehaldurid, kes ei mõista, kuidas rakendused töötavad? Toome nendele küsimustele vastused välja selles artiklis.
Infrastruktuur YAML-ina
Maailmas, mis tuli Puppet'ist ja Chef'ist Kubernetes'eni, oli üks suurimaid muudatusi üleminek "infrastruktuurist koodina" "infrastruktuuri andmetena" — nimelt YAML-ina. Kõiki ressursse Kubernetes’is, sealhulgas pod’id, konfiguratsioonid, juurutatud eksemplarid, mahud jne, saab hõlpsasti kirjeldada YAML-failis. Näiteks:
apiVersion: v1
kind: Pod
metadata:
name: site
labels:
app: web
spec:
containers:
- name: front-end
image: nginx
ports:
- containerPort: 80Sellise esitluse korral on DevOpi või SRE spetsialistidel mugavam oma töökoormusi täielikult väljendada, ilma vajaduseta kirjutada programmkoodi sellistes keeltes nagu Python või Javascript.
Muud andmete infrastruktuuri korraldamise eelised on järgmised:
- GitOps ehk versioonihaldus Git Operations Version. See lähenemine võimaldab hoida kõik Kubernetes YAML-failid git-repositooriumites, tänu millele saate täpselt jälgida, millal muudatus tehti, kes selle tegi ja mis täpselt muutus. See suurendab organisatsiooni tegevuste läbipaistvust ning tõhusust, vähendades ebamugavust, sealhulgas selles osas, kus töötajad peavad vajalikke ressursse otsima. Samuti muutub Kubernetes'i ressursside automaatsete muudatuste tegemine lihtsamaks - tavapärase pull-iga sulandumise teel.
- Skaleeritavus. Kui ressursid on määratletud YAML-vormingus, on klastrite operaatoritele äärmiselt lihtne muuta ühte või kahte numbrit Kubernetes'i ressursis, muutes sellega selle skaleerimise põhimõtteid. Kubernetes pakub mehaanikat podide horisontaalse automaatse skaleerimise jaoks, mille abil on mugav kindlaks määrata, kui palju on minimaalset ja maksimaalset podide arvu, mida antud rakenduse seadistuse jaoks on vaja, et toime tulla madala ja kõrge liiklusastmega. Näiteks kui olete juuranud seadistuse, mis vajab äkilise liiklusetõusu tõttu täiendavaid ressursse, võite maxReplicase väärtust muuta 10-lt 20-le:
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- Turvalisus ja haldus. YAML sobib suurepäraselt hindama, kuidas teatud asjad Kuberneteses rakenduvad. Näiteks on tõsine probleem, mis puudutab turvalisust, see, kas teie töökoormused käivituvad mitteadministraatori õigustega kasutaja alt. Sel juhul võivad osutuda kasulikeks sellised tööriistad nagu , YAML/JSON valideerija, pluss , poliitikate valideerija, mis aitab veenduda, et kontekst teie töökoormuste jaoks ei võimalda konteineril töötada administraatori õigustes. Kui see on vajalik tagada, saavad kasutajad rakendada lihtsat poliitikat , nii:
package main
deny[msg] {
input.kind = "Deployment"
not input.spec.template.spec.securityContext.runAsNonRoot = true
msg = "Konteinerid ei tohi käivituda root'i alt"
}- Integreerimisvõimalused Pilveteenuse Pakkujaga. Üks silmatorkavamaid suundi tänapäeva kõrge tehnoloogia valdkonnas on käivitada töökoormused avalike pilveteenuse pakkujate infrastruktuuril. Selleks kasutatakse komponenti Kubernetes võimaldab igal klastril integreeruda selle pilvepakkujaga, kus ta töötab. Näiteks kui kasutaja on käivitanud rakenduse Kuberneteses AWS-is ja soovib sellele rakendusele ligipääsu avada teenuse kaudu, aitab pilvepakkuja automaatselt luua teenuse
LoadBalancer, mis pakub automaatselt koormuse tasakaalustajat , et suunata liiklust rakenduse podidesse.
Skaleeritavus
Kubernetes on väga hästi skaleeritav, mis meeldib arendajatele. On olemas komplekt olemasolevatest ressurssidest, nagu podid, väljatööd, StatefulSets, saladused, ConfigMaps, jne. Tegelikult saavad kasutajad ja arendajad lisada ka teisi ressursse kujul .
Näiteks kui soovime määratleda ressursi CronTab, võiksime teha midagi sellist:
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
Hiljem saame luua CronTab ressursi umbes nii:
apiVersion: "my.org/v1"
kind: CronTab
metadata:
name: my-cron-object
spec:
cronSpec: "* * * * */5"
image: my-cron-image
replicas: 5
Kubernetesis on veel üks laiendatavuse võimalus, et arendaja saab kirjutada oma operaatorid. on eriline protsess Kubernetes klastris, mis töötab „“. Operaatori abil saab kasutaja automatiseerida CRD (kohandatud ressursside definitsioonide) haldamist, vahetades teavet Kubernetes API-ga.
Kogukonnas on mitmeid tööriistu, millega arendajad saavad mugavalt luua oma operaatorid. Nende seas on — ja selle . See SDK annab aluse, millele tuginedes saab arendaja väga kiiresti koos operaatori loomisega alustada. Näiteks võib alustada käsurealt umbes järgmiselt:
$ operator-sdk new my-operator --repo github.com/myuser/my-operatorNii luuakse kogu süstematiseeritud kood teie operaatori jaoks, sealhulgas YAML-failid ja Golangi kood:
.
|____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.goSeejärel saab lisada vajalikud API-d ja kontrolleri, näiteks:
$ operator-sdk add api --api-version=myapp.com/v1alpha1 --kind=MyAppService
$ operator-sdk add controller --api-version=myapp.com/v1alpha1 --kind=MyAppServicePärast seda saab lõpuks operaatori kokku panna ja selle teie konteineriregistrisse saata:
$ operator-sdk build your.container.registry/youruser/myapp-operator Kui arendaja vajab veelgi täielikku kontrolli, saab ta muuta süstematiseeritud koodi Go-failides. Näiteks, et muuta kontrolleri spetsiifikat, võib teha muudatusi failis controller.go.
Teine projekt, , võimaldades luua operaattoreid, kasutades ainult deklaratiivseid YAML-faile. Näiteks määratletakse Apache Kafka operaator umbes . Selle abil saab vaid paari käsuga instalarida Kafka kluster Kubernetes'i peale:
$ kubectl kudo install zookeeper
$ kubectl kudo install kafkaJa seejärel seadistada see veel ühe käsuga:
$ 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
Innovatsioonid
Viimase paariaasta jooksul on suured Kubernetes'i väljalasked toimunud iga paarikuud — see tähendab, kolm-neli suurt väljalaset aastas. Igaühes neist tutvustatakse järjest rohkem uusi funktsioone. Veelgi enam, signaale aeglustumisest ei ole isegi keerulistel aegadel — vaadake, kui suur on praegu .
Uued võimalused võimaldavad operatsioonide klasterdamist paindlikumalt erinevate koormuste olemasoluga. Lisaks meeldib arendajatele suurem kontroll rakenduste otse tootmisesse juurutamisel.
Kogukond
Kubernetesi populaarsuse üks tõsisemaid aspekte on selle kogukonna tugevus. 2015. aastal, kui versioon 1.0 tuli välja, toetas Kubernetes .
Eksisteerivad ka mitmed kogukonnad (huvigruppide erirühmad), mille eesmärk on süveneda Kubernetes erinevatesse valdkondadesse vastavalt projekti arengule. Need grupid lisavad pidevalt uusi funktsioone, mistõttu on Kubernetesega töötamine järjest lihtsam ja mugavam.
Cloud Native Foundation korraldab ka CloudNativeCon/KubeCon'i, mis on hetke seisuga maailman kõige suurem avatud lähtekoodiga konverents. Tavaline on, et see toimub kolm korda aastas ja kogub kokku tuhandeid professionaale, kes soovivad Kuberneteset ja selle ökosüsteemi parandada, samuti tutvuda uute võimalustega, mis ilmuvad iga kolme kuu tagant.
Lisaks on Cloud Native Foundationil , mis koos SIGidega hindab uusi ja olemasolevaid fondi, mis on suunatud pilveökosüsteemile. Enamik neist projektidest aitab parandada Kubernetes'i tugevusi.
Lõfinally, ma usun, et Kubernetes ei oleks saavutanud sellist edu ilma kogu kogukonna teadlike pingutusteta, kus inimesed toetavad üksteist, kuid samas võtavad rõõmuga vastu uusi liikmeid.
Tulevik
Üks peamisi väljakutseid, millega arendajad tulevikus silmitsi seisavad, on oskus keskenduda koodi detailidele, mitte sellele infrastruktuurile, kus see töötab. Just sellele suunale vastab , mis on täna üks juhtivaid. Juba on olemas arenenud raamistikud, näiteks ja , mis kasutavad Kubernetes'e, et abstraheerida infrastruktuur arendajast.
Selles artiklis käsitlesime me ainult üldiselt Kubernetes'e praegust olekut – tegelikult on see vaid jäämäe(tipp). Kubernetes'e kasutajatel on ka palju teisi ressursse, võimalusi ja konfiguratsioone.
Allikas: habr.com
