Kubernetesi kasvava populaarsuse kohta

Tere, Habr!

Suve lõpus tahame me meelde tuletada, et jätkame teema uurimist Kubernetes ja otsustasime avaldada Stackoverflowist artikli, mis demonstreerib projekti seisukorda juuni alguses.

Head lugemist!

Käesoleva artikli kirjutamise ajal on Kubernetes umbes kuus aastat vana, ja viimase kahe aasta jooksul on selle populaarsus kasvanud sedavõrd, et see on alaliselt kolm kõige armastatumat platvormi hulgas. Sel aastal on Kubernetes kolmandal kohal. Tuletame meelde: Kubernetes on platvorm, mis on mõeldud konteinerite töökoormuste käitamiseks ja orkestreerimiseks. Konteinerid tekkisid nagu eriline konstruktsioon protsesside isoleerimiseks Linuxis; konteinerite koosseisu kuuluvad alates 2007.

, ja alates 2002. aastast - nimelised ruumid. Konteinerid said veelgi paremini välja kujunenud 2008. aastaks, kui sai kergesti kätte cgroups, ja Google'is arendati välja oma sisemine mehhanism nimega LXCBorg , kus "kõik töö toimub konteinerites". Kutsume nüüd ajas edasi 2013. aastasse, kui toimus Docker'i esimene väljaanne, ja konteinerid said lõpuks populaarseteks massiliseks lahenduseks. Sel ajal oli peamine tööriist konteinerite orkestreerimiseksMesos , kuigi see ei olnud ülemääraselt populaarne. Kubernetes'e esimene väljaanne toimus 2015. aastal, pärast mida sai sellest de facto standard konteinerite orkestreerimise valdkonnas.Et proovida mõista, miks Kubernetes nii populaarne on, katsume vastata mõnele küsimusele. Millal viimati suudeti arendajatel kokku leppida, kuidas rakendusi tootmiselt välja lasta? Kui palju te teate arendajatest, kes kasutavad tööriistu just sellisel kujul, nagu need "karbist välja" antakse? Kui palju on täna selliseid pilve administraatoreid, kes ei mõista, kuidas rakendused töötavad? Nendele küsimustele anname vastuseid käesolevas artiklis.

Infrastruktuur kui YAML

Maailmas, mis on Puppet'ist ja Chef'ist liikunud Kubernetes'e juurde, on üks suurimaid muudatusi olnud üleminek "infrastruktuurist kui koodist" "infrastruktuuriks nagu andmed" — konkreetselt, nagu YAML. Kõiki Kubernetes'e ressursse, sealhulgas pod'e, konfiguratsioone, paigaldatud eksemplare, mahtusid 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

apiVersion: v1
kind: Pod
metadata:
  name: site
  labels:
    app: web
spec:
  containers:
    - name: front-end
      image: nginx
      ports:
        - containerPort: 80

Sellise lähenemise puhul on DevOps või SRE spetsialistidel lihtsam täielikult väljendada oma töökoormusi, ilma et peaks kirjutama programmeerimiskeelt nagu Python või Javascript.

Teised infrastruktuuri korraldamise eelised andmete osas on järgmised:

• GitOps või Git Operations versioonihaldus. 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 tõstab organisatsiooni tegevuste läbipaistvust ja parandab töö efektiivsust, vähendades ebaselgust seoses sellega, kus töötajad peavad otsima vajalikke ressursse. Samas muutub ka automaatne muutuste tegemine Kubernetesi ressurssides lihtsamaks, läbi tavalise pull-päringu sulandumise.
• Skaleeritavus. Kui ressursid on määratletud YAML-vormingus, on klastrite operaatoritel äärmiselt lihtne muuta ühte või kahte numbrit Kubernetesi ressursis, muutes sellega selle skaleerimise põhimõtteid. Kuberneteses on mehhanism horisontaalse automaatse skaleerimise jaoks, mille abil on mugav määrata, kui palju minimaalset ja maksimaalset podi on konkreetses juurutatud konfiguratsioonis vajalik madala ja kõrge liikluse taseme haldamiseks. Näiteks kui olete juurinud konfiguratsiooni, mis vajab täiendavaid ressursse liikluse järsu tõusu tõttu, saate maxReplicas näitajat 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 haldamine. YAML sobib suurepäraselt hindamiseks, kuidas teatud asju Kuberneteses juurutatakse. Näiteks tõsine turvalisusprobleem seisneb selles, kas teie töökoormused käivitatakse kasutaja poolt, kellel ei ole administreerimisõigusi. Sellisel juhul võivad meid aidata sellised tööriistad nagu conftest, YAML/JSON valideerija, pluss Open Policy Agent, poliitika valideerija, mis aitab veenduda, et kontekst SecurityContext teie töökoormused ei luba konteineril töötada administraatori õigustega. Kui see on vajalik, 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 töötada root õigustega"
}

• Integreerimisvõimalused pilveteenuse pakkujaga. Üks silmapaistvamaid suundi kaasaegses tehnoloogias on töökoormuste käitamine avalikes pilveteenuse pakkujate infrastruktuuris. Spetsiaalse komponente abil cloud-provider Kubernetes võimaldab igal klastril integreeruda selle pilveteenuse pakkujaga, millel see töötab. Näiteks kui kasutaja käivitab rakenduse Kubernetes AWS-is ja soovib sellele rakendusele avada juurdepääsu teenuse kaudu, siis pilveteenuse pakkuja aitab automaatselt luua teenuse LoadBalancer, mis automaatset genereerib koormuse tasakaalustaja Amazon Elastic Load Balancer, et suunata liiklus rakenduste podidesse.

