Sikkerhed i Helm

Essensen af historien om den mest populære pakkehåndtering til Kubernetes kunne illustreres med emojis:

• kassen – det er Helm (det mest passende i den seneste Emoji-udgave);
• låsen – sikkerhed;
• menneskefigur – løsningen på problemet.

I virkeligheden vil det dog være lidt mere kompliceret, og historien er fyldt med tekniske detaljer om, hvordan man gør Helm sikkert.

• Kort sagt, hvad er Helm, hvis du ikke vidste eller har glemt det. Hvilke problemer løser det, og hvor passer det ind i økosystemet.
• Lad os se på Helm-arkitekturen. Ingen samtale om sikkerhed og om, hvordan man gør et værktøj eller en løsning mere sikker, kan undgå at forstå komponentens arkitektur.
• Vi vil diskutere Helm-komponenterne.
• Det mest presserende spørgsmål – fremtiden – den nye version af Helm 3. 

Alt i denne artikel vedrører Helm 2. Denne version er i produktion nu, og det er sandsynligvis den, du bruger lige nu, og den indeholder sikkerhedstrusler.

Om taleren: Alexander Khayorov (allexx) har arbejdet med udvikling i 10 år og hjælper med at forbedre indholdet Moscow Python Conf++ og tilsluttede sig komiteen Helm Summit. Han arbejder nu hos Chainstack som utviklingsleder – en hybrid mellem en udviklingsleder og den, der er ansvarlig for leveringen af de endelige versioner. Det vil sige, han er i krigszonen, hvor alt sker fra produktets skabelse til dets drift.

Chainstack er en lille, hurtigt voksende startup, hvis opgave er at give kunderne mulighed for at glemme om infrastrukturer og kompleksiteter ved drift af decentraliserede applikationer; udviklingsteamet er baseret i Singapore. Bed ikke Chainstack om at sælge eller købe kryptovaluta, men tilbyd at tale om enterprise blockchain-rammer, så bliver du gladeligt besvaret.

Helm

Det er en pakkehåndtering (chart manager) til Kubernetes. Den mest klare og alsidige måde at bringe applikationer ind i et Kubernetes-klynge.

Det handler selvfølgelig om en mere struktureret og industriel tilgang end at oprette egne YAML-manifestationer og skrive små værktøjer.

Helm er det bedste, der lige nu er tilgængeligt og populært.

Hvorfor Helm? Først og fremmest fordi det støttes af CNCF. Cloud Native er en stor organisation, der er moderselskab for projekterne Kubernetes, etcd, Fluentd og andre.

En anden vigtig fakta er, at Helm er et meget populært projekt. Da jeg i januar 2019 første gang overvejede at fortælle, hvordan man gør Helm sikkert, havde projektet tusind stjerner på GitHub. I maj var de steget til 12.000.

Mange interesserer sig for Helm, så selvom du stadig ikke bruger det, vil din viden om dets sikkerhed være nyttig. Sikkerhed er vigtigt.

Den primære team for Helm understøttes af Microsoft Azure, og derfor er det et ret stabilt projekt i modsætning til mange andre. Udgivelsen af Helm 3 Alpha 2 i midten af juli vidner om, at der er mange mennesker, der arbejder på projektet, og de har vilje og styrke til at udvikle og forbedre Helm.

Helm løser flere grundlæggende problemer ved applikationshåndtering i Kubernetes.

• Paketering af applikationen. Selv en applikation som "Hello, World" på WordPress består allerede af flere tjenester, og de vil gerne blive pakket sammen.
• Håndtering af kompleksitet, der opstår med styring af disse applikationer.
• Livscyklus, der ikke slutter efter installationen eller deployment af applikationen. Den fortsætter med at eksistere, den skal opdateres, og Helm hjælper med det og stræber efter at bringe de rigtige tiltag og politikker.

Paketering er ordnet på en forståelig måde: der er metadata i fuld overensstemmelse med driften af en almindelig pakkeadministrator for Linux, Windows eller MacOS. Det vil sige, repository, afhængigheder mellem forskellige pakker, metadata for applikationer, indstillinger, konfigurationsspecifikationer, indeksering af information osv. Alt dette gør Helm muligt at få og bruge til applikationer.

Håndtering af kompleksitet. Hvis du har mange ensartede applikationer, kræves der parametrisering. Deraf følger skabeloner, men for ikke at skulle finde på din egen måde at oprette skabeloner på, kan du bruge det, som Helm tilbyder lige ud af boksen.

Applikationens livscyklushåndtering — efter min mening, det mest interessante og uløste spørgsmål. Det er grunden til, at jeg på et tidspunkt henvendte mig til Helm. Vi havde brug for at overvåge applikationens livscyklus, vi ønskede at flytte vores CI/CD og applikationscykler ind i denne paradyme.

Helm gør det muligt at:

• håndtere deployment, introducerer begrebet konfiguration og revision;
• gennemføre rollback succesfuldt;
• bruge hooks til forskellige begivenheder;
• tilføje ekstra kontroller af applikationer og reagere på deres resultater.

Derudover Helm har "batterier" — en enorm mængde lækre ting, som kan inkluderes som plugins for at gøre dit liv lettere. Plugins kan skrives selv, de er ret isolerede og kræver ikke en strømlinet arkitektur. Hvis du ønsker at implementere noget, anbefaler jeg at gøre det som et plugin, og derefter muligvis inkludere det i upstream.

Helm er baseret på tre hovedkoncept:

• Chart Repo — en beskrivelse og et sæt parametre, der er mulige for dit manifest. 
• Konfigurer — det vil sige værdier, der vil blive anvendt (tekst, numeriske værdier osv.).
• Release samler de to øverste komponenter, og sammen bliver de til et Release. Releases kan versioneres, hvilket giver en styring af livscyklussen: lille ved installation og stor ved opgradering, nedgradering eller rollback.

Helm-arkitektur

Diagrammet viser konceptuelt den højniveaue arkitektur af Helm.

Lad mig minde om, at Helm er noget, der er relateret til Kubernetes. Derfor kan vi ikke undvære et Kubernetes-kluster (rektangel). Komponent kube-apiserver er på masteren. Uden Helm har vi Kubeconfig. Helm bringer en lille binær, hvis man kan kalde det, værktøj Helm CLI, som installeres på computer, laptop, mainframe — på alt muligt.

Men det er ikke nok. Helm har en serverkomponent kaldet Tiller. Den repræsenterer Helm's interesser inden i klusteret, det er en applikation inden i Kubernetes-klusteret ligesom enhver anden.

Den næste komponent Chart Repo — et repository med charts. Der er et officielt repository, og der kan være et privat repository for virksomheden eller projektet.

Interaktion

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

• Vi siger Helm install, vi henvender os til repositoryet (Chart Repo) og får Helm-chartet.

• Helm-værktøjet (Helm CLI) interagerer med Kubeconfig for at finde ud af, hvilket kluster der skal tilgås. 
• Når denne information er indhentet, henvender værktøjet sig til Tiller, som findes i vores kluster, nu som en applikation. 
• Tiller henvender sig til Kube-apiserver for at udføre handlinger i Kubernetes, skabe nogle objekter (tjenester, pods, replikaer, hemmeligheder osv.).

Derefter vil vi komplicere diagrammet for at se angrebsvinklen, som hele Helm-arkitekturen kan udsættes for. Og derefter vil vi forsøge at beskytte den.

Angrebsvinkler

Det første potentielt svage punkt — privilegeret API—bruger. I dette tilfælde er det en hacker, der har fået adminadgang til Helm CLI.

Ikke-privilegeret API-bruger kan også udgøre en risiko, hvis de befinder sig et sted i nærheden. En sådan bruger vil have en anden kontekst, for eksempel kan de være låst i et bestemt namespace i klyngens Kubeconfig-indstillinger.

