Om den växande populariteten av Kubernetes

Hej, Habr!

I slutet av sommaren vill vi påminna om att vi fortsatt arbetar med ämnet Kubernetes och har beslutat att publicera en artikel från Stackoverflow som visar läget i detta projekt i början av juni.

Trevlig läsning!

Vid tidpunkten för denna artikels skrivande är Kubernetes ungefär sex år gammal, och under de senaste två åren har dess popularitet ökat så mycket att den stabilt ligger bland de mest älskade plattformarna. I år har Kubernetes placerat sig på tredje plats. Låt oss påminna om: Kubernetes är en plattform avsedd för att köra och orkestrera containerarbetsbelastningar.

Containrar föddes som en specifik konstruktion för processisolering i Linux; sedan 2007 ingår cgroups, och sedan 2002 - namnrymder. Containrar blev ännu mer utvecklade 2008 när LXC, och Google utvecklade sin interna mekanism som heter Borg, där "allt arbete utförs i containrar". Låt oss hoppa fram till 2013, när den första versionen av Docker släpptes och containrar blev allmänt populära. Vid den tiden var det huvudsakliga verktyget för containerorkestrering Mesos, även om det inte var särskilt populärt. Den första versionen av Kubernetes släpptes 2015, varefter detta verktyg de facto blev standard inom containerorkestrering.

För att försöka förstå varför Kubernetes är så populärt, låt oss försöka svara på några frågor. När var senaste gången utvecklare kunde enas om hur man distribuerar applikationer i produktion? Hur många utvecklare känner du som använder verktyg i den form de tillhandahålls "ut ur lådan"? Hur många molnadministratörer idag förstår inte hur applikationer fungerar? Svaren på dessa frågor kommer vi att gå igenom i denna artikel.

Infrastruktur som YAML

I en värld som från Puppet och Chef har kommit till Kubernetes, var en av de största förändringarna övergången från "infrastruktur som kod" till "infrastruktur som data" - specifikt, som YAML. Alla resurser i Kubernetes, inklusive pods, konfigurationer, distribuerade instanser, volymer och andra kan enkelt beskrivas i en YAML-fil. Till exempel:

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

Med en sådan representation blir det enklare för DevOps- eller SRE-specialister att helt uttrycka sina arbetsbelastningar utan att behöva skriva programkod på språk som Python eller Javascript.

Andra fördelar med att organisera infrastrukturen för data är bland annat:

• GitOps eller versionskontroll för Git Operations. Denna metod gör det möjligt att hålla alla YAML-filer för Kubernetes i git-repo, vilket gör att du exakt kan spåra när en ändring gjordes, vem som gjorde den och vad som ändrades. Detta ökar transparensen i verksamheten, förbättrar effektiviteten genom att eliminera osäkerhet, särskilt när det gäller var anställda ska leta efter resurser. Samtidigt blir det enklare att automatiskt genomföra förändringar i resurserna i Kubernetes genom att använda vanliga pull-request sammanslagningar.
• Skalbarhet. När resurser definieras i form av YAML blir det mycket enkelt för klusteroperatörer att ändra ett eller två siffror i Kubernetes-resursen, vilket ändrar dess skalningsprinciper. Kubernetes har en mekanism för horisontell automatisk skalning av pods, vilket gör det enkelt att definiera vad som är det minimi- och maximala antalet pods som krävs i en specifik distribuerad konfiguration för att hantera låg och hög trafik. Till exempel, om du har distribuerat en konfiguration som kräver ytterligare resurser på grund av en kraftig trafikökning, kan maxReplicas-värdet ändras från 10 till 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

• Säkerhet och hantering. YAML är utmärkt för att bedöma hur olika saker distribueras i Kubernetes. Till exempel är ett allvarligt säkerhetsproblem relaterat till om dina arbetsbelastningar körs från en användare utan administratörsrättigheter. I detta fall kan verktyg som conftest, YAML/JSON-validerare, plus Open Policy Agent, policynvaliderare som ser till att kontexten SecurityContext de arbetsbelastningarna tillåter inte containern att köra med administratörsbehörighet. Om detta behövs kan användarna tillämpa en enkel policy rego, så här:

package main

deny[msg] {
  input.kind = "Deployment"
  not input.spec.template.spec.securityContext.runAsNonRoot = true
  msg = "Containrar får inte köras som root"
}

• Alternativ för integration med molnleverantören. En av de mest framträdande trenderna inom modern högteknologi är att köra arbetsbelastningar på resurser från offentliga molnleverantörer. Genom hjälp av komponenten cloud-provider Kubernetes gör det möjligt för varje kluster att integreras med den molnleverantör där det körs. Till exempel, om en användare har startat en applikation i Kubernetes på AWS och vill ge tillgång till denna applikation via en tjänst, hjälper molnleverantören automatiskt att skapa en tjänst LoadBalancer, som automatiskt ger en belastningsbalanserare Amazon Elastic Load Balancer, för att omdirigera trafik till applikationens pods.

