Om den voksende populariteten til Kubernetes

Hei, Habr!

På slutten av sommeren vil vi minne om at vi fortsatt jobber med temaet Kubernetes og har besluttet å publisere en artikkel fra Stackoverflow som viser statusen for dette prosjektet i begynnelsen av juni.

God lesning!

Ved skrivingen av denne artikkelen er alderen til Kubernetes omtrent seks år, og i løpet av de siste to årene har populariteten vokst så mye at den stabilt er blant de mest foretrukne plattformene. I år inntar Kubernetes tredjeplassen. La oss minne om: Kubernetes er en plattform designet for å kjøre og orkestrere container arbeidsbelastninger.

Containere oppstod som en spesialstruktur for prosessisolering i Linux; siden 2007 har de inkludert cgroups, og siden 2002 - navnerom. Containere ble enda bedre definert i 2008, da det ble tilgjengelig LXC, og Google utviklet sin interne mekanisme kalt Borg, hvor «alt arbeid skjer i containere». La oss spole frem til 2013, da den første utgivelsen av Docker fant sted, og containere endelig ble et populært masseprodukt. På den tiden var det primære verktøyet for orkestrering av containere Mesos, selv om det ikke hadde stor popularitet. Den første utgivelsen av Kubernetes skjedde i 2015, hvoretter dette verktøyet de facto ble standarden innen orkestrering av containere.

For å forstå hvorfor Kubernetes er så populært, la oss prøve å svare på noen spørsmål. Når var siste gang utviklerne klarte å enes om hvordan man skulle distribuere applikasjoner i produksjon? Hvor mange utviklere kjenner du som bruker verktøyene i den formen de leveres "out of the box"? Hvor mange skyadministratorer i dag forstår ikke hvordan applikasjoner fungerer? Vi vil drøfte svarene på disse spørsmålene i denne artikkelen.

Infrastruktur som YAML

I en verden som gikk fra Puppet og Chef til Kubernetes, var en av de største endringene overgangen fra "infrastruktur som kode" til "infrastruktur som data" — konkret, som YAML. Alle ressursene i Kubernetes, som pods, konfigurasjoner, distribuerte instanser, volumer osv. kan enkelt beskrives i en YAML-fil. For eksempel:

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

Med en slik fremstilling kan DevOps- eller SRE-spesialister lettere uttrykke arbeidsbelastningen sin fullt ut, uten å måtte skrive programkode i språk som Python eller Javascript.

Andre fordeler ved organisering av infrastruktur for data er som følger:

• GitOps eller Git Operations versjonskontroll. Denne tilnærmingen gjør det mulig å holde alle YAML-filer for Kubernetes i git-repositorier, noe som gjør at du nøyaktig kan spore når endringer ble gjort, hvem som gjorde dem og hva som ble endret. Dette øker transparensen i operasjonene i hele organisasjonen, samt øker effektiviteten ved å eliminere tvetydighet, spesielt når det gjelder hvor ansatte skal lete etter de ressursene de trenger. Samtidig blir det lettere å automatisere endringer av Kubernetes-ressurser ved hjelp av vanlige pull-forespørsel-fusjoner.
• Skalerbarhet. Når ressurser er definert i YAML-format, blir det ekstremt enkelt for klyngeoperatører å endre ett eller to tall i en Kubernetes-ressurs, og dermed endre dens skaleringsprinsipper. Kubernetes har et mekanisme for horisontal autoskalering av pod-er, som gjør det enkelt å spesifisere det minimale og maksimale antallet pod-er som kreves for en spesifikk distribusjonskonfigurasjon for å håndtere lav og høy trafikk. For eksempel, hvis du har rullet ut en konfigurasjon som krever ekstra ressurser på grunn av en brå økning i trafikk, kan du endre maxReplicas fra 10 til 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

• Sikkerhet og administrasjon. YAML er utmerket for å vurdere hvordan ulike ting distribueres i Kubernetes. For eksempel er et alvorlig problem knyttet til sikkerhet om arbeidsbelastningene dine kjøres fra en bruker uten administratorrettigheter. I dette tilfellet kan verktøy som være nyttige. conftest, en YAML/JSON-validator, pluss Open Policy Agent, en policy-validator som sørger for at konteksten SecurityContext arbeidsbelastningene dine tillater ikke at containeren kjører med administratorrettigheter. Hvis dette er nødvendig, kan brukerne anvende en enkel policy rego, slik:

pakke hoved

tilbakevis[msg] {
  input.kind = "Deployering"
  ikke input.spec.template.spec.securityContext.runAsNonRoot = true
  msg = "Containere må ikke kjøre som root"
}

• Integrasjonsmuligheter med skyleverandøren. En av de mest fremtredende tendensene innen moderne teknologi er å kjøre arbeidsbelastninger på offentlige skyleverandørers infrastruktur. Med komponenten cloud-provider Kubernetes lar enhver kluster integrere med den skyløsningen den kjører på. For eksempel, hvis en bruker har startet en applikasjon i Kubernetes på AWS og ønsker å åpne tilgang til denne applikasjonen via en tjeneste, hjelper skyleverandøren automatisk med å opprette en tjeneste LoadBalancer, som automatisk vil gi en belastningsfordeler Amazon Elastic Load Balancer, for å omdirigere trafikk til applikasjonspods.

