cilium-kubernetes

Este rol de Ansible instala la red de Cilium en un clúster de Kubernetes. Utiliza el Helm chart oficial. Actualmente, se admiten procedimientos como la instalación, actualización y eliminación del despliegue de Cilium.

Versiones

Etiqueto cada lanzamiento y trato de seguir la numeración semántica. Si deseas utilizar el rol, te recomiendo que revises la última etiqueta. La rama principal es básicamente para desarrollo, mientras que las etiquetas marcan versiones estables. Una etiqueta como 13.0.0+1.15.3 significa que este es el lanzamiento 13.0.0 de este rol y contiene la versión 1.15.3 del chart de Cilium. Si el rol en sí cambia, X.Y.Z antes de + aumentará, y si cambia la versión del chart de Cilium, X.Y.Z después de + también aumentará. Esto permite etiquetar correcciones de errores y nuevas versiones importantes del rol mientras todavía se desarrolla para un lanzamiento específico de Cilium.

Requisitos

Necesitas tener instalado el binario de Helm 3 en el host donde se ejecuta ansible-playbook o en el host al que has delegado los playbooks (por ejemplo, usando la variable cilium_delegate_to). Puedes optar por:

• usar tu gestor de paquetes favorito si tu distribución incluye helm en su repositorio (por ejemplo, en Archlinux usa sudo pacman -S helm)
• o usar uno de los roles de Ansible Helm (por ejemplo, helm - que también se instala si usas ansible-galaxy role install -vr requirements.yml)
• o descargar directamente el binario desde Helm releases y ponerlo en el directorio /usr/local/bin/.

También se necesita un KUBECONFIG correctamente configurado (que por defecto se encuentra en ${HOME}/.kube/config). Normalmente, si kubectl funciona con tu clúster, entonces todo debería estar bien en este aspecto.

Además, es necesario instalar la colección kubernetes.core de Ansible. Esto se puede hacer usando el archivo collections.yml incluido en este rol: ansible-galaxy install -r collections.yml.

Y, por supuesto, necesitas un clúster de Kubernetes ;-)

Instalación

• Descarga directamente desde Github (cambia al directorio de roles de Ansible antes de clonar. Puedes averiguar la ruta del rol usando el comando ansible-config dump | grep DEFAULT_ROLES_PATH): git clone https://github.com/githubixx/ansible-role-cilium-kubernetes.git githubixx.cilium_kubernetes

• A través del comando ansible-galaxy y descarga directamente de Ansible Galaxy: ansible-galaxy install role githubixx.cilium_kubernetes

• Crea un archivo requirements.yml con el siguiente contenido (esto descargará el rol de Github) e instala con ansible-galaxy role install -r requirements.yml (cambia version si es necesario):

---
roles:
  - name: githubixx.cilium_kubernetes
    src: https://github.com/githubixx/ansible-role-cilium-kubernetes.git
    version: 13.0.0+1.15.3

Registro de cambios

Historial de cambios:

Consulta el CHANGELOG.md completo.

Cambios recientes:

13.0.0+1.15.3

Cambios importantes

• cambios en templates/cilium_values_default.yml.j2:
  • añadido kubeProxyReplacement, nodePort y socketLB (esto es necesario porque el enmascaramiento de BPF requiere NodePort)

Actualización

• actualización a Cilium v1.15.3

Molecule

• sustituir las cajas de Vagrant generic/ubuntu2204 por alvistack/ubuntu-22.04

12.0.0+1.15.0

• actualización a Cilium v1.15.0
• reorganización de la configuración de Molecule
• introducción de la variable cilium_chart_values_directory

Variables del rol

# Versión del Helm chart
cilium_chart_version: "1.15.3"

# Nombre del Helm chart
cilium_chart_name: "cilium"

# URL del Helm chart
cilium_chart_url: "https://helm.cilium.io/"

# Espacio de nombres de Kubernetes donde se deben instalar los recursos de Cilium
cilium_namespace: "cilium"

