Leme sem exageros. Olhar sóbrio
Helm é um gerenciador de pacotes para o Kubernetes.
À primeira vista, não é ruim. Essa ferramenta simplifica bastante o processo de lançamento, mas às vezes pode ser um aborrecimento, você não faz nada!
Recentemente, Helm foi oficialmente reconhecido como o principal projeto @CloudNativeFdn , e é amplamente usado pela comunidade. Isso diz muito, mas eu gostaria de falar brevemente sobre os momentos desagradáveis associados a este gerenciador de pacotes.
Qual é o verdadeiro valor do Helm?
Ainda não consigo responder a essa pergunta com confiança. O Helm não fornece nenhum recurso especial. Quais benefícios o Tiller (lado do servidor) traz?
Muitos gráficos Helm estão longe de serem perfeitos e são necessários esforços adicionais para usá-los no cluster Kubernetes. Por exemplo, eles não possuem RBAC, limites de recursos e políticas de rede. Simplesmente pegar e instalar o gráfico Helm em formato binário - sem pensar em como ele funcionará - não funcionará.
Não basta elogiar Helm, dando os exemplos mais simples. Você explicará por que é tão bom - especialmente em termos de um ambiente de trabalho seguro para vários inquilinos.
As palavras estão vazias. Mostre-me o código!
- Linus Torvalds
Um nível adicional de autorização e controle de acesso
Lembro-me de alguém comparando Tiller a um "enorme servidor sudo". Na minha opinião, este é apenas o próximo nível de autorização, que ao mesmo tempo requer certificados TLS adicionais, mas não fornece recursos de controle de acesso. Por que não usar a API Kubernetes e o modelo de segurança existente que suporta auditoria e RBAC?
Uma ferramenta de processamento de modelo superestimada?
O fato é que, para processamento e análise estática dos arquivos de modelo Go, é values.yaml a configuração do arquivo values.yaml e, em seguida, o manifesto Kubernetes processado é usado com os metadados correspondentes armazenados no ConfigMap.
E você pode usar alguns comandos simples:
$ # render go-template files using golang or python script $ kubectl apply --dry-run -f . $ kubectl apply -f .
Percebi que os desenvolvedores geralmente usavam um arquivo values.yaml por ambiente ou até obtinham de values.yaml.tmpl antes do uso.
Isso não faz sentido ao trabalhar com segredos do Kubernetes, que geralmente são criptografados e têm várias versões no repositório. Para contornar essa limitação, você precisará usar o plug-in helm-secrets ou o comando --set key=value . De qualquer forma, outro nível de complexidade é adicionado.
Helm como uma ferramenta de gerenciamento do ciclo de vida da infraestrutura
Esqueça. Isso não é possível, especialmente se estivermos falando sobre os principais componentes do Kubernetes, como o kube-dns, o provedor CNI, o autoscaler de cluster, etc. Os ciclos de vida desses componentes variam e o Helm não se encaixa neles.
Minha experiência com o Helm mostra que essa ferramenta é ótima para implantações simples nos principais recursos do Kubernetes, facilmente implementadas a partir do zero e sem um processo de liberação complicado.
Infelizmente, com implantações mais complexas e frequentes, incluindo Namespace, RBAC, NetworkPolicy, ResourceQuota e PodSecurityPolicy, o Helm não consegue lidar.
Entendo que os fãs de Helm podem não gostar das minhas palavras, mas essa é a realidade.
Elmo do Estado
O servidor Tiller armazena informações nos arquivos ConfigMap dentro do Kubernetes. Ele não precisa de seu próprio banco de dados.
Infelizmente, o tamanho do ConfigMap não pode exceder 1 MB devido a limitações do etcd .
Espero que alguém tenha uma maneira de melhorar o driver de armazenamento do ConfigMap para compactar a versão serializada antes de passar para o armazenamento. No entanto, acho que o verdadeiro problema ainda não pode ser resolvido.
Falhas aleatórias e tratamento de erros
Para mim, o maior problema de Helm é sua insegurança.
Erro: UPGRADE FAILED: "foo" não possui versões implantadas
Este, IMHO, é um dos problemas mais irritantes de Helm.
Se não foi possível criar a primeira versão, cada tentativa subsequente falhará com um erro indicando a impossibilidade de atualizar de um estado desconhecido.
A solicitação a seguir para inclusão de alterações "corrige" o erro adicionando o sinalizador --force , que na verdade apenas mascara o problema executando o helm delete & helm install —replace
No entanto, na maioria dos casos, você precisará fazer uma limpeza completa da liberação.
helm delete --purge $RELEASE_NAME
Erro: falha na liberação foo: tempo limite excedido aguardando a condição
Se ServiceAccount estiver ausente ou o RBAC não permitir a criação de um recurso específico, o Helm retornará a seguinte mensagem de erro:
Error: release foo failed: timed out waiting for the condition
Infelizmente, a causa raiz deste erro não pode ser vista:
kubectl -n foo get events --sort-by='{.lastTimestamp}'
Error creating: pods "foo-5467744958" is forbidden: error looking up service account foo/foo: serviceaccount "foo" not found
Falhar fora do azul
Nos casos mais avançados, o Helm gera um erro sem executar nenhuma ação. Por exemplo, às vezes ele não atualiza os limites de recursos.
O comando helm init executa o leme com uma cópia, não na configuração de alta disponibilidade
O Leme por padrão não implica em alta disponibilidade, e a solicitação para ativar alterações por referência ainda está aberta.
Um dia isso levará ao tempo de inatividade ...
Leme 3? Operadores? O futuro?
A próxima versão do Helm adicionará alguns recursos promissores:
- arquitetura de serviço único sem separação entre cliente e servidor. Não há mais leme;
- mecanismo de script Lua embutido;
- Fluxo de trabalho do DevOps com base em solicitações de inclusão e no novo projeto Helm Controller.
Consulte Propostas de projeto do leme 3 para obter mais informações.
Eu realmente gosto da idéia de arquitetura sem o Tiller, mas os scripts baseados em Lua estão em dúvida, porque podem complicar os gráficos.
Notei que recentemente os operadores que são muito mais adequados para o Kubernetes do que os gráficos Helm ganharam popularidade.
Eu realmente espero que a comunidade em breve lide com os problemas do Helm (com a nossa ajuda, é claro), mas por enquanto eu mesmo tentarei usar essa ferramenta o menos possível.
Entenda isso: este artigo é minha opinião pessoal, ao qual cheguei ao criar uma plataforma de nuvem híbrida para implantações baseadas no Kubernetes.