Despre popularitatea tot mai mare a Kubernetes

Hei Habr!

La sfârșitul verii, vrem să vă reamintim că lucrăm în continuare pe această temă Kubernetes și a decis să publice un articol din Stackoverflow care să demonstreze starea de fapt în acest proiect la începutul lunii iunie.

Bucură-te!

La momentul scrierii acestui articol, vârsta lui Kubernetes este de aprox. în vârstă de șase ani, iar în ultimii doi ani popularitatea sa a crescut atât de mult încât este clasat constant printre cel mai favorit platforme. Kubernetes ocupă locul trei în acest an. Recapitulând: Kubernetes este o platformă concepută pentru rularea și orchestrarea sarcinilor de lucru în containere.

Containerele au început ca un design special pentru izolarea proceselor în Linux; containerele au fost incluse din 2007 cgrupuri, iar din 2002 – spații de nume. Containerele au fost proiectate și mai bine până în 2008, când au devenit disponibile LXC, iar Google și-a dezvoltat propriul mecanism intern corporativ numit Borg, unde „toată munca se face în containere”. De aici avansăm rapid până în 2013, când a avut loc prima lansare a Docker, iar containerele au devenit în sfârșit o soluție populară în masă. La acea vreme, instrumentul principal pentru orchestrarea containerelor era mesos, deși nu era extrem de popular. Kubernetes a fost lansat pentru prima dată în 2015, după care acest instrument a devenit standardul de facto în domeniul orchestrarii containerelor.

Pentru a încerca să înțelegem de ce Kubernetes este atât de popular, să încercăm să răspundem la câteva întrebări. Când a fost ultima dată când dezvoltatorii au putut să cadă de acord cu privire la modul de implementare a aplicațiilor în producție? Câți dezvoltatori știți care folosesc instrumentele, așa cum sunt furnizate din cutie? Câți administratori cloud există astăzi care nu înțeleg cum funcționează aplicațiile? Vom analiza răspunsurile la aceste întrebări în acest articol.

Infrastructură ca YAML

În lumea care a trecut de la Puppet and Chef la Kubernetes, una dintre cele mai mari schimbări a fost trecerea de la „infrastructură ca cod” la „infrastructură ca date” – în special, cum ar fi YAML. Toate resursele din Kubernetes, care includ pod-uri, configurații, instanțe implementate, volume etc., pot fi descrise cu ușurință într-un fișier YAML. De exemplu:

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

Această vizualizare face mai ușor pentru profesioniștii DevOps sau SRE să-și exprime pe deplin sarcinile de lucru fără a fi nevoie să scrie cod în limbaje precum Python sau Javascript.

Alte avantaje ale organizării infrastructurii ca date includ:

• Controlul versiunii GitOps sau Git Operations. Această abordare vă permite să păstrați toate fișierele YAML Kubernetes în depozitele git, astfel încât să puteți urmări exact când a fost făcută o modificare, cine a făcut-o și ce anume s-a schimbat. Acest lucru crește transparența operațiunilor în întreaga organizație și îmbunătățește eficiența operațională prin eliminarea ambiguității, în special în cazul în care angajații ar trebui să caute resursele de care au nevoie. În același timp, devine mai ușor să faceți automat modificări la resursele Kubernetes prin simpla îmbinare a unei cereri de extragere.
• Scalabilitate. Când resursele sunt definite ca YAML, devine extrem de ușor pentru operatorii de cluster să schimbe unul sau două numere într-o resursă Kubernetes, schimbând astfel modul în care aceasta se scalează. Kubernetes oferă un mecanism pentru scalarea automată orizontală a podurilor, care poate fi utilizat pentru a determina în mod convenabil numărul minim și maxim de poduri necesare într-o anumită configurație de implementare pentru a gestiona nivelurile scăzute și ridicate de trafic. De exemplu, dacă ați implementat o configurație care necesită capacitate suplimentară din cauza unei creșteri bruște a traficului, atunci maxReplicas poate fi schimbat de la 10 la 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

• Securitate și management. YAML este excelent pentru a evalua modul în care sunt implementate lucrurile în Kubernetes. De exemplu, o problemă majoră de securitate se referă la faptul că sarcinile dvs. de lucru rulează ca utilizator non-administrator. În acest caz, este posibil să avem nevoie de instrumente precum concurs, validator YAML/JSON, plus Deschideți Politica Agent, un validator de politici pentru a se asigura că contextul SecurityContext sarcinile dvs. de lucru nu permit rularea containerului cu privilegii de administrator. Dacă acest lucru este necesar, utilizatorii pot aplica o politică simplă Mă rog, ca aceasta:

package main

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

• Opțiuni de integrare cu un furnizor de cloud. Una dintre cele mai notabile tendințe în tehnologia actuală este de a rula sarcini de lucru pe furnizorii de cloud public. Folosind componenta furnizor de cloud Kubernetes permite oricărui cluster să se integreze cu furnizorul de cloud pe care rulează. De exemplu, dacă un utilizator rulează o aplicație în Kubernetes pe AWS și dorește să expună acea aplicație printr-un serviciu, furnizorul de cloud ajută la crearea automată a serviciului LoadBalancer, care va furniza automat echilibrul de încărcare Amazon Elastic Load Balancerpentru a redirecționa traficul către podurile de aplicații.

Extensibilitate

Kubernetes este foarte extensibil, iar dezvoltatorilor le place. Există un set de resurse disponibile, cum ar fi pod-uri, implementări, StatefulSets, secrete, ConfigMaps, etc. Adevărat, utilizatorii și dezvoltatorii pot adăuga alte resurse în formular definiții personalizate de resurse.

De exemplu, dacă vrem să definim o resursă CronTab, atunci ai putea face ceva de genul acesta:

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

Mai târziu, putem crea o resursă CronTab cam așa:

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

O altă opțiune de extensibilitate în Kubernetes este că dezvoltatorul își poate scrie propriile declarații. Operator este un proces special din clusterul Kubernetes care funcționează conform „circuit de control" Cu ajutorul unui operator, utilizatorul poate automatiza gestionarea CRD-urilor (definiții personalizate de resurse) prin schimbul de informații cu API-ul Kubernetes.

Există mai multe instrumente în comunitate care facilitează crearea propriilor operatori pentru dezvoltatori. Printre ei - Cadrul operatorului și Operator SDK. Acest SDK oferă o bază de la care un dezvoltator poate începe rapid să creeze un operator. Să presupunem că puteți începe de la linia de comandă ceva de genul acesta:

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

Acest lucru creează tot codul standard pentru operatorul dvs., inclusiv fișierele YAML și codul 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

Apoi puteți adăuga API-urile și controlerul necesar, astfel:

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

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

Apoi, în sfârșit, asamblați operatorul și trimiteți-l la registrul containerului dvs.:

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

Dacă dezvoltatorul dorește și mai mult control, codul standard din fișierele Go poate fi schimbat. De exemplu, pentru a modifica specificul controlerului, puteți face modificări fișierului controller.go.

Un alt proiect PRETUTINDENI, vă permite să creați declarații folosind numai fișiere YAML declarative. De exemplu, un operator pentru Apache Kafka ar fi definit aproximativ astfel. Cu acesta, puteți instala un cluster Kafka deasupra Kubernetes cu doar câteva comenzi:

$ kubectl kudo install zookeeper
$ kubectl kudo install kafka

Și apoi configurați-l cu o altă comandă:

$ 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

inovații

În ultimii ani, versiunile majore Kubernetes au apărut la fiecare câteva luni - adică trei până la patru lansări majore pe an. Numărul de noi funcții introduse în fiecare dintre ele nu scade. Mai mult decât atât, nu există semne de încetinire chiar și în aceste vremuri dificile - uitați-vă care este situația acum Activitatea proiectului Kubernetes pe Github.

Noile capabilități vă permit să grupați mai flexibil operațiunile pe diverse sarcini de lucru. În plus, programatorii se bucură de un control mai mare atunci când implementează aplicații direct în producție.

Comunitate

Un alt aspect major al popularității Kubernetes este puterea comunității sale. În 2015, când a ajuns la versiunea 1.0, Kubernetes a fost sponsorizat de Fundația Cloud Native Computing.

Există, de asemenea, diverse comunități SIG (Grupuri de interes special) s-au concentrat pe lucrul pe diferite zone ale Kubernetes pe măsură ce proiectul evoluează. Aceste grupuri adaugă în mod constant noi funcții, făcând lucrul cu Kubernetes mai convenabil și mai convenabil.

Cloud Native Foundation găzduiește și CloudNativeCon/KubeCon, care, la momentul scrierii, este cea mai mare conferință open source din lume. Desfășurat de obicei de trei ori pe an, reunește mii de profesioniști care doresc să îmbunătățească Kubernetes și ecosistemul său, precum și să învețe noi funcții care apar la fiecare trei luni.

Mai mult, Cloud Native Foundation are Comitetul Tehnic de Supraveghere, care, împreună cu SIG-urile, revizuiește noi și existente Proiecte fonduri concentrate pe ecosistemul cloud. Cele mai multe dintre aceste proiecte ajută la îmbunătățirea punctelor forte ale Kubernetes.

În cele din urmă, cred că Kubernetes nu ar avea atât de succes pe cât este fără eforturile conștiente ale întregii comunități, în care oamenii rămân uniți, dar în același timp îi întâmpină pe noii veniți.

Viitorul

Una dintre principalele provocări cu care dezvoltatorii vor trebui să le facă față în viitor este capacitatea de a se concentra asupra detaliilor codului în sine, și nu asupra infrastructurii în care rulează. Îndeplinește aceste tendințe paradigma arhitecturală fără server, care este una dintre cele mai importante astăzi. Cadre avansate există deja, de ex. nativ и OpenFaas, care utilizează Kubernetes pentru a abstrage infrastructura de la dezvoltator.

În acest articol, am zgâriat doar suprafața stării actuale a Kubernetes - de fapt, este doar vârful aisbergului. Utilizatorii Kubernetes au la dispoziție multe alte resurse, capabilități și configurații.

Sursa: www.habr.com