Applies to SUSE Telco Cloud 3.6

51 Aprovisionamiento de clústeres en sentido descendente con aprovisionamiento de red dirigida (nodo único) #

Esta sección describe el flujo de trabajo utilizado para automatizar el aprovisionamiento de un clúster en sentido descendente de nodo único mediante el aprovisionamiento de red dirigida. Esta es la forma más sencilla de automatizar el aprovisionamiento de un clúster en sentido descendente.

Requisitos

La imagen generada mediante EIB, tal como se describe en la sección anterior (Chapter 49, Preparar la imagen del clúster descendente para escenarios conectados), con la configuración mínima para el clúster en sentido descendente debe estar ubicada en el clúster de gestión exactamente en la vía que configuró en esta sección (Note).
El servidor de gestión creado y disponible para ser utilizado en las siguientes secciones. Para obtener más información, consulte la sección del Clúster de gestión Part V, “Configuración del clúster de gestión”.

Flujo de trabajo

El siguiente diagrama muestra el flujo de trabajo utilizado para automatizar el aprovisionamiento de un clúster descendente de nodo único mediante aprovisionamiento de red dirigido:

Existen dos pasos diferentes para automatizar el aprovisionamiento de un clúster descendente de nodo único mediante aprovisionamiento de red dirigido:

Inscriba el host de equipo sin sistema operativo para que esté disponible para el proceso de aprovisionamiento.
Aprovisione el host de equipo sin sistema operativo para instalar y configurar el sistema operativo y el clúster de Kubernetes.

Inscribir el host de equipo sin sistema operativo

El primer paso es inscribir el nuevo host de equipo sin sistema operativo en el clúster de gestión para que esté disponible para ser aprovisionado. Para ello, se debe crear el siguiente archivo (bmh-example.yaml) en el clúster de gestión, para especificar las credenciales BMC que se utilizarán y el objeto BaremetalHost que se va a inscribir:

apiVersion: v1
kind: Secret
metadata:
  name: example-demo-credentials
type: Opaque
data:
  username: ${BMC_USERNAME}
  password: ${BMC_PASSWORD}
---
apiVersion: metal3.io/v1alpha1
kind: BareMetalHost
metadata:
  name: example-demo
  labels:
    cluster-role: control-plane
spec:
  architecture: x86_64
  online: true
  bootMACAddress: ${BMC_MAC}
  rootDeviceHints:
    deviceName: /dev/nvme0n1
  bmc:
    address: ${BMC_ADDRESS}
    disableCertificateVerification: true
    credentialsName: example-demo-credentials

Donde:

${BMC_USERNAME} — El nombre de usuario para el BMC del nuevo host de equipo sin sistema operativo.
${BMC_PASSWORD} — La contraseña para el BMC del nuevo host de equipo sin sistema operativo.
${BMC_MAC} — La dirección MAC del nuevo host de equipo sin sistema operativo que se va a utilizar.
${BMC_ADDRESS} — El URL para el host de equipo sin sistema operativo BMC (por ejemplo, redfish-virtualmedia://192.168.200.75/redfish/v1/Systems/1/). Para obtener más información sobre las diferentes opciones disponibles según su proveedor de hardware, consulte el siguiente enlace.

Note

La arquitectura debe ser x86_64 o aarch64, dependiendo de la arquitectura del host de equipo sin sistema operativo que se va a inscribir.
Si no se ha especificado ninguna configuración de red para el host, ya sea en el momento de la creación de la imagen o a través de la definición BareMetalHost, se utilizará un mecanismo de autoconfiguración (DHCP, DHCPv6, SLAAC). Para obtener más detalles o configuraciones complejas, consulte el Chapter 53, Configuración de red avanzada.

Una vez creado el archivo, se debe ejecutar el siguiente comando en el clúster de gestión para comenzar a inscribir el nuevo host de equipo sin sistema operativo en el clúster de gestión:

$ kubectl apply -f bmh-example.yaml

El nuevo objeto de host de equipo sin sistema operativo se inscribirá, cambiando su estado de registro a inspección y disponible. Los cambios se pueden comprobar utilizando el siguiente comando:

$ kubectl get bmh

Note

El objeto BaremetalHost está en el estado registering hasta que se validan las credenciales BMC. Una vez validadas las credenciales, el objeto BaremetalHost cambia su estado a inspecting, y este paso podría llevar algún tiempo dependiendo del hardware (hasta 20 minutos). Durante la fase de inspección, se recupera la información del hardware y se actualiza el objeto de Kubernetes. Compruebe la información utilizando el siguiente comando: kubectl get bmh -o yaml.

Paso de aprovisionamiento

Una vez que el host de equipo sin sistema operativo esté inscrito y disponible, el siguiente paso es aprovisionarlo para instalar y configurar el sistema operativo y el clúster de Kubernetes. Para ello, se debe crear el siguiente archivo (capi-provisioning-example.yaml) en el clúster de gestión con la siguiente información (el capi-provisioning-example.yaml se puede generar uniendo los siguientes bloques).

Note

Solo se deben reemplazar los valores entre $\{…\} por los valores reales.

El siguiente bloque es la definición del clúster, donde la red se puede configurar utilizando los bloques pods y services. Además, contiene las referencias a los objetos del plano de control y de la infraestructura (utilizando el proveedor Metal³) que se van a utilizar.

apiVersion: cluster.x-k8s.io/v1beta2
kind: Cluster
metadata:
  name: single-node-cluster
  namespace: default
  labels:
    cluster-api.cattle.io/rancher-auto-import: "true"
spec:
  clusterNetwork:
    pods:
      cidrBlocks:
        - 192.168.0.0/18
        - fd00:bad:cafe::/48
    services:
      cidrBlocks:
        - 10.96.0.0/12
        - fd00:bad:bad:cafe::/112
  controlPlaneRef:
    apiGroup: controlplane.cluster.x-k8s.io
    kind: RKE2ControlPlane
    name: single-node-cluster
  infrastructureRef:
    apiGroup: infrastructure.cluster.x-k8s.io
    kind: Metal3Cluster
    name: single-node-cluster

Note

Son posibles tanto las implementaciones de pila única como de pila dual; elimine los CIDR de IPv6 de la definición anterior para un clúster solo de IPv4.
Las implementaciones de IPv6 de pila única están en fase de vista previa técnica y aún no cuentan con soporte oficial.
Añadir la etiqueta cluster-api.cattle.io/rancher-auto-import: "true" a los objetos cluster.x-k8s.io importará el clúster a Rancher (creando un objeto clusters.management.cattle.io correspondiente). Consulte la documentación de Cluster API para obtener más información.

El objeto Metal3Cluster especifica el punto de conexión del plano de control (reemplazando el ${DOWNSTREAM_CONTROL_PLANE_IPV4}) que se va a configurar y el noCloudProvider porque se utiliza un equipo sin sistema operativo.

apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
kind: Metal3Cluster
metadata:
  name: single-node-cluster
  namespace: default
spec:
  controlPlaneEndpoint:
    host: ${DOWNSTREAM_CONTROL_PLANE_IPV4}
    port: 6443
  noCloudProvider: true

El objeto RKE2ControlPlane especifica la configuración del plano de control que se va a utilizar y el objeto Metal3MachineTemplate especifica la imagen del plano de control que se va a utilizar. Además, contiene la información sobre el número de réplicas que se van a utilizar (en este caso, una) y el complemento CNI que se va a utilizar (en este caso, Cilium). El bloque agentConfig contiene el formato Ignition que se va a utilizar y el additionalUserData que se va a utilizar para configurar el nodo RKE2 con información como un systemd llamado rke2-preinstall.service para reemplazar automáticamente el BAREMETALHOST_UUID y el node-name durante el proceso de aprovisionamiento utilizando la información de Ironic. Para habilitar multus con cilium, se crea un archivo en el directorio de manifiestos del servidor rke2 llamado rke2-cilium-config.yaml con la configuración que se va a utilizar. El último bloque de información contiene la versión de Kubernetes que se va a utilizar. ${RKE2_VERSION} es la versión de RKE2 que se va a utilizar reemplazando este valor (por ejemplo, v1.35.4+rke2r1).

apiVersion: controlplane.cluster.x-k8s.io/v1beta2
kind: RKE2ControlPlane
metadata:
  name: single-node-cluster
  namespace: default
  annotations: {
    rke2.controlplane.cluster.x-k8s.io/load-balancer-exclusion: "true"
  }
spec:
  machineTemplate:
  infrastructureRef:
    apiGroup: infrastructure.cluster.x-k8s.io
    kind: Metal3MachineTemplate
    name: single-node-cluster-controlplane
  replicas: 1
  version: ${RKE2_VERSION}
  rolloutStrategy:
    type: "RollingUpdate"
    rollingUpdate:
      maxSurge: 0
  serverConfig:
    cni: cilium
  agentConfig:
    format: ignition
    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"
              ExecStart=/bin/sh -c "echo \"node-label:\" >> /etc/rancher/rke2/config.yaml"
              ExecStart=/bin/sh -c "echo \"  - metal3.io/uuid=$(jq -r .uuid /mnt/openstack/latest/meta_data.json)\" >> /etc/rancher/rke2/config.yaml"
              ExecStartPost=/bin/sh -c "umount /mnt"
              [Install]
              WantedBy=multi-user.target
          # rke2-traefik-deployment.service unit to be removed once "traefik" being the default ingress controller (starting with RKE2 v1.36)
          - name: rke2-traefik-deployment.service
            enabled: true
            contents: |
              [Unit]
              Description=rke2-traefik-deployment
              Wants=rke2-preinstall.service
              Before=rke2-install.service
              ConditionPathExists=!/run/cluster-api/bootstrap-success.complete
              [Service]
              Type=oneshot
              User=root
              ExecStart=/bin/sh -c "echo \"ingress-controller: traefik\" >> /etc/rancher/rke2/config.yaml"
              [Install]
              WantedBy=multi-user.target
        storage:
          directories:
          - path: /var/lib/rancher/rke2/server/manifests
            overwrite: true
          files:
          # https://docs.rke2.io/networking/multus_sriov#using-multus-with-cilium
          - path: /var/lib/rancher/rke2/server/manifests/rke2-cilium-config.yaml
            overwrite: true
            contents:
              inline: |
                apiVersion: helm.cattle.io/v1
                kind: HelmChartConfig
                metadata:
                  name: rke2-cilium
                  namespace: kube-system
                spec:
                  valuesContent: |-
                    cni:
                      exclusive: false
            mode: 0644
            user:
              name: root
            group:
              name: root
          - path: /var/lib/rancher/rke2/server/manifests/rke2-traefik-config.yaml
            overwrite: true
            contents:
              inline: |
                apiVersion: helm.cattle.io/v1
                kind: HelmChartConfig
                metadata:
                  name: rke2-traefik
                  namespace: kube-system
                spec:
                  valuesContent: |-
                    ingressClass:
                      isDefaultClass: true
                    ports:
                      web:
                        hostPort: null    # disallow hostPort
                        exposedPort: 80
                      websecure:
                        hostPort: null    # disallow hostPort
                        exposedPort: 443
                    service:
                      enabled: true
                      type: LoadBalancer
                      spec:
                        externalTrafficPolicy: Local
                        allocateLoadBalancerNodePorts: false  # k8s GA from 1.24; supported by MetalLB
            mode: 0644
            user:
              name: root
            group:
              name: root
    kubelet:
      extraArgs:
      - provider-id=metal3://BAREMETALHOST_UUID
    nodeName: "localhost.localdomain"

El objeto Metal3MachineTemplate especifica la siguiente información:

El dataTemplate que se va a utilizar como referencia para la plantilla.
El hostSelector que se debe utilizar coincidiendo con la etiqueta creada durante el proceso de inscripción.
El image que se debe utilizar como referencia a la imagen generada utilizando EIB en la sección (Chapter 49, Preparar la imagen del clúster descendente para escenarios conectados) anterior, y el checksum y checksumType que se deben utilizar para validar la imagen.

apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
kind: Metal3MachineTemplate
metadata:
  name: single-node-cluster-controlplane
  namespace: default
spec:
  template:
    spec:
      dataTemplate:
        name: single-node-cluster-controlplane-template
      hostSelector:
        matchLabels:
          cluster-role: control-plane
      image:
        checksum: http://imagecache.local:8080/eibimage-output-telco.raw.sha256
        checksumType: sha256
        format: raw
        url: http://imagecache.local:8080/eibimage-output-telco.raw

El objeto Metal3DataTemplate especifica el metaData para el clúster descendente.

apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
kind: Metal3DataTemplate
metadata:
  name: single-node-cluster-controlplane-template
  namespace: default
spec:
  clusterName: single-node-cluster
  metaData:
    objectNames:
    - key: name
      object: machine
    - key: local-hostname
      object: machine
    - key: local_hostname
      object: machine

Una vez creado el archivo uniendo los bloques anteriores, se debe ejecutar el siguiente comando en el clúster de gestión para comenzar a aprovisionar el nuevo host de equipo sin sistema operativo:

$ kubectl apply -f capi-provisioning-example.yaml