Kubernetese kasvavast populaarsusest

Tere Habr!

Suve lõpus tahame teile meelde tuletada, et jätkame teemaga tööd Kubernetes ja otsustas juuni alguses avaldada Stackoverflow artikli, mis demonstreerib selle projekti olukorda.

Nautige lugemist!

Selle artikli kirjutamise ajal on Kubernetese vanus u. kuueaastane, ja viimase kahe aasta jooksul on selle populaarsus nii palju kasvanud, et see on järjekindlalt selle hulgas kõige lemmikum platvormid. Kubernetes on tänavu kolmandal kohal. Kokkuvõtteks: Kubernetes on platvorm, mis on loodud konteinerite töökoormuste käitamiseks ja korraldamiseks.

Konteinerid said alguse Linuxi protsesside isoleerimiseks mõeldud erikujundusest; konteinerid on sisaldanud alates 2007. aastast rühmad, ja aastast 2002 – nimeruumid. Konteinerid kujundati veelgi paremini 2008. aastaks, mil see kättesaadavaks sai LXC, ja Google töötas välja oma ettevõttesisese mehhanismi nimega Borg, kus "kõik tööd tehakse konteinerites". Siit liigume edasi 2013. aastasse, mil toimus Dockeri esimene väljalaskmine, ja lõpuks sai konteineritest populaarne masslahendus. Sel ajal oli konteineri orkestreerimise põhitööriist Mesos, kuigi ta polnud metsikult populaarne. Kubernetes ilmus esmakordselt 2015. aastal, pärast mida sai sellest tööriistast konteinerite orkestreerimise alal de facto standard.

Et mõista, miks Kubernetes on nii populaarne, proovime vastata mõnele küsimusele. Millal suutsid arendajad viimati kokku leppida, kuidas rakendusi tootmisse juurutada? Kui paljusid arendajaid teate, kes kasutavad tööriistu nii, nagu need karbist välja antakse? Kui palju on tänapäeval pilveadministraatoreid, kes ei mõista, kuidas rakendused töötavad? Vaatleme selles artiklis vastuseid neile küsimustele.

Taristu nagu YAML

Maailmas, mis läks Puppetist ja Chefist Kubernetesesse, oli üks suurimaid muudatusi üleminek "infrastruktuurilt kui koodile" "infrastruktuurile kui andmetele" - täpsemalt nagu YAML. Kõiki Kubernetese ressursse, sealhulgas kaustasid, konfiguratsioone, juurutatud eksemplare, köiteid 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: 80

See vaade muudab DevOpsi või SRE spetsialistide jaoks lihtsamaks oma töökoormuse täieliku väljendamise, ilma et nad peaksid koodi kirjutama sellistes keeltes nagu Python või Javascript.

Infrastruktuuri andmetena korraldamise eelised on järgmised:

• GitOpsi või Git Operationsi versioonikontroll. See lähenemisviis võimaldab hoida kõiki Kubernetes YAML-faile git-hoidlates, et saaksite täpselt jälgida, millal muudatus tehti, kes selle tegi ja mis täpselt muutus. See suurendab tegevuse läbipaistvust kogu organisatsioonis ja parandab tegevuse tõhusust, kõrvaldades ebaselgused, eriti seal, kus töötajad peaksid otsima vajalikke ressursse. Samal ajal muutub Kubernetese ressursside automaatne muutmine lihtsamaks, ühendades lihtsalt tõmbamistaotluse.
• Skaleeritavus. Kui ressursid on määratletud kui YAML, on klastrioperaatoritel äärmiselt lihtne muuta Kubernetese ressursis ühte või kahte numbrit, muutes seeläbi selle skaleerimist. Kubernetes pakub mehhanismi kaubikute horisontaalseks automaatseks skaleerimiseks, mille abil saab mugavalt määrata, milline minimaalne ja maksimaalne kaustade arv on konkreetses juurutuskonfiguratsioonis nõutav madala ja suure liiklusega toimetulemiseks. Näiteks kui olete juurutanud konfiguratsiooni, mis nõuab liikluse äkilise hüppe tõttu lisavõimsust, saab maxReplicas 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 juhtimine. YAML sobib suurepäraselt Kubernetesis asjade juurutamise hindamiseks. Näiteks on suur turbeprobleem seotud sellega, kas teie töökoormused töötavad administraatorivaba kasutajana. Sel juhul võime vajada selliseid tööriistu nagu võistlus, YAML/JSON validaator, pluss Avatud poliitikaagent, poliitika valideerija, mis tagab konteksti Turvakontekst teie töökoormused ei luba konteineril administraatoriõigustega käitada. Kui see on vajalik, saavad kasutajad rakendada lihtsat poliitikat ma palvetan, nagu nii:

package main

deny[msg] {
  input.kind = "Deployment"
  not input.spec.template.spec.securityContext.runAsNonRoot = true
  msg = "Containers must not run as root"
}

• Pilveteenuse pakkujaga integreerimise võimalused. Tänapäeva kõrgtehnoloogia üks silmapaistvamaid suundumusi on avalike pilveteenuse pakkujate töökoormuste käitamine. Komponenti kasutamine pilvepakkuja Kubernetes võimaldab igal klastril integreeruda pilveteenuse pakkujaga, millel see töötab. Näiteks kui kasutaja käitab rakendust Kubernetesis AWS-is ja soovib seda rakendust teenuse kaudu avalikustada, aitab pilveteenuse pakkuja teenuse automaatselt luua. LoadBalancermis tagab automaatselt koormuse tasakaalustaja Amazon elastne koormuse tasakaalustajaliikluse ümbersuunamiseks rakenduste kaustadesse.