Den mest interessante angrebsvektor kan være en proces, der befinder sig inde i klyngen et sted nær Tiller og kan tilgå den. Dette kan være en webserver eller mikrotjeneste, der ser det netværksmiljø, som klyngen arbejder i.

En eksotisk, men stigende populær angrebsmetode er relateret til Chart Repo. Et chart, der er oprettet af en illoyal forfatter, kan indeholde usikre ressourcer, og du vil udføre det, idet du tager det for gode varer. Alternativt kan de ændre chartet, som du henter fra det officielle depot, og for eksempel oprette en ressource i form af politikker og eskalere deres adgang.

Lad os forsøge at forsvare os mod angreb fra alle disse fire sider og finde ud af, hvor der er problemer i Helm-arkitekturen, og hvor der muligvis ikke er.

Lad os udvide skemaet, tilføje flere elementer, men bevare alle de grundlæggende komponenter.

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

Tiller præsenteres af to objekter:

• Tiller-deploy svc, der udstiller en slags service;
• Tiller-deploy pod (i skemaet i en enkelt forekomst i en kopi), hvor al belastning kører og som tilgår klyngen.

Der anvendes forskellige protokoller og skemaer til interaktion. Fungerende sikkerhedsmæssigt er vi mest interesserede i:

• Mekanismen, hvormed Helm CLI tilgår chart repo: hvilken protokol, er der autentificering, og hvad kan der gøres med det.
• Protokollen, som Helm CLI bruger til at kommunikere med Tiller via kubectl. Dette er en RPC-server, der er installeret inde i klyngen.
• Tiller er tilgængelig for mikrotjenester, der befinder sig i klyngen, og interagerer med Kube-apiserver.

Lad os diskutere disse retninger ét ad gangen.

RBAC

Det er nytteløst at tale om nogen som helst sikkerhed i Helm eller andre tjenester inde i klyngen, hvis RBAC ikke er aktiveret.

Det virker ikke som den nyeste anbefaling, men jeg er sikker på, at mange stadig ikke har aktiveret RBAC, selv i produktion, fordi det kræver en stor indsats og meget opsætning. Jeg opfordrer dog til at gøre det.

https://rbac.dev/ — En advokatwebsite for RBAC. Her er samlet en enorm mængde interessante materialer, som kan hjælpe med at konfigurere RBAC, vise, hvorfor det er godt, og hvordan man generelt lever med det i produktion.

Jeg vil forsøge at forklare, hvordan Tiller og RBAC fungerer. Tiller arbejder inden for klyngen under en servicekonto. Som regel, hvis RBAC ikke er konfigureret, vil dette være superbruger. I den grundlæggende konfiguration vil Tiller være administrator. Derfor siger man ofte, at Tiller er en SSH-tunnel til din klynge. Det er faktisk sådan, så man kan bruge en separat, specialiseret servicekonto i stedet for Default Service Account i ovenstående diagram.

Når du initialiserer Helm og første gang installerer det på serveren, kan du angive servicekontoen ved hjælp af --service-account. Dette vil tillade brugen af en bruger med det mindst nødvendige sæt af rettigheder. Dog skal der oprettes en sådan "girland": Role og RoleBinding.

Desværre vil Helm ikke gøre dette for dig. Du eller din Kubernetes-klyngeadministrator skal på forhånd forberede et sæt af Role og RoleBinding for service-kontoen, så Helm kan anvende det.

Spørgsmålet opstår — hvad er forskellen mellem Role og ClusterRole? Forskellen er, at ClusterRole gælder for alle namespaces, i modsætning til almindelige Role og RoleBinding, der kun fungerer for en specifik namespace. Man kan konfigurere politikker både for hele klyngen og for alle namespaces, samt individuelt for hver namespace.

