Hej Habr!
I slutet av sommaren vill vi påminna om att vi jobbar vidare med ämnet och bestämde sig för att publicera en artikel från Stackoverflow som visar läget i detta projekt i början av juni.
Njut av att läsa!
Vid skrivandet av denna artikel är Kubernetes ålder ca. , och under de senaste två åren har dess popularitet vuxit så mycket att den konsekvent rankas bland plattformar. Kubernetes ligger på tredje plats i år. För att sammanfatta: Kubernetes är en plattform designad för att köra och orkestrera containeriserade arbetsbelastningar.
Behållare började som en speciell design för att isolera processer i Linux; containrar har inkluderats sedan 2007 , och sedan 2002 – namnutrymmen. Containers designades ännu bättre 2008, när de blev tillgängliga , och Google utvecklade sin egen interna företagsmekanism som kallas , där "allt arbete utförs i containrar." Härifrån spola vi framåt till 2013, då den första releasen av Docker ägde rum, och containrar äntligen blev en populär masslösning. På den tiden var det främsta verktyget för containerorkestrering , även om han inte var jättepopulär. Kubernetes släpptes först 2015, varefter detta verktyg blev de facto-standarden 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 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 titta på svaren på dessa frågor i den här artikeln.
Infrastruktur som YAML
I världen som gick från Puppet and Chef 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, som inkluderar 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: 80Denna vy gör det enklare för DevOps- eller SRE-proffs att fullt ut uttrycka sina arbetsbelastningar 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 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 var 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 autoskalning av pods, som kan användas för att bekvämt bestämma vilket lägsta och maximala antal pods som krävs i en viss distributionskonfiguration för att hantera låga och höga nivåer av trafik. Till exempel, om du har distribuerat en konfiguration som kräver ytterligare kapacitet på grund av en plötslig ökning av trafiken, kan maxReplicas ä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 förvaltning. YAML är bra för att utvärdera hur saker distribueras i Kubernetes. Ett stort säkerhetsproblem gäller till exempel om dina arbetsbelastningar körs som en icke-adminanvändare. I det här fallet kan vi behöva verktyg som t.ex , YAML/JSON-validator, plus , en policyvalidator för att säkerställa att sammanhanget dina arbetsbelastningar tillåter inte att behållaren körs med administratörsbehörighet. Om detta krävs kan användare tillämpa en enkel policy , 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 anmärkningsvärda trenderna inom dagens högteknologi är att köra arbetsbelastningar på offentliga molnleverantörer. Använda komponenten Kubernetes låter vilket kluster som helst integreras med molnleverantören som det körs på. Till exempel, om en användare kör en applikation i Kubernetes på AWS och vill exponera den applikationen genom en tjänst, hjälper molnleverantören automatiskt att skapa tjänsten
LoadBalancersom automatiskt tillhandahåller lastbalanseraren fö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 .
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 ungefär 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 alternativ för utökbarhet i Kubernetes är att utvecklaren kan skriva sina egna uttalanden. är en speciell process i Kubernetes-klustret som fungerar enligt "" Med hjälp av en operatör 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 - och . Denna SDK ger en grund från vilken en utvecklare snabbt kan börja skapa en operatör. Låt oss säga att du kan börja från kommandoraden ungefär så här:
$ operator-sdk new my-operator --repo github.com/myuser/my-operatorDetta skapar all standardkod 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.goSedan kan du lägga till de nödvändiga API:erna och kontrollerna, så här:
$ operator-sdk add api --api-version=myapp.com/v1alpha1 --kind=MyAppService
$ operator-sdk add controller --api-version=myapp.com/v1alpha1 --kind=MyAppServiceSedan, slutligen, montera operatören och skicka den till registret för din container:
$ operator-sdk build your.container.registry/youruser/myapp-operator
Om utvecklaren vill ha ännu mer kontroll kan boilerplate-koden i Go-filer ändras. Till exempel, för att ändra detaljerna för kontrollern, kan du göra ändringar i filen controller.go.
Ett annat projekt , låter dig skapa uttalanden med endast deklarativa YAML-filer. Till exempel skulle en operatör för Apache Kafka definieras ungefär . Med den kan du installera ett Kafka-kluster ovanpå Kubernetes med bara ett par kommandon:
$ kubectl kudo install zookeeper
$ kubectl kudo install kafkaOch 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-utgåvor kommit ut med några månaders mellanrum - det vill säga tre till fyra stora utgåvor 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 dessa svåra tider – titta på hur läget är nu .
Nya funktioner tillåter dig att mer flexibelt klustera verksamheter över olika arbetsbelastningar. Dessutom får programmerare större 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 .
Det finns också olika samfund (Special Interest Groups) fokuserade på att arbeta med olika delar av Kubernetes allt eftersom projektet utvecklas. Dessa grupper lägger ständigt till nya funktioner, vilket gör arbetet med Kubernetes mer bekvämt och bekvämt.
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 lära sig nya funktioner som dyker upp var tredje månad.
Dessutom har Cloud Native Foundation , som tillsammans med SIGs granskar nya och befintliga 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 skulle vara så framgångsrik som den är utan hela samhällets medvetna ansträngningar, där människor håller ihop men samtidigt välkomnar nykomlingar i fållan.
Framtiden
En av de största utmaningarna som utvecklare kommer att behöva hantera i framtiden är förmågan att fokusera på detaljerna i själva koden, och inte på infrastrukturen som den körs i. Den möter dessa trender , som är en av de ledande idag. Avancerade ramverk finns redan, t.ex. и , som använder Kubernetes för att abstrahera infrastrukturen 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 det bara toppen av isberget. Kubernetes-användare har många andra resurser, möjligheter och konfigurationer till sitt förfogande.
Källa: will.com