Uma introdução prática ao gerenciador de pacotes do Kubernetes - Helm



O artigo é uma continuação lógica de nossa publicação recente sobre o histórico do gerenciador de pacotes do Kubernetes - Helm . Desta vez, abordaremos novamente os problemas do dispositivo e do funcionamento do Helm atual ( versão 2.x ), bem como seus gráficos e repositórios gerenciados, após o que passaremos à prática de instalar o Helm no cluster Kubernetes e usar os gráficos.

Entrada


Helm é uma ferramenta de gerenciamento de gráficos.

O gráfico descreve o conjunto de dados necessário para instanciar o aplicativo no cluster Kubernetes. Ele pode ter gráficos incorporados e pode ser usado para descrever serviços completos, consistindo em muitos recursos dependentes, e para descrever componentes independentes individuais. Por exemplo, o gráfico stable / gitlab-ce descreve uma solução completa usando os gráficos redis e postgresql independentes.

Um gráfico pode ser definido um número ilimitado de vezes no mesmo cluster. Portanto, a descrição da lógica de implementação do aplicativo em diferentes ambientes pode e deve ser armazenada no mesmo gráfico.

O lado do cliente do Helm é responsável por criar o gráfico e transferir o componente Tiller para o cluster Kubernetes junto com os parâmetros do usuário. Por sua vez, Tiller é responsável pelo ciclo de vida da instância do gráfico lançado, release. (Só para garantir, lembre-se de que a próxima grande atualização do Helm - versão 3 - não terá mais o Tiller.)

E agora - as primeiras coisas primeiro.

Instalação e atualização


Helm requer que o Kubernetes funcione. Você pode usar um Minikube instalado localmente (consulte também “ Introdução ao Kubernetes com Minikube ”) ou qualquer outro cluster disponível.

Vamos começar com a instalação do cliente: selecione a versão , faça o download e descompacte o arquivo para o seu sistema, transfira o arquivo executável ...

$ curl https://storage.googleapis.com/kubernetes-helm/helm-v2.10.0-linux-amd64.tar.gz | tar -zxv $ sudo mv linux-amd64/helm /usr/local/bin/helm 

Em seguida, instale o Tiller no cluster. Por padrão, o Tiller é instalado no kubectl contexto kubectl contexto kubectl config current-context ), no espaço de nomes do kube-system , mas isso pode ser alterado usando as opções e variáveis ​​de ambiente apropriadas - elas são descritas na ajuda ( helm init --help ). Vamos concluir a instalação e examinar os recursos criados no cluster:

 $ helm init $HELM_HOME has been configured at /home/habr/.helm. (Use --client-only to suppress this message, or --upgrade to upgrade Tiller to the current version.) Happy Helming! $ kubectl get all --selector=name=tiller --namespace kube-system NAME READY STATUS RESTARTS AGE po/tiller-deploy-df4fdf55d-h5mvh 0/1 Running 0 5s NAME CLUSTER-IP EXTERNAL-IP PORT(S) AGE svc/tiller-deploy 10.107.191.68 <none> 44134/TCP 5s NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE deploy/tiller-deploy 1 1 1 0 5s NAME DESIRED CURRENT READY AGE rs/tiller-deploy-df4fdf55d 1 1 0 5s 

Agora, o Tiller está instalado no cluster e está pronto para o gerenciamento de versões, a interação com a API Kubernetes.

Nota : Durante a instalação e atualização (opção - --upgrade ) do Tiller, é possível especificar uma imagem específica em vez de usar a última versão estável por padrão. O nome de uma imagem arbitrária é determinado pela opção --tiller-image e, com a opção --canary-image , uma --canary-image será usada quando o Tiller for lançado. A imagem do canário permite usar o Tiller, cuja versão do código corresponde à ramificação principal.

Os dados do serviço são armazenados em um cluster em recursos especiais, o ConfigMaps , portanto, desinstalar e reinstalar o Tiller não leva à perda de dados de liberações instaladas anteriormente.

Repositórios de gráficos


Repositório de gráficos - um servidor HTTP para armazenar e distribuir gráficos. As informações sobre gráficos no repositório são armazenadas no arquivo index.yaml . Também indica de onde cada gráfico pode ser carregado. Na maioria das vezes, os gráficos são armazenados com o arquivo index.yaml , mas nada impede que eles sejam colocados em outro servidor. Normalmente, a estrutura do arquivo se resume a uma forma plana:

 . ├── index.yaml ├── artifactory-7.3.0.tgz ├── docker-registry-1.5.2.tgz ... └── wordpress-2.1.10.tgz 

