Helm Sikkerhed

Essensen af ​​historien om den mest populære pakkehåndtering til Kubernetes kunne afbildes ved hjælp af en emoji:

• boksen er Helm (som er det tætteste på den seneste Emoji-udgivelse);
• lås - sikkerhed;
• den lille mand er løsningen på problemet.

Faktisk vil alt være lidt mere kompliceret, og historien er fuld af tekniske detaljer om Sådan gør du Helm sikker.

• Kort, hvad Helm er, hvis du ikke vidste det eller glemte det. Hvilke problemer løser det, og hvor er det placeret i økosystemet.
• Lad os se på Helm-arkitekturen. Ingen samtale om sikkerhed og hvordan man gør et værktøj eller en løsning mere sikker er komplet uden at forstå komponentens arkitektur.
• Lad os diskutere Helm-komponenter.
• Det mest brændende spørgsmål er fremtiden - den nye version af Helm 3. 

Alt i denne artikel gælder for Helm 2. Denne version er i øjeblikket i produktion og er højst sandsynlig den, du bruger i øjeblikket, og det er den version, der indeholder sikkerhedsrisici.

Om taleren: Alexander Khayorov (allexx) har udviklet sig i 10 år og bidraget til at forbedre indholdet Moskva Python Conf++ og kom med i udvalget Helm Topmøde. Nu arbejder han hos Chainstack som udviklingsleder – dette er en hybrid mellem en udviklingschef og en person, der er ansvarlig for at levere endelige udgivelser. Det vil sige, at det er placeret på slagmarken, hvor alt sker fra skabelsen af ​​et produkt til dets drift.

Chainstack er en lille, aktivt voksende startup, hvis mission er at give kunderne mulighed for at glemme alt om infrastrukturen og kompleksiteten ved drift af decentrale applikationer; udviklingsteamet er placeret i Singapore. Spørg ikke Chainstack om at sælge eller købe kryptovaluta, men tilbud at tale om enterprise blockchain-rammer, og de vil med glæde svare dig.

Helm

Dette er en pakke (diagram) manager til Kubernetes. Den mest intuitive og universelle måde at bringe applikationer til en Kubernetes-klynge.

Vi taler selvfølgelig om en mere strukturel og industriel tilgang end at lave dine egne YAML-manifester og skrive små hjælpeprogrammer.

Helm er det bedste, der er tilgængeligt og populært i øjeblikket.

Hvorfor Helm? Primært fordi det er støttet af CNCF. Cloud Native er en stor organisation og er moderselskab for projekter Kubernetes, etcd, Fluentd og andre.

En anden vigtig kendsgerning er, at Helm er et meget populært projekt. Da jeg begyndte at tale om, hvordan man gør Helm sikker i januar 2019, havde projektet tusind stjerner på GitHub. I maj var der 12 tusinde af dem.

Mange mennesker er interesserede i Helm, så selvom du ikke bruger det endnu, vil du have gavn af at kende til dets sikkerhed. Sikkerhed er vigtig.

Kerne Helm-teamet er understøttet af Microsoft Azure og er derfor et ret stabilt projekt i modsætning til mange andre. Udgivelsen af ​​Helm 3 Alpha 2 i midten af ​​juli indikerer, at der er ret mange mennesker, der arbejder på projektet, og de har lyst og energi til at udvikle og forbedre Helm.

Helm løser flere rodproblemer med applikationsstyring i Kubernetes.

• Applikationsemballage. Selv en applikation som "Hello, World" på WordPress består allerede af flere tjenester, og du vil gerne pakke dem sammen.
• Håndtering af kompleksiteten, der følger med at administrere disse applikationer.
• En livscyklus, der ikke slutter, efter at applikationen er installeret eller implementeret. Det fortsætter med at leve, det skal opdateres, og Helm hjælper med dette og forsøger at bringe de rigtige foranstaltninger og politikker til dette.

Bagning det er organiseret på en overskuelig måde: der er metadata i fuld overensstemmelse med arbejdet i en almindelig pakkeadministrator til Linux, Windows eller MacOS. Det vil sige et lager, afhængigheder af forskellige pakker, metainformation til applikationer, indstillinger, konfigurationsfunktioner, informationsindeksering osv. Helm giver dig mulighed for at få og bruge alt dette til applikationer.

Kompleksitetsstyring. Hvis du har mange applikationer af samme type, så er parameterisering nødvendig. Skabeloner kommer fra dette, men i stedet for at skulle finde på din egen måde at skabe skabeloner på, kan du bruge det, som Helm tilbyder ud af boksen.

Application Lifecycle Management - efter min mening er dette det mest interessante og uafklarede spørgsmål. Det er derfor, jeg kom til Helm dengang. Vi havde brug for at holde øje med applikationens livscyklus og ønskede at flytte vores CI/CD og applikationscyklusser til dette paradigme.

Helm giver dig mulighed for at:

• administrere implementeringer, introducerer begrebet konfiguration og revision;
• gennemføre rollback med succes;
• brug kroge til forskellige begivenheder;
• tilføje yderligere applikationskontrol og svare på deres resultater.

Endvidere Hjelm har "batterier" - et stort antal velsmagende ting, der kan inkluderes i form af plugins, der forenkler dit liv. Plugins kan skrives uafhængigt, de er ret isolerede og kræver ikke en harmonisk arkitektur. Hvis du vil implementere noget, anbefaler jeg at gøre det som et plugin, og så eventuelt inkludere det i upstream.

Helm er baseret på tre hovedkoncepter:

• Chart Repo — beskrivelse og række af parametriseringer mulige for dit manifest. 
• Config - det vil sige de værdier, der vil blive anvendt (tekst, numeriske værdier osv.).
• Slip samler de to øverste komponenter, og tilsammen bliver de til Release. Udgivelser kan versioneres og derved opnå en organiseret livscyklus: lille på installationstidspunktet og stor på tidspunktet for opgradering, nedgradering eller tilbagerulning.

Hjelm arkitektur

Diagrammet skildrer konceptuelt Helms arkitektur på højt niveau.

Lad mig minde dig om, at Helm er noget relateret til Kubernetes. Derfor kan vi ikke undvære en Kubernetes-klynge (rektangel). Kube-apiserver-komponenten ligger på masteren. Uden Helm har vi Kubeconfig. Helm bringer en lille binær, hvis man kan kalde det sådan, Helm CLI-værktøjet, som er installeret på en computer, bærbar computer, mainframe - på hvad som helst.

Men det er ikke nok. Helm har en serverkomponent kaldet Tiller. Det repræsenterer Helms interesser i klyngen; det er en applikation i Kubernetes-klyngen, ligesom alle andre.

Den næste komponent i Chart Repo er et depot med diagrammer. Der er et officielt depot, og der kan være et privat depot for en virksomhed eller et projekt.

Interaktion

Lad os se på, hvordan arkitekturkomponenterne interagerer, når vi vil installere en applikation ved hjælp af Helm.

• Vi taler Helm install, få adgang til depotet (Chart Repo) og få et Helm-diagram.

• Helm-værktøjet (Helm CLI) interagerer med Kubeconfig for at finde ud af, hvilken klynge der skal kontaktes. 
• Efter at have modtaget disse oplysninger, henviser værktøjet til Tiller, som er placeret i vores klynge, som en applikation. 
• Tiller kalder Kube-apiserver for at udføre handlinger i Kubernetes, oprette nogle objekter (tjenester, pods, replikaer, hemmeligheder osv.).

Dernæst vil vi komplicere diagrammet for at se den angrebsvektor, som hele Helm-arkitekturen som helhed kan blive udsat for. Og så vil vi prøve at beskytte hende.

Angrebsvektor

Det første potentielle svage punkt er privilegeret API—bruger. Som en del af ordningen er dette en hacker, der har fået administratoradgang til Helm CLI.

Uprivilegeret API-bruger kan også udgøre en fare, hvis det er et sted i nærheden. En sådan bruger vil have en anden kontekst, for eksempel kan han rettes i ét klyngenavneområde i Kubeconfig-indstillingerne.

Den mest interessante angrebsvektor kan være en proces, der ligger i en klynge et sted i nærheden af ​​Tiller og kan få adgang til den. Dette kan være en webserver eller mikrotjeneste, der ser klyngens netværksmiljø.

