Tutorial do gráfico do leme: Um guia passo a passo com exemplos

Instalação e configuração do Helm

Você verá como instalar o Helm CLI no Windows, Mac e Linux.

No momento em que este artigo foi escrito, a versão mais recente do Helm é a 3.17.2. Os exemplos abordados neste artigo usarão a versão 3.17.2. Você pode encontrar o binário mais recente em nas versões oficiais do GitHub.

Instalação no Windows

Baixe o binário correto correspondente à arquitetura do seu sistema no link de versões do GitHub acima.

Helm binário para Windows

Extraia o arquivo ZIP baixado. Você deve obter os arquivos mostrados abaixo.

Binário do leme

Crie uma pasta chamada "helm" no diretório "C:\Program Files\". Mova os três arquivos acima para lá.

Mova os arquivos para a pasta "helm" recém-criada

Agora, precisaremos adicionar um caminho em nossas variáveis de ambiente para apontar para esse diretório recém-criado "C:\Program Files\helm". Abra a configuração "Editar as variáveis de ambiente do sistema".

Editar as variáveis de ambiente do sistema

A janela "Propriedades do sistema" abaixo será exibida. Na guia "Advanced" (Avançado), selecione "Environment Variables..." (Variáveis de ambiente...)

Propriedades do sistema

A janela "Environment Variables" (Variáveis de ambiente) abaixo será exibida. Em "System variables" (Variáveis do sistema), selecione "Path" (Caminho). Certifique-se de que ele esteja destacado em azul. Depois disso, selecione "Edit" (Editar).

Variáveis de ambiente

A janela "Editar variável de ambiente" será exibida. Selecione "New" (Novo), insira o caminho "C:\Program Files\helm" (C:\Arquivos de programas\helm) e selecione "OK".

Edite a variável de ambiente

Selecione "OK" nas janelas "Environment Variables" (Variáveis de ambiente) e "System Properties" (Propriedades do sistema) para fechá-las. Abra um novo terminal e verifique se o comando Helm funciona.

Verifique a instalação do Helm CLI

Instalando no macOS

Você pode instalar o Helm CLI no macOS por meio do Homebrew ou do binário. Abordarei os dois métodos de instalação.

Instalação binária

Abra o terminal (zsh) e execute os seguintes comandos.

# Download the correct binary corresponding to your system’s architecture.
wget https://get.helm.sh/helm-v3.17.2-darwin-arm64.tar.gz

# Extract the binary
tar -zxvf helm-v3.17.2-darwin-arm64.tar.gz

# Move the helm binary to /usr/local/bin
sudo mv darwin-arm64/helm /usr/local/bin/

# Verify Helm CLI
helm version

Instalação do Helm via binário no macOS

Homebrew

Certifique-se de que você tenha o Homebrew instalado localmente. Para verificar, execute brew --version. Caso contrário, você pode consultar a página oficial do Homebrew para obter instruções de instalação.

Execute os seguintes comandos para instalar o Helm CLI:

# With brew installed, update Homebrew's formulae and cask definitions
brew update

# Install Helm CLI
brew install helm

# Verify the installation
helm version

# Verify the location of the helm binary stored locally
which helm

Instalação do Helm via brew no macOS

Instalação no Linux

Para demonstrar a instalação no Linux, iniciei um Amazon Linux EC2 com a AMI ami-065a492fef70f84b1.

# Switch to superuser
sudo su -

# Download the correct binary corresponding to your system’s architecture.
wget https://get.helm.sh/helm-v3.17.2-linux-amd64.tar.gz

# Extract the binary
tar -zxvf helm-v3.17.2-linux-amd64.tar.gz

# Move the helm binary to /usr/local/bin
mv linux-amd64/helm /usr/local/bin/helm

# Verify Helm CLI
helm version

# Clean-up
rm -rf linux-amd64
rm -f helm-v3.17.2-linux-amd64.tar.gz

Faça o download, extraia e mova o binário

Configurando o Helm com seu cluster

Da mesma forma que o kubectl está configurado para se comunicar com um cluster específico, o Helm também usa o arquivo ~/.kube/config para saber em qual cluster você deve executar os comandos.

# To find out which context (and therefore cluster) is currently being used
kubectl config current-context

# To view the entire ~/.kube/config file
kubectl config view

# If you’re running an EKS cluster on AWS, execute this command to update your .kubeconfig file and set it to the current context.
aws eks update-kubeconfig --name <Name of EKS cluster> --region <region>

# View helm charts installed in all namespaces on the cluster
helm list -A

Saída dos comandos de configuração do kubectl

Adicionar e atualizar repositórios do Helm

Os gráficos públicos do Helm são armazenados nos repositórios do Helm. Antes de usar um gráfico público do Helm, precisamos adicionar alguns metadados desse repositório ao nosso local.

# Adds a Helm repository locally
helm repo add bitnami https://charts.bitnami.com/bitnami

Onde o comando helm repo add salva as informações para você? Run helm env.

Saída do helm repo add e helm env

O caminho mostrado por HELM_REPOSITORY_CONFIG é onde as informações do repositório são salvas.

Para listar todos os repositórios adicionados localmente, execute o comando helm repo list. Ele obtém as informações do valor de HELM_REPOSITORY_CONFIG.

Para mim, será o arquivo ~/Library/Preferences/helm/repositories.yaml.

Para listar todos os gráficos no repositório, execute helm search repo bitnami.

Saída da lista de repositórios do helm e do repositório de pesquisa do helm

Como repositórios públicos, eles recebem atualizações regularmente dos respectivos colaboradores. Para atualizar os gráficos no repositório, basta atualizar o repositório inteiro.

# Update a repository
helm repo update bitnami

Saída da atualização do repositório helm

Explorando a estrutura de um gráfico de leme

