Helm Package do zero no Kubernetes

Antes de mais nada, o Helm é a principal ferramenta de gerenciamento de pacotes no Kubernetes. Não apenas foi construído em Go Lang e validado pela CNCF mas também é OpenSource. De fato ele oferece uma experiência de uso semelhante a de um apt-get, homebrew, etc, sendo bastante completo para o desenvolvimento. Desse modo é possível entender os manifestos kubernetes como um template com variáveis substituíveis. Ao mesmo tempo aqui no blog construímos um conjunto de artigos interessantes que vão te oferecer meios para vocês entender o Helm Package do zero no Kubernetes.

• Criando um cluster Kubernetes com K3D
• 10 Ferramentas mais utilizadas no Kubernetes
• Exemplos de Yaml para Kubernetes com Awesome-Kubernetes
• Como instalar o Helm no Kubernetes
• Como criar um helm package Hello World
• Implantando o helm package no ArtifactHub
• Kubernetes e o deployment quase perfeito
• Helm Package para além do básico

Com o fim de facilitar a compreensão e síntese, contruímos como referência um projeto denominado kube-wordpress-mysql. Ele tem workloads para o funcionamento do wordpress e mysql, além de ter uma estrutura para exposição externa. Customizamos esse repositório para que ele seja todo configurável. Após isso publicamos o repositório no ArtifactHub.

A Solução Kube-wordpress-mysql

Primeiramente ela pode ser encontrada no Artifacthub ou no Github. A solução em si é bastante simples de ser entendida, mas vamos ver um pouco dos detalhes. Ela possui 3 pastas principais dentro de templates: general, mysql e wordpress.

• /Templates/General possui um clusterIssuer que utiliza o cert-manager, de modo que o site fique exposto via HTTPS; e também possui um ingress baseado no nginx-ingress.
• /Templates/mysql possui um configmap, hpa, PersistentVolumeClaim, secrets, service, storageclass o workload num statefulset.
• /Templates/wordpress é muito semelhante à mysql, porém o workload é do tipo deployment e não há um pvc associado.

Como pensar a o values.yaml

O arquivo values.yaml foi feito para ter uma legibilidade muito grande. Nele há 4 itens principais que norteam toda a configuração: public_url, tls, mysql e wordpress.

# Qual será a URL pública da WordPress
public_url: mypublicurl.anselme.com.br

# Configurações de exposição do site em https
tls:
  enabled: true
  server: https://acme-v02.api.letsencrypt.org/directory    
  email: [email protected] 
  redirect_http_to_https: true   

# Configuração do MySQL
mysql:
  autoscalling:
    enabled: true        
    min_replicas: 1      
    max_replicas: 3      
    avg_memory_utilization: 90   
    avg_cpu_utilization: 80     
  database:
    username: YW5zZWxtZQ==   
    username_password: YTEyMzQ1Ng== 
    root_password: cm9vdA== 
  resources: 
    memory_limit: 512Mi   
    memory_requested: 256Mi 
    cpu_limit: 500m 
    cpu_requested: 100m 
  persistent_volume:
    storage: 10Gi   
  labels:                     
    app.kubernetes.io/name: mysql
    app.kubernetes.io/instance: mysql-general
    app.kubernetes.io/version: 1.0.0
    app.kubernetes.io/component: database
    app.kubernetes.io/part-of: wordpress
    app.kubernetes.io/managed-by: helm
    enviroment: production
    confidenciality: restrict
    compliance: none

# Configuração do wordpress
wordpress:
  autoscalling:
    enabled: true    
    min_replicas: 3   
    max_replicas: 20  
    avg_memory_utilization: 90  
    avg_cpu_utilization: 80 
  database:
    wordpress_db_name: wordpress_db 
  resources: 
    memory_limit: 256Mi 
    memory_requested: 128Mi 
    cpu_limit: 300m 
    cpu_requested: 100m 
  labels: 
    app.kubernetes.io/name: wordpress
    app.kubernetes.io/instance: wordpress-mainapp
    app.kubernetes.io/version: 1.0.0
    app.kubernetes.io/component: application
    app.kubernetes.io/part-of: wordpress
    app.kubernetes.io/managed-by: helm
    enviroment: production
    confidenciality: restrict
    compliance: none
 

Testando o Helm Package

A fim de entender melhor os pacotes e garantir que o artigo foi do Helm Package do zero no Kubernetes, veja como podemos fazer para testar e validar a construção real de um helm package. Os comandos lint e template do helm são fundamentais para a construção dos packages. O Lint gera informações relevantes sobre como está sendo construído o pacote e orienta sobre versões depreciadas, por exemplo. Já o comando helm template, como pode ser visto logo a seguir, cria um template.yaml com todos os manifestos com os valores substituídos.

$ helm lint

==> Linting .
[INFO] Chart.yaml: icon is recommended
[WARNING] templates/mysql/hpa.yaml: autoscaling/v2beta2 HorizontalPodAutoscaler is deprecated in v1.23+, unavailable in v1.26+; use autoscaling/v2 HorizontalPodAutoscaler
[WARNING] templates/wordpress/hpa.yaml: autoscaling/v2beta2 HorizontalPodAutoscaler is deprecated in v1.23+, unavailable in v1.26+; use autoscaling/v2 HorizontalPodAutoscaler

1 chart(s) linted, 0 chart(s) failed

helm template . > template.yaml