Laiendatavus

Kubernetes on väga laiendatav ja arendajatele see meeldib. Saadaval on hulk ressursse, nagu kaustad, juurutused, StatefulSets, saladused, ConfigMaps, jne. Tõsi, kasutajad ja arendajad saavad vormile lisada muid ressursse kohandatud ressursside määratlused.

Näiteks kui tahame ressurssi määratleda CronTab, siis võiksite 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 sellise CronTabi ressursi:

apiVersion: "my.org/v1"
kind: CronTab
metadata:
  name: my-cron-object
spec:
  cronSpec: "* * * * */5"
  image: my-cron-image
  replicas: 5

Teine võimalus Kubernetese laiendamiseks on see, et arendaja saab kirjutada oma avaldusi. Operaator on Kubernetese klastris spetsiaalne protsess, mis töötab vastavalt "juhtimisahel" Kasutaja saab operaatori abiga automatiseerida CRD-de (custom resource definitions) haldamist, vahetades Kubernetes API-ga infot.

Kogukonnas on mitu tööriista, mis hõlbustavad arendajatel oma operaatorite loomist. Nende hulgas - Operaatori raamistik ja Operaator SDK. See SDK annab aluse, millest arendaja saab kiiresti alustada operaatori loomist. Oletame, et saate alustada käsurealt midagi sellist:

$ operator-sdk new my-operator --repo github.com/myuser/my-operator

See loob teie operaatori jaoks kogu standardkoodi, sealhulgas YAML-failid ja Golangi koodi:

.
|____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.go

Seejärel saate lisada vajalikud API-d ja kontrolleri, näiteks järgmiselt:

$ operator-sdk add api --api-version=myapp.com/v1alpha1 --kind=MyAppService

$ operator-sdk add controller --api-version=myapp.com/v1alpha1 --kind=MyAppService

Seejärel pange lõpuks kokku operaator ja saatke see oma konteineri registrisse:

$ operator-sdk build your.container.registry/youruser/myapp-operator

Kui arendaja soovib veelgi suuremat kontrolli, saab Go-failide standardkoodi muuta. Näiteks kontrolleri eripärade muutmiseks saate failis muudatusi teha controller.go.

Teine projekt kÕIKJAL, võimaldab teil luua avaldusi, kasutades ainult deklaratiivseid YAML-faile. Näiteks Apache Kafka operaator oleks defineeritud ligikaudu nii. Selle abil saate Kubernetese peale installida Kafka klastri vaid paari käsuga:

$ kubectl kudo install zookeeper
$ kubectl kudo install kafka

Ja seejärel konfigureerige see teise 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

Innovatsioon

Viimase paari aasta jooksul on suuremad Kubernetese väljaanded ilmunud iga paari kuu tagant – see tähendab kolm kuni neli suuremat väljalaset aastas. Igas neist kasutusele võetud uute funktsioonide arv ei vähene. Pealegi pole isegi praegusel raskel ajal märke aeglustumisest – vaadake, mis olukord praegu on Kubernetese projektitegevus Githubis.

Uued võimalused võimaldavad teil toiminguid paindlikumalt rühmitada erinevate töökoormustega. Lisaks on programmeerijatel suurem kontroll rakenduste otse tootmisse juurutamisel.

Kogukond

Kubernetese populaarsuse teine ​​oluline aspekt on selle kogukonna tugevus. 2015. aastal, kui jõudis versioonini 1.0, sponsoreeris Kubernetes Cloud Native Computing Foundation.

Samuti on olemas erinevad kogukonnad SIG (Special Interest Groups) keskendus Kubernetese erinevate valdkondadega töötamisele projekti arenedes. Need rühmad lisavad pidevalt uusi funktsioone, muutes Kubernetesiga töötamise mugavamaks ja mugavamaks.

Cloud Native Foundation korraldab ka CloudNativeCon/KubeConi, mis on selle artikli kirjutamise ajal suurim avatud lähtekoodiga konverents maailmas. Tavaliselt toimub see kolm korda aastas ja see toob kokku tuhandeid spetsialiste, kes soovivad Kubernetest ja selle ökosüsteemi täiustada ning õppida uusi funktsioone, mis ilmuvad iga kolme kuu tagant.

Lisaks on Cloud Native Foundationil Tehnilise järelevalve komitee, mis koos SIG-idega vaatab üle uued ja olemasolevad Projektid pilveökosüsteemile keskendunud fondid. Enamik neist projektidest aitab parandada Kubernetese tugevusi.

Lõpetuseks usun, et Kubernetes ei oleks nii edukas kui kogu kogukonna teadlike pingutusteta, kus inimesed hoiavad kokku, kuid samas tervitavad uusi tulijaid.

Tulevik

Üks peamisi väljakutseid, millega arendajad peavad tulevikus tegelema, on võime keskenduda koodi enda üksikasjadele, mitte infrastruktuurile, milles see töötab. See vastab nendele suundumustele serverita arhitektuuriparadigma, mis on tänapäeval üks juhtivaid. Täiustatud raamistikud on juba olemas, nt. Knatiivne и OpenFaas, mis kasutavad Kubernetesi infrastruktuuri arendajast eraldamiseks.

Selles artiklis oleme vaid kriimustanud Kubernetese praeguse seisu pinda – tegelikult on see vaid jäämäe tipp. Kubernetese kasutajate käsutuses on palju muid ressursse, võimalusi ja konfiguratsioone.

Allikas: www.habr.com