Det er værd at nævne, at RBAC også løser et andet stort problem. Mange klager over, at Helm desværre ikke er multitenancy (understøtter ikke multi-leje). Hvis flere teams bruger klyngen og anvender Helm, er det i princippet umuligt at konfigurere politikker og afgrænse deres adgang inden for denne klynge, fordi der er en vis servicekonto, som Helm kører under, og den opretter alle ressourcer i klyngen under den, hvilket kan være meget besværligt. Dette er sandt — ligesom selve binære filen, som proces, Har Helm Tiller ingen forståelse for multitenancy..

Der er dog en fantastisk måde, som gør det muligt at køre Tiller i klyngen flere gange. Der er ingen problemer med dette, Tiller kan startes i hver namespace. På den måde kan du udnytte RBAC, Kubeconfig som kontekst, og begrænse adgangen til en speciel Helm.

Det vil se sådan ud.

For example, there are two Kubeconfigs with contexts for different teams (two namespaces): X Team for the development team and the admin cluster. The admin cluster has its own extensive Tiller located in the Kube-system namespace, accordingly with an advanced service account. There is also a separate namespace for the development team; they will be able to deploy their services in a dedicated namespace.

This is a practical approach; Tiller is not so resource-intensive that it could significantly impact your budget. This is one of the quick solutions.

