Nota perev. : O artigo foi escrito por Scott Lowe, um engenheiro de TI sênior que foi o autor / co-autor de sete livros impressos (principalmente para o VMware vSphere). Atualmente, ele trabalha na subsidiária da VMware, Heptio (adquirida em 2016), especializada em computação em nuvem e Kubernetes. O próprio texto serve como uma introdução ampla e fácil de entender ao gerenciamento de configurações do Kubernetes usando a tecnologia Kustomize , incluída recentemente no K8s.
O Kustomize é uma ferramenta que permite aos usuários "personalizar arquivos YAML simples e sem modelos para vários propósitos, deixando o YAML original intacto e utilizável" (a descrição é emprestada diretamente do
repositório kustomize no GitHub ). O Kustomize pode ser executado diretamente ou, começando no Kubernetes 1.14, use o
kubectl -k para acessar suas funções (embora, a partir do Kubernetes 1.15, um binário separado seja mais novo que os recursos incorporados no kubectl).
( Nota : Com a versão recente do Kubernetes 1.16 , o kustomize também é suportado no utilitário kubeadm.) Nesta publicação, quero apresentar aos leitores os conceitos básicos do kustomize.
Em sua forma / aplicativo mais simples, o kustomize é simplesmente uma coleção de recursos (arquivos YAML que definem objetos do Kubernetes: Implantações, Serviços etc.), além de uma lista de instruções sobre as alterações que precisam ser feitas nesses recursos. Assim como o make usa o conjunto de instruções contido no
Makefile e o Docker
Dockerfile contêiner com base nas instruções do
Dockerfile , o kustomize usa o
kustomization.yaml para armazenar instruções sobre as alterações que 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 (isso está bem escrito
aqui ), mas darei uma breve explicação de um exemplo específico:
- O campo de
resources indica o que (quais recursos) personalizar irá mudar. Nesse caso, ele procurará recursos nos arquivos deployment.yaml e service.yaml em seu diretório (se necessário, você poderá especificar caminhos completos ou relativos). - O campo
namePrefix instrui o kustomize a adicionar um prefixo específico (neste caso, dev- ) ao atributo name de todos os recursos definidos no campo de resources . Portanto, se houver um name em Deployment com o valor nginx-deployment , o kustomize fará com que o dev-nginx-deployment . - O campo de
namespace instrui o kustomize a adicionar o espaço para nome especificado a todos os recursos. Nesse caso, o Deployment and Service cairá no namespace de development . - Por fim, o campo
commonLabels contém um conjunto de rótulos que serão adicionados a todos os recursos. Em nosso exemplo, o kustomize atribuirá um rótulo aos recursos com o environment nome e o development valor.
Se o usuário executar o
kustomize build . no diretório com o arquivo
kustomization.yaml e os recursos necessários (ou seja, arquivos
deployment.yaml e
service.yaml ), ele receberá o texto com as alterações registradas em
kustomization.yaml como
kustomization.yaml .
Nota perev. : Ilustração da documentação do projeto para o uso "simples" de kustomizeA saída pode ser redirecionada se você precisar confirmar as alterações:
kustomize build . > custom-config.yaml
A saída é determinística (com a mesma entrada, a mesma saída será obtida), portanto, você não pode salvar o resultado em um arquivo. Em vez disso, você pode passá-lo imediatamente para outro comando:
kustomize build . | kubectl apply -f -
As funções Kustomize também podem ser acessadas via
kubectl -k (desde a versão 1.14 do Kubernetes). No entanto, lembre-se de que um pacote kustomize separado é atualizado mais rapidamente do que um pacote integrado no kubectl (pelo menos esse é o caso da versão do Kubernetes 1.15).
Os leitores podem perguntar: "Por que todas essas dificuldades, se você pode editar arquivos diretamente?". Ótima pergunta. No nosso exemplo, é realmente
possível modificar os arquivos
deployment.yaml e
service.yaml diretamente, mas e se eles forem um fork do projeto de outra pessoa? A alteração direta de arquivos dificulta (se não é de todo impossível) reorganizar a bifurcação quando são feitas alterações na fonte / fonte. O uso do kustomize permite centralizar essas alterações no arquivo
kustomization.yaml , deixando os arquivos originais intactos e facilitando a recuperação dos arquivos de origem, se necessário.
Os benefícios do kustomize se tornam aparentes em casos de uso mais complexos. No exemplo acima,
kustomization.yaml e recursos estão no mesmo diretório. No entanto, o kustomize suporta cenários de uso quando há uma configuração básica e muitas de suas variantes, também conhecidas como
sobreposições . Por exemplo, um usuário queria usar o Deployment and Service para nginx, que eu usei como exemplo, e criar versões de desenvolvimento, preparo e produção (ou variantes) desses arquivos. Para fazer isso, ele precisará das sobreposições mencionadas acima e, de fato, dos próprios recursos básicos.
Para ilustrar a idéia de sobreposições e
recursos básicos , 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
base/kustomization.yaml usuários simplesmente usam o campo de
resources para declarar os recursos que o kustomize deve ativar.
Em cada um dos
overlays/{dev,staging,prod}/kustomization.yaml de
overlays/{dev,staging,prod}/kustomization.yaml usuários se referem à configuração básica no campo de
resources e indicam as alterações específicas para
esse ambiente . Por exemplo, o
overlays/dev/kustomization.yaml pode se parecer com o exemplo fornecido anteriormente:
resources: - ../../base namePrefix: dev- namespace: development commonLabels: environment: development
Ao mesmo tempo, o
overlays/prod/kustomization.yaml pode ser completamente diferente:
resources: - ../../base namePrefix: prod- namespace: production commonLabels: environment: production sre-team: blue
Quando o usuário inicia, personalize a
kustomize build . no
overlays/dev , o kustomize irá gerar uma opção de desenvolvimento. Se você executar o
kustomize build . no diretório
overlays/prod - você obtém a opção de produção. E tudo isso - sem fazer nenhuma alteração nos arquivos originais
(base) , e tudo isso - de maneira declarativa e determinística. Você pode confirmar os diretórios básicos de configuração e sobreposição diretamente no sistema de controle de versão, sabendo que, com base nesses arquivos, é possível reproduzir a configuração desejada a qualquer momento.
Nota perev. : Ilustração da documentação do projeto para usar sobreposições no kustomizeO Kustomize pode fazer
muito mais do que o descrito neste artigo. No entanto, espero que sirva como uma boa introdução.
Recursos Adicionais
Existem muitos bons artigos e publicações sobre o kustomize. Aqui estão alguns que eu achei particularmente úteis:
Nota perev. : Você também pode aconselhar o bloco de links publicados como Recursos no site do utilitário e a coleção subseqüente de vídeos com os relatórios mais recentes sobre o 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 no
Twitter ou no
canal Kubernetes Slack . Divirta-se modificando seus manifestos com o kustomize!
PS do tradutor
Leia também em nosso blog: