Saltar al contenido

Refactorizando

Programación, tutoriales y artículos

Menú principal

Refactorizando

  • Frameworks
    • Spring
    • Quarkus
    • Micronaut
    • Hibernate
  • Patrones y Arquitectura
  • Plataformas
    • Kubernetes
    • kafka
  • Base De Datos
  • Lenguajes
    • GraphQL
    • Kotlin
    • Java
  • Kubernetes
  • Plataformas

Como crear un Helm Chart para kubernetes

junio 21, 2021 Noel Rodríguez Calle
Ejemplo de Helm Chart

Ejemplo de Helm Chart


Gran parte de mi día lo solía gastar creando diferentes objetos de kubernetes, deployment, configmaps, secrets, services, etc… . Esta es una tarea algo tediosa y a veces repetitiva en la que te puedes equivocar fácilmente. Es en este momento y para este tipo de casos donde debemos hacer uso y crear un Helm Chart para Kubernetes. Ya que estos nos ayudarán y coordinarán la descarga, instalación y deployment de nuestras aplicaciones. En los siguientes puntos iremos viendo los pasos necesarios que nos ayudarán a ver como crear un Helm Chart para kubernetes.

¿Por que se debería usar Helm?

Sobre por qué deberíamos usar Helm, la respuesta es bastante fácil, por simplicidad y porque nos va a facilitar mucho el trabajo. Helm va a realizar la gestión de los deployment en kubernetes a través de templates. Helm nos da una estructura muy flexibe para que podamos ejecutar cualquier tipo de aplicación en nuestro clúster de Kubernetes. Incluso va a permitir realizar versionado de nuestros templates, de manera que podamos tener diferentes deployments de una manera sencilla y eficaz.

En el mundo del desarrollo y la infraestructura lo que hay que llevar a cabo es evitar realizar tareas manuales siempre y cuando sean posible, ya que estas nos podrán llevar a errores. Es por eso que, aplicando Helm chart podremos eliminar errores y realizar despliegues de una manera sencilla y segura.

Hands on

En este ejemplo vamos a crear un ejemplo de Helm con minikube. Pulsa aquí para instalar minikube y aquí para configurar e instalar Helm.

Si tenemos todo instalado y configurado vamos a comenzar arrancando nuestro minikube.

minikube start
Minikube start

Y a continuación vamos a inicializar la creación de un nuevo Helm chart con nombre chartexample:

helm create chartexample

Una vez creado podemos verificar los ficheros y carpetas creadas:

$ ls chartexample
charts  Chart.yaml  templates  values.yaml

Estructura de Helm Chart

Una vez hemos creado nuestro Helm con el comando anterior, veremos dos ficheros y dos carpetas. Vamos a ir viendo uno por uno.

Si abrimos Chart.yaml veremos lo siguiente:

apiVersion: v2
name: chartexample
description: A Helm chart for Kubernetes

# A chart can be either an 'application' or a 'library' chart.
#
# Application charts are a collection of templates that can be packaged into versioned archives
# to be deployed.
#
# Library charts provide useful utilities or functions for the chart developer. They're included as
# a dependency of application charts to inject those utilities and functions into the rendering
# pipeline. Library charts do not define any templates and therefore cannot be deployed.
type: application

# This is the chart version. This version number should be incremented each time you make changes
# to the chart and its templates, including the app version.
# Versions are expected to follow Semantic Versioning (https://semver.org/)
version: 0.1.0

# This is the version number of the application being deployed. This version number should be
# incremented each time you make changes to the application. Versions are not expected to
# follow Semantic Versioning. They should reflect the version the application is using.
# It is recommended to use it with quotes.
appVersion: "1.16.0"

En el fichero vemos una serie de atributos, empezando por la versión del API, el nombre del gráfico y una descripción. A continuación veremos el tipo de chart que tendremos que es application por defecto, y la versión del chart y de la aplicación.

Ahora pasamos a la carpeta /templates, que se podría decir que es en donde reside toda la lógica para poder realizar un despliegue de nuestra aplicación. Es la que contiene los ficheros de los objetos de kubernetes, si echas un vistazo,verás un deployment, ingress, un service, un service account, un horizontal pod autoscaler y una carpeta de tests.

Si continuamos explorando veremos una carpeta vacía que se llama charts. Esta carpeta nos será de gran utilidad para añadir charts que serán necesarios o que nuestra aplicación dependerá de ellos.

A continuación vamos a analizar donde reside la lógica y la configuración que hay que aplicar para generar un template, el fichero values.yaml.

Analizar fichero values.yaml en Helm Chart

El archivo values.yaml nos trae un formato de plantilla en el que podremos realizar la configuración de nuestros objetos de kubernetes.

# Default values for chartexample.
# This is a YAML-formatted file.
# Declare variables to be passed into your templates.

replicaCount: 1

image:
  repository: nginx
  pullPolicy: IfNotPresent
  # Overrides the image tag whose default is the chart appVersion.
  tag: ""

imagePullSecrets: []
nameOverride: ""
fullnameOverride: ""

serviceAccount:
  # Specifies whether a service account should be created
  create: true
  # Annotations to add to the service account
  annotations: {}
  # The name of the service account to use.
  # If not set and create is true, a name is generated using the fullname template
  name: ""

podAnnotations: {}

podSecurityContext: {}
  # fsGroup: 2000

securityContext: {}
  # capabilities:
  #   drop:
  #   - ALL
  # readOnlyRootFilesystem: true
  # runAsNonRoot: true
  # runAsUser: 1000

service:
  type: ClusterIP
  port: 80

ingress:
  enabled: false
  className: ""
  annotations: {}
    # kubernetes.io/ingress.class: nginx
    # kubernetes.io/tls-acme: "true"
  hosts:
    - host: chart-example.local
      paths:
        - path: /
          pathType: ImplementationSpecific
  tls: []
  #  - secretName: chart-example-tls
  #    hosts:
  #      - chart-example.local

resources: {}
  # We usually recommend not to specify default resources and to leave this as a conscious
  # choice for the user. This also increases chances charts run on environments with little
  # resources, such as Minikube. If you do want to specify resources, uncomment the following
  # lines, adjust them as necessary, and remove the curly braces after 'resources:'.
  # limits:
  #   cpu: 100m
  #   memory: 128Mi
  # requests:
  #   cpu: 100m
  #   memory: 128Mi

autoscaling:
  enabled: false
  minReplicas: 1
  maxReplicas: 100
  targetCPUUtilizationPercentage: 80
  # targetMemoryUtilizationPercentage: 80

nodeSelector: {}

tolerations: []

affinity: {}

En el fichero de configuración anterior podemos ver que se ha estructurado para poder añadir un servicio, un ingress, autoscaling, afinidad etc… .Vamos a ir analizando y definiendo cada parte de nuestro fichero values.yaml.

Configuración del Pod

La primera parte de nuestro fichero values contiene información referida a configuración del Pod.

El primer argumento que nos encontramos es replicaCount, el cual nos indica el número de réplicas que existirán del pod, por defecto lo establece a 1.

A continuación nos encontramos con la definición de la imagen, en la que por defecto define la imagen de nginx y la pullPolicy a IfNotPresent, la cual cambiaremos a always para nuestro ejemplo.

Secretos

A continuación nos encontramos con imagePullSecrets, en esta sección se podrá definir cualquier password o tokens.

Nombres

La siguiente sección que nos encontramos es la referida a nameOverride y fullnameOverride. En esta sección podremos cambiar el nombre del chart que hemos creado con el comando helm create.

Service Account

En la creación por defecto generará un service account basado en el nombre completo que hemos definido. Lo mejor y más recomendable es generar uno propio y definir los permisos que desees.

Seguridad

En la sección de securityContext y podSecurityContext, se van a definir límites sobre usuarios, o que grupos de archivos se pueden usar o no.

Red

La siguiente parte que vamos a ver es service e ingress. En cuanto a service, vamos a poder definir ClusterIP o NodePort. Este último es el que vamos a usar en nuestro ejemplo, ya que va a exponer el servicio en la dirección IP de cada nodo de kubernetes con un puerto fijo.

Y en cuanto a ingress, lo vamos a dejar por defecto a false.

Recurso

En la de sección de resources, vamos a definir los límites de los recursos a emplear. Por defecto viene vacío, pero lo recomendable es rellenarlo. En nuestro ejemplo vamos a definir 100m de CPU y 128Mi de memoria.

Autoescalado

En siguiente parámetro que nos encontramos es autoscaling, el cual se encuentra desactivado por defecto y una vez activado funcionará en función de unos parámetros.

Tolerations, node selectors, y affinities

A continuación veremos los últimos tres apartados que nos quedan, los cuales por defecto vienen vacíos.

Tal y como ya explícamos en algún artículo anterior, nodeSelector se utiliza cuando se va a asignar nuestra aplicación o pods a nodos específicos en nuestro clúster de kubernetes.

Tolerations y affinities, van a asegurarnos que nuestros pods se están ejecutando en diferentes nodos.

En nuestro ejemplo por simplicidad vamos a dejarlo con la configuración por defecto.

Hacer deploy con Helm

A continuación vamos a hacer deploy de un nginx con las modificaciones que hemos indicado anteriormente:

# Default values for chartexample.
# This is a YAML-formatted file.
# Declare variables to be passed into your templates.

replicaCount: 1

image:
  repository: nginx
  pullPolicy: Always
  # Overrides the image tag whose default is the chart appVersion.
  tag: ""

imagePullSecrets: []
nameOverride: ""
fullnameOverride: ""

serviceAccount:
  # Specifies whether a service account should be created
  create: true
  # Annotations to add to the service account
  annotations: {}
  # The name of the service account to use.
  # If not set and create is true, a name is generated using the fullname template
  name: ""

podAnnotations: {}

podSecurityContext: {}
  # fsGroup: 2000

securityContext: {}
  # capabilities:
  #   drop:
  #   - ALL
  # readOnlyRootFilesystem: true
  # runAsNonRoot: true
  # runAsUser: 1000

service:
  type: NodePort
  port: 80

ingress:
  enabled: false
  className: ""
  annotations: {}
    # kubernetes.io/ingress.class: nginx
    # kubernetes.io/tls-acme: "true"
  hosts:
    - host: chart-example.local
      paths:
        - path: /
          pathType: ImplementationSpecific
  tls: []
  #  - secretName: chart-example-tls
  #    hosts:
  #      - chart-example.local

resources: 
  # We usually recommend not to specify default resources and to leave this as a conscious
  # choice for the user. This also increases chances charts run on environments with little
  # resources, such as Minikube. If you do want to specify resources, uncomment the following
  # lines, adjust them as necessary, and remove the curly braces after 'resources:'.
  limits:
    cpu: 100m
    memory: 128Mi
  requests:
    cpu: 100m
    memory: 128Mi

autoscaling:
  enabled: false
  minReplicas: 1
  maxReplicas: 100
  targetCPUUtilizationPercentage: 80
  # targetMemoryUtilizationPercentage: 80

nodeSelector: {}

tolerations: []

affinity: {}

Para hacer un install con Helm usaremos el siguiente comando:

helm install helm-example chartexample/ --values chartexample/values.yaml

y si todo va bien debería mostrar la siguiente salida:

NAME: helm-example
LAST DEPLOYED: Fri Jun 11 13:17:17 2021
NAMESPACE: default
STATUS: deployed
REVISION: 1
NOTES:
1. Get the application URL by running these commands:
  export NODE_PORT=$(kubectl get --namespace default -o jsonpath="{.spec.ports[0].nodePort}" services helm-example-chartexample)
  export NODE_IP=$(kubectl get nodes --namespace default -o jsonpath="{.items[0].status.addresses[0].address}")
  echo http://$NODE_IP:$NODE_PORT

Una vez ejecutados los comandos anteriores deberíamos obtener la IP y el puerto de ejecución para ver la página de nginx:

Nginx con Helm | Como crear un Helm Chart para kubernetes
Nginx con Helm

Conclusión

A lo largo de este artículo sobre como crear un Helm Chart para kubernetes, hemos visto como podemos desplegar una aplicación haciendo uso de Helm y sus templates. Esto nos ayudará para tareas repetitivas o cuando tengamos que realizar despliegues de aplicaciones con características similares.

Otro ejemplo en el que hemos usado Helm es en el autoescalado con Spring Boot y Prometheus.


Tags: Deployment, helm, Helm Chart, nodeport, pod, resources, service account

Más historias

  • Devops
  • Kubernetes
  • Plataformas

Desplegar aplicaciones con ArgoCD en Kubernetes

mayo 3, 2022 Noel Rodríguez Calle
  • Frameworks
  • Java
  • Lenguajes
  • Plataformas
  • Spring

Introducción a Apache Pulsar en Spring Boot

febrero 28, 2022 Noel Rodríguez Calle
  • Frameworks
  • Java
  • kafka
  • Lenguajes
  • Plataformas
  • Spring
  • Uncategorized

KStream en Kafka Stream con Spring Boot

febrero 1, 2022 Noel Rodríguez Calle

Deja una respuesta Cancelar la respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Últimas entradas

  • Testing en aplicaciones con Quarkus
  • Desplegar aplicaciones con ArgoCD en Kubernetes
  • Ejemplo de Zeebe con Spring Boot en Docker
  • Crear anotaciones en Java
  • Configuración de Hikari en Spring Boot

Te pueden interesar

  • Frameworks
  • Quarkus

Testing en aplicaciones con Quarkus

mayo 16, 2022 Noel Rodríguez Calle
  • Devops
  • Kubernetes
  • Plataformas

Desplegar aplicaciones con ArgoCD en Kubernetes

mayo 3, 2022 Noel Rodríguez Calle
  • Frameworks
  • Patrones y Arquitectura
  • Spring

Ejemplo de Zeebe con Spring Boot en Docker

abril 28, 2022 Noel Rodríguez Calle
  • Java

Crear anotaciones en Java

abril 11, 2022 Noel Rodríguez Calle
  • Frameworks
  • Spring

Configuración de Hikari en Spring Boot

abril 8, 2022 Noel Rodríguez Calle
  • Facebook
  • Twitter
  • Instagram
  • Email
Refactorizando Copyright © Todos los derechos reservados.

Utilizamos cookies para ofrecerte la mejor experiencia en nuestra web.

Puedes aprender más sobre qué cookies utilizamos o desactivarlas en los ajustes.

Refactorizando
Powered by  GDPR Cookie Compliance
Resumen de privacidad

Esta web utiliza cookies para que podamos ofrecerte la mejor experiencia de usuario posible. La información de las cookies se almacena en tu navegador y realiza funciones tales como reconocerte cuando vuelves a nuestra web o ayudar a nuestro equipo a comprender qué secciones de la web encuentras más interesantes y útiles.

Cookies estrictamente necesarias

Las cookies estrictamente necesarias tiene que activarse siempre para que podamos guardar tus preferencias de ajustes de cookies.

Si desactivas esta cookie no podremos guardar tus preferencias. Esto significa que cada vez que visites esta web tendrás que activar o desactivar las cookies de nuevo.