Langt fra alle serverplatforme, selv de mest kraftfulde og skalerbare, opfylder alle behov, som de er. Selvom Kubernetes fungerer fremragende for sig selv, kan det mangle de nødvendige komponenter for at være fuldendt. Du vil altid finde et særligt tilfælde, der ignorerer dit behov, eller hvor Kubernetes ikke fungerer med standardinstallationen — for eksempel database understøttelse eller CD-arbejde.
Her kommer tilføjelser, udvidelser og andre lækkerier til denne containerorkestrator, understøttet af et bredt fællesskab. I denne artikel vil vi præsentere 11 bedste ting, vi har fundet. Vi selv i de er meget interessante, og vi planlægger at undersøge dem praktisk — skrue dem ned og se, hvad der er indeni. Nogle af dem vil perfekt supplere enhver Kubernetes-klynge, mens andre vil hjælpe med at løse specifikke opgaver, der ikke er implementeret i standardleveringen af Kubernetes.
Gatekeeper: politikstyring
Projekt (OPA) giver mulighed for at skabe politikker ovenpå cloud-applikationsstakke i Kubernetes, fra ingress til service mesh. giver en indbygget Kubernetes-funktion til automatisk håndhævelse af politikker i klyngen samt giver kontrol over enhver begivenhed eller ressource, der overtræder politikken. Alt dette behandles af en relativt ny mekanisme i Kubernetes, en webhook-godkendelsesagent, der aktiveres ved ændring af ressourcer. Ved hjælp af Gatekeeper bliver OPA-politikker en del af status for din Kubernetes-klynge, uden behov for konstant overvågning.
Gravity: Transportable Kubernetes-klynger
Hvis du ønsker at implementere en applikation i Kubernetes, har mange applikationer et Helm-diagram, der guider og automatiserer denne proces. Men hvad hvis du vil tage din Kubernetes-klynge "som den er" og rulle den ud et andet sted?
tager snapshots af tilstanden af Kubernetes-klynger, deres registry til containerbilleder samt kørende applikationer, kaldet "applikationspakker". En sådan pakke, der repræsenterer en almindelig fil .tar, kan replikere klyngen overalt, hvor Kubernetes kan køre.
Gravity kontrollerer også, at den målrettede infrastruktur opfører sig som den oprindelige, samt at Kubernetes-miljøet på målet er tilgængeligt. Den betalte version af Gravity tilføjer også sikkerhedsfunktioner, herunder RBAC og muligheden for at synkronisere sikkerhedsindstillinger på tværs af forskellige cluster-implementeringer.
Den seneste hovedversion, Gravity 7, kan implementere et Gravity-billede i et eksisterende Kubernetes-cluster i stedet for at oprette et helt nyt cluster fra billedet. Gravity 7 kan også arbejde med cluster-installationer, der er oprettet uden brug af Gravity-billedet. Desuden understøtter Gravity SELinux og fungerer nativt med Teleport SSH-gatewayen.
Kaniko: Bygning af containere i Kubernetes-clusteret
De fleste containerbilleder bygges på systemer uden for containerstakken. Men nogle gange er det nødvendigt at bygge et billede inden for containerstakken, for eksempel et sted i en kørende container eller i et Kubernetes-cluster.
opbygger containere inden for et container-miljø, men uden afhængighed af en containeriseringsservice, som f.eks. Docker. I stedet trækker Kaniko filsystemet fra basebilledet, udfører alle bygkommandorer i brugerrummet oven på det udtrukne filsystem og laver et snapshot af filsystemet efter hver kommando.
Bemærk: Kaniko kan i øjeblikket (maj 2020) oversætterens bemærkning) ikke samle Windows-containere.
Kubecost: Omkostninger ved at køre Kubernetes
De fleste Kubernetes-administrationsværktøjer er fokuseret på brugervenlighed, overvågning, forståelse af adfærd inden for pods osv. Men hvad med at overvåge omkostningerne — i kroner og øre — forbundet med at køre Kubernetes?
behandler Kubernetes-omkostninger i realtid, hvilket giver information om de aktuelle omkostninger fra kørende clusters hos de største cloud-leverandører, som vises på et dashboard med månedlige omkostninger for hvert cluster. Priser for RAM, CPU-tid, GPU og disk-komponenter opdeles efter Kubernetes-elementer (container, pod, service osv.).
Kubecost sporer også omkostninger til ressourcer uden for klyngen, såsom Amazon S3-buckets, selvom det er begrænset til AWS. Omkostningsdata kan sendes til Prometheus, så du kan bruge dem til at ændre klyngens adfærd programmatisk.
Kubecost er gratis at bruge, hvis du er tilfreds med dataene i logfilerne i 15 dage. For yderligere funktioner starter priserne ved 199$ om måneden for overvågning af 50 noder.
KubeDB: Kørsel af produktions databaser i Kubernetes
Det er også ret komplekst at køre databaser effektivt i Kubernetes. Du vil finde Kubernetes-operatører til MySQL, PostgreSQL, MongoDB og Redis, men de har alle ulemper. Også det typiske funktionssæt for Kubernetes løser ikke direkte de fleste specifikke databaseproblemer.
hjælper dig med at oprette dine egne Kubernetes-operatører til databaseadministration. Backup, kloning, overvågning, snapshots og deklarativ databaseoprettelse er dets komponenter. Vær opmærksom på, at understøttelse af funktioner afhænger af databasen. For eksempel fungerer klyngeoprettelse for PostgreSQL, men ikke for MySQL ( der er, som korrekt bemærket , oversætterens bemærkning).
Kube-monkey: Chaos Monkey for Kubernetes
Den mest fejlsikre metode til stresstest anses for at være tilfældige fejl. Denne teori ligger til grund for Chaos Monkey fra Netflix, et kaotisk ingeniørværktøj, der tilfældigt slukker virtuelle maskiner og containere i produktionsmiljøet for at "stimulere" udviklere til at skabe mere robuste systemer. er en implementering af den samme grundlæggende teori om stresstest for Kubernetes-klynger. Det fungerer ved tilfældigt at dræbe de moduler i klyngen, som du tildeler, og kan også indstilles til at arbejde i bestemte tidsintervaller.
Kubernetes Ingress Controller til AWS
Kubernetes leverer en ekstern belastningsaflastning og netværkstjenester til klyngen gennem en tjeneste kaldet AWS tilbyder belastningsaflastningsfunktioner, men kobler dem ikke automatisk til de samme muligheder i Kubernetes. fylder dette hul.
Det administrerer automatisk AWS-ressourcer for hver ingress-objekt i klyngen, opretter belastningsbalancer for nye ingress-ressourcer og fjerner belastningsbalancer, når ressourcer slettes. Det bruger CloudFormation til at sikre, at klyngens tilstand forbliver intakt. Det understøtter også CloudWatch Alarm-indstillinger og administrerer automatisk andre elementer, der anvendes i klyngen, såsom SSL-certifikater og EC2 Auto Scaling Groups.
Kubespray: Automatisk installation af Kubernetes
automatiserer installationen af en produktionsklar Kubernetes-klynge, fra installation på 'bare metal'-servere til de store offentlige skyer. Det bruger Ansible (Vagrant — valgfrit) til at udføre implementeringen og oprette en højtilgængelig klynge fra bunden med det valgte netværks-plugin (f.eks. Flannel, Calico osv.) på det valgte populære Linux-distribution ved installation på 'bare metal'-servere.
Skaffold: Iterativ udvikling for Kubernetes
er et af Googles værktøjer, der bruges til at organisere CD-applikationer i Kubernetes. Så snart du foretager ændringer i kildekoden — identificerer skaffold automatisk dette, lancerer bygning og deployment, og advarer dig, hvis der er nogen fejl. Skaffold kører fuldt ud på klientsiden, så der kan være nogle små nuancer med installation eller opdatering. Det kan bruges med eksisterende CICD-pipelines og interagere med nogle eksterne byggeværktøjer, primært Bazel fra Google.
Teresa: Den enkleste PaaS på Kubernetes
er et system til implementering af applikationer, der kører den enkleste PaaS oven på Kubernetes. Brugere, opdelt i teams, kan implementere og administrere deres egne applikationer. Det gør det lidt lettere for folk, der stoler på denne applikation, og som ikke ønsker at håndtere Kubernetes og alle dets kompleksiteter.
Tilt: Strømmende opdateringer af containere til Kubernetes-klynger
, udviklet af Windmill Engineering, overvåger ændringer i forskellige Dockerfile-filer og ruller derefter gradvist de relevante containere ud i Kubernetes-klyngen. Det gør det muligt at opdatere den aktive klynge i realtid ved blot at opdatere Dockerfile-filerne. Tilt udfører bygningen inde i klyngen; kildekoden er alt, hvad du behøver at ændre. Du kan også tage et snapshot af klyngens tilstand og fastsætte fejludløsningsbetingelser direkte fra Tilt for at dele dem med teammedlemmer til fejlretning.
P.S. Vi har gang på gang testet alle disse værktøjer med vores nysgerrige hænder. For at præsentere reelle praksisser allerede (forhåbentlig!) ved offline-intensiverne i februar. 8–10 februar 2021. Og 12–14 februar. Ærligt talt, vi savner også den varme og energiske atmosfære ved offline-uddannelse. Uanset hvor avanceret teknologien er, kan den ikke erstatte det levende menneskelige samvær og den særlige atmosfære, når ligesindede samles.
Kilde: habr.com
