Hei Habr!
På slutten av sommeren vil vi minne om at vi jobber videre med temaet og bestemte seg for å publisere en artikkel fra Stackoverflow som demonstrerer tingenes tilstand i dette prosjektet i begynnelsen av juni.
Liker å lese!
På tidspunktet for skriving av denne artikkelen er alderen til Kubernetes ca. , og i løpet av de siste to årene har populariteten vokst så mye at den er konsekvent rangert blant plattformer. Kubernetes ligger på tredjeplass i år. For å oppsummere: Kubernetes er en plattform designet for å kjøre og orkestrere containeriserte arbeidsmengder.
Beholdere begynte som et spesielt design for å isolere prosesser i Linux; containere har inkludert siden 2007 , og siden 2002 – navnerom. Containere ble designet enda bedre innen 2008, da den ble tilgjengelig , og Google utviklet sin egen interne bedriftsmekanisme kalt , hvor "alt arbeid utføres i containere." Herfra spoler vi videre til 2013, da den første utgivelsen av Docker fant sted, og containere endelig ble en populær masseløsning. På den tiden var hovedverktøyet for containerorkestrering , selv om han ikke var veldig populær. Kubernetes ble først utgitt i 2015, hvoretter dette verktøyet ble de facto-standarden innen containerorkestrering.
For å prøve å forstå hvorfor Kubernetes er så populær, la oss prøve å svare på noen spørsmål. Når var siste gang utviklere var i stand til å bli enige om hvordan de skulle distribuere applikasjoner til produksjon? Hvor mange utviklere kjenner du som bruker verktøyene når de leveres ut av esken? Hvor mange skyadministratorer er det i dag som ikke forstår hvordan applikasjoner fungerer? Vi vil se på svarene på disse spørsmålene i denne artikkelen.
Infrastruktur som YAML
I verden som gikk fra Puppet and Chef til Kubernetes, var en av de største endringene overgangen fra «infrastruktur som kode» til «infrastruktur som data» – nærmere bestemt som YAML. Alle ressurser i Kubernetes, som inkluderer pods, konfigurasjoner, distribuerte forekomster, volumer osv., kan enkelt 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 visningen gjør det enklere for DevOps- eller SRE-profesjonelle å uttrykke arbeidsbelastningene sine fullt ut uten å måtte skrive kode på språk som Python eller Javascript.
Andre fordeler med å organisere infrastruktur som data inkluderer:
- GitOps eller Git Operations versjonskontroll. Denne tilnærmingen lar deg beholde alle Kubernetes YAML-filer i git-repositories, slik at du kan spore nøyaktig når en endring ble gjort, hvem som gjorde den, og nøyaktig hva som endret seg. Dette øker transparensen av operasjoner i hele organisasjonen og forbedrer operasjonell effektivitet ved å eliminere tvetydighet, spesielt hvor ansatte skal se etter ressursene de trenger. Samtidig blir det enklere å automatisk gjøre endringer i Kubernetes-ressurser ved å slå sammen en pull-forespørsel.
- Skalerbarhet. Når ressurser er definert som YAML, blir det ekstremt enkelt for klyngeoperatører å endre ett eller to tall i en Kubernetes-ressurs, og dermed endre hvordan den skaleres. Kubernetes tilbyr en mekanisme for horisontal autoskalering av pods, som kan brukes til å enkelt bestemme hvilket minimum og maksimum antall pods som kreves i en bestemt distribusjonskonfigurasjon for å håndtere lave og høye nivåer av trafikk. Hvis du for eksempel har implementert en konfigurasjon som krever ekstra kapasitet på grunn av en plutselig økning i trafikken, kan maxReplicas endres 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- Sikkerhet og ledelse. YAML er flott for å evaluere hvordan ting distribueres i Kubernetes. Et stort sikkerhetsproblem gjelder for eksempel om arbeidsbelastningene dine kjører som en ikke-administratorbruker. I dette tilfellet kan vi trenge verktøy som f.eks , YAML/JSON-validator, pluss , en policyvalidator for å sikre at konteksten arbeidsbelastningene dine tillater ikke beholderen å kjøre med administratorrettigheter. Hvis dette er nødvendig, kan brukere bruke en enkel policy , som dette:
package main
deny[msg] {
input.kind = "Deployment"
not input.spec.template.spec.securityContext.runAsNonRoot = true
msg = "Containers must not run as root"
}- Alternativer for integrasjon med en skyleverandør. En av de mest bemerkelsesverdige trendene i dagens høyteknologi er å kjøre arbeidsbelastninger på offentlige skyleverandører. Bruke komponenten Kubernetes lar enhver klynge integreres med skyleverandøren den kjører på. For eksempel, hvis en bruker kjører en applikasjon i Kubernetes på AWS og ønsker å eksponere den applikasjonen gjennom en tjeneste, hjelper skyleverandøren automatisk med å opprette tjenesten
LoadBalancersom automatisk gir lastbalanseren for å omdirigere trafikk til applikasjonsputer.
Utvidbarhet
Kubernetes er veldig utvidbar og utviklere elsker det. Det er et sett med tilgjengelige ressurser som pods, distribusjoner, StatefulSets, hemmeligheter, ConfigMaps, etc. Riktignok kan brukere og utviklere legge til andre ressurser i skjemaet .
For eksempel hvis vi ønsker å definere en ressurs CronTab, så kan du gjøre noe slikt:
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 lage en CronTab-ressurs som dette:
apiVersion: "my.org/v1"
kind: CronTab
metadata:
name: my-cron-object
spec:
cronSpec: "* * * * */5"
image: my-cron-image
replicas: 5
Et annet alternativ for utvidbarhet i Kubernetes er at utvikleren kan skrive sine egne uttalelser. er en spesiell prosess i Kubernetes-klyngen som fungerer i henhold til "" Ved hjelp av en operatør kan brukeren automatisere administrasjonen av CRD-er (tilpassede ressursdefinisjoner) ved å utveksle informasjon med Kubernetes API.
Det finnes flere verktøy i fellesskapet som gjør det enkelt for utviklere å lage sine egne operatører. Blant dem - og . Denne SDK-en gir et grunnlag som en utvikler raskt kan begynne å opprette en operatør fra. La oss si at du kan starte fra kommandolinjen noe slikt:
$ operator-sdk new my-operator --repo github.com/myuser/my-operatorDette oppretter all kjelekode for operatøren din, inkludert 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.goDeretter kan du legge til de nødvendige API-ene og kontrolleren, slik:
$ operator-sdk add api --api-version=myapp.com/v1alpha1 --kind=MyAppService
$ operator-sdk add controller --api-version=myapp.com/v1alpha1 --kind=MyAppServiceDeretter, til slutt, sett sammen operatøren og send den til registret til beholderen din:
$ operator-sdk build your.container.registry/youruser/myapp-operator
Hvis utvikleren ønsker enda mer kontroll, kan standardkoden i Go-filer endres. For å endre detaljene til kontrolleren, kan du for eksempel gjøre endringer i filen controller.go.
Et annet prosjekt , lar deg lage utsagn med kun deklarative YAML-filer. For eksempel vil en operatør for Apache Kafka være definert omtrentlig . Med den kan du installere en Kafka-klynge på toppen av Kubernetes med bare et par kommandoer:
$ kubectl kudo install zookeeper
$ kubectl kudo install kafkaOg konfigurer den med en annen 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
innovasjoner
I løpet av de siste årene har store Kubernetes-utgivelser kommet ut med noen måneders mellomrom - det vil si tre til fire store utgivelser per år. Antallet nye funksjoner introdusert i hver av dem reduseres ikke. Dessuten er det ingen tegn til å bremse selv i disse vanskelige tidene – se på hvordan situasjonen er nå .
Nye funksjoner lar deg gruppere operasjoner mer fleksibelt på tvers av ulike arbeidsmengder. I tillegg får programmerere større kontroll når de distribuerer applikasjoner direkte til produksjon.
Samfunnet
Et annet viktig aspekt ved Kubernetes' popularitet er styrken til fellesskapet. I 2015, etter å ha nådd versjon 1.0, ble Kubernetes sponset av .
Det finnes også ulike samfunn (Special Interest Groups) fokuserte på å jobbe med ulike områder av Kubernetes etter hvert som prosjektet utvikler seg. Disse gruppene legger stadig til nye funksjoner, noe som gjør arbeidet med Kubernetes mer praktisk og praktisk.
Cloud Native Foundation er også vertskap for CloudNativeCon/KubeCon, som i skrivende stund er den største åpen kildekodekonferansen i verden. Den arrangeres vanligvis tre ganger i året, og samler tusenvis av fagfolk som ønsker å forbedre Kubernetes og dets økosystem, samt lære nye funksjoner som vises hver tredje måned.
Dessuten har Cloud Native Foundation , som sammen med SIGs gjennomgår nye og eksisterende midler fokusert på skyøkosystemet. De fleste av disse prosjektene bidrar til å forbedre styrken til Kubernetes.
Til slutt tror jeg at Kubernetes ikke ville vært så vellykket som det er uten den bevisste innsatsen fra hele samfunnet, der folk holder sammen, men samtidig ønsker nykommere velkommen inn i folden.
Fremtiden
En av hovedutfordringene som utviklere vil måtte håndtere i fremtiden er muligheten til å fokusere på detaljene i selve koden, og ikke på infrastrukturen den kjører i. Den møter disse trendene , som er en av de ledende i dag. Avanserte rammeverk finnes allerede, f.eks. и , som bruker Kubernetes for å abstrahere infrastrukturen fra utvikleren.
I denne artikkelen har vi bare skrapet på overflaten av den nåværende staten Kubernetes – faktisk er det bare toppen av isfjellet. Kubernetes-brukere har mange andre ressurser, muligheter og konfigurasjoner til rådighet.
Kilde: www.habr.com