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

41.1 Introducción #

El clúster de gestión es la parte de SUSE Telco Cloud que se emplea para gestionar el aprovisionamiento y el ciclo de vida de las pilas de entorno de ejecución. Desde un punto de vista técnico, el clúster de gestión contiene los componentes siguientes:

SUSE Linux Micro como sistema operativo. Dependiendo del caso práctico, será posible personalizar algunas configuraciones como la red, el almacenamiento, los usuarios y los argumentos del kernel.
RKE2 como clúster de Kubernetes. Dependiendo del caso práctico, se puede configurar para utilizar complementos de CNI específicos, como Multus, Cilium, Calico, etc.
Rancher como plataforma de gestión del ciclo de vida de los clústeres.
Metal³ como componente para gestionar el ciclo de vida de los nodos bare metal.
CAPI como componente para gestionar el ciclo de vida de los clústeres de Kubernetes (clústeres descendentes). El proveedor CAPI de RKE2 se utiliza para gestionar el ciclo de vida de los clústeres RKE2.

Con todos los componentes mencionados, el clúster de gestión puede gestionar el ciclo de vida de los clústeres descendentes usando un enfoque declarativo para gestionar la infraestructura y las aplicaciones.

Nota

Para obtener más información sobre SUSE Linux Micro, consulte: SUSE Linux Micro (Capítulo 9, SUSE Linux Micro)

Para obtener más información sobre RKE2, consulte: RKE2 (Capítulo 16, RKE2)

Para obtener más información sobre Rancher, consulte: Rancher (Capítulo 5, Rancher)

Para obtener más información sobre Metal³, consulte: Metal3 (Capítulo 10, Metal³)

41.2 Pasos para configurar el clúster de gestión #

Los siguientes pasos son necesarios para configurar el clúster de gestión (usando un único nodo):

Estos son los pasos principales para configurar el clúster de gestión usando un enfoque declarativo:

Preparación de imágenes para entornos conectados (Sección 41.3, “Preparación de la imagen para entornos conectados”). El primer paso es preparar los manifiestos y los archivos con todas las configuraciones necesarias para su uso en entornos conectados.
- Estructura de directorios para entornos conectados (Sección 41.3.1, “Estructura del directorio”). Este paso crea una estructura de directorios que Edge Image Builder utilizará para almacenar los archivos de configuración y la propia imagen.
- Archivo de definición del clúster de gestión (Sección 41.3.2, “Archivo de definición del clúster de gestión”). El archivo mgmt-cluster.yaml es el archivo de definición principal del clúster de gestión. Contiene la siguiente información sobre la imagen que se va a crear:
  - Información de la imagen: la información relacionada con la imagen que se creará utilizando la imagen base.
  - Sistema operativo: las configuraciones del sistema operativo que se utilizarán en la imagen.
  - Kubernetes: los charts de Helm y los repositorios, la versión de Kubernetes, la configuración de red y los nodos que se utilizarán en el clúster.
- Carpeta personalizada (Sección 41.3.3, “Carpeta custom”). La carpeta custom contiene los archivos de configuración y los guiones que utilizará Edge Image Builder para desplegar un clúster de gestión totalmente funcional.
  - Archivos: contiene los archivos de configuración que utilizará el clúster de gestión.
  - Guiones: contiene los guiones que utilizará el clúster de gestión.
- Carpeta de Kubernetes (Sección 41.3.4, “Carpeta kubernetes”). La carpeta kubernetes contiene los archivos de configuración que utilizará el clúster de gestión.
  - Manifiestos: contiene los manifiestos que utilizará el clúster de gestión.
  - Helm: contiene los archivos de valores de Helm que utilizará el clúster de gestión.
  - Config: contiene los archivos de configuración que utilizará el clúster de gestión.
- Carpeta de red (Sección 41.3.5, “Carpeta network”). La carpeta network contiene los archivos de configuración de red que utilizarán los nodos del clúster de gestión.
Preparación de imágenes para entornos aislados (Sección 41.4, “Preparación de la imagen para entornos aislados”). El paso consiste en mostrar las diferencias para preparar los manifiestos y los archivos que se utilizarán en un entorno aislado.
- Modificaciones en el archivo de definición (Sección 41.4.1, “Modificaciones del archivo de definición”). El archivo mgmt-cluster.yaml debe modificarse para incluir la sección embeddedArtifactRegistry con el campo images establecido en todas las imágenes de contenedor que se incluirán en la imagen de salida de EIB.
- Modificaciones en la carpeta custom (Sección 41.4.2, “Modificaciones de la carpeta custom”). La carpeta custom debe modificarse para incluir los recursos necesarios para ejecutar el clúster de gestión en un entorno aislado.
  - Guion de registro: el guion custom/scripts/99-register.sh debe eliminarse cuando se utiliza un entorno aislado.
- Modificaciones en la carpeta de valores de Helm (Sección 41.4.3, “Modificaciones de la carpeta de valores de Helm”). La carpeta helm/values debe modificarse para incluir la configuración necesaria para ejecutar el clúster de gestión en un entorno aislado.
Creación de la imagen (Sección 41.5, “Creación de la imagen”). Este paso abarca la creación de la imagen mediante la herramienta Edge Image Builder (tanto para escenarios conectados como en entornos aislados). Compruebe los requisitos previos (Capítulo 11, Edge Image Builder) para ejecutar la herramienta Edge Image Builder en su sistema.
Aprovisionamiento del clúster de gestión (Sección 41.6, “Aprovisionamiento del clúster de gestión”). Este paso abarca el aprovisionamiento del clúster de gestión que usa la imagen creada en el paso anterior (tanto para entornos conectados como aislados). Este paso se puede realizar con un ordenador portátil, un servidor, una máquina virtual o cualquier otro sistema AMD64/Intel 64 con un puerto USB.

Nota

Para obtener más información, consulte la sección sobre Edge Image Builder (Capítulo 11, Edge Image Builder) y la guía de inicio rápido de Edge Image Builder (Capítulo 3, Clústeres independientes con Edge Image Builder).

41.3 Preparación de la imagen para entornos conectados #

Edge Image Builder se utiliza para crear la imagen del clúster de gestión. En este documento se describe la configuración mínima necesaria para configurar el clúster de gestión.

Edge Image Builder se ejecuta dentro de un contenedor, por lo que se requiere un entorno de ejecución de contenedores como Podman o Rancher Desktop. En esta guía, se entiende que Podman está disponible.

Además, como requisito previo para desplegar un clúster de gestión de alta disponibilidad, es necesario reservar tres direcciones IP en la red:

apiVIP para la dirección IP virtual de API (utilizada para acceder al servidor API de Kubernetes).
ingressVIP para la dirección IP virtual de Ingress (utilizada, por ejemplo, por la interfaz de usuario de Rancher).
metal3VIP para la dirección IP virtual de Metal3.

41.3.1 Estructura del directorio #

Al ejecutar EIB, se monta un directorio desde el host, por lo que lo primero que hay que hacer es crear una estructura de directorios que EIB utilizará para almacenar los archivos de configuración y la propia imagen. Este directorio tiene la siguiente estructura:

eib
├── mgmt-cluster.yaml
├── network
│ └── mgmt-cluster-node1.yaml
├── os-files
│ └── var
│   └── lib
│     └── rancher
│       └── rke2
│         └── server
│           └── manifests
│             └── rke2-ingress-config.yaml
├── kubernetes
│ ├── manifests
│ │ ├── neuvector-namespace.yaml
│ │ ├── ingress-l2-adv.yaml
│ │ └── ingress-ippool.yaml
│ ├── helm
│ │ └── values
│ │     ├── rancher.yaml
│ │     ├── neuvector.yaml
│ │     ├── longhorn.yaml
│ │     ├── metal3.yaml
│ │     └── certmanager.yaml
│ └── config
│     └── server.yaml
├── custom
│ ├── scripts
│ │ ├── 99-register.sh
│ │ ├── 99-mgmt-setup.sh
│ │ └── 99-alias.sh
│ └── files
│     ├── rancher.sh
│     ├── mgmt-stack-setup.service
│     ├── metal3.sh
│     └── basic-setup.sh
└── base-images

Nota

La imagen SL-Micro.x86_64-6.1-Base-SelfInstall-GM.install.iso debe descargarse desde el Centro de servicios al cliente de SUSE o desde la página de descargas de SUSE, y debe estar ubicada en la carpeta base-images.

Debe comprobar la suma de comprobación SHA256 de la imagen para asegurarse de que no ha sido manipulada. La suma de comprobación se encuentra en la misma ubicación en la que se descargó la imagen.

Un ejemplo de estructura del directorios se puede encontrar en el repositorio GitHub de SUSE Edge, en la carpeta "telco-examples".

41.3.2 Archivo de definición del clúster de gestión #

El archivo de definición principal del clúster de gestión es mgmt-cluster.yaml. Contiene la siguiente información:

apiVersion: 1.3
image:
  imageType: iso
  arch: x86_64
  baseImage: SL-Micro.x86_64-6.1-Base-SelfInstall-GM.install.iso
  outputImageName: eib-mgmt-cluster-image.iso
operatingSystem:
  isoConfiguration:
    installDevice: /dev/sda
  users:
  - username: root
    encryptedPassword: $ROOT_PASSWORD
  packages:
    packageList:
    - jq
    - open-iscsi
    sccRegistrationCode: $SCC_REGISTRATION_CODE
kubernetes:
  version: v1.33.3+rke2r1
  helm:
    charts:
      - name: cert-manager
        repositoryName: jetstack
        version: 1.18.2
        targetNamespace: cert-manager
        valuesFile: certmanager.yaml
        createNamespace: true
        installationNamespace: kube-system
      - name: longhorn-crd
        version: 107.0.0+up1.9.1
        repositoryName: rancher-charts
        targetNamespace: longhorn-system
        createNamespace: true
        installationNamespace: kube-system
      - name: longhorn
        version: 107.0.0+up1.9.1
        repositoryName: rancher-charts
        targetNamespace: longhorn-system
        createNamespace: true
        installationNamespace: kube-system
        valuesFile: longhorn.yaml
      - name: metal3
        version: 304.0.16+up0.12.6
        repositoryName: suse-edge-charts
        targetNamespace: metal3-system
        createNamespace: true
        installationNamespace: kube-system
        valuesFile: metal3.yaml
      - name: rancher-turtles
        version: 304.0.6+up0.24.0
        repositoryName: suse-edge-charts
        targetNamespace: rancher-turtles-system
        createNamespace: true
        installationNamespace: kube-system
      - name: neuvector-crd
        version: 107.0.0+up2.8.7
        repositoryName: rancher-charts
        targetNamespace: neuvector
        createNamespace: true
        installationNamespace: kube-system
        valuesFile: neuvector.yaml
      - name: neuvector
        version: 107.0.0+up2.8.7
        repositoryName: rancher-charts
        targetNamespace: neuvector
        createNamespace: true
        installationNamespace: kube-system
        valuesFile: neuvector.yaml
      - name: rancher
        version: 2.12.1
        repositoryName: rancher-prime
        targetNamespace: cattle-system
        createNamespace: true
        installationNamespace: kube-system
        valuesFile: rancher.yaml
    repositories:
      - name: jetstack
        url: https://charts.jetstack.io
      - name: rancher-charts
        url: https://charts.rancher.io/
      - name: suse-edge-charts
        url: oci://registry.suse.com/edge/charts
      - name: rancher-prime
        url: https://charts.rancher.com/server-charts/prime
  network:
    apiHost: $API_HOST
    apiVIP: $API_VIP
  nodes:
    - hostname: mgmt-cluster-node1
      initializer: true
      type: server
#   - hostname: mgmt-cluster-node2
#     type: server
#   - hostname: mgmt-cluster-node3
#     type: server

Para explicar los campos y valores del archivo de definición mgmt-cluster.yaml, lo hemos dividido en las siguientes secciones.

Sección de imagen (archivo de definición):

image:
  imageType: iso
  arch: x86_64
  baseImage: SL-Micro.x86_64-6.1-Base-SelfInstall-GM.install.iso
  outputImageName: eib-mgmt-cluster-image.iso

Donde baseImage es la imagen original que descargó del Centro de servicios al cliente de SUSE o de la página de descargas de SUSE. outputImageName es el nombre de la nueva imagen que se utilizará para aprovisionar el clúster de gestión.

Sección de sistema operativo (archivo de definición):

operatingSystem:
  isoConfiguration:
    installDevice: /dev/sda
  users:
  - username: root
    encryptedPassword: $ROOT_PASSWORD
  packages:
    packageList:
    - jq
    sccRegistrationCode: $SCC_REGISTRATION_CODE

Donde installDevice es el dispositivo que se utilizará para instalar el sistema operativo, username y encryptedPassword son las credenciales que se utilizarán para acceder al sistema, packageList es la lista de paquetes que se instalarán (jq es necesario internamente durante el proceso de instalación), y sccRegistrationCode es el código de registro utilizado para obtener los paquetes y las dependencias en el momento de la creación, que se pueden obtener en el Centro de servicios al cliente de SUSE. La contraseña cifrada se puede generar utilizando el comando openssl de la siguiente manera:

openssl passwd -6 MyPassword!123

El resultado es algo similar a esto:

$6$UrXB1sAGs46DOiSq$HSwi9GFJLCorm0J53nF2Sq8YEoyINhHcObHzX2R8h13mswUIsMwzx4eUzn/rRx0QPV4JIb0eWCoNrxGiKH4R31

Sección de Kubernetes (archivo de definición):