En eksotisk, men stadig mere populær angrebsvariant involverer Chart Repo. Et diagram lavet af en skruppelløs forfatter kan indeholde usikre ressourcer, og du vil fuldende det ved at tage det på tro. Eller det kan erstatte diagrammet, som du downloader fra det officielle lager og for eksempel oprette en ressource i form af politikker og eskalere dens adgang.

Lad os prøve at afværge angreb fra alle disse fire sider og finde ud af, hvor der er problemer i Helm-arkitekturen, og hvor der måske ikke er nogen.

Lad os forstørre diagrammet, tilføje flere elementer, men behold alle de grundlæggende komponenter.

Helm CLI kommunikerer med Chart Repo, interagerer med Kubeconfig, og arbejdet overføres til klyngen til Tiller-komponenten.

Tiller er repræsenteret af to objekter:

• Tiller-deploy svc, som afslører en bestemt tjeneste;
• Tiller-deploy pod (i diagrammet i en enkelt kopi i én replika), hvorpå hele belastningen kører, som får adgang til klyngen.

Forskellige protokoller og skemaer bruges til interaktion. Ud fra et sikkerhedsmæssigt synspunkt er vi mest interesserede i:

• Den mekanisme, hvorved Helm CLI'en får adgang til søkortrepoen: hvilken protokol, er der godkendelse, og hvad kan der gøres med den.
• Den protokol, hvormed Helm CLI, ved hjælp af kubectl, kommunikerer med Tiller. Dette er en RPC-server installeret inde i klyngen.
• Tiller selv er tilgængelig for mikrotjenester, der ligger i klyngen og interagerer med Kube-apiserveren.

Lad os diskutere alle disse områder i rækkefølge.

RBAC

Det nytter ikke at tale om sikkerhed for Helm eller nogen anden tjeneste i klyngen, medmindre RBAC er aktiveret.

Det ser ud til, at dette ikke er den seneste anbefaling, men jeg er sikker på, at mange mennesker stadig ikke har aktiveret RBAC, selv i produktionen, fordi det er meget ballade, og mange ting skal konfigureres. Jeg opfordrer dig dog til at gøre dette.

https://rbac.dev/ — webstedsadvokat for RBAC. Den indeholder en enorm mængde interessante materialer, som vil hjælpe dig med at sætte RBAC op, vise, hvorfor den er god, og hvordan du i bund og grund kan leve med den i produktionen.

Jeg vil prøve at forklare, hvordan Tiller og RBAC fungerer. Tiller arbejder inde i klyngen under en bestemt servicekonto. Typisk, hvis RBAC ikke er konfigureret, vil dette være superbrugeren. I den grundlæggende konfiguration vil Tiller være admin. Det er derfor, det ofte siges, at Tiller er en SSH-tunnel til din klynge. Faktisk er dette sandt, så du kan bruge en separat dedikeret servicekonto i stedet for standardservicekontoen i diagrammet ovenfor.

Når du initialiserer Helm og installerer det på serveren for første gang, kan du indstille servicekontoen vha --service-account. Dette giver dig mulighed for at bruge en bruger med det mindst nødvendige sæt rettigheder. Sandt nok bliver du nødt til at skabe sådan en "krans": Rolle og Rollebinding.

Desværre vil Helm ikke gøre dette for dig. Du eller din Kubernetes-klyngeadministrator skal forberede et sæt roller og rollebindinger til servicekontoen på forhånd for at bestå Helm.

Spørgsmålet opstår - hvad er forskellen mellem Rolle og ClusterRole? Forskellen er, at ClusterRole fungerer for alle navnerum, i modsætning til almindelige Roller og Rollebindinger, som kun virker for et specialiseret navneområde. Du kan konfigurere politikker for hele klyngen og alle navneområder eller tilpasset for hvert navneområde individuelt.

Det er værd at nævne, at RBAC løser et andet stort problem. Mange mennesker klager over, at Helm, desværre, ikke er multitenancy (understøtter ikke multitenancy). Hvis flere teams bruger en klynge og bruger Helm, er det dybest set umuligt at opsætte politikker og begrænse deres adgang inden for denne klynge, fordi der er en bestemt servicekonto, som Helm kører under, og den opretter alle ressourcerne i klyngen under den. , hvilket nogle gange meget ubelejligt. Dette er sandt - ligesom den binære fil selv, ligesom processen, Helm Tiller har intet begreb om multilejemål.