Para que você entenda realmente como funcionam os gráficos do Helm, é importante se familiarizar com sua estrutura. 

Um gráfico Helm é mais do que apenas um pacote de arquivos YAML - é um diretório bem organizado que define um aplicativo Kubernetes combinando modelos, configuração e metadados. 

Nesta seção, analisarei os principais componentes, incluindo o layout geral do diretório de gráficos, a função do arquivo values.yaml para configuração e como o Helm usa modelos em Go para gerar dinamicamente manifestos do Kubernetes.

Estrutura do diretório do gráfico

O diretório padrão do gráfico é o seguinte, em que demo-helm é o nome do gráfico que defini. Nós o criaremos na próxima seção. 

Vamos abordar brevemente a finalidade de cada arquivo ou pasta dentro dele.

#    demo-helm/
#    ├── .helmignore   # Contains patterns to ignore when packaging Helm charts.
#    ├── Chart.yaml    # Information about your chart
#    ├── values.yaml   # The default values for your templates
#    ├── charts/       # Charts that this chart depends on
#    └── templates/    # The template files
#        └── tests/    # The test files

• O arquivo .helmignore funciona de forma semelhante ao .gitignore ou .dockerignore. Se quisermos excluir determinados arquivos ou diretórios do nosso gráfico do Helm, poderemos listar seus padrões no arquivo .helmignore. Todos os arquivos ou diretórios que corresponderem a esses padrões serão ignorados durante a execução dos comandos do Helm.
• Chart.yaml contém metadados sobre o gráfico do Helm, como o nome do gráfico, a descrição, a versão do gráfico e a versão do aplicativo.
• values.yaml contém os valores de configuração padrão que transformam os modelos Go do Helm chart em manifestos do Kubernetes. Alguns valores comuns definidos nesse arquivo incluem:
  • O repositório de imagens e a tag.
  • Sinalizadores booleanos para ativar ou desativar recursos específicos.
  • Números de porta.
  • Outras configurações específicas do aplicativo.
• O diretório da pasta charts/ armazena as dependências do gráfico. Se o gráfico do Helm depender de outros gráficos (conhecidos como subgráficos), eles serão colocados aqui.
• A última é a pasta templates/, que contém os arquivos de modelo Go usados para gerar manifestos do Kubernetes. Esses modelos definem os recursos que serão implantados, como Deployment, ServiceAccount, Service, Ingress e ConfigMap.

Entendendo o values.yaml

O values.yaml é o arquivo de configuração padrão, fornecendo um local central para definir valores de entrada que os modelos referenciam ao renderizar manifestos do Kubernetes.

Ao instalar um gráfico do Helm, o Helm lê o arquivo values.yaml e injeta seu conteúdo nos modelos do gráfico por meio do mecanismo de modelos. Isso nos permite parametrizar a configuração do aplicativo, como versões de imagens de contêineres, limites de recursos, contagens de réplicas, configurações de entrada e muito mais, sem alterar diretamente os modelos.

Um trecho do site padrão values.yaml de um gráfico do Helm recém-criado é o seguinte:

# Default values for demo-helm.
# This is a YAML-formatted file.
# Declare variables to be passed into your templates.

# This will set the replicaset count more information can be found here: https://kubernetes.io/docs/concepts/workloads/controllers/replicaset/
replicaCount: 1

# This sets the container image more information can be found here: https://kubernetes.io/docs/concepts/containers/images/
image:
  repository: nginx
  # This sets the pull policy for images.
  pullPolicy: IfNotPresent
  # Overrides the image tag whose default is the chart appVersion.
  tag: ""

# This is for the secrets for pulling an image from a private repository more information can be found here: https://kubernetes.io/docs/tasks/configure-pod-container/pull-image-private-registry/
imagePullSecrets: []
# This is to override the chart name.
nameOverride: ""
fullnameOverride: ""

# This section builds out the service account more information can be found here: https://kubernetes.io/docs/concepts/security/service-accounts/
serviceAccount:
  # Specifies whether a service account should be created
  create: true
  # Automatically mount a ServiceAccount's API credentials?
  automount: true

Esses valores são referenciados nos arquivos de modelo usando a notação ., como {{ .Values.replicaCount }} ou {{ .Values.image.repository }}. O Helm permite que você substitua esses valores padrão na instalação ou atualização, o que é feito usando um arquivo de valores personalizados ou passando valores individuais em linha.

# Install a helm chart with the default values from values.yaml
helm install demo-helm ./demo-helm

# Values defined in custom-values.yaml will override those in values.yaml.
# Nonetheless, values in values.yaml not found in custom-values.yaml will still be applied.
# “-f” flag is short for the “--values” flag
helm install demo-helm ./demo-helm -f custom-values.yaml

# Overwrite default values using the  “--set” flag
helm install demo-helm ./demo-helm --set replicaCount=3 --set image.tag=latest

Criação de modelos com modelos Go

Um dos recursos mais avançados do Helm é seu mecanismo de modelos, que permite a configuração dinâmica e reutilizável dos manifestos do Kubernetes. Os modelos Go estão no centro desse recurso, e a mesma linguagem de modelos é usada em muitas outras ferramentas e estruturas baseadas em Go, como Terraform e Docker.

Em vez de codificar valores diretamente em nossos arquivos YAML, o Helm nos permite definir modelos que fazem referência a entradas dinâmicas, mais comumente de values.yaml. Por exemplo, no snippet do modelo deployment abaixo:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: {{ .Values.name }}
spec:
  replicas: {{ .Values.replicas }}

{{ .Values.name }} e {{ .Values.replicas }} são expressões de modelo em Go. Onde .Values se refere ao conteúdo do arquivo values.yaml, ao arquivo definido no sinalizador --values ou aos valores passados em linha. Esses espaços reservados são substituídos por valores reais quando o gráfico é renderizado.

Por exemplo, o modelo deployment abaixo usa valores como replicaCount e image.repository.

Mapeamento entre values.yaml e deployment.yaml

Enquanto isso, o modelo serviceAccount usa serviceAccount.create. O recurso serviceAccount inteiro será omitido se o valor for falso.

Mapeamento entre values.yaml e serviceaccount.yaml

Para ilustrar melhor, digamos que você tenha a seguinte configuração em seu site values.yaml.

replicaCount: 2
image:
  repository: nginx
  tag: "1.21.1"

Seu modelo deployment.yaml (em templates/deployment.yaml ) pode ter a seguinte aparência:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: {{ .Release.Name }}
spec:
  replicas: {{ .Values.replicaCount }}
  selector:
    matchLabels:
      app: {{ .Release.Name }}
  template:
    metadata:
      labels:
        app: {{ .Release.Name }}
    spec:
      containers:
        - name: nginx
          image: "{{ .Values.image.repository }}:{{ .Values.image.tag }}"
          ports:
            - containerPort: 80

Quando o Helm renderiza o manifesto do Kubernetes, seja durante helm template, helm install, seja durante helm upgrade, ele o faz injetando os valores de values.yaml.

# helm template <release name> <chart name OR path to chart folder>
helm template my-nginx <chart name OR path to chart folder>

Com isso, você obterá o manifesto abaixo:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-nginx
spec:
  replicas: 2
  selector:
    matchLabels:
      app: my-nginx
  template:
    metadata:
      labels:
        app: my-nginx
    spec:
      containers:
        - name: nginx
          image: "nginx:1.21.1"
          ports:
            - containerPort: 80

Criando seu primeiro mapa do leme

A maneira mais fácil de aprender o Helm é criar um gráfico para você. Você verá como criar um gráfico básico, entender sua estrutura e personalizá-lo para implantar nosso aplicativo no Kubernetes.

Usando o helm create

Em vez de usar gráficos Helm públicos dos repositórios Helm, que mencionamos acima na subseção "Adicionar e atualizar repositórios Helm", vamos criar um gráfico próprio.

# Creates a helm chart with the name “demo-helm”
helm create demo-helm

A estrutura do diretório será a seguinte:

#    demo-helm/
#    ├── .helmignore   # Contains patterns to ignore when packaging Helm charts.
#    ├── Chart.yaml    # Information about your chart
#    ├── values.yaml   # The default values for your templates
#    ├── charts/       # Charts that this chart depends on
#    └── templates/    # The template files
#        └── tests/    # The test files

Saída do comando helm create

Personalização de modelos

Vamos explorar o conteúdo da pasta templates para que você possa entendê-lo melhor antes de modificá-lo.

Conteúdo da pasta de modelos

O arquivo _helpers.tpl armazena auxiliares de modelo Go reutilizáveis (semelhantes a funções) que podem ser chamados de outros modelos dentro do gráfico, promovendo a reutilização e a manutenção do código .

A imagem abaixo mostra como as seções do arquivo _helpers.tpl são mapeadas para o arquivo service.yaml.

Mapeamento entre _helpers.tpl e service.yaml

Podemos executar o comando helm template para obter o service.yaml renderizado. O comando valida se o gráfico não contém nenhum erro e renderiza os arquivos de manifesto.

# helm template <release name> <chart name OR path to chart folder>
helm template demo-helm ./demo-helm

Saída do comando helm template

Podemos adicionar ou modificar o conteúdo do arquivo _helpers.tpl ou de qualquer um dos recursos de modelo para atender às nossas necessidades. Por exemplo, para adicionar um rótulo de seletor ao recurso service por meio do arquivo _helpers.tpl:

{{- define "demo-helm.selectorLabels" -}}
app.kubernetes.io/name: {{ include "demo-helm.name" . }}
app.kubernetes.io/instance: {{ .Release.Name }}
app.kubernetes.io/custom: "testing" # Add this line
{{- end }}

Adicionar um rótulo de seletor em _helpers.tpl

As aspas usadas em torno do valor testing devem ser aspas retas ("testing") e não aspas curvas ("testing"). Embora o site helm template não apresente um erro, o site helm install apresentará .

• Salve o arquivo _helpers.tpl e execute novamente o comando helm template. Você deverá ver o seletor sendo adicionado ao recurso de serviço.

Saída atualizada do comando helm template

Observe que, além de ser adicionado ao seletor, ele também foi adicionado aos rótulos de todos os recursos. Isso ocorre porque o {{- define "demo-helm.labels" -}} contém o {{ include "demo-helm.selectorLabels" . }}. Assim, tudo no site selectorLabels será incluído nos rótulos .

Outro exemplo é que podemos modificar o deployment.yaml para expor outra porta no contêiner. Por padrão, quando criamos um gráfico com o comando helm create, o modelo de implantação expõe apenas uma porta no contêiner.

• Adicione a seguinte configuração ao site deployment.yaml.

- name: https
  containerPort: 443
  protocol: TCP

Você adicionou uma porta ao contêiner em deployment.yaml

Para simplificar, o valor containerPort é codificado como 443. Na próxima subseção, exp loraremos como usar o site values.yaml para parametrizá- lo. Você pode usar o site para parametrizá-lo .

• Salve o arquivo deployment.yaml e execute o comando helm template novamente. Agora, a porta deve ser adicionada ao contêiner no recurso de implementação.

Apenas para ressaltar que, como o recuo é crucial na formatação YAML, o modelo para os recursos do Kubernetes inclui a função nindent para recuar os blocos necessários de acordo.

apiVersion: v1
kind: Service
metadata:
  name: {{ include "demo-helm.fullname" . }}
  labels:
    {{- include "demo-helm.labels" . | nindent 4 }} 
spec:
  type: {{ .Values.service.type }}
  ports:
    - port: {{ .Values.service.port }}
      targetPort: http
      protocol: TCP
      name: http
  selector:
    {{- include "demo-helm.selectorLabels" . | nindent 4 }}

Definição de valores padrão

Agora que já cobrimos a maior parte do conteúdo da pasta de modelos, estamos prontos para passar para values.yaml.

Diretório de cartas do leme

Na subseção anterior, codificamos o endereço containerPort como 443. Vamos parametrizá-lo. 

• Em values.yaml, sob a chave service, adicione a chave aninhada https_port com o valor 443.

Adicionar chave aninhada

• Modifique o deployment.yaml para substituir o 443 codificado por {{ .Values.service.port }}.

Parametrizar o número da porta

• Para validar e renderizar os recursos do Kubernetes:

# helm template <release name> <chart name OR path to chart folder>
helm template demo-helm ./demo-helm

Você deve ver que o valor 443 está definido corretamente no site containerPort.

Valor de https_port renderizado

Se houver outros locais no gráfico do Helm que exijam o valor desse containerPort, basta usar {{ .Values.service.https_port }}.

Implementação e gerenciamento de versões

Agora que criamos nosso próprio gráfico do Helm, a próxima etapa seria implantá-lo em um cluster do Kubernetes. 

O Helm gerencia o ciclo de vida dos recursos implantados do Kubernetes como uma versão. Nesta seção, exploraremos como o Helm lida com implantações, upgrades, reversões e o rastreamento do histórico de versões, o que nos dá controle e visibilidade poderosos sobre nossas cargas de trabalho do Kubernetes.

O que é uma liberação?

No Helm, uma versão é uma instância específica de um gráfico do Helm que foi implantado em um cluster do Kubernetes.

Sempre que instalamos um gráfico usando helm install, o Helm cria uma nova versão com seu próprio nome, configuração e versão. Da mesma forma, quando atualizamos uma versão usando helm upgrade, o Helm cria uma nova revisão dessa versão com o mesmo nome, mas a configuração e a versão podem ser diferentes. Essencialmente, uma versão é uma nova versão da mesma versão com configurações ou conteúdo de gráfico atualizados.

Portanto, quando dizemos "instalar um gráfico do Helm", na verdade estamos nos referindo a "criar uma versão do Helm".

Ilustração visual dos lançamentos - imagem do autor.

Embora apenas a revisão mais recente de uma versão seja ativamente implantada no cluster, o Helm mantém o histórico completo das revisões anteriores. Isso significa que podemos reverter facilmente para um estado anterior usando helm rollback.

Quando realizamos uma reversão, o Helm não restaura a revisão da versão antiga como está; em vez disso, ele cria uma nova revisão que replica a configuração da versão anterior selecionada. Cada revisão é numerada e as reversões aumentam o número da revisão, mantendo o histórico de versões consistente e auditável.

Instalação de um gráfico com o helm install

Vamos analisar a implantação de uma versão do Helm em um cluster do Kubernetes. Vamos instalar dois gráficos do Helm: o que criamos na seção anterior e o gráfico bitnami/apache do repositório público da Bitnami que já adicionamos à nossa configuração local do Helm.

bitnami/apache Helm chart

Ao instalar um gráfico, devemos especificar um nome de versão - pode ser qualquer coisa que você escolher e não precisa corresponder ao nome do gráfico. No entanto, é recomendável usar um nome que esteja intimamente relacionado ao gráfico para que os usuários entendam mais facilmente o que a versão representa em um relance.

• Primeiro, para o gráfico do Helm que criamos:

# Install the helm chart (in other words, create a helm release) into the default namespace
# helm install <release name> <chart name OR path to chart folder>
helm install datacamp-demo-helm ./demo-helm
# OR
helm upgrade --install datacamp-demo-helm ./demo-helm

# If installing to a specific namespace, add the -n flag
# Install the chart to the “app” namespace
helm install my-amazing-helm-demo ./demo-helm -n app

Implantar um gráfico personalizado do Helm

# To validate the Kubernetes resources
# Get pods, service, and serviceaccount resources in the default namespace
kubectl get pods,svc,sa

Validar recursos implementados a partir do gráfico personalizado do Helm

• Segundo, para o gráfico bitnami/apache:

# Install the helm chart into the default namespace
helm install apache bitnami/apache
# OR
helm upgrade --install apache bitnami/apache

Saída da instalação do helm

Saída do helm upgrade --install

Para visualizar as versões do Helm que foram implementadas, você pode usar o Helm para fazer o download:

# List all helm releases in all namespaces
helm list -A

Listar todos os lançamentos do Helm

Atualização com upgrade do leme

Após a implementação inicial de um gráfico do Helm, as atualizações são inevitáveis, seja alterando a tag da imagem, ajustando o número de réplicas, ativando ou desativando recursos opcionais ou modificando os valores de configuração.

O Helm fornece o comando helm upgrade para que você aplique essas alterações a uma versão existente sem reimplantar do zero. Esse comando nos permite atualizar nosso aplicativo em execução, renderizando novamente os modelos com a nova configuração e aplicando as alterações ao cluster do Kubernetes, gerenciando perfeitamente as atualizações com o mínimo de interrupção.

O aplicativo implantado por meio do nosso gráfico de leme personalizado executa uma imagem nginx com a tag 1.16.0. Você pode determinar a tag executando o comando helm get manifest.

# Output the rendered Kubernetes manifest that was installed by the helm chart
# helm get manifest <release name>
helm get manifest datacamp-demo-helm

No manifesto do recurso deployment, você deve ver o seguinte:

Valor da imagem

