Introdução breve ao Kustomize

Nota do tradutor.: O artigo foi escrito por Scott Lowe - um engenheiro com vasta experiência em TI, autor/coautor de sete livros impressos (principalmente sobre VMware vSphere). Atualmente, ele trabalha em sua filial da VMware - Heptio (adquirida em 2016), especializado em computação em nuvem e Kubernetes. O texto oferece uma introdução concisa e fácil de entender sobre gerenciamento de configurações para Kubernetes usando a tecnologia Kustomize, que recentemente foi integrada ao K8s.

Kustomize é uma ferramenta que permite aos usuários “personalizar arquivos YAML simples e sem modelos para vários propósitos, mantendo o YAML original intacto e utilizável” (descrição extraída diretamente do repositório kustomize no GitHub). Kustomize pode ser executado diretamente ou, a partir do Kubernetes 1.14, pode usar kubectl -k para acessar suas funções (embora, com o Kubernetes 1.15, um binário separado seja mais recente do que as capacidades embutidas no kubectl). (Nota do tradutor.: E com o recente lançamento Kubernetes 1.16 (a propósito, seu desenvolvimento agora é feito em um repositório separado), ou seja, para processar arquivos YAML adicionais de diretórios especiais de kustomization (detalhes sobre seu uso podem ser encontrados em suportado , também na ferramenta kubeadm.) Nesta publicação, quero apresentar aos leitores os fundamentos do kustomize.

Em sua forma/uso mais simples, o kustomize é apenas um conjunto de recursos (arquivos YAML que definem objetos Kubernetes: Deployments, Services, etc.) mais uma lista de instruções sobre as mudanças que precisam ser feitas nesses recursos. Assim como o make usa um conjunto de instruções contidas em Makefile, e o Docker constrói um contêiner com base nas instruções de Dockerfile, o kustomize usa kustomization.yaml para armazenar as prescrições sobre quais alterações o usuário deseja fazer no conjunto de recursos.

Aqui está um exemplo de arquivo kustomization.yaml:

resources:
- deployment.yaml
- service.yaml
namePrefix: dev-
namespace: development
commonLabels:
  environment: development

Não tentarei falar sobre todos os campos possíveis no arquivo kustomization.yaml (o que é bem escrito aqui), mas farei uma breve explicação de um exemplo específico:

• Campo resources indica quais (quais recursos) o kustomize fará alterações. Neste caso, ele procurará recursos nos arquivos deployment.yaml e service.yaml em seu diretório (caminhos completos ou relativos podem ser especificados, se necessário).
• Campo namePrefix instrui o kustomize a adicionar um determinado prefixo (neste caso - dev-) ao atributo nome de todos os recursos definidos no campo resources. Assim, se houver um nome com o valor nginx-deployment, o kustomize o transformará em dev-nginx-deployment.
• Campo namespace instrui o kustomize a adicionar o namespace especificado a todos os recursos. Neste caso, Deployment e Service serão colocados no namespace desenvolvimento.
• Finalmente, o campo commonLabels contém um conjunto de rótulos que será adicionado a todos os recursos. No nosso exemplo, o kustomize atribuirá aos recursos um rótulo chamado environment e valor desenvolvimento.

Se o usuário executar kustomize build . no diretório com o arquivo kustomization.yaml e os recursos necessários (ou seja, os arquivos deployment.yaml e service.yaml), a saída será um texto com as alterações definidas em kustomization.yaml.

Nota do tradutor.: Ilustração da documentação do projeto sobre o uso "simples" do kustomize

A saída pode ser redirecionada, se necessário, para registrar as alterações:

kustomize build . > custom-config.yaml

A saída é determinística (com os mesmos dados de entrada, os mesmos resultados de saída serão produzidos), portanto, não é necessário salvar o resultado em um arquivo. Em vez disso, ele pode ser passado diretamente para outro comando:

kustomize build . | kubectl apply -f -

O acesso às funções do kustomize também pode ser obtido através de kubectl -k (a partir da versão 1.14 do Kubernetes). No entanto, tenha em mente que o pacote kustomize separado é atualizado mais rapidamente do que o integrado ao kubectl (pelo menos, assim é com o lançamento do Kubernetes 1.15).

Os leitores podem perguntar: "Por que todas essas complicações, se posso editar os arquivos diretamente?". Ótima pergunta. No nosso exemplo, realmente é possível modificar arquivos deployment.yaml e service.yaml diretamente, mas e se eles forem um fork de algum projeto? Modificar os arquivos diretamente dificulta (se não impossibilita) o rebase do fork, quando mudanças são feitas na fonte/origem. O uso do kustomize permite centralizar essas alterações em um arquivo kustomization.yaml, mantendo os arquivos originais intocados e, assim, facilitando a necessidade de rebase dos arquivos originais.

As vantagens do kustomize tornam-se evidentes em casos de uso mais complexos. No exemplo acima, kustomization.yaml e os recursos estão no mesmo diretório. No entanto, o kustomize suporta cenários em que há uma configuração base e várias de suas variantes, também conhecidas como Além disso:. Por exemplo, o usuário pode pegar um Deployment e um Service para o nginx, que usei como exemplo, e criar versões (ou variantes) de desenvolvimento, staging e produção desses arquivos. Para isso, ele precisará dos overlays mencionados acima e, de fato, dos próprios recursos base.

Para ilustrar a ideia de overlays e recursos base (base resources), suponha que os diretórios tenham a seguinte estrutura:

- base
  - deployment.yaml
  - service.yaml
  - kustomization.yaml
- overlays
  - dev
    - kustomization.yaml
  - staging
    - kustomization.yaml
  - prod
    - kustomization.yaml

No arquivo base/kustomization.yaml os usuários através do campo resources simplesmente declaram os recursos que o kustomize deve incluir.

Em cada um dos arquivos overlays/{dev,staging,prod}/kustomization.yaml os usuários se referem à configuração base no campo resources, e então especificam as mudanças específicas para este ambiente. Por exemplo, o arquivo overlays/dev/kustomization.yaml pode parecer como o exemplo acima:

resources:
- ../../base
namePrefix: dev-
namespace: development
commonLabels:
  environment: development

Enquanto isso, o arquivo overlays/prod/kustomization.yaml pode ser completamente diferente:

resources:
- ../../base
namePrefix: prod-
namespace: production
commonLabels:
  environment: production
  sre-team: blue

Quando um usuário executa kustomize build . no diretório overlays/dev, o kustomize gerará a variante de desenvolvimento. Se executar kustomize build . no diretório overlays/prod , obterá a variante de produção. E tudo isso — sem fazer nenhuma alteração nos arquivos originais (base) e tudo isso — de uma maneira declarativa e determinística. É possível fazer commit da configuração base e dos diretórios de overlay diretamente no sistema de controle de versão, sabendo que com base nesses arquivos sempre pode-se reproduzir a configuração desejada.

Nota do tradutor.: Ilustração da documentação do projeto sobre o uso de overlays no kustomize

O Kustomize pode muito mais do que é abordado neste artigo. No entanto, espero que ele sirva como uma boa introdução.

Recursos adicionais

Há muitos bons artigos e publicações sobre kustomize. Aqui estão alguns que considerei especialmente úteis:

• Mude a configuração YAML base para diferentes ambientes prod/test usando Kustomize;
• Kustomize — A maneira correta de fazer modelagem no Kubernetes;
• Gerenciamento Declarativo de Objetos Kubernetes Usando Kustomize;
• Personalizando Gráficos Helm Upstream com Kustomize.

Nota do tradutor.: Também é possível recomendar um bloco de links, publicados como Recursos no site da ferramenta, e a coleção subsequente de vídeos com as últimas palestras sobre kustomize.

Se você tiver dúvidas ou sugestões para melhorar este material, estou sempre aberto a feedback. Você pode entrar em contato comigo no Twitter ou para canal Slack do Kubernetes. Divirta-se modificando seus manifests usando o kustomize!

P.S. do tradutor

Confira também em nosso blog:

• «Ferramentas para desenvolvedores de aplicativos executados no Kubernetes»;
• «Kubernetes 1.14: visão geral das principais inovações»;
• «Cinco principais conclusões do Helm Summit 2019 em Amsterdã»;
• «Introdução prática ao gerenciador de pacotes para Kubernetes — Helm».

Fonte: habr.com