Documentación de SUSE Edge|Documentación de SUSE Telco Cloud|Acciones del ciclo de vida

44 Acciones del ciclo de vida

 

Esta sección describe las acciones de gestión del ciclo de vida de los clústeres desplegados con SUSE Telco Cloud.

44.1 Exclusión del equilibrador de carga

 

Hay muchas acciones del ciclo de vida que requieren que se vacíen los nodos. Durante el proceso de vaciado, todos los pods se trasladarán a otros nodos del clúster. Una vez finalizado el proceso de vaciado, el nodo no aloja ningún servicio y, por lo tanto, no debe recibir ningún tráfico. Se puede informar de esto a los equilibradores de carga, como MetalLB, aplicando una etiqueta al nodo:

node.kubernetes.io/exclude-from-external-load-balancers: "true"

Para obtener más detalles, consulte la documentación de Kubernetes.

Para ver las etiqueta de todos los nodos de un clúster, puede ejecutar:

kubectl get nodes -o json | jq -r '.items[].metadata | .name, .labels'

En el caso de las actualizaciones de clústeres descendentes, esto se puede automatizar anotando el RKE2ControlPlane en el clúster de gestión:

rke2.controlplane.cluster.x-k8s.io/load-balancer-exclusion="true"

Se crea de inmediato una anotación en todos los objetos de máquina del clúster de gestión para ese RKE2ControlPlane.

pre-drain.delete.hook.machine.cluster.x-k8s.io/rke2-lb-exclusion: ""

Con esta anotación en los objetos de la máquina, cualquier nodo del clúster descendente que esté programado para el vaciado obtendrá la etiqueta de nodo anterior adjunta antes del inicio del proceso de vaciado. La etiqueta se eliminará del nodo una vez que esté disponible y listo de nuevo.

44.2 Actualizaciones del clúster de gestión

 

La actualización del clúster de gestión se describe en la documentación del clúster de gestión de día 2 (Capítulo 36, Clúster de gestión).

44.3 Actualización de clústeres descendentes

 

Para actualizar los clústeres descendentes hay que actualizar varios componentes. Las siguientes secciones describen el proceso de actualización de cada uno de los componentes.

Actualización del sistema operativo

Para este proceso, consulte la siguiente referencia (Sección 43.2, “Preparación de la imagen del clúster descendente para entornos conectados”) para crear la nueva imagen con una nueva versión del sistema operativo. Con esta nueva imagen generada por EIB, la siguiente fase de aprovisionamiento utiliza la nueva versión operativa proporcionada. En el siguiente paso, la nueva imagen se utiliza para actualizar los nodos.

Actualización del clúster RKE2

Los cambios necesarios para actualizar el clúster RKE2 utilizando el flujo de trabajo automatizado son los siguientes:

apiVersion: controlplane.cluster.x-k8s.io/v1beta1
kind: RKE2ControlPlane
metadata:
  name: single-node-cluster
  namespace: default
spec:
  infrastructureRef:
    apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
    kind: Metal3MachineTemplate
    name: single-node-cluster-controlplane
  version: ${RKE2_NEW_VERSION}
  replicas: 1
  rolloutStrategy:
    type: "RollingUpdate"
    rollingUpdate:
      maxSurge: 0
  serverConfig:
    cni: cilium
  rolloutStrategy:
    rollingUpdate:
      maxSurge: 0
  registrationMethod: "control-plane-endpoint"
  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"
                ExecStartPost=/bin/sh -c "umount /mnt"
                [Install]
                WantedBy=multi-user.target
    kubelet:
      extraArgs:
        - provider-id=metal3://BAREMETALHOST_UUID
    nodeName: "localhost.localdomain"
apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
kind: Metal3MachineTemplate
metadata:
  name: single-node-cluster-controlplane
  namespace: default
spec:
  nodeReuse: True
  template:
    spec:
      automatedCleaningMode: metadata
      dataTemplate:
        name: single-node-cluster-controlplane-template
      hostSelector:
        matchLabels:
          cluster-role: control-plane
      image:
        checksum: http://imagecache.local:8080/${NEW_IMAGE_GENERATED}.sha256
        checksumType: sha256
        format: raw
        url: http://imagecache.local:8080/${NEW_IMAGE_GENERATED}.raw

Antes de aplicar el archivo capi-provisioning-example.yaml, siempre es recomendable informar a los equilibradores de carga externos (por ejemplo, MetalLB) sobre los nodos que se están vaciando, para que no dirijan el tráfico a los nodos que se encuentran en ese estado. Como se menciona en la sección Sección 44.1, “Exclusión del equilibrador de carga”, puede automatizar este proceso anotando el RKE2ControlPlane en el clúster de gestión. En este ejemplo, se anota un objeto RKE2ControlPlane llamado multinode-cluster:

kubectl annotate  RKE2ControlPlane/multinode-cluster  rke2.controlplane.cluster.x-k8s.io/load-balancer-exclusion="true"

Verifique que los objetos de máquina se han anotado:

pre-drain.delete.hook.machine.cluster.x-k8s.io/rke2-lb-exclusion: ""

Recopile las anotaciones de todos los objetos de máquina:

kubectl get machines -o json | jq -r '.items[].metadata | .name, .annotations'
Nota
Nota

Sin estas anotaciones, los usuarios pueden sufrir mayores tiempos de respuesta de los servicios, ya que los equilibradores de carga no están informados de los nodos vaciados.

Después de realizar estos cambios, el archivo capi-provisioning-example.yaml se puede aplicar al clúster con este comando:

kubectl apply -f capi-provisioning-example.yaml