Utvidbarhet

Kubernetes skalerer veldig bra, og det setter utviklerne pris på. Det finnes et sett med tilgjengelige ressurser, som pods, distribusjoner, StatefulSets, hemmeligheter, ConfigMaps, osv. Faktisk kan brukere og utviklere legge til flere ressurser i form av brukerdefinerte ressursdefinisjoner.

For eksempel, hvis vi ønsker å definere ressursen CronTab, kunne vi lage noe slik:

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

Senere kan vi opprette en CronTab-ressurs omtrent som dette:

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

En annen måte å utvide Kubernetes på er at utvikleren kan skrive sine egne operatører. Operator – det er en spesiell prosess i Kubernetes-klusteret som følger mønsteret «kontrollsløyfe». Ved hjelp av operatøren kan brukeren automatisere håndtering av CRD (brukerdefinerte ressursdefinisjoner) ved å utveksle informasjon med Kubernetes API.

I fellesskapet er det flere verktøy som gjør det enkelt for utviklere å lage sine egne operatorer. Blant dem er Operator Framework og dets Operator SDK. Dette SDK-et gir et grunnlag som utvikleren raskt kan bygge videre på for å lage en operator. La oss si at man kan begynne fra kommandolinjen slik:

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

Slik genereres all standardkode for operatoren din, inkludert YAML-filer og kode i Golang:

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

Deretter kan du legge til nødvendige API-er og kontroller, slik:

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

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

Etterpå kan du endelig bygge operatoren og sende den til containerregisteret ditt:

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

Hvis utvikleren trenger enda mer kontroll, kan man endre standardkoden i Go-filene. For eksempel, for å endre spesifikasjonen til kontrolleren, kan man gjøre endringer i filen controller.go.

Et annet prosjekt, KUDO, lar deg lage operatorer ved kun å bruke deklarative YAML-filer. For eksempel vil en operator for Apache Kafka bli definert omtrent slik. Ved hjelp av dette kan man med bare noen få kommandoer installere et Kafka-kluster over Kubernetes:

$ kubectl kudo install zookeeper
$ kubectl kudo install kafka

Og deretter konfigurere det med enda en kommando:

$ 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

Innovasjoner

I løpet av de siste årene har store utgivelser av Kubernetes skjedd hver måned – med tre til fire store utgivelser per år. Antallet nye funksjoner som innføres i hver av dem, reduseres ikke. Faktisk er det ingen tegn til nedgang selv i vår vanskelige tid – se på aktiviteten til Kubernetes-prosjektet på Github.

Nye muligheter gir mer fleksibilitet i klusteroperasjoner med varierte arbeidsbelastninger. I tillegg liker utviklerne å ha mer kontroll når de distribuerer applikasjoner direkte i produksjon.

Samfunnet

En annen alvorlig aspekt ved populariteten til Kubernetes er kraften i fellesskapet. I 2015, etter å ha nådd versjon 1.0, ble Kubernetes sponsa Cloud Native Computing Foundation.

Det finnes også en rekke forskjellige fellesskap SIG (spesielle interessegrupper), fokusert på å utforske forskjellige områder av Kubernetes mens prosjektet utvikler seg. Disse gruppene legger stadig til nye funksjoner, noe som gjør det enklere og mer brukervennlig å jobbe med Kubernetes.

Cloud Native Foundation arrangerer også CloudNativeCon/KubeCon, som på tidspunktet for skrivingen av denne teksten er den største open source-konferansen i verden. Vanligvis avholdes den tre ganger i året og samler tusenvis av fagfolk som ønsker å forbedre Kubernetes og dets økosystem, samt lære om nye funksjoner som dukker opp hver tredje måned.

Videre har Cloud Native Foundation Teknisk tilsynsutvalg, som sammen med SIGer vurderer nye og eksisterende prosjekter fond, fokusert på sky-økosystemet. De fleste av disse prosjektene bidrar til å styrke Kubernetes.

Til slutt tror jeg at Kubernetes ikke ville hatt så stor suksess uten de bevisste innsatsene fra hele fellesskapet, hvor folk støtter hverandre, men samtidig gjerne tar imot nykommere.

Fremtiden

En av de viktigste utfordringene utviklere må håndtere i fremtiden, er evnen til å fokusere på detaljene i koden fremfor infrastrukturen den kjører på. Dette er nettopp de tendensene den serverløse arkitekturparadigmen, som i dag er en av de ledende. Det finnes allerede avanserte rammeverk, som Knative og OpenFaas, som bruker Kubernetes for å abstrahere infrastrukturen bort fra utvikleren.

I denne artikkelen har vi bare sett på den nåværende tilstanden til Kubernetes i all hovedsak – egentlig er dette bare toppen av isfjellet. Brukere av Kubernetes har også mange andre ressurser, muligheter og konfigurasjoner tilgjengelig.

Kilde: habr.com