De onde veio a tag 1.16.0? Nosso image.tag em values.yaml valor está vazio .

Examine o modelo deployment.yaml: a chave image tem o valor "{{ .Values.image.repository }}:{{ .Values.image.tag | default .Chart.AppVersion }}". Quando o image.tag não estiver definido em values.yaml, o Helm obterá o valor do appVersion definido no Charts.yaml.

appVersion em Chart.yaml

• Vamos atualizar o values.yaml do nosso gráfico personalizado, atualizar o image.tag para "1.26".

Atualizar image.tag de "" para "1.26"

• Depois disso, execute o comando helm upgrade.

# helm upgrade <release name> <chart name or path to chart>
helm upgrade datacamp-demo-helm ./demo-helm

# Alternatively, you can update the value via the --set flag
helm upgrade datacamp-demo-helm ./demo-helm --set 

A saída do comando helm upgrade

Examine o recurso de implantação; a tag de imagem deve ser 1.26. Nos bastidores, durante uma atualização, o Helm faz o seguinte:

1. Renderização de modelos: O Helm renderiza novamente os modelos do gráfico usando os valores (atualizados) passados com o comando.
2. Determine as alterações: O Helm compara os manifestos recém-criados com os atuais no cluster. Na última seção do artigo, exploraremos a verificação das alterações antes de aplicá-las.
3. Atualização seletiva: Somente os recursos que foram alterados (como deployment, configmaps ou secrets ) são atualizados.
4. Rastreamento do histórico de versões: O Helm registra a nova versão e a configuração, o que nos permite reverter a situação, se necessário.

# To view the release history. It also shows the revision numbers.
# helm history <release name>
helm history datacamp-demo-helm

Saída do comando helm history

Reversão com o helm rollback

Acabamos de fazer o upgrade de uma versão do Helm, mas logo depois percebemos que o aplicativo não está se comportando como esperado. Embora a solução de problemas seja importante, em um ambiente de produção, a prioridade imediata geralmente é estabilizar o sistema. É aí que entra o recurso de reversão do Helm. 

O Helm facilita a reversão para uma versão anterior e conhecida como boa com um único comando, o que nos permite recuperar rapidamente de implementações com falha e minimizar o tempo de inatividade. 

• Reverteremos a atualização realizada acima.

# The first argument of the rollback command is the name of a release, and the second is a revision (version) number. If this argument is omitted or set to 0, it will roll back to the previous release.
# helm rollback <release name> <revision number>
helm rollback datacamp-demo-helm 0

A saída do comando helm rollback

Examine a implantação datacamp-demo-helm e você verá a tag da imagem nginx de volta para 1.16.0.

kubectl get deploy datacamp-demo-helm -oyaml

Desinstalação de uma versão

Para desinstalar a versão do Helm, em outras palavras, para excluir todos os recursos do Kubernetes implantados a partir da versão, execute o comando helm uninstall.

# helm uninstall <release name>
helm uninstall datacamp-demo-helm
helm uninstall apache

Saída do comando helm uninstall

Para ver como o Helm oferece suporte a pipelines de CI/CD dimensionáveis, especialmente para fluxos de trabalho de ML, explore o curso CI/CD para machine learning.

Personalizando gráficos do timão para diferentes ambientes

Um dos maiores pontos fortes do Helm é sua flexibilidade. Independentemente de estarmos implementando no desenvolvimento, na preparação ou na produção, o Helm facilita a personalização do comportamento do nosso gráfico por meio da configuração. 

Nesta seção, exploraremos como adaptar um gráfico do Helm para diferentes ambientes usando ferramentas como values.yaml, substituições específicas do ambiente e os sinalizadores --set e -f do Helm.

Uso de vários arquivos values.yaml

O Helm oferece uma maneira flexível de gerenciar configurações específicas do ambiente usando vários arquivos values.yaml .

Em vez de manter um único e complexo values.yaml que tenta levar em conta todas as configurações possíveis em desenvolvimento, preparação e produção, ou declarações condicionais complexas em nossos modelos para levar em conta os diferentes ambientes, podemos dividi-los em arquivos separados, cada um adaptado a um ambiente específico.

Por exemplo, nosso diretório de gráficos pode incluir:

my-chart/
├── values.yaml                    # default values
├── values-dev.yaml           # development-specific overrides
├── values-staging.yaml    # staging-specific overrides
└── values-prod.yaml          # production-specific overrides

Substituição de valores no momento da instalação

O Helm permite que você substitua os valores padrão definidos em values.yaml usando o sinalizador --set para substituições em linha ou o sinalizador -f para fornecer um arquivo de valores externos. A bandeira -f é a abreviação da bandeira --values.

Para instalar ou atualizar nossa versão do Helm com o comando -f você pode usar o sinalizador -f:

# For installing on dev
helm install <release name> <chart name or path to chart> -f values-dev.yaml

# For upgrading on dev
helm upgrade <release name> <chart name or path to chart> -f values-dev.yaml

# For installing on staging
helm install <release name> <chart name or path to chart> -f values-staging.yaml

# For upgrading on staging
helm upgrade <release name> <chart name or path to chart> -f values-staging.yaml

Para instalar ou atualizar nossa versão do Helm com o sinalizador --set:

# For installation
helm install <release name> <chart name or path to chart> --set image.tag=1.26

# For upgrading
helm upgrade <release name> <chart name or path to chart> --set image.tag=1.26

Se tanto --set quanto -f forem usados durante a instalação (ou atualização), o Helm aplicará os valores na seguinte ordem:

1. A base values.yaml (se houver)
2. Valores do arquivo especificado com -f
3. Valores inline passados com --set

Isso significa que, se a mesma chave aparecer no arquivo -f e no sinalizador --set, o valor de --set terá precedência .

Por exemplo, se definirmos image.tag como 1.22 em values-dev.yaml, mas definirmos image.tag como 1.26 por meio do sinalizador --set, o valor image.tag que será usado para renderizar o manifesto do Kubernetes será 1.26.

# E.g. we defined image.tag to be 1.22 in values-dev.yaml
helm install <release name> <chart name OR path to chart> --set image.tag=1.26 -f values-dev.yaml

Gerenciando segredos

Ao implantar aplicativos no Kubernetes usando o Helm, o manuseio de dados confidenciais, como chaves de API, credenciais de banco de dados ou certificados TLS, requer cuidados especiais. Embora o Helm seja compatível com o recurso Secret do Kubernetes, os valores no recurso secreto são simplesmente codificados em base64, que podem ser decodificados por qualquer pessoa .

apiVersion: v1
kind: Secret
metadata:
  name: my-secret
  namespace: default
type: Opaque
data:
  key1: c3VwZXJzZWNyZXQ=  # ← This is base64 encoded
  key2: dG9wc2VjcmV0          # ← This is base64 encoded

# Decode the value of key1
echo "c3VwZXJzZWNyZXQ=" | base64 -d

# Decode the value of key2
echo "dG9wc2VjcmV0" | base64 -d

Armazenar segredos diretamente em um arquivo values.yaml ou em texto simples em nosso gráfico não é seguro e deve ser evitado, especialmente ao enviar arquivos para o controle de versão .

Para gerenciar segredos com segurança nos gráficos do Helm em diferentes ambientes, considere o uso de ferramentas projetadas especificamente para essa finalidade. Duas soluções amplamente adotadas são os Sealed Secrets e os External Secrets.

Segredos selados

O Sealed Secrets é um projeto de código aberto desenvolvido pela Bitnami que ajuda a gerenciar dados confidenciais no Kubernetes de forma segura e amigável ao GitOps. Ele apresenta uma definição de recurso personalizado (CRD) chamada SealedSecret, que nos permite criptografar segredos antes de enviá-los para um repositório Git.

Diferentemente dos recursos regulares do Kubernetes secrets, que armazenam dados na codificação base64 e não são criptografados, os recursos SealedSecret contêm valores criptografados que só podem ser descriptografados pelo controlador Sealed Secrets em execução no cluster Kubernetes de destino. Isso significa que os segredos criptografados podem ser armazenados com segurança em sistemas de controle de versão como o Git.

Para configurar nosso cluster e o ambiente local para usar o Sealed Secrets, você deve

• Instale o CRD do SealedSecret e o controlador do lado do servidor (que é executado como um pod) no namespace kube-system

kubectl apply -f https://github.com/bitnami-labs/sealed-secrets/releases/download/v0.29.0/controller.yaml
#OR
helm install sealed-secret bitnami/sealed-secrets -n kube-system

Instalar o SealedSecret em nosso cluster via kubectl

Instale o SealedSecret em nosso cluster via Helm

• Verifique os recursos:

Verifique os recursos da instalação do Sealed Secrets

• Instale a CLI do kubeseal em nosso sistema local.

# Linux x86_64:
curl -OL "https://github.com/bitnami-labs/sealed-secrets/releases/download/v0.29.0/kubeseal-0.29.0-linux-amd64.tar.gz"
tar -xvzf kubeseal-0.29.0-linux-amd64.tar.gz kubeseal
sudo install -m 755 kubeseal /usr/local/bin/kubeseal

# macOS
brew install kubeseal

Para criar o recurso CRD SealedSecret:

# Pass the secret manifest to kubeseal for it to generate the SealedSecret CRD resource containing the encrypted secrets. Saves the SealedSecret CRD manifest in sealed-mysecret.yaml.
kubectl create secret generic mysecret --dry-run=client --from-literal key1=supersecret --from-literal key2=topsecret --output json | kubeseal | tee sealed-mysecret.yaml

# Or if you have the secret manifest saved in a JSON file
kubeseal -f mysecret.yaml -w sealed-mysecret.yaml

Gerar e salvar o recurso CRD SealedSecret

Aplique o arquivo sealed-mysecret.yaml. Quando um recurso do SealedSecret é criado no cluster, o controlador descriptografa automaticamente os dados selados e cria um recurso padrão do Kubernetes secrets a partir dele.

Criar o recurso CRD SealedSecret

Essa abordagem garante que as informações confidenciais permaneçam seguras em todo o pipeline de CI/CD.

Operador de segredos externos (ESO)

O External Secrets Operator (ESO) é um operador do Kubernetes que nos permite buscar e injetar com segurança segredos de sistemas externos de gerenciamento de segredos, como o AWS Secrets Manager, o HashiCorp Vault, o Google Secret Manager, o Azure Key Vault e outros, no Kubernetes Secrets. 

Em vez de criar ou atualizar manualmente os segredos do Kubernetes, o ESO recupera os valores secretos mais recentes desses provedores externos por meio de suas APIs e garante que nosso cluster do Kubernetes sempre tenha credenciais ou dados confidenciais atualizados.

O ESO apresenta um conjunto de recursos personalizados -ExternalSecret e ClusterSecretStore- que abstraem as complexidades da interação com back-ends secretos externos. Esses recursos definem quais segredos você deve buscar e de onde, facilitando o gerenciamento de ciclos de vida de segredos de forma declarativa e nativa do Kubernetes.

Para este exemplo, buscaremos um segredo no AWS Secrets Manager. 

• Primeiro, crie uma função IAM que será usada pelo pod external-secrets para buscar o segredo no AWS Secrets Manager.

Função de IAM para o pod external-secrets

A política de permissão de função do IAM é a seguinte:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "ESO",
            "Effect": "Allow",
            "Action": [
                "secretsmanager:GetSecretValue"
            ],
            "Resource": "*"
        }
    ]
}

• Em segundo lugar, crie um segredo no AWS Secrets Manager.

Segredo do AWS Secrets Manager

Para configurar nosso cluster para usar o ESO:

helm repo add external-secrets https://charts.external-secrets.io


# Replace the ARN of the IAM role
helm install external-secrets external-secrets/external-secrets \
    -n external-secrets \
    --create-namespace \
    --version 0.15.1 \
    --set serviceAccount.annotations."eks\.amazonaws\.com/role-arn"="<ARN of IAM Role>"

Resultado da instalação de external-secrets

• Verifique a instalação:

kubectl get pods,crd -n external-secrets

Verificar os recursos da instalação do ESO

• Em seguida, para implantar o recurso ClusterSecretStore, salve o seguinte em cluster-secret-store.yaml e crie o recurso.

apiVersion: external-secrets.io/v1beta1
kind: ClusterSecretStore
metadata:
  name: "cluster-secret-store"
spec:
  provider:
    aws:
      service: SecretsManager
      region: ap-southeast-1
      auth:
        jwt:
          serviceAccountRef:
            name: "external-secrets"
            namespace: "external-secrets"

kubectl create -f cluster-secret-store.yaml
kubectl get ClusterSecretStore

O recurso personalizado ClusterSecretStore é um SecretStore em todo o cluster que pode ser referenciado por ExternalSecrets a partir de qualquer namespace. Ele faz referência ao endereço external-secrets serviceAccount para que você possa se autenticar no AWS Secrets Manager.

Validar a criação do recurso ClusterSecretStore

• Por último, para extrair o segredo demo-datacamp-ESO do AWS Secrets Manager, implemente o recurso personalizado ExternalSecret. Você obterá o valor da chave password. Salve o seguinte em external-secret.yaml e crie o recurso.

apiVersion: external-secrets.io/v1beta1
kind: ExternalSecret
metadata:
  name: demo-datacamp-secret
  namespace: default  # Change to your target namespace
spec:
  refreshInterval: 1h # How often to refresh the secret
  secretStoreRef:
    name: cluster-secret-store # This references your ClusterSecretStore
    kind: ClusterSecretStore
  target:
    name: demo-datacamp-k8s-secret # The name of the resulting Kubernetes Secret
    creationPolicy: Owner # ESO manages lifecycle of the K8s secret
  data:
    - secretKey: password # Key name in the Kubernetes Secret
      remoteRef:
        key: demo-datacamp-ESO # AWS Secrets Manager secret name
        property: password # Key in the AWS secret JSON object

kubectl create -f external-secret.yaml
kubectl get externalsecrets
kubectl get secrets

Verificar se a obtenção do segredo foi bem-sucedida

Na imagem acima, podemos ver que o valor top_secret_password da chave password foi obtido com êxito do AWS Secrets Manager, e um segredo do Kubernetes foi criado contendo o valor.

Práticas recomendadas para o desenvolvimento do Helm Chart

À medida que nosso uso do Helm cresce além da instalação básica de gráficos, é importante seguir as práticas recomendadas que promovem a manutenção, a reutilização e a confiabilidade. 

Esta seção aborda as principais práticas de desenvolvimento, como o uso de plug-ins do Helm para ampliar a funcionalidade, a estruturação de gráficos para reutilização, a validação de nossos gráficos com ferramentas de linting e o gerenciamento eficaz de versões e dependências.

Plug-ins do Helm

Os plug-ins do Helm são uma maneira poderosa de estender a funcionalidade principal do Helm e adaptá-la ao seu fluxo de trabalho. Eles nos permitem adicionar comandos personalizados e integrar com ferramentas externas sem modificar o próprio Helm.

Os plug-ins podem ser instalados a partir de repositórios Git, tarballs ou diretórios locais e, uma vez instalados, eles se comportam como comandos nativos do Helm. Os plug-ins do Helm são instalados localmente em nosso computador, não no cluster do Kubernetes. Isso significa que eles aprimoram nossos recursos locais do Helm CLI e não exigem alterações ou implementações no cluster do Kubernetes. Cada usuário ou sistema que executa o Helm deve instalar os plug-ins desejados de forma independente.

Um plug-in comum que é amplamente usado, especialmente em pipelines de CI/CD, é o helm-diff. Ele compara uma versão do Helm com um gráfico do Helm e mostra quais alterações seriam aplicadas. Isso é especialmente útil para visualizar as atualizações.

# Install the plugin
helm plugin install https://github.com/databus23/helm-diff

# List installed plugins
helm plugin list

# View the changes for an upgrade
helm diff upgrade datacamp-demo-helm ./demo-helm --set image.tag="1.26"

Saída dos comandos do plug-in do helm

Saída do comando helm diff

Estruturação de gráficos reutilizáveis

À medida que o uso do Helm cresce, a estruturação de nossos gráficos para reutilização torna-se crucial. Um gráfico Helm bem estruturado promove a consistência, simplifica a manutenção e permite padrões de implementação modular entre projetos. Aqui estão duas dicas:

Use modelos e auxiliares

Conforme demonstrado na subseção "Personalizando modelos" na seção "Criando seu primeiro Helm Chart", aproveitamos o arquivo _helpers.tpl para adicionar um seletor adicional ao recurso deployment e rótulos a todos os recursos. O uso de modelos auxiliares evita a duplicação, fornecendo assim uma única fonte de verdade para trechos comumente reutilizados. Isso melhora a consistência em todo o seu gráfico e facilita a manutenção - qualquer alteração futura só precisa ser feita em um único lugar.

Dividir gráficos grandes em subgráficos

Se o nosso aplicativo consistir em vários componentes fracamente acoplados (por exemplo, um aplicativo Web, um banco de dados e o Redis), considere dividir o gráfico em subgráficos. Coloque-os dentro da pasta charts/ e gerencie-os como dependências via Chart.yaml.

dependencies:
  - name: redis
    version: 17.1.2
    repository: https://charts.bitnami.com/bitnami

Execute o site helm dependency update para obter esses subgráficos. Isso torna cada componente gerenciável de forma independente e promove a reutilização em diferentes projetos.

Linting e validação de gráficos

Antes de implantar um gráfico do Helm em um cluster do Kubernetes, é importante garantir que o gráfico esteja bem estruturado, sintaticamente correto e logicamente sólido. O Helm fornece ferramentas integradas para nos ajudar a detectar problemas antecipadamente por meio de linting e testes.

O comando helm lint analisa nosso gráfico em busca de erros comuns e violações de práticas recomendadas. Ele verifica a sintaxe dos modelos, a estrutura dos arquivos de gráficos e a presença dos campos obrigatórios em Chart.yaml.

helm lint ./demo-helm

Saída do comando helm lint

Se você modificasse o valor de name em Chart.yaml de "demo-helm" para "demo_helm", haveria um problema em que helm lint seria capturado.

Modificou o "-" para "_"

O helm lint emite mensagens de aviso

Com a criação de linting e o teste de nossos gráficos antes da implementação, reduzimos o risco de falhas nas versões e configurações incorretas na produção. Essas práticas são essenciais para manter gráficos do Helm de alta qualidade que se comportam de forma previsível em todos os ambientes.

Gerenciamento de versões e dependências

À medida que os gráficos do Helm evoluem e dependem de outros gráficos, torna-se fundamental gerenciar as versões de forma consistente e rastrear as dependências com precisão. O Helm fornece mecanismos internos para dar suporte a isso por meio do controle de versão semântico, do arquivo Chart.lock e das dependências do Chart.yaml.

O Helm usa o Semantic Versioning para versões de gráficos. A versão de um gráfico é definida em Chart.yaml na chave version:

Versão do gráfico

O controle de versão semântico segue o formato: MAJOR.MINOR.PATCH

• PRINCIPAIS - mudanças revolucionárias
• MENOR - adições de recursos compatíveis com versões anteriores
• PATCH - correções de erros compatíveis com versões anteriores

A versão do gráfico deve ser incrementada sempre que houver alterações no próprio gráfico, incluindo seus modelos, valores ou até mesmo a versão do aplicativo. Ao mesmo tempo, a versão do aplicativo reflete a versão do aplicativo real que o gráfico está implantando, normalmente alinhada com a tag de imagem usada no gráfico. Ele deve ser atualizado sempre que a imagem do aplicativo for alterada.

O controle de versão adequado ajuda as equipes a saber se uma atualização é segura ou se requer cuidados adicionais. Ele também permite que o Helm gerencie caminhos de atualização e dependências de forma mais confiável.

No Helm 3, que é o que estamos usando neste artigo, as dependências são definidas diretamente no arquivo Chart.yaml na seção dependencies. Ele não é incluído por padrão quando criamos o gráfico. Isso substitui o arquivo requirements.yaml do Helm 2.

Dependências definidas em Chart.yaml

O arquivo Chart.lock é gerado automaticamente quando você executa helm dependency update. Ele funciona como um lockfile em muitos gerenciadores de pacotes, registrando as versões exatas de cada dependência, conforme definido na seção dependencies de Chart.yaml. Isso garante compilações reproduzíveis e comportamento consistente entre ambientes e equipes.

Conteúdo em Chart.lock

Se você estiver familiarizado com o Terraform, o conceito é semelhante ao do arquivo .terraform.lock.hcl, que bloqueia as versões do provedor. Embora os formatos e os ecossistemas subjacentes sejam diferentes, ambos bloqueiam as versões de dependência para garantir a estabilidade e a repetibilidade.

Conclusão

Os gráficos do Helm fornecem uma maneira avançada e padronizada de empacotar, configurar e implantar aplicativos no Kubernetes. Ao longo deste artigo, exploramos o que é um gráfico do Helm, como ele é estruturado e como ele simplifica o processo de implementação em diferentes ambientes.

Percorremos as principais etapas do processo:

• Criando seu primeiro gráfico do Helm usando helm create.
• Personalização das configurações por meio do site values.yaml e de substituições específicas do ambiente.
• Implementando e gerenciando versões usando comandos como helm install, helm upgrade e helm rollback.
• Seguir as práticas recomendadas como gráficos de linting, estruturação de componentes reutilizáveis, manipulação segura de segredos e gerenciamento eficaz de versões e dependências.

À medida que você ganha confiança ao trabalhar com o Helm, reserve um tempo para explorar o vasto ecossistemade gráficos públicos do Helm, hospedados pelas comunidades e fornecedores doy. Esses gráficos podem acelerar suas implementações e servir como referências valiosas para o seu próprio desenvolvimento.

Por fim, considere a possibilidade de contribuir com seus gráficos para a comunidade. Seja uma ferramenta interna personalizada ou uma versão bem empacotada de um projeto de código aberto, seus gráficos podem ajudar outras pessoas a implantar de forma mais eficiente e consistente no mundo do Kubernetes.

O Helm torna o Kubernetes mais simples - um gráfico de cada vez.

• Se você planeja obter uma certificação do Kubernetes, confira esteblog em Guia de certificação do Kubernetes: Exames, dicas e recursos de estudo. 
• Para obter uma trilha de aprendizagem estruturada que combine os fundamentos do Docker e do Kubernetes, confira nosso programa de virtualização e conteinerização.
• Aperfeiçoe suas habilidades no Git para gerenciar melhor os valores e arquivos de configuração do Helm usando nossos cursos de Introdução ao Git e Git Intermediário.