Der er dog en fantastisk måde, der giver dig mulighed for at køre Tiller flere gange i en klynge. Der er ikke noget problem med dette, Tiller kan lanceres i ethvert navneområde. Således kan du bruge RBAC, Kubeconfig som en kontekst og begrænse adgangen til en speciel Helm.

Det vil se sådan ud.

For eksempel er der to Kubeconfigs med kontekst for forskellige teams (to navnerum): X Team for udviklingsteamet og admin-klyngen. Admin-klyngen har sin egen brede Tiller, som er placeret i Kube-systemets navneområde, en tilsvarende avanceret servicekonto. Og et separat navneområde til udviklingsteamet, vil de være i stand til at implementere deres tjenester til et særligt navneområde.

Dette er en brugbar tilgang, Tiller er ikke så strømkrævende, at det i høj grad vil påvirke dit budget. Dette er en af ​​de hurtige løsninger.

Du er velkommen til at konfigurere Tiller separat og give Kubeconfig kontekst til teamet, for en specifik udvikler eller for miljøet: Dev, Staging, Production (det er tvivlsomt, at alt vil være på samme klynge, men dette kan lade sig gøre).

For at fortsætte vores historie, lad os skifte fra RBAC og tale om ConfigMaps.

ConfigMaps

Helm bruger ConfigMaps som datalager. Da vi talte om arkitektur, var der ingen database nogen steder, der kunne gemme information om udgivelser, konfigurationer, rollbacks osv. ConfigMaps bruges til dette.

Hovedproblemet med ConfigMaps er kendt - de er i princippet usikre; det er umuligt at gemme følsomme data. Vi taler om alt det, der ikke skal gå ud over tjenesten, for eksempel adgangskoder. Den mest oprindelige måde for Helm lige nu er at skifte fra at bruge ConfigMaps til hemmeligheder.

Dette gøres meget enkelt. Tilsidesæt Tiller-indstillingen og angiv, at lagringen skal være hemmeligheder. Så for hver implementering vil du ikke modtage et ConfigMap, men en hemmelighed.

Du kan argumentere for, at hemmeligheder i sig selv er et mærkeligt koncept og ikke særlig sikkert. Det er dog værd at forstå, at Kubernetes-udviklerne selv gør dette. Fra version 1.10, dvs. I et stykke tid har det været muligt, i det mindste i offentlige skyer, at forbinde det korrekte lager til at opbevare hemmeligheder. Holdet arbejder nu på måder til bedre at distribuere adgang til hemmeligheder, individuelle pods eller andre enheder.

Det er bedre at overføre Storage Helm til hemmeligheder, og de er til gengæld sikret centralt.

Det bliver selvfølgelig ved datalagringsgrænse på 1 MB. Helm her bruger etcd som distribueret lager til ConfigMaps. Og der mente de, at dette var en passende dataklump til replikering osv. Der er en interessant diskussion om dette på Reddit, jeg anbefaler at finde denne sjove læsning til weekenden eller læse uddraget her.

Kort Repos

Diagrammer er de mest socialt sårbare og kan blive en kilde til "Man in the middle", især hvis du bruger en aktieløsning. Først og fremmest taler vi om repositories, der eksponeres via HTTP.

Du skal helt sikkert eksponere Helm Repo over HTTPS - dette er den bedste mulighed og er billig.

Vær opmærksom på diagram signatur mekanisme. Teknologien er simpel som helvede. Dette er det samme, du bruger på GitHub, en almindelig PGP-maskine med offentlige og private nøgler. Konfigurer og vær sikker på, at have de nødvendige nøgler og underskrive alt, at dette virkelig er dit diagram.

Desuden Helm-klient understøtter TLS (ikke i HTTP-forstand på serversiden, men gensidig TLS). Du kan bruge server- og klientnøgler til at kommunikere. For at være ærlig bruger jeg ikke sådan en mekanisme, fordi jeg ikke kan lide gensidige certifikater. I bund og grund, kortmuseum - hovedværktøjet til opsætning af Helm Repo til Helm 2 - understøtter også grundlæggende godkendelse. Du kan bruge grundlæggende godkendelse, hvis det er mere bekvemt og mere støjsvagt.