# Directorio que contiene el archivo de valores del chart de Helm. Ansible intentará localizar
# un archivo llamado "values.yml.j2" o "values.yaml.j2" en el directorio especificado
# (".j2" porque puedes usar la sintaxis habitual de plantillas Jinja2).
# Si no se encuentra, se utilizará el "templates/cilium_values_default.yml.j2" por defecto
# (que se puede usar como plantilla, por cierto). El contenido de este archivo
# se proporcionará al comando "helm install/template" como archivo de valores.
cilium_chart_values_directory: "/tmp/cilium/helm"

# Configuraciones de etcd. Si la variable "cilium_etcd_enabled" está definida y establecida en "true",
# se generan y despliegan las configuraciones de etcd de Cilium. De lo contrario, todas las siguientes
# configuraciones de "cilium_etcd_*" serán ignoradas.
#
cilium_etcd_enabled: "true"

# Interfaz donde escuchan los demonios de etcd. Si los demonios de etcd están vinculados a
# una interfaz de WireGuard, esta configuración debería ser "wg0" (por defecto) e.g.
# También puedes usar una variable como "{{ etcd_interface }}" si usaste
# mi rol de etcd (https://github.com/githubixx/ansible-role-etcd)
cilium_etcd_interface: "eth0"

# Puerto donde escuchan los demonios de etcd
cilium_etcd_client_port: 2379

# Grupo de host de etcd de Ansible en el archivo "hosts" de Ansible. Este valor se utiliza en
# la plantilla "templates/cilium_values_default.yml.j2" para determinar las direcciones IP
# de los hosts donde escuchan los demonios de etcd.
cilium_etcd_nodes_group: "k8s_etcd"

# Si esta variable está definida, se instalará un secreto de Kubernetes que
# contiene los archivos de certificado definidos en "cilium_etcd_cafile",
# "cilium_etcd_certfile" y "cilium_etcd_keyfile"
#
# Esto provoca que se establezca una conexión segura (https) a etcd.
# Esto, por supuesto, requiere que etcd esté configurado para usar SSL/TLS.
#
# Si este valor no está definido (por ejemplo, comentado) se ignorarán el resto de
# configuraciones "cilium_etcd_*" a continuación y se establecerá una conexión a etcd
# sin seguridad a través de "http".
cilium_etcd_secrets_name: "cilium-etcd-secrets"

# Dónde encontrar los archivos de certificado definidos a continuación. Si utilizaste mi
# rol de Autoridad de Certificación de Kubernetes (https://github.com/githubixx/ansible-role-kubernetes-ca)
# es posible que ya tengas definida la variable "k8s_ca_conf_directory" que puedes
# reutilizar aquí. Este rol también genera los archivos de certificado que pueden
# ser utilizados para las variables a continuación.
# Por defecto, será "$HOME/k8s/certs" del usuario actual que ejecuta el
# comando "ansible-playbook".
cilium_etcd_cert_directory: "{{ '~/k8s/certs' | expanduser }}"

# Archivo de la autoridad de certificado de etcd (el archivo se buscará en "cilium_etcd_cert_directory")
cilium_etcd_cafile: "ca-etcd.pem"

# Archivo de certificado de etcd (el archivo se buscará en "cilium_etcd_cert_directory")
# Asegúrate de que el certificado contenga las direcciones IP en el "Nombre Alternativo de Sujeto"
# (SAN) de las interfaces donde escuchan los demonios de etcd
# (esa es la dirección IP de las interfaces definidas en "cilium_etcd_interface").
# Esto ya se maneja por mi rol de Autoridad de Certificación de Kubernetes
# (https://github.com/githubixx/ansible-role-kubernetes-ca) si usaste ese rol.
cilium_etcd_certfile: "cert-cilium.pem"

# Archivo de clave del certificado de etcd (el archivo se buscará en "cilium_etcd_cert_directory")
cilium_etcd_keyfile: "cert-cilium-key.pem"

# Por defecto, todas las tareas que necesitan comunicarse con el clúster de Kubernetes
# se ejecutan en tu host local (127.0.0.1). Pero si este no tiene conexión directa
# a este clúster o debe ejecutarse en otro lugar, esta variable se puede cambiar
# en consecuencia.
cilium_delegate_to: 127.0.0.1

