L'essència de la història sobre el gestor de paquets més popular per a Kubernetes es podria representar amb emoji:
- box és Helm (això és el més adequat a l'últim llançament d'Emoji);
- bloqueig - seguretat;
- l'home és la solució al problema.
De fet, tot serà una mica més complicat, i la història està plena de detalls tècnics sobre com com fer que Helm sigui segur.
- Breument, què és Helm, si no ho sabia o ho va oblidar. Quins problemes soluciona i on es troba a l'ecosistema.
- Penseu en l'arquitectura Helm. Cap conversa sobre seguretat i com fer que una eina o solució sigui més segura no està completa sense comprendre l'arquitectura del component.
- Parlem dels components de Helm.
- La pregunta més candent és el futur: la nova versió de Helm 3.
Tot el que hi ha en aquest article s'aplica a Helm 2. Aquesta versió està actualment en producció i és molt probable que sigui la que esteu utilitzant actualment, i és la que presenta riscos de seguretat.
Sobre l'altaveu: Alexander Khayorov () desenvolupa des de fa 10 anys, ajudant a millorar el contingut i es va incorporar a la comissió . Ara treballa a Chainstack com a responsable de desenvolupament: aquest és un híbrid entre un gestor de desenvolupament i una persona responsable del lliurament de les versions finals. És a dir, es troba al lloc de les hostilitats, on tot passa des de la creació d'un producte fins al seu funcionament.
Chainstack és una startup petita i en creixement actiu la missió de la qual és permetre als clients oblidar-se de la infraestructura i la complexitat de l'operació d'aplicacions descentralitzades, l'equip de desenvolupament es troba a Singapur. No demaneu a Chainstack que vengui o compri criptomoneda, però ofereixeu-vos a parlar sobre marcs de blockchain empresarials i us respondran encantats.
Timó
Aquest és un gestor de paquets (gràfics) per a Kubernetes. La forma més clara i versàtil de portar aplicacions a un clúster de Kubernetes.
Això, per descomptat, tracta d'un enfocament més estructural i industrial que crear els vostres propis manifests YAML i escriure petites utilitats.
Helm és el millor que ara està disponible i popular.
Per què Helm? Principalment perquè compta amb el suport de CNCF. Cloud Native és una gran organització i és l'empresa matriu de Kubernetes, etcd, Fluentd i altres.
Un altre fet important és que Helm és un projecte molt popular. Quan el gener de 2019 vaig pensar per primera vegada a parlar de com fer que Helm fos segur, el projecte tenia mil estrelles a GitHub. Al maig n'hi havia 12.
Molta gent està interessada en Helm, així que encara que encara no l'utilitzeu, us serà útil conèixer la seva seguretat. La seguretat és important.
L'equip principal de Helm està recolzat per Microsoft Azure i, com a tal, és un projecte força estable, a diferència de molts altres. El llançament d'Helm 3 Alpha 2 a mitjans de juliol indica que hi ha molta gent treballant en el projecte i té el desig i la força per desenvolupar i millorar Helm.
Helm aborda diversos problemes de gestió d'aplicacions arrel a Kubernetes.
- Embalatge de l'aplicació. Fins i tot una aplicació com "Hello, World" a WordPress ja consta de diversos serveis i volen empaquetar-los junts.
- Gestionar la complexitat que comporta la gestió d'aquestes aplicacions.
- Un cicle de vida que no s'acaba després d'instal·lar o desplegar l'aplicació. Continua vivint, cal actualitzar-lo, i Helm ajuda en això i intenta portar les mesures i polítiques adequades per a això.
Embalatge organitzats d'una manera entenedora: hi ha metadades d'acord amb el treball d'un gestor de paquets convencional per a Linux, Windows o MacOS. És a dir, el repositori, dependències de diversos paquets, metainformació per a aplicacions, paràmetres, característiques de configuració, informació d'indexació, etc. Tot aquest Helm permet obtenir i utilitzar per a aplicacions.
Gestió de la complexitat. Si teniu moltes aplicacions del mateix tipus, cal la parametrització. Les plantilles es deriven d'això, però per no crear la vostra pròpia manera de crear plantilles, podeu utilitzar el que Helm ofereix de manera immediata.
Gestió del cicle de vida d'aplicacions - al meu entendre, aquest és el tema més interessant i sense resoldre. Per això en un moment vaig venir a Helm. Necessitàvem fer un seguiment del cicle de vida de l'aplicació, volíem traslladar el nostre CI/CD i els cicles d'aplicació a aquest paradigma.
Helm et permet:
- gestionar els desplegaments, introdueix el concepte de configuració i revisió;
- dur a terme amb èxit la recuperació;
- utilitzar ganxos per a diferents esdeveniments;
- afegir comprovacions addicionals de l'aplicació i respondre als seus resultats.
Per altra banda Helm té "bateries" - un gran nombre de coses delicioses que es poden incloure en forma de connectors, simplificant la teva vida. Els connectors es poden escriure de manera independent, estan bastant aïllats i no requereixen una arquitectura coherent. Si voleu implementar alguna cosa, us recomano fer-ho com a connector i, a continuació, possiblement incloure-lo a la part amunt.
Helm es basa en tres conceptes principals:
- Repos de gràfics — descripció i matriu de parametrització possibles per al vostre manifest.
- Config —és a dir, els valors a aplicar (text, valors numèrics, etc.).
- Deixeu anar recull els dos components superiors i junts es converteixen en Release. Les versions es poden versionar, aconseguint així l'organització del cicle de vida: petites en el moment de la instal·lació i grans en el moment de l'actualització, baixada o retrocés.
Arquitectura del timó
El diagrama representa conceptualment l'arquitectura d'alt nivell de Helm.
Permeteu-me que us recordi que Helm és una cosa relacionada amb Kubernetes. Per tant, no podem prescindir d'un clúster de Kubernetes (rectangle). El component kube-apiserver es troba al mestre. Sense Helm, tenim Kubeconfig. Helm ofereix un petit binari, si podeu anomenar-lo així, la utilitat Helm CLI, que s'instal·la en un ordinador, un ordinador portàtil, un sistema central, qualsevol cosa.
Però això no és suficient. Helm té un component de servidor anomenat Tiller. Representa Helm dins del clúster i és una aplicació dins d'un clúster de Kubernetes com qualsevol altra.
El següent component Chart Repo és un dipòsit amb gràfics. Hi ha un repositori oficial, i pot haver-hi un repositori privat d'una empresa o projecte.
Interacció
Vegem com interactuen els components de l'arquitectura quan volem instal·lar una aplicació amb Helm.
- Estem parlant
Helm install, accediu al repositori (Chart Repo) i obteniu el gràfic Helm.
- La utilitat Helm (Helm CLI) interactua amb Kubeconfig per esbrinar a quin clúster cal fer referència.
- Un cop rebuda aquesta informació, la utilitat s'adreça a Tiller, que es troba al nostre clúster, ja com una aplicació.
- Tiller truca a Kube-apiserver per realitzar accions a Kubernetes, crear alguns objectes (serveis, pods, rèpliques, secrets, etc.).
A continuació, complicarem l'esquema per tal de veure el vector d'atac al qual es pot exposar l'arquitectura Helm en conjunt. I després intentarem protegir-la.
Vector d'atac
La primera debilitat potencial és API privilegiada-l’usuari. Com a part de l'esquema, es tracta d'un pirata informàtic que ha obtingut accés d'administrador a la CLI de Helm.
Usuari de l'API sense privilegis també pot ser un perill si es troba a prop. Aquest usuari tindrà un context diferent, per exemple, es pot arreglar en un espai de noms de clúster a la configuració de Kubeconfig.
El vector d'atac més interessant pot ser un procés que es troba dins del clúster a prop de Tiller i hi pot accedir. Pot ser un servidor web o un microservei que veu l'entorn de xarxa del clúster.
Una variant exòtica, però cada cop més popular, de l'atac està relacionada amb Chart Repo. Un gràfic creat per un autor sense escrúpols pot contenir un recurs no segur, i el seguireu per fe. O pot substituir el gràfic que descarregueu del repositori oficial i, per exemple, crear un recurs en forma de polítiques i augmentar l'accés a ell mateix.
Intentem combatre els atacs de tots aquests quatre costats i esbrineu on hi ha problemes a l'arquitectura Helm i on, potser, no.
Ampliem l'esquema, afegim més elements, però mantenim tots els components bàsics.
Helm CLI es comunica amb Chart Repo, interactua amb Kubeconfig, el treball es transfereix al clúster al component Tiller.
El tiller està representat per dos objectes:
- Tiller-deploy svc, que exposa un determinat servei;
- Pod de desplegament de tiller (al diagrama en una sola instància en una rèplica), en el qual s'executa tota la càrrega, que accedeix al clúster.
Per a la interacció s'utilitzen diferents protocols i esquemes. Des del punt de vista de la seguretat, ens interessa més:
- El mecanisme pel qual Helm CLI accedeix al repositori de gràfics: quin és el protocol, hi ha autenticació i què es pot fer al respecte.
- El protocol pel qual l'Helm CLI, mitjançant kubectl, es comunica amb Tiller. Aquest és un servidor RPC instal·lat dins del clúster.
- El propi Tiller està disponible per als microserveis que es troben al clúster i interactua amb Kube-apiserver.
Parlem de cadascuna d'aquestes àrees al seu torn.
RBAC
És inútil parlar de qualsevol seguretat per a Helm o qualsevol altre servei dins del clúster tret que RBAC estigui habilitat.
Sembla que aquesta no és la recomanació més recent, però estic segur que molts encara no han habilitat RBAC ni tan sols en producció, perquè és molt enrenou i hi ha molt per configurar. Tanmateix, us demano que ho feu.
— advocat de lloc per RBAC. Hi ha una gran quantitat de material interessant recollit allà que us ajudarà a configurar RBAC, mostrar per què és bo i com conviure-hi en principi en la producció.
Intentaré explicar com funcionen Tiller i RBAC. Tiller s'executa dins del clúster amb un compte de servei determinat. Normalment, si RBAC no està configurat, aquest serà el superusuari. A la configuració bàsica, Tiller serà l'administrador. És per això que sovint es diu que Tiller és un túnel SSH per al vostre clúster. De fet, aquest és el cas, de manera que podeu utilitzar un compte de servei especialitzat independent en lloc del compte de servei predeterminat del diagrama anterior.
Quan inicialitzeu Helm la primera vegada que l'instal·leu en un servidor, podeu configurar un compte de servei amb --service-account. Això us permetrà utilitzar un usuari amb el conjunt mínim de drets necessaris. És cert que haureu de crear aquesta "garlanda": Role i RoleBinding.
Malauradament, Helm no ho farà per tu. Vostè o l'administrador del clúster de Kubernetes heu de preparar un conjunt de rols, RoleBinding per al compte de servei per endavant per passar l'Helm.
Sorgeix la pregunta: quina diferència hi ha entre Role i ClusterRole? La diferència és que ClusterRole funciona per a tots els espais de noms, a diferència de Role i RoleBinding normals, que només funcionen per a espais de noms especialitzats. Podeu configurar polítiques per a tot el clúster i tots els espais de noms, així com personalitzades per a cada espai de noms individualment.
Val a dir que RBAC resol un altre gran problema. Molts es queixen que Helm, malauradament, no és multitenancy (no admet multitenancy). Si diversos equips consumeixen el clúster i utilitzen Helm, en principi és impossible configurar polítiques i diferenciar el seu accés dins d'aquest clúster, perquè hi ha un determinat compte de servei des del qual s'executa Helm i crea tots els recursos del clúster des de sota. això, que de vegades molt incòmode. Això és cert: com a fitxer binari en si mateix, com a procés, Helm Tiller no té ni idea de la multitenència.
Tanmateix, hi ha una manera fantàstica que us permet executar Tiller diverses vegades en un clúster. No hi ha cap problema amb això, Tiller es pot executar a tots els espais de noms. Així, podeu utilitzar RBAC, Kubeconfig com a context i restringir l'accés a un Helm especial.
Es veurà així.
Per exemple, hi ha dos Kubeconfigs amb context per a equips diferents (dos espais de noms): X Team per a l'equip de desenvolupament i un clúster d'administrador. El clúster d'administració té el seu propi Tiller ampli, que es troba a l'espai de noms del sistema Kube, respectivament, compte de servei avançat. I un espai de noms separat per a l'equip de desenvolupament, podran desplegar els seus serveis en un espai de noms especial.
Aquest és un enfocament de treball, Tiller no és tan glotó que pugui afectar molt el vostre pressupost. Aquesta és una de les solucions ràpides.
No dubteu a configurar Tiller per separat i proporcionar a Kubeconfig context per a un equip, per a un desenvolupador específic o per a l'entorn: Dev, Staging, Production (és dubtós que tot estigui al mateix clúster, però, es pot fer) .
Continuant amb la nostra història, canviem de RBAC i parlem de ConfigMaps.
ConfigMaps
Helm utilitza ConfigMaps com a magatzem de dades. Quan parlàvem d'arquitectura, no hi havia enlloc una base de dades que emmagatzemés informació sobre llançaments, configuracions, rollbacks, etc. Per a això s'utilitza ConfigMaps.
El principal problema amb ConfigMaps és conegut: en principi no són segurs, ells incapaç d'emmagatzemar dades sensibles. Estem parlant de tot allò que no hauria d'anar més enllà del servei, per exemple, les contrasenyes. La manera més nativa de Helm ara mateix és passar d'utilitzar ConfigMaps a secrets.
Això es fa de manera molt senzilla. Anul·leu la configuració de Tiller i especifiqueu que l'emmagatzematge serà secret. Aleshores, per a cada desplegament, rebreu no un ConfigMap, sinó un secret.
Podríeu argumentar que els secrets en si són un concepte estrany i poc segur. Tanmateix, cal entendre que els mateixos desenvolupadors de Kubernetes ho estan fent. A partir de la versió 1.10, és a dir. durant molt de temps, és possible, almenys en núvols públics, connectar l'emmagatzematge correcte per emmagatzemar secrets. Ara l'equip està treballant en com distribuir encara millor l'accés a secrets, pods individuals o altres entitats.
És millor traduir Storage Helm en secrets i, al seu torn, protegir-los de manera centralitzada.
Per descomptat, es quedarà Límit d'emmagatzematge de dades d'1 MB. Helm aquí utilitza etcd com a repositori distribuït per a ConfigMaps. I allà van considerar que aquest és un tros de dades adequat per a rèpliques, etc. Hi ha una discussió interessant a Reddit sobre això, us recomano trobar aquesta lectura divertida per al cap de setmana o llegir el squeeze .
Repos de gràfics
Els gràfics són els més vulnerables socialment i poden convertir-se en una font d'"Home al mig", sobretot si utilitzeu una solució d'existències. En primer lloc, estem parlant de repositoris que s'exposen mitjançant HTTP.
Definitivament, heu d'exposar Helm Repo a través d'HTTPS: aquesta és la millor opció i és barata.
Preste atenció a mecanisme de signatura del gràfic. La tecnologia és fàcil de deshonrar. És el mateix que utilitzeu a GitHub, una màquina PGP normal amb claus públiques i privades. Configureu i assegureu-vos, tenint les claus adequades i signant-ho tot, que aquest és realment el vostre gràfic.
A més, El client Helm admet TLS (no en el sentit d'HTTP des del costat del servidor, sinó TLS mutu). Podeu utilitzar les claus del servidor i del client per comunicar-vos. Per ser sincer, no faig servir aquest mecanisme perquè no m'agraden els certificats mutus. Bàsicament, - l'eina principal per configurar Helm Repo per a Helm 2 - també admet l'autenticació bàsica. Podeu utilitzar l'autenticació bàsica si és més còmode i silenciós.
També hi ha un connector , que us permet allotjar Chart Repos a Google Cloud Storage. Això és bastant convenient, funciona molt bé i és prou segur, perquè s'utilitzen tots els mecanismes descrits.
Si activeu HTTPS o TLS, utilitzeu mTLS, activeu l'autenticació bàsica per reduir encara més els riscos, obtindreu un canal de comunicació segur per a Helm CLI i Chart Repo.
API gRPC
El següent pas és molt responsable: assegurar Tiller, que es troba al clúster i és, d'una banda, un servidor, d'altra banda, accedeix a altres components i intenta fer-se passar per algú.
Com he dit, Tiller és un servei que exposa gRPC, el client Helm hi arriba a través de gRPC. Per defecte, per descomptat, TLS està desactivat. Per què es fa això és una qüestió discutible, em sembla, per tal de simplificar la configuració al principi.
Per a la producció i fins i tot per a la posada en escena, recomano habilitar TLS a gRPC.
Al meu entendre, a diferència de mTLS per als gràfics, això és adequat aquí i es fa de manera molt senzilla: generar una infraestructura PQI, crear un certificat, executar Tiller, transferir el certificat durant la inicialització. Després d'això, podeu executar totes les ordres d'Helm, fent veure que són el certificat i la clau privada generats.
Així, us protegireu de totes les sol·licituds a Tiller des de fora del clúster.
Així doncs, hem assegurat el canal de connexió a Tiller, ja hem parlat de RBAC i hem ajustat els drets de l'apiserver de Kubernetes, hem reduït el domini amb el qual pot interactuar.
Timó protegit
Vegem el diagrama final. És la mateixa arquitectura amb les mateixes fletxes.
Ara totes les connexions es poden dibuixar de manera segura en verd:
- per a Chart Repo fem servir TLS o mTLS i autenticació bàsica;
- mTLS per Tiller, i s'exposa com un servei gRPC amb TLS, fem servir certificats;
- el clúster utilitza un compte de servei especial amb Role i RoleBinding.
Hem assegurat notablement el clúster, però algú intel·ligent va dir:
"Només pot haver-hi una solució absolutament segura: un ordinador apagat, que es troba en una caixa de formigó i està vigilat per soldats".
Hi ha diferents maneres de manipular dades i trobar nous vectors d'atac. Tanmateix, estic segur que aquestes recomanacions us permetran implementar l'estàndard bàsic de seguretat de la indústria.
prima
Aquesta part no està directament relacionada amb la seguretat, però també serà útil. Us mostraré coses interessants que poca gent coneix. Per exemple, com cercar gràfics: oficials i no oficials.
Al repositori ara hi ha uns 300 gràfics i dos corrents: estable i incubadora. Qualsevol que hi contribueixi sap perfectament com de difícil és passar de la incubadora a l'estable, i el fàcil que és sortir de l'estable volant. Tanmateix, no és la millor eina per trobar gràfics per a Prometeu i qualsevol altra cosa que us agradi, per una senzilla raó: no és un portal convenient per cercar paquets.
Però hi ha un servei , amb la qual cosa és molt més convenient trobar gràfics. El més important és que hi ha molts més repositoris externs i gairebé 800 encants disponibles. A més, podeu connectar el vostre dipòsit si per algun motiu no voleu enviar els vostres gràfics a l'estable.
Proveu hub.helm.sh i desenvolupem-lo junts. Aquest servei està sota un projecte Helm i fins i tot podeu contribuir a la seva interfície d'usuari si sou un frontend i només voleu millorar l'aspecte.
També vull cridar la vostra atenció Integració de l'API Open Service Broker. Sona feixuc i incomprensible, però soluciona els problemes als quals s'enfronta tothom. Permeteu-me explicar-ho amb un exemple senzill.
Tenim un clúster de Kubernetes on volem executar una aplicació clàssica de WordPress. Per regla general, es necessita una base de dades per a una funcionalitat completa. Hi ha moltes solucions diferents, per exemple, podeu executar el vostre propi servei complet. Això no és molt convenient, però moltes persones ho fan.
Altres, com nosaltres a Chainstack, utilitzen bases de dades gestionades com MySQL o PostgreSQL per a servidors. Per tant, les nostres bases de dades es troben en algun lloc del núvol.
Però sorgeix un problema: hem de connectar el nostre servei amb la base de dades, crear un sabor de la base de dades, passar la credencial i gestionar-la d'alguna manera. Tot això normalment ho fa manualment un administrador o desenvolupador del sistema. I no hi ha cap problema quan hi ha poques aplicacions. Quan n'hi ha molts, necessiteu una combinació. Hi ha una combinació així: és Service Broker. Us permet utilitzar un connector especial per a un clúster de núvol públic i demanar recursos a un proveïdor a través d'un corredor, com si es tractés d'una API. Per fer-ho, podeu utilitzar eines natives de Kubernetes.
És molt senzill. Podeu sol·licitar, per exemple, MySQL gestionat a Azure amb un nivell base (això es pot configurar). Mitjançant l'API d'Azure, la base de dades es crearà i es podrà utilitzar. No cal que interfereixis amb això, el connector és responsable d'això. Per exemple, OSBA (connector d'Azure) tornarà la credencial al servei i la passarà a Helm. Podreu utilitzar WordPress amb MySQL al núvol, no tractar-vos en absolut amb bases de dades gestionades i no preocupar-vos pels serveis complets a l'interior.
Podem dir que Helm actua com un cola que, d'una banda, permet desplegar serveis i, de l'altra, consumeix els recursos dels proveïdors de núvol.
Podeu escriure el vostre propi connector i utilitzar tot aquest historial local. Aleshores, simplement tindreu el vostre propi connector per al proveïdor de núvol corporatiu. Us recomano que proveu aquest enfocament, sobretot si teniu una gran escala i voleu desplegar ràpidament el desenvolupament, la posada en escena o tota la infraestructura d'una funció. Això facilitarà la vida a les vostres operacions o DevOps.
Una altra troballa que ja he comentat és connector helm-gcs, que us permet utilitzar Google-buckets (emmagatzematge d'objectes) per emmagatzemar gràfics Helm.
Només necessiteu quatre ordres per començar a utilitzar-lo:
- instal·lar el connector;
- iniciar-lo;
- establiu el camí cap al cub, que és a gcp;
- publicar gràfics de la manera estàndard.
La bellesa és que s'utilitzarà el mètode gcp natiu per a l'autorització. Podeu utilitzar un compte de servei, un compte de desenvolupador, el que sigui. És molt còmode i no costa res d'operar. Si, com jo, promocioneu la filosofia opsless, serà molt convenient, especialment per a equips petits.
Alternatives
Helm no és l'única solució de gestió de serveis. Hi ha moltes preguntes per a ell, i és probablement per això que la tercera versió va aparèixer tan ràpidament. És clar que hi ha alternatives.
Aquestes poden ser solucions especialitzades com Ksonnet o Metaparticle. Podeu utilitzar les vostres eines clàssiques de gestió d'infraestructures (Ansible, Terraform, Chef, etc.) amb les mateixes finalitats que he esmentat.
Finalment hi ha una solució que està creixent en popularitat.
L'Operator Framework és la principal alternativa d'Helm a buscar.
És més natiu de CNCF i Kubernetes, però la barrera d'entrada és molt més alta, cal codificar més i descriure menys els manifests.
Hi ha diversos complements, com ara Draft, Scaffold. Faciliten molt la vida, per exemple, simplifiquen el cicle perquè els desenvolupadors enviïn i executin Helm per desplegar un entorn de prova. Jo els diria empoderadors.
Aquí teniu un gràfic visual d'on es troba tot.
L'abscissa és el nivell del teu control personal sobre el que està passant, l'ordenada és el nivell d'origen de Kubernetes. La versió 2 d'Helm es troba entremig. A la versió 3, no és enorme, però es milloren tant el control com el nivell de nativitat. Les solucions de nivell Ksonnet encara són inferiors fins i tot a Helm 2. No obstant això, val la pena mirar-les per saber què més hi ha en aquest món. Per descomptat, el vostre gestor de configuració estarà sota el vostre control, però no és absolutament natiu de Kubernetes.
L'Operator Framework és absolutament natiu de Kubernetes i us permet gestionar-lo de manera molt més elegant i escrupolosa (però tingueu en compte el nivell d'entrada). Més aviat, és adequat per a una aplicació especialitzada i per crear-ne una gestió, en lloc d'una combinació massiva per empaquetar un gran nombre d'aplicacions amb Helm.
Els extensors només milloren lleugerament el control, complementen el flux de treball o retallen cantonades a les canonades CI/CD.
Futur Helms
La bona notícia és que arriba Helm 3. La versió alfa de Helm 3.0.0-alpha.2 ja s'ha llançat, podeu provar-la. És bastant estable, però la funcionalitat encara és limitada.
Per què necessites Helm 3? En primer lloc, aquesta és una història La desaparició de Tiller, com a component. Això, com ja heu entès, és un gran pas endavant, perquè des del punt de vista de la seguretat de l'arquitectura, tot es simplifica.
Quan es va crear Helm 2, que va ser durant el Kubernetes 1.8 dies o fins i tot abans, molts dels conceptes eren immadurs. Per exemple, ara s'està implementant activament el concepte CRD, i Helm ho farà utilitzar CRDper emmagatzemar estructures. Serà possible utilitzar només el client i no mantenir la part del servidor. En conseqüència, utilitzeu ordres natives de Kubernetes per treballar amb estructures i recursos. Aquest és un gran pas endavant.
Apareixerà suport per a repositoris OCI natius (Iniciativa de contenidors oberts). Aquesta és una iniciativa enorme i a Helm li interessa principalment publicar els seus gràfics. Arriba al punt que, per exemple, Docker Hub admet molts estàndards OCI. No ho suposo, però potser els proveïdors clàssics de dipòsits de Docker començaran a permetre't allotjar els seus gràfics Helm.
Una història controvertida per a mi és Suport Lua, com a motor de plantilles per escriure scripts. No sóc un gran fan de Lua, però serà completament opcional. Ho vaig comprovar 3 vegades; no serà necessari utilitzar Lua. Així que qui vulgui poder utilitzar Lua, qui li agradi Go, uneix-te al nostre gran campament i utilitza go-tmpl per això.
Finalment, el que em trobava a faltar definitivament era aparició de l'esquema i validació de tipus de dades. No hi haurà més problemes amb int o string, no cal posar zero entre cometes dobles. Apareixerà un esquema JSONS que us permetrà descriure-ho explícitament per als valors.
Serà molt reelaborat model impulsat per esdeveniments. Ja s'ha conceptualitzat. Mireu la branca Helm 3 i veureu quants esdeveniments i ganxos i altres coses s'han afegit, la qual cosa simplifica molt i, d'altra banda, afegeix control sobre els processos de desplegament i reaccions sobre ells.
Helm 3 serà més fàcil, més segur i més interessant, no perquè no ens agradi Helm 2, sinó perquè Kubernetes està cada cop més avançat. En conseqüència, Helm pot utilitzar els desenvolupaments de Kubernetes i crear-hi gestors excel·lents per a Kubernetes.
Una altra bona notícia és que el Alexander Khayorov ho dirà Recordem que la conferència sobre la integració dels processos de desenvolupament, proves i operació se celebrarà a Moscou 30 de setembre i 1 d'octubre. Encara pots fins el 20 d'agost i explica la teva experiència tasques de l'enfocament DevOps.
Seguiu els punts de control de la conferència i les notícies и .
Font: www.habr.com