Por padrão, o Helm usa o repositório oficial de gráficos do Kubernetes . Ele contém gráficos atuais cuidadosamente projetados para resolver muitos problemas aplicados. Este repositório é chamado de estável :

 $ helm repo list NAME URL stable https://kubernetes-charts.storage.googleapis.com 

Se necessário, criar seu próprio repositório não será problema. Os requisitos do servidor são mínimos, portanto, como a maioria dos repositórios de gráficos públicos, ele pode ser hospedado nas páginas do GitHub. Você pode ler mais sobre as ferramentas e as etapas necessárias para isso na documentação .

Ao usar repositórios de gráficos, eles podem ser adicionados e removidos. Para que as versões do gráfico estejam atualizadas, você deve atualizar periodicamente o índice. Vou dar um exemplo para o repositório público de bitnami , cuja maioria dos gráficos é usada no repositório oficial do Helm:

 $ helm repo add bitnami https://charts.bitnami.com/bitnami "bitnami" has been added to your repositories $ helm repo update Hang tight while we grab the latest from your chart repositories... ...Successfully got an update from the "bitnami" chart repository ...Successfully got an update from the "stable" chart repository Update Complete. Happy Helming! $ helm repo remove bitnami "bitnami" has been removed from your repositories 

Próximo - pesquise nos repositórios. Uma chamada de helm search sem argumentos mostra todos os gráficos disponíveis:

 $ helm search NAME CHART VERSION APP VERSION DESCRIPTION stable/acs-engine-autoscaler 2.2.0 2.1.1 Scales worker nodes within agent pools stable/aerospike 0.1.7 v3.14.1.2 A Helm chart for Aerospike in Kubernetes stable/anchore-engine 0.2.1 0.2.4 Anchore container analysis and policy evaluation engine s... stable/apm-server 0.1.0 6.2.4 The server receives data from the Elastic APM agents and ... stable/ark 1.2.1 0.9.1 A Helm chart for ark stable/artifactory 7.3.0 6.1.0 Universal Repository Manager supporting all major packagi... ... stable/weave-cloud 0.2.2 0.2.0 Weave Cloud is a add-on to Kubernetes which provides Cont... stable/weave-scope 0.9.3 1.6.5 A Helm chart for the Weave Scope cluster visualizer. stable/wordpress 2.1.10 4.9.8 Web publishing platform for building blogs and websites. stable/xray 0.4.1 2.3.0 Universal component scan for security and license invento... stable/zeppelin 1.0.1 0.7.2 Web-based notebook that enables data-driven, interactive ... stable/zetcd 0.1.9 0.0.3 CoreOS zetcd Helm chart for Kubernetes 

No campo de keywords opcionais em Chart.yaml desenvolvedores especificam tags usadas para simplificar a pesquisa nos repositórios de gráficos:

 $ helm search web NAME CHART VERSION APP VERSION DESCRIPTION stable/cerebro 0.3.1 0.8.1 A Helm chart for Cerebro - a web admin tool that replaces... stable/chronograf 0.4.5 1.3 Open-source web application written in Go and React.js th... stable/jasperreports 2.0.4 7.1.0 The JasperReports server can be used as a stand-alone or ... stable/joomla 2.0.9 3.8.12 PHP content management system (CMS) for publishing web co... stable/kubernetes-dashboard 0.7.2 1.8.3 General-purpose web UI for Kubernetes clusters stable/odoo 2.0.7 11.0.20180815 A suite of web based open source business apps. stable/phabricator 2.1.9 2018.34.0 Collection of open source web applications that help soft... stable/redmine 4.1.0 3.4.6 A flexible project management web application. stable/rethinkdb 0.1.4 0.1.0 The open-source database for the realtime web stable/schema-registry-ui 0.1.0 v0.9.4 This is a web tool for the confluentinc/schema-registry i... stable/superset 0.1.2 0.24.0 Apache Superset (incubating) is a modern, enterprise-read... stable/testlink 2.0.3 1.9.17 Web-based test management system that facilitates softwar... stable/tomcat 0.1.0 7 Deploy a basic tomcat application server with sidecar as ... stable/wordpress 2.1.10 4.9.8 Web publishing platform for building blogs and websites. ... $ helm search cms blog NAME CHART VERSION APP VERSION DESCRIPTION stable/drupal 1.1.3 8.5.6 One of the most versatile open source content management ... stable/joomla 2.0.9 3.8.12 PHP content management system (CMS) for publishing web co... stable/wordpress 2.1.10 4.9.8 Web publishing platform for building blogs and websites 

Nota: Ao usar o helm search , você pode encontrar uma operação instável de vários filtros: a disponibilidade do resultado depende da ordem da indicação e do número de filtros.

Após o círculo de pesquisa ter reduzido a várias opções, você pode prosseguir para uma análise mais detalhada dos gráficos - usando o helm inspect . Ele exibe o conteúdo dos arquivos de gráfico Chart.yaml , values.yaml e README.md . Cada seção pode ser exibida individualmente com os argumentos correspondentes: chart , values e readme - readme .

No repositório oficial, os gráficos são lindamente documentados e contêm exemplos de uso, e alguns têm até configurações prontas para produção . Por exemplo, um bom readme - readme é fornecido pelo stable / wordpress (para obter sua saída no console, consulte helm inspect readme stable/wordpress ) .

A pesquisa é uma boa maneira de encontrar pacotes acessíveis. Após a localização do pacote, você pode usá-lo para instalar o aplicativo no cluster.

Primeira aplicação


Por exemplo, o gráfico stable / wordpress já mencionado está selecionado.

Ele usa os parâmetros descritos no arquivo values.yaml . Você pode substituir os parâmetros em um arquivo YAML e depois transferi-lo durante a instalação (opções -f , --values ). Além disso, eles podem ser substituídos diretamente na linha de comando (opções --set , --set-string e --set-file ). Todas as opções estão disponíveis para uso um número arbitrário de vezes; ao mesmo tempo, a substituição na linha de comando tem precedência sobre os arquivos com parâmetros.

Ao definir o gráfico, você pode definir o nome do release com a opção --name ou usar o nome aleatório gerado pelo Helm.

Defina o gráfico de configuração para produção , altere o nome do blog, desative o salvamento de dados do WordPress no PersistentVolumeClaim (para obter mais informações sobre armazenamento persistente, consulte a documentação do Kubernetes ) :

 $ curl https://raw.githubusercontent.com/helm/charts/master/stable/wordpress/values-production.yaml --output values-production.yaml $ helm install --name habr --set "wordpressBlogName=Flant's Blog!" --set "persistence.enabled=false" -f values-production.yaml stable/wordpress NAME: habr LAST DEPLOYED: Fri Aug 31 15:17:57 2018 NAMESPACE: default STATUS: DEPLOYED RESOURCES: ==> v1/Secret NAME TYPE DATA AGE habr-mariadb Opaque 2 0s habr-wordpress Opaque 2 0s ==> v1/ConfigMap NAME DATA AGE habr-mariadb-init-scripts 1 0s habr-mariadb 1 0s habr-mariadb-tests 1 0s ==> v1/Service NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE habr-mariadb ClusterIP 10.111.7.232 <none> 3306/TCP 0s habr-wordpress ClusterIP 10.106.129.88 <none> 80/TCP,443/TCP 0s ==> v1beta1/Deployment NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE habr-wordpress 3 3 3 0 0s ==> v1beta1/StatefulSet NAME DESIRED CURRENT AGE habr-mariadb 1 1 0s ==> v1beta1/Ingress NAME HOSTS ADDRESS PORTS AGE wordpress.local-habr wordpress.local 80, 443 0s ==> v1/Pod(related) NAME READY STATUS RESTARTS AGE habr-wordpress-7955b95fd-hh7b9 0/1 ContainerCreating 0 0s habr-wordpress-7955b95fd-tgsxk 0/1 ContainerCreating 0 0s habr-wordpress-7955b95fd-xjz74 0/1 ContainerCreating 0 0s habr-mariadb-0 0/1 ContainerCreating 0 0s NOTES: 1. Get the WordPress URL: You should be able to access your new WordPress installation through https://wordpress.local/admin 2. Login with the following credentials to see your blog echo Username: user echo Password: $(kubectl get secret --namespace default habr-wordpress -o jsonpath="{.data.wordpress-password}" | base64 --decode) 

No caso de trabalhar com um cluster completo, você pode seguir as recomendações do bloco NOTES acima. Se você possui o Minikube, abra o site em um navegador da seguinte maneira:

 $ minikube service habr-wordpress Waiting, endpoint for service is not ready yet... Opening kubernetes service default/habr-wordpress in default browser... 

Parabéns, o aplicativo está em um cluster!



Um gráfico detalhado com o WordPress apareceu na lista de todos os lançamentos do Helm:

 $ helm list NAME REVISION UPDATED STATUS CHART APP VERSION NAMESPACE habr 1 Fri Aug 31 15:17:57 2018 DEPLOYED wordpress-2.1.10 4.9.8 default 

O próximo passo é atualizar nossa versão e alterar a imagem com o blog. Por exemplo, outra tag do mesmo repositório do Docker ( 4.9.8-ol-7 ) será usada:

 $ helm upgrade habr --set "image.tag=4.9.8-ol-7" --set "wordpressBlogName=Flant's Blog!" --set "persistence.enabled=false" -f values-production.yaml stable/wordpress Release "habr" has been upgraded. Happy Helming! LAST DEPLOYED: Fri Aug 31 15:21:08 2018 NAMESPACE: default STATUS: DEPLOYED RESOURCES: ==> v1/Service NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE habr-mariadb ClusterIP 10.111.7.232 <none> 3306/TCP 3m habr-wordpress ClusterIP 10.106.129.88 <none> 80/TCP,443/TCP 3m ==> v1beta1/Deployment NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE habr-wordpress 3 4 2 0 3m ==> v1beta1/StatefulSet NAME DESIRED CURRENT AGE habr-mariadb 1 1 3m ==> v1beta1/Ingress NAME HOSTS ADDRESS PORTS AGE wordpress.local-habr wordpress.local 80, 443 3m ==> v1/Pod(related) NAME READY STATUS RESTARTS AGE habr-wordpress-66f4fd6b74-gqwhh 0/1 Pending 0 0s habr-wordpress-66f4fd6b74-mf6vj 0/1 Pending 0 0s habr-wordpress-7955b95fd-hh7b9 1/1 Running 2 3m habr-wordpress-7955b95fd-tgsxk 1/1 Running 2 3m habr-wordpress-7955b95fd-xjz74 0/1 Terminating 2 3m habr-mariadb-0 1/1 Running 0 3m ==> v1/Secret NAME TYPE DATA AGE habr-mariadb Opaque 2 3m habr-wordpress Opaque 2 3m ==> v1/ConfigMap NAME DATA AGE habr-mariadb-init-scripts 1 3m habr-mariadb 1 3m habr-mariadb-tests 1 3m NOTES: 1. Get the WordPress URL: You should be able to access your new WordPress installation through https://wordpress.local/admin 2. Login with the following credentials to see your blog echo Username: user echo Password: $(kubectl get secret --namespace default habr-wordpress -o jsonpath="{.data.wordpress-password}" | base64 --decode) 

Observe que, ao atualizar o Tiller, o gráfico recebido compara os parâmetros com o último salvo e executa as solicitações correspondentes na API do Kubernetes, e o estado atual dos recursos da versão não é levado em consideração . É importante entender esse recurso e não cometer erros:

  • A atualização não é diferente da instalação: o cliente Helm envia o gráfico do Tiller junto com os parâmetros, portanto, você deve ter cuidado e lembrar de especificar os parâmetros e arquivos com os parâmetros que foram definidos durante a instalação (ou durante a atualização anterior) e que não devem ser ignorados. No exemplo acima, este é --set "wordpressBlogName=Flant's Blog!" --set "persistence.enabled=false" -f values-production.yaml --set "wordpressBlogName=Flant's Blog!" --set "persistence.enabled=false" -f values-production.yaml .
  • Os aplicativos lançados usando o Helm devem ser atendidos apenas com o Helm: as alterações manuais feitas com o kubectl não serão levadas em consideração pelo Helm e podem levar a consequências irreversíveis.

Daí a conclusão lógica: o processo deve ser automatizado e as alterações devem ser executadas apenas através da confirmação no repositório Git, alterando os arquivos de gráfico e o arquivo de configuração do IC.

O status dos componentes de liberação do aplicativo em um cluster sempre pode ser verificado da seguinte maneira:

 $ helm status habr LAST DEPLOYED: Fri Aug 31 15:21:08 2018 NAMESPACE: default STATUS: DEPLOYED RESOURCES: ==> v1/Secret NAME TYPE DATA AGE habr-mariadb Opaque 2 4m habr-wordpress Opaque 2 4m ==> v1/ConfigMap NAME DATA AGE habr-mariadb-init-scripts 1 4m habr-mariadb 1 4m habr-mariadb-tests 1 4m ==> v1/Service NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE habr-mariadb ClusterIP 10.111.7.232 <none> 3306/TCP 4m habr-wordpress ClusterIP 10.106.129.88 <none> 80/TCP,443/TCP 4m ==> v1beta1/Deployment NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE habr-wordpress 3 4 2 3 4m ==> v1beta1/StatefulSet NAME DESIRED CURRENT AGE habr-mariadb 1 1 4m ==> v1beta1/Ingress NAME HOSTS ADDRESS PORTS AGE wordpress.local-habr wordpress.local 80, 443 4m ==> v1/Pod(related) NAME READY STATUS RESTARTS AGE habr-wordpress-66f4fd6b74-gqwhh 0/1 Pending 0 1m habr-wordpress-66f4fd6b74-mf6vj 1/1 Running 0 1m habr-wordpress-7955b95fd-hh7b9 1/1 Running 3 4m habr-wordpress-7955b95fd-tgsxk 1/1 Running 3 4m habr-mariadb-0 1/1 Running 1 4m NOTES: 1. Get the WordPress URL: You should be able to access your new WordPress installation through https://wordpress.local/admin 2. Login with the following credentials to see your blog echo Username: user echo Password: $(kubectl get secret --namespace default habr-wordpress -o jsonpath="{.data.wordpress-password}" | base64 --decode) 

O Helm permite reverter para uma revisão de versão específica . Atualmente, existem duas revisões:

 $ helm history habr REVISION UPDATED STATUS CHART DESCRIPTION 1 Fri Aug 31 15:17:57 2018 SUPERSEDED wordpress-2.1.10 Install complete 2 Fri Aug 31 15:21:08 2018 DEPLOYED wordpress-2.1.10 Upgrade complete 

Reverta o aplicativo ao seu estado original:

 $ helm rollback habr 1 Rollback was a success! Happy Helming! 

Agora, o histórico de revisões foi reabastecido com um registro:

 $ helm history habr REVISION UPDATED STATUS CHART DESCRIPTION 1 Fri Aug 31 15:17:57 2018 SUPERSEDED wordpress-2.1.10 Install complete 2 Fri Aug 31 15:21:08 2018 SUPERSEDED wordpress-2.1.10 Upgrade complete 3 Fri Aug 31 15:25:06 2018 DEPLOYED wordpress-2.1.10 Rollback to 1 

O artigo está chegando ao fim e o lançamento não é mais necessário?

 $ helm delete habr release "habr" deleted 

É realmente excluído? ..

O comando remove os recursos do Kubernetes associados à liberação, mas não a liberação propriamente dita . Todas as informações sobre o lançamento permanecem disponíveis, incluindo seu histórico:

 $ helm list --all NAME REVISION UPDATED STATUS CHART APP VERSION NAMESPACE habr 3 Fri Aug 31 15:25:06 2018 DELETED wordpress-2.1.10 4.9.8 default 

 $ helm history habr REVISION UPDATED STATUS CHART DESCRIPTION 1 Fri Aug 31 15:17:57 2018 SUPERSEDED wordpress-2.1.10 Install complete 2 Fri Aug 31 15:21:08 2018 SUPERSEDED wordpress-2.1.10 Upgrade complete 3 Fri Aug 31 15:25:06 2018 DELETED wordpress-2.1.10 Deletion complete 

Nota : Conforme planejado, o release remoto pode ser revertido para as versões anteriores, mas nas versões recentes esse recurso não funciona - consulte o problema nº 3722 para obter detalhes.

Para remover completamente a liberação, use a opção --purge :

 $ helm delete --purge habr release "habr" deleted 

Resumindo


Este artigo fala sobre a arquitetura básica do Helm 2, seus componentes e suas funções, bem como as primitivas básicas, gráficos, liberações e repositórios de gráficos. Instalamos o Helm no cluster Kubernetes e adquirimos uma compreensão do ciclo de vida do release e dos comandos básicos para trabalhar com ele.

O material a seguir desta série será dedicado ao tópico de criação de seu próprio gráfico - nele falarei sobre a estrutura do gráfico, padronização e ferramentas de depuração. ATUALIZADO : Um novo artigo está disponível neste link .

PS


Source: https://habr.com/ru/post/pt420437/


All Articles