# Muestra el comando "helm" que se ejecutó si una tarea utiliza Helm para
# instalar, actualizar o eliminar dicho recurso.
cilium_helm_show_commands: false

# Sin la variable "cilium_action" definida, este rol solo generará un archivo
# con todos los recursos que se instalarán o actualizarán. El archivo generado
# con los recursos se llamará "template.yml" y se colocará en la carpeta especificada
# a continuación.
cilium_template_output_directory: "{{ '~/cilium/template' | expanduser }}"

Uso

Lo primero que debes hacer es revisar templates/cilium_values_default.yml.j2. Este archivo contiene los valores/configuraciones para el Helm chart de Cilium que son diferentes a los valores por defecto que se encuentran aquí. Los valores por defecto de este rol de Ansible usan un clúster etcd habilitado para TLS. Si tienes un clúster de Kubernetes autoalojado o bare metal, es probable que ya haya un clúster etcd en funcionamiento para el servidor de API de Kubernetes, que es mi caso. Estoy usando mi rol de Ansible etcd para instalar dicho clúster de etcd y mi rol de Autoridad de Certificación de Kubernetes para generar los certificados. Así que si usaste mis roles, puedes usar este rol de Cilium prácticamente tal cual.

La plantilla templates/cilium_values_default.yml.j2 también contiene algunas cláusulas if para usar un clúster etcd que no está habilitado para TLS. Consulta defaults/main.yml para ver qué valores se pueden cambiar. También puedes introducir tus propias variables. Para usar tus propios valores, simplemente crea un archivo llamado values.yml.j2 o values.yaml.j2 y colócalo en el directorio especificado en cilium_chart_values_directory. Luego, este rol usará ese archivo para renderizar los valores de Helm.

Después de que el archivo de valores esté en su lugar y se hayan revisado los valores de defaults/main.yml, se puede instalar el rol. La mayoría de las tareas del rol se ejecutan localmente por defecto, porque varias tareas necesitan comunicarse con el servidor de API de Kubernetes o ejecutar comandos de Helm. Pero puedes delegar este tipo de tareas a otro host usando la variable cilium_delegate_to (ver arriba). Asegúrate de que el host al que delegues este tipo de tareas tenga conexión al servidor de API de Kubernetes y que el usuario tenga un archivo KUBECONFIG válido.

La acción por defecto es renderizar el archivo YAML de recursos de Kubernetes después de reemplazar todas las variables y cosas así de Jinja2. En la sección Example Playbook a continuación hay un Example 2 (asignar etiqueta al rol). El rol githubixx.cilium_kubernetes tiene una etiqueta role-cilium-kubernetes asignada. Suponiendo que los valores para el Helm chart deben ser renderizados (nada se instalará en este caso) y el playbook se llama k8s.yml, ejecuta el siguiente comando:

ansible-playbook --tags=role-cilium-kubernetes k8s.yml

Para renderizar la plantilla en un directorio diferente, utiliza la variable cilium_template_output_directory, por ejemplo:

ansible-playbook --tags=role-cilium-kubernetes --extra-vars cilium_template_output_directory="/tmp/cilium" k8s.yml

Si deseas ver los comandos helm y los parámetros que se ejecutaron en los registros, también puedes especificar --extra-vars cilium_helm_show_commands=true.

Una de las tareas finales se llama TASK [githubixx.cilium_kubernetes : Write templates to file]. Esto renderiza la plantilla con los recursos que se crearán en el directorio especificado en cilium_template_output_directory. El archivo se llamará template.yml. El directorio/archivo se colocará en tu máquina local para poder inspeccionarlo.

Si la salida renderizada contiene todo lo que necesitas, se puede instalar el rol, lo que finalmente despliega Cilium:

ansible-playbook --tags=role-cilium-kubernetes --extra-vars cilium_action=install k8s.yml

Para comprobar si todo se ha desplegado, utiliza los comandos kubectl habituales como kubectl -n <cilium_namespace> get pods -o wide.

