A essência da história sobre o gerenciador de pacotes mais popular para Kubernetes poderia ser representada com emojis:
- caixa — é o Helm (isso é o mais apropriado na última versão do Emoji);
- cadeado — segurança;
- bonequinho — solução do problema.
Na verdade, tudo será um pouco mais complicado, e a narrativa está cheia de detalhes técnicos sobre como tornar o Helm seguro..
- Em resumo, o que é o Helm, caso você não soubesse ou tivesse esquecido. Quais problemas ele resolve e onde ele se encaixa na ecossistema.
- Vamos considerar a arquitetura do Helm. Nenhuma conversa sobre segurança e como tornar uma ferramenta ou solução mais segura pode deixar de lado a compreensão da arquitetura do componente.
- Vamos discutir os componentes do Helm.
- A pergunta mais candente — o futuro — a nova versão do Helm 3.
Tudo nesta artigo se refere ao Helm 2. Esta versão atualmente está em produção e, provavelmente, é esta que você está usando agora, e é nela que existem ameaças à segurança.
Sobre o palestrante: Alexander Khayorov () tem 10 anos de experiência em desenvolvimento, ajudando a melhorar o conteúdo e se juntou ao comitê . Atualmente trabalha na Chainstack como líder de desenvolvimento — um híbrido entre gerente de desenvolvimento e a pessoa responsável pela entrega de releases finais. Ou seja, está no campo de batalha, onde tudo acontece, desde a criação do produto até sua operação.
Chainstack é uma startup pequena, em rápido crescimento, cuja missão é permitir que os clientes esqueçam a infraestrutura e as complexidades de operar aplicativos descentralizados, a equipe de desenvolvimento está em Cingapura. Não peça para a Chainstack comprar ou vender criptomoedas, mas ofereça conversar sobre frameworks de blockchain empresarial, e eles ficarão felizes em responder.
Helm
Este é o gerenciador de pacotes (charts) para Kubernetes. A maneira mais clara e versátil de trazer aplicativos para o cluster Kubernetes.
Refere-se, é claro, a uma abordagem mais estruturada e industrial, em vez de criar seus próprios manifests YAML e escrever pequenas utilidades.
O Helm é o melhor que existe atualmente em termos de disponibilidade e popularidade.
Por que o Helm? Em primeiro lugar, porque é suportado pela CNCF. Cloud Native é uma grande organização, que é a empresa-mãe de projetos como Kubernetes, etcd, Fluentd e outros.
Outro fato importante é que o Helm é um projeto muito popular. Quando em janeiro de 2019 comecei a pensar em como tornar o Helm seguro, o projeto tinha mil estrelas no GitHub. Em maio, já haviam 12 mil.
Muitas pessoas se interessam pelo Helm, então, mesmo que você ainda não o utilize, o conhecimento sobre sua segurança será útil. A segurança é importante.
A equipe principal do Helm é apoiada pela Microsoft Azure, o que torna este projeto bastante estável, ao contrário de muitos outros. O lançamento do Helm 3 Alpha 2 em meados de julho é um indicativo de que muitas pessoas estão trabalhando no projeto, e elas têm a vontade e os recursos para desenvolver e melhorar o Helm.
O Helm resolve vários problemas fundamentais na gestão de aplicações em Kubernetes.
- Empacotamento de aplicações. Mesmo uma aplicação simples como 'Hello, World' em WordPress já envolve vários serviços, e é desejável que eles sejam empacotados juntos.
- Gestão da complexidade que surge com a administração dessas aplicações.
- O ciclo de vida que não termina após a instalação ou o deployment da aplicação. Ela continua a existir, precisa ser atualizada, e o Helm ajuda nisso, oferecendo as medidas e políticas adequadas.
Empacotamento é organizado de forma clara: há metadados em total conformidade com o funcionamento de um gerenciador de pacotes comum para Linux, Windows ou MacOS. Ou seja, repositórios, dependências de diferentes pacotes, metainformações para aplicações, configurações, particularidades de configuração, indexação de informações, etc. O Helm permite obter e utilizar tudo isso para as aplicações.
Gestão da complexidade. Se você tem muitas aplicações similares, a parametrização se faz necessária. Daí surgem os templates, mas para não ter que desenvolver sua própria forma de criar templates, você pode usar o que o Helm oferece pronto.
Gestão do ciclo de vida da aplicação — na minha opinião, essa é a questão mais interessante e não resolvida. Foi a razão pela qual eu cheguei ao Helm. Precisávamos monitorar o ciclo de vida da aplicação, queríamos transferir nosso CI/CD e ciclos de aplicações para essa nova abordagem.
O Helm permite:
- gerenciar deployments, introduz o conceito de configuração e revisões;
- realizar rollback com sucesso;
- usar hooks para diferentes eventos;
- adicionar verificações adicionais para as aplicações e reagir a seus resultados.
Além disso o Helm tem 'baterias' — uma enorme quantidade de coisas deliciosas que podem ser incluídas como plugins, facilitando a sua vida. Os plugins podem ser escritos por conta própria, eles são bastante isolados e não requerem uma arquitetura rigorosa. Se você deseja implementar algo, recomendo fazê-lo como um plugin e, depois, possivelmente incluí-lo no upstream.
O Helm baseia-se em três conceitos principais:
- Repositório de Chart — descrição e conjunto de parametrizações possíveis para o seu manifesto.
- Config — ou seja, valores que serão aplicados (texto, valores numéricos, etc.).
- Release reúne os dois componentes principais, e juntos eles se tornam um Release. Os Releases podem ser versionados, atingindo assim uma organização do ciclo de vida: pequeno no momento da instalação e grande no momento de upgrade, downgrade ou rollback.
Arquitetura do Helm
No diagrama, a arquitetura de alto nível do Helm é conceitualmente refletida.
Vale lembrar que o Helm está relacionado ao Kubernetes. Portanto, não podemos prescindir de um cluster Kubernetes (retângulo). O componente kube-apiserver está no mestre. Sem Helm, temos Kubeconfig. O Helm traz um pequeno binário, se assim posso chamar, a ferramenta Helm CLI, que pode ser instalada no computador, laptop, mainframe — em qualquer lugar.
Mas isso não é suficiente. O Helm tem um componente servidor chamado Tiller. Ele representa os interesses do Helm dentro do cluster, sendo um aplicativo dentro do cluster Kubernetes, assim como qualquer outro.
O próximo componente é o Repositório de Chart — um repositório com charts. Existe um repositório oficial, e pode haver um repositório privado da empresa ou do projeto.
Interação
Vamos considerar como os componentes da arquitetura interagem quando queremos instalar um aplicativo com o Helm.
- Nós dizemos
Helm install, chamamos o repositório (Repositório de Chart) e obtemos o chart do Helm.
- A ferramenta Helm (Helm CLI) interage com o Kubeconfig para descobrir a qual cluster se referir.
- Obtidas essas informações, a ferramenta se comunica com o Tiller, que está em nosso cluster, como se fosse um aplicativo.
- O Tiller se dirige ao Kube-apiserver para realizar ações no Kubernetes, criando alguns objetos (serviços, pods, réplicas, segredos, etc.).
Em seguida, vamos complicar o diagrama para ver o vetor de ataques ao qual toda a arquitetura do Helm pode estar sujeita. Depois, tentaremos protegê-la.
Vetor de ataques
O primeiro ponto potencialmente fraco é a API privilegiada—usuárioNo âmbito do esquema, é um hacker que obteve acesso administrativo ao Helm CLI.
Um usuário da API não privilegiado também pode representar um perigo se estiver por perto. Esse usuário terá outro contexto, por exemplo, ele pode estar fixado em um namespace do cluster nas configurações do Kubeconfig.
O vetor de ataque mais interessante pode ser um processo que está dentro do cluster, perto do Tiller, e pode acessá-lo. Isso pode ser um servidor web ou um microsserviço que vê o ambiente de rede do cluster.
Uma variante exótica, mas em ascensão, de ataque está relacionada ao Chart Repo. Um chart criado por um autor mal-intencionado pode conter recursos inseguros, e você o executará, acreditando nele. Ou ele pode substituir o chart que você baixa do repositório oficial e, por exemplo, criar um recurso na forma de políticas e escalar seu acesso.
Vamos tentar nos defender de ataques por todos esses quatro lados e descobrir onde estão os problemas na arquitetura do Helm e onde, possivelmente, não estão.
Vamos ampliar o esquema, adicionar mais elementos, mas manter todos os componentes básicos.
O Helm CLI se comunica com o Chart Repo, interage com o Kubeconfig, e a operação é transferida para o cluster no componente Tiller.
O Tiller é representado por dois objetos:
- O serviço Tiller-deploy svc, que expõe um certo serviço;
- O pod Tiller-deploy (no esquema, em uma única instância em uma réplica), no qual toda a carga opera e que se comunica com o cluster.
Diferentes protocolos e esquemas são usados para a interação. Do ponto de vista de segurança, os mais interessantes para nós são:
- O mecanismo pelo qual o Helm CLI acessa o chart repo: qual protocolo é utilizado, existe autenticação e o que pode ser feito com isso.
- O protocolo pelo qual o Helm CLI, usando kubectl, se comunica com o Tiller. Este é um servidor RPC instalado dentro do cluster.
- O próprio Tiller está acessível para microsserviços que estão no cluster e interage com o Kube-apiserver.
Vamos discutir todas essas direções em ordem.
RBAC
É inútil falar sobre qualquer segurança do Helm ou de outro serviço dentro do cluster se o RBAC não estiver ativado.
Parece que essa não é a recomendação mais recente, mas estou certo de que muitos ainda não ativaram o RBAC mesmo em produção, porque isso é um grande trabalho e é necessário ajustar muitas coisas. No entanto, eu encorajo a fazê-lo.
— um site de advogado para RBAC. Ele reúne uma enorme quantidade de materiais interessantes que ajudarão a configurar o RBAC, mostrarão por que ele é bom e como viver com ele no ambiente de produção.
Vou tentar explicar como funciona o Tiller e o RBAC. O Tiller opera dentro do cluster sob uma conta de serviço específica. Geralmente, se o RBAC não estiver configurado, será um superusuário. Na configuração padrão, o Tiller será administrador. É por isso que muitas vezes se diz que o Tiller é um túnel SSH para seu cluster. Na verdade, é assim, então você pode usar uma conta de serviço especializada em vez da Default Service Account no diagrama acima.
Quando você inicializa o Helm, instalando-o pela primeira vez no servidor, pode definir uma conta de serviço usando --service-account. Isso permitirá usar um usuário com o mínimo conjunto necessário de permissões. No entanto, será preciso criar uma "guirlanda": Role e RoleBinding.
Infelizmente, o Helm não fará isso por você. Você ou seu administrador do cluster Kubernetes precisam preparar previamente um conjunto de Role e RoleBinding para a conta de serviço, para serem passados ao Helm.
Surge a pergunta – qual é a diferença entre Role e ClusterRole? A diferença é que o ClusterRole atua para todos os namespaces, ao contrário das Role e RoleBinding comuns, que funcionam apenas para um namespace específico. É possível configurar políticas tanto para todo o cluster e todos os namespaces, quanto de forma personalizada para cada namespace individualmente.
Vale mencionar que o RBAC também resolve outro grande problema. Muitos reclamam que o Helm, infelizmente, não é multitenancy (não suporta multi-inquilinos). Se várias equipes utilizam o cluster e o Helm, é praticamente impossível configurar políticas e restringir o acesso dentro desse cluster, pois existe uma conta de serviço sob a qual o Helm opera, e ele cria todos os recursos do cluster sob essa conta, o que muitas vezes é muito inconveniente. Isso é verdade – tanto o arquivo binário em si, quanto o processo, O Helm Tiller não tem noção de multitenancy..
No entanto, há uma ótima maneira de executar o Tiller no cluster várias vezes. Não há problemas com isso, o Tiller pode ser executado em cada namespace. Assim, você pode aproveitar o RBAC, o Kubeconfig como contexto, e limitar o acesso ao Helm específico.
Isso se parecerá com o seguinte.
Por exemplo, há dois Kubeconfig com contexto para equipes diferentes (dois namespaces): Equipe X para a equipe de desenvolvimento e o cluster do administrador. O cluster do administrador possui um Tiller amplo, que está no namespace Kube-system, com uma service-account avançada. E um namespace separado para a equipe de desenvolvimento, que poderá implantar seus serviços em um namespace específico.
Esse é um método viável, Tiller não é tão exigente a ponto de impactar significativamente seu orçamento. É uma das soluções rápidas.
Sinta-se à vontade para configurar o Tiller separadamente e fornecer Kubeconfig com contexto para a equipe, para um desenvolvedor específico ou para os ambientes: Dev, Staging, Production (é duvidoso que tudo esteja em um único cluster, no entanto, é possível fazer assim).
Dando continuidade à nossa história, vamos mudar do RBAC e falar sobre ConfigMaps.
ConfigMaps
O Helm usa ConfigMaps como armazenamento de dados. Quando falamos sobre a arquitetura, não havia um banco de dados onde as informações sobre releases, configurações, rollbacks, etc. fossem armazenadas. Para isso, são usados ConfigMaps.
O principal problema com os ConfigMaps é bem conhecido - eles não são seguros por princípio, neles não é possível armazenar dados sensíveis. Refere-se a tudo que não deve ser exposto além do serviço, como senhas. O método mais nativo para o Helm atualmente é a transição do uso de ConfigMaps para segredos.
Isso é feito de forma muito simples. Você redefine a configuração do Tiller e indica que o armazenamento serão segredos. Então, em cada deploy, você receberá não um ConfigMap, mas sim um segredo.
Você pode argumentar que os próprios segredos são um conceito estranho e não são muito seguros. No entanto, é importante entender que isso é gerenciado pelos próprios desenvolvedores do Kubernetes. Desde a versão 1.10, ou seja, já faz um tempo, há a possibilidade, pelo menos em nuvens públicas, de conectar um armazenamento adequado para armazenar segredos. A equipe agora está trabalhando para melhorar ainda mais o acesso aos segredos, a pods específicas ou outras entidades.
O armazenamento do Helm deve ser melhorado para segredos, e estes devem ser protegidos de forma centralizada.
Claro, ainda haverá um limite de armazenamento de dados de 1 MB. O Helm aqui utiliza o etcd como um armazenamento distribuído para ConfigMaps. E lá consideraram que esse era um chunk de dados apropriado para replicações, etc. Há uma discussão interessante sobre isso no Reddit, recomendo que encontre essa leitura divertida para o fim de semana ou leia um resumo. .
Repositórios de Charts
Os charts são socialmente vulneráveis e podem se tornar fonte de "Man in the middle", especialmente se uma solução padrão for utilizada. Em primeiro lugar, estamos falando de repositórios que são apresentados via HTTP.
Definitivamente, é preciso expor o Helm Repo via HTTPS — essa é a melhor opção e não custa muito.
Preste atenção em mecanismo de assinaturas de charts. A tecnologia é incrivelmente simples. É a mesma que você usa no GitHub, uma máquina PGP comum com chaves públicas e privadas. Configure e você terá certeza, tendo as chaves necessárias e assinando tudo, de que este realmente é seu chart.
Além disso, O cliente Helm suporta TLS (não no sentido de HTTP do lado do servidor, mas mutual TLS). Você pode usar chaves de servidor e cliente para se comunicar. Vou ser honesto, não uso esse mecanismo por não gostar de certificados mútuos. Em princípio, — a principal ferramenta para expor o Helm Repo para Helm 2 — também suporta autenticação básica. Você pode usar autenticação básica, se isso for mais conveniente e confortável.
Ainda há um plugin , que permite hospedar Repositórios de Charts no Google Cloud Storage. Isso é bastante conveniente, funciona muito bem e é seguro o suficiente, pois utiliza todos os mecanismos descritos.
Se ativar HTTPS ou TLS, usar mTLS, adicionar autenticação básica para reduzir ainda mais os riscos, terá um canal de comunicação seguro entre o Helm CLI e o Chart Repo.
API gRPC
O próximo passo é muito importante — proteger o Tiller, que está no cluster e que, por um lado, é um servidor e, por outro, acessa outros componentes e tenta se apresentar como alguém.
Como já disse, o Tiller é um serviço que expõe gRPC, o cliente Helm se conecta a ele via gRPC. Por padrão, naturalmente, o TLS está desligado. O porquê disso é uma questão discutível, me parece ser para simplificar a configuração inicial.
Para produção e até mesmo para staging, recomendo ativar TLS no gRPC.
Na minha opinião, ao contrário do mTLS para gráficos, aqui isso é apropriado e feito de forma muito simples — você gera a infraestrutura PQI, cria um certificado, inicia o Tiller e passa o certificado durante a inicialização. Após isso, você pode executar todos os comandos do Helm, apresentando-se com o certificado gerado e a chave privada.
Assim, você se protegerá de todas as solicitações ao Tiller de fora do cluster.
Agora, protegemos o canal de conexão ao Tiller, já discutimos o RBAC e ajustamos as permissões do Kubernetes apiserver, reduzindo o domínio com o qual ele pode interagir.
Helm Seguro
Vamos olhar para o diagrama final. É a mesma arquitetura com as mesmas setas.
Todas as conexões agora podem ser desenhadas em verde:
- para o Chart Repo, usamos TLS ou mTLS e autenticação básica;
- mTLS para o Tiller, que é exposto como um serviço gRPC com TLS, usando certificados;
- no cluster, usamos uma conta de serviço especial com Role e RoleBinding.
Nós protegemos significativamente o cluster, mas alguém sábio disse:
«A única solução absolutamente segura pode ser um computador desligado, que está dentro de uma caixa de concreto e é guardado por soldados».
Existem várias maneiras de manipulação de dados e encontrar novos vetores de ataque. No entanto, estou confiante de que essas recomendações permitirão implementar um padrão industrial básico de segurança.
Bônus
Esta parte não se relaciona diretamente à segurança, mas também será útil. Vou mostrar algumas coisas interessantes que poucas pessoas conhecem. Por exemplo, como procurar gráficos — oficiais e não oficiais.
No repositório atualmente há cerca de 300 gráficos e duas streams: stable e incubator. Quem contribui sabe muito bem como é difícil passar do incubator para o stable, e como é fácil sair do stable. No entanto, esse não é o melhor instrumento para procurar gráficos para Prometheus e tudo o que você gosta, por uma simples razão — não é um portal prático para pesquisar pacotes.
Mas existe um serviço , com o qual é muito mais fácil encontrar gráficos. O mais importante é que lá há muito mais repositórios externos e quase 800 gráficos disponíveis. Além disso, você pode conectar seu próprio repositório, se por algum motivo não quiser enviar seus gráficos para o stable.
Experimente hub.helm.sh e vamos desenvolvê-lo juntos. Este serviço está sob o projeto Helm, e você pode contribuir até mesmo na sua interface, se você é um desenvolvedor front-end e deseja apenas melhorar a aparência.
Quero também chamar sua atenção para a integração da API Open Service Broker. Parece complicado e confuso, mas resolve problemas com os quais todos se deparam. Vou explicar com um exemplo simples.
Temos um cluster Kubernetes onde queremos rodar um aplicativo clássico — WordPress. Normalmente, para plena funcionalidade, precisamos de um banco de dados. Existem muitas soluções diferentes, por exemplo, é possível rodar seu próprio serviço stateful. Isso não é muito conveniente, mas muitos fazem assim.
Outros, como nós na Chainstack, utilizamos bancos de dados gerenciados, como MySQL ou PostgreSQL, para servidores. Assim, nossos bancos de dados estão em algum lugar na nuvem.
Mas surge um problema: é necessário conectar nosso serviço ao banco de dados, criar o flavor do banco de dados, passar as credenciais e gerenciar tudo isso. Geralmente, isso é feito manualmente por um administrador de sistema ou um desenvolvedor. E não há problema algum quando há poucos aplicativos. Quando são muitos, é preciso um mecanismo. Esse mecanismo existe — é o Service Broker. Ele permite usar um plugin especial para o cluster de nuvem pública e solicitar recursos ao provedor via Broker, como se fosse uma API. Isso pode ser feito com as ferramentas nativas do Kubernetes.
É muito simples. Por exemplo, podemos solicitar um Managed MySQL no Azure com o tier básico (isso pode ser configurado). Usando a API do Azure, o banco será criado e preparado para uso. Você não precisará se envolver nisso, o plugin cuida disso. Por exemplo, o OSBA (plugin do Azure) retornará as credenciais ao serviço, passando isso para o Helm. Você poderá utilizar o WordPress com o MySQL na nuvem, sem se preocupar com bancos de dados gerenciados e sem se estressar com serviços stateful internos.
Pode-se dizer que o Helm atua como uma cola, que de um lado permite implantar serviços e do outro — consumir recursos dos provedores de nuvem.
É possível escrever seu próprio plugin e utilizar toda essa história on-premise. Assim, você terá seu próprio plugin para o provedor de Cloud corporativo. Eu recomendo tentar essa abordagem, especialmente se você tem uma grande escala e deseja implantar rapidamente dev, staging ou toda a infraestrutura para uma funcionalidade. Isso facilitará a vida para suas operações ou DevOps.
Mais uma descoberta que já mencionei — é o plugin helm-gcs, que permite usar Google-buckets (armazenamento de objetos) para armazenar charts do Helm.
São necessárias apenas quatro comandos para começar a utilizá-lo:
- instalar o plugin;
- inicializá-lo;
- definir o caminho para o bucket que está no gcp;
- publicar os charts de forma padrão.
A beleza disso é que será utilizado o método nativo do gcp para autenticação. Você pode usar uma conta de serviço, conta de desenvolvedor — o que quiser. Isso é muito conveniente e não gera custos de operação. Se você, assim como eu, defende a filosofia opsless, será muito útil, especialmente para pequenas equipes.
Alternativas
O Helm não é a única solução para gerenciamento de serviços. Existem muitas questões sobre isso, talvez seja por isso que a terceira versão surgiu tão rapidamente. Claro, existem alternativas.
Podem ser soluções especializadas, como Ksonnet ou Metaparticle. Você pode usar suas ferramentas clássicas de gerenciamento de infraestrutura (Ansible, Terraform, Chef, etc.) para os mesmos fins que mencionei.
Finalmente, há uma solução , cuja popularidade está crescendo.
Operator Framework é a principal alternativa ao Helm, que merece atenção.
É mais nativo para CNCF e Kubernetes, mas a barreira de entrada é muito maior, requer mais programação e menos descrição de manifestos.
Existem vários addons, como Draft, Scaffold. Eles facilitam muito a vida, por exemplo, para os desenvolvedores, simplificando o ciclo de envio e execução do Helm para o deployment de um ambiente de teste. Eu os chamaria de expandidores de capacidades.
Aqui está um gráfico claro sobre onde cada coisa está.
No eixo horizontal está o nível de controle pessoal que você tem sobre o que está acontecendo, e no eixo vertical está o nível de natividade do Kubernetes. A versão 2 do Helm está mais ou menos no meio. A versão 3 não trouxe uma grande diferença, mas tanto o controle quanto o nível de natividade foram aprimorados. As soluções de nível Ksonnet ainda ficam atrás até mesmo do Helm 2. No entanto, vale a pena dar uma olhada nelas para saber o que mais existe neste mundo. Claro, seu gerenciador de configuração estará sob seu controle, mas não é absolutamente nativo para Kubernetes.
O Operator Framework é absolutamente nativo para Kubernetes e permite gerenciá-lo de uma forma muito mais elegante e minuciosa (mas lembremos do nível de entrada). Provavelmente, é mais adequado para aplicações especializadas e para criar gerência para elas, em vez de um grande combinado para empacotar uma enorme quantidade de aplicações com o Helm.
Os expandidores apenas melhoram um pouco o controle, complementam o fluxo de trabalho ou cortam arestas dos pipelines de CI/CD.
O futuro do Helm
A boa notícia é que o Helm 3 está chegando. Já foi lançada a versão alfa do Helm 3.0.0-alpha.2, que pode ser testada. Está bastante estável, mas a funcionalidade ainda é limitada.
Por que o Helm 3 é necessário? Em primeiro lugar, é sobre o desaparecimento do Tiller, como componente. Isso, como você já deve entender, é um grande passo à frente, pois do ponto de vista de segurança da arquitetura tudo fica mais simples.
Quando o Helm 2 foi criado, isso foi durante os tempos do Kubernetes 1.8 ou até antes, muitas concepções eram imaturas. Por exemplo, a concepção de CRD está sendo ativamente implementada agora, e o Helm vai usar CRD, para armazenar estruturas. Será possível usar apenas o cliente e não precisar manter a parte do servidor. Assim, será possível utilizar comandos nativos do Kubernetes para trabalhar com estruturas e recursos. Isso é um enorme passo à frente.
Haverá suporte a repositórios nativos OCI (Open Container Initiative). Esta é uma grande iniciativa, e para o Helm, ela é interessante principalmente para hospedar seus charts. Chega ao ponto de que, por exemplo, o Docker Hub suporta muitos padrões OCI. Eu não estou prevendo, mas é possível que os provedores clássicos de repositórios Docker comecem a permitir que você hospede seus charts do Helm.
Uma história polêmica para mim é a suporte ao Lua, como engine de templating para escrever scripts. Eu não sou um grande fã de Lua, mas isso será uma opção totalmente opcional. Eu verifiquei três vezes — o uso do Lua não será obrigatório. Portanto, quem quiser poderá usar Lua, quem gosta de Go — junte-se ao nosso grande grupo e use o go-tmpl para isso.
Finalmente, o que eu realmente sentia falta era da aparição de esquemas e validação de tipos de dados. Não haverá mais problemas com int ou string, não será necessário colocar zero entre aspas duplas. Haverá um esquema JSONS, que permitirá descrever isso explicitamente para os values.
A modelo baseado em eventos será fortemente reformulada.Já está conceitualmente descrita. Veja a branch do Helm 3 e veja quantos eventos, hooks e outros foram adicionados, o que simplificará muito e, por outro lado, aumentará o controle sobre os processos de deployment e reações a eles.
O Helm 3 será mais simples, seguro e interessante não porque não gostamos do Helm 2, mas porque o Kubernetes está se tornando mais avançado. Assim, o Helm poderá utilizar as inovações do Kubernetes e criar excelentes gerentes para o Kubernetes.
Outra boa notícia é que Alexandre Khayev falará sobre Lembramos que a conferência sobre a integração dos processos de desenvolvimento, teste e operação ocorrerá em Moscovo nos dias 30 de setembro e 1 de outubro.Até 20 de agosto ainda é possível e compartilhar sua experiência na solução desafios da abordagem DevOps.
Acompanhe os checkpoints da conferência e as novidades no e .
Fonte: habr.com
