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

Se configura un clúster de gestión para proporcionar API declarativas que permitan la gestión del inventario y el estado de los servidores bare metal del clúster descendente, incluida la inspección, limpieza y aprovisionamiento/desaprovisionamiento automatizados.

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

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

El archivo de imagen de sistema operativo SL-Micro.x86_64-6.1-Base-GM.raw se debe descargar del Centro de servicios al cliente de SUSE o de la página de descargas de SUSE.

1.3.1 Configuración del clúster de gestión #

 

Los pasos básicos para instalar un clúster de gestión y usar Metal³ son:

1. Instalar un clúster de gestión RKE2

2. Instalar Rancher

3. Instalar un proveedor de almacenamiento (opcional)

4. Instalar las dependencias de Metal³

5. Instalar las dependencias de CAPI mediante Rancher Turtles

6. Crear una imagen del sistema operativo SLEMicro para los hosts del clúster descendente

7. Registrar los CR de BareMetalHost para definir el inventario de bare metal

8. Crear un clúster descendente definiendo los recursos de CAPI

En esta guía se entiende que ya existe un clúster RKE2 y que se ha instalado Rancher (incluido cert-manager), por ejemplo, utilizando Edge Image Builder (Capítulo 11, Edge Image Builder).

Sugerencia

Estos pasos también se pueden automatizar por completo, como se describe en la documentación sobre el clúster de gestión (Capítulo 40, Configuración del clúster de gestión).

1.3.2 Instalación de las dependencias de Metal³ #

 

Si aún no se ha hecho como parte de la instalación de Rancher, se debe instalar y ejecutar cert-manager.

Se debe instalar un proveedor de almacenamiento persistente. Se recomienda SUSE Storage, pero también se puede utilizar local-pathprovisioner para entornos de desarrollo/PoC. Las instrucciones siguientes dan por sentado que se ha marcado una StorageClass como predeterminada; de lo contrario, se requiere una configuración adicional para el chart de Metal³.

Se requiere una IP adicional, gestionada por MetalLB para proporcionar un punto final coherente para los servicios de gestión de Metal³. Esta IP debe formar parte de la subred del plano de control y estar reservada para la configuración estática (no debe formar parte de ningún grupo DHCP).

Sugerencia

Si el clúster de gestión es un solo nodo, no es necesario contar con una IP fleetnte adicional gestionada mediante MetalLB. Consulte la Sección 1.6.1, “Configuración de un solo nodo”.

1. Primero, se instala MetalLB:

   helm install \
     metallb oci://registry.suse.com/edge/charts/metallb \
     --namespace metallb-system \
     --create-namespace

2. Luego, se definen IPAddressPool y L2Advertisement con la IP reservada, definida como STATIC_IRONIC_IP a continuación:

   export STATIC_IRONIC_IP=<STATIC_IRONIC_IP>
   
   cat <<-EOF | kubectl apply -f -
   apiVersion: metallb.io/v1beta1
   kind: IPAddressPool
   metadata:
     name: ironic-ip-pool
     namespace: metallb-system
   spec:
     addresses:
     - ${STATIC_IRONIC_IP}/32
     serviceAllocation:
       priority: 100
       serviceSelectors:
       - matchExpressions:
         - {key: app.kubernetes.io/name, operator: In, values: [metal3-ironic]}
   EOF

   cat <<-EOF | kubectl apply -f -
   apiVersion: metallb.io/v1beta1
   kind: L2Advertisement
   metadata:
     name: ironic-ip-pool-l2-adv
     namespace: metallb-system
   spec:
     ipAddressPools:
     - ironic-ip-pool
   EOF

3. Ya se puede instalar Metal³:

   helm install \
     metal3 oci://registry.suse.com/edge/charts/metal3 \
     --namespace metal3-system \
     --create-namespace \
     --set global.ironicIP="$STATIC_IRONIC_IP"

4. El contenedor de inicio puede tardar unos dos minutos en ejecutarse en este despliegue, así que asegúrese de que todos los pods estén funcionando antes de continuar:

   kubectl get pods -n metal3-system
   NAME                                                    READY   STATUS    RESTARTS   AGE
   baremetal-operator-controller-manager-85756794b-fz98d   2/2     Running   0          15m
   metal3-metal3-ironic-677bc5c8cc-55shd                   4/4     Running   0          15m
   metal3-metal3-mariadb-7c7d6fdbd8-64c7l                  1/1     Running   0          15m

Aviso

No continúe con los siguientes pasos hasta que todos los pods del espacio de nombres metal3-system estén en ejecución.

cat > values.yaml <<EOF
rancherTurtles:
  features:
    embedded-capi:
      disabled: true
    rancher-webhook:
      cleanup: true
EOF

helm install \
  rancher-turtles oci://registry.suse.com/edge/charts/rancher-turtles \
  --namespace rancher-turtles-system \
  --create-namespace \
  -f values.yaml

1.3.4 Preparación de la imagen del clúster descendente #

 

Kiwi (Capítulo 28, Creación de imágenes actualizadas de SUSE Linux Micro con Kiwi) y Edge Image Builder (Capítulo 11, Edge Image Builder) se usan para preparar una imagen base de SLEMicro modificada que se aprovisiona en los hosts de clústeres descendentes.

En esta guía, se trata la configuración mínima necesaria para desplegar el clúster descendente.

1.3.4.1 Configuración de la imagen #

 

Nota

Como primer paso necesario para crear clústeres, cree una imagen nueva siguiendo las instrucciones del Capítulo 28, Creación de imágenes actualizadas de SUSE Linux Micro con Kiwi.

Al ejecutar Edge Image Builder, se monta un directorio desde el host, por lo que es necesario crear una estructura de directorios para almacenar los archivos de configuración usados para definir la imagen de destino.

• downstream-cluster-config.yaml es el archivo de definición de la imagen. Consulte el Capítulo 3, Clústeres independientes con Edge Image Builder para obtener más detalles.

• La imagen base, cuando se descarga, está comprimida con xz, por lo que debe descomprimirse con unxz y copiarse/moverse a la carpeta base-images.

• La carpeta network es opcional. Para obtener más información, consulte la Sección 1.3.5.1.1, “Guion adicional para la configuración de la red estática”.

• El directorio custom/scripts contiene guiones que se ejecutan en el primer arranque; actualmente, se requiere un guion 01-fix-growfs.sh para cambiar el tamaño de la partición raíz del sistema operativo en el despliegue.

├── downstream-cluster-config.yaml
├── base-images/
│   └ SL-Micro.x86_64-6.1-Base-GM.raw
├── network/
|   └ configure-network.sh
└── custom/
    └ scripts/
        └ 01-fix-growfs.sh

1.3.4.1.1 Archivo de definición de la imagen del clúster descendente #

 

El archivo downstream-cluster-config.yaml es el principal archivo de configuración para la imagen del clúster descendente. A continuación, se muestra un ejemplo mínimo de despliegue mediante Metal³:

apiVersion: 1.2
image:
  imageType: raw
  arch: x86_64
  baseImage: SL-Micro.x86_64-6.1-Base-GM.raw
  outputImageName: SLE-Micro-eib-output.raw
operatingSystem:
  time:
    timezone: Europe/London
    ntp:
      forceWait: true
      pools:
        - 2.suse.pool.ntp.org
      servers:
        - 10.0.0.1
        - 10.0.0.2
  kernelArgs:
    - ignition.platform.id=openstack
    - net.ifnames=1
  systemd:
    disable:
      - rebootmgr
      - transactional-update.timer
      - transactional-update-cleanup.timer
  users:
    - username: root
      encryptedPassword: $ROOT_PASSWORD
      sshKeys:
      - $USERKEY1
  packages:
    packageList:
      - jq
  sccRegistrationCode: $SCC_REGISTRATION_CODE

Donde $SCC_REGISTRATION_CODE es el código de registro copiado del Centro de servicios al cliente de SUSE y la lista de paquetes contiene jq, que es obligatorio.

$ROOT_PASSWORD es la contraseña cifrada del usuario root, que puede ser útil para pruebas y depuración. Se puede generar con el comando openssl passwd -6 PASSWORD.

En entornos de producción, se recomienda usar las claves SSH que se pueden añadir al bloque de usuarios sustituyendo $USERKEY1 por las claves SSH reales.

Nota

net.ifnames=1 permite los nombres predecibles para las interfaces de red

Esto coincide con la configuración predeterminada para el chart de Metal³, pero el ajuste debe coincidir con el valor de predictableNicNames configurado en el chart.

Tenga en cuenta también que ignition.platform.id=openstack es obligatorio. Sin este argumento, la configuración de SUSE Linux Micro a través de Ignition fallará en el flujo automatizado de Metal³.

La sección time es opcional, pero se recomienda encarecidamente configurarla para evitar posibles problemas con los certificados y la desviación del reloj. Los valores proporcionados en este ejemplo son solo ilustrativos. Ajústelos según sus requisitos específicos.

1.3.4.1.2 Guion Growfs #

 

Actualmente, se requiere un guion personalizado (custom/scripts/01-fix-growfs.sh) para ampliar el sistema de archivos y que coincida con el tamaño del disco en el primer arranque después del aprovisionamiento. El guion 01-fix-growfs.sh contiene la siguiente información:

#!/bin/bash
growfs() {
  mnt="$1"
  dev="$(findmnt --fstab --target ${mnt} --evaluate --real --output SOURCE --noheadings)"
  # /dev/sda3 -> /dev/sda, /dev/nvme0n1p3 -> /dev/nvme0n1
  parent_dev="/dev/$(lsblk --nodeps -rno PKNAME "${dev}")"
  # Last number in the device name: /dev/nvme0n1p42 -> 42
  partnum="$(echo "${dev}" | sed 's/^.*[^0-9]\([0-9]\+\)$/\1/')"
  ret=0
  growpart "$parent_dev" "$partnum" || ret=$?
  [ $ret -eq 0 ] || [ $ret -eq 1 ] || exit 1
  /usr/lib/systemd/systemd-growfs "$mnt"
}
growfs /

Nota

Use el mismo método para añadir sus propios guiones personalizados que se ejecuten durante el proceso de aprovisionamiento. Para obtener más información, consulte el Capítulo 3, Clústeres independientes con Edge Image Builder.

1.3.4.2 Creación de la imagen #

 

Cuando se haya preparado la estructura de directorios siguiendo las secciones anteriores, ejecute el siguiente comando para crear la imagen:

podman run --rm --privileged -it -v $PWD:/eib \
 registry.suse.com/edge/3.3/edge-image-builder:1.2.1 \
 build --definition-file downstream-cluster-config.yaml

Esto crea el archivo de imagen de salida denominado SLE-Micro-eib-output.raw, basado en la definición descrita anteriormente.

La imagen resultante debe estar disponible a través de un servidor web, ya sea el contenedor del servidor multimedia habilitado mediante el chart de Metal3 (Nota) o algún otro servidor al que se pueda acceder localmente. En los ejemplos siguientes, nos referimos a este servidor como imagecache.local:8080.

Nota

Al desplegar imágenes de EIB en clústeres descendentes, también es necesario incluir la suma sha256 de la imagen en el objeto Metal3MachineTemplate. Se puede generar de la siguiente manera:

sha256sum <image_file> > <image_file>.sha256
# On this example:
sha256sum SLE-Micro-eib-output.raw > SLE-Micro-eib-output.raw.sha256

1.3.5 Adición del inventario de BareMetalHost #

 

El registro de servidores bare metal para el despliegue automatizado requiere la creación de dos recursos: un secreto que almacena las credenciales de acceso a BMC y un recurso BareMetalHost de Metal³ que define la conexión de BMC y otros detalles:

apiVersion: v1
kind: Secret
metadata:
  name: controlplane-0-credentials
type: Opaque
data:
  username: YWRtaW4=
  password: cGFzc3dvcmQ=
---
apiVersion: metal3.io/v1alpha1
kind: BareMetalHost
metadata:
  name: controlplane-0
  labels:
    cluster-role: control-plane
spec:
  online: true
  bootMACAddress: "00:f3:65:8a:a3:b0"
  bmc:
    address: redfish-virtualmedia://192.168.125.1:8000/redfish/v1/Systems/68bd0fb6-d124-4d17-a904-cdf33efe83ab
    disableCertificateVerification: true
    credentialsName: controlplane-0-credentials

Tenga en cuenta lo siguiente:

• El nombre de usuario y la contraseña del secreto deben estar cifrados en base64. No deben incluir saltos de línea al final (por ejemplo, use echo -n, no solo echo)

• La etiqueta cluster-role se puede establecer ahora o más adelante, durante la creación del clúster. En el ejemplo siguiente, se espera control-plane o worker

• bootMACAddress debe ser una dirección MAC válida que coincida con la NIC de plano de control del host

• La dirección bmc es la conexión a la API de gestión de BMC. Se admiten las siguientes:

  • redfish-virtualmedia://<DIRECCIÓN IP>/redfish/v1/Systems/<ID DEL SISTEMA>: medio virtual Redfish, por ejemplo, SuperMicro

  • idrac-virtualmedia://<DIRECCIÓN IP>/redfish/v1/Systems/System.Embedded.1: iDRAC de Dell

• Consulte la documentación original de la API para obtener más información sobre la API de BareMetalHost

1.3.5.1 Configuración de IP estáticas #

 

El ejemplo anterior de BareMetalHost presupone que DHCP proporciona la configuración de red del plano de control, pero para situaciones en las que se necesite una configuración manual, como en el caso de las IP estáticas, es posible proporcionar una configuración adicional, como se describe a continuación.

