Pri la kreskanta populareco de Kubernetes

Hej Habr!

Fine de la somero, ni volas memorigi vin, ke ni daŭre laboras pri la temo Kubernetoj kaj decidis publikigi artikolon de Stackoverflow pruvantan la staton en ĉi tiu projekto komence de junio.

Ĝuu legi!

En la momento de verkado de ĉi tiu artikolo, la aĝo de Kubernetes estas ĉ. sesjara, kaj dum la lastaj du jaroj ĝia populareco tiom kreskis, ke ĝi estas konstante rangita inter plej ŝatata platformoj. Kubernetes estas tria ĉi-jare. Resume: Kubernetes estas platformo desegnita por funkcii kaj reordigi konteneritajn laborŝarĝojn.

Ujoj komenciĝis kiel speciala dezajno por izolado de procezoj en Linukso; ujoj inkludis ekde 2007 grupoj, kaj ekde 2002 – nomspacoj. Ujoj estis dizajnitaj eĉ pli bone antaŭ 2008, kiam ĝi iĝis havebla LXC, kaj Google evoluigis sian propran internan kompanian mekanismon nomitan urbo, kie "ĉiu laboro estas farita en ujoj." De ĉi tie ni rapide antaŭen ĝis 2013, kiam okazis la unua eldono de Docker, kaj ujoj finfine fariĝis populara amasa solvo. En tiu tempo, la ĉefa ilo por kontenera instrumentado estis Mesos, kvankam li ne estis tre populara. Kubernetes unue estis publikigita en 2015, post kio ĉi tiu ilo fariĝis la fakta normo en la kampo de ujo-instrumentado.

Por provi kompreni kial Kubernetes estas tiel populara, ni provu respondi kelkajn demandojn. Kiam la lastan fojon programistoj povis interkonsenti pri kiel disfaldi aplikaĵojn al produktado? Kiom da programistoj vi konas, kiuj uzas la ilojn, ĉar ili estas provizitaj el la skatolo? Kiom da nubaj administrantoj estas hodiaŭ, kiuj ne komprenas kiel funkcias aplikaĵoj? Ni rigardos la respondojn al ĉi tiuj demandoj en ĉi tiu artikolo.

Infrastrukturo kiel YAML

En la mondo, kiu iris de Puppet and Chef al Kubernetes, unu el la plej grandaj ŝanĝoj estis la transiro de "infrastrukturo kiel kodo" al "infrastrukturo kiel datumoj"—specife, kiel YAML. Ĉiuj rimedoj en Kubernetes, kiuj inkluzivas podojn, agordojn, deplojitajn petskribojn, volumojn, ktp., povas esti facile priskribitaj en YAML-dosiero. Ekzemple:

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

Ĉi tiu vidpunkto faciligas por profesiuloj de DevOps aŭ SRE plene esprimi siajn laborŝarĝojn sen devi skribi kodon en lingvoj kiel Python aŭ Javascript.

Aliaj avantaĝoj de organizado de infrastrukturo kiel datumoj inkluzivas:

• GitOps aŭ Git Operations Versiokontrolo. Ĉi tiu aliro permesas vin konservi ĉiujn Kubernetes YAML-dosierojn en git-deponejoj, do vi povas spuri ĝuste kiam ŝanĝo estis farita, kiu faris ĝin, kaj kio ĝuste ŝanĝiĝis. Ĉi tio pliigas la travideblecon de operacioj ĉie en la organizo kaj plibonigas funkcian efikecon eliminante ambiguecon, precipe en kie dungitoj devus serĉi la rimedojn kiujn ili bezonas. Samtempe, fariĝas pli facile aŭtomate fari ŝanĝojn al Kubernetes-resursoj simple kunfandante tirpeton.
• Skalebleco. Kiam resursoj estas difinitaj kiel YAML, fariĝas ege facile por clusterfunkciigistoj ŝanĝi unu aŭ du nombrojn en Kubernetes-rimedo, tiel ŝanĝante kiel ĝi skalas. Kubernetes disponigas mekanismon por horizontala aŭtoskalado de podoj, kiu povas esti uzata por oportune determini kia la minimuma kaj maksimuma nombro da podoj estas postulataj en aparta deploja konfiguracio por trakti malaltajn kaj altajn nivelojn de trafiko. Ekzemple, se vi deplojis agordon kiu postulas plian kapaciton pro subita trafiko, tiam maxReplicas povas esti ŝanĝita de 10 al 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

• Sekureco kaj administrado. YAML estas bonega por taksi kiel aferoj estas deplojitaj en Kubernetes. Ekzemple, grava sekureca zorgo koncernas ĉu viaj laborŝarĝoj funkcias kiel ne-administra uzanto. En ĉi tiu kazo, ni eble bezonos ilojn kiel ekzemple konkurso, YAML/JSON validigilo, plus Malfermu Politikan Agenton, politika validigilo por certigi ke la kunteksto Sekureckunteksto viaj laborŝarĝoj ne permesas la ujo funkcii kun administranto-privilegioj. Se tio estas postulata, uzantoj povas apliki simplan politikon Mi preĝas, kiel tio:

package main

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

• Opcioj por integriĝo kun nuba provizanto. Unu el la plej rimarkindaj tendencoj en la hodiaŭa alta teknologio estas ruli laborŝarĝojn sur publikaj nubaj provizantoj. Uzante la komponanton nubo-provizanto Kubernetes permesas al ajna areto integri kun la nuba provizanto, sur kiu ĝi funkcias. Ekzemple, se uzanto kuras aplikaĵon en Kubernetes sur AWS kaj volas elmontri tiun aplikaĵon per servo, la nuba provizanto helpas aŭtomate krei la servon. LoadBalancerkiu aŭtomate provizos la ŝarĝbalancilon Amazon Elastic Load Balancerpor alidirekti trafikon al aplikaj podoj.

Vastebleco

Kubernetes estas tre etendebla kaj programistoj amas ĝin. Estas aro da disponeblaj rimedoj kiel balgoj, deplojoj, StatefulSets, sekretoj, ConfigMaps, ktp. Vere, uzantoj kaj programistoj povas aldoni aliajn rimedojn en la formo difinoj de kutimaj rimedoj.

Ekzemple, se ni volas difini rimedon CronTab, tiam vi povus fari ion tian:

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

Poste ni povas krei CronTab-rimedon ion kiel ĉi tio:

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

Alia opcio por etendebleco en Kubernetes estas, ke la programisto povas skribi siajn proprajn deklarojn. Telefonisto estas speciala procezo en la Kubernetes-areto, kiu funkcias laŭ la "kontrola cirkvito" Kun la helpo de funkciigisto, la uzanto povas aŭtomatigi la administradon de CRDs (personaj rimedadifinoj) interŝanĝante informojn kun la Kubernetes API.

Estas pluraj iloj en la komunumo, kiuj faciligas al programistoj krei siajn proprajn funkciigistojn. Inter ili - Operatora Kadro kaj lia Funkciigisto SDK. Ĉi tiu SDK disponigas fundamenton de kiu programisto povas rapide komenci krei funkciigiston. Ni diru, ke vi povas komenci de la komandlinio ion tian:

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

Ĉi tio kreas la tutan kodon por via funkciigisto, inkluzive de YAML-dosieroj kaj Golang-kodo:

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

Tiam vi povas aldoni la postulatajn API-ojn kaj regilon, jene:

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

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

Poste, finfine, kunigu la funkciigiston kaj sendu ĝin al la registro de via ujo:

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

Se la programisto volas eĉ pli da kontrolo, la kodo en Go-dosieroj povas esti ŝanĝita. Ekzemple, por modifi la specifaĵojn de la regilo, vi povas fari ŝanĝojn al la dosiero controller.go.

Alia projekto ĈIE, permesas al vi krei deklarojn uzante nur deklarajn YAML-dosierojn. Ekzemple, operatoro por Apache Kafka estus difinita proksimume tiel. Per ĝi, vi povas instali Kafka-grupon supre de Kubernetes per nur kelkaj komandoj:

$ kubectl kudo install zookeeper
$ kubectl kudo install kafka

Kaj tiam agordu ĝin per alia komando:

$ 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

Novigado

Dum la lastaj jaroj, ĉefaj eldonoj de Kubernetes aperis ĉiujn kelkajn monatojn - tio estas, tri ĝis kvar ĉefaj eldonoj jare. La nombro da novaj funkcioj enkondukitaj en ĉiu el ili ne malpliiĝas. Krome, ne estas signoj de malrapidiĝo eĉ en ĉi tiuj malfacilaj tempoj - rigardu, kia estas la situacio nun Kubernetes-projekta agado sur Github.

Novaj kapabloj permesas vin pli flekseble grupigi operaciojn tra diversaj laborŝarĝoj. Krome, programistoj ĝuas pli grandan kontrolon dum deplojado de aplikoj rekte al produktado.

Komunumo

Alia grava aspekto de la populareco de Kubernetes estas la forto de sia komunumo. En 2015, atinginte la version 1.0, Kubernetes estis sponsorita de Cloud Native Computing Foundation.

Estas ankaŭ diversaj komunumoj GIS (Specialaj Interesaj Grupoj) temigis laboradon pri malsamaj areoj de Kubernetes dum la projekto evoluas. Ĉi tiuj grupoj konstante aldonas novajn funkciojn, farante labori kun Kubernetes pli oportuna kaj oportuna.

La Cloud Native Foundation ankaŭ gastigas CloudNativeCon/KubeCon, kiu, en la momento de la skribado, estas la plej granda malfermfonta konferenco en la mondo. Ĝenerale okazigita trifoje jare, ĝi kunvenigas milojn da profesiuloj, kiuj volas plibonigi Kubernetes kaj ĝian ekosistemon, kaj lerni novajn funkciojn, kiuj aperas ĉiujn tri monatojn.

Plie, Cloud Native Foundation havas Teknika Kontrola Komitato, kiu, kune kun SIGoj, recenzas novajn kaj ekzistantajn projektoj financoj koncentriĝis al la nuba ekosistemo. Plej multaj el ĉi tiuj projektoj helpas plibonigi la fortojn de Kubernetes.

Fine, mi kredas, ke Kubernetes ne estus tiel sukcesa kiel ĝi estas sen la konsciaj klopodoj de la tuta komunumo, kie homoj restas kune sed samtempe bonvenigas novulojn en la gregon.

Estonteco

Unu el la ĉefaj defioj, kiujn programistoj devos trakti en la estonteco, estas la kapablo koncentriĝi pri la detaloj de la kodo mem, kaj ne pri la infrastrukturo en kiu ĝi funkcias. Ĝi renkontas ĉi tiujn tendencojn senservila arkitektura paradigmo, kiu estas unu el la ĉefaj hodiaŭ. Altnivelaj kadroj jam ekzistas, ekz. Knativo и OpenFaas, kiuj uzas Kubernetes por abstrakti la infrastrukturon de la programisto.

En ĉi tiu artikolo, ni nur skrapis la surfacon de la nuna stato de Kubernetes—fakte, ĝi estas nur la pinto de la glacimonto. Kubernetes-uzantoj havas multajn aliajn rimedojn, kapablojn kaj agordojn je sia dispono.

fonto: www.habr.com