Hello, Habr!
Sidst på sommeren vil vi gerne minde om, at vi stadig arbejder på dette emne og har besluttet at offentliggøre en artikel fra Stackoverflow, der viser status for dette projekt i begyndelsen af juni.
God læselyst!
På tidspunktet for skrivningen af denne artikel er Kubernetes omkring , og i de sidste to år er dets popularitet steget så meget, at det konsekvent er blandt de platforme. I år indtager Kubernetes tredjepladsen. Lad os minde om: Kubernetes er en platform designet til at køre og orkestrere containerarbejdsbelastninger.
Containere blev udviklet som en speciel konstruktion til isolering af processer i Linux; siden 2007 har containere inkluderet , og siden 2002 - namespaces. Containerne tog sig endnu bedre ud i 2008, da blev tilgængelige, og Google udviklede deres interne system kaldet , hvor "alt arbejde foregår i containere". Så lad os bevæge os til 2013, hvor den første udgave af Docker blev udgivet, og containerne gik endeligt fra at være nicheprodukter til at blive populære masseløsninger. På det tidspunkt var det primære værktøj til orkestrering af containere , selvom det ikke var synderligt populært. Den første udgave af Kubernetes blev udgivet i 2015, hvorefter dette værktøj de facto blev standarden inden for orkestrering af containere.
For at forsøge at forstå, hvorfor Kubernetes er så populært, lad os besvare nogle spørgsmål. Hvornår har udviklerne sidst været i stand til at blive enige om, hvordan man implementerer applikationer i produktion? Hvor mange udviklere kender du, der bruger værktøjer i den form, de leveres "out of the box"? Hvor mange cloudadministratorer i dag forstår ikke, hvordan applikationer fungerer? Vi vil se på svarene på disse spørgsmål i denne artikel.
Infrastruktur som YAML
I en verden, der er gået fra Puppet og Chef til Kubernetes, har en af de største ændringer været overgangen fra "infrastruktur som kode" til "infrastruktur som data" — specifikt, som YAML. Alle ressourcer i Kubernetes, herunder pods, konfigurationer, udrullede instanser, volumener osv., kan let 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: 80Med denne tilgang kan DevOps- eller SRE-specialister nemmere udtrykke deres arbejdsbyrder fuldt ud, uden at skulle skrive programkode i sprog som Python eller Javascript.
Andre fordele ved at organisere infrastrukturen som data er som følger:
- GitOps eller versionskontrol af Git Operations Version. Denne tilgang gør det muligt at holde alle YAML-filer til Kubernetes i git-repositorier, hvilket gør det muligt for dig præcist at spore, hvornår en ændring blev foretaget, hvem der lavede den, og hvad der præcist blev ændret. Dette øger gennemsigtigheden af operationer i hele organisationen og forbedrer arbejdseffektiviteten ved at fjerne tvetydighed, især hvad angår, hvor medarbejdere skal finde de ressourcer, de har brug for. Samtidig bliver det lettere automatisk at foretage ændringer i Kubernetes-ressourcer – ved simpelthen at fusionere en pull-request.
- Skalerbarhed. Når ressourcer er defineret i form af YAML, bliver det ekstremt nemt for klyngeoperatører at ændre et eller to tal i Kubernetes-ressourcen, hvilket ændrer skaleringsprincipperne. Kubernetes har en mekanisme til horisontal automatisk skalering af pods, som gør det nemt at definere, hvad det minimale og maksimale antal pods, der kræves i en specifik implementeringskonfiguration, er for at håndtere lav og høj trafik. For eksempel, hvis du har implementeret en konfiguration, der har brug for ekstra kræfter på grund af en kraftig trafikstigning, kan du ændre 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- Sikkerhed og styring. YAML er fremragende til at vurdere, hvordan forskellige elementer implementeres i Kubernetes. Et alvorligt sikkerhedsproblem drejer sig om, hvorvidt dine arbejdsbyrder kører under en bruger uden administratortilladelser. I dette tilfælde kan værktøjer som , en YAML/JSON-valider, plus , en politikvalider, der sikrer, at konteksten De arbejdsbyrder giver ikke containeren mulighed for at fungere med administratorrettigheder. Hvis dette er nødvendigt, kan brugerne anvende en simpel politik , sådan her:
pakke hoved
denier[msg] {
input.kind = "Deployment"
not input.spec.template.spec.securityContext.runAsNonRoot = true
msg = "Containere må ikke køre som root"
}- Integrationsmuligheder med cloududbyderen. En af de mest iøjnefaldende tendenser inden for moderne teknologi er at køre arbejdsbyrder på offentlige cloududbyderes infrastruktur. Ved hjælp af komponenten Kubernetes gør det muligt for enhver klynge at integrere med den cloududbyder, som den kører på. For eksempel, hvis en bruger har kørt en applikation i Kubernetes på AWS og ønsker at give adgang til denne applikation via en service, hjælper cloududbyderen automatisk med at oprette en service
LoadBalancer, der automatisk vil give en belastningsaflastning , for at dirigere trafik til applikationernes pods.
Skalerbarhed
Kubernetes er meget skalerbart, og det sætter udviklerne pris på. Der er et sæt eksisterende ressourcer, såsom pods, distributioner, StatefulSets, hemmeligheder, ConfigMaps, osv. Faktisk kan brugere og udviklere tilføje andre ressourcer i form af .
For eksempel, hvis vi ønsker at definere ressourcen CronTab, kunne vi gøre noget lignende:
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-resource på omtrent denne måde:
apiVersion: "my.org/v1"
kind: CronTab
metadata:
name: my-cron-object
spec:
cronSpec: "* * * * */5"
image: my-cron-image
replicas: 5
En anden form for skalerbarhed i Kubernetes er, at udvikleren kan skrive sine egne operatører. – det er en særlig proces i Kubernetes-klyngen, der fungerer efter mønsteret "". Ved hjælp af operatøren kan brugeren automatisere administrationen af CRD (brugerdefinerede ressourcebeskrivelser) ved at udveksle information med Kubernetes API.
I samfundet er der flere værktøjer, som udviklere nemt kan bruge til at lave deres egne operatorer. Blandt dem er og dets . Denne SDK giver en foundation, som udvikleren hurtigt kan bruge til at begynde at lave en operator. For eksempel kan man starte fra kommandolinjen på en måde som denne:
$ operator-sdk new my-operator --repo github.com/myuser/my-operatorDette genererer al den standardkode til din operator, 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=MyAppServiceDerefter kan du endelig bygge operatoren og sende den til dit containerregister:
$ operator-sdk build your.container.registry/youruser/myapp-operator Hvis udvikleren har brug for endnu mere kontrol, kan de ændre standardkoden i filer skrevet i Go. For eksempel, for at ændre controllerens specifik, kan der laves ændringer i filen controller.go.
Et andet projekt, , giver mulighed for at oprette operatører ved hjælp af kun deklarative YAML-filer. For eksempel vil en operator til Apache Kafka blive defineret omtrent . Med det kan du nemt installere et Kafka-kluster over Kubernetes med blot et par kommandoer:
$ kubectl kudo install zookeeper
$ kubectl kudo install kafkaOg derefter konfigurere det med endnu 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
Innovationer
I de seneste år er store Kubernetes-udgivelser kommet hver few måneder – det vil sige, tre til fire store udgivelser om året. Antallet af nye funktioner, der implementeres i hver af dem, mindskes ikke. Desuden er der ingen tegn på afmatning, selv i vores svære tider – se på den nuværende .
De nye funktioner giver en mere fleksibel måde at klusterere operationer på, når der er forskellige arbejdsbelastninger. Desuden sætter programmører pris på den øgede kontrol ved at implementere applikationer direkte i produktionen.
Fællesskab
En anden vigtig faktor for Kubernetes' popularitet er styrken af dets fællesskab. I 2015, da version 1.0 blev lanceret, blev Kubernetes sponsoreret .
Der findes også forskellige fællesskaber (specialinterestgrupper), der fokuserer på at udforske forskellige områder af Kubernetes, mens projektet udvikler sig. Disse grupper tilføjer konstant nye funktioner, hvilket gør det lettere og lettere at arbejde med Kubernetes.
Cloud Native Foundation afholder også CloudNativeCon/KubeCon, som på tidspunktet for denne tekst er den største open source-konference i verden. Den finder normalt sted tre gange om året og samler tusinder af fagfolk, der ønsker at forbedre Kubernetes og dets økosystem samt mestre de nye funktioner, der kommer hver tredje måned.
Desuden er der i Cloud Native Foundation , som sammen med SIG'erne vurderer nye og eksisterende i fonden, der fokuserer på cloud-økosystemet. De fleste af disse projekter hjælper med at forbedre styrkerne i Kubernetes.
Endelig tror jeg på, at Kubernetes ikke ville have haft så meget succes uden de bevidste bestræbelser fra hele fællesskabet, hvor folk støtter hinanden, men samtidig glædeligt byder nykommere velkommen.
Fremtid
En af de største udfordringer, som udviklere vil stå over for i fremtiden, er evnen til at fokusere på detaljerne i selve koden snarere end den infrastruktur, det kører på. Denne tendens adresseres af , som i dag er en af de førende. Der findes allerede avancerede rammer, såsom og , der bruger Kubernetes til at abstrahere infrastrukturen fra udvikleren.
I denne artikel har vi kun set på den nuværende tilstand af Kubernetes i store træk – i virkeligheden er det kun toppen af isbjerget. Brugerne af Kubernetes har også mange andre ressourcer, muligheder og konfigurationer til rådighed.
Kilde: habr.com