1.3.5.1.1 Guion adicional para la configuración de la red estática #

 

Al crear la imagen base con Edge Image Builder, en la carpeta de network, cree el archivo configure-network.sh siguiente.

Esto consume datos de la unidad de configuración en el primer arranque y configura la red del host usando la herramienta NM Configurator.

#!/bin/bash

set -eux

# Attempt to statically configure a NIC in the case where we find a network_data.json
# In a configuration drive

CONFIG_DRIVE=$(blkid --label config-2 || true)
if [ -z "${CONFIG_DRIVE}" ]; then
  echo "No config-2 device found, skipping network configuration"
  exit 0
fi

mount -o ro $CONFIG_DRIVE /mnt

NETWORK_DATA_FILE="/mnt/openstack/latest/network_data.json"

if [ ! -f "${NETWORK_DATA_FILE}" ]; then
  umount /mnt
  echo "No network_data.json found, skipping network configuration"
  exit 0
fi

DESIRED_HOSTNAME=$(cat /mnt/openstack/latest/meta_data.json | tr ',{}' '\n' | grep '\"metal3-name\"' | sed 's/.*\"metal3-name\": \"\(.*\)\"/\1/')
echo "${DESIRED_HOSTNAME}" > /etc/hostname

mkdir -p /tmp/nmc/{desired,generated}
cp ${NETWORK_DATA_FILE} /tmp/nmc/desired/_all.yaml
umount /mnt

./nmc generate --config-dir /tmp/nmc/desired --output-dir /tmp/nmc/generated
./nmc apply --config-dir /tmp/nmc/generated

1.3.5.1.2 Secreto adicional con configuración de red de host #

 

Se puede definir un secreto adicional que contenga datos en el formato nmstate compatible con NM Configurator (Capítulo 12, Conexiones de red de Edge) para cada host.

A continuación, se hace referencia al secreto en el recurso BareMetalHost mediante el campo de especificación preprovisioningNetworkDataName.

apiVersion: v1
kind: Secret
metadata:
  name: controlplane-0-networkdata
type: Opaque
stringData:
  networkData: |
    interfaces:
    - name: enp1s0
      type: ethernet
      state: up
      mac-address: "00:f3:65:8a:a3:b0"
      ipv4:
        address:
        - ip:  192.168.125.200
          prefix-length: 24
        enabled: true
        dhcp: false
    dns-resolver:
      config:
        server:
        - 192.168.125.1
    routes:
      config:
      - destination: 0.0.0.0/0
        next-hop-address: 192.168.125.1
        next-hop-interface: enp1s0
---
apiVersion: metal3.io/v1alpha1
kind: BareMetalHost
metadata:
  name: controlplane-0
  labels:
    cluster-role: control-plane
spec:
  preprovisioningNetworkDataName: controlplane-0-networkdata
# Remaining content as in previous example

Nota

En algunas circunstancias, la dirección MAC puede omitirse. Consulte la Sección 12.5.8, “Configuraciones unificadas de nodos” para obtener más detalles.

1.3.5.2 Preparación de BareMetalHost #

 

Después de crear el recurso BareMetalHost y los secretos asociados como se ha descrito, se activa un flujo de trabajo de preparación del host:

• Se arranca una imagen ramdisk mediante la conexión de un dispositivo virtual al BMC del host de destino

• El ramdisk inspecciona los detalles del hardware y prepara el host para el aprovisionamiento (por ejemplo, limpiando los discos de datos anteriores)

• Una vez completado este proceso, se actualizan los detalles del hardware en el campo status.hardware de BareMetalHost y se pueden verificar

Este proceso puede tardar varios minutos, pero una vez completado, debería ver que el estado de BareMetalHost pasa a ser available (disponible):

% kubectl get baremetalhost
NAME             STATE       CONSUMER   ONLINE   ERROR   AGE
controlplane-0   available              true             9m44s
worker-0         available              true             9m44s

1.3.7 Despliegue del plano de control #

 

Para desplegar el plano de control, se define un manifiesto YAML similar al que se muestra a continuación, que contiene los siguientes recursos:

• El recurso Cluster define el nombre del clúster, las redes y el tipo de proveedor de plano de control/infraestructura (en este caso, RKE2/Metal3)

• Metal3Cluster define el punto final del plano de control (IP del host para un solo nodo, punto final LoadBalancer para varios nodos; en este ejemplo se supone que hay un solo nodo)

• RKE2ControlPlane define la versión de RKE2 y cualquier configuración adicional necesaria durante el arranque del clúster

• Metal3MachineTemplate define la imagen del sistema operativo que se aplicará a los recursos BareMetalHost, y hostSelector define qué recursos BareMetalHost se consumirán

• Metal3DataTemplate define los metadatos adicionales que se pasarán a BareMetalHost (tenga en cuenta que networkData no es compatible actualmente con Edge)

Nota

Para simplificar, en este ejemplo se entiende que hay un plano de control de un solo nodo en el que BareMetalHost se ha configurado con la IP 192.168.125.200. Para ejemplos más avanzados de varios nodos, consulte el Capítulo 42, Aprovisionamiento de red dirigida totalmente automatizado.

apiVersion: cluster.x-k8s.io/v1beta1
kind: Cluster
metadata:
  name: sample-cluster
  namespace: default
spec:
  clusterNetwork:
    pods:
      cidrBlocks:
        - 192.168.0.0/18
    services:
      cidrBlocks:
        - 10.96.0.0/12
  controlPlaneRef:
    apiVersion: controlplane.cluster.x-k8s.io/v1beta1
    kind: RKE2ControlPlane
    name: sample-cluster
  infrastructureRef:
    apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
    kind: Metal3Cluster
    name: sample-cluster
---
apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
kind: Metal3Cluster
metadata:
  name: sample-cluster
  namespace: default
spec:
  controlPlaneEndpoint:
    host: 192.168.125.200
    port: 6443
  noCloudProvider: true
---
apiVersion: controlplane.cluster.x-k8s.io/v1beta1
kind: RKE2ControlPlane
metadata:
  name: sample-cluster
  namespace: default
spec:
  infrastructureRef:
    apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
    kind: Metal3MachineTemplate
    name: sample-cluster-controlplane
  replicas: 1
  version: v1.32.4+rke2r1
  rolloutStrategy:
    type: "RollingUpdate"
    rollingUpdate:
      maxSurge: 0
  agentConfig:
    format: ignition
    kubelet:
      extraArgs:
        - provider-id=metal3://BAREMETALHOST_UUID
    additionalUserData:
      config: |
        variant: fcos
        version: 1.4.0
        systemd:
          units:
            - name: rke2-preinstall.service
              enabled: true
              contents: |
                [Unit]
                Description=rke2-preinstall
                Wants=network-online.target
                Before=rke2-install.service
                ConditionPathExists=!/run/cluster-api/bootstrap-success.complete
                [Service]
                Type=oneshot
                User=root
                ExecStartPre=/bin/sh -c "mount -L config-2 /mnt"
                ExecStart=/bin/sh -c "sed -i \"s/BAREMETALHOST_UUID/$(jq -r .uuid /mnt/openstack/latest/meta_data.json)/\" /etc/rancher/rke2/config.yaml"
                ExecStart=/bin/sh -c "echo \"node-name: $(jq -r .name /mnt/openstack/latest/meta_data.json)\" >> /etc/rancher/rke2/config.yaml"
                ExecStartPost=/bin/sh -c "umount /mnt"
                [Install]
                WantedBy=multi-user.target
---
apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
kind: Metal3MachineTemplate
metadata:
  name: sample-cluster-controlplane
  namespace: default
spec:
  template:
    spec:
      dataTemplate:
        name: sample-cluster-controlplane-template
      hostSelector:
        matchLabels:
          cluster-role: control-plane
      image:
        checksum: http://imagecache.local:8080/SLE-Micro-eib-output.raw.sha256
        checksumType: sha256
        format: raw
        url: http://imagecache.local:8080/SLE-Micro-eib-output.raw
---
apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
kind: Metal3DataTemplate
metadata:
  name: sample-cluster-controlplane-template
  namespace: default
spec:
  clusterName: sample-cluster
  metaData:
    objectNames:
      - key: name
        object: machine
      - key: local-hostname
        object: machine
      - key: local_hostname
        object: machine

Una vez adaptado a su entorno, puede aplicar el ejemplo mediante kubectl y, a continuación, supervisar el estado del clúster mediante clusterctl.

% kubectl apply -f rke2-control-plane.yaml

# Wait for the cluster to be provisioned
% clusterctl describe cluster sample-cluster
NAME                                                    READY  SEVERITY  REASON  SINCE  MESSAGE
Cluster/sample-cluster                                  True                     22m
├─ClusterInfrastructure - Metal3Cluster/sample-cluster  True                     27m
├─ControlPlane - RKE2ControlPlane/sample-cluster        True                     22m
│ └─Machine/sample-cluster-chflc                        True                     23m

apiVersion: cluster.x-k8s.io/v1beta1
kind: MachineDeployment
metadata:
  labels:
    cluster.x-k8s.io/cluster-name: sample-cluster
  name: sample-cluster
  namespace: default
spec:
  clusterName: sample-cluster
  replicas: 1
  selector:
    matchLabels:
      cluster.x-k8s.io/cluster-name: sample-cluster
  template:
    metadata:
      labels:
        cluster.x-k8s.io/cluster-name: sample-cluster
    spec:
      bootstrap:
        configRef:
          apiVersion: bootstrap.cluster.x-k8s.io/v1alpha1
          kind: RKE2ConfigTemplate
          name: sample-cluster-workers
      clusterName: sample-cluster
      infrastructureRef:
        apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
        kind: Metal3MachineTemplate
        name: sample-cluster-workers
      nodeDrainTimeout: 0s
      version: v1.32.4+rke2r1
---
apiVersion: bootstrap.cluster.x-k8s.io/v1alpha1
kind: RKE2ConfigTemplate
metadata:
  name: sample-cluster-workers
  namespace: default
spec:
  template:
    spec:
      agentConfig:
        format: ignition
        version: v1.32.4+rke2r1
        kubelet:
          extraArgs:
            - provider-id=metal3://BAREMETALHOST_UUID
        additionalUserData:
          config: |
            variant: fcos
            version: 1.4.0
            systemd:
              units:
                - name: rke2-preinstall.service
                  enabled: true
                  contents: |
                    [Unit]
                    Description=rke2-preinstall
                    Wants=network-online.target
                    Before=rke2-install.service
                    ConditionPathExists=!/run/cluster-api/bootstrap-success.complete
                    [Service]
                    Type=oneshot
                    User=root
                    ExecStartPre=/bin/sh -c "mount -L config-2 /mnt"
                    ExecStart=/bin/sh -c "sed -i \"s/BAREMETALHOST_UUID/$(jq -r .uuid /mnt/openstack/latest/meta_data.json)/\" /etc/rancher/rke2/config.yaml"
                    ExecStart=/bin/sh -c "echo \"node-name: $(jq -r .name /mnt/openstack/latest/meta_data.json)\" >> /etc/rancher/rke2/config.yaml"
                    ExecStartPost=/bin/sh -c "umount /mnt"
                    [Install]
                    WantedBy=multi-user.target
---
apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
kind: Metal3MachineTemplate
metadata:
  name: sample-cluster-workers
  namespace: default
spec:
  template:
    spec:
      dataTemplate:
        name: sample-cluster-workers-template
      hostSelector:
        matchLabels:
          cluster-role: worker
      image:
        checksum: http://imagecache.local:8080/SLE-Micro-eib-output.raw.sha256
        checksumType: sha256
        format: raw
        url: http://imagecache.local:8080/SLE-Micro-eib-output.raw
---
apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
kind: Metal3DataTemplate
metadata:
  name: sample-cluster-workers-template
  namespace: default
spec:
  clusterName: sample-cluster
  metaData:
    objectNames:
      - key: name
        object: machine
      - key: local-hostname
        object: machine
      - key: local_hostname
        object: machine

% kubectl apply -f rke2-agent.yaml

# Wait for the worker nodes to be provisioned
% clusterctl describe cluster sample-cluster
NAME                                                    READY  SEVERITY  REASON  SINCE  MESSAGE
Cluster/sample-cluster                                  True                     25m
├─ClusterInfrastructure - Metal3Cluster/sample-cluster  True                     30m
├─ControlPlane - RKE2ControlPlane/sample-cluster        True                     25m
│ └─Machine/sample-cluster-chflc                        True                     27m
└─Workers
  └─MachineDeployment/sample-cluster                    True                     22m
    └─Machine/sample-cluster-56df5b4499-zfljj           True                     23m

% kubectl delete -f rke2-agent.yaml
% kubectl delete -f rke2-control-plane.yaml

% kubectl get bmh
NAME             STATE            CONSUMER                            ONLINE   ERROR   AGE
controlplane-0   deprovisioning   sample-cluster-controlplane-vlrt6   false            10m
worker-0         deprovisioning   sample-cluster-workers-785x5        false            10m

...

% kubectl get bmh
NAME             STATE       CONSUMER   ONLINE   ERROR   AGE
controlplane-0   available              false            15m
worker-0         available              false            15m

La documentación de SUSE Edge for Telco (Capítulo 37, SUSE Edge for Telco) tiene ejemplos de uso más avanzados de Metal³ para casos de uso relacionados con las telecomunicaciones.

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

