Ikke alle serverplatforme, selv de mest kraftfulde og skalerbare, opfylder alle behov, som de er. Selvom Kubernetes fungerer godt alene, mangler den muligvis de rigtige dele til at være komplet. Du vil altid finde en speciel sag, der ignorerer dit behov, eller hvor Kubernetes ikke vil fungere i standardinstallationen - for eksempel databaseunderstøttelse eller cd-drift.
Det er her tilføjelser, udvidelser og andre godbidder til denne containerorkestrator dukker op, støttet af et bredt fællesskab. Denne artikel vil indeholde de 11 bedste ting, vi fandt. Til os selv i de er meget interessante, og vi planlægger at håndtere dem praktisk talt - adskille dem i skruer og møtrikker og se, hvad der er indeni. Nogle af dem vil perfekt komplementere enhver Kubernetes-klynge, mens andre vil hjælpe med at løse specifikke problemer, der ikke er implementeret i Kubernetes-standardpakken.
Gatekeeper: Politikstyring
Projekt (OPA) giver mulighed for at oprette politikker oven på cloud-applikationsstakke i Kubernetes, fra indgang til servicemesh. giver den Kubernetes-indfødte mulighed for at håndhæve politikker automatisk på tværs af klyngen, og giver også inspektion af eventuelle hændelser eller ressourcer, der overtræder en politik. Alt dette håndteres af en relativt ny mekanisme i Kubernetes, Webhooks-admissionsmanageren, som udløses, når ressourcerne ændres. Med Gatekeeper bliver OPA-politikker endnu en del af sundheden for din Kubernetes-klynge uden behov for konstant tilsyn.
Tyngdekraft: Bærbare Kubernetes-klynger
Hvis du vil implementere en applikation til Kubernetes, har mange applikationer et Helm-diagram, der guider og automatiserer denne proces. Men hvad nu hvis du vil tage din Kubernetes-klynge som den er og rulle den ud et andet sted?
tager snapshots af tilstanden for Kubernetes-klynger, deres registre til containerbilleder og kører applikationer kaldet "applikationspakker". Sådan en pakke, som er en almindelig fil .tar, kan replikere klyngen overalt hvor Kubernetes kan køre.
Gravity verificerer også, at målinfrastrukturen opfører sig på samme måde som kilden, og 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 klyngeimplementeringer.
Den seneste større version, Gravity 7, kan rulle et Gravity-billede ud til en eksisterende Kubernetes-klynge, i stedet for at spinde en helt ny klynge op fra billedet. Gravity 7 kan også fungere med klynger installeret uden et Gravity-billede. Gravity understøtter også SELinux og fungerer indbygget med Teleport SSH-gatewayen.
Kaniko: Byg containere i en Kubernetes-klynge
De fleste containerbilleder er bygget på systemer uden for containerstakken. Nogle gange har du dog brug for at bygge et billede inde i en containerstak, for eksempel et sted i en kørende container eller i en Kubernetes-klynge.
bygger containere i et containermiljø, men uden at være afhængig af en containeriseringstjeneste, såsom Docker. I stedet udtrækker Kaniko filsystemet fra basisbilledet, kører alle build-kommandoer i brugerrummet oven på det udpakkede filsystem og tager et øjebliksbillede af filsystemet efter hver kommando.
Bemærk: Kaniko er i øjeblikket (maj 2020, ca. oversætter) kan ikke bygge Windows-containere.
Kubecost: Kubernetes startomkostningsparametre
De fleste Kubernetes-administrationsværktøjer fokuserer på brugervenlighed, overvågning, forståelse af adfærd i en pod osv. Men hvad med at se på omkostningerne - i dollars og øre - forbundet med at drive Kubernetes?
Behandler Kubernetes-parametre i realtid, hvilket resulterer i opdaterede omkostningsoplysninger fra kørende klynger på tværs af store cloud-udbydere, vist i et dashboard, der viser de månedlige omkostninger for hver klynge. Priser for RAM, CPU-tid, GPU og diskundersystem er opdelt efter Kubernetes-komponent (container, pod, service osv.)
Kubecost sporer også omkostningerne ved ressourcer uden for klyngen, såsom Amazon S3 buckets, selvom dette er begrænset til AWS. Omkostningsdata kan sendes til Prometheus, så du kan bruge dem til programmæssigt at ændre klyngens adfærd.
Kubecost er gratis at bruge, så længe 15 dages logdata er nok for dig. For yderligere funktioner starter priserne ved $199 om måneden for overvågning af 50 noder.
KubeDB: Kørsel af kampdatabaser på Kubernetes
Databaser er også ret svære at køre effektivt på Kubernetes. Du finder Kubernetes-operatører til MySQL, PostgreSQL, MongoDB og Redis, men de har alle ulemper. Desuden løser det typiske Kubernetes-funktionssæt ikke direkte de fleste specifikke databaseproblemer.
hjælper dig med at oprette dine Kubernetes-udsagn til at administrere databaser. Kørsel af sikkerhedskopier, kloning, overvågning, snapshots og deklarativ databaseoprettelse er dens komponenter. Bemærk venligst, at understøttelse af funktioner kan variere fra database til database. For eksempel fungerer oprettelse af en klynge for PostgreSQL, men ikke for MySQL ( der er, som korrekt bemærket , ca. oversætter).
Kube-abe: Chaos Monkey for Kubernetes
Den mest fejlfri metode til stresstest anses for at være tilfældige nedbrud. Det er teorien bag Netflix's Chaos Monkey, et kaotisk ingeniørværktøj, der tilfældigt lukker virtuelle maskiner og produktionscontainere ned for at "incitere" udviklere til at bygge mere modstandsdygtige systemer. — implementering af den samme grundlæggende teori om stresstest for Kubernetes-klynger. Det virker ved tilfældigt at dræbe pods i den klynge, som du udpeger, og kan også konfigureres til at køre med et bestemt tidsinterval.
Kubernetes Ingress Controller til AWS
Kubernetes leverer en ekstern belastningsbalancer og klyngenetværkstjenester gennem en tjeneste kaldet AWS leverer belastningsbalanceringsfunktionalitet, men forbinder det ikke automatisk med de samme muligheder i Kubernetes. lukker dette hul.
Den administrerer automatisk AWS-ressourcer for hvert indgangsobjekt i klyngen, opretter belastningsbalancere for nye indgangsressourcer og fjerner belastningsbalancere, når ressourcer slettes. Den bruger CloudFormation til at sikre, at klyngens tilstand forbliver konsistent. Den understøtter også CloudWatch Alarm-indstillinger og administrerer automatisk andre elementer, der bruges 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å hardwareservere til større offentlige skyer. Den bruger Ansible (Vagrant - valgfri) til at køre udrulningen og skabe en meget tilgængelig klynge fra bunden med dit valg af netværkstilføjelse (såsom Flannel, Calico og andre) på din valgte populære Linux-distribution, når den er installeret på hardwareservere.
Skaffold: Iterativ udvikling for Kubernetes
- et af Google-værktøjerne, der bruges til at organisere cd-applikationer i Kubernetes. Så snart du foretager ændringer i kildekoden, registrerer skaffold automatisk dette, begynder at bygge og implementere og advarer dig, hvis der er fejl. Skaffold kører udelukkende på klientsiden, så der kan være mindre installations- eller opdateringsproblemer. Det kan bruges med eksisterende CICD-pipelines og kan også interface med nogle eksterne byggeværktøjer, primært Googles Bazel.
Teresa: Den enkleste PaaS på Kubernetes
er et applikationsimplementeringssystem, der kører en simpel PaaS oven på Kubernetes. Brugere organiseret i teams kan implementere og administrere de applikationer, de ejer. Dette gør tingene lidt nemmere for folk, der har tillid til applikationen og ikke ønsker at håndtere Kubernetes og alle dens kompleksiteter.
Tilt: Streaming af containeropdateringer til Kubernetes-klynger
, udviklet af Windmill Engineering, holder øje med ændringer af forskellige Dockerfiler og implementerer derefter gradvist de tilsvarende containere til en Kubernetes-klynge. I det væsentlige giver det dig mulighed for at opdatere din produktionsklynge i realtid ved blot at opdatere Dockerfiles. Tilt builds i klyngen, kildekoden er alt, der skal ændres. Du kan også tage et øjebliksbillede af klyngens helbred og fange fejltilstande direkte fra Tilt for at dele med teammedlemmer til fejlretning.
PS Vi har gentagne gange brugt alle disse værktøjer sonderet med vores nysgerrige hænder. At præsentere reel praksis allerede (forhåbentlig!) ved offline intensive kurser i februar. 8.-10. februar 2021. Og 12-14 februar. Helt ærligt savner vi også den varme og energisk ladede atmosfære af offline læring. Uanset hvor avancerede teknologier er, kan de ikke erstatte levende menneskelig kommunikation og en særlig atmosfære, når ligesindede samles.
Kilde: www.habr.com