Utbyggbarhet

Kubernetes skalar mycket bra, vilket tilltalar utvecklare. Det finns en uppsättning befintliga resurser, som pods, distributioner, StatefulSets, hemligheter, ConfigMaps, osv. I själva verket kan användare och utvecklare även lägga till andra resurser i form av anpassade resurser.

Till exempel, om vi vill definiera en resurs CronTab, kan vi göra något liknande:

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

Sen kan vi skapa en CronTab-resurs på ungefär det här sättet:

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

Ett annat alternativ för utvidgbarhet i Kubernetes är att en utvecklare kan skriva sina egna operatörer. Operator – är en speciell process i Kubernetes-klustret som arbetar enligt mönstret "styrkontur". Med hjälp av operatören kan användaren automatisera hanteringen av CRD (anpassade resursdefinitioner) genom att utbyta information med Kubernetes API.

Det finns flera verktyg i gemenskapen som underlättar för utvecklare att skapa sina egna operators. Bland dem finns Operator Framework och dess Operator SDK. Denna SDK ger en grund som utvecklaren kan utgå ifrån för att snabbt börja skapa en operator. Man kan till exempel börja från kommandoraden på följande sätt:

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

Så här skapas all standardkod för din operator, inklusive YAML-filer och kod 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

Sedan kan man lägga till nödvändiga API:er och kontroller, så här:

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

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

Därefter kan man äntligen bygga operatorn och skicka den till din containerregister:

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

Om utvecklaren behöver ännu mer kontroll kan man ändra standardkoden i Go-filerna. Till exempel, för att modifiera specifikationen för kontrollern kan man göra ändringar i filen controller.go.

Ett annat projekt, KUDO, tillåter att skapa operators enbart med deklarativa YAML-filer. Till exempel, en operator för Apache Kafka skulle definieras ungefär så. Med den kan du med bara några kommandon installera en Kafka-kluster ovanpå Kubernetes:

$ kubectl kudo install zookeeper
$ kubectl kudo install kafka

Och sedan konfigurera den med ytterligare ett 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

Innovationer

Under de senaste åren har stora versioner av Kubernetes släppts var några månader – det vill säga tre till fyra stora versioner om året. Antalet nya funktioner som införs i varje version minskar inte. Dessutom finns det inga tecken på avmattning ens i dessa svåra tider – se hur aktivt Kubernetes-projektet är på Github nu aktivitet..

De nya funktionerna möjliggör en mer flexibel klustring av operationer vid olika arbetsbelastningar. Dessutom tycker programmerare om att ha mer fullständig kontroll vid distribution av applikationer direkt i produktionen.

Gemenskap

En annan viktig aspekt av Kubernetes popularitet är styrkan i dess samhälle. År 2015, vid lanseringen av version 1.0, sponsrades Kubernetes Cloud Native Computing Foundation.

Det finns även olika samhällen SIG (specialintressegrupper) som fokuserar på olika områden inom Kubernetes när projektet utvecklas. Dessa grupper lägger ständigt till nya funktioner, vilket gör det enklare och mer bekvämt att arbeta med Kubernetes.

Cloud Native Foundation arrangerar också CloudNativeCon/KubeCon, som, vid tidpunkten för detta skrivande, är den största öppna källkodskonferensen i världen. Den hålls vanligtvis tre gånger om året och samlar tusentals yrkesverksamma som vill förbättra Kubernetes och dess ekosystem, samt lära sig de nya funktioner som dyker upp var tredje månad.

Dessutom finns det inom Cloud Native Foundation Ett tekniskt övervakningskommitté, som tillsammans med SIG:erna granskar nya och befintliga projekt inom fonden som riktas mot molnekosystemet. Många av dessa projekt hjälper till att förbättra styrkorna hos Kubernetes.

Slutligen tror jag att Kubernetes inte skulle ha haft så stor framgång utan medvetna insatser från hela gemenskapen, där människor stöttar varandra men också gärna välkomnar nykomlingar.

Framtiden

En av de grundläggande utmaningarna som utvecklare kommer att behöva hantera i framtiden är förmågan att fokusera på detaljerna i själva koden snarare än på den infrastruktur som den arbetar i. Det är dessa trender som den serverlösa arkitekturparadigmen, som idag är en av ledarna, svarar mot. Det finns redan avancerade ramverk, till exempel Knative och OpenFaas, som använder Kubernetes för att abstrahera infrastrukturen från utvecklaren.

I den här artikeln har vi endast i stora drag diskuterat det nuvarande tillståndet för Kubernetes – i verkligheten är detta bara toppen av isberget. Användare av Kubernetes har också tillgång till många andra resurser, funktioner och konfigurationer.

Källa: habr.com