A esencia da historia sobre o xestor de paquetes máis popular para Kubernetes podería representarse usando un emoji:
- a caixa é Helm (que é o máis parecido ao último lanzamento de Emoji);
- bloqueo - seguridade;
- o home pequeno é a solución ao problema.
De feito, todo será un pouco máis complicado, ea historia está chea de detalles técnicos sobre Como facer que Helm sexa seguro.
- Brevemente o que é Helm por se non o sabías ou esqueciches. Que problemas resolve e onde se sitúa no ecosistema.
- Vexamos a arquitectura Helm. Non se pode completar ningunha conversación sobre seguridade e como facer que unha ferramenta ou solución sexa máis segura sen comprender a arquitectura do compoñente.
- Imos discutir os compoñentes de Helm.
- A pregunta máis candente é o futuro: a nova versión de Helm 3.
Todo o contido deste artigo aplícase a Helm 2. Esta versión está actualmente en produción e é moi probable que sexa a que estás a usar actualmente, e é a versión que contén os riscos de seguridade.
Acerca do orador: Alexander Khayorov () leva 10 anos desenvolvendo, axudando a mellorar o contido e incorporouse ao comité . Agora traballa en Chainstack como xefe de desenvolvemento: este é un híbrido entre un xestor de desenvolvemento e unha persoa que se encarga de entregar as versións finais. É dicir, está situado no campo de batalla, onde sucede todo desde a creación dun produto ata o seu funcionamento.
Chainstack é unha pequena startup en crecemento activo cuxa misión é permitir que os clientes se esquezan da infraestrutura e da complexidade de operar aplicacións descentralizadas; o equipo de desenvolvemento está situado en Singapur. Non lle pidas a Chainstack que venda ou compre moeda criptográfica, pero ofrécese a falar sobre marcos de cadeas de bloques empresariais, e eles contestaránche encantados.
Leme
Este é un xestor de paquetes (gráficos) para Kubernetes. A forma máis intuitiva e universal de levar aplicacións a un clúster de Kubernetes.
Por suposto, estamos a falar dun enfoque máis estrutural e industrial que crear os teus propios manifestos YAML e escribir pequenas utilidades.
Helm é o mellor que está actualmente dispoñible e popular.
Por que Helm? Principalmente porque está apoiado pola CNCF. Cloud Native é unha gran organización e é a empresa matriz dos proxectos Kubernetes, etcd, Fluentd e outros.
Outro dato importante é que Helm é un proxecto moi popular. Cando comecei a falar de como facer que Helm fose seguro en xaneiro de 2019, o proxecto tiña mil estrelas en GitHub. En maio eran 12 mil.
Moitas persoas están interesadas en Helm, polo que aínda que aínda non o uses, beneficiarase de coñecer a súa seguridade. A seguridade é importante.
O equipo principal de Helm está apoiado por Microsoft Azure e, polo tanto, é un proxecto bastante estable, a diferenza de moitos outros. O lanzamento de Helm 3 Alpha 2 a mediados de xullo indica que hai moita xente traballando no proxecto e que teñen o desexo e a enerxía para desenvolver e mellorar Helm.
Helm resolve varios problemas raíz da xestión de aplicacións en Kubernetes.
- Embalaxe da aplicación. Incluso unha aplicación como "Ola, mundo" en WordPress xa consta de varios servizos e queres empaquetalos xuntos.
- Xestionar a complexidade que supón a xestión destas aplicacións.
- Un ciclo de vida que non remata despois de instalar ou despregar a aplicación. Continúa vivindo, hai que actualizar e Helm axuda con isto e trata de levar as medidas e políticas adecuadas para iso.
Ensacado organízase dun xeito claro: hai metadatos en plena consonancia co traballo dun xestor de paquetes habitual para Linux, Windows ou MacOS. É dicir, un repositorio, dependencias de varios paquetes, metainformación para aplicacións, axustes, funcións de configuración, indexación de información, etc. Helm permite obter e utilizar todo isto para aplicacións.
Xestión da complexidade. Se tes moitas aplicacións do mesmo tipo, é necesaria a parametrización. Os modelos proveñen disto, pero para evitar ter que crear o teu propio xeito de crear modelos, podes usar o que Helm ofrece fóra da caixa.
Xestión do ciclo de vida da aplicación - na miña opinión, esta é a pregunta máis interesante e sen resolver. É por iso que vin a Helm no seu día. Necesitabamos manter un ollo no ciclo de vida das aplicacións e queriamos trasladar os nosos ciclos CI/CD e aplicación a este paradigma.
Helm permítelle:
- xestionar despregamentos, introduce o concepto de configuración e revisión;
- levar a cabo con éxito a recuperación;
- usar ganchos para diferentes eventos;
- engadir comprobacións adicionais da aplicación e responder aos seus resultados.
Ademais Helm ten "pilas" - un gran número de cousas saborosas que se poden incluír en forma de complementos, simplificando a súa vida. Os complementos pódense escribir de forma independente, están bastante illados e non requiren unha arquitectura harmoniosa. Se queres implementar algo, recoméndoo facelo como complemento e, a continuación, posiblemente incluílo en upstream.
Helm baséase en tres conceptos principais:
- Repo de gráficos — descrición e matriz de parametrizacións posibles para o seu manifesto.
- Config —é dicir, os valores que se aplicarán (texto, valores numéricos, etc.).
- Solte recolle os dous compoñentes superiores e xuntos convértense en Release. As versións pódense versionar, conseguindo así un ciclo de vida organizado: pequenos no momento da instalación e grandes no momento da actualización, downgrade ou rollback.
Arquitectura Helm
O diagrama representa conceptualmente a arquitectura de alto nivel de Helm.
Permíteme recordarche que Helm é algo relacionado con Kubernetes. Polo tanto, non podemos prescindir dun clúster de Kubernetes (rectángulo). O compoñente kube-apiserver reside no mestre. Sen Helm temos Kubeconfig. Helm trae un pequeno binario, se pode chamalo así, Helm CLI utilidade, que está instalada nun ordenador, portátil, mainframe - en calquera cousa.
Pero isto non é suficiente. Helm ten un compoñente de servidor chamado Tiller. Representa os intereses de Helm dentro do clúster; é unha aplicación dentro do clúster de Kubernetes, como calquera outra.
O seguinte compoñente de Chart Repo é un repositorio con gráficos. Hai un repositorio oficial, e pode haber un repositorio privado dunha empresa ou proxecto.
Interacción
Vexamos como interactúan os compoñentes da arquitectura cando queremos instalar unha aplicación usando Helm.
- Estamos falando
Helm install, accede ao repositorio (Chart Repo) e obtén un gráfico Helm.
- A utilidade Helm (Helm CLI) interactúa con Kubeconfig para descubrir con que clúster contactar.
- Unha vez recibida esta información, a utilidade refírese a Tiller, que se atopa no noso clúster, como unha aplicación.
- Tiller accede a Kube-apiserver para realizar accións en Kubernetes, crear algúns obxectos (servizos, pods, réplicas, segredos, etc.).
A continuación, complicaremos o diagrama para ver o vector de ataque ao que pode estar exposta toda a arquitectura Helm no seu conxunto. E despois tentaremos protexela.
Vector de ataque
O primeiro punto débil potencial é API privilexiada-usuario. Como parte do esquema, este é un hacker que obtivo acceso de administrador á CLI de Helm.
Usuario de API sen privilexios tamén pode supoñer un perigo se está nalgún lugar preto. Este usuario terá un contexto diferente, por exemplo, pódese arranxar nun espazo de nomes de clúster na configuración de Kubeconfig.
O vector de ataque máis interesante pode ser un proceso que está situado dentro dun clúster nalgún lugar preto de Tiller e pode acceder a el. Este pode ser un servidor web ou un microservizo que ve o ambiente de rede do clúster.
Unha variante de ataque exótica, pero cada vez máis popular, implica Chart Repo. Un gráfico creado por un autor sen escrúpulos pode conter recursos inseguros e completarao tomándoo por fe. Ou pode substituír o gráfico que descargas do repositorio oficial e, por exemplo, crear un recurso en forma de políticas e aumentar o seu acceso.
Tentemos evitar ataques de todos estes catro lados e descubrir onde hai problemas na arquitectura Helm e onde, quizais, non hai ningún.
Imos ampliar o diagrama, engadir máis elementos, pero manter todos os compoñentes básicos.
A CLI de Helm comunícase co Chart Repo, interactúa con Kubeconfig e o traballo transfírese ao clúster ao compoñente Tiller.
Tiller está representado por dous obxectos:
- Tiller-deploy svc, que expón un determinado servizo;
- Tiller-deploy pod (no diagrama nunha única copia nunha réplica), no que se executa toda a carga, que accede ao clúster.
Utilízanse diferentes protocolos e esquemas para a interacción. Dende o punto de vista da seguridade, estamos máis interesados en:
- O mecanismo polo cal a CLI de Helm accede ao repositorio de gráficos: que protocolo, hai autenticación e que se pode facer con el.
- O protocolo polo que Helm CLI, mediante kubectl, se comunica con Tiller. Este é un servidor RPC instalado dentro do clúster.
- O propio Tiller é accesible para os microservizos que residen no clúster e interactúan co Kube-apiserver.
Imos discutir todas estas áreas en orde.
RBAC
Non ten sentido falar de ningunha seguridade para Helm ou calquera outro servizo dentro do clúster a menos que RBAC estea activado.
Parece que esta non é a última recomendación, pero estou seguro de que moita xente aínda non ten activado RBAC nin en produción, porque é moito ruído e hai que configurar moitas cousas. Non obstante, anímote a que o fagas.
— avogado do sitio web de RBAC. Contén unha gran cantidade de materiais interesantes que che axudarán a configurar RBAC, mostrar por que é bo e como vivir con el na produción.
Intentarei explicar como funcionan Tiller e RBAC. Tiller funciona dentro do clúster cunha determinada conta de servizo. Normalmente, se RBAC non está configurado, este será o superusuario. Na configuración básica, Tiller será un administrador. É por iso que adoita dicirse que Tiller é un túnel SSH para o teu clúster. De feito, isto é certo, polo que pode usar unha conta de servizo dedicada separada en lugar da conta de servizo predeterminada no diagrama anterior.
Cando inicialice Helm e o instale no servidor por primeira vez, pode configurar a conta de servizo usando --service-account. Isto permitirache utilizar un usuario co conxunto mínimo de dereitos necesarios. É certo, terás que crear tal "guirlanda": Role e RoleBinding.
Desafortunadamente, Helm non fará isto por ti. Ti ou o teu administrador de clúster de Kubernetes debes preparar un conxunto de roles e vinculacións de roles para a conta de servizo con antelación para poder pasar Helm.
Xorde a pregunta: cal é a diferenza entre Role e ClusterRole? A diferenza é que ClusterRole funciona para todos os espazos de nomes, a diferenza dos Roles e RoleBindings normais, que só funcionan para un espazo de nomes especializado. Pode configurar políticas para todo o clúster e todos os espazos de nomes, ou personalizar cada espazo de nomes individualmente.
Cabe mencionar que RBAC resolve outro gran problema. Moita xente quéixase de que Helm, por desgraza, non é multitenancy (non admite multitenancy). Se varios equipos consomen un clúster e usan Helm, é basicamente imposible configurar políticas e limitar o seu acceso dentro deste clúster, porque hai unha determinada conta de servizo baixo a que se executa Helm e crea todos os recursos do clúster desde debaixo dela. , que ás veces moi incómodo. Isto é certo, como o propio ficheiro binario, como o proceso, Helm Tiller non ten concepto de multitenencia.
Non obstante, hai unha boa forma que che permite executar Tiller varias veces nun clúster. Non hai ningún problema con isto, Tiller pódese lanzar en todos os espazos de nomes. Así, pode usar RBAC, Kubeconfig como contexto e limitar o acceso a un Helm especial.
Será así.
Por exemplo, hai dous Kubeconfigs con contexto para diferentes equipos (dous espazos de nomes): X Team para o equipo de desenvolvemento e o clúster de administración. O clúster de administración ten o seu propio Tiller amplo, que se atopa no espazo de nomes do sistema Kube, unha conta de servizo avanzada correspondente. E un espazo de nomes separado para o equipo de desenvolvemento, poderán implantar os seus servizos nun espazo de nomes especial.
Este é un enfoque viable, Tiller non ten tanta fame de poder que afectará moito o seu orzamento. Esta é unha das solucións rápidas.
Non dubides en configurar Tiller por separado e proporcionar a Kubeconfig contexto para o equipo, para un desenvolvedor específico ou para o entorno: Dev, Staging, Production (é dubidoso que todo estea no mesmo clúster, non obstante, pódese facer).
Continuando a nosa historia, cambiemos de RBAC e falemos sobre ConfigMaps.
ConfigMaps
Helm usa ConfigMaps como almacén de datos. Cando falamos de arquitectura, non había ningunha base de datos en ningún lugar que almacenase información sobre lanzamentos, configuracións, retrocesos, etc. Para iso úsase ConfigMaps.
O principal problema con ConfigMaps é coñecido: son inseguros en principio; é imposible almacenar datos sensibles. Estamos a falar de todo o que non debe ir máis aló do servizo, por exemplo, os contrasinais. O xeito máis nativo de Helm agora mesmo é cambiar de usar ConfigMaps a segredos.
Isto faise de xeito moi sinxelo. Anular a configuración Tiller e especificar que o almacenamento será secreto. Entón, para cada implementación, recibirá non un ConfigMap, senón un segredo.
Poderíase argumentar que os segredos son un concepto estraño e non moi seguro. Non obstante, paga a pena entender que os propios desenvolvedores de Kubernetes están a facer isto. A partir da versión 1.10, i.e. Desde hai bastante tempo, é posible, polo menos nas nubes públicas, conectar o almacenamento correcto para almacenar segredos. O equipo está a traballar agora en formas de distribuír mellor o acceso a segredos, pods individuais ou outras entidades.
É mellor transferir Storage Helm a segredos e, á súa vez, están protexidos de forma centralizada.
Por suposto que permanecerá límite de almacenamento de datos de 1 MB. Helm aquí usa etcd como almacenamento distribuído para ConfigMaps. E alí consideraron que este era un anaco de datos axeitado para a replicación, etc. Hai unha discusión interesante sobre isto en Reddit, recomendo atopar esta lectura divertida para a fin de semana ou ler o extracto .
Chart Repos
Os gráficos son os máis vulnerables socialmente e poden converterse nunha fonte de "Home no medio", especialmente se usas unha solución de accións. En primeiro lugar, estamos a falar de repositorios que se expoñen a través de HTTP.
Definitivamente cómpre expoñer Helm Repo a través de HTTPS: esta é a mellor opción e é barata.
preste atención a mecanismo de sinatura do gráfico. A tecnoloxía é sinxela como o inferno. Isto é o mesmo que usas en GitHub, unha máquina PGP normal con claves públicas e privadas. Configura e asegúrate, tendo as claves necesarias e asinando todo, que este é realmente o teu gráfico.
Ademais, O cliente Helm admite TLS (non no sentido HTTP do servidor, senón TLS mutuo). Podes usar as claves do servidor e do cliente para comunicarte. Para ser honesto, non uso tal mecanismo porque non me gustan os certificados mutuos. Basicamente, - a ferramenta principal para configurar Helm Repo para Helm 2 - tamén admite a autenticación básica. Podes usar a autenticación básica se é máis cómodo e silencioso.
Tamén hai un complemento , que che permite aloxar Chart Repos en Google Cloud Storage. Isto é bastante cómodo, funciona moi ben e é bastante seguro, porque todos os mecanismos descritos son reciclados.
Se activas HTTPS ou TLS, usas mTLS e habilitas a autenticación básica para reducir aínda máis os riscos, obterás unha canle de comunicación segura con Helm CLI e Chart Repo.
API de gRPC
O seguinte paso é moi importante: protexer Tiller, que está situado no clúster e é, por unha banda, un servidor, por outra banda, el mesmo accede a outros compoñentes e intenta facerse pasar por alguén.
Como xa dixen, Tiller é un servizo que expón gRPC, o cliente Helm chega a el a través de gRPC. Por defecto, por suposto, TLS está desactivado. Por que se fixo isto é unha pregunta discutible, paréceme que simplifica a configuración ao principio.
Para a produción e mesmo a posta en escena, recomendo habilitar TLS en gRPC.
Na miña opinión, a diferenza de mTLS para gráficos, isto é apropiado aquí e faise de forma moi sinxela: xerar unha infraestrutura PQI, crear un certificado, lanzar Tiller, transferir o certificado durante a inicialización. Despois diso, pode executar todos os comandos de Helm, presentándose co certificado xerado e a clave privada.
Deste xeito, protexerase de todas as solicitudes a Tiller desde fóra do clúster.
Así, aseguramos a canle de conexión a Tiller, xa falamos de RBAC e axustamos os dereitos do apiserver de Kubernetes, reducindo o dominio co que pode interactuar.
Casco protexido
Vexamos o diagrama final. É a mesma arquitectura coas mesmas frechas.
Agora todas as conexións pódense debuxar de forma segura en verde:
- para Chart Repo usamos TLS ou mTLS e autenticación básica;
- mTLS para Tiller, e exponse como un servizo gRPC con TLS, usamos certificados;
- o clúster usa unha conta de servizo especial con Role e RoleBinding.
Protexemos significativamente o clúster, pero alguén intelixente dixo:
"Só pode haber unha solución absolutamente segura: un ordenador apagado, que está situado nunha caixa de formigón e está vixiado por soldados".
Hai diferentes formas de manipular datos e atopar novos vectores de ataque. Non obstante, confío en que estas recomendacións acadarán un estándar básico da industria de seguridade.
Bonos
Esta parte non está directamente relacionada coa seguridade, pero tamén será útil. Vouche mostrar cousas interesantes que pouca xente sabe. Por exemplo, como buscar gráficos - oficiais e non oficiais.
No repositorio Agora hai uns 300 gráficos e dous fluxos: estable e incubadora. Calquera que colabore sabe perfectamente o difícil que é pasar da incubadora ao establo e o fácil que é saír voando do establo. Non obstante, esta non é a mellor ferramenta para buscar gráficos para Prometheus e calquera outra cousa que che guste, por un simple motivo: non é un portal onde poidas buscar paquetes comodamente.
Pero hai un servizo , o que fai que sexa moito máis cómodo atopar gráficos. O máis importante é que hai moitos máis repositorios externos e case 800 encantos dispoñibles. Ademais, podes conectar o teu repositorio se por algún motivo non queres enviar os teus gráficos a estable.
Proba hub.helm.sh e desenvolvémolo xuntos. Este servizo está no proxecto Helm, e incluso podes contribuír á súa IU se es un programador front-end e só queres mellorar a aparencia.
Tamén me gustaría chamar a súa atención Integración da API de Open Service Broker. Parece complicado e pouco claro, pero resolve os problemas aos que se enfrontan todos. Déixame explicar cun exemplo sinxelo.
Hai un clúster de Kubernetes no que queremos executar unha aplicación clásica: WordPress. Xeralmente, é necesaria unha base de datos para a funcionalidade completa. Hai moitas solucións diferentes, por exemplo, pode lanzar o seu propio servizo con estado. Isto non é moi cómodo, pero moitas persoas fano.
Outros, como nós en Chainstack, usan bases de datos xestionadas como MySQL ou PostgreSQL para os seus servidores. É por iso que as nosas bases de datos están situadas nalgún lugar da nube.
Pero xorde un problema: necesitamos conectar o noso servizo cunha base de datos, crear un sabor de base de datos, transferir a credencial e xestionala dalgún xeito. Todo isto adoita facerse manualmente polo administrador ou desenvolvedor do sistema. E non hai problema cando hai poucas aplicacións. Cando hai moitos, necesitas unha combinada. Hai tal colleitadora: é Service Broker. Permítelle utilizar un complemento especial para un clúster de nube pública e solicitar recursos ao provedor a través de Broker, coma se dunha API se tratara. Para iso, podes usar ferramentas nativas de Kubernetes.
É moi sinxelo. Pode consultar, por exemplo, MySQL xestionado en Azure cun nivel base (pódese configurar). Usando a API de Azure, a base de datos crearase e prepararase para o seu uso. Non necesitas interferir con isto, o complemento é o responsable diso. Por exemplo, OSBA (complemento de Azure) devolverá a credencial ao servizo e pasarálla a Helm. Poderás usar WordPress con MySQL na nube, non tratar con bases de datos xestionadas en absoluto e non preocuparte polos servizos con estado.
Podemos dicir que Helm actúa como un pegamento que, por unha banda, permite despregar servizos e, por outra banda, consumir os recursos dos provedores da nube.
Podes escribir o teu propio complemento e usar toda esta historia local. Entón, simplemente terás o teu propio complemento para o provedor de nube corporativo. Recomendo probar este enfoque, especialmente se tes unha gran escala e queres implementar rapidamente o desenvolvemento, a posta en escena ou toda a infraestrutura dunha función. Isto facilitará a vida das túas operacións ou DevOps.
Outro descubrimento que xa mencionei é complemento helm-gcs, que che permite usar Google-buckets (almacenamento de obxectos) para almacenar gráficos Helm.
Só necesitas catro comandos para comezar a usalo:
- instalar o complemento;
- inicialo;
- establecer o camiño para o balde, que está situado en gcp;
- publicar gráficos de forma estándar.
O fermoso é que se utilizará o método gcp nativo para a autorización. Podes usar unha conta de servizo, unha conta de programador, o que queiras. É moi cómodo e non custa nada de operar. Se, coma min, promoves a filosofía opsless, isto será moi cómodo, especialmente para equipos pequenos.
Alternativas
Helm non é a única solución de xestión de servizos. Hai moitas preguntas sobre iso, polo que probablemente a terceira versión apareceu tan rápido. Claro que hai alternativas.
Estas poden ser solucións especializadas, por exemplo, Ksonnet ou Metaparticle. Podes utilizar as túas ferramentas clásicas de xestión de infraestruturas (Ansible, Terraform, Chef, etc.) para os mesmos fins dos que vos falei.
Finalmente hai unha solución , cuxa popularidade é cada vez maior.
Operator Framework é a principal alternativa de Helm a considerar.
É máis nativo de CNCF e Kubernetes, pero a barreira de entrada é moito maior, cómpre programar máis e describir os manifestos menos.
Hai varios complementos, como Draft, Scaffold. Facilitan moito a vida, por exemplo, simplifican o ciclo de envío e lanzamento de Helm para que os desenvolvedores poidan despregar un ambiente de proba. Eu chamaríalles empoderadores.
Aquí tes un gráfico visual de onde está todo.
No eixe x está o nivel de control persoal sobre o que está a suceder, no eixe y está o nivel de natividade de Kubernetes. Helm versión 2 cae nalgún lugar no medio. Na versión 3, non é enorme, pero tanto o control como o nivel de natividade melloráronse. As solucións a nivel de Ksonnet aínda son inferiores incluso a Helm 2. Non obstante, paga a pena miralas para saber que máis hai neste mundo. Por suposto, o teu xestor de configuración estará baixo o teu control, pero non é absolutamente nativo de Kubernetes.
O Operator Framework é absolutamente nativo de Kubernetes e permíteche xestionalo de forma moito máis elegante e escrupulosa (pero recorda o nivel de entrada). Pola contra, isto é adecuado para unha aplicación especializada e para a creación de xestión para ela, en lugar dunha colleitadora masiva para envasar un gran número de aplicacións usando Helm.
Os extensores simplemente melloran un pouco o control, complementan o fluxo de traballo ou cortan esquinas nas canalizacións CI/CD.
O futuro de Helm
A boa noticia é que está chegando Helm 3. Xa se publicou a versión alfa de Helm 3.0.0-alpha.2, podes probala. É bastante estable, pero a funcionalidade aínda é limitada.
Por que necesitas Helm 3? En primeiro lugar, esta é unha historia sobre desaparición de Tiller, como compoñente. Isto, como xa entendes, é un gran paso adiante, porque dende o punto de vista da seguridade da arquitectura, todo se simplifica.
Cando se creou Helm 2, que databa da época de Kubernetes 1.8 ou incluso anterior, moitos dos conceptos eran inmaduros. Por exemplo, o concepto CRD agora está a implementarse activamente, e Helm farao use CRDpara almacenar estruturas. Será posible utilizar só o cliente e non manter a parte do servidor. En consecuencia, use comandos nativos de Kubernetes para traballar con estruturas e recursos. Este é un gran paso adiante.
Aparecerá soporte para repositorios OCI nativos (Iniciativa de contedores abertos). Esta é unha gran iniciativa e Helm está interesado principalmente en publicar as súas listas. Chega ao punto de que, por exemplo, Docker Hub admite moitos estándares OCI. Non supoño, pero quizais os provedores clásicos de repositorio de Docker comecen a darche a oportunidade de aloxar os teus gráficos Helm.
A historia controvertida para min é Lua apoio, como motor de modelos para escribir guións. Non son un gran fan de Lua, pero esta sería unha función completamente opcional. Comprobei isto 3 veces; non será necesario usar Lua. Por iso, os que queiran poder usar Lua, os que lles gusta Go, únense ao noso enorme campamento e usan go-tmpl para iso.
Finalmente, o que definitivamente me faltaba era aparición de esquemas e validación de tipos de datos. Non haberá máis problemas con int ou string, sen necesidade de envolver cero entre comiñas dobres. Aparecerá un esquema JSONS que che permitirá describir isto de forma explícita para os valores.
Será moi reelaborado modelo impulsado por eventos. Xa foi descrito conceptualmente. Mira a rama Helm 3, e verás cantos eventos, ganchos e outras cousas se engadiron, o que simplificará moito e, por outra banda, engadirá control sobre os procesos de despregamento e reaccións a eles.
Helm 3 será máis sinxelo, seguro e divertido, non porque Helm 2 non nos guste, senón porque Kubernetes está cada vez máis avanzado. En consecuencia, Helm pode utilizar os desenvolvementos de Kubernetes e crear nela xestores excelentes para Kubernetes.
Outra boa noticia é que Alexander Khayorov diráche: Lembrámosche que a conferencia sobre a integración dos procesos de desenvolvemento, proba e operación celebrarase en Moscova 30 de setembro e 1 de outubro. Aínda podes facelo ata o 20 de agosto e cóntanos a túa experiencia coa solución tarefas do enfoque DevOps.
Siga os puntos de control da conferencia e as noticias en и .
Fonte: www.habr.com