Kubernetes'e kasvav populaarsus

Tere, Habr!

Suve lõpus tahame meenutada, et jätkame teema käsitlemist Kubernetes ja otsustasime avaldada Stackoverflow artikli, mis demonstreerib projekti hetkeseisu juuni alguses.

Head lugemist!

Käesoleva artikli kirjutamise ajal on Kubernetes umbes kuus aastat vana, ja viimase kahe aasta jooksul on tema populaarsus kasvanud nii, et ta on pidevalt olnud üheks kõige armastatumaks 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 cgroups, ja alates 2002. aastast – nimitsoonid. Konteinerid hakkasid veelgi paremini välja kujunema 2008. aastaks, kui said kätte LXC, ja Google töötas välja oma sisemised mehhanismid nimega Borg, 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 Mesos, 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: 80

Sellise 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 conftest, YAML/JSON valideerija, pluss Open Policy Agent, poliitikate valideerija, mis aitab veenduda, et kontekst SecurityContext teie töökoormuste jaoks ei võimalda konteineril töötada administraatori õigustes. Kui see on vajalik tagada, saavad kasutajad rakendada lihtsat poliitikat rego, 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 cloud-provider 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 Amazon Elastic Load Balancer, 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 kohandatud ressurside määratlemisi.

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. Operaator on eriline protsess Kubernetes klastris, mis töötab „kontrollvoona“. 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 — Operator Framework ja selle Operator SDK. 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-operator

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

Seejä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=MyAppService

Pä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, KUDO, võimaldades luua operaattoreid, kasutades ainult deklaratiivseid YAML-faile. Näiteks määratletakse Apache Kafka operaator umbes nii. Selle abil saab vaid paari käsuga instalarida Kafka kluster Kubernetes'i peale:

$ kubectl kudo install zookeeper
$ kubectl kudo install kafka

Ja 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 Kubernetes'i projekti tegevus Githubis.

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 Cloud Native Computing Foundation.

Eksisteerivad ka mitmed kogukonnad SIG (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 Tehnilise Järelevalve Komitee, mis koos SIGidega hindab uusi ja olemasolevaid projekte 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 serveriteta arhitektuuri paradigma, mis on täna üks juhtivaid. Juba on olemas arenenud raamistikud, näiteks Knative ja OpenFaas, 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