Laaditavus

Kubernetes on väga hästi laienev, mis meeldib arendajatele. On olemas loetelu olemasolevatest ressurssidest, nagu podid, juurutused, StatefulSets, salajased andmed, ConfigMaps, jne. Tõsi, kasutajad ja arendajad saavad lisada ka teisi ressursse kujul kasutaja määratletud ressurssidest.

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 umbkaudu selliselt:

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

Teine Kubernetes'i laiendamise võimalus on see, et arendaja saab kirjutada oma operaatorid. Operaator on eriline protsess Kubernetes'i klastris, mis töötab „haldusvoolu“ mudeli järgi. Tänu operaatorile saab kasutaja automatiseerida CRD (kasutaja määratletud ressursside) haldamise, vahetades teavet Kubernetes API-ga.

Kogukonnas on mitu tööriista, mille abil saavad arendajad mugavalt luua oma operaatorid. Nende hulgas on Operator Framework ja selle Operator SDK. See SDK pakub aluse, mille põhjal saavad arendajad väga kiiresti operaatori loomisega alustada. Näiteks võib alustada käsurealt ligikaudu järgmiselt:

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

Nii luuakse kogu teie operaatori tüüpiline kood, 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 vajalikke API-sid ja kontrollerit nii:

$ 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, lõpuks, saab operaatori kokku panna ja saata selle oma konteineriregistrisse:

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

Kui arendaja vajab veelgi suuremat kontrolli, siis saab muudatusi teha Go-failides tüübikoodis. Näiteks, et kohandada kontrolleri spetsiifikat, saab muudatusi teha failis controller.go.

Teine projekt, KUDO, võimaldab luua operaatorid, kasutades ainult deklaratiivseid YAML-faile. Näiteks Apache Kafka operaator määratletakse ligikaudu nii. Selle abil saab lihtsalt paarist käsust luua Kafka klastrit Kubernetesel:

$ kubectl kudo install zookeeper
$ kubectl kudo install kafka

Ja siis saab selle konfigureerida veel ühe käsu abil:

$ 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

Uuendused

Viimase paar aasta jooksul on Kubernetes'i suured väljaanded toimunud iga paari kuu tagant - see tähendab, et kolm kuni neli suurt väljaannet aastas. Uute funktsioonide arv, mis igas neist rakendatakse, ei vähene. Veelgi enam, isegi meie keerulistel aegadel ei paista aeglustumise märke - vaadake, kui aktiivne on praegu Kubernetes'i projekt Githubis.

Uued võimalused võimaldavad paindlikumalt klasterdada operatsioone mitmekesiste töökoormuste korral. Lisaks meeldib arendajatele parem kontroll rakenduste juurutamisel otse tootmisvõttes.

Ühendus

Kubernetes'i populaarsuse veel üks oluline aspekt on tema kogukonna tugevus. 2015. aastal, kui saavutati versioon 1.0, sponsoreeris Kubernetes Cloud Native Computing Foundation.

Eksisteerivad ka mitmesugused kogukonnad SIG (erihuvigruppide) koosolekud, mis on suunatud erinevate Kubernetes'i valdkondade arendamisele, kuna see projekt areneb. Need grupid lisavad pidevalt uusi funktsioone, muutes Kubernetes'ega töötamise mugavamaks ja lihtsamaks.

Cloud Native Foundation korraldab samuti CloudNativeCon/KubeCon'i, mis on hetkel, mil seda teksti kirjutatakse, suurim avatud lähtekoodiga konverents maailmas. Tüüpiliselt korraldatakse seda kolm korda aastas ja see toob kokku tuhandeid professionaale, kes soovivad parendada Kubernetes'i ja selle ökosüsteemi ning õppida tundma uusi võimalusi, mis ilmnevad iga kolme kuu järel.

Lisaks on Cloud Native Foundation'il Tehnilise Järelevalve Komitee, mis koos SIG-dega vaatab üle uusi ja olemasolevaid projektid fondi projekte, millel on suunatud pilveökosüsteemile. Enamik neist projektidest aitab parandada Kubernetes'i tugevusi.

Lõpuks usun, et Kubernetes ei oleks saavutanud sellist edu ilma kogu kogukonna teadlike pingutusteta, kus inimesed toetavad üksteist, kuid samas aktsepteerivad rõõmuga ka uusi tulijaid.

Tulevik

Üks peamisi väljakutseid, millega arendajad tulevikus silmitsi seisavad, on oskus keskenduda koodi detailidele, mitte sellele infrastruktuurile, milles see töötab. Just sellele suundumusele vastab serverita arhitektuuriparadiig, mis on täna üks juhtivaid. Juba on olemas edasijõudnud raamistikud, nagu Knative ja OpenFaas, mis kasutavad Kubernetes'i arendaja infrastruktuuri abistamiseks.

Selles artiklis oleme vaid üldiselt vaatlenud Kubernetes'e hetkeolekut – tegelikult on see vaid jäämäe tipp. Kubernetes'e kasutajatel on palju muid ressursse, võimalusi ja konfiguratsioone.

Allikas: habr.com