global:
  enable_vmedia_tls: false

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

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

A continuación se describen los requisitos mínimos del sistema y del entorno para la ejecución:

Nota

Los datos existentes en los equipos de destino se sobrescribirán como parte del proceso, por lo que debe asegurarse de realizar una copia de seguridad de todos los datos almacenados en dispositivos USB y discos conectados a los nodos de despliegue de destino.

En esta guía se utiliza un droplet de Digital Ocean para alojar el clúster ascendente y un NUC Intel como dispositivo descendente. Para crear el medio de instalación, se utiliza SUSE Linux Enterprise Server.

Para empezar, cree un clúster capaz de alojar Rancher y Elemental. Este clúster debe ser enrutable desde la red a la que están conectados los nodos descendentes.

2.3.2 Configuración de DNS #

 

Antes de continuar, debe configurar el acceso a su clúster. Como ocurre con la configuración del propio clúster, la forma de configurar el servidor DNS variará en función del lugar donde esté alojado.

Sugerencia

Si no desea ocuparse de la configuración de los registros DNS (por ejemplo, si se trata solo de un servidor de prueba efímero), puede utilizar un servicio como sslip.io en su lugar. Con este servicio, puede resolver cualquier dirección IP con <dirección>.sslip.io.

Para instalar Rancher, necesitas acceder a la API de Kubernetes del clúster que acabas de crear. Esto varía en función de la distribución de Kubernetes que se utilice.

Para RKE2, el archivo kubeconfig se habrá escrito en /etc/rancher/rke2/rke2.yaml. Guarde este archivo como ~/.kube/config en su sistema local. Es posible que tenga que editar el archivo para incluir la dirección IP o el nombre de host externos correctos.

Instale Rancher fácilmente con los comandos que encontrará en la documentación de Rancher:

Instale cert-manager:

helm repo add jetstack https://charts.jetstack.io
helm repo update
helm install cert-manager jetstack/cert-manager \
 --namespace cert-manager \
 --create-namespace \
 --set crds.enabled=true

Después, instale Rancher:

helm repo add rancher-prime https://charts.rancher.com/server-charts/prime
helm repo update
helm install rancher rancher-prime/rancher \
  --namespace cattle-system \
  --create-namespace \
  --set hostname=<DNS or sslip from above> \
  --set replicas=1 \
  --set bootstrapPassword=<PASSWORD_FOR_RANCHER_ADMIN> \
  --version 2.11.2

Nota

Si se trata de un sistema de producción, use cert-manager para configurar un certificado real (como uno de Let’s Encrypt).

Busque el nombre de host que ha configurado e inicie sesión en Rancher con la contraseña que ha utilizado en bootstrapPassword. Se le guiará a través de un breve proceso de configuración.

Una vez instalado Rancher, ya puede instalar el operador de Elemental y las CRD necesarias. El chart de Helm para Elemental se publica como un artefacto OCI, por lo que la instalación es un poco más sencilla que la de otros charts. Se puede instalar desde la misma shell que se utilizó para instalar Rancher o en el navegador desde la shell de Rancher.

helm install --create-namespace -n cattle-elemental-system \
 elemental-operator-crds \
 oci://registry.suse.com/rancher/elemental-operator-crds-chart \
 --version 1.6.8

helm install -n cattle-elemental-system \
 elemental-operator \
 oci://registry.suse.com/rancher/elemental-operator-chart \
 --version 1.6.8

Por sencillez, se recomienda configurar la variable $ELEM con la vía completa donde desea que se encuentre el directorio de configuración:

export ELEM=$HOME/elemental
mkdir -p $ELEM

Para permitir que las máquinas se registren en Elemental, se necesita crear un objeto MachineRegistration en el espacio de nombres fleet-default.

Vamos a crear una versión básica de este objeto:

cat << EOF > $ELEM/registration.yaml
apiVersion: elemental.cattle.io/v1beta1
kind: MachineRegistration
metadata:
  name: ele-quickstart-nodes
  namespace: fleet-default
spec:
  machineName: "\${System Information/Manufacturer}-\${System Information/UUID}"
  machineInventoryLabels:
    manufacturer: "\${System Information/Manufacturer}"
    productName: "\${System Information/Product Name}"
EOF

kubectl apply -f $ELEM/registration.yaml

Nota

El comando cat escapa cada $ con una barra invertida (\) para que Bash no las utilice como plantilla. Elimine las barras invertidas si va a realizar una copia manualmente.

Una vez creado el objeto, busque y anote el punto final que se le asigna:

REGISURL=$(kubectl get machineregistration ele-quickstart-nodes -n fleet-default -o jsonpath='{.status.registrationURL}')

Alternativamente, puede hacerlo desde la interfaz de usuario.

Aunque la versión actual de Elemental permite crear sus propios medios de instalación, en SUSE Edge 3.3.1 se hace con Kiwi y Edge Image Builder, por lo que el sistema resultante se crea con SUSE Linux Micro como sistema operativo base.

Sugerencia

Para obtener más información sobre Kiwi, siga el proceso de creación de imágenes de Kiwi (Capítulo 28, Creación de imágenes actualizadas de SUSE Linux Micro con Kiwi) para crear imágenes nuevas en primer lugar. En el caso de Edge Image Builder, consulte la guía de introducción a Edge Image Builder (Capítulo 3, Clústeres independientes con Edge Image Builder) y la documentación de los componentes (Capítulo 11, Edge Image Builder).

Desde un sistema Linux con Podman instalado, cree los directorios y coloque la imagen base que está creando Kiwi:

mkdir -p $ELEM/eib_quickstart/base-images
cp /path/to/{micro-base-image-iso} $ELEM/eib_quickstart/base-images/
mkdir -p $ELEM/eib_quickstart/elemental

curl $REGISURL -o $ELEM/eib_quickstart/elemental/elemental_config.yaml

cat << EOF > $ELEM/eib_quickstart/eib-config.yaml
apiVersion: 1.2
image:
    imageType: iso
    arch: x86_64
    baseImage: SL-Micro.x86_64-6.1-Base-SelfInstall-GM.install.iso
    outputImageName: elemental-image.iso
operatingSystem:
  time:
    timezone: Europe/London
    ntp:
      forceWait: true
      pools:
        - 2.suse.pool.ntp.org
      servers:
        - 10.0.0.1
        - 10.0.0.2
  isoConfiguration:
    installDevice: /dev/vda
  users:
    - username: root
      encryptedPassword: \$6\$jHugJNNd3HElGsUZ\$eodjVe4te5ps44SVcWshdfWizrP.xAyd71CVEXazBJ/.v799/WRCBXxfYmunlBO2yp1hm/zb4r8EmnrrNCF.P/
  packages:
    sccRegistrationCode: XXX
EOF

Nota

• La sección time es opcional, pero se recomienda encarecidamente configurarla para evitar posibles problemas con los certificados y la desviación del reloj. Los valores proporcionados en este ejemplo son solo ilustrativos. Ajústelos según sus requisitos específicos.

• La contraseña sin cifrar es eib.

• Se necesita el código sccRegistrationCode para descargar e instalar los paquetes RPM necesarios de las fuentes oficiales (alternativamente, los RPM elemental-register y elemental-system-agent se pueden cargar de forma manual y local).

• El comando cat escapa cada $ con una barra invertida (\) para que Bash no las utilice como plantilla. Elimine las barras invertidas si va a realizar una copia manualmente.

• El dispositivo de instalación se borrará durante la instalación.

podman run --privileged --rm -it -v $ELEM/eib_quickstart/:/eib \
 registry.suse.com/edge/3.3/edge-image-builder:1.2.1 \
 build --definition-file eib-config.yaml

Si está arrancando un dispositivo físico, es necesario grabar la imagen en una unidad flash USB. Puede hacerlo con:

sudo dd if=/eib_quickstart/elemental-image.iso of=/dev/<PATH_TO_DISK_DEVICE> status=progress

Ahora que se ha creado el medio de instalación, se pueden arrancar los nodos descendentes con él.

Para cada sistema que desee controlar con Elemental, añada el medio de instalación y arranque el dispositivo. Tras la instalación, se reiniciará y se registrará automáticamente.

Si utiliza la extensión de la interfaz de usuario, debería ver su nodo aparecer en "Inventory of Machines" (Inventario de equipos).

Nota

No retire el medio de instalación hasta que haya visto el mensaje de inicio de sesión; durante el primer arranque, se sigue accediendo a los archivos desde la memoria USB.

Para aprovisionar un clúster nuevo con Elemental, debe crear dos objetos.

Después de crear estos objetos, debería ver cómo se inicia un nuevo clúster de Kubernetes que usa el nuevo nodo que acaba de instalar.

SUSE Rancher Elemental permite realizar un "restablecimiento de nodo", que se puede activar opcionalmente cuando se elimina todo un clúster de Rancher o un solo nodo de un clúster, o cuando se elimina manualmente un nodo del inventario de equipos. Esto resulta útil cuando se desean restablecer y limpiar los recursos huérfanos y se quiere volver a incorporar automáticamente el nodo limpiado al inventario de equipos para que pueda reutilizarse. Esta función no está habilitada de forma predeterminada, por lo que no se limpiará cualquier sistema que se elimine (es decir, los datos no se eliminarán y los recursos del clúster de Kubernetes seguirán funcionando en los clústeres descendentes) y será necesaria una intervención manual para borrar los datos y volver a registrar el equipo en Rancher a través de Elemental.

Si desea que esta funcionalidad esté habilitada de forma predeterminada, debe asegurarse de que esté explícitamente habilitada en MachineRegistration añadiendo config.elemental.reset.enabled: true, por ejemplo:

config:
  elemental:
    registration:
      auth: tpm
    reset:
      enabled: true

A continuación, todos los sistemas registrados con este registro MachineRegistration recibirán automáticamente la anotación elemental.cattle.io/resettable: “true” en su configuración. Si desea hacerlo manualmente en nodos individuales, por ejemplo, porque tiene un MachineInventory que no tiene esa anotación o porque ya ha desplegado nodos, puede modificar MachineInventory y añadir la configuración resettable. Por ejemplo:

apiVersion: elemental.cattle.io/v1beta1
kind: MachineInventory
metadata:
  annotations:
    elemental.cattle.io/os.unmanaged: 'true'
    elemental.cattle.io/resettable: 'true'

En SUSE Edge 3.1, el operador de Elemental coloca un marcador en el sistema operativo que activará automáticamente el proceso de limpieza, detendrá todos los servicios de Kubernetes, eliminará todos los datos persistentes, desinstalará todos los servicios de Kubernetes, limpiará cualquier directorio restante de Kubernetes/Rancher y forzará un nuevo registro en Rancher a través de la configuración original de MachineRegistration de Elemental. Esto ocurre automáticamente, sin necesidad de intervención manual. El guion que se ejecuta se encuentra en /opt/edge/elemental_node_cleanup.sh y se activa a través de systemd.path al colocar el marcador, por lo que su ejecución es inmediata.

Aviso

El uso de la función resettable presupone que el comportamiento deseado al eliminar un nodo/clúster de Rancher es borrar los datos y forzar un nuevo registro. En esta situación, la pérdida de datos está garantizada, por lo que solo debe utilizarla si está seguro de que desea que se realice un restablecimiento automático.

Se recomienda estudiar los siguientes recursos después de utilizar esta guía:

Dado que EIB se ejecuta dentro de un contenedor, es necesario montar un directorio de configuración desde el host, lo que le permite especificar la configuración deseada. Así, durante el proceso de creación, EIB tiene acceso a cualquier archivo de entrada y artefactos de apoyo necesarios. Este directorio debe tener una estructura específica. Vamos a crearlo suponiendo que este directorio existirá en su directorio de inicio y se llamará "eib":

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

En el paso anterior creamos el directorio "base-images" donde se alojará la imagen de entrada de SUSE Linux Micro 6.1. Ahora, nos aseguraremos de que la imagen se copie en el directorio de configuración:

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

Nota

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

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

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

El archivo de definición describe la mayoría de las opciones configurables que admite Edge Image Builder. Encontrará un ejemplo completo de las opciones aquí. Le recomendamos que consulte la guía original sobre creación de imágenes para ver ejemplos más completos que los que se muestran a continuación. Comencemos con un archivo de definición muy básico para nuestra imagen del sistema operativo:

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

Esta definición especifica que estamos generando una imagen de salida para un sistema basado en AMD64/Intel 64. Para modificaciones posteriores, se utilizará como base una imagen iso denominada slemicro.iso, que se espera que se encuentre en $CONFIG_DIR/base-images/slemicro.iso. También indica que, una vez que EIB haya terminado de modificarla, la imagen de salida se llamará eib-image.iso y, por defecto, se ubicará en $CONFIG_DIR.

Ahora, nuestra estructura de directorio debe tener este aspecto:

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

En las siguientes secciones veremos algunos ejemplos de operaciones comunes:

3.3.1 Configuración de usuarios del sistema operativo #

 

EIB permite preconfigurar la información de inicio de sesión de los usuarios, como las contraseñas o las claves SSH, incluyendo la configuración de una contraseña raíz fija. Como parte de este ejemplo, vamos a fijar la contraseña raíz, y el primer paso es utilizar OpenSSL para crear una contraseña cifrada unidireccional:

openssl passwd -6 SecurePassword

Se obtendrá un resultado similar a:

$6$G392FCbxVgnLaFw1$Ujt00mdpJ3tDHxEg1snBU3GjujQf6f8kvopu7jiCBIhRbRvMmKUqwcmXAKggaSSKeUUOEtCP3ZUoZQY7zTXnC1

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

apiVersion: 1.2
image:
  imageType: iso
  arch: x86_64
  baseImage: slemicro.iso
  outputImageName: eib-image.iso
operatingSystem:
  users:
    - username: root
      encryptedPassword: $6$G392FCbxVgnLaFw1$Ujt00mdpJ3tDHxEg1snBU3GjujQf6f8kvopu7jiCBIhRbRvMmKUqwcmXAKggaSSKeUUOEtCP3ZUoZQY7zTXnC1

Nota

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

3.3.2 Configuración de la hora del sistema operativo #

 

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

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

• timezone: especifica la zona horaria en el formato "Región/Localidad" (por ejemplo, "Europa/Madrid"). Para ver la lista completa, ejecute timedatectl list-timezones en un sistema Linux.

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

• forceWait: solicita que chronyd intente sincronizar las fuentes de tiempo antes de iniciar otros servicios, con un tiempo de espera de 180 segundos.

• pools: especifica una lista de grupos que chronyd usará como fuentes de datos (utilizando iburst para mejorar el tiempo que tarda la sincronización inicial).

• servers: especifica una lista de servidores que chronyd usará como fuentes de datos (utilizando iburst para mejorar el tiempo que tarda la sincronización inicial).

Nota

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

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

3.3.4 Configuración de paquetes RPM #

 

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

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

• Repositorios de red para buscar estos paquetes

• Credenciales del Centro de servicios al cliente de SUSE (SCC) para buscar los paquetes mostrados en los repositorios oficiales de SUSE

• Mediante un directorio $CONFIG_DIR/rpms, paquetes RPM personalizados y locales que no existen en los repositorios de red

• Mediante el mismo directorio ($CONFIG_DIR/rpms/gpg-keys), claves GPG para habilitar la validación de paquetes de terceros

EIB ejecuta un proceso de resolución de paquetes en el momento de la creación de la imagen, tomando la imagen base como entrada, e intentará extraer e instalar todos los paquetes suministrados, ya sea especificados a través de la lista o proporcionados localmente. EIB descarga todos los paquetes, incluidas las dependencias, en un repositorio que existe dentro de la imagen de salida e indica al sistema que los instale durante el primer proceso de arranque. Realizar este proceso durante la creación de la imagen garantiza que los paquetes se instalarán correctamente durante el primer arranque en la plataforma deseada, por ejemplo, el nodo del perímetro. Esto también es útil en entornos en los que se desea integrar los paquetes adicionales en la imagen en lugar de descargarlos a través de la red durante el funcionamiento, por ejemplo, en entornos de red restringidos o aislados.

Como ejemplo de demostración simple, vamos a instalar el paquete RPM nvidia-container-toolkit que se encuentra en el repositorio NVIDIA de terceros:

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

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

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

Este es un ejemplo sencillo. Si necesita uno más detallad, descargue la clave de firma del paquete NVIDIA antes de ejecutar la generación de la imagen:

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

Aviso

La adición de paquetes RPM adicionales mediante este método permite añadir componentes de terceros compatibles o paquetes proporcionados (y mantenidos) por el usuario. Este mecanismo no debe utilizarse para añadir paquetes que normalmente no serían compatibles con SUSE Linux Micro. Si se utiliza este mecanismo para añadir componentes de los repositorios de openSUSE (que no son compatibles), incluidos los de versiones más recientes o paquetes de servicio, es posible que se obtenga una configuración no compatible, especialmente si al resolver las dependencias se sustituyen partes fundamentales del sistema operativo, aunque el sistema resultante parezca funcionar según lo esperado. Si no está seguro, póngase en contacto con su representante de SUSE para que le ayude a determinar la compatibilidad de la configuración que desea.

Nota

Encontrará una guía más completa con ejemplos adicionales en la guía original sobre instalación de paquetes.

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

 

Otra característica de EIB es la posibilidad de utilizarlo para automatizar el despliegue de clústeres de Kubernetes de alta disponibilidad, tanto de un solo nodo como de varios nodos, que se "arrancan en el lugar" (es decir, que no requieren infraestructura de gestión centralizada para coordinarse). Este enfoque está pensado principalmente para despliegues en entornos aislados o con restricciones de red, pero también sirve como una forma de arrancar rápidamente clústeres independientes, incluso si se dispone de acceso completo y sin restricciones a la red.

Este método no solo permite el despliegue del sistema operativo personalizado, sino también la posibilidad de especificar la configuración de Kubernetes, cualquier componente adicional en capas a través de charts de Helm y cualquier carga de trabajo del usuario a través de los manifiestos de Kubernetes proporcionados. Sin embargo, el principio de diseño detrás del uso de este método es que asumimos por defecto que el usuario desea usar un entorno aislado y, por lo tanto, cualquier elemento especificado en la definición de la imagen se incorporará a la imagen y a las cargas de trabajo proporcionadas por el usuario. EIB se asegurará de que cualquier imagen descubierta que sea requerida por las definiciones proporcionadas se copie localmente y que el registro de imágenes integrado las proporcione al sistema desplegado resultante.

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

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

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

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

Nota

Encontrará más ejemplos como despliegues de varios nodos, redes personalizadas y opciones/valores de chart de Helm en la documentación original.

3.3.6 Configuración de la red #

 

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

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

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

mkdir $CONFIG_DIR/network

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

Aviso

El ejemplo anterior está configurado para la subred predeterminada 192.168.122.0/24, suponiendo que la prueba se ejecuta en una máquina virtual. Adáptelo a su entorno, sin olvidar la dirección MAC. Dado que se puede utilizar la misma imagen para aprovisionar varios nodos, la configuración de red realizada por EIB (a través de nmc) depende de que pueda identificar de forma única el nodo por su dirección MAC y, por lo tanto, durante el arranque, nmc aplicará la configuración de red correcta a cada equipo. Esto significa que deberá conocer las direcciones MAC de los sistemas en los que desea realizar la instalación. Alternativamente, el comportamiento predeterminado es confiar en DHCP, pero puede utilizar el gancho configure-network.sh para aplicar una configuración común a todos los nodos. Consulte la guía sobre conexión de redes (Capítulo 12, Conexiones de red de Edge) para obtener más detalles.

La estructura de archivo resultante tendrá este aspecto:

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

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

Nota

Consulte la sección sobre el componente de red de Edge (Capítulo 12, Conexiones de red de Edge) para obtener una explicación más completa de la configuración anterior y ejemplos de esta función.

Ahora que tenemos una imagen base y una definición de imagen para que EIB la utilice, vamos a crear la imagen. Para ello, solo tenemos que usar Podman para llamar al contenedor EIB con el comando "build", especificando el archivo de definición:

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

El resultado del comando debe tener este aspecto:

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

La imagen ISO creada se guarda en $CONFIG_DIR/eib-image.iso:

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

Para cada imagen se crea una carpeta con marca de tiempo en $CONFIG_DIR/_build/ que incluye los registros del proceso de creación, los artefactos utilizados durante la creación y los directorios combustion y artefacts, que contienen todos los guiones y artefactos que se añaden a la imagen lista para arrancar.

El contenido de este directorio tendrá este aspecto:

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

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

En este punto, debe tener una imagen lista para usar que:

Si el proceso de creación de imágenes falla, consulte la guía original sobre depuración.

Para obtener instrucciones sobre cómo probar la imagen lista para arrancar recién creada, consulte la guía original sobre pruebas de imágenes.

Si ya tiene una instancia de la última versión de SUSE Multi-Linux Manager 5.0 en ejecución, puede omitir este paso.

Puede ejecutar SUSE Multi-Linux Manager Server en un servidor físico dedicado, como máquina virtual en su propio hardware, o en la nube. Se proporcionan imágenes de máquinas virtuales preconfiguradas para SUSE Multi-Linux Server para las nubes públicas compatibles.

En esta guía de inicio rápido se utiliza la imagen "qcow2" SUSE-Manager-Server.x86_64-5.0.2-Qcow-2024.12.qcow2 para AMD64/Intel 64. La puede encontrar en https://www.suse.com/download/suse-manager/ o en el Centro de servicios al cliente de SUSE. Esta imagen funciona como una máquina virtual en hipervisores como KVM. Compruebe siempre que dispone de la versión más reciente de la imagen y utilícela para las nuevas instalaciones.

También puede instalar SUSE Multi-Linux Manager Server en cualquier otra arquitectura de hardware compatible. En tal caso, elija la imagen que coincida con su arquitectura de hardware.

Una vez que haya descargado la imagen, cree una máquina virtual que cumpla, como mínimo, con las siguientes especificaciones de hardware:

Con la imagen qcow2, no es necesario instalar el sistema operativo. Puede conectar directamente la imagen como su partición raíz.

Debe configurar la red para que sus nodos periféricos puedan acceder posteriormente a SUSE Multi-Linux Manager Server con un nombre de host que contenga el nombre de dominio completo.

Cuando inicie SUSE Multi-Linux Manager por primera vez, deberá realizar algunas configuraciones iniciales:

Los pasos siguientes se deben realizar con permisos de usuario root:

Para el siguiente paso, necesitará dos códigos de registro, que encontrará en el Centro de servicios al cliente de SUSE:

Registre SUSE Linux Micro:

transactional-update register -r <REGCODE> -e <your_email>

Registre SUSE Multi-Linux Manager:

transactional-update register -p SUSE-Manager-Server/5.0/x86_64 -r <REGCODE>

La cadena del producto depende de la arquitectura de su hardware. Por ejemplo, si utiliza SUSE Multi-Linux Manager en un sistema ARM de 64 bits, la cadena es "SUSE-Manager-Server/5.0/aarch64".

Rearranque.

Actualice el sistema:

transactional-update

A menos que no haya habido cambios, reinicie el sistema para aplicar las actualizaciones.

SUSE Multi-Linux Manager se proporciona a través de un contenedor gestionado por Podman. El comando mgradm se encarga de la instalación y la configuración.

Aviso

Es muy importante que el nombre de host configurado en su instancia de SUSE Multi-Linux Manager Server tenga un nombre de dominio completo que los nodos periféricos que desea administrar puedan resolver correctamente en su red.

Antes de instalar y configurar el contenedor de SUSE Multi-Linux Manager Server, debe preparar el dispositivo de bloque adicional que ha añadido previamente. Para ello, debe conocer el nombre que la máquina virtual ha asignado al dispositivo. Por ejemplo, si el dispositivo de bloque es /dev/vdb, puede configurarlo para que se utilice con SUSE Multi-Linux Manager mediante el siguiente comando:

mgr-storage-server /dev/vdb

Despliegue SUSE Multi-Linux Manager:

mgradm install podman <FQDN>

Proporcione la contraseña para el certificado de CA. Esta contraseña debe ser diferente de sus contraseñas de inicio de sesión. Por lo general, no es necesario introducirla más adelante, pero debe anotarla.

Proporcione la contraseña para el usuario "admin". Se trata del usuario inicial para iniciar sesión en SUSE Multi-Linux Manager. Más adelante podrá crear usuarios adicionales con derechos completos o restringidos.

Una vez finalizado el despliegue, puede iniciar sesión en la interfaz de usuario web de SUSE Multi-Linux Manager utilizando el nombre de host que proporcionó anteriormente. El usuario inicial es "admin". Use la contraseña que proporcionó en el paso anterior.

Para el siguiente paso, necesitará las credenciales de su organización, que encontrará en la segunda subpestaña de la pestaña "Usuarios" de su organización en el Centro de servicios al cliente de SUSE. Con esas credenciales, SUSE Multi-Linux Manager puede sincronizar todos los productos a los que está suscrito.

Seleccione Admin › Setup Wizard (Admin > Asistente de configuración).

En la pestaña Organization Credentials (Credenciales de la organización) cree nuevas credenciales con sus datos de Username (Nombre de usuario) y Password (Contraseña) que encontró en el Centro de servicios al cliente de SUSE.

Diríjase a la pestaña siguiente, SUSE Products (Productos SUSE). Debe esperar hasta que finalice la primera sincronización de datos con el Centro de servicios al cliente de SUSE.

Cuando la lista se haya rellenado, utilice el filtro para mostrar solo "Micro 6". Marque la casilla de SUSE Linux Micro 6.1 para la arquitectura de hardware en la que se ejecutarán sus nodos periféricos (x86_64 o aarch64).

Haga clic en Add Products (Añadir productos). Esto añadirá el repositorio de paquetes principal ("canal") para SUSE Linux Micro y añadirá automáticamente el canal para las herramientas cliente de SUSE Manager como un subcanal.

Dependiendo de su conexión a Internet, la primera sincronización tardará un poco. Ya puede empezar con los siguientes pasos:

En Systems > System Groups (Sistemas > Grupos de sistemas), cree al menos un grupo al que sus sistemas se unirán automáticamente cuando se incorporen. Los grupos son una forma importante de categorizar los sistemas, ya que permiten aplicar configuraciones o acciones a un conjunto completo de sistemas a la vez. Conceptualmente, son similares a las etiquetas de Kubernetes.

Haga clic en + Create Group (Crear grupo).

Proporcione un nombre corto, por ejemplo, "Nodos periféricos", y una descripción detallada.