Der er også et plugin ror-gcs, som giver dig mulighed for at hoste Chart Repos på Google Cloud Storage. Dette er ret praktisk, fungerer godt og er ret sikkert, fordi alle de beskrevne mekanismer genbruges.

Hvis du aktiverer HTTPS eller TLS, bruger mTLS og aktiverer grundlæggende godkendelse for yderligere at reducere risici, får du en sikker kommunikationskanal med Helm CLI og Chart Repo.

gRPC API

Det næste trin er meget vigtigt - at sikre Tiller, som er placeret i klyngen og på den ene side er en server, på den anden side får den selv adgang til andre komponenter og forsøger at udgive sig for at være nogen.

Som jeg allerede har sagt, er Tiller en tjeneste, der eksponerer gRPC, Helm-klienten kommer til det via gRPC. Som standard er TLS selvfølgelig deaktiveret. Hvorfor dette blev gjort er et diskutabelt spørgsmål, det forekommer mig at forenkle opsætningen i starten.

Til produktion og jævn iscenesættelse anbefaler jeg at aktivere TLS på gRPC.

Efter min mening, i modsætning til mTLS for diagrammer, er dette passende her og gøres meget enkelt - generer en PQI-infrastruktur, opret et certifikat, start Tiller, overfør certifikatet under initialisering. Herefter kan du udføre alle Helm-kommandoer og præsentere dig selv for det genererede certifikat og den private nøgle.

På denne måde vil du beskytte dig selv mod alle anmodninger til Tiller uden for klyngen.

Så vi har sikret forbindelseskanalen til Tiller, vi har allerede diskuteret RBAC og justeret rettighederne til Kubernetes apiserver, hvilket reducerer det domæne, som den kan interagere med.

Beskyttet Helm

Lad os se på det endelige diagram. Det er den samme arkitektur med de samme pile.

Alle forbindelser kan nu sikkert tegnes med grønt:

• til Chart Repo bruger vi TLS eller mTLS og grundlæggende godkendelse;
• mTLS for Tiller, og det er eksponeret som en gRPC service med TLS, vi bruger certifikater;
• klyngen bruger en speciel servicekonto med Rolle og Rollebinding. 

Vi har sikret klyngen betydeligt, men en smart sagde:

"Der kan kun være én absolut sikker løsning - en slukket computer, som er placeret i en betonkasse og bevogtet af soldater."

Der er forskellige måder at manipulere data og finde nye angrebsvektorer. Jeg er dog overbevist om, at disse anbefalinger vil opnå en grundlæggende industristandard for sikkerhed.

Bonus

Denne del er ikke direkte relateret til sikkerhed, men vil også være nyttig. Jeg vil vise dig nogle interessante ting, som de færreste kender til. For eksempel hvordan man søger efter diagrammer - officielle og uofficielle.

I depotet github.com/helm/charts Nu er der omkring 300 diagrammer og to vandløb: stald og inkubator. Alle, der bidrager, ved udmærket, hvor svært det er at komme fra inkubator til stald, og hvor let det er at flyve ud af stald. Dette er dog ikke det bedste værktøj til at søge efter diagrammer for Prometheus og hvad du ellers kan lide, af en simpel grund - det er ikke en portal, hvor du nemt kan søge efter pakker.

Men der er en service hub.helm.sh, hvilket gør det meget mere bekvemt at finde diagrammer. Vigtigst af alt er der mange flere eksterne repositories og næsten 800 charms tilgængelige. Plus, du kan tilslutte dit lager, hvis du af en eller anden grund ikke ønsker at sende dine diagrammer til stabile.

Prøv hub.helm.sh og lad os udvikle det sammen. Denne service er under Helm-projektet, og du kan endda bidrage til dens brugergrænseflade, hvis du er en frontend-udvikler og blot ønsker at forbedre udseendet.

Jeg vil også gerne henlede din opmærksomhed på Åbn Service Broker API-integration. Det lyder besværligt og uklart, men det løser problemer, som alle står over for. Lad mig forklare med et simpelt eksempel.

