Skip to content

Integración de Helm en RKE2: Gestión Avanzada de Despliegues


Introducción

Helm es la herramienta de gestión de paquetes más utilizada en entornos Kubernetes, permitiendo una gestión más eficiente y flexible de los despliegues mediante "charts". Los charts de Helm proporcionan una sintaxis de plantillas para los documentos YAML de Kubernetes, facilitando la creación de despliegues configurables en lugar de depender exclusivamente de archivos estáticos. Gracias a esto, Helm se convierte en una solución clave para simplificar la administración y configuración de recursos en clústeres Kubernetes.

En el contexto de RKE2, la integración con Helm no requiere configuraciones especiales, permitiendo a los administradores usar esta herramienta de manera nativa. Además, RKE2 ofrece funcionalidades adicionales que simplifican el despliegue de manifiestos y charts de Helm mediante recursos personalizados, proporcionando una forma más automatizada y eficiente de gestionar aplicaciones en el clúster.


Objetivo

Objetivo General:

  • Explorar y comprender la integración de Helm en entornos RKE2, abordando desde los conceptos básicos de Helm y su uso como herramienta de gestión de paquetes, hasta su funcionalidad avanzada en RKE2. Esto incluye la automatización del despliegue de manifiestos y charts de Helm, así como la administración de recursos personalizados mediante el controlador HelmChart. Al finalizar, los participantes tendrán las habilidades necesarias para implementar y gestionar despliegues dinámicos y configurables en clústeres RKE2 utilizando Helm.

Integración con Helm

Helm es la herramienta de gestión de paquetes preferida para Kubernetes. Los charts de Helm proporcionan una sintaxis de plantillas para los documentos YAML de manifiestos de Kubernetes. Con Helm, podemos crear despliegues configurables en lugar de utilizar únicamente archivos estáticos. Para más información sobre cómo crear tu propio catálogo de despliegues, consulta la documentación en Helm.

RKE2 no requiere ninguna configuración especial para utilizar las herramientas de línea de comandos de Helm. Solo asegúrate de haber configurado correctamente tu kubeconfig, según la sección sobre acceso al clúster. Además, RKE2 incluye funcionalidades adicionales que facilitan aún más el despliegue tanto de manifiestos de recursos tradicionales de Kubernetes como de charts de Helm mediante el CRD (Custom Resource Definition) rancher/helm-release.

Despliegue Automático de Manifiestos y Charts de Helm

Cualquier manifiesto de Kubernetes que se encuentre en el directorio /var/lib/rancher/rke2/server/manifests será desplegado automáticamente en RKE2 de una manera similar al comando kubectl apply, tanto durante el inicio del clúster como cuando el archivo se modifica en el disco. Sin embargo, eliminar archivos de este directorio no eliminará los recursos correspondientes del clúster.

Los manifiestos desplegados de esta manera se gestionan como recursos personalizados llamados AddOns, los cuales pueden visualizarse ejecutando el comando kubectl get addon -A. Por defecto, encontrarás AddOns para componentes empaquetados como CoreDNS, Nginx-Ingress y Metrics Server. Los AddOns son creados automáticamente por el controlador de despliegue y se nombran en función del nombre del archivo en el directorio de manifiestos.

También es posible desplegar charts de Helm como AddOns. RKE2 incluye un controlador de Helm (Helm Controller) que gestiona los charts utilizando un CRD llamado HelmChart.

Requisitos para el Nombre de Archivos

El nombre del AddOn para cada archivo en el directorio de manifiestos se deriva del nombre base del archivo. Asegúrate de que todos los archivos dentro del directorio de manifiestos (o en cualquier subdirectorio) tengan nombres únicos y que cumplan con las restricciones de nomenclatura de objetos de Kubernetes. También es importante evitar conflictos con los nombres ya utilizados por los componentes empaquetados predeterminados de RKE2, incluso si dichos componentes están deshabilitados.

Un ejemplo de un error que se reportaría si el nombre del archivo contiene guiones bajos (_):

Failed to process config: failed to process /var/lib/rancher/rke2/server/manifests/example_manifest.
yaml: Addon.k3s.cattle.io "example_manifest" is invalid: metadata.name: Invalid value:
"example_manifest": a lowercase RFC 1123 subdomain must consist of lower case alphanumeric
characters, '-' or '.', and must start and end with an alphanumeric character (e.g. 'example.com',
regex used for validation is '[a-z0-9]([-a-z0-9]*[a-z0-9])?(\\.[a-z0-9]([-a-z0-9]*[a-z0-9])?)*')

Esto significa que los nombres de los archivos deben consistir únicamente en caracteres alfanuméricos en minúsculas, guiones (-) o puntos (.), y deben comenzar y terminar con un carácter alfanumérico válido. Por ejemplo, nombres válidos serían example.com o my-addon.


Laboratorio: Despliegue Automático de Manifiestos - archivos YAML

Antes de comenzar

  • Contar con el acceso al ambiente de laboratorio
  • Haber realizado la validación de conexión y funcionamiento
  • Finalizar las prácticas de laboratorio de las instalaciones de RKE2.

  1. Establecer una sesión como el usuario student a lab-#-master.
    export LAB=X
    
    ssh student@lab-${LAB}-master 
    
  2. Cambiar al usuario root
    sudo -i
    
  3. Crear el siguiente archivo llamado hello-world-app-ns.yaml en la ubicación /var/lib/rancher/rke2/server/manifests.
    apiVersion: v1
    kind: Namespace
    metadata:
      name: hello-world-app
    
  4. Crear el siguiente archivo llamado hello-world-deploy.yaml en la ubicación /var/lib/rancher/rke2/server/manifests.
    apiVersion: apps/v1
    kind: Deployment
    metadata:
      namespace: hello-world-app
      name: hello-world-deploy
      labels:
        app: hello-world
    spec:
      replicas: 2
      selector:
        matchLabels:
          app: hello-world
      template:
        metadata:
          labels:
            app: hello-world
        spec:
          containers:
          - name: hello-world
            image: rancher/hello-world
            ports:
            - containerPort: 80
    
  5. Crear el siguiente archivo llamado hello-world-svc.yaml en la ubicación /var/lib/rancher/rke2/server/manifests.
    apiVersion: v1
    kind: Service
    metadata:
      namespace: hello-world-app
      name: hello-world-svc
      labels:
        app: hello-world
    spec:
      type: ClusterIP
      selector:
        app: hello-world
      ports:
      - protocol: TCP
        port: 80
        targetPort: 80
    
  6. Crear el siguiente archivo llamado hello-world-ing.yaml en la ubicación /var/lib/rancher/rke2/server/manifests.
    apiVersion: networking.k8s.io/v1
    kind: Ingress
    metadata:
      namespace: hello-world-app
      name: hello-world-ing
      annotations:
        nginx.ingress.kubernetes.io/ssl-redirect: "true"
    spec:
      ingressClassName: nginx
      tls:
      - hosts:
        - hello-world.apps.lab-0.mx-g01.ws.itmlabs.io
      rules:
      - host: hello-world.apps.lab-0.mx-g01.ws.itmlabs.io
        http:
          paths:
          - path: /hello
            pathType: Prefix
            backend:
              service:
                name: hello-world-svc
                port:
                  number: 80
          - path: /img
            pathType: Prefix
            backend:
              service:
                name: hello-world-svc
                port:
                  number: 80
    
  7. Validar que la sintáxis de los archivos creados anteriormente este correcta utilizando los siguientes comandos para cada archivo.

    yq /var/lib/rancher/rke2/server/manifests/hello-world-app-ns.yaml && echo $?
    
    yq /var/lib/rancher/rke2/server/manifests/hello-world-app-deploy.yaml && echo $?
    
    yq /var/lib/rancher/rke2/server/manifests/hello-world-app-svc.yaml && echo $?
    
    yq /var/lib/rancher/rke2/server/manifests/hello-world-app-ing.yaml && echo $?
    
    La salida de este comando deberá ser 0 en todos los casos.

  8. Todos los manifiestos de Kubernetes que se encuentren en /var/lib/rancher/rke2/server/manifests, se implementarán automáticamente en RKE2 de manera similar a kubectl apply, tanto al crear como cuando se modifica el archivo en el disco.
    IMPORTANTE: Eliminar archivos de este directorio no eliminará los recursos correspondientes del clúster.
    Puedes verificar la creación de los recursos ingresando a la consola web de Rancher Manager y explorando el cluster1 en el Namespace llamado hello-world-app.
    Rancher and RKE

  9. Los manifiestos implementados de esta manera se administran como recursos personalizados de complementos y se pueden ver ejecutando kubectl get addon -A. De manera predeterminada, encontrará complementos para componentes empaquetados como CoreDNS, Nginx-Ingress y Metrics Server.
    El deploy controller crea automáticamente los complementos y se les asigna un nombre según su nombre de archivo en el directorio de manifiestos.
    Verificar los addon con el siguiente comando, el cual puede ejecutarse desde el Shell de la consola web de Rancher Manager.

    kubectl get addon -A
    
    Rancher and RKE

  10. Para finalizar elimine todos los archivos creados anteriormente, puede utilizar el siguiente comando en el servidor Master.

    cd /var/lib/rancher/rke2/server/manifests/
    
    rm -f hello-world-app-ns.yaml hello-world-deploy.yaml hello-world-svc.yaml hello-world-ing.yaml
    

  11. Ingresando a la consola web de Rancher Manager y explorando el cluster1 en el Namespace llamado hello-world-app, puedes eliminarlo para terminar de limpiar el ambiente. Rancher and RKE Y luego confirmar la eliminación: Rancher and RKE La eliminación puede demorar unos minutos.


Laboratorio: Modificando componente de RKE2 utilizando Helm Controller

Este tema aborda la revisión del servicio Ingress Controller en un clúster RKE2, esencial para exponer aplicaciones al exterior. Se incluyen pasos para verificar los Pods desplegados desde Rancher Manager, etiquetar nodos específicos con kubectl, y configurar un archivo HelmChartConfig para personalizar la asignación de nodos del Ingress Controller.

Antes de comenzar

  • Contar con el acceso al ambiente de laboratorio
  • Haber realizado la validación de conexión y funcionamiento
  • Finalizar las prácticas de laboratorio de las instalaciones de RKE2.

  1. Establecer una sesión como el usuario student a lab-#-master
    export LAB=X
    
    ssh student@lab-${LAB}-master 
    
  2. Cambiar al usuario root
    sudo -i
    
  3. Verificar la ejecución del servicio de Ingress Controller actualmente en el cluster1, este servicio es el encargado de exponer las aplicaciones hace el mundo exterior de Kubernetes, en la configuración inicial del ambiente, se encuentra desplegado en los dos servidores Workers con que cuenta el cluster1. Puedes verificar la ejecución de los Pods actuales, ingresando a la consola web de Rancher Manager y explorando el cluster1 en Workloads, luego DaemonSets elige el que tiene el nombre rke2-ingress-nginx-controller, podrás comprobar que deben haber dos Pods del Ingress Controller, uno en cada nodo Worker: Rancher and RKE
  4. El Objetivo a cubrir en la presente guía, se centra en modificar la configuración actual del Ingress Controller y hacer que dicho componente se ejecute en un solo Nodo Worker, para este caso en el lab-0-node1.c.mx-g01.internal.
  5. Agregar el siguiente Label al servidor Worker 1 (lab-#-node1), asegurarse de utilizar el nombre del nodo que corresponde.
    kubectl label nodes lab-0-node1.c.mx-g01.internal ingress-ready=true
    
    La salida del comando anterior debe ser similar a la siguiente:
    node/lab-0-node1.c.mx-g01.internal labeled
    
  6. Ejecuta el siguiente comando para verificar que el nodo tiene el label:
    kubectl get nodes --show-labels | grep ingress-ready
    
    La salida del comando anterior debe ser similar a la siguiente:
    lab-0-node1.c.mx-g01.internal    Ready    <none> \
    3d15h   v1.30.5+rke2r1   beta.kubernetes.io/arch=amd64,beta.kubernetes.io/instance-type=rke2,beta.\
    kubernetes.io/os=linux,ingress-ready=true,kubernetes.io/arch=amd64,kubernetes.io/hostname=lab-0-node1.c.mx-g01.internal,\
    kubernetes.io/os=linux, \
    lab=cluster1,node.kubernetes.io/ \
    instance-type=rke2
    
  7. Crear el siguiente archivo llamado rke2-ingress-nginx-config.yaml en la ubicación /var/lib/rancher/rke2/server/manifests
    ---
    apiVersion: helm.cattle.io/v1
    kind: HelmChartConfig
    metadata:
      name: rke2-ingress-nginx
      namespace: kube-system
    spec:
      valuesContent: |-
        controller:
          nodeSelector:
            ingress-ready: "true"
    
  8. Verificar los nuevos recursos creados en el cluster: Verificar el nuevo AddOns:
    kubectl get addon -A | grep config
    
    La salida del comando anterior debe ser similar a la siguiente:
    kube-system   rke2-ingress-nginx-config \
    /var/lib/rancher/rke2/server/manifests/rke2-ingress-nginx-config.yaml \
    1915ec035f5e39f289344eb68def8c5b31c8691ca9e9e2fb124e71194608ec9a
    
    Verificar el nuevo HelmChartConfig:
    kubectl get helmchartconfig -A | grep nginx
    
    La salida del comando anterior debe ser similar a la siguiente:
    kube-system   rke2-ingress-nginx   8m33s
    
    Verificar el contenido del HelmChartConfig con el siguiente comando:
    kubectl get helmchartconfig rke2-ingress-nginx -n kube-system -o yaml
    
    La salida del comando anterior debe ser similar a la siguiente:
    apiVersion: helm.cattle.io/v1
    kind: HelmChartConfig
    metadata:
      annotations:
        objectset.rio.cattle.io/applied: H4sIAAAAAAAA/4TPwWrjMBDG8Vcxc7azUWw2jmAPSy4Leyz0lMtYmtiq5ZkgTdKGkHcvJgTaQ5qj9MFPf10AD+GVUg7CYGGgOC0cqkZaBPl1MlDCGNiDhX8Up+2ASbfC+9BDCRMpelQEewFkFkUNwnk+SvdGTjPpIgX5AoZZgvLhLu9MqepPI1gY6/wtpSz+B/Z//nov/JRgnAgspJFWVeA+Uc4V94E/KnfPfw7kA7pZGY8dVfmclSa4lhCxo/jjNwfMA1hoV2ZvDG3qpkW37FqHtWm8M/WmXnerZt39bpYtopnRh8Fw2x605AO5ueSE8Uh5K6zEChacsCaJkZLdcVGweHqhSE7ldlEU90cSoT/bYgeajrQDuF4/AwAA//8QbTMpFAIAAA
        objectset.rio.cattle.io/id: ""
        objectset.rio.cattle.io/owner-gvk: k3s.cattle.io/v1, Kind=Addon
        objectset.rio.cattle.io/owner-name: rke2-ingress-nginx-config
        objectset.rio.cattle.io/owner-namespace: kube-system
      creationTimestamp: "2024-11-21T15:07:41Z"
      generation: 1
      labels:
        objectset.rio.cattle.io/hash: 821f11e9348ac0b8ca314dc13937b247b6408aa1
      name: rke2-ingress-nginx
      namespace: kube-system
      resourceVersion: "399524"
      uid: 94d87805-c6bb-4088-8ae8-d8bb9eb91572
    spec:
      valuesContent: |-
        controller:
          nodeSelector:
            ingress-ready: "true"
    
  9. Puedes verificar la ejecución de los Pods luego de haber aplicado la nueva configuración, ingresando a la consola web de Rancher Manager y explorando el cluster1 en Workloads, luego DaemonSets elige el que tiene el nombre rke2-ingress-nginx-controller, podrás comprobar que la nueva configuración inicia un solo Pod del Ingress Controller, en el servidor que contiene el Label: ingress-ready=true. Rancher and RKE Como se puede comprobar en la imágen anterio, el componente de Ingress Controller, esta inicializado unicamente en en servidor lab-0-node1.c.mx-g01.internal. Lo anterior puede ser utilizado para aplicar diferentes configuraciones y cambiar el comportamiento de los componentes de Rancher Kubernetes Engine.
  10. Para regresar la configuración anterior, es necesario eliminar los recursos creados anteriormente, por lo que debes ejecutas los siguientes comandos. Para eliminar el recurso AddOn: rke2-ingress-nginx-config:
    kubectl delete addon rke2-ingress-nginx-config -n kube-system
    
    Para eliminar el recurso HelmChartConfig: rke2-ingress-nginx:
    kubectl delete helmchartconfig rke2-ingress-nginx -n kube-system
    
    Para eliminar el archivo YAML de la configuración:
    rm -f /var/lib/rancher/rke2/server/manifests/rke2-ingress-nginx-config.yaml
    
    Para eliminar el Label al servidor Worker 1 (lab-#-node1), asegurarse de utilizar el nombre del nodo que corresponde.
    kubectl label nodes lab-0-node1.c.mx-g01.internal ingress-ready-
    
  11. Asegurarse que la configuración del componente Ingress Controller en RKE2 se reestablece desde la consola web de Rancher Manager y explorando el cluster1 en Workloads, luego DaemonSets elige el que tiene el nombre rke2-ingress-nginx-controller, podrás comprobar que deben haber dos Pods del Ingress Controller, uno en cada nodo Worker: Rancher and RKE Fin del laboratorio.