En Systems > Activation Keys (Sistemas > Claves de activación), cree al menos una clave de activación. Las claves de activación pueden considerarse como un perfil de configuración que se aplica automáticamente a los sistemas cuando se incorporan a SUSE Multi-Linux Manager. Si desea que determinados nodos periféricos se añadan a diferentes grupos o usen una configuración diferente, puede crear claves de activación independientes para ellos y utilizarlas posteriormente en Edge Image Builder para crear medios de instalación personalizados.

Un caso de uso avanzado típico de las claves de activación sería asignar los clústeres de prueba a los canales de software con las últimas actualizaciones y los clústeres de producción a los canales de software que solo reciben esas últimas actualizaciones una vez que se han probado en el clúster de prueba.

Haga clic en + Create Key (Crear clave).

Elija una descripción corta, por ejemplo, "Nodos periféricos". Proporcione un nombre único que identifique la clave, por ejemplo, "edge-x86_64" para sus nodos periféricos con arquitectura de hardware AMD64/Intel 64. Se añade automáticamente un prefijo numérico a la clave. Para la organización predeterminada, el número es siempre "1". Si crea organizaciones adicionales en SUSE Multi-Linux Manager y crea claves para ellas, ese número puede ser diferente.

Si no ha creado ningún canal de software duplicado, puede conservar la configuración del canal base como "SUSE Manager Default" (Predeterminada de SUSE Manager). De este modo, se asignará automáticamente el repositorio de actualizaciones de SUSE adecuado para sus nodos periféricos.

Como "Child Channel" (Canal secundario), seleccione el control deslizante "Include recommended" (Incluir recomendados) para la arquitectura de hardware para la que se utiliza su clave de activación. Esto añadirá el canal "SUSE-Manager-Tools-For-SL-Micro-6.1".

En la pestaña "Groups" (Grupos), añada el grupo que ha creado anteriormente. Todos los nodos que se incorporen utilizando esta clave de activación se añadirán automáticamente a ese grupo.

Para usar Edge Image Builder, solo necesita un entorno en el que pueda iniciar un contenedor basado en Linux con Podman.

Para una configuración mínima del laboratorio, es posible usar la misma máquina virtual en la que se ejecuta SUSE Multi-Linux Manager Server. Asegúrese de que dispone de suficiente espacio en disco en la máquina virtual. Esta configuración no es recomendable en entornos de producción. Consulte la Sección 3.1, “Requisitos previos” para conocer los sistemas operativos host con los que hemos probado Edge Image Builder.

Inicie sesión en su host de SUSE Multi-Linux Manager Server como usuario root.

Extraiga el contenedor de Edge Image Builder:

podman pull registry.suse.com/edge/3.3/edge-image-builder:1.2.1

Cree el directorio /opt/eib y un subdirectorio base-images:

mkdir -p /opt/eib/base-images

En esta guía de inicio rápido se usa la versión "autoinstalable" de la imagen de SUSE Linux Micro. Esa imagen se puede grabar posteriormente en una unidad USB física y utilizarse para la instalación en servidores físicos. Si su servidor tiene la opción de conexión remota de imágenes ISO de instalación a través de un BMC (Baseboard Management Controller), también puede utilizar ese método. Por último, esa imagen también se puede utilizar con la mayoría de las herramientas de virtualización.

Si desea precargar la imagen directamente en un nodo físico o iniciarla directamente desde una máquina virtual, también puede utilizar el tipo de imagen "raw".

Encontrará esas imágenes en el Centro de servicios al cliente de SUSE o en https://www.suse.com/download/sle-micro/.

Descargue o copie la imagen SL-Micro.x86_64-6.1-Default-SelfInstall-GM.install.iso en el directorio base-images y asígnele el nombre "slemicro.iso".

La creación de imágenes AArch64 en un host de creación basado en ARM es una tecnología en fase preliminar en SUSE Edge 3.3.1. Es muy probable que funcione, pero aún no es compatible. Si desea probarlo, debe ejecutar Podman en un equipo ARM de 64 bits y sustituir "x86_64" por "aarch64" en todos los ejemplos y fragmentos de código.

En /opt/eib, cree un archivo llamado iso-definition.yaml. Esta es tu definición de creación para Edge Image Builder.

En este sencillo ejemplo se instala SL Micro 6.1, se establece una contraseña raíz y el mapa de teclas, se inicia la interfaz gráfica Cockpit y se registra el nodo en SUSE Multi-Linux Manager:

apiVersion: 1.0
image:
  imageType: iso
  arch: x86_64
  baseImage: slemicro.iso
  outputImageName: eib-image.iso
operatingSystem:
  users:
  - username: root
    createHomeDir: true
    encryptedPassword: $6$aaBTHyqDRUMY1HAp$pmBY7.qLtoVlCGj32XR/Ogei4cngc3f4OX7fwBD/gw7HWyuNBOKYbBWnJ4pvrYwH2WUtJLKMbinVtBhMDHQIY0
  keymap: de
  systemd:
    enable:
      - cockpit.socket
  packages:
    noGPGCheck: true
  suma:
    host: ${fully qualified hostname of your SUSE Multi-Linux Manager Server}
    activationKey: 1-edge-x86_64

Edge Image Builder también puede configurar la red, instalar automáticamente Kubernetes en el nodo e, incluso, desplegar aplicaciones a través de charts de Helm. Consulte el Capítulo 3, Clústeres independientes con Edge Image Builder para obtener ejemplos más completos.

Para baseImage, especifique el nombre real de la ISO en el directorio base-images que desea utilizar.

En este ejemplo, la contraseña raíz sería "root". Consulte la Sección 3.3.1, “Configuración de usuarios del sistema operativo” para crear hashes para la contraseña segura que desea utilizar.

Defina el mapa de teclas de la disposición de teclado actual que desee que tenga el sistema después de la instalación.

Nota

Utilizamos la opción noGPGCheck: true porque no vamos a proporcionar una clave GPG para comprobar los paquetes RPM. En la guía original sobre instalación de paquetes encontrará instrucciones completas para realizar una configuración más segura, que se recomienda en entornos de producción.

Como se ha mencionado en varias ocasiones, el host de SUSE Multi-Linux Manager requiere un nombre de host completo que pueda resolverse en la red en la que se iniciarán los nodos periféricos.

El valor de activationKey debe coincidir con la clave que ha creado en SUSE Multi-Linux Manager.

Para crear una imagen de instalación que registre automáticamente sus nodos periféricos en SUSE Multi-Linux Manager después de la instalación, también debe preparar dos artefactos:

curl -O http://${HOSTNAME_OF_SUSE_MANAGER}/pub/repositories/slmicro/6/1/bootstrap/x86_64/venv-salt-minion-3006.0-3.1.x86_64.rpm

En /opt/eib, cree un subdirectorio certificates.

Descargue el certificado de CA de SUSE Multi-Linux Manager en ese directorio:

curl -O http://${HOSTNAME_OF_SUSE_MANAGER}/pub/RHN-ORG-TRUSTED-SSL-CERT

Aviso

Debe cambiar el nombre del certificado a RHN-ORG-TRUSTED-SSL-CERT.crt. Edge Image Builder se asegurará de que el certificado se instale y se active en el nodo periférico durante la instalación.

Ahora puede ejecutar Edge Image Builder:

cd /opt/eib
podman run --rm -it --privileged -v /opt/eib:/eib \
registry.suse.com/edge/3.3/edge-image-builder:1.2.1 \
build --definition-file iso-definition.yaml

Si ha usado un nombre diferente para su archivo de definición YAML o desea utilizar una versión diferente de Edge Image Builder, deberá adaptar el comando en consecuencia.

Una vez finalizada la creación, encontrará la imagen ISO de instalación en el directorio /opt/eib con el nombre eib-image.iso.

Rancher proporciona varias funcionalidades básicas a la pila de SUSE Edge:

SUSE Edge usa Capítulo 11, Edge Image Builder para personalizar las imágenes del sistema operativo base SUSE Linux Micro. Siga las instrucciones de la Sección 27.6, “Instalación de Rancher” para realizar una instalación en un entorno aislado de Rancher sobre clústeres de Kubernetes aprovisionados por EIB.

Todos los componentes de SUSE Edge 3.3.1, incluidas las extensiones de panel de control, se despliegan como artefactos OCI. Para instalar extensiones de SUSE Edge, puede usar la interfaz del usuario del panel de control de Rancher, Helm o Fleet:

6.1.2 Instalación con Helm #

 

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

# Akri extension
helm install akri-dashboard-extension oci://registry.suse.com/edge/charts/akri-dashboard-extension --version 303.0.2+up1.3.1 --namespace cattle-ui-plugin-system

Nota

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

Nota

Después de instalar una extensión, es necesario volver a cargar la interfaz de usuario del panel de control de Rancher.

6.1.3 Instalación con Fleet #

 

Para instalar extensiones de panel de control con Fleet, es necesario definir un recurso gitRepo que apunte a un repositorio Git con archivos de configuración fleet.yaml de bundle personalizados.

# 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: "303.0.2+up1.3.2"

# Akri extension fleet.yaml
defaultNamespace: cattle-ui-plugin-system
helm:
  releaseName: akri-dashboard-extension
  chart: oci://registry.suse.com/edge/charts/akri-dashboard-extension
  version: "303.0.2+up1.3.1"

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/
  - fleets/akri-dashboard-extension/
EOF

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

Después de que se hayan instalado las extensiones, aparecen en la sección Extensions (Extensiones) de la pestaña Installled (Instaladas). Dado que no se instalan a través de Apps/Marketplace, se marcan con la etiqueta Third-Party (De terceros).

La extensión KubeVirt proporciona funciones básicas de gestión de máquinas virtuales para la interfaz de usuario del panel de control de Rancher. Sus capacidades se describen en la Sección 21.7.2, “Uso de la extensión de panel de control KubeVirt de Rancher”.

Akri es una interfaz de recursos de Kubernetes que permite exponer fácilmente dispositivos periféricos heterogéneos (como cámaras IP y dispositivos USB) como recursos en un clúster de Kubernetes, al tiempo que admite la exposición de recursos de hardware integrados, como GPU y FPGA. Akri detecta continuamente los nodos que tienen acceso a estos dispositivos y programa las cargas de trabajo en función de ellos.

La extensión de panel de control Akri permite utilizar la interfaz de usuario del panel de control de Rancher para gestionar y supervisar dispositivos periféricos y ejecutar cargas de trabajo una vez que se han detectado dichos dispositivos.

Las capacidades de la extensión se describen en más detalle en la Sección 14.5, “Extensión de panel de control Akri de Rancher”.

La pila de SUSE Edge proporciona un chart wrapper de Helm que instala Rancher Turtles con una configuración específica que habilita lo siguiente:

Solo se admiten los proveedores predeterminados instalados a través del chart wrapper. Los proveedores alternativos de plano de control, arranque e infraestructura no son compatibles actualmente como parte de la pila de SUSE Edge.

Rancher Turtles se puede instalar siguiendo las instrucciones de la guía de inicio rápido de Metal3 (Capítulo 1, Despliegues automatizados de BMC con Metal³) o la documentación del clúster de gestión (Capítulo 40, Configuración del clúster de gestión).

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

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

Fleet funciona de forma óptima como parte integrante de Rancher. En los clústeres gestionados con Rancher se despliega automáticamente el agente de Fleet como parte del proceso de instalación/importación, y el clúster queda inmediatamente disponible para ser gestionado por Fleet.

Fleet viene preinstalado en Rancher y se gestiona con la opción Continuous Delivery (Entrega continua) en la interfaz de usuario de Rancher.

La sección Continuous Delivery (Entrega continua) incluye estos elementos:

La sección "Advanced" (Avanzado) ofrece una visión general de los recursos de Fleet de nivel inferior. Un bundle es un recurso interno que se utiliza para la coordinación de recursos de Git. Cuando se analiza un repositorio Git, se generan uno o varios Bundles.

Para encontrar 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.

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

Para consejos sobre la resolución de problemas de Fleet, consulte este documento.

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

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

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

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

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

Este método proporciona API declarativas que permiten la gestión del inventario y el estado de los servidores bare metal, incluyendo la inspección, la limpieza y el aprovisionamiento/desaprovisionamiento automatizados.

SUSE Edge utiliza EIB para la configuración simplificada y rápida de imágenes de SUSE Linux Micro personalizadas en distintas situaciones. Por ejemplo, para el arranque de máquinas virtuales y bare metal con lo siguiente:

Encontrará la documentación completa sobre el uso y las pruebas de Edge Image Builder aquí.

Asimismo, en el Capítulo 3, Clústeres independientes con Edge Image Builder se explica un escenario básico de despliegue.

Cuando se haya familiarizado con esta herramienta, encontrará más información útil en la página de consejos y trucos.

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

NetworkManager almacena las configuraciones de redes como archivos de conexión que contienen el estado deseado en el directorio /etc/NetworkManager/system-connections/.

Encontrará más información sobre NetworkManager en la documentación de SUSE Linux Micro.

nmstate es una biblioteca de amplia adopción (que incluye una herramienta de interfaz de línea de comandos) que ofrece una API declarativa para configuraciones de red a través de un esquema predefinido.

Encontrará información sobre nmstate en la documentación original.

Para acceder a las opciones de personalización de redes disponibles en SUSE Edge se usa una herramienta de interfaz de línea de comandos llamada NetworkManager Configurator, o nmc para abreviar. Aprovecha la funcionalidad que ofrece la biblioteca nmstate y es capaz de configurar por si sola direcciones IP estáticas, servidores DNS, VLAN, vinculaciones, puentes, etc. Esta herramienta permite generar configuraciones de redes a partir de estados predefinidos deseados y aplicarlas de forma automatizada en muchos nodos diferentes.

Encontrará información sobre NetworkManager Configurator (nmc) en el repositorio original.

SUSE Edge usa nmc para personalizar las redes en los distintos modelos de aprovisionamiento:

Edge Image Builder (EIB) es una herramienta que permite configurar varios hosts con una sola imagen del sistema operativo. En esta sección, se muestra 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.3/edge-image-builder:1.2.1

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

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

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

cat << EOF > $CONFIG_DIR/definition.yaml
apiVersion: 1.2
image:
  arch: x86_64
  imageType: raw
  baseImage: SL-Micro.x86_64-6.1-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.1-Base-GM.raw

12.5.5 Definición de las configuraciones de redes #

 

Las configuraciones de redes deseadas no forman parte del archivo de definición de imagen que se acaba de crear. Se introducen ahora en el directorio network/ especial. Vamos a crearlo:

mkdir -p $CONFIG_DIR/network

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

En esta guía se explica cómo configurar la red en tres nodos diferentes:

• Un nodo que usa dos interfaces Ethernet

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

• Un nodo que usa un puente de redes

Aviso

No se recomienda utilizar configuraciones de redes completamente diferentes en entornos de producción, especialmente si se configuran clústeres de Kubernetes. Las configuraciones de redes deben ser, por lo general, homogéneas entre los nodos o, al menos, entre las funciones dentro de un clúster determinado. Esta guía incluye varias opciones diferentes solo a modo de referencia.

Nota

En el ejemplo siguiente se entiende que se usa una red libvirt predeterminada con un rango de direcciones IP 192.168.122.1/24. Ajústelo según las necesidades concretas de su entorno.

Vamos a crear 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:
      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 el 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 incluidas en la lista. Estas direcciones se utilizan durante el proceso de aprovisionamiento como identificadores de los nodos y sirven para determinar qué configuraciones deben aplicarse. De esta manera, podemos configurar varios nodos utilizando una sola imagen ISO o RAW.

El siguiente es 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:
      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 permiten 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 usará 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:
      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 momento 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.1-Base-GM.raw

Nota

Los nombres de los archivos del 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.3/edge-image-builder:1.2.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.3/edge-image-builder:1.2.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

12.5.9 Configuraciones de red personalizadas #

 

Ya hemos tratado la configuración de red predeterminada para Edge Image Builder, que se basa en 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 su uso resulta mucho menos práctico cuando se arrancan varios nodos con una sola imagen.

Nota

Se recomienda utilizar la configuración de red predeterminada mediante archivos que describen los estados de red deseados en el directorio /network. Utilice guiones personalizados únicamente cuando ese comportamiento no sea aplicable a su caso de uso.

Crearemos y aprovisionaremos un nodo periférico con una estructura de configuración diferente. Siga todos los pasos desde la Sección 12.5.3, “Creación del directorio de configuración de imágenes” hasta la Sección 12.5.5, “Definición de las configuraciones de redes”.

En este ejemplo, crearemos un guion personalizado que aplica una configuración estática para la interfaz eth0 en todos los nodos aprovisionados, además de eliminar e inhabilitar las conexiones con cable que haya creado automáticamente NetworkManager. Esto resulta útil en situaciones en las que se desea garantizar que todos los nodos del clúster tengan una configuración de red idéntica, por lo que no es necesario preocuparse por la dirección MAC de cada nodo antes de crear la imagen.

Para empezar, se almacena 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 ya hemos creado la configuración estática, 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 de nmc seguirá estando incluido por defecto, por lo que también se puede utilizar en el guion configure-network.sh si es necesario.

Aviso

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

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

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

Vamos a crear la imagen:

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

Cuando la imagen se haya creado correctamente, crearemos una máquina virtual con dicha imagen:

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, inicie sesión en el sistema con las credenciales proporcionadas.

Verifique que la configuración de enrutamiento sea correcta:

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

Verifique 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

Verifique que se ha configurado de forma estática una interfaz Ethernet utilizando nuestro archivo de conexión y que esta interfaz 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

Partes de Elemental se usan para gestionar dispositivos remotos en caso de que no sea posible hacerlo con Metal³ (por ejemplo, si no hay BMC o si el dispositivo está tras una puerta de enlace NAT). Esto permite a los operadores arrancar sus dispositivos en un laboratorio antes de saber cuándo o dónde se enviarán. En concreto, se aprovechan los componentes elemental-register y elemental-system-agent para permitir la incorporación de hosts de SUSE Linux Micro en Rancher para casos de uso de aprovisionamiento de red "phone home". Si se usa Edge Image Builder (EIB) para crear imágenes de despliegue, es posible realizar el registro automático a través de Rancher vía Elemental especificando la configuración de registro en el directorio de configuración de EIB.

Nota

En SUSE Edge 3.3.1 no se aprovechan las funciones de gestión del sistema operativo de Elemental, por lo que no es posible gestionar los parches del sistema operativo a través de Rancher. En lugar de utilizar las herramientas de Elemental para crear imágenes de despliegue, SUSE Edge usa Edge Image Builder, que hace uso de la configuración de registro.

Aviso

Akri es actualmente una tecnología en fase preliminar en la pila de SUSE Edge.

Akri está disponible como parte de la pila de Edge siempre que sea necesario detectar y programar cargas de trabajo en dispositivos periféricos.

Akri está disponible como un chart de Helm dentro del repositorio de Helm de Edge. La forma recomendada de configurar Akri es utilizando el chart de Helm proporcionado para desplegar los diferentes componentes (agente, controlador, gestores de descubrimiento) y, a continuación, utilizar su mecanismo de despliegue preferido para desplegar las CRD de configuración de Akri.

Akri se configura mediante un objeto akri.sh/Configuration. En él, se recopila toda la información sobre cómo detectar los dispositivos, así como indicaciones de qué hacer cuando se detecta uno compatible.

A continuación se muestra un ejemplo de la configuración con todos los campos explicados:

apiVersion: akri.sh/v0
kind: Configuration
metadata:
  name: sample-configuration
spec:

Esta parte describe la configuración del controlador de detección. Debe especificar su nombre (los controladores disponibles como parte del chart de Akri son udev, opcua y onvif). discoveryDetails es específico de cada controlador; consulte la documentación del controlador para saber cómo configurarlo.

  discoveryHandler:
    name: debugEcho
    discoveryDetails: |+
      descriptions:
        - "foo"
        - "bar"

Esta sección define la carga de trabajo que se desplegará para cada dispositivo detectado. El ejemplo muestra una versión mínima de una configuración de pod en brokerPodSpec. Aquí se pueden utilizar todos los campos habituales de la especificación de un pod. También muestra la sintaxis específica de Akri para solicitar el dispositivo en la sección resources.

Como alternativa, puede utilizar un trabajo en lugar de un pod, utilizando la clave brokerJobSpec y proporcionándole la parte específica de un trabajo.

  brokerSpec:
    brokerPodSpec:
      containers:
      - name: broker-container
        image: rancher/hello-world
        resources:
          requests:
            "{{PLACEHOLDER}}" : "1"
          limits:
            "{{PLACEHOLDER}}" : "1"

Estas dos secciones muestran cómo configurar Akri para desplegar un servicio por agente (instanceService) o apuntando a todos los agentes (configurationService). Contienen todos los elementos relacionados con un servicio habitual.

  instanceServiceSpec:
    type: ClusterIp
    ports:
    - name: http
      port: 80
      protocol: tcp
      targetPort: 80
  configurationServiceSpec:
    type: ClusterIp
    ports:
    - name: https
      port: 443
      protocol: tcp
      targetPort: 443

El campo brokerProperties es un almacén de claves/valores que se expondrán como variables de entorno adicionales a cualquier pod que solicite un dispositivo detectado.

La capacidad es el número permitido de usuarios simultáneos de un dispositivo detectado.

  brokerProperties:
    key: value
  capacity: 1

En caso de que el protocolo utilizado por su dispositivo no esté cubierto por un controlador de detección existente, puede escribir su propio protocolo utilizando la guía de desarrollo de controladores.

La extensión de panel de control Akri permite utilizar la interfaz de usuario del panel de control de Rancher para gestionar y supervisar dispositivos periféricos y ejecutar cargas de trabajo una vez que se han detectado dichos dispositivos.

Consulte el Capítulo 6, Extensiones de panel de control de Rancher para obtener instrucciones sobre la instalación.

Una vez instalada la extensión, puede dirigirse a cualquier clúster gestionado compatible con Akri utilizando el explorador de clústeres. En el grupo de navegación Akri, puede ver las secciones Configurations (Configuraciones) e Instances (Instancias).

La lista de configuraciones proporciona información sobre Configuration Discovery Handler (gestor de detección de configuraciones) y el número de instancias. Al hacer clic en el nombre, se abre una página con los detalles de la configuración.

También puede editar o crear una nueva configuración. La extensión le permite seleccionar el controlador de detección, configurar el pod o el trabajo del agente, personalizar las configuraciones y los servicios de instancia, y establecer la capacidad de configuración.

Los dispositivos descubiertos se muestran en la lista Instances (Instancias).

Al hacer clic en un nombre de Instance (Instancia), se abre una página de detalles donde se muestran las cargas de trabajo y el servicio de la instancia.

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

El uso de K3s como distribución de Kubernetes de la pila de SUSE Edge solo se recomienda cuando resulta imposible usar etcd como backend. Si es posible usar etcd como backend, es mejor utilizar RKE2 (Capítulo 16, RKE2).

K3s es una distribución de Kubernetes totalmente compatible y ligera, centrada en Edge, IoT y ARM, optimizada para que su uso sea sencillo y para entornos con recursos limitados.

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

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

De RKE1, hereda una estrecha alineación con la versión original de Kubernetes. En algunos aspectos, K3s se ha desviado de la versión original de Kubernetes con el fin de optimizar los despliegues periféricos; pero RKE1 y RKE2 pueden mantenerse estrechamente alineados con dicha versión original.

RKE2 es una pieza fundamental de la pila de SUSE Edge. Se sitúa sobre SUSE Linux Micro (Capítulo 9, SUSE Linux Micro) y proporciona una interfaz de Kubernetes estándar necesaria para desplegar cargas de trabajo de Edge.

Si está siguiendo esta guía, se da por hecho que ya dispone de lo siguiente:

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