Der er en Kubernetes-klynge, hvor vi ønsker at køre en klassisk applikation - WordPress. Generelt er en database nødvendig for fuld funktionalitet. Der er mange forskellige løsninger, for eksempel kan du starte din egen statefull service. Dette er ikke særlig praktisk, men mange mennesker gør det.

Andre, som os hos Chainstack, bruger administrerede databaser som MySQL eller PostgreSQL til deres servere. Derfor er vores databaser placeret et sted i skyen.

Men der opstår et problem: Vi skal forbinde vores service med en database, skabe en databasesmag, overføre legitimationsoplysningerne og på en eller anden måde administrere den. Alt dette gøres normalt manuelt af systemadministratoren eller udvikleren. Og der er ikke noget problem, når der er få ansøgninger. Når der er mange af dem, skal du bruge en mejetærsker. Der er sådan en mejetærsker - det er Service Broker. Det giver dig mulighed for at bruge et specielt plugin til en offentlig cloud-klynge og bestille ressourcer fra udbyderen gennem Broker, som om det var en API. For at gøre dette kan du bruge native Kubernetes-værktøjer.

Det er meget enkelt. Du kan forespørge f.eks. Managed MySQL i Azure med et basisniveau (dette kan konfigureres). Ved hjælp af Azure API oprettes databasen og klargøres til brug. Du behøver ikke at blande dig i dette, plugin'et er ansvarlig for dette. For eksempel vil OSBA (Azure-plugin) returnere legitimationsoplysninger til tjenesten og videregive dem til Helm. Du vil være i stand til at bruge WordPress med cloud MySQL, slet ikke håndtere administrerede databaser og ikke bekymre dig om statefull-tjenester indeni.

Vi kan sige, at Helm fungerer som en lim, der på den ene side giver dig mulighed for at implementere tjenester, og på den anden side forbruge cloud-udbydernes ressourcer.

Du kan skrive dit eget plugin og bruge hele denne historie på stedet. Så har du blot dit eget plugin til virksomhedens Cloud-udbyder. Jeg anbefaler at prøve denne tilgang, især hvis du har en stor skala og hurtigt vil implementere dev, iscenesættelse eller hele infrastrukturen for en funktion. Dette vil gøre livet lettere for dine operationer eller DevOps.

Et andet fund, som jeg allerede har nævnt, er helm-gcs plugin, som giver dig mulighed for at bruge Google-buckets (objektopbevaring) til at gemme Helm-diagrammer.

Du behøver kun fire kommandoer for at begynde at bruge det:

1. installer plugin'et;
2. igangsætte det;
3. sæt stien til spanden, som er placeret i gcp;
4. udgive diagrammer på standard måde.

Skønheden er, at den native gcp-metode vil blive brugt til godkendelse. Du kan bruge en servicekonto, en udviklerkonto, hvad du vil. Det er meget praktisk og koster ingenting at betjene. Hvis du, ligesom jeg, fremmer opsless-filosofien, så vil dette være meget praktisk, især for små teams.

alternativer

Helm er ikke den eneste service management løsning. Der er mange spørgsmål om det, og det er nok derfor, den tredje version dukkede op så hurtigt. Selvfølgelig er der alternativer.

Det kan være specialiserede løsninger, for eksempel Ksonnet eller Metaparticle. Du kan bruge dine klassiske infrastrukturstyringsværktøjer (Ansible, Terraform, Chef osv.) til de samme formål, som jeg talte om.

Endelig er der en løsning Operatørramme, hvis popularitet vokser.

Operator Framework er det bedste Helm-alternativ at overveje.

Det er mere hjemmehørende i CNCF og Kubernetes, men adgangsbarrieren er meget højere, du skal programmere mere og beskrive manifester mindre.

Der er forskellige tilføjelser, såsom Draft, Scaffold. De gør livet meget lettere, for eksempel forenkler de cyklussen med at sende og lancere Helm, så udviklere kan implementere et testmiljø. Jeg vil kalde dem empowerers.

Her er et visuelt diagram over, hvor alt er.

På x-aksen er niveauet af din personlige kontrol over, hvad der sker, på y-aksen er niveauet af indfødte for Kubernetes. Helm version 2 falder et sted i midten. I version 3, ikke enormt, men både kontrol og niveauet af nativeness er blevet forbedret. Løsninger på Ksonnet-niveau er stadig ringere end Helm 2. Men de er værd at se på for at vide, hvad der ellers er i denne verden. Selvfølgelig vil din konfigurationsmanager være under din kontrol, men den er absolut ikke hjemmehørende i Kubernetes.

Operator Framework er helt naturligt hjemmehørende i Kubernetes og giver dig mulighed for at administrere det meget mere elegant og omhyggeligt (men husk om indgangsniveauet). Dette er snarere egnet til en specialiseret applikation og oprettelse af ledelse for det, snarere end en massehøster til emballering af et stort antal applikationer ved hjælp af Helm.

Udvidere forbedrer ganske enkelt kontrollen lidt, supplerer arbejdsgangen eller skærer hjørner på CI/CD-pipelines.

Fremtiden for Helm

Den gode nyhed er, at Helm 3 er på vej. Alfaversionen af ​​Helm 3.0.0-alpha.2 er allerede udgivet, du kan prøve den. Den er ret stabil, men funktionaliteten er stadig begrænset.

Hvorfor har du brug for Helm 3? Først og fremmest er dette en historie om Tillers forsvinden, som en komponent. Dette er, som du allerede forstår, et stort skridt fremad, for fra synspunktet om arkitekturens sikkerhed er alt forenklet.

Da Helm 2 blev skabt, som var omkring Kubernetes 1.8 eller endnu tidligere, var mange af koncepterne umodne. Eksempelvis bliver CRD-konceptet nu aktivt implementeret, og det vil Helm bruge CRDat opbevare strukturer. Det vil kun være muligt at bruge klienten og ikke vedligeholde serverdelen. Brug derfor indbyggede Kubernetes-kommandoer til at arbejde med strukturer og ressourcer. Dette er et stort skridt fremad.

Vises understøttelse af native OCI-depoter (Open Container Initiative). Dette er et kæmpe initiativ, og Helm er primært interesseret i at lægge sine diagrammer ud. Det kommer til det punkt, at for eksempel Docker Hub understøtter mange OCI-standarder. Jeg gætter ikke, men måske vil klassiske Docker repository-udbydere begynde at give dig muligheden for at være vært for dine Helm-diagrammer.

Den kontroversielle historie for mig er Lua støtte, som en skabelonmotor til at skrive scripts. Jeg er ikke en stor fan af Lua, men dette ville være en helt valgfri funktion. Jeg tjekkede dette 3 gange - det er ikke nødvendigt at bruge Lua. Derfor skal de, der ønsker at kunne bruge Lua, dem der kan lide Go, slutte sig til vores kæmpe lejr og bruge go-tmpl til dette.

Til sidst, hvad jeg helt klart manglede var skemafremkomst og datatypevalidering. Der vil ikke være flere problemer med int eller streng, ingen grund til at pakke nul ind i dobbelte anførselstegn. Et JSONS-skema vises, som giver dig mulighed for eksplicit at beskrive dette for værdier.

Vil blive kraftigt omarbejdet begivenhedsdrevet model. Det er allerede blevet begrebsmæssigt beskrevet. Se på Helm 3-grenen, og du vil se, hvor mange hændelser og hooks og andre ting, der er blevet tilføjet, hvilket vil forenkle og på den anden side tilføre kontrol over implementeringsprocesserne og reaktioner på dem.

Helm 3 bliver enklere, sikrere og sjovere, ikke fordi vi ikke kan lide Helm 2, men fordi Kubernetes bliver mere avanceret. Derfor kan Helm bruge udviklingen af ​​Kubernetes og skabe fremragende ledere til Kubernetes på den.

En anden god nyhed er det DevOpsConf Alexander Khayorov vil fortælle dig, kan containere være sikre? Lad os minde dig om, at konferencen om integration af udviklings-, test- og driftsprocesser vil blive afholdt i Moskva 30. september og 1. oktober. Du kan stadig gøre det indtil 20. august Indsend en rapport og fortæl os om din oplevelse med løsningen en af ​​mange opgaver i DevOps-tilgangen.

Følg konferencens kontrolpunkter og nyheder kl postliste и telegram kanal.

Kilde: www.habr.com