El clúster de gestión es un despliegue único en una sola ubicación. El aprovisionamiento basado en imágenes agrupa todos los componentes en una única imagen arrancable. De este modo, el clúster de gestión se iniciará por sí mismo, lo que requiere una complejidad operativa mínima. Es la forma más sencilla y directa de ponerlo en marcha.

Los clústeres descendentes, sin embargo, son otra historia. En entornos de telecomunicaciones, se despliegan a gran escala en muchos centros de datos y en sitios edge, a menudo sin disponer de experiencia técnica in situ. El aprovisionamiento de red dirigido está diseñado para esto: requiere que los servidores de destino admitan una interfaz de gestión fuera de banda como Redfish, a través de la cual el clúster de gestión enciende, inspecciona y aprovisiona de forma remota los nodos bare-metal sin ninguna intervención in situ.

Integrar toda la configuración específica del clúster en una imagen de arranque, como requeriría el aprovisionamiento basado en imágenes, significa que cada variación del sitio exige una imagen diferente, y cualquier cambio de configuración requiere reconstruir y redistribuir las imágenes en todos los sitios. El aprovisionamiento de red dirigido resuelve esto manteniendo la imagen del SO genérica y gestionando toda la configuración específica del clúster, incluidos los perfiles de red, Kubernetes y Telco, desde el clúster de gestión en el momento del aprovisionamiento. Los operadores simplemente instalan en rack, encienden y conectan el hardware, y el clúster de gestión se encarga del resto.

Esta separación también permite una integración completa de GitOps. Dado que toda la definición del clúster en sentido descendente se expresa como manifiestos de Cluster API, puede almacenarse en Git y ser reconciliada por Fleet en todos los sitios, lo que hace que las operaciones de aprovisionamiento, configuración y ciclo de vida sean totalmente auditables y repetibles sin intervención manual.

Uso de Edge Image Builder (Capítulo 12, Edge Image Builder) para crear una nueva imagen ISO con la pila de gestión incluida. A continuación, puede utilizar esta imagen ISO para instalar un nuevo clúster de gestión en máquinas virtuales o en equipo sin sistema operativo.

Nota

Para obtener más información sobre cómo desplegar un nuevo clúster de gestión, consulte la guía del clúster de gestión de SUSE Telco Cloud (Parte V, “Configuración del clúster de gestión”).

Nota

Para obtener más información sobre cómo utilizar Edge Image Builder, consulte la guía de Edge Image Builder (Capítulo 5, Clústeres independientes con Edge Image Builder).

Una vez que tengamos el clúster de gestión en funcionamiento, podemos utilizarlo para desplegar un clúster en sentido descendente de nodo único con todas las capacidades de Telco habilitadas y configuradas utilizando el flujo de trabajo de aprovisionamiento de red dirigido.

El siguiente diagrama muestra el flujo de trabajo de alto nivel para desplegarlo:

Nota

Para obtener más información sobre cómo desplegar un clúster en sentido descendente, consulte la guía de aprovisionamiento automatizado de SUSE Telco Cloud. (Parte VII, “Aprovisionamiento de red dirigido totalmente automatizado”)

Nota

Para obtener más información sobre las funciones de Telco, consulte la guía de funciones de Telco de SUSE Telco Cloud. (Parte VI, “Configuración de las funciones Telco”)

Una vez que tengamos el clúster de gestión en funcionamiento, podemos utilizarlo para desplegar un clúster de alta disponibilidad en sentido descendente con MetalLB como equilibrador de carga utilizando el flujo de trabajo de aprovisionamiento de red dirigida.

El siguiente diagrama muestra el flujo de trabajo de alto nivel para desplegarlo:

Nota

Para obtener más información sobre cómo desplegar un clúster en sentido descendente, consulte la guía de aprovisionamiento automatizado de SUSE Telco Cloud. (Parte VII, “Aprovisionamiento de red dirigido totalmente automatizado”)

Nota

Para obtener más información sobre MetalLB, consulte aquí: (Capítulo 17, MetalLB)

Este método es útil para escenarios en los que el hardware de destino admite la gestión fuera de banda y se desea un flujo de gestión de infraestructura totalmente automatizado.

Se configura un clúster de gestión para proporcionar APIs declarativas que permitan la gestión del inventario y del estado de los servidores de equipo sin sistema operativo del clúster descendente, incluida la inspección, limpieza y aprovisionamiento/desaprovisionamiento automatizados.

Existen algunas restricciones específicas relacionadas con el hardware y la red del servidor del clúster descendente:

Se requieren algunas herramientas; estas pueden instalarse en el clúster de gestión o en un host que pueda acceder a él.

La Documentación del clúster de gestión de SUSE Telco Cloud (Parte V, “Configuración del clúster de gestión”) contiene ejemplos de un uso más avanzado de Metal³ para casos de uso de telecomunicaciones.

global:
  ironicIP: <MANAGEMENT_CLUSTER_IP>
metal3-ironic:
  service:
    type: NodePort

global:
  enable_vmedia_tls: false

kubectl get secret -n metal3-system ironic-vmedia-cert -o yaml

metal3-ironic:
  persistence:
    ironic:
      size: "5Gi"

Como EIB se ejecuta dentro de un contenedor, necesitamos montar un directorio de configuración desde el host, lo que le permite especificar la configuración deseada, y durante el proceso de compilación EIB tiene acceso a cualquier archivo de entrada y artefacto de soporte necesario. Este directorio debe seguir una estructura específica. Vamos a crearlo, asumiendo que este directorio existirá en su directorio personal y se llamará "eib":

export CONFIG_DIR=$HOME/eib
mkdir -p $CONFIG_DIR/base-images

En el paso anterior creamos un directorio "base-images" que albergará la imagen de entrada de SUSE Linux Micro 6.2, asegurémonos de que la imagen se copie al directorio de configuración:

cp /path/to/SL-Micro.x86_64-6.2-Base-SelfInstall-GM.install.iso $CONFIG_DIR/base-images/slemicro.iso

Nota

Durante la ejecución de EIB, la imagen base original no se modifica; se crea una versión nueva y personalizada con la configuración deseada en la raíz del directorio de configuración de EIB.

El directorio de configuración en este punto debería tener el siguiente aspecto:

└── base-images/
    └── slemicro.iso

El archivo de definición describe la mayoría de las opciones configurables que admite Edge Image Builder. Puede encontrar un ejemplo completo de opciones aquí, y le recomendamos que eche un vistazo a la guía de creación de imágenes upstream para obtener ejemplos más completos que el que vamos a analizar a continuación. Comencemos con un archivo de definición muy básico para nuestra imagen de SO:

cat << EOF > $CONFIG_DIR/iso-definition.yaml
apiVersion: 1.3
image:
  imageType: iso
  arch: x86_64
  baseImage: slemicro.iso
  outputImageName: eib-image.iso
EOF

Esta definición especifica que estamos generando una imagen de salida para un sistema basado en AMD64/Intel 64. La imagen que se utilizará como base para modificaciones posteriores es una imagen iso llamada slemicro.iso, que se espera que esté ubicada en $CONFIG_DIR/base-images/slemicro.iso. También describe que, una vez que EIB termine de modificar la imagen, la imagen de salida se llamará eib-image.iso y, de forma predeterminada, residirá en $CONFIG_DIR.

Ahora nuestra estructura de directorios debería tener este aspecto:

├── iso-definition.yaml
└── base-images/
    └── slemicro.iso

En las siguientes secciones veremos algunos ejemplos de operaciones comunes:

apiVersion: 1.3
image:
  imageType: iso
  arch: x86_64
  baseImage: slemicro.iso
  outputImageName: eib-Base-RT-SelfInstall.iso
operatingSystem:
  isoConfiguration:
    installDevice: /dev/disk/by-id/ata-QEMU_HARDDISK_111-disk1 # first defined disk

5.3.2 Configuración de usuarios del SO #

 

EIB le permite preconfigurar usuarios con información de inicio de sesión, como contraseñas o claves SSH, incluida la configuración de una contraseña de root fija. Como parte de este ejemplo, vamos a fijar la contraseña de root, y el primer paso es utilizar OpenSSL para crear una contraseña cifrada de una sola vía:

openssl passwd -6 SecurePassword

Esto generará algo similar a:

$6$G392FCbxVgn[...]Y7zTXnC1

A continuación, podemos añadir una sección en el archivo de definición llamada operatingSystem con una matriz users en su interior. El archivo resultante debería tener este aspecto:

apiVersion: 1.3
image:
  imageType: iso
  arch: x86_64
  baseImage: slemicro.iso
  outputImageName: eib-image.iso
operatingSystem:
  users:
    - username: root
      encryptedPassword: $6$G392FCbxVgn[...]Y7zTXnC1

Nota

También es posible añadir usuarios adicionales, crear los directorios de inicio, establecer los ID de usuario, añadir autenticación mediante claves SSH y modificar la información de los grupos. Consulte la guía de compilación de imágenes upstream para obtener más ejemplos.

5.3.3 Configuración de la hora del SO #

 

La sección time es opcional, pero se recomienda encarecidamente configurarla para evitar posibles problemas con los certificados y el desfase del reloj. EIB configurará chronyd y /etc/localtime dependiendo de los parámetros aquí indicados.

operatingSystem:
  time:
    timezone: Europe/London
    ntp:
      forceWait: true
      pools:
        - 2.suse.pool.ntp.org
      servers:
        - 10.0.0.1
        - 10.0.0.2

• El timezone especifica la zona horaria en el formato "Región/Localidad" (p. ej. "Europe/London"). La lista completa se puede encontrar ejecutando timedatectl list-timezones en un sistema Linux.

• ntp - Define los atributos relacionados con la configuración de NTP (usando chronyd):

• forceWait - Solicita que chronyd intente sincronizar las fuentes de tiempo antes de iniciar otros servicios, con un tiempo de espera de 180 s.

• pools - Especifica una lista de grupos que chronyd utilizará como fuentes de datos (usando iburst para mejorar el tiempo necesario para la sincronización inicial).

• servers - Especifica una lista de servidores que chronyd utilizará como fuentes de datos (usando iburst para mejorar el tiempo necesario para la sincronización inicial).

Nota

Los valores proporcionados en este ejemplo son solo para fines ilustrativos. Ajústelos para que se adapten a sus requisitos específicos.

.
├── definition.yaml
└── certificates
    ├── my-ca.pem
    └── my-ca.crt

5.3.5 Añadir archivos de sistema operativo #

 

Los archivos colocados en el directorio os-files dentro del directorio de configuración de la imagen se copian automáticamente en el sistema de archivos de la imagen compilada. El directorio exacto se conservará cuando se copien. Por ejemplo, si un archivo existe en un subdirectorio llamado os-files/etc, se coloca en el directorio /etc de la imagen compilada.

Nota

Si el directorio os-files existe, no puede estar vacío.

.
├── definition.yaml
└── os-files
    └── etc
        └── ssh
            └── sshd_config

5.3.6 Configuración de paquetes RPM #

 

Una de las principales características de EIB es proporcionar un mecanismo para añadir paquetes de software adicionales a la imagen, de modo que cuando finalice la instalación, el sistema pueda aprovechar los paquetes instalados de inmediato. EIB permite a los usuarios especificar lo siguiente:

• Paquetes por su nombre dentro de una lista en la definición de la imagen

• Repositorios de red en los que buscar estos paquetes

• Credenciales del SUSE Customer Center (SCC) para buscar en los repositorios oficiales de SUSE los paquetes enumerados

• A través de un directorio $CONFIG_DIR/rpms, cargar paquetes RPM personalizados que no existen en los repositorios de red

• A través del mismo directorio ($CONFIG_DIR/rpms/gpg-keys), claves GPG para permitir la validación de paquetes de terceros

EIB llevará a cabo entonces un proceso de resolución de paquetes durante el tiempo de compilación de la imagen, tomando la imagen base como entrada, e intentará extraer e instalar todos los paquetes suministrados, ya sea especificados a través de la lista o proporcionados localmente. EIB descarga todos los paquetes, incluidas las dependencias, en un repositorio que existe dentro de la imagen de salida e indica al sistema que los instale durante el primer proceso de arranque. Realizar este proceso durante la compilación de la imagen garantiza que los paquetes se instalarán correctamente durante el primer arranque en la plataforma deseada, por ejemplo, el nodo en el extremo. Esto también es ventajoso en entornos en los que desea integrar los paquetes adicionales en la imagen en lugar de extraerlos a través de la red cuando están en funcionamiento, por ejemplo, para entornos aislados o con red restringida.

Como ejemplo sencillo para demostrar esto, vamos a instalar el paquete RPM nvidia-container-toolkit que se encuentra en el repositorio de NVIDIA compatible con proveedores externos:

  packages:
    packageList:
      - nvidia-container-toolkit
    additionalRepos:
      - url: https://nvidia.github.io/libnvidia-container/stable/rpm/x86_64

El archivo de definición resultante tiene el siguiente aspecto:

apiVersion: 1.3
image:
  imageType: iso
  arch: x86_64
  baseImage: slemicro.iso
  outputImageName: eib-image.iso
operatingSystem:
  users:
    - username: root
      encryptedPassword: $6$G392FCbxVgn[...]Y7zTXnC1
  packages:
    packageList:
      - nvidia-container-toolkit
    additionalRepos:
      - url: https://nvidia.github.io/libnvidia-container/stable/rpm/x86_64

Lo anterior es un ejemplo sencillo, pero para mayor exhaustividad, descargue la clave de firma del paquete NVIDIA antes de ejecutar la generación de la imagen:

$ mkdir -p $CONFIG_DIR/rpms/gpg-keys
$ curl -fsSL https://nvidia.github.io/libnvidia-container/gpgkey > $CONFIG_DIR/rpms/gpg-keys/nvidia.gpg

Aviso

La adición de RPM adicionales mediante este método está pensada para la incorporación de componentes de terceros compatibles o paquetes suministrados (y mantenidos) por el usuario; este mecanismo no debe utilizarse para añadir paquetes que normalmente no serían compatibles con SUSE Linux Micro. Si se utiliza este mecanismo para añadir componentes de repositorios de openSUSE (que no son compatibles), incluidos los de versiones o paquetes de servicio más recientes, puede acabar con una configuración no compatible, especialmente cuando la resolución de dependencias da lugar a la sustitución de partes fundamentales del sistema operativo, aunque el sistema resultante pueda parecer que funciona como se espera. Si no está seguro, póngase en contacto con su representante de SUSE para obtener ayuda a la hora de determinar la compatibilidad de la configuración que desea.

Nota

Puede encontrar una guía más completa con ejemplos adicionales en la guía de instalación de paquetes en sentido ascendente.

5.3.7 Configuración del clúster de Kubernetes y de las cargas de trabajo de los usuarios #

 

Otra característica de EIB es la capacidad de utilizarlo para automatizar el despliegue de clústeres de Kubernetes de alta disponibilidad tanto de nodo único como de varios nodos que se "inician en el lugar" (es decir, que no requieren ningún tipo de infraestructura de gestión centralizada para coordinarse). El principal motor de este enfoque son los despliegues en entornos aislados o en entornos con red restringida, pero también sirve para iniciar clústeres independientes de forma rápida, incluso si se dispone de acceso completo y sin restricciones a la red.

Este método permite no solo el despliegue del sistema operativo personalizado, sino también la capacidad de especificar la configuración de Kubernetes, cualquier componente en capas adicional mediante charts de Helm y cualquier carga de trabajo del usuario mediante los manifiestos de Kubernetes suministrados. Sin embargo, el principio de diseño detrás de este método es asumir por defecto que el usuario desea un entorno aislado. Por lo tanto, cualquier elemento especificado en la definición de la imagen se incluirá en la imagen, lo que incluye las cargas de trabajo suministradas por el usuario. EIB garantiza que todas las imágenes detectadas que requieran las definiciones se copien localmente y sean servidas por el registro de imágenes integrado en el sistema desplegado resultante.

En este siguiente ejemplo, vamos a tomar nuestra definición de imagen existente y especificaremos una configuración de Kubernetes (en este ejemplo no se enumeran los sistemas ni sus funciones, por lo que asumimos por defecto que se trata de un solo nodo), lo que indicará a EIB que aprovisione un clúster de Kubernetes RKE2 de un solo nodo. Para mostrar la automatización tanto del despliegue de cargas de trabajo suministradas por el usuario (mediante manifiesto) como de los componentes en capas (mediante Helm), vamos a instalar KubeVirt a través del chart de Helm SUSE Telco Cloud, así como NGINX mediante un manifiesto de Kubernetes. La configuración adicional que debemos añadir a la definición de imagen existente es la siguiente:

kubernetes:
  version: v1.35.4+rke2r1
  manifests:
    urls:
      - https://k8s.io/examples/application/nginx-app.yaml
  helm:
    charts:
      - name: kubevirt
        version: 306.0.2+up0.7.0
        repositoryName: suse-edge
    repositories:
      - name: suse-edge
        url: oci://registry.suse.com/edge/charts

El archivo de definición completo resultante debería tener ahora este aspecto:

apiVersion: 1.3
image:
  imageType: iso
  arch: x86_64
  baseImage: slemicro.iso
  outputImageName: eib-image.iso
operatingSystem:
  users:
    - username: root
      encryptedPassword: $6$G392FCbxVgn[...]Y7zTXnC1
  packages:
    packageList:
      - nvidia-container-toolkit
    additionalRepos:
      - url: https://nvidia.github.io/libnvidia-container/stable/rpm/x86_64
kubernetes:
  version: v1.35.4+k3s1
  manifests:
    urls:
      - https://k8s.io/examples/application/nginx-app.yaml
  helm:
    charts:
      - name: kubevirt
        version: 306.0.2+up0.7.0
        repositoryName: suse-edge
    repositories:
      - name: suse-edge
        url: oci://registry.suse.com/edge/charts

Nota

Puede encontrar más ejemplos de opciones como despliegues de varios nodos, redes personalizadas y opciones/valores de charts de Helm en la documentación upstream.

5.3.8 Configuración de la red #

 

En el último ejemplo de esta guía de inicio rápido, vamos a configurar la red que se activará cuando se aprovisione un sistema con la imagen generada por EIB. Es importante entender que, a menos que se proporcione una configuración de red, el modelo predeterminado es que se utilizará DHCP en todas las interfaces detectadas en el momento del arranque. Sin embargo, esta no siempre es una configuración deseable, especialmente si DHCP no está disponible y necesita proporcionar configuraciones estáticas, o si necesita configurar construcciones de red más complejas, por ejemplo, enlaces, LACP y VLAN, o necesita anular ciertos parámetros, por ejemplo, nombres de host, servidores DNS y rutas.

EIB ofrece la posibilidad de proporcionar configuraciones por nodo (donde el sistema en cuestión se identifica de forma única por su dirección MAC), o una anulación para suministrar una configuración idéntica a cada máquina, lo cual es más útil cuando no se conocen las direcciones MAC del sistema. EIB utiliza una herramienta adicional llamada Network Manager Configurator, o nmc para abreviar, que es una herramienta creada por el equipo de SUSE Telco Cloud para permitir que se apliquen configuraciones de red personalizadas basadas en el esquema de red declarativo nmstate.io, y en el momento del arranque identificará el nodo en el que se está iniciando y aplicará la configuración de red deseada antes de que se activen los servicios.

Ahora vamos a aplicar una configuración de red estática para un sistema con una única interfaz describiendo el estado de red deseado en un archivo específico del nodo (basado en el nombre de host deseado) en el directorio network requerido:

mkdir $CONFIG_DIR/network

cat << EOF > $CONFIG_DIR/network/host1.local.yaml
routes:
  config:
  - destination: 0.0.0.0/0
    metric: 100
    next-hop-address: 192.168.122.1
    next-hop-interface: eth0
    table-id: 254
  - destination: 192.168.122.0/24
    metric: 100
    next-hop-address: 192.168.122.1
    next-hop-interface: eth0
    table-id: 254
dns-resolver:
  config:
    server:
    - 192.168.122.1
    - 8.8.8.8
interfaces:
- name: eth0
  type: ethernet
  state: up
  mac-address: 34:8A:B1:4B:16:E7
  ipv4:
    address:
    - ip: 192.168.122.50
      prefix-length: 24
    dhcp: false
    enabled: true
  ipv6:
    enabled: false
EOF

Aviso

El ejemplo anterior está configurado para la subred 192.168.122.0/24 predeterminada asumiendo que la prueba se está ejecutando en una máquina virtual. Por favor, adáptelo a su entorno, sin olvidar la dirección MAC. Como la misma imagen puede utilizarse para aprovisionar múltiples nodos, la red configurada por EIB (a través de nmc) depende de que sea capaz de identificar de forma única el nodo por su dirección MAC, y por tanto, durante el arranque, nmc aplicará la configuración de red correcta a cada máquina. Esto significa que necesitará conocer las direcciones MAC de los sistemas en los que desea realizar la instalación. Alternativamente, el comportamiento predeterminado es depender de DHCP, pero puede utilizar el hook configure-network.sh para aplicar una configuración común a todos los nodos; consulte la guía de red (Capítulo 13, Redes edge) para obtener más detalles.

La estructura de archivos resultante debería ser:

├── iso-definition.yaml
├── base-images/
│   └── slemicro.iso
└── network/
    └── host1.local.yaml

La configuración de red que acabamos de crear será analizada y los archivos de conexión de NetworkManager necesarios se generarán automáticamente e insertarán en la nueva imagen de instalación que creará EIB. Estos archivos se aplicarán durante el aprovisionamiento del host, lo que dará como resultado una configuración de red completa.

Nota

Por favor, consulte el componente de red edge (Capítulo 13, Redes edge) para obtener una explicación más completa de la configuración anterior y ejemplos de esta funcionalidad.

Ahora que tenemos una imagen base y una definición de imagen para que EIB la utilice, procedamos a compilar la imagen. Para ello, simplemente utilizamos podman para llamar al contenedor EIB con el comando \"build\", especificando el archivo de definición:

podman run --rm -it --privileged -v $CONFIG_DIR:/eib \
registry.suse.com/edge/3.6/edge-image-builder:1.3.3.1 \
build --definition-file iso-definition.yaml

La salida del comando debería ser similar a:

Setting up Podman API listener...
Downloading file: dl-manifest-1.yaml 100% (498/498 B, 9.5 MB/s)
Pulling selected Helm charts... 100% (1/1, 43 it/min)
Generating image customization components...
Identifier ................... [SUCCESS]
Custom Files ................. [SKIPPED]
Time ......................... [SKIPPED]
Network ...................... [SUCCESS]
Groups ....................... [SKIPPED]
Users ........................ [SUCCESS]
Proxy ........................ [SKIPPED]
Resolving package dependencies...
Rpm .......................... [SUCCESS]
Os Files ..................... [SKIPPED]
Systemd ...................... [SKIPPED]
Fips ......................... [SKIPPED]
Elemental .................... [SKIPPED]
Suma ......................... [SKIPPED]
Populating Embedded Artifact Registry... 100% (3/3, 10 it/min)
Embedded Artifact Registry ... [SUCCESS]
Keymap ....................... [SUCCESS]
Configuring Kubernetes component...
The Kubernetes CNI is not explicitly set, defaulting to 'cilium'.
Downloading file: rke2_installer.sh
Downloading file: rke2-images-core.linux-amd64.tar.zst 100% (657/657 MB, 48 MB/s)
Downloading file: rke2-images-cilium.linux-amd64.tar.zst 100% (368/368 MB, 48 MB/s)
Downloading file: rke2.linux-amd64.tar.gz 100% (35/35 MB, 50 MB/s)
Downloading file: sha256sum-amd64.txt 100% (4.3/4.3 kB, 6.2 MB/s)
Kubernetes ................... [SUCCESS]
Certificates ................. [SKIPPED]
Cleanup ...................... [SKIPPED]
Building ISO image...
Kernel Params ................ [SKIPPED]
Build complete, the image can be found at: eib-image.iso

La imagen ISO compilada se almacena en $CONFIG_DIR/eib-image.iso:

├── iso-definition.yaml
├── eib-image.iso
├── _build
│   └── cache/
│       └── ...
│   └── build-<timestamp>/
│       └── ...
├── base-images/
│   └── slemicro.iso
└── network/
    └── host1.local.yaml

Cada compilación crea una carpeta con marca de tiempo en $CONFIG_DIR/_build/ que incluye los registros de la compilación, los artefactos utilizados durante la misma, y los directorios combustion y artefacts que contienen todos los scripts y artefactos que se añaden a la imagen CRB.

El contenido de este directorio debería ser similar a:

├── build-<timestamp>/
│   │── combustion/
│   │   ├── 05-configure-network.sh
│   │   ├── 10-rpm-install.sh
│   │   ├── 12-keymap-setup.sh
│   │   ├── 13b-add-users.sh
│   │   ├── 20-k8s-install.sh
│   │   ├── 26-embedded-registry.sh
│   │   ├── 48-message.sh
│   │   ├── network/
│   │   │   ├── host1.local/
│   │   │   │   └── eth0.nmconnection
│   │   │   └── host_config.yaml
│   │   ├── nmc
│   │   └── script
│   │── artefacts/
│   │   │── registry/
│   │   │   ├── hauler
│   │   │   ├── nginx:<version>-registry.tar.zst
│   │   │   ├── rancher_kubectl:<version>-registry.tar.zst
│   │   │   └── registry.suse.com_suse_sles_15.6_virt-operator:<version>-registry.tar.zst
│   │   │── rpms/
│   │   │   └── rpm-repo
│   │   │       ├── addrepo0
│   │   │       │   ├── nvidia-container-toolkit-<version>.rpm
│   │   │       │   ├── nvidia-container-toolkit-base-<version>.rpm
│   │   │       │   ├── libnvidia-container1-<version>.rpm
│   │   │       │   └── libnvidia-container-tools-<version>.rpm
│   │   │       ├── repodata
│   │   │       │   ├── ...
│   │   │       └── zypper-success
│   │   └── kubernetes/
│   │       ├── rke2_installer.sh
│   │       ├── registries.yaml
│   │       ├── server.yaml
│   │       ├── images/
│   │       │   ├── rke2-images-cilium.linux-amd64.tar.zst
│   │       │   └── rke2-images-core.linux-amd64.tar.zst
│   │       ├── install/
│   │       │   ├── rke2.linux-amd64.tar.gz
│   │       │   └── sha256sum-amd64.txt
│   │       └── manifests/
│   │           ├── dl-manifest-1.yaml
│   │           └── kubevirt.yaml
│   ├── createrepo.log
│   ├── eib-build.log
│   ├── embedded-registry.log
│   ├── helm
│   │   └── kubevirt
│   │       └── kubevirt-0.4.0.tgz
│   ├── helm-pull.log
│   ├── helm-template.log
│   ├── iso-build.log
│   ├── iso-build.sh
│   ├── iso-extract
│   │   └── ...
│   ├── iso-extract.log
│   ├── iso-extract.sh
│   ├── modify-raw-image.sh
│   ├── network-config.log
│   ├── podman-image-build.log
│   ├── podman-system-service.log
│   ├── prepare-resolver-base-tarball-image.log
│   ├── prepare-resolver-base-tarball-image.sh
│   ├── raw-build.log
│   ├── raw-extract
│   │   └── ...
│   └── resolver-image-build
│       └──...
└── cache
    └── ...

Si la compilación falla, eib-build.log es el primer registro que contiene información. A partir de ahí, le dirigirá al componente que falló para su depuración.

En este punto, debería tener una imagen lista para usar que:

Si el proceso de compilación de la imagen falla, consulte la guía de depuración en sentido ascendente.

Para obtener instrucciones sobre cómo probar la imagen CRB recién creada, consulte la guía de pruebas de imágenes en sentido ascendente.

Rancher proporciona varias funcionalidades principales a la pila SUSE Telco Cloud:

SUSE Telco Cloud utiliza Capítulo 12, Edge Image Builder para personalizar las imágenes base del sistema operativo SUSE Linux Micro. Siga Sección 63.6, “Instalación de Rancher” para una instalación de Rancher en entorno aislado sobre clústeres de Kubernetes aprovisionados por EIB.

Todos los componentes de SUSE Telco Cloud 3.6 , incluidas las extensiones del Dashboard, se distribuyen como artefactos OCI. Para instalar las extensiones SUSE Telco Cloud, puede utilizar la interfaz de usuario de Rancher Dashboard, Helm o Fleet:

7.1.2 Instalación con Helm #

 

# KubeVirt extension
helm install kubevirt-dashboard-extension oci://registry.suse.com/edge/charts/kubevirt-dashboard-extension --version 306.0.4+up1.3.3 --namespace cattle-ui-plugin-system

Nota

Las extensiones deben instalarse en el espacio de nombres cattle-ui-plugin-system.

Nota

Después de instalar una extensión, es necesario recargar la interfaz de usuario de Rancher Dashboard.

7.1.3 Instalación con Fleet #

 

La instalación de extensiones de Dashboard con Fleet requiere definir un recurso gitRepo que apunte a un repositorio Git con archivo(s) de configuración de paquete fleet.yaml personalizado(s).

# KubeVirt extension fleet.yaml
defaultNamespace: cattle-ui-plugin-system
helm:
  releaseName: kubevirt-dashboard-extension
  chart: oci://registry.suse.com/edge/charts/kubevirt-dashboard-extension
  version: "306.0.4+up1.3.3"

Nota

La propiedad releaseName es obligatoria y debe coincidir con el nombre de la extensión para que esta se instale correctamente.

cat <<- EOF | kubectl apply -f -
apiVersion: fleet.cattle.io/v1alpha1
metadata:
  name: edge-dashboard-extensions
  namespace: fleet-local
spec:
  repo: https://github.com/suse-edge/fleet-examples.git
  branch: main
  paths:
  - fleets/kubevirt-dashboard-extension/
EOF

Para obtener más información, consulte Capítulo 9, Fleet y el repositorio fleet-examples.

Una vez instaladas las extensiones, aparecen en la sección Extensiones bajo la pestaña Instaladas. Dado que no se instalan a través de Aplicaciones/Marketplace, están marcadas con la etiqueta Third-Party.

La extensión de KubeVirt proporciona una gestión básica de máquinas virtuales para la interfaz de usuario de Rancher Dashboard. Sus capacidades se describen en Sección 19.7.2, “Uso de la extensión de la UI de KubeVirt Rancher”.

La pila SUSE Telco Cloud proporciona un chart de Helm rancher-turtles-providers que habilita ciertos proveedores CAPI a través de la API CAPIProvider:

Solo se admiten los proveedores predeterminados instalados a través del wrapper chart; los proveedores alternativos de plano de control, iniciar e infraestructura no se admiten actualmente como parte de la pila SUSE Telco Cloud.

Desde Rancher 2.13, Rancher Turtles está habilitado de forma predeterminada al instalar Rancher.

Los proveedores de Rancher Turtles pueden instalarse siguiendo la guía Metal3 Quickstart (Capítulo 4, Despliegues automatizados de BMC con Metal³) o la documentación del clúster de gestión (Parte V, “Configuración del clúster de gestión”).

Fleet viene integrado en Rancher, pero también puede instalarse como una aplicación independiente en cualquier clúster de Kubernetes mediante Helm.

Rancher utiliza Fleet para desplegar aplicaciones en clústeres gestionados. La entrega continua con Fleet introduce GitOps a escala, diseñado para gestionar aplicaciones que se ejecutan en un gran número de clústeres.

Fleet destaca como parte integrada de Rancher. Los clústeres gestionados con Rancher obtienen automáticamente el agente de Fleet desplegado como parte del proceso de instalación/importación y el clúster está disponible inmediatamente para ser gestionado por Fleet.

Fleet viene preinstalado en Rancher y se gestiona mediante la opción Entrega continua en la interfaz de usuario de Rancher.

La sección de Entrega continua consta de los siguientes elementos:

La sección de navegación «Avanzado» proporciona información general sobre los recursos de Fleet de bajo nivel. Un bundle es un recurso interno utilizado para la orquestación de recursos desde Git. Cuando se escanea un repositorio Git, este produce uno o más bundles.

Para encontrar los bundles relevantes para un repositorio específico, vaya a la página de detalles del repositorio Git y haga clic en la pestaña Bundles.

Para cada clúster, el bundle se aplica a un recurso BundleDeployment que se crea. Para ver los detalles de BundleDeployment, haga clic en el botón Graph en la parte superior derecha de la página de detalles del repositorio Git. Se carga un gráfico de Repo > Bundles > BundleDeployments. Haga clic en el BundleDeployment en el gráfico para ver sus detalles y haga clic en Id para ver el YAML de BundleDeployment.

Para obtener información adicional sobre consejos de solución de problemas de Fleet, consulte aquí.

El equipo de Edge mantiene un repositorio con ejemplos de instalación de proyectos Edge con Fleet.

El proyecto Fleet incluye un repositorio fleet-examples que cubre todos los casos de uso para la estructura del repositorio Git.

Utilizamos SUSE Linux Micro como sistema operativo base para nuestra pila de plataforma. Esto nos proporciona una base segura, estable y mínima sobre la que construir.

SUSE Linux Micro es único en su uso de instantáneas del sistema de archivos (Btrfs) para permitir reversiones sencillas en caso de que algo salga mal con una actualización. Esto permite realizar actualizaciones remotas seguras de toda la plataforma incluso sin acceso físico en caso de problemas.

SUSE Telco Cloud utiliza Metal³ para gestionar el ciclo de vida del hardware físico, como los servidores. El hardware debe admitir un protocolo de gestión fuera de banda compatible con Metal³ (p. ej., Redfish). Cuando un clúster de gestión SUSE Telco Cloud aprovisiona o desaprovisiona clústeres de sentido descendente, Metal³ interactuará con la BMC de un servidor a través de Redfish. Las siguientes acciones suelen formar parte de esta interacción:

Este enfoque es útil para escenarios en los que el hardware de destino admite la gestión fuera de banda y se desea un flujo de gestión de infraestructura totalmente automatizado.

Metal³ y CAPI proporcionan API declarativas que permiten la gestión del inventario y del estado de servidores de equipo sin sistema operativo, incluyendo la inspección, limpieza y aprovisionamiento/desaprovisionamiento automatizados.

SUSE Telco Cloud utiliza EIB para la configuración simplificada y rápida de imágenes personalizadas de SUSE Linux Micro para una variedad de escenarios. Estos escenarios incluyen el inicio de máquinas virtuales y de equipos sin sistema operativo con:

Puede encontrar documentación completa sobre el uso y las pruebas de Edge Image Builder aquí.

Además, consulte Capítulo 5, Clústeres independientes con Edge Image Builder que cubre un escenario de ampliación básico.

Una vez que esté familiarizado con esta herramienta, encontrará información más útil en nuestra página Sección de Consejos y Trucos de EIB (Parte X, “Consejos y trucos”).

NetworkManager es una herramienta que gestiona la conexión de red primaria y otras interfaces de conexión.

NetworkManager almacena las configuraciones de red como archivos de conexión que contienen el estado deseado. Estas conexiones se almacenan como archivos en el directorio /etc/NetworkManager/system-connections/.

Puede encontrar detalles sobre NetworkManager en la documentación de SUSE Linux Micro.

nmstate es una biblioteca ampliamente adoptada (con una herramienta CLI complementaria) que ofrece una API declarativa para configuraciones de red mediante un esquema predefinido.

Puede encontrar detalles sobre nmstate en la documentación upstream.

Las opciones de personalización de red disponibles en SUSE Telco Cloud se consiguen mediante una herramienta CLI llamada Configurador de NetworkManager o nmc para abreviar. Aprovecha la funcionalidad proporcionada por la biblioteca nmstate y, como tal, es totalmente capaz de configurar direcciones IP estáticas, servidores DNS, VLAN, vinculación, puentes, etc. Esta herramienta nos permite generar configuraciones de red a partir de estados deseados predefinidos y aplicarlas en muchos nodos diferentes de forma automatizada.

Puede encontrar detalles sobre el Configurador de NetworkManager (nmc) en el repositorio upstream.

SUSE Telco Cloud utiliza nmc para las personalizaciones de red en los diversos modelos de aprovisionamiento: * Configuraciones de red personalizadas en los escenarios de aprovisionamiento de red dirigida (Capítulo 4, Despliegues automatizados de BMC con Metal³) * Configuraciones estáticas declarativas en los escenarios de aprovisionamiento basado en imágenes (Capítulo 5, Clústeres independientes con Edge Image Builder)

Edge Image Builder (EIB) es una herramienta que permite configurar varios hosts con una única imagen de SO. En esta sección mostraremos cómo se puede utilizar un enfoque declarativo para describir los estados de red deseados, cómo se convierten en las respectivas conexiones de NetworkManager y cómo se aplican durante el proceso de aprovisionamiento.

podman pull registry.suse.com/edge/3.6/edge-image-builder:1.3.3.1

export CONFIG_DIR=$HOME/eib
mkdir -p $CONFIG_DIR/base-images

mv /path/to/downloads/SL-Micro.x86_64-6.2-Base-GM.raw $CONFIG_DIR/base-images/

└── base-images/
    └── SL-Micro.x86_64-6.2-Base-GM.raw

cat << EOF > $CONFIG_DIR/definition.yaml
apiVersion: 1.3
image:
  arch: x86_64
  imageType: raw
  baseImage: SL-Micro.x86_64-6.2-Base-GM.raw
  outputImageName: modified-image.raw
operatingSystem:
  users:
    - username: root
      encryptedPassword: $6$jHugJNNd3HElGsUZ$eodjVe4te5ps44SVcWshdfWizrP.xAyd71CVEXazBJ/.v799/WRCBXxfYmunlBO2yp1hm/zb4r8EmnrrNCF.P/
EOF

├── definition.yaml
└── base-images/
    └── SL-Micro.x86_64-6.2-Base-GM.raw

13.5.5 Definición de las configuraciones de red #

 

Las configuraciones de red deseadas no forman parte del archivo de definición de imagen que acabamos de crear. Ahora poblaremos esas bajo el directorio especial network/. Creémoslo:

mkdir -p $CONFIG_DIR/network

Como se mencionó anteriormente, la herramienta NetworkManager Configurator (nmc) espera una entrada en forma de esquema predefinido. Puedes encontrar cómo configurar una amplia variedad de opciones de red en la documentación de ejemplos upstream de NMState.

Esta guía explicará cómo configurar la red en tres nodos diferentes:

• Un nodo que utiliza dos interfaces Ethernet

• Un nodo que utiliza vinculación de interfaces de red

• Un nodo que utiliza un puente de red (bridge)

Aviso

No se recomienda utilizar configuraciones de red completamente diferentes en compilaciones de producción, especialmente si se configuran clústeres de Kubernetes. Las configuraciones de red generalmente deben ser homogéneas entre los nodos o, al menos, entre los roles dentro de un clúster determinado. Esta guía incluye varias opciones diferentes solo para servir como referencia de ejemplo.

Nota

Lo siguiente asume una libvirt red predeterminada con un rango de direcciones IP 192.168.122.1/24. Ajuste en consecuencia si esto difiere en su entorno.

Creemos los estados deseados para el primer nodo al que llamaremos node1.suse.com:

cat << EOF > $CONFIG_DIR/network/node1.suse.com.yaml
routes:
  config:
    - destination: 0.0.0.0/0
      metric: 100
      next-hop-address: 192.168.122.1
      next-hop-interface: eth0
      table-id: 254
    - destination: 192.168.122.0/24
      metric: 100
      next-hop-address: 192.168.122.1
      next-hop-interface: eth0
      table-id: 254
dns-resolver:
  config:
    server:
      - 192.168.122.1
      - 8.8.8.8
interfaces:
  - name: eth0
    type: ethernet
    state: up
    mac-address: 34:8A:B1:4B:16:E1
    ipv4:
      address:
        - ip: 192.168.122.50
          prefix-length: 24
      dhcp: false
      enabled: true
    ipv6:
      enabled: false
  - name: eth3
    type: ethernet
    state: down
    mac-address: 34:8A:B1:4B:16:E2
    ipv4:
      address:
        - ip: 192.168.122.55
          prefix-length: 24
      dhcp: false
      enabled: true
    ipv6:
      enabled: false
EOF

En este ejemplo definimos un estado deseado de dos interfaces Ethernet (eth0 y eth3), sus direcciones IP solicitadas, el enrutamiento y la resolución DNS.

Aviso

Debe asegurarse de que las direcciones MAC de todas las interfaces Ethernet estén enumeradas. Estas se utilizan durante el proceso de aprovisionamiento como identificadores de los nodos y sirven para determinar qué configuraciones deben aplicarse. Así es como podemos configurar múltiples nodos utilizando una única imagen ISO o RAW.

A continuación, el segundo nodo, al que llamaremos node2.suse.com y que utilizará vinculación de interfaces de red:

cat << EOF > $CONFIG_DIR/network/node2.suse.com.yaml
routes:
  config:
    - destination: 0.0.0.0/0
      metric: 100
      next-hop-address: 192.168.122.1
      next-hop-interface: bond99
      table-id: 254
    - destination: 192.168.122.0/24
      metric: 100
      next-hop-address: 192.168.122.1
      next-hop-interface: bond99
      table-id: 254
dns-resolver:
  config:
    server:
      - 192.168.122.1
      - 8.8.8.8
interfaces:
  - name: bond99
    type: bond
    state: up
    ipv4:
      address:
        - ip: 192.168.122.60
          prefix-length: 24
      enabled: true
    link-aggregation:
      mode: balance-rr
      options:
        miimon: '140'
      port:
        - eth0
        - eth1
  - name: eth0
    type: ethernet
    state: up
    mac-address: 34:8A:B1:4B:16:E3
    ipv4:
      enabled: false
    ipv6:
      enabled: false
  - name: eth1
    type: ethernet
    state: up
    mac-address: 34:8A:B1:4B:16:E4
    ipv4:
      enabled: false
    ipv6:
      enabled: false
EOF

En este ejemplo definimos un estado deseado de dos interfaces Ethernet (eth0 y eth1) que no habilitan el direccionamiento IP, así como una vinculación con una directiva round-robin y su dirección respectiva que se utilizará para reenviar el tráfico de red.

Por último, crearemos el tercer y último archivo de estado deseado que utilizará un puente de red y al que llamaremos node3.suse.com:

cat << EOF > $CONFIG_DIR/network/node3.suse.com.yaml
routes:
  config:
    - destination: 0.0.0.0/0
      metric: 100
      next-hop-address: 192.168.122.1
      next-hop-interface: linux-br0
      table-id: 254
    - destination: 192.168.122.0/24
      metric: 100
      next-hop-address: 192.168.122.1
      next-hop-interface: linux-br0
      table-id: 254
dns-resolver:
  config:
    server:
      - 192.168.122.1
      - 8.8.8.8
interfaces:
  - name: eth0
    type: ethernet
    state: up
    mac-address: 34:8A:B1:4B:16:E5
    ipv4:
      enabled: false
    ipv6:
      enabled: false
  - name: linux-br0
    type: linux-bridge
    state: up
    ipv4:
      address:
        - ip: 192.168.122.70
          prefix-length: 24
      dhcp: false
      enabled: true
    bridge:
      options:
        group-forward-mask: 0
        mac-ageing-time: 300
        multicast-snooping: true
        stp:
          enabled: true
          forward-delay: 15
          hello-time: 2
          max-age: 20
          priority: 32768
      port:
        - name: eth0
          stp-hairpin-mode: false
          stp-path-cost: 100
          stp-priority: 32
EOF

El directorio de configuración en este punto debería tener el siguiente aspecto:

├── definition.yaml
├── network/
│   │── node1.suse.com.yaml
│   │── node2.suse.com.yaml
│   └── node3.suse.com.yaml
└── base-images/
    └── SL-Micro.x86_64-6.2-Base-GM.raw

Nota

Los nombres de los archivos en el directorio network/ son intencionados. Corresponden a los nombres de host que se establecerán durante el proceso de aprovisionamiento.

podman run --rm -it -v $CONFIG_DIR:/eib registry.suse.com/edge/3.6/edge-image-builder:1.3.3.1 build --definition-file definition.yaml

Generating image customization components...
Identifier ................... [SUCCESS]
Custom Files ................. [SKIPPED]
Time ......................... [SKIPPED]
Network ...................... [SUCCESS]
Groups ....................... [SKIPPED]
Users ........................ [SUCCESS]
Proxy ........................ [SKIPPED]
Rpm .......................... [SKIPPED]
Systemd ...................... [SKIPPED]
Elemental .................... [SKIPPED]
Suma ......................... [SKIPPED]
Embedded Artifact Registry ... [SKIPPED]
Keymap ....................... [SUCCESS]
Kubernetes ................... [SKIPPED]
Certificates ................. [SKIPPED]
Building RAW image...
Kernel Params ................ [SKIPPED]
Image build complete!

mkdir edge-nodes && cd edge-nodes
for i in {1..4}; do cp $CONFIG_DIR/modified-image.raw node$i.raw; done

virt-install --name node1 --ram 10000 --vcpus 6 --disk path=node1.raw,format=raw --osinfo detect=on,name=sle-unknown --graphics none --console pty,target_type=serial --network default,mac=34:8A:B1:4B:16:E1 --network default,mac=34:8A:B1:4B:16:E2 --virt-type kvm --import

Starting install...
Creating domain...

Running text console command: virsh --connect qemu:///system console node1
Connected to domain 'node1'
Escape character is ^] (Ctrl + ])


Welcome to SUSE Linux Micro 6.0 (x86_64) - Kernel 6.4.0-18-default (tty1).

SSH host key: SHA256:XN/R5Tw43reG+QsOw480LxCnhkc/1uqMdwlI6KUBY70 (RSA)
SSH host key: SHA256:/96yGrPGKlhn04f1rb9cXv/2WJt4TtrIN5yEcN66r3s (DSA)
SSH host key: SHA256:Dy/YjBQ7LwjZGaaVcMhTWZNSOstxXBsPsvgJTJq5t00 (ECDSA)
SSH host key: SHA256:TNGqY1LRddpxD/jn/8dkT/9YmVl9hiwulqmayP+wOWQ (ED25519)
eth0: 192.168.122.50
eth1:


Configured with the Edge Image Builder
Activate the web console with: systemctl enable --now cockpit.socket

node1 login:

node1:~ # hostnamectl
 Static hostname: node1.suse.com
 ...

node1:~ # ip r
default via 192.168.122.1 dev eth0 proto static metric 100
192.168.122.0/24 dev eth0 proto static scope link metric 100
192.168.122.0/24 dev eth0 proto kernel scope link src 192.168.122.50 metric 100

node1:~ # ping google.com
PING google.com (142.250.72.78) 56(84) bytes of data.
64 bytes from den16s09-in-f14.1e100.net (142.250.72.78): icmp_seq=1 ttl=56 time=13.2 ms
64 bytes from den16s09-in-f14.1e100.net (142.250.72.78): icmp_seq=2 ttl=56 time=13.4 ms
^C
--- google.com ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1002ms
rtt min/avg/max/mdev = 13.248/13.304/13.361/0.056 ms

node1:~ # ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 34:8a:b1:4b:16:e1 brd ff:ff:ff:ff:ff:ff
    altname enp0s2
    altname ens2
    inet 192.168.122.50/24 brd 192.168.122.255 scope global noprefixroute eth0
       valid_lft forever preferred_lft forever
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 34:8a:b1:4b:16:e2 brd ff:ff:ff:ff:ff:ff
    altname enp0s3
    altname ens3

node1:~ # nmcli -f NAME,UUID,TYPE,DEVICE,FILENAME con show
NAME  UUID                                  TYPE      DEVICE  FILENAME
eth0  dfd202f5-562f-5f07-8f2a-a7717756fb70  ethernet  eth0    /etc/NetworkManager/system-connections/eth0.nmconnection
eth1  7e211aea-3d14-59cf-a4fa-be91dac5dbba  ethernet  --      /etc/NetworkManager/system-connections/eth1.nmconnection

