🥇Breve introdução ao Kustomize

Observação. trad.: O artigo foi escrito por Scott Lowe, engenheiro com vasta experiência em TI, autor/coautor de sete livros impressos (principalmente sobre VMware vSphere). Ele agora trabalha para a Heptio, subsidiária da VMware (adquirida em 2016), especializada em computação em nuvem e Kubernetes. O texto em si serve como uma introdução concisa e fácil de entender ao gerenciamento de configuração do Kubernetes usando tecnologia Customizar, que recentemente se tornou parte do K8s.

Kustomize é uma ferramenta que permite aos usuários “personalizar arquivos YAML simples e sem modelos para diferentes finalidades, deixando o YAML original intacto e utilizável” (descrição emprestada diretamente de personalizar repositório no GitHub). Kustomize pode ser executado diretamente ou, a partir do Kubernetes 1.14, usado kubectl -k para acessar sua funcionalidade (embora a partir do Kubernetes 1.15, o binário separado seja mais recente que os recursos integrados ao kubectl). (Observação. trad.: E com o lançamento recente Kubernetes 1.16 personalizar apoiado por também no utilitário kubeadm.) Neste post, quero apresentar aos leitores os fundamentos do kustomize.

Em sua forma/aplicação mais simples, kustomize é simplesmente uma coleção de recursos (arquivos YAML que definem objetos Kubernetes: implantações, serviços, etc.) mais uma lista de instruções para alterações que precisam ser feitas nesses recursos. Assim como make usa o conjunto de instruções contido em Makefile, e o Docker constrói o contêiner com base nas instruções de Dockerfile,personalizar usos kustomization.yaml para armazenar instruções sobre quais alterações o usuário deseja fazer em um conjunto de recursos.

Aqui está um arquivo de exemplo 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 (isso está bem escrito sobre aqui), mas darei uma breve explicação de um exemplo específico:

Campo resources indica o que (quais recursos) o kustomize mudará. Neste caso, irá procurar recursos em arquivos deployment.yaml и service.yaml no seu diretório (você pode especificar caminhos completos ou relativos, se necessário).
Campo namePrefix instrui o kustomize a adicionar um determinado prefixo (neste caso - dev-) atribuir name todos os recursos definidos no campo resources. Assim, se a implantação tiver name com valor nginx-deployment, personalizar fará isso dev-nginx-deployment.
Campo namespace instrui o kustomize a adicionar o namespace fornecido a todos os recursos. Nesse caso, Implantação e Serviço cairão no namespace development.
Finalmente, o campo commonLabels contém um conjunto de rótulos que serão adicionados a todos os recursos. Em nosso exemplo, kustomize atribuirá um rótulo aos recursos com o nome environment e significado development.

Se o usuário fizer kustomize build . no diretório com o arquivo kustomization.yaml e os recursos necessários (ou seja, arquivos deployment.yaml и service.yaml), então na saída ele receberá um texto com as alterações especificadas em kustomization.yaml.

Observação. trad.: Ilustração da documentação do projeto sobre o uso “simples” de kustomize

A saída pode ser redirecionada se for necessário confirmar alterações:

kustomize build . > custom-config.yaml

Os dados de saída são determinísticos (os mesmos dados de entrada produzirão os mesmos resultados de saída), portanto você não precisa salvar o resultado em um arquivo. Em vez disso, pode ser passado diretamente para outro comando:

kustomize build . | kubectl apply -f -

Os recursos de personalização também podem ser acessados via kubectl -k (desde a versão 1.14 do Kubernetes). No entanto, lembre-se de que o pacote kustomize independente é atualizado mais rapidamente do que o pacote kubectl integrado (pelo menos é o caso da versão 1.15 do Kubernetes).

Os leitores podem perguntar: “Por que toda essa complexidade se você pode editar os arquivos diretamente?” Ótima pergunta. No nosso exemplo, de fato uma lata modificar arquivos deployment.yaml и service.yaml diretamente, mas e se eles forem uma bifurcação do projeto de outra pessoa? Alterar arquivos diretamente torna difícil (se não impossível) rebase de uma bifurcação quando alterações são feitas na origem/fonte. Usar kustomize permite centralizar essas alterações em um arquivo kustomization.yaml, deixando os arquivos originais intactos e facilitando assim o rebase dos arquivos originais, se necessário.

Os benefícios do kustomize tornam-se aparentes em casos de uso mais complexos. No exemplo acima kustomization.yaml e os recursos estão no mesmo diretório. No entanto, kustomize oferece suporte a casos de uso onde existe uma configuração básica e muitas variantes dela, também conhecida como sobreposições. Por exemplo, um usuário queria usar Deployment and Service for nginx, que usei como exemplo, e criar versões (ou variantes) de desenvolvimento, teste e produção desses arquivos. Para isso, ele precisará das sobreposições mencionadas acima e, na verdade, dos próprios recursos básicos.

Para ilustrar a ideia de sobreposições e recursos subjacentes (recursos básicos), vamos supor 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 usuários usando o campo resources simplesmente declare os recursos que o kustomize deve incluir.

Em cada um dos arquivos overlays/{dev,staging,prod}/kustomization.yaml os usuários referem-se à configuração básica no campo resourcese, em seguida, indique alterações específicas para determinado ambiente. Por exemplo, arquivo overlays/dev/kustomization.yaml pode ser semelhante ao exemplo dado anteriormente:

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

Neste caso o arquivo overlays/prod/kustomization.yaml poderia ser completamente diferente:

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

Quando o usuário executa kustomize build . no catálogo overlays/dev, kustomize irá gerar a opção de desenvolvimento. Se você correr kustomize build . no catálogo overlays/prod - você obtém a opção de produção. E tudo isso - sem fazer alterações no original (base) arquivos, tudo de forma declarativa e determinística. Você pode enviar a configuração base e os diretórios de sobreposição diretamente para o controle de versão, sabendo que com base nesses arquivos você pode reproduzir a configuração desejada a qualquer momento.

Observação. trad.: Ilustração da documentação do projeto sobre o uso de sobreposições no kustomize

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

Recursos adicionais

Existem muitos artigos e publicações bons sobre kustomize. Aqui estão alguns que achei particularmente úteis:

Observação. trad.: Você também pode recomendar um bloco de links publicados como Regal no site do utilitário, seguido por uma coleção de vídeos com os relatórios mais recentes sobre kustomize.

Se você tiver dúvidas ou sugestões para melhorar este material, estou sempre aberto a comentários. Você pode entrar em contato comigo em Twitter ou Canal Slack do Kubernetes. Divirta-se modificando seus manifestos com o kustomize!

Uma breve introdução ao Kustomize

Recursos adicionais

PS do tradutor