Nota perev. : O interesse crescente no "gerenciador de pacotes Kubernetes" - Helm, que foi observado recentemente, é fácil de explicar. A tão esperada atualização importante do Helm v3, sobre a qual já escrevemos , está no estágio ativo - e não apenas no desenvolvimento, mas também nos lançamentos. Seu último beta, o terceiro consecutivo , foi lançado no início de setembro. E, recentemente, foi realizado um evento bastante grande (para um projeto de código aberto tão especializado), cujas impressões são compartilhadas por seus visitantes do CloudARK, que oferece iPaaS (plataforma de integração como serviço) para o Kubernetes.
Foto original retirada da conta do CNCF FlickrO Helm Summit foi realizado em Amsterdã na semana passada. Reuniu cerca de 150 entusiastas, representando vários usuários e prestadores de serviços no Kubernetes. Aqui estão cinco pontos-chave deste evento.
1. No Helm 3.0 - melhor segurança, suporte a CRD e algumas alterações que quebram a abordagem usual
Participaram da cúpula alguns dos principais membros da equipe principal de desenvolvimento do Helm. Com seus discursos e comunicação à margem, ficou claro que o Helm 3.0 será um marco importante para o projeto. Muitos de vocês provavelmente já ouviram dizer que a terceira versão não terá o Tiller - o componente do servidor Helm.
( Observação : mais sobre isso pode ser encontrado neste artigo .) Outras inovações importantes aparecerão no Helm 3.0, como controles de segurança mais próximos e melhor suporte para definições de recursos personalizados (CRDs). Aqui estão três aspectos principais dos quais me lembro especialmente:
- Na área de segurança, o conjunto de permissões pré-configuradas para usuários por padrão será mínimo. Ao contrário do Tiller, que recebeu automaticamente direitos de administrador em todo o cluster, no Helm 3.0, você terá que conceder manualmente privilégios para contas de usuário (Usuário) e serviço (Serviço) projetadas para trabalhar com o Helm. Essa alteração garante uma tomada de decisão informada pelos administradores sobre a segurança de seus clusters.
- A segunda grande mudança é o suporte aprimorado a CRD. Na versão atual do Helm, o CRD é instalado através do gancho
crd-install , definido como uma anotação. No entanto, nem todos os desenvolvedores e operadores de CRD o utilizam. Isso torna os gráficos Helm vulneráveis a erros de instalação, pois a configuração correta dos gráficos exige que os CRDs sejam colocados na frente dos manifestos de recursos personalizados. O Helm 3.0 trará o suporte a CRD para um novo nível. O subdiretório chrts aparecerá no diretório de crd . Será suficiente para o usuário adicionar todos os arquivos CRD YAML a esse diretório. Helm irá processá-lo antes de definir o restante do gráfico. Este procedimento garantirá que o CRD seja instalado antes da instalação dos manifestos de Recursos Customizados. - As principais mudanças afetarão o trabalho com a CLI. Por exemplo, agora durante a instalação do gráfico, um nome de release aleatório será gerado se não for especificado como um parâmetro de entrada. No Helm 3.0, a situação será o oposto: um parâmetro com um nome se tornará obrigatório. Para preservar a nomeação aleatória de liberações, você precisará especificar um sinalizador especial ao inserir o comando.
2. Consolidação de artefatos nativos da nuvem
Várias sessões foram dedicadas aos problemas de armazenamento dos gráficos Helm. Essas sessões foram lideradas por
Josh Dolitsky , autor do
ChartMuseum . Ele apresentou o problema, as soluções existentes e falou sobre as tendências gerais neste espaço. A principal conclusão é que o trabalho com vários artefatos que precisam ser tratados na abordagem nativa da nuvem (imagens do Docker, gráficos Helm, arquivos de correção Kustomize) deve ser feito da mesma maneira.
O projeto
ORAS - Registro OCI como armazenamento é chamado para garantir o armazenamento de todos esses artefatos em um único registro. Para os usuários do Kubernetes, este é definitivamente um passo na direção certa, pois permitirá consolidar vários artefatos em um registro e, ao mesmo tempo, fornecer suporte para itens como divisão de registro, controle de acesso etc.
3. Leme e operadores
Vários oradores abordaram o tópico de controladores e operadores de usuários em seus discursos.
A apresentação do CloudARK focou nas melhores práticas para a criação de gráficos Helm para operadores.
A equipe da Red Hat falou sobre operadores e o
Hub de Operadores .
Representantes da
Workday , da
Weaveworks e da
Universidade de Notre Dame discutiram a abordagem nativa do Kubernetes para negociar continuamente lançamentos baseados em Helm em um cluster usando um processo chamado GitOps.
( Nota, traduza : Leia mais sobre GitOps aqui .)A principal conclusão de todas essas performances foi que Helm e os operadores se complementam bem. Enquanto o primeiro (Helm) se concentra na estereotipagem e na simplicidade do gerenciamento de artefatos, o último (operadores) se concentra no gerenciamento das tarefas do Dia 2
(ou seja, na fase do ciclo de vida do sistema, quando começa a dar frutos aos seus criadores - aprox. ) para software de terceiros, como bancos de dados relacionais / não relacionais em execução em um cluster Kubernetes.
4. Problemas de gerenciamento de gráfico de leme
Quando se trata de grandes aplicativos corporativos, um gráfico Helm não é suficiente. Alguns gráficos são necessários.
A apresentação do GitLab foi uma descoberta real nesse sentido. Eles têm muitos gráficos, enquanto o tamanho médio do gráfico também é bastante grande (vários milhares de linhas). Gerenciar todos esses gráficos não é uma tarefa fácil por si só.
Houve duas apresentações interessantes sobre vários aspectos desse problema. Em um deles
, a equipe da IBM apresentou sua ferramenta interna que simplifica a pesquisa de gráficos Helm por vários critérios. Eles se concentraram em resolver o problema dos engenheiros do DevOps, que foram forçados a selecionar e instalar gráficos em seus clusters. Em outro,
a equipe Replicated falou sobre tentar resolver o problema de gerenciar edições do Helm chart sem criar cópias ou garfos. A essência de sua abordagem é separar o gráfico Helm base e criar gráficos Helm personalizados, emprestando a idéia de customizar dos arquivos de correção. No futuro, podemos testemunhar uma atividade rápida nessa direção, pois vários fornecedores se concentram em vários aspectos dos gráficos Helm que influenciam seu gerenciamento. Por exemplo, no CloudARK,
focamos nos gráficos Helm para operadores que recebem anotações especiais de
platform-as-code para facilitar a descoberta e facilitar o uso dos Recursos Personalizados.
5. Comunidade hospitaleira
Desenvolvedores de lemes e membros-chave da comunidade eram pessoas muito amigáveis. Eles estavam abertos e disponíveis para todas as discussões e perguntas, como datas de lançamento, pensamentos sobre Helm e customizar, eventos conjuntos com o KubeCon, etc.
Eles também conversaram sobre o processo de participação no desenvolvimento do Helm. Ele não parecia muito complicado. O projeto Helm ainda não adotou o processo KEP (Proposta de aprimoramento do Kubernetes). No entanto, isso pode mudar após a conclusão da fase de incubação.
CloudARK no Helm Summit
Nossa apresentação na cúpula foi dedicada aos princípios e às melhores práticas de criação de gráficos de leme para os operadores. Oferecemos o iPaaS, que permite às equipes de DevOps criar suas próprias pilhas de plataformas Kubernetes sem nenhuma conexão com o provedor Kubernetes ou com as interfaces proprietárias. Os CRD / operadores necessários são empacotados na forma de gráficos Helm, com ênfase especial na compatibilidade dos Recursos Personalizados de vários operadores.
A apresentação foi baseada nas lições aprendidas com o desenvolvimento independente de vários operadores e na análise de mais de cem operadores disponíveis ao público para obter uma camada de plataforma nativa Kubernetes personalizada, pronta para uso corporativo.
Amsterdam
O local da conferência oferece vistas panorâmicas de um dos muitos canais de Amsterdã.
Conclusão
Helm está prestes a se tornar um projeto CNCF de nível superior. Nos últimos anos, ele se tornou mais maduro, ganhou uma comunidade forte e alta popularidade. Se você ainda não o estiver usando, tente. Ele oferece uma das maneiras mais fáceis de modelar e gerenciar artefatos do Kubernetes. Para aqueles que já o usam intensamente, o Helm 3.0 deve dissipar muitas preocupações de segurança e fornecer suporte explícito à extensibilidade do Kubernetes por meio do CRD.
PS do tradutor
Outras impressões do Helm Summit e seus relatórios podem ser encontrados no Twitter usando a tag
#HelmSummit .
Leia também em nosso blog: