Usando Helm e Kubernetes

1. Visão geral

Helm is a package manager for Kubernetes applications. Neste tutorial, entenderemos os fundamentos do Helm e como eles formam uma ferramenta poderosa para trabalhar com recursos do Kubernetes.

Nos últimos anos, o Kubernetes cresceu tremendamente, e o ecossistema também o apoia. Recentemente, o Helm foi anunciado como um projeto em incubação porCloud Native Computing Foundation (CNCF), o que mostra sua popularidade crescente entre os usuários do Kubernetes.

2. fundo

Embora esses termos sejam bastante comuns atualmente, especialmente entre aqueles que trabalham com tecnologias de nuvem, vamos examiná-los rapidamente para quem não sabe:

Container:Container refers to operating system level virtualization. Vários contêineres são executados em um sistema operacional em espaços de usuário isolados. Os programas em execução em um contêiner têm acesso apenas aos recursos atribuídos ao contêiner.
Docker:Docker is a popular program to create and run containers. Ele vem com o Docker Daemon, que é o principal programa que gerencia contêineres. O Docker Daemon oferece acesso a seus recursos por meio da API do Docker Engine, usada pela CLI (Interface da linha de comando) do Docker. Please refer to this article for a more detailed description of Docker.
Kubernetes:Kubernetes is a popular container orchestration program. Embora tenha sido projetado para trabalhar com diferentes contêineres, o Docker é usado com mais frequência. Ele oferece uma ampla seleção de recursos, incluindo automação de implantação, dimensionamento e operações em um cluster de hosts. There is excellent coverage of Kubernetes in this article for further reference.

3. Arquitetura do leme

O Helm possui uma arquitetura bastante simples, composta por um cliente e um servidor em cluster:

Tiller Server:Helm manages Kubernetes application through a component called Tiller Server instalado em um cluster Kubernates. O Tiller interage com o servidor da API Kubernetes para instalar, atualizar, consultar e remover recursos do Kubernetes.
Cliente do Helm:Helm provides a command-line interface for users to work with Helm Charts. O Helm Client é responsável por interagir com o Tiller Server para executar várias operações, como gráficos de instalação, atualização e reversão.

4. Helm Charts

Helm manages Kubernetes resource packages through Charts.

Veremos mais sobre os gráficos conforme os criarmos em breve, mas por enquanto, um gráfico nada mais é do que um conjunto de informações necessárias para criar um aplicativo Kubernetes, dado um cluster Kubernetes:

Achart is a collection of files organizado em uma estrutura de diretório específica
As informações de configuração relacionadas a um gráfico são gerenciadas na configuração
Finalmente,a running instance of a chart with a specific config is called a release

5. Configuração

Precisamos de algumas coisas a serem configuradas com antecedência para desenvolvermos nosso primeiro gráfico de leme.

Primeiramente, para começar a trabalhar com o Helm, precisamos de um cluster Kubernetes. Para este tutorial, usaremosMinikube, which offers an excellent way to work with a single-node Kubernetes cluster locally. No Windows, agora é possível usar o Hyper-V como o hipervisor nativo para executar o Minikube. Refer to this article to understand setting up Minikube in more details.

E, precisaremos de um aplicativo básico para gerenciar dentro do cluster Kubernetes. Para este tutorial, usaremos um aplicativo Spring Boot simples empacotado como um contêiner Docker. For a more detailed description of how to package such an application as a Docker container, please refer to this article.

6. Instalando o Helm

Existem várias maneiras de instalar o Helm que estão perfeitamente descritas emthe official install page on Helm. The quickest way to install helm on Windows is using Chocolaty, um gerenciador de pacotes para plataformas Windows.

Usando o Chocolaty, é um comando simples de uma linha para instalar o Helm:

choco install kubernetes-helm

Isso instala o Helm Client localmente.

Agora, precisamos inicializar o Helm CLI, que efetivamente também instala o servidor Tiller em um cluster Kubernetes, conforme identificado na configuração do Kubernetes. Por favor,ensure that the Kubernetes cluster is running and accessible through kubectl before initializing Helm:

kubectl cluster-info

E então, podemos inicializar o Helm através da própria CLI do Helm:

helm init

7. Desenvolvendo nosso primeiro gráfico

Agora, estamos prontos para desenvolver nosso primeiro Helm Chart com modelos e valores.

7.1. Criando um gráfico

Helm CLI, which we installed earlier, is quite handy in creating a chart:

helm create hello-world

Observe que osname of the chart provided here will be the name of the directory where the chart is createde armazenados.

Vamos ver rapidamente a estrutura de diretórios criada para nós:

hello-world /
  Chart.yaml
  values.yaml
  templates /
  charts /
  .helmignore

Vamos entender a relevância desses arquivos e pastas criados para nós:

Chart.yaml: Este é o arquivo principal que contém a descrição do nosso gráfico
values.yaml: este é o arquivo que contém os valores padrão para nosso gráfico
templates: este é o diretório onde os recursos do Kubernetes são definidos como modelos
charts: este é um diretório opcional que pode conter subgráficos
.helmignore: aqui é onde podemos definir padrões a serem ignorados ao empacotar (semelhante em conceito a .gitignore)

7.2. Criando modelo

Se virmos dentro do diretório de modelos, notaremos quefew templates for common Kubernetes resources have already been created para nós:

hello-world /
  templates /
    deployment.yaml
    service.yaml
    ingress.yaml
    ......

Podemos precisar de alguns desses e possivelmente de outros recursos em nosso aplicativo, que teremos que criar como modelos.

Para este tutorial, vamos criar uma implantação e um serviço para expor essa implantação. Observe que a ênfase aqui não é entender o Kubernetes em detalhes. Portanto, manteremos esses recursos o mais simples possível.

Vamos editar o arquivodeployment.yaml dentro do diretóriotemplates para se parecer com:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: {{ include "hello-world.fullname" . }}
  labels:
    app.kubernetes.io/name: {{ include "hello-world.name" . }}
    helm.sh/chart: {{ include "hello-world.chart" . }}
    app.kubernetes.io/instance: {{ .Release.Name }}
    app.kubernetes.io/managed-by: {{ .Release.Service }}
spec:
  replicas: {{ .Values.replicaCount }}
  selector:
    matchLabels:
      app.kubernetes.io/name: {{ include "hello-world.name" . }}
      app.kubernetes.io/instance: {{ .Release.Name }}
  template:
    metadata:
      labels:
        app.kubernetes.io/name: {{ include "hello-world.name" . }}
        app.kubernetes.io/instance: {{ .Release.Name }}
    spec:
      containers:
        - name: {{ .Chart.Name }}
          image: "{{ .Values.image.repository }}:{{ .Values.image.tag }}"
          imagePullPolicy: {{ .Values.image.pullPolicy }}
          ports:
            - name: http
              containerPort: 8080
              protocol: TCP

Da mesma forma, vamos editar o arquivoservice.yaml para se parecer com:

apiVersion: v1
kind: Service
metadata:
  name: {{ include "hello-world.fullname" . }}
  labels:
    app.kubernetes.io/name: {{ include "hello-world.name" . }}
    helm.sh/chart: {{ include "hello-world.chart" . }}
    app.kubernetes.io/instance: {{ .Release.Name }}
    app.kubernetes.io/managed-by: {{ .Release.Service }}
spec:
  type: {{ .Values.service.type }}
  ports:
    - port: {{ .Values.service.port }}
      targetPort: http
      protocol: TCP
      name: http
  selector:
    app.kubernetes.io/name: {{ include "hello-world.name" . }}
    app.kubernetes.io/instance: {{ .Release.Name }}

Agora, com o nosso conhecimento do Kubernetes, esses arquivos de modelo parecem bastante familiares, exceto por algumas esquisitices. Note the liberal usage of text within double parentheses \{\{}}. This is what is called a template directive.

Helm makes use of the Go template language and extends that to something called Helm template language. Durante a avaliação, todos os arquivos dentro do diretório de modelos são submetidos ao mecanismo de renderização de modelos. É aqui que a diretiva de modelo injeta valores reais nos modelos.

7.3. Fornecendo valores

Na subseção anterior, vimos como usar a diretiva de modelo em nossos modelos. Agora, vamos entender como podemos passar valores para o mecanismo de renderização de template. We typically pass values through Built-in Objects in Helm.

Existem muitos objetos disponíveis no Helm, como Liberação, Valores, Gráfico e Arquivos.

Podemos usar o arquivovalues.yaml em nosso gráfico para passar valores para o mecanismo de renderização do modelo por meio dos Valores de objeto integrados. Vamos modificar ovalues.yaml para ficar assim:

replicaCount: 1
image:
  repository: "hello-world"
  tag: "1.0"
  pullPolicy: IfNotPresent
service:
  type: NodePort
  port: 80

No entanto, observe como esses valores foram acessados nos modelos usando pontos que separam os espaços para nome. Usamos o repositório de imagens e a tag como "olá mundo" e "1.0". Isso deve corresponder à tag da imagem do docker que criamos para nosso aplicativo Spring Boot.

8. Noções básicas sobre comandos de leme

Com tudo feito até agora, agora estamos prontos para brincar com nosso gráfico. Vamos ver quais são os diferentes comandos disponíveis no Helm CLI para tornar isso divertido!

8.1. Helm Lint

Em primeiro lugar, este é um comando simples que segue o caminho para um gráfico e executa uma bateria de testes para garantir que o gráfico esteja bem formado:

helm lint ./hello-world
==> Linting ./hello-world
1 chart(s) linted, no failures

8.2 Helm Template

Além disso, temos este comando para renderizar o modelo localmente, sem um Servidor Tiller, para obter um feedback rápido:

helm template ./hello-world
---
# Source: hello-world/templates/service.yaml
apiVersion: v1
kind: Service
metadata:
  name: release-name-hello-world
  labels:
    app.kubernetes.io/name: hello-world
    helm.sh/chart: hello-world-0.1.0
    app.kubernetes.io/instance: release-name
    app.kubernetes.io/managed-by: Tiller
spec:
  type: NodePort
  ports:
    - port: 80
      targetPort: http
      protocol: TCP
      name: http
  selector:
    app.kubernetes.io/name: hello-world
    app.kubernetes.io/instance: release-name

---
# Source: hello-world/templates/deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: release-name-hello-world
  labels:
    app.kubernetes.io/name: hello-world
    helm.sh/chart: hello-world-0.1.0
    app.kubernetes.io/instance: release-name
    app.kubernetes.io/managed-by: Tiller
spec:
  replicas: 1
  selector:
    matchLabels:
      app.kubernetes.io/name: hello-world
      app.kubernetes.io/instance: release-name
  template:
    metadata:
      labels:
        app.kubernetes.io/name: hello-world
        app.kubernetes.io/instance: release-name
    spec:
      containers:
        - name: hello-world
          image: "hello-world:1.0"
          imagePullPolicy: IfNotPresent
          ports:
            - name: http
              containerPort: 8080
              protocol: TCP

8.3. Instalação do leme

Depois de verificar se o gráfico está bom, finalmente, podemos executar este comando para instalar o gráfico no cluster do Kubernetes:

helm install --name hello-world ./hello-world
NAME:   hello-world
LAST DEPLOYED: Mon Feb 25 15:29:59 2019
NAMESPACE: default
STATUS: DEPLOYED

RESOURCES:
==> v1/Service
NAME         TYPE      CLUSTER-IP     EXTERNAL-IP  PORT(S)       AGE
hello-world  NodePort  10.110.63.169         80:30439/TCP  1s

==> v1/Deployment
NAME         DESIRED  CURRENT  UP-TO-DATE  AVAILABLE  AGE
hello-world  1        0        0           0          1s

==> v1/Pod(related)
NAME                          READY  STATUS   RESTARTS  AGE
hello-world-7758b9cdf8-cs798  0/1    Pending  0         0s

Por fim, observe que nomeamos o lançamento deste gráfico com a bandeira –name. O comando responde com o resumo dos recursos do Kubernetes criados no processo.

8.4. Helm Get

Agora, gostaríamos de ver quais gráficos estão instalados e qual versão. Este comando nos permite consultar os releases nomeados:

helm ls --all
NAME            REVISION        UPDATED                         STATUS          CHART               APP VERSION NAMESPACE
hello-world     1               Mon Feb 25 15:29:59 2019        DEPLOYED        hello-world-0.1.0   1.0         default

8.5. Atualização do leme

E se tivermos modificado nosso gráfico e precisar instalar a versão atualizada? Este comando nos ajuda a atualizar um release para uma versão especificada ou atual do gráfico ou configuração:

helm upgrade hello-world ./hello-world
Release "hello-world" has been upgraded. Happy Helming!
LAST DEPLOYED: Mon Feb 25 15:36:04 2019
NAMESPACE: default
STATUS: DEPLOYED

RESOURCES:
==> v1/Service
NAME         TYPE      CLUSTER-IP     EXTERNAL-IP  PORT(S)       AGE
hello-world  NodePort  10.110.63.169         80:30439/TCP  6m5s

==> v1/Deployment
NAME         DESIRED  CURRENT  UP-TO-DATE  AVAILABLE  AGE
hello-world  1        1        1           1          6m5s

==> v1/Pod(related)
NAME                          READY  STATUS   RESTARTS  AGE
hello-world-7758b9cdf8-cs798  1/1    Running  0         6m4s

8.6. Reversão do leme

Sempre pode acontecer que um lançamento tenha errado e precise ser recuperado. Este é o comando para reverter um release para a versão anterior:

helm rollback hello-world 1
Rollback was a success! Happy Helming!

8.7. Excluir leme

Embora menos provável, podemos excluir uma versão completamente. Podemos usar este comando para excluir uma versão do Kubernetes:

helm delete --purge hello-world
release "hello-world" deleted

Esses são apenas alguns dos comandos disponíveis para trabalhar com gráficos e liberações no Helm.

9. Distribuindo gráficos

Embora os modelos sejam uma ferramenta poderosa que o Helm traz para o mundo do gerenciamento de recursos do Kubernetes, não é o único benefício de usar o Helm. Como vimos na seção anterior, o Helm atua como um gerenciador de pacotes para o aplicativo Kubernetes e simplifica a instalação, a consulta, a atualização e a exclusão de versões.

Além disso,Helm comes with commands as part of its CLI to package, publish, and fetch Kubernetes applications as charts:

9.1. Pacote de Leme

Primeiro, precisamos empacotar os gráficos que criamos para poder distribuí-los. Este é o comando para criar arquivos compactados com versão do gráfico:

helm package ./hello-world
Successfully packaged chart and saved it to: \hello-world\hello-world-0.1.0.tgz

Observe que ele produz um arquivo na sua máquina que pode ser distribuído manualmente ou por meio de repositórios de gráficos públicos ou privados.

9.2. Helm Repo

Finalmente, precisamos de um mecanismo para trabalhar com repositórios compartilhados para colaborar. O repositório agrupa vários comandos que podemos usar para adicionar, remover, listar ou indexar repositórios de gráficos. Vamos ver como podemos usá-los.

We can create a git repository and use that to function as our chart repository. O único requisito é que ele deve ter um arquivoindex.yaml.

Podemos criarindex.yaml para nosso repo de gráfico:

helm repo index my-repo/ --url https://.github.io/my-repo

Isso gera o arquivoindex.yaml, que devemos enviar para o repositório junto com os arquivos do gráfico.

Após criar com êxito o repositório do gráfico, posteriormente, podemos adicionar remotamente este repositório:

helm repo add my-repo https://my-pages.github.io/my-repo

Agora, poderemos instalar os gráficos diretamente do nosso repositório:

helm install my-repo/hello-world --name=hello-world

Existemquite some utility commands available para trabalhar com repositórios de gráficos.

10. Conclusão

Para resumir, neste tutorial, discutimos os principais componentes do Helm, um gerenciador de pacotes para aplicativos Kubernetes. Entendemos as opções para instalar o Helm. Além disso, criamos um gráfico de amostra e modelos com valores.

Em seguida, examinamos vários comandos disponíveis como parte da Helm CLI para gerenciar o aplicativo Kubernetes como um pacote Helm.

Finalmente, discutimos as opções para distribuir pacotes Helm por meio de repositórios.

TOC

Usando Helm e Kubernetes