Vamos a crear un recurso 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 ya tenemos nuestro StorageClass, necesitamos una solicitud PersistentVolumeClaim que haga referencia a él. Una PersistentVolumeClaim (PVC) es una solicitud de almacenamiento por parte de un usuario. Las PVC consumen recursos PersistentVolume. Las solicitudes pueden pedir tamaños y modos de acceso específicos (por ejemplo, se pueden montar una vez en modo lectura/escritura o varias veces en modo 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

Tras crear la PersistentVolumeClaim, podemos adjuntarla a un pod. Cuando se despliega el pod, Kubernetes crea el volumen de Longhorn y lo vincula al ood 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 más comunes de Kubernetes, sin embargo, le sugerimos que se familiarice con la terminología específica en la documentación de Longhorn.

En este ejemplo, el resultado debería ser similar 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 ha instalado Longhorn con kubectl o Helm, debe configurar un controlador Ingress para permitir el tráfico externo hacia el clúster. La autenticación no está habilitada de forma predeterminada. Si se ha usado la aplicación de catálogo de Rancher, Rancher habrá creado automáticamente un controlador Ingress con control de acceso (el proxy de rancher).

SUSE Edge utiliza Capítulo 11, Edge Image Builder para personalizar las imágenes del sistema operativo SUSE Linux Micro base. Vamos a mostrar cómo hacerlo para aprovisionar un clúster RKE2 con Longhorn 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.2
image:
  imageType: iso
  baseImage: SL-Micro.x86_64-6.1-Base-SelfInstall-GM.install.iso
  arch: x86_64
  outputImageName: eib-image.iso
kubernetes:
  version: v1.32.4+rke2r1
  helm:
    charts:
      - name: longhorn
        version: 106.2.0+up1.8.1
        repositoryName: longhorn
        targetNamespace: longhorn-system
        createNamespace: true
        installationNamespace: kube-system
      - name: longhorn-crd
        version: 106.2.0+up1.8.1
        repositoryName: longhorn
        targetNamespace: longhorn-system
        createNamespace: true
        installationNamespace: kube-system
    repositories:
      - name: longhorn
        url: https://charts.rancher.io
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 chart de Helm mediante un archivo independiente proporcionado en helm.charts[].valuesFile. Consulte la documentación original para obtener más detalles.

Vamos a crear la imagen:

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

Una vez creada la imagen, puede usarla para instalar su sistema operativo en un host físico o virtual. Tras completar el aprovisionamiento, podrá iniciar sesión en el sistema utilizando el par de credenciales root:eib.

Asegúrese de que Longhorn 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 funciona en entornos completamente aislados. Para esos casos, consulte la Sección 27.8, “Instalación de SUSE Storage”.

SUSE Edge proporciona una configuración más ágil de SUSE Security como punto de partida para despliegues periféricos.

SUSE Edge utiliza Capítulo 11, Edge Image Builder para personalizar las imágenes del sistema operativo SUSE Linux Micro base. Siga las instrucciones de la Sección 27.7, “Instalación de SUSE Security” para realizar una instalación en entornos aislados de SUSE Security sobre clústeres de Kubernetes aprovisionados por EIB.

SUSE Edge usa MetalLB principalmente de dos formas:

Nota

Para poder exponer la API, se utiliza el operador Endpoint Copier Operator (Capítulo 20, Endpoint Copier Operator) para mantener sincronizados los puntos finales de la API de K8s desde el servicio kubernetes con un servicio LoadBalancer kubernetes-vip.

La instalación de MetalLB en el modo L2 se describe en el Capítulo 25, MetalLB en K3s (con el modo de capa 2).

Hay disponible una guía sobre cómo instalar MetalLB delante del kube-api-server para lograr una topología de alta disponibilidad en el Capítulo 26, MetalLB delante del servidor de Kubernetes API.

En SUSE Edge, Endpoint Copier Operator desempeña un papel crucial para conseguir una configuración de alta disponibilidad (HA) para clústeres K3s/RKE2. Esto se logra creando un servicio kubernetes-vip de tipo LoadBalancer, lo que garantiza que su punto final se sincronice constantemente con el punto final de Kubernetes. MetalLB (Capítulo 19, MetalLB) se utiliza 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 Endpoint Copier Operator se encuentra aquí.

También puede consultar nuestra guía (Capítulo 25, MetalLB en K3s (con el modo de capa 2)) sobre cómo lograr una configuración HA de K3s/RKE2 utilizando Endpoint Copier Operator y MetalLB.

Actualmente, Endpoint Copier Operator solo puede trabajar con un servicio/punto final. Se prevé realizar mejoras en el futuro para admitir múltiples servicios/puntos finales.

KubeVirt permite gestionar máquinas virtuales con Kubernetes junto con el resto de sus cargas de trabajo en contenedores. Para ello, ejecuta 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 facilita la configuración y la gestión.

Si está siguiendo esta guía, se da por hecho que ya dispone de lo siguiente:

Esta guía no explica el despliegue de Kubernetes, pero da por sentado que ha instalado la versión de K3s o RKE2 adecuada para SUSE Edge y que tiene su kubeconfig configurada adecuadamente para que los comandos estándar kubectl se puedan ejecutar como superusuario. También se presupone 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 charts de Helm distintos, en concreto:

Cada uno de estos charts de Helm tiene versiones distintas según la versión de SUSE Edge que esté utilizando actualmente. Para usarlos en entornos de producción o con asistencia, utilice los artefactos que se pueden encontrar en el registro de SUSE.

En primer lugar, asegúrese de que puede acceder correctamente a kubectl:

$ 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 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 comprobar que todos los recursos se han desplegado en los espacios de nombres kubevirt-system y cdi-system.

Verifique 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

Verifique 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 personalizados (CRD) de VirtualMachine están desplegadas, puede usar:

$ kubectl explain virtualmachine

Esto debería dar como resultado la definición del objeto VirtualMachine, que debería tener este aspecto:

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 se han desplegado, vamos a definir una máquina virtual sencilla basada en openSUSE Tumbleweed. La configuración de esta máquina virtual es muy sencilla: usa una "conexión de red de pod" idéntica a la de cualquier otro pod. También emplea almacenamiento no persistente, lo que garantiza que el almacenamiento sea efímero, al igual que en cualquier contenedor que no tenga un PVC.

$ 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: registry.opensuse.org/home/roxenham/tumbleweed-container-disk/containerfile/cloud-image:latest
        name: tumbleweed-containerdisk-0
      - cloudInitNoCloud:
          userDataBase64: I2Nsb3VkLWNvbmZpZwpkaXNhYmxlX3Jvb3Q6IGZhbHNlCnNzaF9wd2F1dGg6IFRydWUKdXNlcnM6CiAgLSBkZWZhdWx0CiAgLSBuYW1lOiBzdXNlCiAgICBncm91cHM6IHN1ZG8KICAgIHNoZWxsOiAvYmluL2Jhc2gKICAgIHN1ZG86ICBBTEw9KEFMTCkgTk9QQVNTV0Q6QUxMCiAgICBsb2NrX3Bhc3N3ZDogRmFsc2UKICAgIHBsYWluX3RleHRfcGFzc3dkOiAnc3VzZScK
        name: cloudinitdisk
EOF

El resultado debe ser que se ha creado una VirtualMachine:

virtualmachine.kubevirt.io/tumbleweed created

Esta definición de VirtualMachine es mínima y especifica muy poco sobre la configuración. Solo indica que se trata de una máquina de tipo q35 con 2 GB de memoria que usa 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 con cifrado base64, que solo utilizamos para la creación de usuarios y la obligación de usar contraseña en el momento del arranque (utilice base64 -d para descifrarlo).

Esta máquina tarda unos minutos en arrancar, ya que necesita descargar la imagen de disco de openSUSE Tumbleweed, pero una vez que lo haya hecho, podrá ver más detalles sobre ella:

$ kubectl get vmi

Esto debería dar como resultado 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 conexión de red de pod, la dirección IP indicada será igual que la de cualquier otro pod y, por lo tanto, enrutable:

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 conectarse directamente por ssh a la máquina. Sustituya la siguiente dirección IP por la que se le haya asignado a su máquina virtual:

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

Cuando se encuentre en esta máquina virtual, puede practicar un poco, pero recuerde que tiene recursos limitados y solo cuenta con 1 GB de espacio en disco. Cuando termine, pulse 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. La CRD VirtualMachine es una representación de la máquina virtual deseada, pero el proceso en el que se inicia realmente la máquina virtual es a través del pod virt-launcher, un pod estándar de Kubernetes, igual que cualquier otra aplicación. Por cada máquina virtual iniciada, se puede ver que hay un pod virt-launcher:

$ kubectl get pods

Esto debería mostrar el único pod virt-launcher para la máquina Tumbleweed que hemos definido:

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

Si echamos un vistazo a este pod virt-launcher, veremos que está ejecutando los procesos libvirt y qemu-kvm. Podemos entrar en el propio pod y echar un vistazo, pero tenga en cuenta que es necesario adaptar el siguiente comando al nombre de su pod:

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

Una vez en el pod, pruebe a ejecutar comandos virsh y observe los procesos. Comprobará que se está ejecutando el binario qemu-system-x86_64, 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, eliminemos esta máquina virtual:

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

Además de la estándar de Kubernetes (kubectl), KubeVirt incluye una interfaz de línea de comandos adicional que permite interactuar con el clúster de una forma que obvia ciertas diferencias entre los entornos de virtualización y los usos para los que se diseñó Kubernetes. Por ejemplo, la herramienta virtctl permite gestionar el ciclo de vida de las máquinas virtuales (iniciar, detener, reiniciar, etc.), proporciona acceso a los paneles de control virtuales, permite cargar imágenes de máquinas virtuales e interactuar con construcciones de Kubernetes como servicios, sin utilizar directamente la API o las CRD.

Vamos a descargar la última versión estable de la herramienta virtctl:

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

Si utiliza una arquitectura diferente o una máquina que no sea Linux, encontrará otras versiones aquí. Debe hacer que este archivo sea ejecutable antes de continuar, y puede ser útil moverlo a una ubicación dentro de $PATH:

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

A continuación, puede utilizar la herramienta de línea de comandos virtctl para crear máquinas virtuales. Vamos a replicar nuestra máquina virtual anterior, teniendo en cuenta que estamos canalizando la salida directamente a kubectl apply:

$ virtctl create vm --name virtctl-example --memory=1Gi \
    --volume-containerdisk=src:registry.opensuse.org/home/roxenham/tumbleweed-container-disk/containerfile/cloud-image:latest \
    --cloud-init-user-data "I2Nsb3VkLWNvbmZpZwpkaXNhYmxlX3Jvb3Q6IGZhbHNlCnNzaF9wd2F1dGg6IFRydWUKdXNlcnM6CiAgLSBkZWZhdWx0CiAgLSBuYW1lOiBzdXNlCiAgICBncm91cHM6IHN1ZG8KICAgIHNoZWxsOiAvYmluL2Jhc2gKICAgIHN1ZG86ICBBTEw9KEFMTCkgTk9QQVNTV0Q6QUxMCiAgICBsb2NrX3Bhc3N3ZDogRmFsc2UKICAgIHBsYWluX3RleHRfcGFzc3dkOiAnc3VzZScK" | kubectl apply -f -

Esto debería mostrar la máquina virtual en ejecución (esta vez debería iniciarse mucho más rápido, ya que la imagen del contenedor estará almacenada 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 conectarnos directamente a la máquina virtual:

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

Se pueden utilizar muchos otros comandos con virtctl. Por ejemplo, virtctl console permite acceder al panel de control serie si la red no funciona, y puede utilizar virtctl guestosinfo para obtener información completa sobre el sistema operativo, siempre que el invitado tenga instalado y en ejecución qemu-guest-agent.

Por último, hagamos una pausa y reiniciemos la máquina virtual:

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

Verá que el objeto VirtualMachine aparece como Paused (En pausa) y el objeto VirtualMachineInstance aparece como Running (En ejecución), pero como 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 comprobará que ya no puede conectarse 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

Reiniciemos la máquina virtual y volvamos a intentarlo:

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

Ahora deberíamos poder restablecer la conexión:

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

Por último, eliminemos la máquina virtual:

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

En esta sección, se explica cómo exponer máquinas virtuales como servicios estándar de Kubernetes y cómo hacerlas disponibles mediante el servicio Ingress de Kubernetes; por ejemplo, NGINX con RKE2 o Traefik con K3s. En este documento se entiende que estos componentes ya están configurados adecuadamente y que dispone de un puntero DNS adecuado (por ejemplo, un comodín) que dirija a los nodos de su servidor de Kubernetes o a su IP virtual de Ingress para que Ingress se resuelva adecuadamente.

En el entorno de ejemplo, se despliega otra máquina virtual Tumbleweed de openSUSE, se usa cloud-init para instalar NGINX como servidor Web sencillo en el momento del arranque y se configura un mensaje sencillo, que se envía para verificar que funciona según lo esperado cuando se realiza una llamada. Para ver cómo se hace, use el comando base64 -d en la sección cloud-init del siguiente ejemplo.

Vamos a crear esta máquina virtual:

$ 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: registry.opensuse.org/home/roxenham/tumbleweed-container-disk/containerfile/cloud-image:latest
        name: tumbleweed-containerdisk-0
      - cloudInitNoCloud:
          userDataBase64: I2Nsb3VkLWNvbmZpZwpkaXNhYmxlX3Jvb3Q6IGZhbHNlCnNzaF9wd2F1dGg6IFRydWUKdXNlcnM6CiAgLSBkZWZhdWx0CiAgLSBuYW1lOiBzdXNlCiAgICBncm91cHM6IHN1ZG8KICAgIHNoZWxsOiAvYmluL2Jhc2gKICAgIHN1ZG86ICBBTEw9KEFMTCkgTk9QQVNTV0Q6QUxMCiAgICBsb2NrX3Bhc3N3ZDogRmFsc2UKICAgIHBsYWluX3RleHRfcGFzc3dkOiAnc3VzZScKcnVuY21kOgogIC0genlwcGVyIGluIC15IG5naW54CiAgLSBzeXN0ZW1jdGwgZW5hYmxlIC0tbm93IG5naW54CiAgLSBlY2hvICJJdCB3b3JrcyEiID4gL3Nydi93d3cvaHRkb2NzL2luZGV4Lmh0bQo=
        name: cloudinitdisk
EOF

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

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

A continuación, se crea automáticamente el servicio adecuado:

$ 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

Ahora, si utiliza kubectl create ingress, puede crear un objeto Ingress que apunte a este servicio. Adapte la URL (conocida como "host" en el objeto ingress) aquí para que coincida con su configuración de DNS y asegúrese de que apunta al puerto 8080:

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

Con el servidor DNS configurado correctamente, debería poder ejecutar el comando curl en la URL de inmediato:

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

Para limpiar, eliminaremos esta máquina virtual y sus recursos de servicio y de 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 interfaz de usuario para Rancher Manager, lo que permite la gestión básica de máquinas virtuales mediante la interfaz de usuario del panel de control de Rancher.

21.7.2 Uso de la extensión de panel de control KubeVirt de Rancher #

 

La extensión introduce una nueva sección KubeVirt en Cluster Explorer. Esta sección se añade a cualquier clúster gestionado que tenga instalado KubeVirt.

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

21.7.2.1 Creación de una máquina virtual #

 

1. En el panel de navegación izquierdo, diríjase a Cluster Explorer (Explorador de clústeres) haciendo clic en el clúster gestionado habilitado para KubeVirt.

2. Diríjase a la página KubeVirt > Virtual Machines (KubeVirt > Máquinas virtuales) y haga clic en Create from YAML (Crear desde YAML) en la parte superior derecha de la pantalla.

3. Rellene o pegue una definición de máquina virtual y pulse Create (Crear). Use la definición de máquina virtual de la sección Despliegue de máquinas virtuales como referencia.

21.7.2.2 Acciones de la máquina virtual #

 

Puede utilizar el menú de acciones al que se accede desde la lista desplegable ⋮ situada a la derecha de cada máquina virtual para iniciar, detener, pausar o hacer un reinicio suave. También puede usar las acciones de grupo de la parte superior de la lista seleccionando las máquinas virtuales en las que desea realizar la acción.

Estas acciones pueden afectar a la estrategia de ejecución de la máquina virtual. Consulte la tabla en la documentación de KubeVirt para obtener más detalles.

21.7.2.3 Acceso al panel de control de la máquina virtual #

 

La lista "Virtual Machines" (Máquinas virtuales) proporciona una lista desplegable Console (Panel de control) que permite conectarse a la máquina mediante VNC o un panel de control serie. Esta acción solo está disponible para máquinas en ejecución.

En algunos casos, para poder acceder al panel de control en una máquina virtual recién iniciada se debe esperar un poco.

SUSE Edge usa Capítulo 11, Edge Image Builder para personalizar las imágenes del sistema operativo SUSE Linux Micro base. Siga las instrucciones de la Sección 27.9, “Instalación de KubeVirt y CDI” para realizar una instalación en un entorno aislado tanto de KubeVirt como de CDI sobre clústeres de Kubernetes aprovisionados por EIB.

SUSE Edge usa SUC para facilitar diversas operaciones de "día 2" relacionadas con las actualizaciones de la versión del sistema operativo y Kubernetes en los clústeres de gestión y descendentes.

Las operaciones de "día 2" se definen mediante planes de SUC. Según esos planes, SUC despliega las cargas de trabajo en cada nodo para ejecutar la operación correspondiente de "día 2".

SUC también se utiliza en Capítulo 23, Upgrade Controller. Para obtener más información sobre las diferencias clave entre SUC y Upgrade Controller, consulte la Sección 23.2, “Diferencias entre Upgrade Controller y System Upgrade Controller”.

Importante

A partir de la versión 2.10.0 de Rancher, System Upgrade Controller se instala automáticamente.

Siga los pasos siguientes solo si su entorno no está gestionado por Rancher, o si su versión de Rancher es anterior a la 2.10.0.

Se recomienda instalar SUC mediante Fleet (Capítulo 8, Fleet), situado 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 válida de fleet-examples. Para determinar qué versión debe utilizar, consulte las Notas de la versión (Sección 52.1, “Resumen”).

Si no puede utilizar Fleet para la instalación de SUC, puede instalarlo mediante el repositorio de charts de Helm de Rancher o incorporar el chart de Helm de Rancher en su propio flujo de trabajo de GitOps de terceros.

En esta sección se trata lo siguiente:

22.2.1 Instalación de System Upgrade Controller con Fleet #

 

Hay dos posibles recursos que se pueden usar para desplegar SUC mediante Fleet:

• Recurso GitRepo: para casos de uso en los que se dispone de un servidor Git externo/local. Para obtener instrucciones de instalación, consulte la sección Instalación de System Upgrade Controller - GitRepo (Sección 22.2.1.1, “Instalación de System Upgrade Controller - GitRepo”).

• Recurso Bundle: para casos de uso en entornos aislados que no admiten la opción de servidor Git local. Para obtener instrucciones de instalación, consulte la sección Instalación de System Upgrade Controller - Bundle (Sección 22.2.1.2, “Instalación de System Upgrade Controller - Bundle”).

22.2.1.1 Instalación de System Upgrade Controller - GitRepo #

 

Nota

Este proceso también se puede realizar a través de la interfaz de usuario de Rancher, si está disponible. Para obtener más información, consulte Accessing Fleet in the Rancher UI (Acceso a Fleet en la interfaz de Rancher).

En el clúster de gestión:

1. Determine en qué clústeres desea desplegar SUC. Para ello, despliegue un recurso GitRepo de SUC en el espacio de trabajo correcto de Fleet de su clúster de gestión. De forma predeterminada, Fleet tiene dos espacios de trabajo:

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

   • fleet-default: para recursos que deben desplegarse en clústeres descendentes.

     Para obtener más información sobre los espacios de trabajo de Fleet, consulte la documentación original.

2. Despliegue el recurso GitRepo:

   • Para desplegar SUC en el 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.3.0
       paths:
       - fleets/day2/system-upgrade-controller
       repo: https://github.com/suse-edge/fleet-examples.git
     EOF

   • Para desplegar SUC en los clústeres descendentes:

     

     Nota

     Antes de desplegar el recurso que se indica a continuación, debe proporcionar una configuración válida para targets, de modo que Fleet sepa en qué clústeres descendentes debe desplegar su recurso. Para obtener más información sobre cómo realizar la asignación a clústeres descendentes, consulte Mapping to Downstream Clusters (Asignación a clústeres descendentes).

     kubectl apply -n fleet-default -f - <<EOF
     apiVersion: fleet.cattle.io/v1alpha1
     kind: GitRepo
     metadata:
       name: system-upgrade-controller
     spec:
       revision: release-3.3.0
       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. Compruebe que el recurso GitRepo se ha 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.3.0   1/1

4. Compruebe que System Upgrade Controller se ha desplegado:

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

22.2.1.2 Instalación de System Upgrade Controller - Bundle #

 

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

1. En un equipo con acceso de red, descargue fleet-cli:

   

   Nota

   Asegúrese de que la versión de fleet-cli que descargue coincida con la versión de Fleet que se ha desplegado en su clúster.

   • Para usuarios de Mac, hay una versión propia de fleet-cli.

   • Para usuarios de Linux y Windows, los binarios son recursos distintos para cada versión de Fleet.

     • Linux AMD:

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

     • Linux ARM:

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

2. Permita que fleet-cli se pueda ejecutar:

   chmod +x fleet-cli

3. Clone la versión de suse-edge/fleet-examples que desee usar:

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

4. Diríjase a la instancia de Fleet de SUC, situada en el repositorio fleet-examples:

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

5. Determine en qué clústeres desea desplegar SUC. Para ello, despliegue el Bundle de SUC en el espacio de trabajo correcto de Fleet dentro de su clúster de gestión. De forma predeterminada, Fleet tiene dos espacios de trabajo:

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

   • fleet-default: para recursos que deben desplegarse en clústeres descendentes.

     Para obtener más información sobre los espacios de trabajo de Fleet, consulte la documentación original.

6. Si tiene intención de desplegar SUC solo en clústeres descendentes, cree 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 la asignación a clústeres descendentes, consulte Mapping to Downstream Clusters (Asignación a clústeres descendentes).

7. Cree el Bundle:

   

   Nota

   Asegúrese de que no ha descargado fleet-cli en el directorio fleet-examples/fleets/day2/system-upgrade-controller, ya que, si fuera así, se empaquetaría con el Bundle, lo cual no es recomendable.

   • Para desplegar SUC en su clúster de gestión, ejecute:

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

   • Para desplegar SUC en sus clústeres descendentes, ejecute:

     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, consulte la sección Convert a Helm Chart into a Bundle (Conversión de un chart de Helm en un Bundle).

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

8. Transfiera el Bundle system-upgrade-controller-bundle.yaml al equipo del clúster de gestión:

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

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

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

10. En el clúster de gestión, compruebe 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 haya desplegado su Bundle, diríjase al clúster y compruebe que SUC se ha desplegado:

    

    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 de SUC se pueden consultar de las siguientes maneras:

Importante

Los pods desplegados para los planes de SUC se mantienen activos 15 minutos tras una ejecución correcta. Después, son eliminados por el trabajo correspondiente que los creó. Para tener acceso a los registros del pod después de este periodo de tiempo, debe habilitar el registro para su clúster. Para obtener información sobre cómo hacerlo en Rancher, consulte Rancher Integration with Logging Services (Integración de Rancher con servicios de registro).

22.3.2 Supervisión de planes de System Upgrade Controller - Manual #

 

Nota

Los pasos siguientes dan por supuesto que kubectl se ha configurado para conectarse al clúster en el que se han desplegado los planes de SUC.

1. Muestre los planes de SUC desplegados:

   kubectl get plans -n cattle-system

2. Obtenga el pod para el plan de SUC:

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

   

   Nota

   Puede haber pods con los estados Completed (Completado) y Unknown (Desconocido) para un plan de SUC específico. Esto está previsto debido a la naturaleza de algunas de las actualizaciones.

3. Obtenga los registros del pod:

   kubectl logs <pod_name> -n cattle-system

Upgrade Controller es esencial para automatizar las operaciones de "día 2" (que antes eran manuales) necesarias para actualizar los clústeres de gestión desde una versión de SUSE Edge a la siguiente.

Para lograr esta automatización, Upgrade Controller usa herramientas como System Upgrade Controller (Capítulo 22, System Upgrade Controller) y Helm Controller.

Para obtener más detalles sobre cómo funciona Upgrade Controller, consulte la Sección 23.4, “¿Cómo funciona Upgrade Controller?”.

Para ver las limitaciones de Upgrade Controller, consulte la Sección 23.7, “Limitaciones conocidas”.

Para ver las diferencias entre Upgrade Controller y System Upgrade Controller, consulte la Sección 23.2, “Diferencias entre Upgrade Controller y System Upgrade Controller”.

System Upgrade Controller (SUC) (Capítulo 22, System Upgrade Controller) es una herramienta de uso 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 en el caso de las operaciones admitidas, los usuarios tienen que configurar, mantener y desplegar manualmente múltiples planes de SUC, un proceso propenso a errores que puede dar lugar a problemas inesperados.

Esto llevó a la necesidad de una herramienta que automatizara y resumiera la complejidad de gestionar diversas operaciones de "día 2" para la plataforma SUSE Edge. Así, se desarrolló Upgrade Controller, que simplifica el proceso de actualización al introducir un único recurso orientado al usuario que se encarga de la actualización. Los usuarios solo tienen que gestionar este recurso y Upgrade Controller se encarga del resto.

Para actualizar la versión de Edge, Upgrade Controller introduce dos nuevos recursos personalizados de Kubernetes:

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

Con los datos de los componentes de ReleaseManifest, Upgrade Controller actualiza los componentes de la versión de Edge en el orden siguiente:

Nota

Durante el proceso de actualización, Upgrade Controller envía continuamente información sobre la actualización al recurso UpgradePlan creado. Para obtener más información sobre cómo realizar un seguimiento del proceso de actualización, consulte la sección correspondiente (Sección 23.6, “Seguimiento del proceso de actualización”).

23.4.1 Actualización del sistema operativo #

 

Para actualizar el sistema operativo, Upgrade Controller crea planes de SUC (Capítulo 22, System Upgrade Controller) que siguen este formato de nombre:

• Para los planes de SUC relacionados con actualizaciones del SO del nodo de plano de control: control-plane-<nombre-so>-<versión-so>-<sufijo>.

• Para los planes de SUC relacionados con actualizaciones del SO del nodo de trabajador: workers-<nombre-so>-<versión-so>-<sufijo>.

Basándose en estos planes, SUC crea cargas de trabajo en cada nodo del clúster que realizan la actualización real del sistema operativo.

Dependiendo del recurso ReleaseManifest, la actualización del sistema operativo puede incluir:

• Solo actualizaciones de paquetes: para casos en los que la versión del sistema operativo no cambie entre las versiones de Edge.

• Migración completa del sistema operativo: para casos en los que la versión del sistema operativo cambie entre versiones de Edge.

La actualización se ejecuta nodo a nodo, comenzando por los nodos de plano de control. Solo cuando finalice la actualización del nodo de plano de control, se empezarán a actualizar los nodos de trabajador.

Nota

Upgrade Controller configura los planes de SUC del sistema operativo para realizar un drenaje de los nodos del clúster si este tiene más de un nodo del tipo especificado.

En los clústeres en los que hay más de un nodo de plano de control y hay un único nodo de trabajador, el drenaje se realizará solo para los nodos de plano de control, y viceversa.

Para obtener información sobre cómo inhabilitar el drenaje de nodos, consulte la sección sobre UpgradePlan (Sección 23.5.1, “UpgradePlan”).

23.4.2 Actualización de Kubernetes #

 

Para actualizar la distribución de Kubernetes de un clúster, Upgrade Controller crea planes de SUC (Capítulo 22, System Upgrade Controller) con el siguiente formato de nombre:

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

• Para planes de SUC relacionados con actualizaciones de Kubernetes en nodos de trabajador: workers-<versión-k8s>-<sufijo>.

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

La actualización de Kubernetes se realizará nodo a nodo, comenzando por los nodos de plano de control. Solo cuando finalice la actualización de los nodos de plano de control se empezarán a actualizar los nodos de trabajador.

Nota

Upgrade Controller configura los planes de SUC de Kubernetes para realizar un drenaje de los nodos del clúster si este tiene más de un nodo del tipo especificado.

En los clústeres en los que hay más de un nodo de plano de control y hay un único nodo de trabajador, el drenaje se realizará solo para los nodos de plano de control, y viceversa.

Para obtener información sobre cómo inhabilitar el drenaje de nodos, consulte la Sección 23.5.1, “UpgradePlan”.

Extensiones a la API de Kubernetes introducidas por Upgrade Controller.

23.5.2 ReleaseManifest #

 

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

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

Aviso

El recurso ReleaseManifest siempre debe crearlo Upgrade Controller.

No es recomendable crear o editar manualmente los recursos ReleaseManifest. Si un usuario decide hacerlo, será bajo su propia responsabilidad.

Estos son algunos de los componentes que incluye ReleaseManifest:

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

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

• Datos de componentes adicionales: datos del chart de Helm de SUSE (ubicación, versión, nombre, etc.)

Para ver un ejemplo de recurso ReleaseManifest, consulte la documentación original. Tenga en cuenta que se trata solo de un ejemplo, no de un recurso ReleaseManifest válido.

Esta sección sirve como medio para realizar un seguimiento y depurar el proceso de actualización que inicia Upgrade Controller después de que el usuario haya creado un recurso UpgradePlan.