Hej Habr!
I slutningen af sommeren vil vi minde om, at vi arbejder videre med emnet og besluttede at publicere en artikel fra Stackoverflow, der demonstrerer tingenes tilstand i dette projekt i begyndelsen af juni.
Nyd læsning!
På tidspunktet for skrivning af denne artikel er Kubernetes alder ca. , og i løbet af de sidste to år er dens popularitet vokset så meget, at den konsekvent er rangeret blandt platforme. Kubernetes ligger på tredjepladsen i år. For at opsummere: Kubernetes er en platform designet til at køre og orkestrere containeriserede arbejdsbelastninger.
Containere begyndte som et specielt design til isolering af processer i Linux; containere har inkluderet siden 2007 , og siden 2002 – navnerum. Containere blev designet endnu bedre i 2008, da de blev tilgængelige , og Google udviklede sin egen interne virksomhedsmekanisme kaldet , hvor "alt arbejde udføres i containere." Herfra spoler vi frem til 2013, hvor den første udgivelse af Docker fandt sted, og containere endelig blev en populær masseløsning. På det tidspunkt var det vigtigste værktøj til containerorkestrering , selvom han ikke var voldsomt populær. Kubernetes blev første gang udgivet i 2015, hvorefter dette værktøj blev de facto standard inden for containerorkestrering.
For at prøve at forstå, hvorfor Kubernetes er så populær, lad os prøve at besvare et par spørgsmål. Hvornår var det sidste gang, udviklere var i stand til at blive enige om, hvordan de skulle implementere applikationer til produktion? Hvor mange udviklere kender du, der bruger værktøjerne, når de leveres ud af kassen? Hvor mange cloud-administratorer er der i dag, som ikke forstår, hvordan applikationer fungerer? Vi vil se på svarene på disse spørgsmål i denne artikel.
Infrastruktur som YAML
I verden, der gik fra Puppet and Chef til Kubernetes, var en af de største ændringer overgangen fra "infrastruktur som kode" til "infrastruktur som data" - specifikt som YAML. Alle ressourcer i Kubernetes, som inkluderer pods, konfigurationer, implementerede forekomster, volumener osv., kan nemt 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: 80Denne visning gør det nemmere for DevOps- eller SRE-professionelle at udtrykke deres arbejdsbelastning fuldt ud uden at skulle skrive kode på sprog som Python eller Javascript.
Andre fordele ved at organisere infrastruktur som data omfatter:
- GitOps eller Git Operations Version Control. Denne tilgang giver dig mulighed for at beholde alle Kubernetes YAML-filer i git-repositories, så du kan spore præcis, hvornår en ændring blev foretaget, hvem der lavede den, og hvad der præcist ændrede sig. Dette øger gennemsigtigheden af operationer i hele organisationen og forbedrer den operationelle effektivitet ved at eliminere tvetydighed, især hvor medarbejderne skal lede efter de ressourcer, de har brug for. Samtidig bliver det nemmere automatisk at foretage ændringer i Kubernetes-ressourcer ved blot at flette en pull-anmodning.
- Skalerbarhed. Når ressourcer er defineret som YAML, bliver det ekstremt nemt for klyngeoperatører at ændre et eller to tal i en Kubernetes-ressource og derved ændre, hvordan den skaleres. Kubernetes leverer en mekanisme til horisontal autoskalering af pods, som kan bruges til bekvemt at bestemme, hvilket minimum og maksimum antal pods, der kræves i en bestemt implementeringskonfiguration for at håndtere lave og høje niveauer af trafik. Hvis du for eksempel har implementeret en konfiguration, der kræver yderligere kapacitet på grund af en pludselig stigning i trafikken, kan maxReplicas ændres 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- Sikkerhed og ledelse. YAML er fantastisk til at evaluere, hvordan tingene er implementeret i Kubernetes. Et stort sikkerhedsproblem vedrører f.eks., om dine arbejdsbelastninger kører som en ikke-administratorbruger. I dette tilfælde kan vi få brug for værktøjer som f.eks , YAML/JSON validator, plus , en politikvalidator for at sikre, at konteksten dine arbejdsbelastninger tillader ikke containeren at køre med administratorrettigheder. Hvis dette er påkrævet, kan brugerne anvende en simpel politik , sådan her:
package main
deny[msg] {
input.kind = "Deployment"
not input.spec.template.spec.securityContext.runAsNonRoot = true
msg = "Containers must not run as root"
}- Muligheder for integration med en cloud-udbyder. En af de mest bemærkelsesværdige tendenser i nutidens højteknologi er at køre arbejdsbelastninger på offentlige cloud-udbydere. Brug af komponenten Kubernetes tillader enhver klynge at integrere med den cloud-udbyder, den kører på. For eksempel, hvis en bruger kører en applikation i Kubernetes på AWS og ønsker at eksponere den applikation gennem en tjeneste, hjælper skyudbyderen automatisk med at oprette tjenesten
LoadBalancersom automatisk vil levere belastningsbalanceren at omdirigere trafik til applikations-pods.
Udvidelsesmuligheder
Kubernetes er meget udvidelsesmuligheder, og udviklere elsker det. Der er et sæt tilgængelige ressourcer såsom pods, implementeringer, StatefulSets, hemmeligheder, ConfigMaps, etc. Sandt nok kan brugere og udviklere tilføje andre ressourcer i formularen .
For eksempel hvis vi vil definere en ressource CronTab, så kunne du gøre sådan noget:
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 oprette en CronTab-ressource noget som dette:
apiVersion: "my.org/v1"
kind: CronTab
metadata:
name: my-cron-object
spec:
cronSpec: "* * * * */5"
image: my-cron-image
replicas: 5
En anden mulighed for udvidelse i Kubernetes er, at udvikleren kan skrive sine egne udsagn. er en særlig proces i Kubernetes-klyngen, der fungerer i henhold til "" Ved hjælp af en operatør kan brugeren automatisere håndteringen af CRD'er (custom resource definitions) ved at udveksle information med Kubernetes API.
Der er flere værktøjer i fællesskabet, der gør det nemt for udviklere at oprette deres egne operatører. Blandt dem - og . Denne SDK giver et fundament, hvorfra en udvikler hurtigt kan begynde at oprette en operatør. Lad os sige, at du kan starte fra kommandolinjen noget som dette:
$ operator-sdk new my-operator --repo github.com/myuser/my-operatorDette opretter al boilerplate-koden for din operatør, inklusive YAML-filer og Golang-kode:
.
|____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.goDerefter kan du tilføje de nødvendige API'er og controller, sådan her:
$ operator-sdk add api --api-version=myapp.com/v1alpha1 --kind=MyAppService
$ operator-sdk add controller --api-version=myapp.com/v1alpha1 --kind=MyAppServiceTil sidst skal du samle operatøren og sende den til registreringsdatabasen for din container:
$ operator-sdk build your.container.registry/youruser/myapp-operator
Hvis udvikleren ønsker endnu mere kontrol, kan boilerplate-koden i Go-filer ændres. For at ændre controllerens specifikationer kan du for eksempel foretage ændringer i filen controller.go.
Endnu et projekt , giver dig mulighed for at oprette udsagn ved kun at bruge deklarative YAML-filer. For eksempel vil en operatør for Apache Kafka blive defineret tilnærmelsesvis . Med det kan du installere en Kafka-klynge oven på Kubernetes med blot et par kommandoer:
$ kubectl kudo install zookeeper
$ kubectl kudo install kafkaOg konfigurer det derefter med en anden 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
I løbet af de sidste par år er store Kubernetes-udgivelser udkommet med få måneders mellemrum - det vil sige tre til fire store udgivelser om året. Antallet af nye funktioner introduceret i hver af dem falder ikke. Desuden er der ingen tegn på at sætte farten ned selv i disse svære tider – se på, hvordan situationen er nu .
Nye funktioner giver dig mulighed for mere fleksibelt at gruppere operationer på tværs af forskellige arbejdsbelastninger. Derudover har programmører større kontrol, når de implementerer applikationer direkte til produktionen.
Fællesskab
Et andet vigtigt aspekt af Kubernetes' popularitet er styrken af dets fællesskab. I 2015, efter at have nået version 1.0, blev Kubernetes sponsoreret af .
Der er også forskellige fællesskaber (Special Interest Groups) fokuserede på at arbejde på forskellige områder af Kubernetes, efterhånden som projektet udvikler sig. Disse grupper tilføjer konstant nye funktioner, hvilket gør arbejdet med Kubernetes mere bekvemt og bekvemt.
Cloud Native Foundation er også vært for CloudNativeCon/KubeCon, som i skrivende stund er den største open source-konference i verden. Det afholdes typisk tre gange om året og samler tusindvis af fagfolk, der ønsker at forbedre Kubernetes og dets økosystem, samt lære nye funktioner, der vises hver tredje måned.
Desuden har Cloud Native Foundation , som sammen med SIGs gennemgår nye og eksisterende midler fokuseret på skyens økosystem. De fleste af disse projekter hjælper med at forbedre Kubernetes styrker.
Endelig tror jeg på, at Kubernetes ikke ville være så succesfuld, som den er uden hele samfundets bevidste indsats, hvor folk holder sammen, men samtidig byder nytilkomne velkommen i folden.
fremtiden
En af de vigtigste udfordringer, som udviklere skal håndtere i fremtiden, er evnen til at fokusere på detaljerne i selve koden, og ikke på den infrastruktur, den kører i. Det imødekommer disse tendenser , som er en af de førende i dag. Avancerede rammer findes allerede, f.eks. и , som bruger Kubernetes til at abstrahere infrastrukturen fra udvikleren.
I denne artikel har vi kun ridset overfladen af den nuværende tilstand Kubernetes – faktisk er det kun toppen af isbjerget. Kubernetes-brugere har mange andre ressourcer, muligheder og konfigurationer til deres rådighed.
Kilde: www.habr.com