Ikke alle serverplattformer, selv de kraftigste og mest skalerbare, tilfredsstiller alle behov som de er. Selv om Kubernetes fungerer utmerket alene, kan den mangle de riktige delene for å være komplett. Du vil alltid finne en spesiell sak som ignorerer behovet ditt, eller hvor Kubernetes ikke vil fungere på en standardinstallasjon, for eksempel databasestøtte eller CD-drift.
Det er her tillegg, utvidelser og andre godbiter for denne containerorkestratoren dukker opp, støttet av det bredeste fellesskapet. I denne artikkelen vil det være 11 av de beste tingene vi fant. Vi selv i de er veldig interessante, og vi planlegger å håndtere dem praktisk talt - å demontere dem til skruer og muttere og se hva som er inni. Noen av dem vil perfekt utfylle enhver Kubernetes-klynge, mens andre vil hjelpe til med å løse spesielle oppgaver som ikke er implementert i den typiske Kubernetes-distribusjonen.
Portvakt: policystyring
Prosjekt (OPA) gir muligheten til å lage policyer på toppen av skyapplikasjonsstabler i Kubernetes, fra ingress til service mesh. gir Kubernetes innfødte evne til å håndheve retningslinjer på klyngen automatisk, og gir også inspeksjon for eventuelle hendelser eller ressurser som bryter retningslinjene. Alt dette håndteres av den relativt nye Kubernetes-mekanismen, Webhooks-opptaksbehandlingen, som utløses når ressursene endres. Med Gatekeeper blir OPA-policyer en annen del av tilstanden til Kubernetes-klyngen din uten behov for konstant tilsyn.
Tyngdekraft: Bærbare Kubernetes-klynger
Hvis du vil rulle ut en applikasjon til Kubernetes, har mange applikasjoner et Helm-diagram som veileder og automatiserer denne prosessen. Men hva om du vil ta Kubernetes-klyngen "som den er" og rulle den ut et annet sted?
tar øyeblikksbilder av Kubernetes-klynger, deres register for containerbilder, samt kjører applikasjoner kalt "applikasjonspakker". En slik pakke, som er en vanlig fil .tar, kan replikere klyngen hvor enn Kubernetes kan kjøre.
Gravity sjekker også at målinfrastrukturen oppfører seg på samme måte som kildeinfrastrukturen, og også at Kubernetes-miljøet på målet er tilgjengelig. Den betalte versjonen av Gravity legger også til sikkerhetsfunksjoner, inkludert RBAC og muligheten til å synkronisere sikkerhetsinnstillinger på tvers av forskjellige klyngedistribusjoner.
Den siste store utgivelsen, Gravity 7, kan skyve et Gravity-bilde inn i en eksisterende Kubernetes-klynge, i stedet for å spinne opp en helt ny klynge fra bildet. Gravity 7 kan også fungere med klynger installert uten å bruke Gravity-bildet. Gravity støtter også SELinux, og fungerer naturlig med Teleport SSH-gatewayen.
Kaniko: Bygge containere i en Kubernetes-klynge
De fleste containerbilder er bygget på systemer utenfor containerstabelen. Noen ganger må du imidlertid bygge bildet inne i en stabel med beholdere, for eksempel et sted i en løpende beholder, eller i en Kubernetes-klynge.
bygger containere inne i et containermiljø, men uten å være avhengig av en containeriseringstjeneste, for eksempel Docker. I stedet trekker Kaniko ut filsystemet fra basisbildet, utfører alle brukerplassbyggekommandoer på toppen av det utpakkede filsystemet, og tar et øyeblikksbilde av filsystemet etter hver kommando.
Merk: Kaniko er for øyeblikket (mai 2020, ca. oversetter) kan ikke bygge Windows-beholdere.
Kubecost: alternativer for Kubernetes oppstartskostnad
De fleste Kubernetes administrasjonsverktøy fokuserer på brukervennlighet, overvåking, forståelse av atferden inne i en pod, og så videre. Men hva med å overvåke kostnadene - i rubler og kopek - forbundet med lanseringen av Kubernetes?
behandler Kubernetes-parametere i sanntid, noe som resulterer i oppdatert kostnadsinformasjon fra kjørende klynger hos store skyleverandører, vist i et panel med månedlig kostnad per klynge. Prisene for RAM, CPU-tid, GPU og diskdelsystem er delt opp etter Kubernetes-komponenter (beholder, pod, service, etc.)
Kubecost sporer også kostnadene for ikke-klyngeressurser som Amazon S3-bøtter, selv om dette er begrenset av AWS. Kostnadsdataene kan sendes til Prometheus slik at du kan bruke dem til å endre klyngens oppførsel programmatisk.
Kubecost er gratis å bruke hvis du har nok 15 dager med loggdata. For tilleggsfunksjoner starter prisen på $199 månedlig for overvåking av 50 noder.
KubeDB: Kjøre kampdatabaser i Kubernetes
Databaser er også vanskelige å kjøre spektakulært i Kubernetes. Du finner Kubernetes-operatører for MySQL, PostgreSQL, MongoDB og Redis, men de har alle ulemper. Dessuten adresserer ikke det typiske Kubernetes-funksjonssettet direkte de fleste av de definerte databaseproblemene.
hjelper deg med å lage Kubernetes-uttalelser for databasebehandling. Kjøring av sikkerhetskopier, kloning, overvåking, øyeblikksbilder og deklarativ databaseoppretting er dens bestanddeler. Merk at funksjonsstøtte er databaseavhengig. For eksempel, å lage en klynge fungerer for PostgreSQL, men ikke for MySQL ( det er, som riktig påpekt , ca. oversetter).
Kube-monkey: Chaos Monkey for Kubernetes
Den mest feilfrie metoden for stresstesting anses å være tilfeldige sammenbrudd. Denne teorien er kjernen i Netflixs Chaos Monkey, et kaotisk ingeniørverktøy som tilfeldig slår av virtuelle maskiner og produksjonsmiljøbeholdere for å "incentivere" utviklere til å bygge mer motstandsdyktige systemer. - implementering av den samme grunnleggende teorien om stresstesting for Kubernetes-klynger. Det fungerer ved tilfeldig å drepe moduler i klyngen du utpeker, og kan også settes til å kjøre med et spesifikt tidsintervall.
Kubernetes Ingress Controller for AWS
Kubernetes tilbyr en ekstern lastbalanser og klyngenettverkstjenester gjennom en tjeneste kalt AWS tilbyr funksjoner for belastningsbalansering, men kombinerer dem ikke automatisk med de samme Kubernetes-funksjonene. tetter dette gapet.
Den administrerer automatisk AWS-ressurser for hver inngang i klyngen, oppretter lastbalansere for nye inngående ressurser og sletter lastbalansere når ressurser fjernes. Den bruker CloudFormation for å sikre at klyngetilstanden forblir konsistent. Den støtter også CloudWatch Alarm-innstillinger og administrerer automatisk andre elementer som brukes i klyngen, for eksempel SSL-sertifikater og EC2 Auto Scaling Groups.
Kubespray: Automatisk installasjon av Kubernetes
automatiserer installasjonen av en produksjonsklar Kubernetes-klynge, fra installasjon på maskinvareservere til store offentlige skyer. Den bruker Ansible (Vagrant valgfritt) for å kickstarte distribusjonen og lage en høytilgjengelighetsklynge fra bunnen av med ditt valg av nettverkstillegg (som Flannel, Calico, etc.) på ditt valg av populær Linux-distribusjon når den er installert på maskinvareservere.
Skaffold: Iterativ utvikling for Kubernetes
- et av Google-verktøyene som brukes til å organisere program-CDer i Kubernetes. Så snart du gjør endringer i kildekoden, oppdager skaffold dette automatisk, begynner å bygge og distribuere, og varsler deg hvis det er noen feil. Skaffold går helt på klientsiden, så det kan være små nyanser med installasjon eller oppdatering. Den kan brukes med eksisterende CICD-rørledninger samt samhandle med noen eksterne byggeverktøy, hovedsakelig Googles Bazel.
Teresa: Den enkleste PaaS på Kubernetes
er et applikasjonsdistribusjonssystem som kjører en enkel PaaS på toppen av Kubernetes. Teambrukere kan distribuere og administrere sine egne applikasjoner. Dette gjør ting litt enklere for folk som stoler på denne applikasjonen og ikke ønsker å håndtere Kubernetes og alle dens kompleksitet.
Tilt: Strøm beholderoppdateringer til Kubernetes-klynger
, utviklet av Windmill Engineering, overvåker endringer i forskjellige Dockerfiler og distribuerer deretter de riktige beholderne til Kubernetes-klyngen. I hovedsak lar det deg oppdatere produksjonsklyngen i sanntid ganske enkelt ved å oppdatere Dockerfiles. Tilt bygger inne i klyngen, kildekoden er alt som må endres. Du kan også ta et øyeblikksbilde av klyngetilstanden og fange opp feiltilstander direkte fra Tilt for å dele med teammedlemmer for feilsøking.
PS Alle disse verktøyene har vi gjentatte ganger i sondert med våre nysgjerrige hender. For å presentere ekte praksis allerede (forhåpentligvis!) på offline intensiver i februar. 8.–10. februar 2021. Og 12.–14. februar. Ærlig talt, vi savnet også den varme og energifylte atmosfæren til offline læring. Uansett hvor avansert teknologi er, vil de ikke erstatte levende menneskelig kommunikasjon og en spesiell atmosfære når likesinnede mennesker samles.
Kilde: www.habr.com