Rancher proporciona varias funcionalidades principales a la pila SUSE Edge:

SUSE Edge utiliza Capítulo 8, Edge Image Builder para personalizar las imágenes base del sistema operativo SUSE Linux Micro. Siga Sección 25.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 Edge 3.6 , incluidas las extensiones del Dashboard, se distribuyen como artefactos OCI. Para instalar las extensiones SUSE Edge, puede utilizar la interfaz de usuario de Rancher Dashboard, Helm o Fleet:

5.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.

5.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 6, 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 17.7.2, “Uso de la extensión de la UI de KubeVirt Rancher”.

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 Edge 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 2, 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 IV, “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 Edge 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 Edge utiliza nmc para las personalizaciones de red en los diversos modelos de aprovisionamiento: * Configuraciones estáticas declarativas en los escenarios de aprovisionamiento basado en imágenes (Capítulo 2, 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

9.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

9.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 9.5.3, “Creación del directorio de configuración de la imagen” hasta Sección 9.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

Utilizamos partes de Elemental para gestionar dispositivos remotos donde Metal³ no es una opción (por ejemplo, no hay BMC, o el dispositivo está detrás de un gateway NAT). Esta herramienta permite a un operador iniciar sus dispositivos en un laboratorio antes de saber cuándo o dónde se enviarán. Concretamente, aprovechamos los componentes elemental-register y elemental-system-agent para permitir la incorporación de hosts de SUSE Linux Micro a Rancher para casos de uso de aprovisionamiento de red "phone home". Al utilizar Edge Image Builder (EIB) para crear imágenes de despliegue, el registro automático a través de Rancher mediante Elemental puede lograrse especificando la configuración de registro en el directorio de configuración de EIB.

Nota

En SUSE Edge 3.6 no aprovechamos los aspectos de gestión del sistema operativo de Elemental y, por tanto, no es posible gestionar la aplicación de parches de su sistema operativo a través de Rancher. En lugar de utilizar las herramientas de Elemental para crear imágenes de despliegue, SUSE Edge utiliza las herramientas de Edge Image Builder, que consumen la configuración de registro.

K3s se puede utilizar como la distribución de Kubernetes que respalda la pila SUSE Edge. Está pensado para instalarse en un sistema operativo SUSE Linux Micro.

El uso de K3s como distribución de Kubernetes de la pila SUSE Edge solo se recomienda cuando etcd como backend no se ajusta a sus limitaciones. Si etcd como backend es posible, es mejor utilizar RKE2 (Capítulo 12, RKE2).

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 Edge. Se asienta sobre SUSE Linux Micro (Capítulo 7, 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 Edge utiliza Capítulo 8, 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 25.8, “Instalación de SUSE Storage”.

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

SUSE Edge utiliza Capítulo 8, Edge Image Builder para personalizar las imágenes base de SUSE Linux Micro OS. Sigan Sección 25.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 Edge utiliza MetalLB de tres formas clave:

Nota

Para poder exponer la API, se utiliza el Endpoint Copier Operator (Capítulo 16, 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 21, MetalLB en K3s (usando el modo de capa 2) y para el modo L3 en Capítulo 22, 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 24, MetalLB delante del servidor de API de Kubernetes.

En SUSE Edge, 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 15, 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 21, 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 Edge 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 Edge 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 Edge 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 Edge 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.

17.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.

17.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.

17.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.

17.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 Edge utiliza Capítulo 8, Edge Image Builder para personalizar las imágenes base del SO SUSE Linux Micro. Seguid Sección 25.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 Edge 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 19, 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 19.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 6, 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 41, 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:

18.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 18.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 18.2.1.2, “Instalación del controlador de actualización del sistema - Bundle”).

18.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

18.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.

18.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 Edge a la siguiente.

Para lograr esta automatización, el Controlador de actualización utiliza herramientas como el System Upgrade Controller (Capítulo 18, 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 19.5, “¿Cómo funciona el Controlador de actualización?”.

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

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

El System Upgrade Controller (SUC) (Capítulo 18, 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 Edge, 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 Edge. 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 8, 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 19.7, “Seguimiento del proceso de actualización”).

19.5.1 Actualización del sistema operativo #

 

Para actualizar el sistema operativo, el Controlador de actualización crea planes SUC (Capítulo 18, 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 19.6.1, “UpgradePlan”).

19.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 18, 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 19.6.1, “UpgradePlan”.

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

19.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

19.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