Como Cilium emite actualizaciones/mejoras cada pocas semanas/meses, el rol también puede hacer actualizaciones. El rol básicamente ejecuta lo que se describe en la guía de actualización de Cilium. Eso significa que se instalará la verificación previa de Cilium y se ejecutarán algunas comprobaciones antes de que se produzca realmente la actualización. Echa un vistazo a tasks/upgrade.yml para ver qué sucede antes, durante y después de la actualización. Por supuesto, debes consultar la guía de actualización de Cilium en general para verificar cambios importantes y cosas así antes de actualizar. ¡También asegúrate de revisar las Notas de actualización!

Si una actualización no fue exitosa, se puede iniciar un rollback a una versión anterior simplemente cambiando la variable cilium_chart_version. Pero definitivamente deberías leer la guía de rollback de Cilium. Cambiar entre versiones menores normalmente no es un problema, pero cambiar de una versión importante a una anterior puede no ser tan fácil.

También revisa templates/cilium_values_default_pre_flight_check.yml.j2. Si necesitas ajustar valores para la verificación previa, puedes cambiar ese archivo o crear un archivo templates/cilium_values_user_pre_flight_check.yml.j2 con tus propios valores.

Antes de hacer la actualización, básicamente solo necesitas cambiar la variable cilium_chart_version, por ejemplo, de 1.13.4 a 1.14.5 para actualizar de 1.13.4 a 1.14.5. Así que, para realizar la actualización, ejecuta

ansible-playbook --tags=role-cilium-kubernetes --extra-vars cilium_action=upgrade k8s.yml

Como se mencionó anteriormente, el rol ya incluye algunas comprobaciones para asegurarse de que la actualización se realice sin problemas, pero nuevamente deberías comprobar con kubectl si todo funciona como se espera después de la actualización.

Y, finalmente, si deseas deshacerte de Cilium, puedes eliminar todos los recursos nuevamente:

ansible-playbook --tags=role-cilium-kubernetes --extra-vars cilium_action=delete k8s.yml

Si no tienes ningún complemento CNI configurado, esto ocasionará que el proceso kubelet en los nodos de trabajo de Kubernetes emita errores de CNI de vez en cuando, ya que no hay más cosas relacionadas con CNI, y por supuesto, la conectividad entre pods en diferentes hosts desaparecerá junto con cualquier política de red y cosas así.

Ejemplo de Playbook

Ejemplo 1 (sin etiqueta de rol):

- hosts: k8s_worker
  roles:
    - githubixx.cilium_kubernetes

Ejemplo 2 (asignar etiqueta al rol):

-
  hosts: k8s_worker
  roles:
    -
      role: githubixx.cilium_kubernetes
      tags: role-cilium-kubernetes

Pruebas

Este rol tiene una pequeña configuración de prueba que se crea usando Molecule, libvirt (vagrant-libvirt) y QEMU/KVM. Consulta mi publicación de blog Probando roles de Ansible con Molecule, libvirt (vagrant-libvirt) y QEMU/KVM para saber cómo configurarlo. La configuración de prueba está aquí.

Después de eso, se puede ejecutar Molecule. El siguiente comando hará una configuración básica y creará una plantilla de los recursos (acción por defecto, ver arriba) que se crearán:

molecule converge

Instala Cilium y los recursos requeridos. Esto configurará algunas máquinas virtuales (VM) e instalará un clúster de Kubernetes. Esa configuración se utilizará para instalar Cilium usando este rol.

molecule converge -- --extra-vars cilium_action=install

El siguiente comando se puede usar para instalar CoreDNS para cosas de DNS de Kubernetes y para marcar controladores de nodos para ejecutar solo pods de Cilium:

molecule converge -- --extra-vars cilium_setup_networking=install

Actualizar Cilium o cambiar parámetros:

molecule converge -- --extra-vars cilium_action=upgrade

Eliminar Cilium y sus recursos:

molecule converge -- --extra-vars cilium_action=delete

Para ejecutar algunas pruebas, usa (opcionalmente añade -v para más salida):

molecule verify

Para limpiar, ejecuta

molecule destroy

Licencia

GNU GENERAL PUBLIC LICENSE Versión 3

Información del autor

http://www.tauceti.blog