Feel free to configure Tiller separately and provide Kubeconfig with contexts for the team, a specific developer, or for environments: Dev, Staging, Production (though it's doubtful everything will be on one cluster, it is possible).

Continuing our story, let's switch from RBAC and talk about ConfigMaps.

ConfigMaps

Helm uses ConfigMaps as a data storage. When we talked about the architecture, there was no database storing information about releases, configurations, rollbacks, etc. ConfigMaps are used for this.

The main known issue with ConfigMaps is that they are inherently insecure; they cannot store sensitive data.This includes anything that should not go beyond the service, such as passwords. The most native way for Helm now is to switch from using ConfigMaps to secrets.

This is done very easily. You override the Tiller configuration and specify that the storage will be secrets. Then for each deployment, you will get a secret instead of a ConfigMap.

You may argue that secrets are a strange concept and not very secure. However, it's important to understand that the Kubernetes developers are handling this. Since version 1.10, which is quite some time ago, there has been the option, at least in public clouds, to connect the proper storage for storing secrets. The team is currently working on providing even better access to secrets for specific pods or other entities.

It’s better to transfer the Helm storage to secrets, and then secure them centrally.

Of course, there will still be a data storage limit of 1 MB.. Helm bruger her etcd som et distribueret lager til ConfigMaps. De har vurderet, at dette er et passende datchunk til replikering osv. Der er en interessant diskussion om dette på Reddit, jeg vil anbefale at finde denne underholdende læsning til weekenden eller læse et resumé. her.

Chart Repos

Charts er særligt socialt sårbare og kan blive en kilde til "Man in the middle", især hvis der anvendes en standardløsning. Dette gælder primært for de repositoryer, der er tilgængelige via HTTP.

Det er bestemt nødvendigt at offentliggøre Helm Repo via HTTPS — det er den bedste løsning og ikke dyr.

Bemærk venligst mekanisme til signering af charts. Teknologien er ufattelig simpel. Det er det samme, som du bruger på GitHub, en almindelig PGP-mekanisme med offentlige og private nøgler. Konfigurer det, og du kan være sikker, når du har de nødvendige nøgler og signerer alt, der reelt er dit chart.

Derudover, Helm-klienten understøtter TLS (ikke i betydningen HTTP fra serverens side, men gensidig TLS). Du kan bruge server- og klientnøgler til at kommunikere. Jeg må være ærlig, jeg bruger ikke denne mekanisme på grund af min modvilje mod gensidige certifikater. Grundlæggende, chartmuseum — det primære værktøj til at offentliggøre Helm Repo for Helm 2 — understøtter også basic auth. Du kan bruge basic auth, hvis det er mere bekvemt og giver større ro.

Der er også et plugin helm-gcs, som gør det muligt at hoste Chart Repos i Google Cloud Storage. Det er ret praktisk, fungerer fremragende og er tilstrækkeligt sikkert, fordi alle de beskrevne mekanismer udnyttes.

Hvis du aktiverer HTTPS eller TLS, bruger mTLS, tilføjer basic auth for at mindske risiciene, får du en sikker kommunikationskanal mellem Helm CLI og Chart Repo.

gRPC API

Det næste skridt er meget vigtigt — at sikre Tiller, som befinder sig i klyngen og er, på den ene side, serveren, på den anden side, henvender sig til andre komponenter og forsøger at præsentere sig selv som nogen anden.

Som jeg allerede har sagt, er Tiller en service, der tilbyder gRPC, og Helm-klienten henvender sig til den via gRPC. Som standard er TLS naturligvis slået fra. Hvorfor dette er tilfældet er et diskussionsemne, jeg mener, det er for at gøre opsætningen lettere i starten.

For produktion og endda for staging anbefaler jeg at aktivere TLS på gRPC.

Efter min mening er det i modsætning til mTLS for charts passende her og gøres meget enkelt - du genererer en PQI-infrastruktur, opretter et certifikat, starter Tiller og overfører certifikatet under initialiseringen. Derefter kan du udføre alle Helm-kommandoer ved at præsentere det genererede certifikat og den private nøgle.

Dermed beskytter du dig mod alle anmodninger til Tiller udefra klyngen.

Så vi har sikret forbindelsen til Tiller, allerede diskuteret RBAC og justeret rettighederne for Kubernetes apiserver, reduceret domænet, som det kan interagere med.

Sikret Helm

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

Alle forbindelser kan nu trygt tegnes grønne:

• til Chart Repo bruger vi TLS eller mTLS samt basic auth;
• mTLS for Tiller, som er oprettet som en gRPC-service med TLS, vi bruger certifikater;
• i klyngen bruges en speciel servicekonto med Role og RoleBinding. 

Vi har betydeligt sikret klyngen, men nogen klog person sagde:

„Der kan kun være én absolut sikker løsning - en slukket computer i en betonboks beskyttet af soldater.”

Der er forskellige måder at manipulere data og finde nye angrebsvektorer. Jeg er dog sikker på, at disse anbefalinger vil gøre det muligt at implementere en grundlæggende industriel sikkerhedsstandard.

Bonus

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

I lageret github.com/helm/charts der er nu omkring 300 charts og to streams: stable og incubator. Den, der bidrager, ved godt, hvor svært det er at gå fra incubator til stable, og hvor nemt det er at falde ud af stable. Dette er dog ikke det bedste værktøj til at finde charts til Prometheus og alt, hvad du kunne lide, af én simpel grund - det er ikke en portal, hvor det er nemt at søge efter pakker.

Men der er en service hub.helm.sh, som gør det meget lettere at finde charts. Det vigtigste er, at der er mange flere eksterne repositories, og næsten 800 charts er tilgængelige. Plus, du kan tilføje dit eget repository, hvis du af en eller anden grund ikke ønsker at sende dine charts til stable.

Prøv hub.helm.sh, og lad os udvikle det sammen. Denne service er under Helm-projektet, og du kan endda bidrage til dets UI, hvis du er frontend-udvikler og vil forbedre udseendet.

Jeg vil også gerne gøre opmærksom på Open Service Broker API-integration. Det lyder komplekst og uforståeligt, men løser problemer, som alle står over for. Jeg vil forklare med et simpelt eksempel.

Der er et Kubernetes-kluster, hvor vi ønsker at køre en klassisk applikation – WordPress. Som regel har man brug for en database for fuld funktionalitet. Der findes mange forskellige løsninger, for eksempel kan man starte sin egen stateful service. Det er ikke særlig praktisk, men mange gør det.

Andre, for eksempel os hos Chainstack, bruger managed databaser som MySQL eller PostgreSQL til serverne. Derfor ligger vores database et sted i skyen.

Men der opstår et problem: Vi skal forbinde vores service med databasen, oprette en database flavor, overføre legitimationsoplysninger og på en eller anden måde administrere dem. Alt dette gøres typisk manuelt af en systemadministrator eller udvikler. Og der er ingen problemer, når der er få applikationer. Når der er mange, er der brug for en kombajn. Den kombajn findes – det er Service Broker. Det gør det muligt at bruge en speciel plugin til offentlige cloud-klustre og bestille ressourcer fra udbyderen gennem Broker, som om det var et API. Dette kan gøres med de indbyggede værktøjer i Kubernetes.

Det er meget enkelt. Man kan for eksempel anmode om Managed MySQL i Azure med en grundplan (det kan tilpasses). Ved hjælp af API'en i Azure vil databasen blive oprettet og klargjort til brug. Du behøver ikke at involvere dig i dette; plugin'en tager sig af det. For eksempel vil OSBA (Azure-plugin) returnere legitimationsoplysninger til servicen og overføre dem til Helm. Du vil kunne bruge WordPress med skyens MySQL, helt uden at håndtere managed databaser og bekymre dig om stateful services internt.

Man kan sige, at Helm fungerer som lim, der på den ene side muliggør udrulning af tjenester, og på den anden side forbruker cloud-udbyderes ressourcer.

Man kan skrive sin egen plugin og bruge hele denne historie on-premise. Så vil du blot have din egen plugin til den virksomhedscloud-udbyder. Jeg anbefaler at prøve denne tilgang, især hvis du har stor skala og gerne vil hurtigt rulle dev, staging eller hele infrastrukturen ud til en feature. Det vil forenkle livet for dine operations eller DevOps.

Endnu en opdagelse, som jeg allerede har nævnt – det er plugin'en helm-gcs, som gør det muligt at bruge Google-buckets (objektdatabase) til at opbevare Helm-charts.

Det kræver kun fire kommandoer at begynde at bruge det:

1. installer plugin'en;
2. initier den;
3. angiv en sti til den bucket, der findes i gcp;
4. udgive charts på den almindelige måde.

Skønheden ligger i, at den native gcp-metode til autentificering vil blive anvendt. Du kan bruge en servicekonto, en udviklerkonto – hvad som helst. Det er meget praktisk og koster ikke noget at vedligeholde. Hvis du, ligesom jeg, fremmer opsless-filosofien, vil dette være meget nyttigt, især for små teams.

Alternativer

Helm er ikke den eneste løsning til at håndtere tjenester. Der er mange spørgsmål til det, og måske derfor kom den tredje version så hurtigt. Selvfølgelig findes der alternativer.

Dette kan være både specialiserede løsninger, som Ksonnet eller Metaparticle. Du kan bruge dine klassiske infrastrukturværktøjer (Ansible, Terraform, Chef osv.) til de samme formål, som jeg tidligere nævnte.

Endelig er der en løsning Operator Framework, hvis popularitet stiger.

Operator Framework er den primære alternative til Helm, som man bør være opmærksom på.

Det er mere native for CNCF og Kubernetes, men indgangsbarrieren er betydeligt højere, der kræves mere programmering og mindre beskrivelse af manifester.

Der findes forskellige addons, som Draft og Scaffold. De letter livet betydeligt, for eksempel for udviklere, ved at forenkle cyklussen for indsending og kørsel af Helm til at implementere testmiljøer. Jeg ville kalde dem muligheden for udvidere funktionaliteten.

Her er et illustrerende diagram over, hvor hvad befinder sig.

På x-aksen dit personlige kontrolniveau over, hvad der sker, og på y-aksen niveauet for native Kubernetes. Helm version 2 er et sted midt imellem. Version 3 har ikke en kolossal ændring, men både kontrol og niveau for native er forbedret. Ksonnet-løsninger ligger stadig tilbage i forhold til selv Helm 2. Men det er værd at se på dem for at vide, hvad der ellers findes i denne verden. Selvfølgelig vil din konfiguration manager være under kontrol, men den er slet ikke native for Kubernetes.

Operator Framework er helt native for Kubernetes og tillader en mere elegant og detaljeret styring (men husk indgangsniveauet). Det er mere passende for specialiserede applikationer og oprettelse af management til dem end som en masseproducent af en masse applikationer via Helm.

Udvidere muligheder forbedrer blot kontrol, supplerer workflow eller skærer hjørner af CI/CD pipelines.

Fremtiden for Helm

Den gode nyhed er, at Helm 3 er på vej. Alpha-versionen Helm 3.0.0-alpha.2 er allerede blevet udgivet, og den kan prøves. Den er ganske stabil, men funktionaliteten er stadig begrænset.

Hvorfor er Helm 3 vigtigt? Først og fremmest handler det om forlængelsen af Tiller, som komponent. Dette er, som du sikkert forstår, et kæmpe skridt fremad, fordi det forenkler sikkerhedsarkitekturen.

Da Helm 2 blev udviklet, hvilket var i en tid hvor Kubernetes 1.8 var langt fra ny, var mange koncepter stadig umodne. For eksempel er konceptet med CRD i øjeblikket aktivt implementeret, og Helm vil bruge CRD, til at gemme strukturer. Det bliver muligt kun at anvende klienten uden at skulle have en serverdel. Dermed kan man bruge de indfødte Kubernetes-kommandoer til at arbejde med strukturer og ressourcer. Det er et stort skridt fremad.

Der vil komme understøttelse af native OCI-repositories (Open Container Initiative). Dette er en stor initiativ, og Helm finder det især interessant for at hoste sine charts. Det er værd at bemærke, at for eksempel Docker Hub understøtter mange OCI-standarder. Jeg vil ikke gætte, men måske vil de traditionelle Docker repository-leverandører begynde at give mulighed for at hoste dine Helm-charts.

En kontroversiel ting for mig er understøttelse af Lua, som en templating engine til scripting. Jeg er ikke den største fan af Lua, men dette vil være en helt valgfri mulighed. Jeg har tjekket det tre gange - brugen af Lua vil ikke være obligatorisk. Så dem, der ønsker at bruge Lua, kan gøre det, og dem, der kan lide Go - kom med i vores store lejr og brug go-tmpl til dette.

Endelig det, jeg helt sikkert har savnet - fremkomsten af skemaet og validering af datatyper. Der vil ikke længere være problemer med int eller string, og du skal ikke længere pakke nul i dobbelt citationstegn. Der vil komme en JSON-schema, som eksplicit gør det muligt at beskrive dette for values.

Den event-drevne modelvil gennemgå omfattende forbedringer. Den er allerede konceptuelt beskrevet. Tjek Helm 3-tråden, og du vil se, hvor mange begivenheder og hooks der er blevet tilføjet, hvilket vil forenkle og samtidig give mere kontrol over deployments og reaktioner.

Helm 3 bliver enklere, mere sikkert og mere interessant, ikke fordi vi ikke kan lide Helm 2, men fordi Kubernetes bliver mere avanceret. Derfor kan Helm udnytte de fremskridt, der er gjort i Kubernetes, og skabe fremragende værktøjer til Kubernetes.

Endnu en god nyhed er, at DevOpsConf Alexander Khayorov vil fortælle, om containere kan være sikre? Lad os minde om, at konferencen om integration af udviklings-, test- og driftsprocesser finder sted i Moskva den 30. september og 1. oktober. Indtil 20. august er det stadig muligt at indgive et oplæg og dele din erfaring med at løse en af mange opgaver i DevOps-tilgangen.

Følg konferencens checkpoint og nyhederne på nyhedsbrev og telegramkanalen.

Kilde: habr.com