node1:~ # journalctl -u combustion | grep nmc
Apr 23 09:20:19 localhost.localdomain combustion[1360]: [2024-04-23T09:20:19Z INFO  nmc::apply_conf] Identified host: node1.suse.com
Apr 23 09:20:19 localhost.localdomain combustion[1360]: [2024-04-23T09:20:19Z INFO  nmc::apply_conf] Set hostname: node1.suse.com
Apr 23 09:20:19 localhost.localdomain combustion[1360]: [2024-04-23T09:20:19Z INFO  nmc::apply_conf] Processing interface 'eth0'...
Apr 23 09:20:19 localhost.localdomain combustion[1360]: [2024-04-23T09:20:19Z INFO  nmc::apply_conf] Processing interface 'eth3'...
Apr 23 09:20:19 localhost.localdomain combustion[1360]: [2024-04-23T09:20:19Z INFO  nmc::apply_conf] Using interface name 'eth1' instead of the preconfigured 'eth3'
Apr 23 09:20:19 localhost.localdomain combustion[1360]: [2024-04-23T09:20:19Z INFO  nmc] Successfully applied config

virt-install --name node2 --ram 10000 --vcpus 6 --disk path=node2.raw,format=raw --osinfo detect=on,name=sle-unknown --graphics none --console pty,target_type=serial --network default,mac=34:8A:B1:4B:16:E3 --network default,mac=34:8A:B1:4B:16:E4 --virt-type kvm --import

node2:~ # ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master bond99 state UP group default qlen 1000
    link/ether 34:8a:b1:4b:16:e3 brd ff:ff:ff:ff:ff:ff
    altname enp0s2
    altname ens2
3: eth1: <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master bond99 state UP group default qlen 1000
    link/ether 34:8a:b1:4b:16:e3 brd ff:ff:ff:ff:ff:ff permaddr 34:8a:b1:4b:16:e4
    altname enp0s3
    altname ens3
4: bond99: <BROADCAST,MULTICAST,MASTER,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 34:8a:b1:4b:16:e3 brd ff:ff:ff:ff:ff:ff
    inet 192.168.122.60/24 brd 192.168.122.255 scope global noprefixroute bond99
       valid_lft forever preferred_lft forever

node2:~ # ip r
default via 192.168.122.1 dev bond99 proto static metric 100
192.168.122.0/24 dev bond99 proto static scope link metric 100
192.168.122.0/24 dev bond99 proto kernel scope link src 192.168.122.60 metric 300

node2:~ # nmcli -f NAME,UUID,TYPE,DEVICE,FILENAME con show
NAME    UUID                                  TYPE      DEVICE  FILENAME
bond99  4a920503-4862-5505-80fd-4738d07f44c6  bond      bond99  /etc/NetworkManager/system-connections/bond99.nmconnection
eth0    dfd202f5-562f-5f07-8f2a-a7717756fb70  ethernet  eth0    /etc/NetworkManager/system-connections/eth0.nmconnection
eth1    0523c0a1-5f5e-5603-bcf2-68155d5d322e  ethernet  eth1    /etc/NetworkManager/system-connections/eth1.nmconnection

virt-install --name node3 --ram 10000 --vcpus 6 --disk path=node3.raw,format=raw --osinfo detect=on,name=sle-unknown --graphics none --console pty,target_type=serial --network default,mac=34:8A:B1:4B:16:E5 --virt-type kvm --import

node3:~ # ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master linux-br0 state UP group default qlen 1000
    link/ether 34:8a:b1:4b:16:e5 brd ff:ff:ff:ff:ff:ff
    altname enp0s2
    altname ens2
3: linux-br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 34:8a:b1:4b:16:e5 brd ff:ff:ff:ff:ff:ff
    inet 192.168.122.70/24 brd 192.168.122.255 scope global noprefixroute linux-br0
       valid_lft forever preferred_lft forever

node3:~ # ip r
default via 192.168.122.1 dev linux-br0 proto static metric 100
192.168.122.0/24 dev linux-br0 proto static scope link metric 100
192.168.122.0/24 dev linux-br0 proto kernel scope link src 192.168.122.70 metric 425

node3:~ # nmcli -f NAME,UUID,TYPE,DEVICE,FILENAME con show
NAME       UUID                                  TYPE      DEVICE     FILENAME
linux-br0  1f8f1469-ed20-5f2c-bacb-a6767bee9bc0  bridge    linux-br0  /etc/NetworkManager/system-connections/linux-br0.nmconnection
eth0       dfd202f5-562f-5f07-8f2a-a7717756fb70  ethernet  eth0       /etc/NetworkManager/system-connections/eth0.nmconnection

virt-install --name node4 --ram 10000 --vcpus 6 --disk path=node4.raw,format=raw --osinfo detect=on,name=sle-unknown --graphics none --console pty,target_type=serial --network default --virt-type kvm --import

localhost:~ # ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 52:54:00:56:63:71 brd ff:ff:ff:ff:ff:ff
    altname enp0s2
    altname ens2
    inet 192.168.122.86/24 brd 192.168.122.255 scope global dynamic noprefixroute eth0
       valid_lft 3542sec preferred_lft 3542sec
    inet6 fe80::5054:ff:fe56:6371/64 scope link noprefixroute
       valid_lft forever preferred_lft forever

localhost:~ # journalctl -u combustion | grep nmc
Apr 23 12:15:45 localhost.localdomain combustion[1357]: [2024-04-23T12:15:45Z ERROR nmc] Applying config failed: None of the preconfigured hosts match local NICs

localhost:~ # journalctl | grep eth0
Apr 23 12:15:29 localhost.localdomain NetworkManager[704]: <info>  [1713874529.7801] manager: (eth0): new Ethernet device (/org/freedesktop/NetworkManager/Devices/2)
Apr 23 12:15:29 localhost.localdomain NetworkManager[704]: <info>  [1713874529.7802] device (eth0): state change: unmanaged -> unavailable (reason 'managed', sys-iface-state: 'external')
Apr 23 12:15:29 localhost.localdomain NetworkManager[704]: <info>  [1713874529.7929] device (eth0): carrier: link connected
Apr 23 12:15:29 localhost.localdomain NetworkManager[704]: <info>  [1713874529.7931] device (eth0): state change: unavailable -> disconnected (reason 'carrier-changed', sys-iface-state: 'managed')
Apr 23 12:15:29 localhost.localdomain NetworkManager[704]: <info>  [1713874529.7944] device (eth0): Activation: starting connection 'Wired Connection' (300ed658-08d4-4281-9f8c-d1b8882d29b9)
Apr 23 12:15:29 localhost.localdomain NetworkManager[704]: <info>  [1713874529.7945] device (eth0): state change: disconnected -> prepare (reason 'none', sys-iface-state: 'managed')
Apr 23 12:15:29 localhost.localdomain NetworkManager[704]: <info>  [1713874529.7947] device (eth0): state change: prepare -> config (reason 'none', sys-iface-state: 'managed')
Apr 23 12:15:29 localhost.localdomain NetworkManager[704]: <info>  [1713874529.7953] device (eth0): state change: config -> ip-config (reason 'none', sys-iface-state: 'managed')
Apr 23 12:15:29 localhost.localdomain NetworkManager[704]: <info>  [1713874529.7964] dhcp4 (eth0): activation: beginning transaction (timeout in 90 seconds)
Apr 23 12:15:33 localhost.localdomain NetworkManager[704]: <info>  [1713874533.1272] dhcp4 (eth0): state changed new lease, address=192.168.122.86

localhost:~ # nmcli -f NAME,UUID,TYPE,DEVICE,FILENAME con show
NAME              UUID                                  TYPE      DEVICE  FILENAME
Wired Connection  300ed658-08d4-4281-9f8c-d1b8882d29b9  ethernet  eth0    /var/run/NetworkManager/system-connections/default_connection.nmconnection

mkdir -p $CONFIG_DIR/network

cat <<- EOF > $CONFIG_DIR/network/_all.yaml
interfaces:
- name: eth0
  type: ethernet
  state: up
  ipv4:
    dhcp: true
    enabled: true
  ipv6:
    enabled: false
- name: eth1
  type: ethernet
  state: up
  ipv4:
    address:
    - ip: 10.0.0.1
      prefix-length: 24
    enabled: true
    dhcp: false
  ipv6:
    enabled: false
EOF

podman run --rm -it -v $CONFIG_DIR:/eib registry.suse.com/edge/3.6/edge-image-builder:1.3.3.1 build --definition-file definition.yaml

virt-install --name node1 --ram 10000 --vcpus 6 --disk path=$CONFIG_DIR/modified-image.raw,format=raw --osinfo detect=on,name=sle-unknown --graphics none --console pty,target_type=serial --network default --network default --virt-type kvm --import

localhost:~ # ip r
default via 192.168.122.1 dev eth0 proto dhcp src 192.168.122.100 metric 100
10.0.0.0/24 dev eth1 proto kernel scope link src 10.0.0.1 metric 101
192.168.122.0/24 dev eth0 proto kernel scope link src 192.168.122.100 metric 100

localhost:~ # ping google.com
PING google.com (142.250.72.46) 56(84) bytes of data.
64 bytes from den16s08-in-f14.1e100.net (142.250.72.46): icmp_seq=1 ttl=56 time=14.3 ms
64 bytes from den16s08-in-f14.1e100.net (142.250.72.46): icmp_seq=2 ttl=56 time=14.2 ms
^C
--- google.com ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 14.196/14.260/14.324/0.064 ms

localhost:~ # ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 52:54:00:26:44:7a brd ff:ff:ff:ff:ff:ff
    altname enp1s0
    inet 192.168.122.100/24 brd 192.168.122.255 scope global dynamic noprefixroute eth0
       valid_lft 3505sec preferred_lft 3505sec
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 52:54:00:ec:57:9e brd ff:ff:ff:ff:ff:ff
    altname enp7s0
    inet 10.0.0.1/24 brd 10.0.0.255 scope global noprefixroute eth1
       valid_lft forever preferred_lft forever

localhost:~ # nmcli -f NAME,UUID,TYPE,DEVICE,FILENAME con show
NAME  UUID                                  TYPE      DEVICE  FILENAME
eth0  dfd202f5-562f-5f07-8f2a-a7717756fb70  ethernet  eth0    /etc/NetworkManager/system-connections/eth0.nmconnection
eth1  0523c0a1-5f5e-5603-bcf2-68155d5d322e  ethernet  eth1    /etc/NetworkManager/system-connections/eth1.nmconnection

localhost:~ # cat /etc/NetworkManager/system-connections/eth0.nmconnection
[connection]
autoconnect=true
autoconnect-slaves=-1
id=eth0
interface-name=eth0
type=802-3-ethernet
uuid=dfd202f5-562f-5f07-8f2a-a7717756fb70

[ipv4]
dhcp-client-id=mac
dhcp-send-hostname=true
dhcp-timeout=2147483647
ignore-auto-dns=false
ignore-auto-routes=false
method=auto
never-default=false

[ipv6]
addr-gen-mode=0
dhcp-timeout=2147483647
method=disabled

localhost:~ # cat /etc/NetworkManager/system-connections/eth1.nmconnection
[connection]
autoconnect=true
autoconnect-slaves=-1
id=eth1
interface-name=eth1
type=802-3-ethernet
uuid=0523c0a1-5f5e-5603-bcf2-68155d5d322e

[ipv4]
address0=10.0.0.1/24
dhcp-timeout=2147483647
method=manual

[ipv6]
addr-gen-mode=0
dhcp-timeout=2147483647
method=disabled

13.5.9 Configuraciones de red personalizadas #

 

Ya hemos cubierto la configuración de red predeterminada para Edge Image Builder, que depende de NetworkManager Configurator. Sin embargo, también existe la opción de modificarla mediante un guion personalizado. Aunque esta opción es muy flexible y tampoco depende de la dirección MAC, su limitación radica en el hecho de que utilizarla es mucho menos cómodo al arrancar múltiples nodos con una única imagen.

Nota

Se recomienda utilizar la configuración de red predeterminada mediante archivos que describan los estados de red deseados en el directorio /network. Optad por el scripting personalizado solo cuando ese comportamiento no sea aplicable a vuestro caso de uso.

Construiremos y aprovisionaremos un nodo edge utilizando una estructura de configuración diferente. Sigue todos los pasos desde Sección 13.5.3, “Creación del directorio de configuración de la imagen” hasta Sección 13.5.5, “Definición de las configuraciones de red”.

En este ejemplo, crearemos un guion personalizado que aplique una configuración estática para la interfaz eth0 en todos los nodos aprovisionados, además de eliminar y deshabilitar las conexiones cableadas creadas automáticamente por NetworkManager. Esto resulta beneficioso en situaciones en las que se desea asegurar que cada nodo del clúster tenga una configuración de red idéntica y, por tanto, no es necesario preocuparse por la dirección MAC de cada nodo antes de la creación de la imagen.

Empecemos almacenando el archivo de conexión en el directorio /custom/files:

mkdir -p $CONFIG_DIR/custom/files

cat << EOF > $CONFIG_DIR/custom/files/eth0.nmconnection
[connection]
autoconnect=true
autoconnect-slaves=-1
autoconnect-retries=1
id=eth0
interface-name=eth0
type=802-3-ethernet
uuid=dfd202f5-562f-5f07-8f2a-a7717756fb70
wait-device-timeout=60000

[ipv4]
dhcp-timeout=2147483647
method=auto

[ipv6]
addr-gen-mode=eui64
dhcp-timeout=2147483647
method=disabled
EOF

Ahora que la configuración estática está creada, también crearemos nuestro guion de red personalizado:

mkdir -p $CONFIG_DIR/network

cat << EOF > $CONFIG_DIR/network/configure-network.sh
#!/bin/bash
set -eux

# Remove and disable wired connections
mkdir -p /etc/NetworkManager/conf.d/
printf "[main]\nno-auto-default=*\n" > /etc/NetworkManager/conf.d/no-auto-default.conf
rm -f /var/run/NetworkManager/system-connections/* || true

# Copy pre-configured network configuration files into NetworkManager
mkdir -p /etc/NetworkManager/system-connections/
cp eth0.nmconnection /etc/NetworkManager/system-connections/
chmod 600 /etc/NetworkManager/system-connections/*.nmconnection
EOF

chmod a+x $CONFIG_DIR/network/configure-network.sh

Nota

El binario nmc seguirá incluyéndose por defecto, por lo que también puede utilizarse en el guion configure-network.sh si fuera necesario.

Aviso

El guion personalizado debe proporcionarse siempre en /network/configure-network.sh dentro del directorio de configuración. Si está presente, se ignorarán todos los demás archivos. NO es posible configurar una red trabajando simultáneamente con configuraciones estáticas en formato YAML y un script personalizado.

El directorio de configuración en este punto debería tener el siguiente aspecto:

├── definition.yaml
├── custom/
│   └── files/
│       └── eth0.nmconnection
├── network/
│   └── configure-network.sh
└── base-images/
    └── SL-Micro.x86_64-6.2-Base-GM.raw

Vamos a construir la imagen:

podman run --rm -it -v $CONFIG_DIR:/eib registry.suse.com/edge/3.6/edge-image-builder:1.3.3.1 build --definition-file definition.yaml

Una vez que la imagen se haya construido correctamente, vamos a crear una máquina virtual utilizándola:

virt-install --name node1 --ram 10000 --vcpus 6 --disk path=$CONFIG_DIR/modified-image.raw,format=raw --osinfo detect=on,name=sle-unknown --graphics none --console pty,target_type=serial --network default --virt-type kvm --import

El proceso de aprovisionamiento puede tardar unos minutos. Una vez finalizado, iniciad sesión en el sistema con las credenciales proporcionadas.

Verificad que el enrutamiento esté configurado correctamente:

localhost:~ # ip r
default via 192.168.122.1 dev eth0 proto dhcp src 192.168.122.185 metric 100
192.168.122.0/24 dev eth0 proto kernel scope link src 192.168.122.185 metric 100

Verificad que la conexión a Internet esté disponible:

localhost:~ # ping google.com
PING google.com (142.250.72.78) 56(84) bytes of data.
64 bytes from den16s09-in-f14.1e100.net (142.250.72.78): icmp_seq=1 ttl=56 time=13.6 ms
64 bytes from den16s09-in-f14.1e100.net (142.250.72.78): icmp_seq=2 ttl=56 time=13.6 ms
^C
--- google.com ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 13.592/13.599/13.606/0.007 ms

Verificad que una interfaz Ethernet esté configurada estáticamente utilizando nuestro archivo de conexión y que esté activa:

localhost:~ # ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 52:54:00:31:d0:1b brd ff:ff:ff:ff:ff:ff
    altname enp0s2
    altname ens2
    inet 192.168.122.185/24 brd 192.168.122.255 scope global dynamic noprefixroute eth0

localhost:~ # nmcli -f NAME,UUID,TYPE,DEVICE,FILENAME con show
NAME  UUID                                  TYPE      DEVICE  FILENAME
eth0  dfd202f5-562f-5f07-8f2a-a7717756fb70  ethernet  eth0    /etc/NetworkManager/system-connections/eth0.nmconnection

localhost:~ # cat  /etc/NetworkManager/system-connections/eth0.nmconnection
[connection]
autoconnect=true
autoconnect-slaves=-1
autoconnect-retries=1
id=eth0
interface-name=eth0
type=802-3-ethernet
uuid=dfd202f5-562f-5f07-8f2a-a7717756fb70
wait-device-timeout=60000

[ipv4]
dhcp-timeout=2147483647
method=auto

[ipv6]
addr-gen-mode=eui64
dhcp-timeout=2147483647
method=disabled

K3s es una distribución de Kubernetes totalmente conforme y ligera, centrada en Edge, IoT y en la familia de arquitecturas ARM, optimizada para facilitar su uso y para entornos con recursos limitados

RKE2 combina lo mejor de ambos mundos de la versión 1.x de RKE (en adelante denominada RKE1) y K3s.

De K3s, hereda la facilidad de uso, la sencillez de funcionamiento y el modelo de despliegue.

De RKE1, hereda una estrecha alineación con Kubernetes upstream. En algunos aspectos, K3s se ha desviado de Kubernetes upstream para optimizar despliegues en edge, pero RKE1 y RKE2 pueden mantenerse estrechamente alineados con upstream

RKE2 es una pieza fundamental de la pila SUSE Telco Cloud. Se asienta sobre SUSE Linux Micro (Capítulo 10, SUSE Linux Micro), proporcionando una interfaz de Kubernetes estándar necesaria para desplegar cargas de trabajo de Edge.

Si estáis siguiendo esta guía, se asume que ya disponéis de lo siguiente:

SUSE Storage utiliza recursos de Kubernetes llamados StorageClass para aprovisionar automáticamente objetos PersistentVolume para los pods. Pensad en StorageClass como una forma en que los administradores describen las clases o perfiles de almacenamiento que ofrecen.

Vamos a crear un StorageClass con algunas opciones predeterminadas:

kubectl apply -f - <<EOF
kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
  name: longhorn-example
provisioner: driver.longhorn.io
allowVolumeExpansion: true
parameters:
  numberOfReplicas: "3"
  staleReplicaTimeout: "2880" # 48 hours in minutes
  fromBackup: ""
  fsType: "ext4"
EOF

Ahora que tenemos nuestro StorageClass en su lugar, necesitamos un PersistentVolumeClaim que haga referencia a él. Una PersistentVolumeClaim (PVC) es una solicitud de almacenamiento por parte de un usuario. Los PVC consumen recursos PersistentVolume. Las reclamaciones pueden solicitar tamaños y modos de acceso específicos (por ejemplo, pueden montarse una vez en lectura-escritura o muchas veces en solo lectura).

Vamos a crear una PersistentVolumeClaim:

kubectl apply -f - <<EOF
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: longhorn-volv-pvc
  namespace: longhorn-system
spec:
  accessModes:
    - ReadWriteOnce
  storageClassName: longhorn-example
  resources:
    requests:
      storage: 2Gi
EOF

Es así de sencillo. Una vez que hayamos creado la PersistentVolumeClaim, podemos proceder a adjuntarla a un Pod. Cuando se despliega el Pod, Kubernetes crea el volumen de Longhorn y lo vincula a la Pod si hay almacenamiento disponible.

kubectl apply -f - <<EOF
apiVersion: v1
kind: Pod
metadata:
  name: volume-test
  namespace: longhorn-system
spec:
  containers:
  - name: volume-test
    image: nginx:stable-alpine
    imagePullPolicy: IfNotPresent
    volumeMounts:
    - name: volv
      mountPath: /data
    ports:
    - containerPort: 80
  volumes:
  - name: volv
    persistentVolumeClaim:
      claimName: longhorn-volv-pvc
EOF

Sugerencia

El concepto de almacenamiento en Kubernetes es un tema complejo, pero importante. Hemos mencionado brevemente algunos de los recursos de Kubernetes más comunes; no obstante, os sugerimos que os familiaricéis con la documentación de terminología que ofrece Longhorn.

En este ejemplo, el resultado debería ser parecido a esto:

localhost:~ # kubectl get storageclass
NAME                 PROVISIONER          RECLAIMPOLICY   VOLUMEBINDINGMODE   ALLOWVOLUMEEXPANSION   AGE
longhorn (default)   driver.longhorn.io   Delete          Immediate           true                   12m
longhorn-example     driver.longhorn.io   Delete          Immediate           true                   24s

localhost:~ # kubectl get pvc -n longhorn-system
NAME                STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS       AGE
longhorn-volv-pvc   Bound    pvc-f663a92e-ac32-49ae-b8e5-8a6cc29a7d1e   2Gi        RWO            longhorn-example   54s

localhost:~ # kubectl get pods -n longhorn-system
NAME                                                READY   STATUS    RESTARTS      AGE
csi-attacher-5c4bfdcf59-qmjtz                       1/1     Running   0             14m
csi-attacher-5c4bfdcf59-s7n65                       1/1     Running   0             14m
csi-attacher-5c4bfdcf59-w9xgs                       1/1     Running   0             14m
csi-provisioner-667796df57-fmz2d                    1/1     Running   0             14m
csi-provisioner-667796df57-p7rjr                    1/1     Running   0             14m
csi-provisioner-667796df57-w9fdq                    1/1     Running   0             14m
csi-resizer-694f8f5f64-2rb8v                        1/1     Running   0             14m
csi-resizer-694f8f5f64-z9v9x                        1/1     Running   0             14m
csi-resizer-694f8f5f64-zlncz                        1/1     Running   0             14m
csi-snapshotter-959b69d4b-5dpvj                     1/1     Running   0             14m
csi-snapshotter-959b69d4b-lwwkv                     1/1     Running   0             14m
csi-snapshotter-959b69d4b-tzhwc                     1/1     Running   0             14m
engine-image-ei-5cefaf2b-hvdv5                      1/1     Running   0             14m
instance-manager-0ee452a2e9583753e35ad00602250c5b   1/1     Running   0             14m
longhorn-csi-plugin-gd2jx                           3/3     Running   0             14m
longhorn-driver-deployer-9f4fc86-j6h2b              1/1     Running   0             15m
longhorn-manager-z4lnl                              1/1     Running   0             15m
longhorn-ui-5f4b7bbf69-bln7h                        1/1     Running   3 (14m ago)   15m
longhorn-ui-5f4b7bbf69-lh97n                        1/1     Running   3 (14m ago)   15m
volume-test                                         1/1     Running   0             26s

Si habéis instalado SUSE Storage con kubectl o Helm, debéis configurar un controlador de Ingress para permitir el tráfico externo al clúster. La autenticación no está habilitada de forma predeterminada. Si se utilizó la aplicación de catálogo de Rancher, Rancher creó automáticamente un controlador de Ingress con control de acceso (el rancher-proxy).

SUSE Telco Cloud utiliza Capítulo 12, Edge Image Builder para personalizar las imágenes base del SO SUSE Linux Micro. Vamos a demostrar cómo hacerlo para aprovisionar un clúster RKE2 con SUSE Storage sobre él.

Vamos a crear el archivo de definición:

export CONFIG_DIR=$HOME/eib
mkdir -p $CONFIG_DIR

cat << EOF > $CONFIG_DIR/iso-definition.yaml
apiVersion: 1.3
image:
  imageType: iso
  baseImage: SL-Micro.x86_64-6.2-Base-SelfInstall-GM.install.iso
  arch: x86_64
  outputImageName: eib-image.iso
kubernetes:
  version: v1.35.4+rke2r1
  helm:
    charts:
      - name: suse-storage
        releaseName: longhorn
        version: 1.11.2
        repositoryName: rancher-application-collection
        targetNamespace: longhorn-system
        createNamespace: true
        installationNamespace: kube-system
    repositories:
      - name: rancher-application-collection
        url: oci://dp.apps.rancher.io/charts
        authentication:
          username: $APPS.RANCHER.IO_USERNAME
          password: $APPS.RANCHER.IO_ACCESS_TOKEN
embeddedArtifactRegistry:
  registries:
    - uri: dp.apps.rancher.io
      authentication:
        username: $APPS.RANCHER.IO_USERNAME
        password: $APPS.RANCHER.IO_ACCESS_TOKEN
  images:
    - name: dp.apps.rancher.io/containers/kubernetes-csi-external-attacher:4.11.0-13.2
    - name: dp.apps.rancher.io/containers/kubernetes-csi-external-provisioner:5.3.0-14.1
    - name: dp.apps.rancher.io/containers/kubernetes-csi-external-resizer:2.1.0-6.2
    - name: dp.apps.rancher.io/containers/kubernetes-csi-external-snapshotter:8.5.0-13.2
    - name: dp.apps.rancher.io/containers/kubernetes-csi-livenessprobe:2.18.0-13.2
    - name: dp.apps.rancher.io/containers/kubernetes-csi-node-driver-registrar:2.16.0-13.2
    - name: dp.apps.rancher.io/containers/longhorn-backing-image-manager:1.11.2-4.1
    - name: dp.apps.rancher.io/containers/longhorn-engine:1.11.2-4.2
    - name: dp.apps.rancher.io/containers/longhorn-instance-manager:1.11.2-4.3
    - name: dp.apps.rancher.io/containers/longhorn-manager:1.11.2-4.2
    - name: dp.apps.rancher.io/containers/longhorn-share-manager:1.11.2-4.1
    - name: dp.apps.rancher.io/containers/longhorn-ui:1.11.2-4.1
    - name: dp.apps.rancher.io/containers/rancher-support-bundle-kit:0.0.84-9.4
operatingSystem:
  packages:
    sccRegistrationCode: <reg-code>
    packageList:
      - open-iscsi
  users:
  - username: root
    encryptedPassword: \$6\$jHugJNNd3HElGsUZ\$eodjVe4te5ps44SVcWshdfWizrP.xAyd71CVEXazBJ/.v799/WRCBXxfYmunlBO2yp1hm/zb4r8EmnrrNCF.P/
EOF

Nota

Es posible personalizar cualquiera de los valores del gráfico de Helm mediante un archivo independiente proporcionado en helm.charts[].valuesFile. Consulte la documentación en sentido ascendente para obtener información detallada.

Vamos a compilar la imagen:

podman run --rm --privileged -it -v $CONFIG_DIR:/eib registry.suse.com/edge/3.6/edge-image-builder:1.3.3.1 build --definition-file $CONFIG_DIR/iso-definition.yaml

Una vez compilada la imagen, podéis utilizarla para instalar vuestro SO en un host físico o virtual. Una vez completado el aprovisionamiento, podéis iniciar sesión en el sistema utilizando el par de credenciales root:eib.

Aseguraos de que SUSE Storage se haya desplegado correctamente:

localhost:~ # /var/lib/rancher/rke2/bin/kubectl --kubeconfig /etc/rancher/rke2/rke2.yaml -n longhorn-system get pods
NAME                                                READY   STATUS    RESTARTS        AGE
csi-attacher-5c4bfdcf59-qmjtz                       1/1     Running   0               103s
csi-attacher-5c4bfdcf59-s7n65                       1/1     Running   0               103s
csi-attacher-5c4bfdcf59-w9xgs                       1/1     Running   0               103s
csi-provisioner-667796df57-fmz2d                    1/1     Running   0               103s
csi-provisioner-667796df57-p7rjr                    1/1     Running   0               103s
csi-provisioner-667796df57-w9fdq                    1/1     Running   0               103s
csi-resizer-694f8f5f64-2rb8v                        1/1     Running   0               103s
csi-resizer-694f8f5f64-z9v9x                        1/1     Running   0               103s
csi-resizer-694f8f5f64-zlncz                        1/1     Running   0               103s
csi-snapshotter-959b69d4b-5dpvj                     1/1     Running   0               103s
csi-snapshotter-959b69d4b-lwwkv                     1/1     Running   0               103s
csi-snapshotter-959b69d4b-tzhwc                     1/1     Running   0               103s
engine-image-ei-5cefaf2b-hvdv5                      1/1     Running   0               109s
instance-manager-0ee452a2e9583753e35ad00602250c5b   1/1     Running   0               109s
longhorn-csi-plugin-gd2jx                           3/3     Running   0               103s
longhorn-driver-deployer-9f4fc86-j6h2b              1/1     Running   0               2m28s
longhorn-manager-z4lnl                              1/1     Running   0               2m28s
longhorn-ui-5f4b7bbf69-bln7h                        1/1     Running   3 (2m7s ago)    2m28s
longhorn-ui-5f4b7bbf69-lh97n                        1/1     Running   3 (2m10s ago)   2m28s

Nota

Esta instalación no funcionará en entornos completamente aislados. En esos casos, consultad Sección 63.8, “Instalación de SUSE Storage”.

SUSE Telco Cloud proporciona una configuración más ligera de SUSE Security como punto de partida para despliegues edge.

SUSE Telco Cloud utiliza Capítulo 12, Edge Image Builder para personalizar las imágenes base de SUSE Linux Micro OS. Sigan Sección 63.7, “Instalación de SUSE Security” para una instalación en entorno aislado de SUSE Security sobre clústeres de Kubernetes aprovisionados por EIB.

SUSE Telco Cloud utiliza MetalLB de tres formas clave:

Nota

Para poder exponer la API, se utiliza el Endpoint Copier Operator (Capítulo 18, Operador de Endpoint Copier) para mantener sincronizados los endpoints de la API de K8s desde el servicio kubernetes a un servicio del tipo LoadBalancer kubernetes-vip.

La instalación de MetalLB en modo L2 se describe en Capítulo 60, MetalLB en K3s (usando el modo de capa 2) y para el modo L3 en Capítulo 61, MetalLB en K3s (usando el modo de capa 3).

Puede encontrar una guía sobre la instalación de MetalLB delante de kube-api-server para lograr una topología de alta disponibilidad en Capítulo 62, MetalLB delante del servidor de API de Kubernetes.

En SUSE Telco Cloud, el Operador de Endpoint Copier desempeña un papel crucial para lograr una configuración de alta disponibilidad (HA) para clústeres K3s/RKE2. Esto se logra creando un servicio kubernetes-vip de tipo LoadBalancer, asegurando que su Endpoint permanezca en sincronización constante con el Endpoint de Kubernetes. Se aprovecha MetalLB (Capítulo 17, MetalLB) para gestionar el servicio kubernetes-vip, ya que la dirección IP expuesta se utiliza desde otros nodos para unirse al clúster.

La documentación completa para utilizar el Operador de Endpoint Copier se puede encontrar aquí.

Además, consulte nuestra guía (Capítulo 60, MetalLB en K3s (usando el modo de capa 2)) sobre cómo lograr una configuración de alta disponibilidad (HA) de K3s/RKE2 utilizando el Operador de Endpoint Copier y MetalLB.

Actualmente, el Operador de Endpoint Copier está limitado a trabajar con un solo Servicio/Endpoint. Se planean mejoras para admitir múltiples Servicios/Endpoints en el futuro.

KubeVirt permite gestionar máquinas virtuales con Kubernetes junto con el resto de sus cargas de trabajo en contenedores. Lo hace ejecutando la parte del espacio de usuario de la pila de virtualización de Linux en un contenedor. Esto minimiza los requisitos del sistema host, lo que permite una configuración y gestión más sencillas.

Si está siguiendo esta guía, asumimos que ya tiene disponible lo siguiente:

Esta guía no le explicará el despliegue de Kubernetes, pero asume que ha instalado la versión adecuada de SUSE Telco Cloud de K3s o RKE2 y que tiene su kubeconfig configurado en consecuencia para que los comandos estándar de kubectl se puedan ejecutar como superusuario. Asumimos que su nodo forma un clúster de un solo nodo, aunque no se esperan diferencias significativas para los despliegues de varios nodos.

SUSE Telco Cloud Virtualization se despliega mediante tres gráficos de Helm independientes, concretamente:

Cada uno de estos charts de Helm tiene una versión correspondiente a la versión de SUSE Telco Cloud que esté utilizando actualmente. Para un uso en producción o con soporte, emplee los artefactos que se pueden encontrar en el registro de SUSE.

Primero, asegúrese de que su acceso a kubectl funciona:

$ kubectl get nodes

Esto debería mostrar algo similar a lo siguiente:

NAME                   STATUS   ROLES                       AGE     VERSION
node1.edge.rdo.wales   Ready    control-plane,etcd,master   4h20m   v1.30.5+rke2r1
node2.edge.rdo.wales   Ready    control-plane,etcd,master   4h15m   v1.30.5+rke2r1
node3.edge.rdo.wales   Ready    control-plane,etcd,master   4h15m   v1.30.5+rke2r1

Ahora puede proceder a instalar los charts de Helm de KubeVirt y Containerized Data Importer (CDI):

$ helm install kubevirt oci://registry.suse.com/edge/charts/kubevirt --namespace kubevirt-system --create-namespace
$ helm install cdi oci://registry.suse.com/edge/charts/cdi --namespace cdi-system --create-namespace

En unos minutos, debería tener todos los componentes de KubeVirt y CDI desplegados. Puede validarlo comprobando todos los recursos desplegados en el espacio de nombres kubevirt-system y cdi-system.

Verificar los recursos de KubeVirt:

$ kubectl get all -n kubevirt-system

Esto debería mostrar algo similar a lo siguiente:

NAME                                   READY   STATUS    RESTARTS      AGE
pod/virt-operator-5fbcf48d58-p7xpm     1/1     Running   0             2m24s
pod/virt-operator-5fbcf48d58-wnf6s     1/1     Running   0             2m24s
pod/virt-handler-t594x                 1/1     Running   0             93s
pod/virt-controller-5f84c69884-cwjvd   1/1     Running   1 (64s ago)   93s
pod/virt-controller-5f84c69884-xxw6q   1/1     Running   1 (64s ago)   93s
pod/virt-api-7dfc54cf95-v8kcl          1/1     Running   1 (59s ago)   118s

NAME                                  TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)   AGE
service/kubevirt-prometheus-metrics   ClusterIP   None            <none>        443/TCP   2m1s
service/virt-api                      ClusterIP   10.43.56.140    <none>        443/TCP   2m1s
service/kubevirt-operator-webhook     ClusterIP   10.43.201.121   <none>        443/TCP   2m1s
service/virt-exportproxy              ClusterIP   10.43.83.23     <none>        443/TCP   2m1s

NAME                          DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   NODE SELECTOR            AGE
daemonset.apps/virt-handler   1         1         1       1            1           kubernetes.io/os=linux   93s

NAME                              READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/virt-operator     2/2     2            2           2m24s
deployment.apps/virt-controller   2/2     2            2           93s
deployment.apps/virt-api          1/1     1            1           118s

NAME                                         DESIRED   CURRENT   READY   AGE
replicaset.apps/virt-operator-5fbcf48d58     2         2         2       2m24s
replicaset.apps/virt-controller-5f84c69884   2         2         2       93s
replicaset.apps/virt-api-7dfc54cf95          1         1         1       118s

NAME                            AGE     PHASE
kubevirt.kubevirt.io/kubevirt   2m24s   Deployed

Verificar los recursos de CDI:

$ kubectl get all -n cdi-system

Esto debería mostrar algo similar a lo siguiente:

NAME                                   READY   STATUS    RESTARTS   AGE
pod/cdi-operator-55c74f4b86-692xb      1/1     Running   0          2m24s
pod/cdi-apiserver-db465b888-62lvr      1/1     Running   0          2m21s
pod/cdi-deployment-56c7d74995-mgkfn    1/1     Running   0          2m21s
pod/cdi-uploadproxy-7d7b94b968-6kxc2   1/1     Running   0          2m22s

NAME                             TYPE        CLUSTER-IP     EXTERNAL-IP   PORT(S)    AGE
service/cdi-uploadproxy          ClusterIP   10.43.117.7    <none>        443/TCP    2m22s
service/cdi-api                  ClusterIP   10.43.20.101   <none>        443/TCP    2m22s
service/cdi-prometheus-metrics   ClusterIP   10.43.39.153   <none>        8080/TCP   2m21s

NAME                              READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/cdi-operator      1/1     1            1           2m24s
deployment.apps/cdi-apiserver     1/1     1            1           2m22s
deployment.apps/cdi-deployment    1/1     1            1           2m21s
deployment.apps/cdi-uploadproxy   1/1     1            1           2m22s

NAME                                         DESIRED   CURRENT   READY   AGE
replicaset.apps/cdi-operator-55c74f4b86      1         1         1       2m24s
replicaset.apps/cdi-apiserver-db465b888      1         1         1       2m21s
replicaset.apps/cdi-deployment-56c7d74995    1         1         1       2m21s
replicaset.apps/cdi-uploadproxy-7d7b94b968   1         1         1       2m22s

Para verificar que las definiciones de recursos personalizadas (CRD) de VirtualMachine están desplegadas, puede validar con:

$ kubectl explain virtualmachine

Esto debería imprimir la definición del objeto VirtualMachine, que debería mostrarse de la siguiente manera:

GROUP:      kubevirt.io
KIND:       VirtualMachine
VERSION:    v1

DESCRIPTION:
    VirtualMachine handles the VirtualMachines that are not running or are in a
    stopped state The VirtualMachine contains the template to create the
    VirtualMachineInstance. It also mirrors the running state of the created
    VirtualMachineInstance in its status.
(snip)

Ahora que KubeVirt y CDI están desplegados, defina una máquina virtual sencilla basada en openSUSE Tumbleweed. Esta máquina virtual tiene la configuración más sencilla, utilizando la «red de pod» estándar para una configuración de red idéntica a la de cualquier otro pod. También emplea almacenamiento no persistente, lo que garantiza que el almacenamiento sea efímero, igual que en cualquier contenedor que no tenga un PVC.

$ cat <<EOF > user-data.yaml
#cloud-config
disable_root: false
ssh_pwauth: True
users:
  - default
  - name: suse
    groups: sudo
    shell: /bin/bash
    sudo:  ALL=(ALL) NOPASSWD:ALL
    lock_passwd: False
    plain_text_passwd: 'suse'
EOF
$ kubectl apply -f - <<EOF
apiVersion: kubevirt.io/v1
kind: VirtualMachine
metadata:
  name: tumbleweed
  namespace: default
spec:
  runStrategy: Always
  template:
    spec:
      domain:
        devices: {}
        machine:
          type: q35
        memory:
          guest: 2Gi
        resources: {}
      volumes:
      - containerDisk:
          image: quay.io/containerdisks/opensuse-tumbleweed:1.0.0
        name: tumbleweed-containerdisk-0
      - cloudInitNoCloud:
          userDataBase64: $(cat user-data.yaml | base64 -w 0)
        name: cloudinitdisk
EOF

Esto debería mostrar que se ha creado un VirtualMachine:

virtualmachine.kubevirt.io/tumbleweed created

Esta definición de VirtualMachine es mínima y especifica poco sobre la configuración. Simplemente describe que es un tipo de máquina « q35» con 2 GB de memoria que utiliza una imagen de disco basada en un containerDisk efímero (es decir, una imagen de disco que se almacena en una imagen de contenedor desde un repositorio de imágenes remoto), y especifica un disco cloudInit codificado en base64, que solo utilizamos para la creación de usuarios y la aplicación de contraseñas en el momento del arranque (utilice base64 -d para decodificarlo).

Esta máquina tarda unos minutos en arrancar, ya que necesita descargar la imagen de disco de openSUSE Tumbleweed, pero una vez hecho esto, puede ver más detalles sobre la máquina virtual comprobando la información de la máquina virtual:

$ kubectl get vmi

Esto debería mostrar el nodo en el que se inició la máquina virtual y la dirección IP de la máquina virtual. Recuerde que, dado que utiliza la red de pod, la dirección IP notificada será igual que la de cualquier otro pod, y enrutable como tal:

NAME         AGE     PHASE     IP           NODENAME               READY
tumbleweed   4m24s   Running   10.42.2.98   node3.edge.rdo.wales   True

Al ejecutar estos comandos en los propios nodos del clúster de Kubernetes, con una CNI que enruta el tráfico directamente a los pods (por ejemplo, Cilium), debería poder ssh directamente a la propia máquina. Sustituya la siguiente dirección IP por la que se ha asignado a su máquina virtual:

$ ssh suse@10.42.2.98
(password is "suse")

Una vez que esté en esta máquina virtual, podrá experimentar, pero recuerde que está limitada en cuanto a recursos y solo tiene 1 GB de espacio en disco. Cuando haya terminado, Ctrl-D o exit para desconectarse de la sesión SSH.

El proceso de la máquina virtual sigue estando envuelto en un pod estándar de Kubernetes. El CRD VirtualMachine es una representación de la máquina virtual deseada, pero el proceso en el que la máquina virtual se inicia realmente es a través del pod virt-launcher, un pod estándar de Kubernetes, igual que cualquier otra aplicación. Para cada máquina virtual iniciada, puede ver que hay un pod virt-launcher:

$ kubectl get pods

Esto debería mostrar entonces el pod virt-launcher para la máquina Tumbleweed que ha definido:

NAME                             READY   STATUS    RESTARTS   AGE
virt-launcher-tumbleweed-8gcn4   3/3     Running   0          10m

Si echa un vistazo a este pod virt-launcher, verá que está ejecutando los procesos libvirt y qemu-kvm. Puede entrar en el propio pod y echar un vistazo a lo que hay debajo, teniendo en cuenta que debe adaptar el siguiente comando para el nombre de su pod:

$ kubectl exec -it virt-launcher-tumbleweed-8gcn4 -- bash

Una vez que esté en el pod, intente ejecutar los comandos virsh además de observar los procesos. Verá el binario qemu-system-x86_64 en ejecución, junto con ciertos procesos para supervisar la máquina virtual. También verá la ubicación de la imagen de disco y cómo está conectada la red (como un dispositivo tap):

qemu@tumbleweed:/> ps ax
  PID TTY      STAT   TIME COMMAND
    1 ?        Ssl    0:00 /usr/bin/virt-launcher-monitor --qemu-timeout 269s --name tumbleweed --uid b9655c11-38f7-4fa8-8f5d-bfe987dab42c --namespace default --kubevirt-share-dir /var/run/kubevirt --ephemeral-disk-dir /var/run/kubevirt-ephemeral-disks --container-disk-dir /var/run/kube
   12 ?        Sl     0:01 /usr/bin/virt-launcher --qemu-timeout 269s --name tumbleweed --uid b9655c11-38f7-4fa8-8f5d-bfe987dab42c --namespace default --kubevirt-share-dir /var/run/kubevirt --ephemeral-disk-dir /var/run/kubevirt-ephemeral-disks --container-disk-dir /var/run/kubevirt/con
   24 ?        Sl     0:00 /usr/sbin/virtlogd -f /etc/libvirt/virtlogd.conf
   25 ?        Sl     0:01 /usr/sbin/virtqemud -f /var/run/libvirt/virtqemud.conf
   83 ?        Sl     0:31 /usr/bin/qemu-system-x86_64 -name guest=default_tumbleweed,debug-threads=on -S -object {"qom-type":"secret","id":"masterKey0","format":"raw","file":"/var/run/kubevirt-private/libvirt/qemu/lib/domain-1-default_tumbleweed/master-key.aes"} -machine pc-q35-7.1,usb
  286 pts/0    Ss     0:00 bash
  320 pts/0    R+     0:00 ps ax

qemu@tumbleweed:/> virsh list --all
 Id   Name                 State
------------------------------------
 1    default_tumbleweed   running

qemu@tumbleweed:/> virsh domblklist 1
 Target   Source
---------------------------------------------------------------------------------------------
 sda      /var/run/kubevirt-ephemeral-disks/disk-data/tumbleweed-containerdisk-0/disk.qcow2
 sdb      /var/run/kubevirt-ephemeral-disks/cloud-init-data/default/tumbleweed/noCloud.iso

qemu@tumbleweed:/> virsh domiflist 1
 Interface   Type       Source   Model                     MAC
------------------------------------------------------------------------------
 tap0        ethernet   -        virtio-non-transitional   e6:e9:1a:05:c0:92

qemu@tumbleweed:/> exit
exit

Por último, elimine esta máquina virtual para realizar una limpieza:

$ kubectl delete vm/tumbleweed
virtualmachine.kubevirt.io "tumbleweed" deleted

Junto con las herramientas CLI estándar de Kubernetes, es decir, kubectl, KubeVirt incluye una utilidad CLI complementaria que le permite interactuar con su clúster de una forma que salva algunas diferencias entre el mundo de la virtualización y el mundo para el que se diseñó Kubernetes. Por ejemplo, la herramienta virtctl ofrece la capacidad de gestionar el ciclo de vida de las máquinas virtuales (iniciar, detener, reiniciar, etc.), proporcionando acceso a las consolas virtuales, cargando imágenes de máquinas virtuales, así como interactuando con construcciones de Kubernetes como servicios, sin utilizar directamente la API o los CRD.

Descarguemos la última versión estable de la herramienta virtctl:

$ export VERSION=v0.7.0
$ wget https://github.com/kubevirt/kubevirt/releases/download/$VERSION/virtctl-$VERSION-linux-amd64

Si utilizáis una arquitectura diferente o una máquina que no sea Linux, podéis encontrar otras versiones aquí. Debes hacerlo ejecutable antes de continuar, y puede ser útil moverlo a una ubicación dentro de tu $PATH:

$ mv virtctl-$VERSION-linux-amd64 /usr/local/bin/virtctl
$ chmod a+x /usr/local/bin/virtctl

Entonces podrás utilizar la herramienta de línea de comandos virtctl para crear máquinas virtuales. Repliquemos nuestra máquina virtual anterior, teniendo en cuenta que estamos redirigiendo la salida directamente a kubectl apply:

$ cat <<EOF >  user-data.yaml
#cloud-config
disable_root: false
ssh_pwauth: True
users:
  - default
  - name: suse
    groups: sudo
    shell: /bin/bash
    sudo:  ALL=(ALL) NOPASSWD:ALL
    lock_passwd: False
    plain_text_passwd: 'suse'
EOF
$ alias virtctl=echo
$ virtctl create vm --name virtctl-example --memory=1Gi \
    --volume-containerdisk=src:quay.io/containerdisks/opensuse-tumbleweed:1.0.0 \
    --cloud-init-user-data "$(cat user-data.yaml | base64 -w 0)"

Esto debería mostrar entonces la máquina virtual ejecutándose (debería iniciarse mucho más rápido esta vez dado que la imagen del contenedor estará en caché):

$ kubectl get vmi
NAME              AGE   PHASE     IP           NODENAME               READY
virtctl-example   52s   Running   10.42.2.29   node3.edge.rdo.wales   True

Ahora podemos usar virtctl para conectar directamente a la máquina virtual:

$ virtctl ssh suse@virtctl-example
(password is "suse" - Ctrl-D to exit)

Hay muchos otros comandos que pueden ser utilizados por virtctl. Por ejemplo, virtctl console puede darte acceso a la consola serie si la red no funciona, y puedes usar virtctl guestosinfo para obtener información completa del sistema operativo, siempre que el invitado tenga instalado y en ejecución qemu-guest-agent.

Finalmente, pausemos y reanudemos la máquina virtual:

$ virtctl pause vm virtctl-example
VMI virtctl-example was scheduled to pause

Encuentras que el objeto VirtualMachine se muestra como Paused y el objeto VirtualMachineInstance se muestra como Running pero READY=False:

$ kubectl get vm
NAME              AGE     STATUS   READY
virtctl-example   8m14s   Paused   False

$ kubectl get vmi
NAME              AGE     PHASE     IP           NODENAME               READY
virtctl-example   8m15s   Running   10.42.2.29   node3.edge.rdo.wales   False

También encuentras que ya no puedes conectar a la máquina virtual:

$ virtctl ssh suse@virtctl-example
can't access VMI virtctl-example: Operation cannot be fulfilled on virtualmachineinstance.kubevirt.io "virtctl-example": VMI is paused

Reanudemos la máquina virtual e intentémoslo de nuevo:

$ virtctl unpause vm virtctl-example
VMI virtctl-example was scheduled to unpause

Ahora deberíamos poder restablecer una conexión:

$ virtctl ssh suse@virtctl-example
suse@vmi/virtctl-example.default's password:
suse@virtctl-example:~> exit
logout

Finalmente, eliminemos la máquina virtual:

$ kubectl delete vm/virtctl-example
virtualmachine.kubevirt.io "virtctl-example" deleted

En esta sección, mostramos cómo puedes exponer máquinas virtuales como servicios estándar de Kubernetes y hacerlas disponibles a través del servicio Ingress de Kubernetes, por ejemplo, Traefik con RKE2 o Traefik con K3s. Este documento asume que estos componentes ya están configurados adecuadamente y que tienes un puntero DNS apropiado, por ejemplo, mediante un carácter comodín, para apuntar a tus nodos de servidor de Kubernetes o a tu IP virtual de ingress para una adecuada resolución de ingress.

En el entorno de ejemplo, se despliega otra máquina virtual openSUSE Tumbleweed, se utiliza cloud-init para instalar NGINX como un servidor web simple en el momento del arranque, y se configura un mensaje simple para que se devuelva y verificar que funciona como se espera cuando se realiza una llamada. Para ver cómo se hace esto, simplemente base64 -d la sección cloud-init en la salida siguiente.

Creemos esta máquina virtual ahora:

$ cat <<EOF > user-data.yaml
#cloud-config
disable_root: false
ssh_pwauth: True
users:
  - default
  - name: suse
    groups: sudo
    shell: /bin/bash
    sudo:  ALL=(ALL) NOPASSWD:ALL
    lock_passwd: False
    plain_text_passwd: 'suse'
EOF
$ kubectl apply -f - <<EOF
apiVersion: kubevirt.io/v1
kind: VirtualMachine
metadata:
  name: ingress-example
  namespace: default
spec:
  runStrategy: Always
  template:
    metadata:
      labels:
        app: nginx
    spec:
      domain:
        devices: {}
        machine:
          type: q35
        memory:
          guest: 2Gi
        resources: {}
      volumes:
      - containerDisk:
          image: quay.io/containerdisks/opensuse-tumbleweed:1.0.0
        name: tumbleweed-containerdisk-0
      - cloudInitNoCloud:
          userDataBase64: $(cat user-data.yaml | base64 -w 0)
        name: cloudinitdisk
EOF

Cuando esta máquina virtual se haya iniciado correctamente, podemos usar el comando virtctl para exponer la VirtualMachineInstance con un puerto externo de 8080 y un puerto de destino de 80 (donde NGINX escucha por defecto). Usamos el comando virtctl aquí ya que entiende la asignación entre el objeto de la máquina virtual y el pod. Esto crea un nuevo servicio para nosotros:

$ virtctl expose vmi ingress-example --port=8080 --target-port=80 --name=ingress-example
Service ingress-example successfully exposed for vmi ingress-example

Entonces tendremos un servicio apropiado creado automáticamente:

$ kubectl get svc/ingress-example
NAME              TYPE           CLUSTER-IP      EXTERNAL-IP       PORT(S)                         AGE
ingress-example   ClusterIP      10.43.217.19    <none>            8080/TCP                        9s

A continuación, si utilizas kubectl create ingress, podemos crear un objeto Ingress que apunte a este servicio. Adaptad la URL (conocida como "host" en el objeto ingress) aquí para que coincida con vuestra configuración DNS y aseguraos de apuntarla al puerto 8080:

$ kubectl create ingress ingress-example --rule=ingress-example.suse.local/=ingress-example:8080

Con el DNS configurado correctamente, deberíais poder hacer curl a la URL inmediatamente:

$ curl ingress-example.suse.local
It works!

Vamos a realizar una limpieza eliminando esta máquina virtual y sus recursos de servicio e ingress:

$ kubectl delete vm/ingress-example svc/ingress-example ingress/ingress-example
virtualmachine.kubevirt.io "ingress-example" deleted
service "ingress-example" deleted
ingress.networking.k8s.io "ingress-example" deleted

SUSE Telco Cloud Virtualization proporciona una extensión de la UI para Rancher Manager, que permite la gestión básica de máquinas virtuales mediante la interfaz del panel de control de Rancher.

19.7.2 Uso de la extensión de la UI de KubeVirt Rancher #

 

La extensión introduce una nueva sección KubeVirt en el Explorador de clústeres. Esta sección se añade a cualquier clúster downstream que tenga KubeVirt instalado.

La extensión os permite interactuar directamente con los recursos de máquinas virtuales de KubeVirt para gestionar el ciclo de vida de las máquinas virtuales.

19.7.2.1 Creación de una máquina virtual #

 

1. Navegad al Explorador de clústeres haciendo clic en el clúster downstream habilitado para KubeVirt en la navegación de la izquierda.

2. Navegad a la página KubeVirt > Máquinas virtuales y haced clic en Create from YAML en la parte superior derecha de la pantalla.

3. Rellenad o pegad una definición de máquina virtual y pulsad Create. Utilizad la definición de máquina virtual de la sección Desplegar máquinas virtuales como inspiración.

19.7.2.2 Acciones de la máquina virtual #

 

Podéis utilizar el menú de acciones al que se accede desde la lista desplegable ⋮ a la derecha de cada máquina virtual para realizar acciones de inicio, terminar, pausa o reinicio suave. Alternativamente, también podéis utilizar las acciones de grupo en la parte superior de la lista seleccionando las máquinas virtuales sobre las que realizar la acción.

Realizar las acciones puede tener un efecto en la Estrategia de ejecución de la máquina virtual. Consultad la tabla en la documentación de KubeVirt para obtener más detalles.

19.7.2.3 Acceso a la consola de la máquina virtual #

 

La lista de «Máquinas virtuales» proporciona una lista desplegable Console que permite conectar a la máquina utilizando VNC o consola serie. Esta acción solo está disponible para máquinas en ejecución.

En algunos casos, pasa un breve periodo de tiempo antes de que la consola esté accesible en una máquina virtual recién iniciada.

SUSE Telco Cloud utiliza Capítulo 12, Edge Image Builder para personalizar las imágenes base del SO SUSE Linux Micro. Seguid Sección 63.9, “Instalación de KubeVirt y CDI” para una instalación en un entorno aislado tanto de KubeVirt como de CDI sobre clústeres de Kubernetes aprovisionados por EIB.

SUSE Telco Cloud utiliza SUC para facilitar diversas operaciones de "Día 2" relacionadas con las actualizaciones de la versión del SO y de Kubernetes en los clústeres de gestión y de sentido descendente.

Las operaciones de "Día 2" se definen a través de SUC Plans. Basándose en estos planes, SUC despliega cargas de trabajo en cada nodo para ejecutar la operación de "Día 2" correspondiente.

SUC también se utiliza dentro de Capítulo 21, Controlador de actualización. Para obtener más información sobre las diferencias clave entre SUC y el controlador de actualización del sistema, véase Sección 21.2, “Controlador de actualización frente a System Upgrade Controller”.

Importante

A partir de Rancher v2.10.0, el System Upgrade Controller se instala automáticamente.

Seguid los pasos a continuación solo si vuestro entorno no está gestionado por Rancher, o si vuestra versión de Rancher es inferior a v2.10.0.

Recomendamos que instaléis SUC a través de Fleet (Capítulo 9, Fleet) ubicado en el repositorio suse-edge/fleet-examples.

Nota

Los recursos ofrecidos por el repositorio suse-edge/fleet-examples deben utilizarse siempre desde una versión de fleet-examples válida. Para determinar qué versión necesitáis utilizar, consultad las Notas de la versión (Capítulo 75, Notas de la versión).

Si no podéis utilizar Fleet para la instalación de SUC, podéis instalarlo a través del repositorio de charts de Helm de Rancher, o incorporar el chart de Helm de Rancher en vuestro propio flujo de trabajo GitOps de terceros.

Esta sección cubre:

20.2.1 Instalación de Fleet del controlador de actualización del sistema #

 

Utilizando Fleet, hay dos recursos posibles que se pueden usar para desplegar SUC:

• Recurso GitRepo: para casos de uso en los que hay disponible un servidor Git externo/local. Para obtener instrucciones de instalación, consultad Instalación del controlador de actualización del sistema - GitRepo (Sección 20.2.1.1, “Instalación del controlador de actualización del sistema - GitRepo”).

• Recurso Bundle: para casos de uso en entornos aislados que no admiten una opción de servidor Git local. Para obtener instrucciones de instalación, consultad Instalación del controlador de actualización del sistema - Bundle (Sección 20.2.1.2, “Instalación del controlador de actualización del sistema - Bundle”).

20.2.1.1 Instalación del controlador de actualización del sistema - GitRepo #

 

Nota

Este proceso también puede realizarse a través de la interfaz de usuario de Rancher, si está disponible. Para obtener más información, consultad Acceso a Fleet en la interfaz de usuario de Rancher.

En vuestro clúster de gestión:

1. Determinad en qué clústeres queréis desplegar SUC. Esto se hace desplegando un recurso GitRepo de SUC en el espacio de trabajo de Fleet correcto en vuestro clúster de gestión. Por defecto, Fleet tiene dos espacios de trabajo:

   • fleet-local - para recursos que deban desplegarse en el clúster de gestión.

   • fleet-default - para recursos que deban desplegarse en clústeres sentido descendente.

     Para obtener más información sobre los espacios de trabajo de Fleet, consultad la documentación sentido ascendente.

2. Despliega el recurso GitRepo:

   • Para desplegar SUC en vuestro clúster de gestión:

     kubectl apply -n fleet-local -f - <<EOF
     apiVersion: fleet.cattle.io/v1alpha1
     kind: GitRepo
     metadata:
       name: system-upgrade-controller
     spec:
       revision: release-3.6.1
       paths:
       - fleets/day2/system-upgrade-controller
       repo: https://github.com/suse-edge/fleet-examples.git
     EOF

   • Para desplegar SUC en vuestros clústeres de sentido descendente:

     

     Nota

     Antes de desplegar el recurso siguiente, debéis proporcionar una configuración targets válida, para que Fleet sepa en qué clústeres de sentido descendente desplegar vuestro recurso. Para obtener información sobre cómo realizar el mapeo a clústeres de sentido descendente, consultad Mapping to Downstream Clusters.

     kubectl apply -n fleet-default -f - <<EOF
     apiVersion: fleet.cattle.io/v1alpha1
     kind: GitRepo
     metadata:
       name: system-upgrade-controller
     spec:
       revision: release-3.6.1
       paths:
       - fleets/day2/system-upgrade-controller
       repo: https://github.com/suse-edge/fleet-examples.git
       targets:
       - clusterSelector: CHANGEME
       # Example matching all clusters:
       # targets:
       # - clusterSelector: {}
     EOF

3. Validad que el recurso GitRepo esté desplegado:

   # Namespace will vary based on where you want to deploy SUC
   kubectl get gitrepo system-upgrade-controller -n <fleet-local/fleet-default>
   
   NAME                        REPO                                              COMMIT          BUNDLEDEPLOYMENTS-READY   STATUS
   system-upgrade-controller   https://github.com/suse-edge/fleet-examples.git   release-3.6.1   1/1

4. Validad el despliegue del controlador de actualización del sistema:

   kubectl get deployment system-upgrade-controller -n cattle-system
   NAME                        READY   UP-TO-DATE   AVAILABLE   AGE
   system-upgrade-controller   1/1     1            1           2m20s

20.2.1.2 Instalación del controlador de actualización del sistema - Bundle #

 

Esta sección ilustra cómo crear y desplegar un recurso Bundle a partir de una configuración estándar de Fleet utilizando la fleet-cli.

1. En una máquina con acceso a la red, descarga el fleet-cli:

   

   Nota

   Aseguraos de que la versión de fleet-cli que descarguéis coincida con la versión de Fleet que se ha desplegado en vuestro clúster.

   • Para usuarios de Mac, existe una fleet-cli Homebrew Formulae.

   • Para usuarios de Linux y Windows, los binarios están presentes como assets en cada release de Fleet.

     • Linux AMD:

       curl -L -o fleet-cli https://github.com/rancher/fleet/releases/download/vv0.15.2/fleet-linux-amd64

     • Linux ARM:

       curl -L -o fleet-cli https://github.com/rancher/fleet/releases/download/vv0.15.2/fleet-linux-arm64

2. Haced que fleet-cli sea ejecutable:

   chmod +x fleet-cli

3. Clonad la suse-edge/fleet-examples release que deseéis utilizar:

   git clone -b release-3.6.1 https://github.com/suse-edge/fleet-examples.git

4. Navegad al repositorio SUC fleet, ubicado en el fleet-examples:

   cd fleet-examples/fleets/day2/system-upgrade-controller

5. Determinad en qué clústeres queréis desplegar SUC. Esto se hace desplegando el Bundle de SUC en el espacio de trabajo de Fleet correcto dentro de vuestro clúster de gestión. Por defecto, Fleet tiene dos espacios de trabajo:

   • fleet-local - para recursos que deban desplegarse en el clúster de gestión.

   • fleet-default - para recursos que deban desplegarse en clústeres downstream.

     Para obtener más información sobre los espacios de trabajo de Fleet, consulta la documentación sentido ascendente.

6. Si tenéis la intención de desplegar SUC solo en clústeres de sentido descendente, cread un archivo targets.yaml que coincida con los clústeres específicos:

   cat > targets.yaml <<EOF
   targets:
   - clusterSelector: CHANGEME
   EOF

   Para obtener información sobre cómo realizar el mapeo a clústeres de sentido descendente, consultad Mapping to Downstream Clusters

7. Proceded a compilar el Bundle:

   

   Nota

   Aseguraos de no descargar fleet-cli en el directorio fleet-examples/fleets/day2/system-upgrade-controller, de lo contrario se empaquetará con el Bundle, lo cual no es recomendable.

   • Para desplegar SUC en vuestro clúster de gestión, ejecutad:

     fleet-cli apply --compress -n fleet-local -o - system-upgrade-controller . > system-upgrade-controller-bundle.yaml

   • Para desplegar SUC en vuestros clústeres de sentido descendente, ejecutad:

     fleet-cli apply --compress --targets-file=targets.yaml -n fleet-default -o - system-upgrade-controller . > system-upgrade-controller-bundle.yaml

     Para obtener más información sobre este proceso, consultad Convert a Helm Chart into a Bundle.

     Para obtener más información sobre el comando fleet-cli apply, consultad fleet apply.

8. Transferid el Bundle system-upgrade-controller-bundle.yaml a la máquina de vuestro clúster de gestión:

   scp system-upgrade-controller-bundle.yaml <machine-address>:<filesystem-path>

9. En vuestro clúster de gestión, desplegad el Bundle system-upgrade-controller-bundle.yaml:

   kubectl apply -f system-upgrade-controller-bundle.yaml

10. En vuestro clúster de gestión, validad que el Bundle esté desplegado:

    # Namespace will vary based on where you want to deploy SUC
    kubectl get bundle system-upgrade-controller -n <fleet-local/fleet-default>
    
    NAME                        BUNDLEDEPLOYMENTS-READY   STATUS
    system-upgrade-controller   1/1

11. Según el espacio de trabajo de Fleet en el que hayáis desplegado vuestro Bundle, navegad al clúster y validad el despliegue de SUC:

    

    Nota

    SUC siempre se despliega en el espacio de nombres cattle-system.

    kubectl get deployment system-upgrade-controller -n cattle-system
    NAME                        READY   UP-TO-DATE   AVAILABLE   AGE
    system-upgrade-controller   1/1     1            1           111s

Los planes SUC pueden visualizarse de las siguientes formas:

Importante

Los Pods desplegados para los planes SUC se mantienen activos 15 minutos después de una ejecución correcta. Después de eso, son eliminados por el Job correspondiente que los creó. Para tener acceso a los registros del Pod después de este periodo de tiempo, debéis habilitar el registro para vuestro clúster. Para obtener información sobre cómo hacerlo en Rancher, consultad Rancher Integration with Logging Services.

20.3.2 Planes del Upgrade Controller del sistema de monitorización - Manual #

 

Nota

Los siguientes pasos asumen que kubectl se ha configurado para conectarse al clúster donde se han desplegado los SUC Plans.

1. Listar los planes SUC desplegados:

   kubectl get plans -n cattle-system

2. Obtener el pod para el plan SUC:

   kubectl get pods -l upgrade.cattle.io/plan=<plan_name> -n cattle-system

   

   Nota

   Puede haber ambos pods Completed y Unknown para un plan SUC específico. Esto es normal y ocurre debido a la naturaleza de algunas de las actualizaciones.

3. Obtener los registros del pod:

   kubectl logs <pod_name> -n cattle-system

El Controlador de actualización es esencial para automatizar las operaciones de «Día 2» (anteriormente manuales) necesarias para actualizar los clústeres de gestión de una versión de lanzamiento SUSE Telco Cloud a la siguiente.

Para lograr esta automatización, el Controlador de actualización utiliza herramientas como el System Upgrade Controller (Capítulo 20, Controlador de actualización del sistema) y el Helm Controller.

Para obtener más detalles sobre cómo funciona el Controlador de actualización, consulte Sección 21.5, “¿Cómo funciona el Controlador de actualización?”.

Para conocer las limitaciones que tiene el Controlador de actualización, consulte Sección 21.8, “Limitaciones conocidas”.

Para obtener información sobre la diferencia entre el Controlador de actualización y el System Upgrade Controller, consulte Sección 21.2, “Controlador de actualización frente a System Upgrade Controller”.

El System Upgrade Controller (SUC) (Capítulo 20, Controlador de actualización del sistema) es una herramienta de propósito general que propaga instrucciones de actualización a nodos específicos de Kubernetes.

Aunque admite algunas operaciones de «Día 2» para la plataforma SUSE Telco Cloud, no las cubre todas. Además, incluso para las operaciones admitidas, los usuarios deben configurar, mantener y desplegar manualmente múltiples SUC Plans: un proceso propenso a errores que puede dar lugar a problemas inesperados.

Esto llevó a la necesidad de una herramienta que automatice y abstraiga la complejidad de gestionar diversas operaciones de «Día 2» para la plataforma SUSE Telco Cloud. Por tanto, se desarrolló el Upgrade Controller. Simplifica el proceso de actualización al introducir un único user-facing resource que dirige la actualización. Los usuarios solo necesitan gestionar este recurso, mientras que el Upgrade Controller se encarga del resto.

Como alternativa a la instalación manual descrita anteriormente, es posible instalar el Controlador de actualización como parte del despliegue inicial orquestado por Edge Image Builder (Capítulo 12, Edge Image Builder).

En este caso, es necesario añadir la siguiente configuración de helm chart al archivo de configuración de EIB:

kubernetes:
  helm:
    charts:
      - name: cert-manager
        repositoryName: jetstack
        version: {version-cert-manager}
        targetNamespace: cert-manager
        valuesFile: certmanager-values.yaml
        createNamespace: true
        installationNamespace: kube-system
      - name: upgrade-controller
        version: {version-upgrade-controller-chart}
        repositoryName: suse-edge-charts
        targetNamespace: upgrade-controller-system
        createNamespace: true
        installationNamespace: kube-system

Para realizar una actualización de la versión de Edge, el Upgrade Controller introduce dos nuevos recursos personalizados de Kubernetes:

El Upgrade Controller procede a crear un recurso ReleaseManifest que contiene los datos de los componentes para la versión de Edge especificada por el usuario en la propiedad releaseVersion del recurso UpgradePlan.

Utilizando los datos de los componentes del ReleaseManifest, el Upgrade Controller procede a actualizar los componentes de la versión de Edge en el siguiente orden:

Nota

Durante el proceso de actualización, el Upgrade Controller envía continuamente información de actualización al UpgradePlan creado. Para obtener más información sobre cómo realizar el seguimiento del proceso de actualización, véase Seguimiento del proceso de actualización (Sección 21.7, “Seguimiento del proceso de actualización”).

21.5.1 Actualización del sistema operativo #

 

Para actualizar el sistema operativo, el Controlador de actualización crea planes SUC (Capítulo 20, Controlador de actualización del sistema) que tienen la siguiente plantilla de nomenclatura:

• Para planes SUC relacionados con actualizaciones del SO de los nodos del plano de control: control-plane-<os-name>-<os-version>-<suffix>.

• Para planes SUC relacionados con actualizaciones del SO de los nodos trabajadores: workers-<os-name>-<os-version>-<suffix>.

Basándose en estos planes, SUC procede a crear cargas de trabajo en cada nodo del clúster que realizan la actualización real del SO.

Dependiendo del ReleaseManifest, la actualización del SO puede incluir:

• Actualizaciones solo de paquetes: para casos de uso en los que la versión del SO no cambia entre versiones de Edge.

• Migración completa del SO: para casos de uso en los que la versión del SO cambia entre versiones de Edge.

La actualización se ejecuta uno a uno, empezando primero por los nodos del plano de control. Solo si finaliza la actualización del nodo del plano de control, comenzarán a actualizarse los nodos trabajadores.

Nota

El controlador de actualización configura los planes SUC del SO para realizar un vaciado de los nodos del clúster si este tiene más de un nodo del tipo especificado.

Para clústeres en los que los nodos del plano de control son más de uno y solo hay un nodo trabajador, se realizará un vaciado solo para los nodos del plano de control y viceversa.

Para obtener información sobre cómo desactivar por completo los vaciados de nodos, consulte la sección UpgradePlan (Sección 21.6.1, “UpgradePlan”).

21.5.2 Actualización de versión de Kubernetes #

 

Para actualizar la distribución de Kubernetes de un clúster, el controlador de actualización crea planes SUC (Capítulo 20, Controlador de actualización del sistema) que tienen la siguiente plantilla de nomenclatura:

• Para planes SUC relacionados con actualizaciones de versión de Kubernetes de nodos del plano de control: control-plane-<k8s-version>-<suffix>.

• Para planes SUC relacionados con actualizaciones de versión de Kubernetes de nodos trabajadores: workers-<k8s-version>-<suffix>.

Basándose en estos planes, SUC procede a crear cargas de trabajo en cada nodo del clúster que realizan la actualización de versión de Kubernetes propiamente dicha.

La actualización de versión de Kubernetes se realizará uno a uno, empezando primero por los nodos del plano de control. Solo si finaliza la actualización de versión del nodo del plano de control, comenzarán a actualizarse los nodos trabajadores.

Nota

El controlador de actualización configura los planes SUC de Kubernetes para realizar un vaciado de los nodos del clúster si este tiene más de un nodo del tipo especificado.

Para clústeres en los que los nodos del plano de control son más de uno y solo hay un nodo trabajador, se realizará un vaciado solo para los nodos del plano de control y viceversa.

Para obtener información sobre cómo desactivar por completo los vaciados de nodos, consulte Sección 21.6.1, “UpgradePlan”.

Extensiones de la API de Kubernetes introducidas por el controlador de actualización.

21.6.2 ReleaseManifest #

 

El Upgrade Controller introduce un nuevo recurso personalizado de Kubernetes llamado ReleaseManifest.

El recurso ReleaseManifest es creado por el Upgrade Controller y contiene datos de componentes para una versión de lanzamiento de Edge específica. Esto significa que cada actualización de la versión de lanzamiento de Edge estará representada por un recurso ReleaseManifest diferente.

Aviso

El Release Manifest siempre debe ser creado por el Upgrade Controller.

No es aconsejable crear o editar manualmente los recursos ReleaseManifest. Los usuarios que decidan hacerlo deben hacerlo bajo su propio riesgo.

Los datos de los componentes que incluye el Release Manifest incluyen, entre otros:

• Datos del sistema operativo: versión, arquitecturas compatibles, datos de actualización adicionales, etc.

• Datos de distribución de Kubernetes: versiones compatibles de RKE2/K3s

• Datos de componentes adicionales: datos de los gráficos de Helm de SUSE (ubicación, versión, nombre, etc.)

Para ver un ejemplo de cómo puede ser un Release Manifest, consulte la documentación sentido ascendente. Tenga en cuenta que esto es solo un ejemplo y no pretende ser creado como un recurso ReleaseManifest válido.

Esta sección sirve como medio para realizar el seguimiento y depurar el proceso de actualización que el Upgrade Controller inicia una vez que el usuario crea un UpgradePlan recurso.

kubectl get upgradeplan <upgradeplan_name> -n upgrade-controller-system -o yaml

apiVersion: lifecycle.suse.com/v1alpha1
kind: UpgradePlan
metadata:
  name: upgrade-plan-mgmt
  namespace: upgrade-controller-system
spec:
  releaseVersion: 3.6
status:
  conditions:
  - lastTransitionTime: "2024-10-01T06:26:27Z"
    message: Control plane nodes are being upgraded
    reason: InProgress
    status: "False"
    type: OSUpgraded
  - lastTransitionTime: "2024-10-01T06:26:27Z"
    message: Kubernetes upgrade is not yet started
    reason: Pending
    status: Unknown
    type: KubernetesUpgraded
  - lastTransitionTime: "2024-10-01T06:26:27Z"
    message: Rancher upgrade is not yet started
    reason: Pending
    status: Unknown
    type: RancherUpgraded
  - lastTransitionTime: "2024-10-01T06:26:27Z"
    message: Longhorn upgrade is not yet started
    reason: Pending
    status: Unknown
    type: LonghornUpgraded
  - lastTransitionTime: "2024-10-01T06:26:27Z"
    message: MetalLB upgrade is not yet started
    reason: Pending
    status: Unknown
    type: MetalLBUpgraded
  - lastTransitionTime: "2024-10-01T06:26:27Z"
    message: CDI upgrade is not yet started
    reason: Pending
    status: Unknown
    type: CDIUpgraded
  - lastTransitionTime: "2024-10-01T06:26:27Z"
    message: KubeVirt upgrade is not yet started
    reason: Pending
    status: Unknown
    type: KubeVirtUpgraded
  - lastTransitionTime: "2024-10-01T06:26:27Z"
    message: NeuVector upgrade is not yet started
    reason: Pending
    status: Unknown
    type: NeuVectorUpgraded
  - lastTransitionTime: "2024-10-01T06:26:27Z"
    message: EndpointCopierOperator upgrade is not yet started
    reason: Pending
    status: Unknown
    type: EndpointCopierOperatorUpgraded
  - lastTransitionTime: "2024-10-01T06:26:27Z"
    message: Elemental upgrade is not yet started
    reason: Pending
    status: Unknown
    type: ElementalUpgraded
  - lastTransitionTime: "2024-10-01T06:26:27Z"
    message: SRIOV upgrade is not yet started
    reason: Pending
    status: Unknown
    type: SRIOVUpgraded
  - lastTransitionTime: "2024-10-01T06:26:27Z"
    message: Metal3 upgrade is not yet started
    reason: Pending
    status: Unknown
    type: Metal3Upgraded
  - lastTransitionTime: "2024-10-01T06:26:27Z"
    message: RancherTurtles upgrade is not yet started
    reason: Pending
    status: Unknown
    type: RancherTurtlesUpgraded
  observedGeneration: 1
  sucNameSuffix: 90315a2b6d

apiVersion: lifecycle.suse.com/v1alpha1
kind: UpgradePlan
metadata:
  name: upgrade-plan-mgmt
  namespace: upgrade-controller-system
spec:
  releaseVersion: 3.6
status:
  conditions:
  - lastTransitionTime: "2024-10-01T06:26:48Z"
    message: All cluster nodes are upgraded
    reason: Succeeded
    status: "True"
    type: OSUpgraded
  - lastTransitionTime: "2024-10-01T06:26:59Z"
    message: All cluster nodes are upgraded
    reason: Succeeded
    status: "True"
    type: KubernetesUpgraded
  - lastTransitionTime: "2024-10-01T06:27:13Z"
    message: Chart rancher upgrade succeeded
    reason: Succeeded
    status: "True"
    type: RancherUpgraded
  - lastTransitionTime: "2024-10-01T06:27:13Z"
    message: Chart longhorn is not installed
    reason: Skipped
    status: "False"
    type: LonghornUpgraded
  - lastTransitionTime: "2024-10-01T06:27:13Z"
    message: Specified version of chart metallb is already installed
    reason: Skipped
    status: "False"
    type: MetalLBUpgraded
  - lastTransitionTime: "2024-10-01T06:27:13Z"
    message: Chart cdi is not installed
    reason: Skipped
    status: "False"
    type: CDIUpgraded
  - lastTransitionTime: "2024-10-01T06:27:13Z"
    message: Chart kubevirt is not installed
    reason: Skipped
    status: "False"
    type: KubeVirtUpgraded
  - lastTransitionTime: "2024-10-01T06:27:13Z"
    message: Chart neuvector-crd is not installed
    reason: Skipped
    status: "False"
    type: NeuVectorUpgraded
  - lastTransitionTime: "2024-10-01T06:27:14Z"
    message: Specified version of chart endpoint-copier-operator is already installed
    reason: Skipped
    status: "False"
    type: EndpointCopierOperatorUpgraded
  - lastTransitionTime: "2024-10-01T06:27:14Z"
    message: Chart elemental-operator upgrade succeeded
    reason: Succeeded
    status: "True"
    type: ElementalUpgraded
  - lastTransitionTime: "2024-10-01T06:27:15Z"
    message: Chart sriov-crd is not installed
    reason: Skipped
    status: "False"
    type: SRIOVUpgraded
  - lastTransitionTime: "2024-10-01T06:27:19Z"
    message: Chart metal3 is not installed
    reason: Skipped
    status: "False"
    type: Metal3Upgraded
  - lastTransitionTime: "2024-10-01T06:27:27Z"
    message: Chart rancher-turtles is not installed
    reason: Skipped
    status: "False"
    type: RancherTurtlesUpgraded
  lastSuccessfulReleaseVersion: 3.6
  observedGeneration: 1
  sucNameSuffix: 90315a2b6d

21.7.2 Controlador de Helm #

 

Esta sección trata sobre cómo realizar el seguimiento de los recursos creados por el helm-controller.

Nota

Los pasos siguientes asumen que kubectl se ha configurado para conectarse al clúster donde se ha desplegado el Upgrade Controller.

1. Localice el recurso HelmChart para el componente específico:

   kubectl get helmcharts -n kube-system

2. Utilizando el nombre del recurso HelmChart, localice el Pod de actualización que fue creado por el helm-controller:

   kubectl get pods -l helmcharts.helm.cattle.io/chart=<helmchart_name> -n kube-system
   
   # Example for Rancher
   kubectl get pods -l helmcharts.helm.cattle.io/chart=rancher -n kube-system
   NAME                         READY   STATUS      RESTARTS   AGE
   helm-install-rancher-tv9wn   0/1     Completed   0          16m

3. Vea los registros del pod específico del componente:

   kubectl logs <pod_name> -n kube-system

La siguiente tabla enumera los puertos abiertos en los nodos que ejecutan el clúster de gestión:

Nota

Para los puertos relacionados con el complemento CNI, véase Requisitos de puerto específicos de CNI (Sección 24.3, “Requisitos de puerto específicos de CNI”).

⁽¹⁾ BMC: Controlador de gestión de placa base
⁽²⁾ IPA: Ironic Python Agent

En SUSE Telco Cloud, antes de que cualquier servidor en sentido descendente pase a formar parte de un clúster de Kubernetes en sentido descendente en ejecución (o ejecute por sí mismo un clúster de Kubernetes en sentido descendente de nodo único), es necesario que pase por algunos de los estados de aprovisionamiento de BaremetalHost.

Se espera que los siguientes puertos estén expuestos desde el BMC (podrían diferir dependiendo del hardware exacto):

Nota

Para los puertos relacionados con el complemento CNI, véase Requisitos de puerto específicos de CNI (Sección 24.3, “Requisitos de puerto específicos de CNI”).