Om Kubernetes växande popularitet

Hej Habr!

I slutet av sommaren vill vi påminna om att vi fortsätter att arbeta med detta ämne. Kubernetes och beslutade att publicera en artikel från Stackoverflow som visar läget i detta projekt i början av juni.

Njut av att läsa!

I skrivande stund handlar Kubernetes om sex år gammal, och under de senaste två åren har dess popularitet vuxit så mycket att den konsekvent har rankats bland den mest älskade plattformar. I år ligger Kubernetes på tredje plats. För att sammanfatta, är Kubernetes en plattform designad för att köra och orkestrera containeriserade arbetsbelastningar.

Behållare har sitt ursprung som en speciell design för att isolera processer i Linux; sedan 2007 har containrarna inkluderat cgrupper, och sedan 2002 – namnutrymmen. Behållarna fick ett ännu bättre utseende 2008, då LXC, och Google utvecklade sin egen interna företagsmekanism som kallas Borg, där "allt arbete utförs i containrar." Härifrån går vi till 2013, då Docker först släpptes och containrar äntligen blev en populär masslösning. På den tiden var det främsta verktyget för containerorkestrering Mesos, även om det inte åtnjöt vild popularitet. Kubernetes släpptes första gången 2015 och har sedan dess blivit de facto-standarden för 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 kunde utvecklare senast komma överens om hur applikationer skulle distribueras till produktion? Hur många utvecklare känner du som använder verktygen när de tillhandahålls direkt? Hur många molnadministratörer finns det idag som inte förstår hur applikationer fungerar? Vi kommer att överväga svaren på dessa frågor i den här artikeln.

Infrastruktur som YAML

I världen som har flyttat från Puppet and Chef till Kubernetes har en av de största förändringarna varit övergången från "infrastruktur som kod" till "infrastruktur som data" - närmare bestämt som YAML. Alla resurser i Kubernetes, inklusive poddar, konfigurationer, distribuerade instanser, volymer, etc., 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 denna representation är det lättare för DevOps- eller SRE-proffs att uttrycka sina arbetsbelastningar fullt ut utan att behöva skriva kod på språk som Python eller Javascript.

Andra fördelar med att organisera infrastruktur som data inkluderar:

• GitOps eller Git Operations versionskontroll. Detta tillvägagångssätt låter dig behålla alla dina Kubernetes YAML-filer i git-förråd, så att du kan spåra exakt när en ändring gjordes, vem som gjorde den och exakt vad som ändrades. Detta ökar transparensen i verksamheten i hela organisationen och förbättrar den operativa effektiviteten genom att eliminera oklarheter, särskilt där anställda ska leta efter de resurser de behöver. Samtidigt blir det lättare att automatiskt göra ändringar i Kubernetes-resurser – genom att helt enkelt slå samman en pull-begäran.
• Skalbarhet. När resurser definieras som YAML blir det extremt enkelt för klusteroperatörer att ändra ett eller två nummer i en Kubernetes-resurs och därigenom ändra hur den skalas. Kubernetes tillhandahåller en mekanism för horisontell pod-autoskalning, vilket gör det enkelt att avgöra vad det minsta och maximala antalet pods är som en viss distribution kräver för att hantera låga och höga nivåer av trafik. Om du till exempel distribuerade en konfiguration som kräver ytterligare kapacitet på grund av en plötslig ökning av trafiken, kan du ändra maxReplicas-värdet 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 förvaltning. YAML är bra för att förstå hur saker distribueras till Kubernetes. Ett stort säkerhetsproblem är till exempel om dina arbetsbelastningar körs under en användare som inte är administratör. I det här fallet kan vi hitta verktyg som t.ex strid, YAML/JSON-validator, plus Öppna Policy Agent, en policyvalidator som säkerställer att sammanhanget Säkerhetskontext dina arbetsbelastningar tillåter inte att behållaren körs med administratörsbehörighet. Om detta måste säkerställas 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 = "Containers must not run as root"
}

• Alternativ för integration med en molnleverantör. En av de mest märkbara trenderna inom modern högteknologi är att köra arbetsbelastningar på kapaciteten hos offentliga molnleverantörer. Använda komponenten molnleverantör Kubernetes låter vilket kluster som helst integreras med molnleverantören det körs på. Till exempel, om en användare kör en applikation i Kubernetes på AWS och vill göra den applikationen tillgänglig via en tjänst, hjälper molnleverantören till att skapa tjänsten automatiskt. LoadBalancer, som automatiskt ger en lastbalanserare Amazon Elastic Load Balancerför att omdirigera trafik till programpoddar.

Expanderbarhet

Kubernetes är mycket utbyggbart, och utvecklare älskar det. Det finns en uppsättning tillgängliga resurser som pods, distributioner, StatefulSets, hemligheter, ConfigMaps, etc. Det är sant att användare och utvecklare kan lägga till andra resurser i formuläret anpassade resursdefinitioner.

Till exempel om vi vill definiera en resurs CronTab, då kan du göra något så här:

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

Senare kan vi skapa en CronTab-resurs så här:

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

Ett annat utökningsalternativ i Kubernetes är att en utvecklare kan skriva sina egna operatörer. Operatör – är en speciell process i ett Kubernetes-kluster som fungerar enligt mönstret "kontrollslinga". Med hjälp av operatören kan användaren automatisera hanteringen av CRD:er (custom resource definitions) genom att utbyta information med Kubernetes API.

Det finns flera verktyg i communityn som gör det enkelt för utvecklare att skapa sina egna operatörer. Bland dem finns: Operatörsramverk och Operatörs-SDK. Denna SDK ger en grund från vilken en utvecklare mycket snabbt kan börja skapa en operatör. Låt oss säga att du kan börja från kommandoraden så här:

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

Så här genereras all kod för din operatör, inklusive YAML-filer och Golang-kod:

.
|____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 du lägga till det nödvändiga API:et och styrenheten, 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

Sätt sedan ihop operatören och skicka den till ditt containerregister:

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

Om en utvecklare kräver ännu mer kontroll, kan standardkoden i Go-filer ändras. Till exempel, för att ändra detaljerna för en styrenhet, kan du göra ändringar i filen controller.go.

Ett annat projekt ÖVERALLT, låter dig skapa operatorer med endast deklarativa YAML-filer. Till exempel skulle operatören för Apache Kafka definieras som ungefär så. Med den kan du ställa in ett Kafka-kluster ovanpå Kubernetes med bara ett par kommandon:

$ kubectl kudo install zookeeper
$ kubectl kudo install kafka

Och sedan konfigurera det med ett annat 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 Kubernetes-släpp skett med några månaders mellanrum – det vill säga tre till fyra stora releaser per år. Antalet nya funktioner som introduceras i var och en av dem minskar inte. Dessutom finns det inga tecken på att sakta ner ens i våra svåra tider – titta på hur situationen ser ut just nu Kubernetes projektaktivitet på Github.

Nya funktioner möjliggör mer flexibel klustring av verksamheter vid hantering av en mängd olika arbetsbelastningar. Dessutom får utvecklare mer kontroll när de distribuerar applikationer direkt till produktionen.

Gemenskapen

En annan viktig aspekt av Kubernetes popularitet är styrkan i dess community. Under 2015, efter att ha nått version 1.0, sponsrades Kubernetes av Cloud Native Computing Foundation.

Det finns också olika samfund SIG (speciella intressegrupper) som syftar till att arbeta med olika delar av Kubernetes allt eftersom projektet utvecklas. Dessa team lägger ständigt till nya funktioner som gör arbetet med Kubernetes enklare och bekvämare.

Cloud Native Foundation är också värd för CloudNativeCon/KubeCon, som i skrivande stund är den största konferensen med öppen källkod 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 bemästra de nya funktionerna som dyker upp var tredje månad.

Dessutom har Cloud Native Foundation Utskottet för teknisk övervakning, som tillsammans med SIGs granskar nya och befintliga Projekt fonder fokuserade på molnets ekosystem. De flesta av dessa projekt hjälper till att förbättra Kubernetes styrkor.

Slutligen tror jag att Kubernetes inte hade varit så framgångsrik som den är utan hela samhällets medvetna insatser, där människor håller ihop, men samtidigt välkomnar nykomlingar i sina led.

Framtiden

En av de stora utmaningarna som utvecklare kommer att behöva hantera i framtiden är förmågan att fokusera på detaljerna i själva koden, snarare än infrastrukturen som den körs på. Det är just dessa trender som möts serverlöst arkitektoniskt paradigm, som är en av de ledande idag. Det finns redan avancerade ramverk, t.ex. Kniv и OpenFaas, som använder Kubernetes för att abstrahera infrastruktur från utvecklaren.

I den här artikeln har vi bara skrapat på ytan av det nuvarande tillståndet Kubernetes - i själva verket är detta bara toppen av isberget. Kubernetes-användare har många andra resurser, möjligheter och konfigurationer till sitt förfogande.

Källa: will.com