kubernetes:
  version: v1.33.3+rke2r1
  helm:
    charts:
      - name: cert-manager
        repositoryName: jetstack
        version: 1.18.2
        targetNamespace: cert-manager
        valuesFile: certmanager.yaml
        createNamespace: true
        installationNamespace: kube-system
      - name: longhorn-crd
        version: 107.0.0+up1.9.1
        repositoryName: rancher-charts
        targetNamespace: longhorn-system
        createNamespace: true
        installationNamespace: kube-system
      - name: longhorn
        version: 107.0.0+up1.9.1
        repositoryName: rancher-charts
        targetNamespace: longhorn-system
        createNamespace: true
        installationNamespace: kube-system
        valuesFile: longhorn.yaml
      - name: metal3
        version: 304.0.16+up0.12.6
        repositoryName: suse-edge-charts
        targetNamespace: metal3-system
        createNamespace: true
        installationNamespace: kube-system
        valuesFile: metal3.yaml
      - name: rancher-turtles
        version: 304.0.6+up0.24.0
        repositoryName: suse-edge-charts
        targetNamespace: rancher-turtles-system
        createNamespace: true
        installationNamespace: kube-system
      - name: neuvector-crd
        version: 107.0.0+up2.8.7
        repositoryName: rancher-charts
        targetNamespace: neuvector
        createNamespace: true
        installationNamespace: kube-system
        valuesFile: neuvector.yaml
      - name: neuvector
        version: 107.0.0+up2.8.7
        repositoryName: rancher-charts
        targetNamespace: neuvector
        createNamespace: true
        installationNamespace: kube-system
        valuesFile: neuvector.yaml
      - name: rancher
        version: 2.12.1
        repositoryName: rancher-prime
        targetNamespace: cattle-system
        createNamespace: true
        installationNamespace: kube-system
        valuesFile: rancher.yaml
    repositories:
      - name: jetstack
        url: https://charts.jetstack.io
      - name: rancher-charts
        url: https://charts.rancher.io/
      - name: suse-edge-charts
        url: oci://registry.suse.com/edge/charts
      - name: rancher-prime
        url: https://charts.rancher.com/server-charts/prime
    network:
      apiHost: $API_HOST
      apiVIP: $API_VIP
    nodes:
    - hostname: mgmt-cluster-node1
      initializer: true
      type: server
#   - hostname: mgmt-cluster-node2
#     type: server
#   - hostname: mgmt-cluster-node3
#     type: server

La sección helm contiene la lista de charts de Helm que se instalarán, los repositorios que se utilizarán y la configuración de la versión de todos ellos.

La sección network contiene la configuración de la red, como apiHost y apiVIP, que utilizará el componente RKE2. apiVIP debe ser una dirección IP que no se use en la red y no debe formar parte del pool DHCP (en caso de que se utilice DHCP). Además, si se usa apiVIP en un clúster de varios nodos, se hace para acceder al servidor de API de Kubernetes. apiHost es la resolución de nombres para apiVIP que utilizará el componente RKE2.

La sección nodes contiene la lista de nodos que se usarán en el clúster. En este ejemplo, se usa un clúster de un solo nodo, pero se puede extender a un clúster de varios nodos añadiendo más nodos a la lista (descomentando las líneas).

Nota

Los nombres de los nodos deben ser únicos en el clúster.
Si lo desea, puede usar el campo initializer para especificar el host de arranque. Si no lo hace, será el primer nodo de la lista.
Si se requiere una configuración de red, los nombres de los nodos deben ser los mismos que los nombres de host definidos en la carpeta network (Sección 41.3.5, “Carpeta network”).

41.3.3 Carpeta custom #

La carpeta custom contiene las siguientes subcarpetas:

...
├── custom
│ ├── scripts
│ │ ├── 99-register.sh
│ │ ├── 99-mgmt-setup.sh
│ │ └── 99-alias.sh
│ └── files
│     ├── rancher.sh
│     ├── mgmt-stack-setup.service
│     ├── metal3.sh
│     └── basic-setup.sh
...

La carpeta custom/files contiene los archivos de configuración que utilizará el clúster de gestión.
La carpeta custom/scripts contiene los guiones que utilizará el clúster de gestión.

La carpeta custom/files contiene los siguientes archivos:

basic-setup.sh: contiene los parámetros de configuración para Metal³, Rancher y MetalLB. Solo debe modificar este archivo si desea cambiar los espacios de nombres que se van a utilizar.

#!/bin/bash
# Pre-requisites. Cluster already running
export KUBECTL="/var/lib/rancher/rke2/bin/kubectl"
export KUBECONFIG="/etc/rancher/rke2/rke2.yaml"

##################
# METAL3 DETAILS #
##################
export METAL3_CHART_TARGETNAMESPACE="metal3-system"

###########
# METALLB #
###########
export METALLBNAMESPACE="metallb-system"

###########
# RANCHER #
###########
export RANCHER_CHART_TARGETNAMESPACE="cattle-system"
export RANCHER_FINALPASSWORD="adminadminadmin"

die(){
  echo ${1} 1>&2
  exit ${2}
}

metal3.sh: contiene la configuración del componente Metal³ que se va a utilizar (no es necesario modificarlo). En futuras versiones, este guion se sustituirá por Rancher Turtles para facilitar su uso.

#!/bin/bash
set -euo pipefail

BASEDIR="$(dirname "$0")"
source ${BASEDIR}/basic-setup.sh

METAL3LOCKNAMESPACE="default"
METAL3LOCKCMNAME="metal3-lock"

trap 'catch $? $LINENO' EXIT

catch() {
  if [ "$1" != "0" ]; then
    echo "Error $1 occurred on $2"
    ${KUBECTL} delete configmap ${METAL3LOCKCMNAME} -n ${METAL3LOCKNAMESPACE}
  fi
}

# Get or create the lock to run all those steps just in a single node
# As the first node is created WAY before the others, this should be enough
# TODO: Investigate if leases is better
if [ $(${KUBECTL} get cm -n ${METAL3LOCKNAMESPACE} ${METAL3LOCKCMNAME} -o name | wc -l) -lt 1 ]; then
  ${KUBECTL} create configmap ${METAL3LOCKCMNAME} -n ${METAL3LOCKNAMESPACE} --from-literal foo=bar
else
  exit 0
fi

# Wait for metal3
while ! ${KUBECTL} wait --for condition=ready -n ${METAL3_CHART_TARGETNAMESPACE} $(${KUBECTL} get pods -n ${METAL3_CHART_TARGETNAMESPACE} -l app.kubernetes.io/name=metal3-ironic -o name) --timeout=10s; do sleep 2 ; done

# Get the ironic IP
IRONICIP=$(${KUBECTL} get cm -n ${METAL3_CHART_TARGETNAMESPACE} ironic -o jsonpath='{.data.IRONIC_IP}')

# If LoadBalancer, use metallb, else it is NodePort
if [ $(${KUBECTL} get svc -n ${METAL3_CHART_TARGETNAMESPACE} metal3-metal3-ironic -o jsonpath='{.spec.type}') == "LoadBalancer" ]; then
  # Wait for metallb
  while ! ${KUBECTL} wait --for condition=ready -n ${METALLBNAMESPACE} $(${KUBECTL} get pods -n ${METALLBNAMESPACE} -l app.kubernetes.io/component=controller -o name) --timeout=10s; do sleep 2 ; done

  # Do not create the ippool if already created
  ${KUBECTL} get ipaddresspool -n ${METALLBNAMESPACE} ironic-ip-pool -o name || cat <<-EOF | ${KUBECTL} apply -f -
  apiVersion: metallb.io/v1beta1
  kind: IPAddressPool
  metadata:
    name: ironic-ip-pool
    namespace: ${METALLBNAMESPACE}
  spec:
    addresses:
    - ${IRONICIP}/32
    serviceAllocation:
      priority: 100
      serviceSelectors:
      - matchExpressions:
        - {key: app.kubernetes.io/name, operator: In, values: [metal3-ironic]}
        EOF

  # Same for L2 Advs
  ${KUBECTL} get L2Advertisement -n ${METALLBNAMESPACE} ironic-ip-pool-l2-adv -o name || cat <<-EOF | ${KUBECTL} apply -f -
  apiVersion: metallb.io/v1beta1
  kind: L2Advertisement
  metadata:
    name: ironic-ip-pool-l2-adv
    namespace: ${METALLBNAMESPACE}
  spec:
    ipAddressPools:
    - ironic-ip-pool
        EOF
fi

# If rancher is deployed
if [ $(${KUBECTL} get pods -n ${RANCHER_CHART_TARGETNAMESPACE} -l app=rancher -o name | wc -l) -ge 1 ]; then
  cat <<-EOF | ${KUBECTL} apply -f -
        apiVersion: management.cattle.io/v3
        kind: Feature
        metadata:
          name: embedded-cluster-api
        spec:
          value: false
        EOF

  # Disable Rancher webhooks for CAPI
  ${KUBECTL} delete --ignore-not-found=true mutatingwebhookconfiguration.admissionregistration.k8s.io mutating-webhook-configuration
  ${KUBECTL} delete --ignore-not-found=true validatingwebhookconfigurations.admissionregistration.k8s.io validating-webhook-configuration
  ${KUBECTL} wait --for=delete namespace/cattle-provisioning-capi-system --timeout=300s
fi

# Clean up the lock cm

${KUBECTL} delete configmap ${METAL3LOCKCMNAME} -n ${METAL3LOCKNAMESPACE}

rancher.sh: contiene la configuración del componente Rancher que se va a utilizar (no es necesario modificarlo).

#!/bin/bash
set -euo pipefail

BASEDIR="$(dirname "$0")"
source ${BASEDIR}/basic-setup.sh

RANCHERLOCKNAMESPACE="default"
RANCHERLOCKCMNAME="rancher-lock"

if [ -z "${RANCHER_FINALPASSWORD}" ]; then
  # If there is no final password, then finish the setup right away
  exit 0
fi

trap 'catch $? $LINENO' EXIT

catch() {
  if [ "$1" != "0" ]; then
    echo "Error $1 occurred on $2"
    ${KUBECTL} delete configmap ${RANCHERLOCKCMNAME} -n ${RANCHERLOCKNAMESPACE}
  fi
}

# Get or create the lock to run all those steps just in a single node
# As the first node is created WAY before the others, this should be enough
# TODO: Investigate if leases is better
if [ $(${KUBECTL} get cm -n ${RANCHERLOCKNAMESPACE} ${RANCHERLOCKCMNAME} -o name | wc -l) -lt 1 ]; then
  ${KUBECTL} create configmap ${RANCHERLOCKCMNAME} -n ${RANCHERLOCKNAMESPACE} --from-literal foo=bar
else
  exit 0
fi

# Wait for rancher to be deployed
while ! ${KUBECTL} wait --for condition=ready -n ${RANCHER_CHART_TARGETNAMESPACE} $(${KUBECTL} get pods -n ${RANCHER_CHART_TARGETNAMESPACE} -l app=rancher -o name) --timeout=10s; do sleep 2 ; done
until ${KUBECTL} get ingress -n ${RANCHER_CHART_TARGETNAMESPACE} rancher > /dev/null 2>&1; do sleep 10; done

RANCHERBOOTSTRAPPASSWORD=$(${KUBECTL} get secret -n ${RANCHER_CHART_TARGETNAMESPACE} bootstrap-secret -o jsonpath='{.data.bootstrapPassword}' | base64 -d)
RANCHERHOSTNAME=$(${KUBECTL} get ingress -n ${RANCHER_CHART_TARGETNAMESPACE} rancher -o jsonpath='{.spec.rules[0].host}')

# Skip the whole process if things have been set already
if [ -z $(${KUBECTL} get settings.management.cattle.io first-login -ojsonpath='{.value}') ]; then
  # Add the protocol
  RANCHERHOSTNAME="https://${RANCHERHOSTNAME}"
  TOKEN=""
  while [ -z "${TOKEN}" ]; do
    # Get token
    sleep 2
    TOKEN=$(curl -sk -X POST ${RANCHERHOSTNAME}/v3-public/localProviders/local?action=login -H 'content-type: application/json' -d "{\"username\":\"admin\",\"password\":\"${RANCHERBOOTSTRAPPASSWORD}\"}" | jq -r .token)
  done

  # Set password
  curl -sk ${RANCHERHOSTNAME}/v3/users?action=changepassword -H 'content-type: application/json' -H "Authorization: Bearer $TOKEN" -d "{\"currentPassword\":\"${RANCHERBOOTSTRAPPASSWORD}\",\"newPassword\":\"${RANCHER_FINALPASSWORD}\"}"

  # Create a temporary API token (ttl=60 minutes)
  APITOKEN=$(curl -sk ${RANCHERHOSTNAME}/v3/token -H 'content-type: application/json' -H "Authorization: Bearer ${TOKEN}" -d '{"type":"token","description":"automation","ttl":3600000}' | jq -r .token)

  curl -sk ${RANCHERHOSTNAME}/v3/settings/server-url -H 'content-type: application/json' -H "Authorization: Bearer ${APITOKEN}" -X PUT -d "{\"name\":\"server-url\",\"value\":\"${RANCHERHOSTNAME}\"}"
  curl -sk ${RANCHERHOSTNAME}/v3/settings/telemetry-opt -X PUT -H 'content-type: application/json' -H 'accept: application/json' -H "Authorization: Bearer ${APITOKEN}" -d '{"value":"out"}'
fi

# Clean up the lock cm
${KUBECTL} delete configmap ${RANCHERLOCKCMNAME} -n ${RANCHERLOCKNAMESPACE}

mgmt-stack-setup.service: contiene la configuración para crear el servicio systemd que ejecutará los guiones durante el primer arranque (no es necesario modificarlo).

[Unit]
Description=Setup Management stack components
Wants=network-online.target
# It requires rke2 or k3s running, but it will not fail if those services are not present
After=network.target network-online.target rke2-server.service k3s.service
# At least, the basic-setup.sh one needs to be present
ConditionPathExists=/opt/mgmt/bin/basic-setup.sh

[Service]
User=root
Type=forking
# Metal3 can take A LOT to download the IPA image
TimeoutStartSec=1800

ExecStartPre=/bin/sh -c "echo 'Setting up Management components...'"
# Scripts are executed in StartPre because Start can only run a single one
ExecStartPre=/opt/mgmt/bin/rancher.sh
ExecStartPre=/opt/mgmt/bin/metal3.sh
ExecStart=/bin/sh -c "echo 'Finished setting up Management components'"
RemainAfterExit=yes
KillMode=process
# Disable & delete everything
ExecStartPost=rm -f /opt/mgmt/bin/rancher.sh
ExecStartPost=rm -f /opt/mgmt/bin/metal3.sh
ExecStartPost=rm -f /opt/mgmt/bin/basic-setup.sh
ExecStartPost=/bin/sh -c "systemctl disable mgmt-stack-setup.service"
ExecStartPost=rm -f /etc/systemd/system/mgmt-stack-setup.service

[Install]
WantedBy=multi-user.target

La carpeta custom/scripts contiene los siguientes archivos:

Guion 99-alias.sh: contiene el alias que usará el clúster de gestión para cargar el archivo kubeconfig en el primer arranque (no es necesario modificarlo).

#!/bin/bash
echo "alias k=kubectl" >> /etc/profile.local
echo "alias kubectl=/var/lib/rancher/rke2/bin/kubectl" >> /etc/profile.local
echo "export KUBECONFIG=/etc/rancher/rke2/rke2.yaml" >> /etc/profile.local

Guion 99-mgmt-setup.sh: contiene la configuración para copiar los guiones durante el primer arranque (no es necesario modificarlo).

#!/bin/bash

# Copy the scripts from combustion to the final location
mkdir -p /opt/mgmt/bin/
for script in basic-setup.sh rancher.sh metal3.sh; do
        cp ${script} /opt/mgmt/bin/
done

# Copy the systemd unit file and enable it at boot
cp mgmt-stack-setup.service /etc/systemd/system/mgmt-stack-setup.service
systemctl enable mgmt-stack-setup.service

Guion 99-register.sh: contiene la configuración para registrar el sistema usando el código de registro del Centro de servicios al cliente de SUSE. Los elementos ${SCC_ACCOUNT_EMAIL} y ${SCC_REGISTRATION_CODE} deben configurarse correctamente para registrar el sistema con su cuenta.

#!/bin/bash
set -euo pipefail

# Registration https://www.suse.com/support/kb/doc/?id=000018564
if ! which SUSEConnect > /dev/null 2>&1; then
        zypper --non-interactive install suseconnect-ng
fi
SUSEConnect --email "${SCC_ACCOUNT_EMAIL}" --url "https://scc.suse.com" --regcode "${SCC_REGISTRATION_CODE}"

41.3.4 Carpeta kubernetes #

La carpeta kubernetes contiene las siguientes subcarpetas:

...
├── kubernetes
│ ├── manifests
│ │ ├── rke2-ingress-config.yaml
│ │ ├── neuvector-namespace.yaml
│ │ ├── ingress-l2-adv.yaml
│ │ └── ingress-ippool.yaml
│ ├── helm
│ │ └── values
│ │     ├── rancher.yaml
│ │     ├── neuvector.yaml
│ │     ├── metal3.yaml
│ │     └── certmanager.yaml
│ └── config
│     └── server.yaml
...

La carpeta kubernetes/config contiene los siguientes archivos:

server.yaml: de forma predeterminada, el complemento de CNI instalado por defecto es Cilium, por lo que no es necesario crear esta carpeta ni este archivo. En caso de que necesite personalizar el complemento de CNI, puede usar el archivo server.yaml que se encuentra en la carpeta kubernetes/config. Contiene la siguiente información:
```
cni:
- multus
- cilium
write-kubeconfig-mode: '0644'
selinux: true
system-default-registry: registry.rancher.com
```

Nota

Se trata de un archivo opcional para definir ciertas personalizaciones de Kubernetes, como los complementos de CNI que se utilizarán o muchas opciones que puede consultar en la documentación oficial.

La carpeta os-files/var/lib/rancher/rke2/server/manifests contiene el archivo siguiente:

rke2-ingress-config.yaml: contiene la configuración para crear el servicio Ingress para el clúster de gestión (no es necesario modificarlo).

apiVersion: helm.cattle.io/v1
kind: HelmChartConfig
metadata:
  name: rke2-ingress-nginx
  namespace: kube-system
spec:
  valuesContent: |-
    controller:
      config:
        use-forwarded-headers: "true"
        enable-real-ip: "true"
      publishService:
        enabled: true
      service:
        enabled: true
        type: LoadBalancer
        externalTrafficPolicy: Local

Nota

Se debe incluir HelmChartConfig mediante os-files en el directorio /var/lib/rancher/rke2/server/manifests, no mediante kubernetes/manifests como se describe en las versiones anteriores.

La carpeta kubernetes/manifests contiene los siguientes archivos:

neuvector-namespace.yaml: contiene la configuración para crear el espacio de nombres NeuVector (no es necesario modificarlo).
```
apiVersion: v1
kind: Namespace
metadata:
  labels:
    pod-security.kubernetes.io/enforce: privileged
  name: neuvector
```

ingress-l2-adv.yaml: contiene la configuración para crear el L2Advertisement para el componente MetalLB (no es necesario modificarlo).

apiVersion: metallb.io/v1beta1
kind: L2Advertisement
metadata:
  name: ingress-l2-adv
  namespace: metallb-system
spec:
  ipAddressPools:
    - ingress-ippool

ingress-ippool.yaml: contiene la configuración para crear el IPAddressPool para el componente rke2-ingress-nginx. ${INGRESS_VIP} debe configurarse correctamente para definir la dirección IP reservada para usarse por el componente rke2-ingress-nginx.

apiVersion: metallb.io/v1beta1
kind: IPAddressPool
metadata:
  name: ingress-ippool
  namespace: metallb-system
spec:
  addresses:
    - ${INGRESS_VIP}/32
  serviceAllocation:
    priority: 100
    serviceSelectors:
      - matchExpressions:
          - {key: app.kubernetes.io/name, operator: In, values: [rke2-ingress-nginx]}

La carpeta kubernetes/helm/values contiene los siguientes archivos:

rancher.yaml: contiene la configuración para crear el componente Rancher. ${INGRESS_VIP} debe configurarse correctamente para definir la dirección IP que utilizará el componente Rancher. La URL para acceder al componente Rancher será https://rancher-${INGRESS_VIP}.sslip.io.
```
hostname: rancher-${INGRESS_VIP}.sslip.io
bootstrapPassword: "foobar"
replicas: 1
global:
  cattle:
    systemDefaultRegistry: "registry.rancher.com"
```

neuvector.yaml: contiene la configuración para crear el componente NeuVector (no es necesario modificarlo).

controller:
  replicas: 1
  ranchersso:
    enabled: true
manager:
  enabled: false
cve:
  scanner:
    enabled: false
    replicas: 1
k3s:
  enabled: true
crdwebhook:
  enabled: false
registry: "registry.rancher.com"
global:
  cattle:
    systemDefaultRegistry: "registry.rancher.com"

longhorn.yaml: contiene la configuración para crear el componente Longhorn (no se necesitan modificaciones).
```
global:
  cattle:
    systemDefaultRegistry: "registry.rancher.com"
```

metal3.yaml: contiene la configuración para crear el componente Metal³. ${METAL3_VIP} debe configurarse correctamente para definir la dirección IP que utilizará el componente Metal³.

global:
  ironicIP: ${METAL3_VIP}
  enable_vmedia_tls: false
  additionalTrustedCAs: false
metal3-ironic:
  global:
    predictableNicNames: "true"
  persistence:
    ironic:
      size: "5Gi"

Nota

El servidor de medios es una función opcional incluida en Metal³ (inhabilitada de forma predeterminada). Para utilizar esta función de Metal3, es necesario configurarla en el manifiesto anterior. Para utilizar el servidor de medios de Metal³, especifique la siguiente variable:

Defina enable_metal3_media_server como true para habilitar la función de servidor de medios en la sección global.
Incluya la siguiente configuración sobre el servidor de medios, donde ${MEDIA_VOLUME_PATH} es la ruta al volumen de medios en el medio (por ejemplo, /home/metal3/bmh-image-cache).
```
metal3-media:
  mediaVolume:
    hostPath: ${MEDIA_VOLUME_PATH}
```

Se puede utilizar un servidor de medios externo para almacenar las imágenes y, en caso de que desee usarlo con TLS, deberá modificar las siguientes configuraciones:

Defina true en additionalTrustedCAs en el archivo metal3.yaml anterior para habilitar las CA de confianza adicionales del servidor de medios externo.

Incluya la siguiente configuración de secreto en la carpeta kubernetes/manifests/metal3-cacert-secret.yaml para almacenar el certificado de CA del servidor de medios externo.

apiVersion: v1
kind: Namespace
metadata:
  name: metal3-system
---
apiVersion: v1
kind: Secret
metadata:
  name: tls-ca-additional
  namespace: metal3-system
type: Opaque
data:
  ca-additional.crt: {{ additional_ca_cert | b64encode }}

additional_ca_cert es el certificado de CA cifrado en base64 del servidor de medios externo. Puede usar el siguiente comando para cifrar el certificado y generar el secreto manualmente:

kubectl -n meta3-system create secret generic tls-ca-additional --from-file=ca-additional.crt=./ca-additional.crt

certmanager.yaml: contiene la configuración para crear el componente Cert-Manager (no es necesario modificarlo).
```
installCRDs: true
```

41.3.5 Carpeta network #

La carpeta network contiene tantos archivos como nodos haya en el clúster de gestión. En nuestro caso, solo tenemos un nodo, por lo que solo tenemos un archivo llamado mgmt-cluster-node1.yaml. El nombre del archivo debe coincidir con el nombre de host definido en el archivo de definición mgmt-cluster.yaml en la sección network/node descrita anteriormente.

Si necesita personalizar la configuración de red, por ejemplo, para utilizar una dirección IP estática específica (si no se usa DHCP), puede utilizar el archivo mgmt-cluster-node1.yaml que se encuentra en la carpeta network. Contiene la siguiente información:

${MGMT_GATEWAY}: la dirección IP del gateway.
${MGMT_DNS}: la dirección IP del servidor DNS.
${MGMT_MAC}: la dirección MAC de la interfaz de red.
${MGMT_NODE_IP}: la dirección IP del clúster de gestión.

routes:
  config:
  - destination: 0.0.0.0/0
    metric: 100
    next-hop-address: ${MGMT_GATEWAY}
    next-hop-interface: eth0
    table-id: 254
dns-resolver:
  config:
    server:
    - ${MGMT_DNS}
    - 8.8.8.8
interfaces:
- name: eth0
  type: ethernet
  state: up
  mac-address: ${MGMT_MAC}
  ipv4:
    address:
    - ip: ${MGMT_NODE_IP}
      prefix-length: 24
    dhcp: false
    enabled: true
  ipv6:
    enabled: false

Si desea utilizar DHCP para obtener la dirección IP, puede usar la siguiente configuración (la dirección MAC debe configurarse correctamente utilizando la variable ${MGMT_MAC}):

## This is an example of a dhcp network configuration for a management cluster
interfaces:
- name: eth0
  type: ethernet
  state: up
  mac-address: ${MGMT_MAC}
  ipv4:
    dhcp: true
    enabled: true
  ipv6:
    enabled: false

Nota

Dependiendo del número de nodos del clúster de gestión, puede crear más archivos como mgmt-cluster-node2.yaml, mgmt-cluster-node3.yaml, etc. para configurar el resto de los nodos.
La sección routes se utiliza para definir la tabla de enrutamiento del clúster de gestión.

41.4 Preparación de la imagen para entornos aislados #

En esta sección se describe cómo preparar la imagen para entornos aislados. Muestra solo las diferencias con respecto a las secciones anteriores. Para preparar la imagen para entornos aislados, es necesario realizar los siguientes cambios con respecto a la sección sobre la preparación de imagen en entornos conectados (Sección 41.3, “Preparación de la imagen para entornos conectados”):

El archivo mgmt-cluster.yaml debe modificarse para incluir la sección embeddedArtifactRegistry con el campo images definido con todas las imágenes de contenedor que se incluirán en la imagen de salida de EIB.
El archivo mgmt-cluster.yaml debe modificarse para incluir el chart de Helm rancher-turtles-airgap-resources.
El guion custom/scripts/99-register.sh debe eliminarse si se utiliza un entorno aislado.

41.4.1 Modificaciones del archivo de definición #

El archivo mgmt-cluster.yaml debe modificarse para incluir la sección embeddedArtifactRegistry. En ella, el campo images debe contener la lista de todas las imágenes de contenedor que se incluirán en la imagen de salida.

Nota

A continuación, se muestra un ejemplo del archivo mgmt-cluster.yaml con la sección embeddedArtifactRegistry incluida. Asegúrese de que las imágenes indicadas contengan las versiones de los componentes que necesita.

También se debe añadir el chart de Helm rancher-turtles-airgap-resources, que crea los recursos descritos en la documentación de Rancher Turtles para entornos aislados. Esto también requiere un archivo de valores turtles.yaml para que el chart de rancher-turtles especifique la configuración necesaria.

apiVersion: 1.3
image:
  imageType: iso
  arch: x86_64
  baseImage: SL-Micro.x86_64-6.1-Base-SelfInstall-GM.install.iso
  outputImageName: eib-mgmt-cluster-image.iso
operatingSystem:
  isoConfiguration:
    installDevice: /dev/sda
  users:
  - username: root
    encryptedPassword: $ROOT_PASSWORD
  packages:
    packageList:
    - jq
    sccRegistrationCode: $SCC_REGISTRATION_CODE
kubernetes:
  version: v1.33.3+rke2r1
  helm:
    charts:
      - name: cert-manager
        repositoryName: jetstack
        version: 1.18.2
        targetNamespace: cert-manager
        valuesFile: certmanager.yaml
        createNamespace: true
        installationNamespace: kube-system
      - name: longhorn-crd
        version: 107.0.0+up1.9.1
        repositoryName: rancher-charts
        targetNamespace: longhorn-system
        createNamespace: true
        installationNamespace: kube-system
      - name: longhorn
        version: 107.0.0+up1.9.1
        repositoryName: rancher-charts
        targetNamespace: longhorn-system
        createNamespace: true
        installationNamespace: kube-system
        valuesFile: longhorn.yaml
      - name: metal3
        version: 304.0.16+up0.12.6
        repositoryName: suse-edge-charts
        targetNamespace: metal3-system
        createNamespace: true
        installationNamespace: kube-system
        valuesFile: metal3.yaml
      - name: rancher-turtles
        version: 304.0.6+up0.24.0
        repositoryName: suse-edge-charts
        targetNamespace: rancher-turtles-system
        createNamespace: true
        installationNamespace: kube-system
        valuesFile: turtles.yaml
      - name: rancher-turtles-airgap-resources
        version: 304.0.6+up0.24.0
        repositoryName: suse-edge-charts
        targetNamespace: rancher-turtles-system
        createNamespace: true
        installationNamespace: kube-system
      - name: neuvector-crd
        version: 107.0.0+up2.8.7
        repositoryName: rancher-charts
        targetNamespace: neuvector
        createNamespace: true
        installationNamespace: kube-system
        valuesFile: neuvector.yaml
      - name: neuvector
        version: 107.0.0+up2.8.7
        repositoryName: rancher-charts
        targetNamespace: neuvector
        createNamespace: true
        installationNamespace: kube-system
        valuesFile: neuvector.yaml
      - name: rancher
        version: 2.12.1
        repositoryName: rancher-prime
        targetNamespace: cattle-system
        createNamespace: true
        installationNamespace: kube-system
        valuesFile: rancher.yaml
    repositories:
      - name: jetstack
        url: https://charts.jetstack.io
      - name: rancher-charts
        url: https://charts.rancher.io/
      - name: suse-edge-charts
        url: oci://registry.suse.com/edge/charts
      - name: rancher-prime
        url: https://charts.rancher.com/server-charts/prime
    network:
      apiHost: $API_HOST
      apiVIP: $API_VIP
    nodes:
    - hostname: mgmt-cluster-node1
      initializer: true
      type: server
#   - hostname: mgmt-cluster-node2
#     type: server
#   - hostname: mgmt-cluster-node3
#     type: server
#       type: server
embeddedArtifactRegistry:
  images:
    - name: registry.rancher.com/rancher/hardened-cluster-autoscaler:v1.10.2-build20250611
    - name: registry.rancher.com/rancher/hardened-cni-plugins:v1.7.1-build20250611
    - name: registry.rancher.com/rancher/hardened-coredns:v1.12.2-build20250611
    - name: registry.rancher.com/rancher/hardened-k8s-metrics-server:v0.8.0-build20250704
    - name: registry.rancher.com/rancher/hardened-multus-cni:v4.2.1-build20250627
    - name: registry.rancher.com/rancher/klipper-helm:v0.9.8-build20250709
    - name: registry.rancher.com/rancher/mirrored-cilium-cilium:v1.17.6
    - name: registry.rancher.com/rancher/mirrored-cilium-operator-generic:v1.17.6
    - name: registry.rancher.com/rancher/mirrored-longhornio-csi-attacher:v4.9.0-20250709
    - name: registry.rancher.com/rancher/mirrored-longhornio-csi-node-driver-registrar:v2.14.0-20250709
    - name: registry.rancher.com/rancher/mirrored-longhornio-csi-provisioner:v5.3.0-20250709
    - name: registry.rancher.com/rancher/mirrored-longhornio-csi-resizer:v1.14.0-20250709
    - name: registry.rancher.com/rancher/mirrored-longhornio-csi-snapshotter:v8.3.0-20250709
    - name: registry.rancher.com/rancher/mirrored-longhornio-livenessprobe:v2.16.0-20250709
    - name: registry.rancher.com/rancher/mirrored-longhornio-longhorn-engine:v1.9.1
    - name: registry.rancher.com/rancher/mirrored-longhornio-longhorn-instance-manager:v1.9.1
    - name: registry.rancher.com/rancher/mirrored-longhornio-longhorn-manager:v1.9.1
    - name: registry.rancher.com/rancher/mirrored-longhornio-longhorn-share-manager:v1.9.1
    - name: registry.rancher.com/rancher/mirrored-longhornio-longhorn-ui:v1.9.1
    - name: registry.rancher.com/rancher/mirrored-sig-storage-snapshot-controller:v8.2.0
    - name: registry.rancher.com/rancher/neuvector-compliance-config:1.0.6
    - name: registry.rancher.com/rancher/neuvector-controller:5.4.5
    - name: registry.rancher.com/rancher/neuvector-enforcer:5.4.5
    - name: registry.rancher.com/rancher/nginx-ingress-controller:v1.12.4-hardened2
    - name: registry.suse.com/rancher/cluster-api-addon-provider-fleet:v0.11.0
    - name: registry.rancher.com/rancher/cluster-api-operator:v0.18.1
    - name: registry.rancher.com/rancher/fleet-agent:v0.13.1
    - name: registry.rancher.com/rancher/fleet:v0.13.1
    - name: registry.rancher.com/rancher/hardened-node-feature-discovery:v0.15.7-build20250425
    - name: registry.rancher.com/rancher/rancher-webhook:v0.8.1
    - name: registry.rancher.com/rancher/rancher/turtles:v0.24.0
    - name: registry.rancher.com/rancher/rancher:v2.12.1
    - name: registry.rancher.com/rancher/shell:v0.4.1
    - name: registry.rancher.com/rancher/system-upgrade-controller:v0.16.0
    - name: registry.suse.com/rancher/cluster-api-controller:v1.10.5
    - name: registry.suse.com/rancher/cluster-api-provider-metal3:v1.10.2
    - name: registry.suse.com/rancher/cluster-api-provider-rke2-bootstrap:v0.20.1
    - name: registry.suse.com/rancher/cluster-api-provider-rke2-controlplane:v0.20.1
    - name: registry.suse.com/rancher/hardened-sriov-network-operator:v1.5.0-build20250425
    - name: registry.suse.com/rancher/ip-address-manager:v1.10.2
    - name: registry.rancher.com/rancher/kubectl:v1.32.2
    - name: registry.rancher.com/rancher/mirrored-cluster-api-controller:v1.9.5

41.4.2 Modificaciones de la carpeta custom #

El guion custom/scripts/99-register.sh debe eliminarse si se utiliza un entorno aislado. Como se puede ver en la estructura del directorio, el guion 99-register.sh no está incluido en la carpeta custom/scripts.

41.4.3 Modificaciones de la carpeta de valores de Helm #

El archivo turtles.yaml contiene la configuración necesaria para especificar el funcionamiento con aislamiento para Rancher Turtles. Tenga en cuenta que esto depende de la instalación del chart de rancher-turtles-airgap-resources.

cluster-api-operator:
  cluster-api:
    core:
      fetchConfig:
        selector: "{\"matchLabels\": {\"provider-components\": \"core\"}}"
    rke2:
      bootstrap:
        fetchConfig:
          selector: "{\"matchLabels\": {\"provider-components\": \"rke2-bootstrap\"}}"
      controlPlane:
        fetchConfig:
          selector: "{\"matchLabels\": {\"provider-components\": \"rke2-control-plane\"}}"
    metal3:
      infrastructure:
        fetchConfig:
          selector: "{\"matchLabels\": {\"provider-components\": \"metal3\"}}"

41.5 Creación de la imagen #

Una vez preparada la estructura de directorios siguiendo las secciones anteriores (tanto para escenarios conectados como aislados), ejecute el comando siguiente para crear la imagen:

podman run --rm --privileged -it -v $PWD:/eib \
 registry.suse.com/edge/3.4/edge-image-builder:1.3.0 \
 build --definition-file mgmt-cluster.yaml

Esto crea el archivo de imagen ISO de salida que, en nuestro caso, según la definición de imagen descrita anteriormente, es eib-mgmt-cluster-image.iso.

41.6 Aprovisionamiento del clúster de gestión #

La imagen anterior contiene todos los componentes explicados anteriormente y se puede utilizar para aprovisionar el clúster de gestión mediante una máquina virtual o un servidor bare metal (usando la función de medios virtuales).

41.7 Asuntos a tener en cuenta y configuración de la doble pila #

Los ejemplos mostrados en las secciones anteriores proporcionan orientación y ejemplos sobre cómo configurar un clúster de gestión IPv4 de pila única. Dicho clúster de gestión es independiente del estado operativo de los clústeres descendentes, que pueden configurarse individualmente para funcionar en una configuración IPv4/IPv6 de pila única o de pila doble una vez implementados. Sin embargo, la forma en que se configura el clúster de gestión tiene un impacto directo en los protocolos de comunicación que se pueden usar durante la fase de aprovisionamiento, en la que las comunicaciones en banda y fuera de banda deben realizarse de acuerdo con los protocolos compatibles con el clúster de gestión y el host descendente. En caso de que se prevea que algunos o todos los BMC o los nodos de clúster descendentes utilicen IPv6, se requiere una configuración de doble pila para el clúster de gestión.

Nota

Aún no se admiten clústeres de gestión IPv6 de un pila única.

Para lograr la funcionalidad de doble pila, Kubernetes debe contar con CIDR IPv4 e IPv6 para POD y servicios. Sin embargo, otros componentes también requieren un ajuste específico antes de crear la imagen del clúster de gestión con EIB. Los servicios de aprovisionamiento de Metal³ (Ironic) se pueden configurar de diferentes maneras, dependiendo de su infraestructura o requisitos:

Los servicios de Ironic se pueden configurar para escuchar en todas las interfaces del sistema en lugar de en una única dirección IP, por lo que, siempre que los hosts del clúster de gestión tengan asignadas direcciones IPv4 e IPv6 a la interfaz correspondiente, cualquiera de ellas podrá utilizarse durante el aprovisionamiento. Tenga en cuenta que, en este momento, solo se puede seleccionar una de estas direcciones para la generación de la URL (para su uso por otros servicios, como el operador bare metal, BMC, etc.); por lo tanto, para habilitar las comunicaciones IPv6 con los BMC, se puede indicar al operador bare metal que exponga y transmita una URL IPv6 al tratar definiciones BMH que incluyan una dirección IPv6. En otras palabras, cuando se identifica que un BMC es compatible con IPv6, el aprovisionamiento se realizará únicamente a través de IPv6, y a través de IPv4 en todos los demás casos.
Metal³ puede utilizar un único nombre de host, que se resuelve tanto en IPv4 como en IPv6, para permitir que Ironic utilice esas direcciones para la vinculación y la creación de URL. Este enfoque permite una configuración sencilla y un comportamiento flexible (tanto IPv4 como IPv6 siguen siendo viables en cada paso del aprovisionamiento), pero requiere una infraestructura con servidores DNS preexistentes, asignaciones de IP y registros ya establecidos.

En ambos casos, Kubernetes necesitará saber qué CIDR utilizar tanto para IPv4 como para IPv6, por lo que puede añadir las siguientes líneas a su archivo kubernetes/config/server.yaml en el directorio EIB, asegurándose de añadir primero IPv4:

service-cidr: 10.96.0.0/12,fd12:4567:789c::/112
cluster-cidr: 193.168.0.0/18,fd12:4567:789b::/48

Algunos contenedores aprovechan la red del host, por lo que debe modificar la configuración de red de los hosts, en el directorio network, para habilitar la conectividad IPv6:

routes:
  config:
  - destination: 0.0.0.0/0
    next-hop-address: ${MGMT_GATEWAY_V4}
    next-hop-interface: eth0
  - destination: ::/0
    next-hop-address: ${MGMT_GATEWAY_V6}
    next-hop-interface: eth0
dns-resolver:
  config:
    server:
    - ${MGMT_DNS}
    - 8.8.8.8
    - 2001:4860:4860::8888
interfaces:
- name: eth0
  type: ethernet
  state: up
  mac-address: ${MGMT_MAC}
  ipv4:
    address:
    - ip: ${MGMT_CLUSTER_IP_V4}
      prefix-length: 24
    dhcp: false
    enabled: true
  ipv6:
    address:
    - ip: ${MGMT_CLUSTER_IP_V6}
      prefix-length: 128
    dhcp: false
    autoconf: false
    enabled: true

Sustituya los marcadores de posición por las direcciones IP del gateway, el servidor DNS adicional (si fuera necesario), la dirección MAC de la interfaz de red y la dirección IP del clúster de gestión. Si prefiere la configuración automática de direcciones, consulte el siguiente apartado y establezca la variable ${MGMT_MAC}:

interfaces:
- name: eth0
  type: ethernet
  state: up
  mac-address: ${MGMT_MAC}
  ipv4:
    enabled: true
    dhcp: true
  ipv6:
    enabled: false
    dhcp: true
    autoconf: true

Ahora se pueden definir los archivos restantes para una configuración de un solo nodo, comenzando por la primera opción, creando kubernetes/helm/values/metal3.yaml como:

global:
  ironicIP: ${MGMT_CLUSTER_IP_V4}
  enable_vmedia_tls: false
  additionalTrustedCAs: false
metal3-ironic:
  global:
    predictableNicNames: true
  listenOnAll: true
  persistence:
    ironic:
      size: "5Gi"
  service:
    type: NodePort
metal3-baremetal-operator:
  baremetaloperator:
    externalHttpIPv6: ${MGMT_CLUSTER_IP_V6}

y kubernetes/helm/values/rancher.yaml como:

hostname: rancher-${MGMT_CLUSTER_IP_V4}.sslip.io
bootstrapPassword: "foobar"
replicas: 1
global:
  cattle:
    systemDefaultRegistry: "registry.rancher.com"

donde ${MGMT_CLUSTER_IP_V4} y ${MGMT_CLUSTER_IP_V6} son las direcciones IP asignadas anteriormente al host.

Como alternativa, para usar el nombre del host en lugar de las direcciones IP, modifique kubernetes/helm/values/metal3.yaml a:

global:
  provisioningHostname: `${MGMT_CLUSTER_HOSTNAME}`
  enable_vmedia_tls: false
  additionalTrustedCAs: false
metal3-ironic:
  global:
    predictableNicNames: true
  persistence:
    ironic:
      size: "5Gi"
  service:
    type: NodePort

y kubernetes/helm/values/rancher.yaml a:

hostname: rancher-${MGMT_CLUSTER_HOSTNAME}.sslip.io
bootstrapPassword: "foobar"
replicas: 1
global:
  cattle:
    systemDefaultRegistry: "registry.rancher.com"

donde ${MGMT_CLUSTER_HOSTNAME} debe ser un nombre de dominio completo que se resuelva en las direcciones IP de su host.

Para obtener más información, consulte repositorio GitHub de SUSE Edge, en la carpeta "dual-stack", donde encontrará un ejemplo de estructura de directorios.