Pasos para actualizar el nodo maestro del clúster

Antes de empezar, asegúrate de que dispones del rol de acceso a la plataforma IAM Operador o Administrador. Si no estás seguro de cuál es tu rol de acceso, ve a Gestionar → Acceso (IAM) → Usuarios en la consola de IBM Cloud, o pregunta al administrador de tu cuenta.

Si se está llevando a cabo una rotación de certificados de una autoridad de certificación (CA), la actualización maestra queda bloqueada hasta que finalice la rotación. Comprueba el estado de cualquier rotación en curso antes de empezar.

Para actualizar la versión principal o menor del maestro de Kubernetes:

1. Revisa la información sobre la versión de Kubernetes y realiza las actualizaciones marcadas como Actualizar antes que master.

2. Revisa cualquier advertencia útil de Kubernetes, como los avisos de obsolescencia.

3. Compruebe que la actualización de la versión del clúster no tenga consecuencias para los complementos y plugins instalados en el clúster.

   • Comprobación de complementos

     1. Obtenga una lista de los complementos en el clúster.

        ibmcloud ks cluster addon ls --cluster CLUSTER
        

     2. Compruebe la versión de Kubernetes soportada para cada complemento instalado.

        ibmcloud ks addon-versions
        

     3. Si el complemento debe actualizarse para que se ejecute en la versión de Kubernetes a la que desea actualizar el clúster, actualice el complemento.

   • Comprobación de plug-ins

     1. En el catálogo de Helm, busca los complementos que has instalado en tu clúster.
     2. En el menú lateral, expanda la sección SOURCES & TAR FILE.
     3. Descargue y abra el código fuente.
     4. Compruebe los archivos README.md o RELEASENOTES.md para las versiones soportadas.
     5. Si el plugin debe actualizarse para que se ejecute en la versión de Kubernetes a la que desea actualizar el clúster, actualice el plugin siguiendo las instrucciones del plugin.

4. Actualiza tu servidor API y los componentes principales asociados utilizando el IBM Cloud consola o ejecutando la CLI. ibmcloud ks cluster master updatecomando

5. Espere unos minutos y luego confirme que la actualización se ha completado. Revise la versión del servidor de API en el panel de control de IBM Cloud o ejecutando ibmcloud ks cluster ls.

6. Instale la versión de kubectl cli que coincida con la versión del servidor de API que se ejecuta en el maestro. Kubernetes no admite versiones de cliente kubectl que difieran en dos o más versiones respecto a la versión del servidor (n ± 2). Para actualizar tu configuración local, ejecuta ibmcloud ks cluster config -c CLUSTER_NAME_OR_ID, y a continuación compruébalo con kubectl version --client.

Cuando se haya completado la actualización del nodo maestro, actualiza tus nodos de trabajo. El método depende del tipo de infraestructura que tengas:

1. Actualización de nodos de trabajo clásicos: utiliza una actualización progresiva controlada mediante un ConfigMap y el comando worker update.
2. Actualización de los nodos de trabajo de VPC: los nodos de trabajo VPC VSI y los nodos de trabajo VPC bare metal deben utilizar worker replace --update. El procedimiento de actualización progresiva de ConfigMap aún no es compatible con los nodos de trabajo de VPC.

Requisitos previos

Antes de actualizar los nodos de trabajo de tu infraestructura clásica, sigue los siguientes pasos previos.

Durante la actualización de un nodo de trabajo, se reinstala el sistema operativo del equipo del nodo de trabajo y se eliminan de forma permanente todos los datos que no estén almacenados en un almacenamiento persistente. Comprueba que todos los datos que debas conservar estén almacenados fuera del nodo de trabajo antes de empezar.

Si tiene instalado Portworx en su clúster, debe actualizar la configuración de Portworx antes de actualizar los nodos de trabajo.

Actualización de nodos trabajadores clásicos en la CLI con un mapa de configuración

Utiliza un ConfigMap para realizar una actualización progresiva de tus nodos de trabajo clásicos. La función ConfigMap te permite controlar cuántos nodos pueden estar indisponibles a la vez, por zona o región. Si la regla predeterminada del 20 % de indisponibilidad es aceptable para su clúster, puede omitir los pasos 3 y 4 (creación de ConfigMap ) y pasar directamente al paso 5 para aplicar la actualización utilizando el comportamiento predeterminado.

1. Complete los pasos de requisito previo.

2. Obtenga una lista de los nodos trabajadores disponibles y anote su dirección IP privada.

   ibmcloud ks worker ls --cluster CLUSTER
   

3. Vea las etiquetas de un nodo trabajador. Encontrará las etiquetas de los nodos trabajadores en la sección Labels de la información de salida de la CLI. Cada etiqueta consta de un NodeSelectorKey y un NodeSelectorValue.

   kubectl describe node PRIVATE-WORKER-IP
   

   Salida de ejemplo

   NAME:               10.184.58.3
   Roles:              <none>
   Labels:             arch=amd64
                   beta.kubernetes.io/arch=amd64
                   beta.kubernetes.io/os=linux
                   failure-domain.beta.kubernetes.io/region=us-south
                   failure-domain.beta.kubernetes.io/zone=dal12
                   ibm-cloud.kubernetes.io/encrypted-docker-data=true
                   ibm-cloud.kubernetes.io/iaas-provider=softlayer
                   ibm-cloud.kubernetes.io/machine-type=u3c.2x4.encrypted
                   kubernetes.io/hostname=10.123.45.3
                   privateVLAN=2299001
                   publicVLAN=2299012
   Annotations:        node.alpha.kubernetes.io/ttl=0
                   volumes.kubernetes.io/controller-managed-attach-detach=true
   CreationTimestamp:  Tue, 03 Apr 2022 15:26:17 -0400
   Taints:             <none>
   Unschedulable:      false
   

4. Cree un mapa de configuración y defina las reglas de no disponibilidad para los nodos trabajadores. ConfigMap admite hasta 15 comprobaciones con nombre. Cada comprobación se centra en un conjunto de nodos de trabajo según su etiqueta y establece el porcentaje máximo de dichos nodos que pueden estar indisponibles al mismo tiempo. El siguiente ejemplo muestra una comprobación de zona (zonecheck.json), una comprobación de región (regioncheck.json), una comprobación de alternativa predeterminada (defaultcheck.json) y una plantilla para comprobaciones personalizadas. En cada comprobación, elige una de las etiquetas de los nodos de trabajo que has recuperado en el paso anterior para identificar los nodos de destino.

   Para cada comprobación, solo puede seleccionar un valor para NodeSelectorKey y NodeSelectorValue. Si desea establecer reglas para más de una región, zona u otras etiquetas de nodo trabajador, cree una nueva comprobación. Define hasta 15 comprobaciones en un mapa de configuración. Si añade más comprobaciones, sólo se vuelve a cargar 1 nodo trabajador cada vez hasta que se actualicen todos los trabajadores solicitados.

   Ejemplo

   apiVersion: v1
   kind: ConfigMap
   metadata:
     name: ibm-cluster-update-configuration
     namespace: kube-system
   data:
     drain_timeout_seconds: "120"
     zonecheck.json: |
       {
         "MaxUnavailablePercentage": 30,
         "NodeSelectorKey": "failure-domain.beta.kubernetes.io/zone",
         "NodeSelectorValue": "dal13"
       }
     regioncheck.json: |
       {
         "MaxUnavailablePercentage": 20,
         "NodeSelectorKey": "failure-domain.beta.kubernetes.io/region",
         "NodeSelectorValue": "us-south"
       }
     defaultcheck.json: |
       {
         "MaxUnavailablePercentage": 20
       }
     <check_name>: |
       {
         "MaxUnavailablePercentage": <value_in_percentage>,
         "NodeSelectorKey": "<node_selector_key>",
         "NodeSelectorValue": "<node_selector_value>"
       }
   

   drain_timeout_seconds

   Opcional: El tiempo de espera, en segundos, hasta que finalice el vaciado. El drenaje de un nodo trabajador elimina de forma segura todos los pods existentes del nodo trabajador y replanifica los pods en otros nodos trabajadores del clúster. Los valores aceptados son enteros comprendidos entre 1 y 180. El valor predeterminado es 30.

   zonecheck.json y regioncheck.json

   Dos comprobaciones que definen una regla para un conjunto de nodos de trabajador que puede identificar con los valores NodeSelectorKey y NodeSelectorValue especificados. zonecheck.json identifica los nodos de trabajador en función de la etiqueta de su zona y regioncheck.json utiliza la etiqueta de región que se añade a cada nodo de trabajador durante el suministro. En el ejemplo, el 30 % de todos los nodos de trabajador que tienen dal13 como etiqueta de zona y el 20 % de todos los nodos de trabajador que hay en us-south pueden estar no disponibles durante la actualización.

   defaultcheck.json

   Si no crea una ningún mapa de configuración o el mapa se configura de forma incorrecta, se aplica el valor predeterminado de Kubernetes. De forma predeterminada, solo el 20% de los nodos trabajadores del clúster pueden no estar disponibles a la vez. Puede modificar el valor predeterminado añadiendo la comprobación predeterminada al mapa de configuración. En el ejemplo, todos los nodos de trabajador que no se especifican en las comprobaciones de zona y región (dal13 o us-south) pueden estar no disponibles durante la actualización.

   MaxUnavailablePercentage

   El número máximo de nodos que pueden no estar disponibles para una clave de etiqueta y un valor especificados, especificado como un porcentaje. Un nodo trabajador no está disponible cuando está en proceso de despliegue, de recarga o de suministro. Los nodos trabajadores en cola están bloqueados para actualizarse si se supera cualquier porcentaje no disponible máximo definido.

   NodeSelectorKey

   La clave de etiqueta del nodo trabajador para el que desea definir una regla. Puede establecer reglas para las etiquetas predeterminadas proporcionadas por IBM, así como para las etiquetas de nodos trabajadores que haya creado. Si desea añadir una regla para los nodos de trabajador que pertenecen a una agrupación de trabajadores, puede utilizar la etiqueta ibm-cloud.kubernetes.io/machine-type.

   NodeSelectorValue

   El valor de etiqueta que debe tener el nodo trabajador para que se tenga en cuenta para la regla que defina.

5. Cree el mapa de configuración en el clúster.

   kubectl apply -f <filepath/configmap.yaml>
   

6. Verifique que se ha creado el mapa de configuración.

   kubectl get configmap --namespace kube-system
   

7. Actualice los nodos trabajadores.

   ibmcloud ks worker update --cluster CLUSTER --worker WORKER-NODE-1-ID --worker WORKER-NODE-2-ID
   

8. Opcional: compruebe los sucesos que desencadena el mapa de configuración y los errores de validación que se produzcan. Los sucesos se pueden revisar en la sección Events de la información de salida de la CLI.

   kubectl describe -n kube-system cm ibm-cluster-update-configuration
   

9. Confirme que la actualización se ha completado revisando la versión de Kubernetes de los nodos trabajadores.

   kubectl get nodes
   

10. Verifique que no tiene nodos de trabajador duplicados. En ocasiones, los clústeres más antiguos muestran nodos de trabajo duplicados con un estado NotReady tras una actualización. Para eliminar los duplicados, consulte resolución de problemas.

Actualización de nodos trabajadores clásicos en la consola

Una vez que hayas configurado el ConfigMap por primera vez, podrás actualizar los nodos de trabajo mediante la consola IBM Cloud. La consola respeta las reglas de indisponibilidad que has definido en el servicio ConfigMap.

1. Sigue los pasos previos y configura un ConfigMap para controlar cómo se actualizan tus nodos de trabajo.
2. En el menú de la consola IBM Cloud , haga clic en Containers > Clusters.
3. En la página Clústeres, pulse el clúster.
4. En el separador Nodos trabajadores, marque el recuadro de selección de cada nodo trabajador que desee actualizar. Se muestra una barra de acciones sobre la fila de cabecera de la tabla.
5. En la barra de acciones, pulse Actualizar.

Si tiene Portworx instalado en su clúster, debe reiniciar los pods de Portworx en los nodos de trabajo actualizados. Para obtener más información, consulte las Limitaciones de Portworx.

Requisitos previos

Antes de actualizar los nodos de trabajo de tu infraestructura VPC, sigue los siguientes pasos previos.

En el caso de los trabajadores VPC VSI, el nodo de trabajo se elimina y se sustituye por un nuevo nodo. En el caso de los servidores bare metal de VPC, el nodo se recarga in situ. En ambos casos, los datos que no se almacenan en un almacenamiento persistente se eliminan de forma permanente. Comprueba que todos los datos que debas conservar estén almacenados fuera del nodo de trabajo antes de empezar.

Si tienes un Portworx e implementado en tu clúster, sigue los pasos para actualizar los nodos de trabajo de VPC con volúmenes de Portworx en lugar de los pasos que se indican en esta página.

Actualizaciones de firmware durante la recarga de un trabajador bare metal de VPC

Al reiniciar un nodo de trabajo bare metal de VPC, la infraestructura de IBM Cloud comprueba automáticamente si hay alguna actualización de firmware pendiente para ese servidor y la aplica como parte del proceso de reinicio. No es necesario realizar ninguna acción adicional para activar la actualización del firmware.

Ten en cuenta las siguientes consideraciones al reiniciar un nodo de trabajo bare metal de VPC:

Tiempo de recarga prolongado

Si se aplica una actualización de firmware durante la recarga, el tiempo total de recarga puede aumentar significativamente —en 30 minutos o más— por encima de la duración habitual de la recarga. Planifica tus ventanas de mantenimiento en consecuencia.

No hay información previa sobre las actualizaciones pendientes

No se puede saber si hay una actualización de firmware pendiente para un nodo de trabajo antes de ejecutar el comando de recarga.

Riesgo de pérdida de datos

Al igual que ocurre con todas las recargas de los servidores bare metal de VPC, los datos de los discos locales se eliminan durante la recarga, independientemente de si se aplica una actualización de firmware. Haz una copia de seguridad de todos los datos que no estén almacenados en un almacenamiento persistente antes de volver a cargarlos.

Error de recarga debido a una actualización del firmware

En algunos casos, una actualización de firmware puede fallar, lo que provoca que el nodo de trabajo entre en un estado reload_failed (Failed to reload worker) con los detalles de estado The infrastructure firmware update has failed. (P4056). Si ocurre esto:

1. Espera unos minutos y, a continuación, vuelve a intentar actualizar la página ejecutando de nuevo ibmcloud ks worker reload --cluster CLUSTER --worker WORKER-NODE-ID.
2. Si el error persiste tras 2 o 3 intentos, abre un caso de soporte en IBM Cloud.

Antes de empezar

• Inicie una sesión en la cuenta. If applicable, target the appropriate resource group. Establezca el contexto para el clúster.
• Comprueba que todos los datos que debas conservar estén almacenados en un almacenamiento persistente fuera del nodo de trabajo. Los datos almacenados únicamente en el nodo de trabajo se pierden y no se pueden recuperar.
• Asegúrate de que dispones del rol de acceso a la plataforma IAM de Operador o Administrador. Si no estás seguro de cuál es tu rol de acceso, ve a Gestionar → Acceso (IAM) → Usuarios en la consola de IBM Cloud, o pregunta al administrador de tu cuenta.

Para actualizar las variantes

1. Obtenga una lista de los nodos trabajadores disponibles y anote su dirección IP privada.

   1. Obtenga una lista de los nodos trabajadores del clúster.

       ibmcloud ks worker-pool ls --cluster CLUSTER
       ```
   2. Obtenga una lista de los nodos trabajadores de la agrupación de nodos trabajadores. Anote el **ID** y la **IP privada**.
   ```sh {: pre}
       ibmcloud ks worker ls --cluster CLUSTER --worker-pool WORKER-POOL
       ```
   3. Obtenga los detalles de un nodo trabajador. En la salida, anote la zona y el ID de VLAN privada y pública para los clústeres clásicos o el ID de subred para clústeres de VPC.
   ```sh {: pre}
       ibmcloud ks worker get --cluster CLUSTER --worker WORKER-ID
       ```
   

2. Obtenga una lista de las versiones disponibles en la zona.

   ibmcloud ks flavors --zone <zone>
   

3. Cree un nodo trabajador con el nuevo tipo de máquina.

   1. Cree una agrupación de nodos trabajadores con el número de nodos trabajadores que desea sustituir.
      • Clústeres clásicos:

        ibmcloud ks worker-pool create classic --name WORKER-POOL --cluster CLUSTER --flavor FLAVOR --size-per-zone NUMBER-OF-WORKERS-PER-ZONE
        

      • Clústeres VPC Generación 2:

        ibmcloud ks worker-pool create vpc-gen2 --name NAME --cluster CLUSTER --flavor FLAVOR --size-per-zone NUMBER-OF-WORKERS-PER-ZONE --label LABEL
        

   2. Verifique que la agrupación de nodos trabajadores se ha creado.

       ibmcloud ks worker-pool ls --cluster CLUSTER
       ```
   3. Añada la zona a la agrupación de nodos trabajadores que ha recuperado anteriormente. Cuando se añade una zona, los nodos trabajadores definidos en la agrupación de nodos trabajadores se suministran en la zona y se tienen en cuenta para la futura planificación de la carga de trabajo. Si desea distribuir los nodos trabajadores en varias zonas, elija una ubicación multizona [clásica](/docs/containers?topic=containers-regions-and-zones#zones-mz) o [VPC](/docs/containers?topic=containers-regions-and-zones#zones-vpc).
       * Clústeres clásicos:
           ```sh {: pre}
           ibmcloud ks zone add classic --zone ZONE --cluster CLUSTER --worker-pool WORKER-POOL --private-vlan PRIVATE-VLAN-ID --public-vlan PUBLIC-VLAN-ID
           ```
       * Clústeres VPC:
           ```sh {: pre}
           ibmcloud ks zone add vpc-gen2 --zone ZONE --cluster CLUSTER --worker-pool WORKER-POOL --subnet-id VPC-SUBNET-ID
           ```
   

4. Espere a que se desplieguen los nodos trabajadores. Cuando el estado del nodo trabajador pase a ser Normal, significa que el despliegue ha finalizado.

   ibmcloud ks worker ls --cluster CLUSTER
   

5. Elimina el antiguo grupo de trabajadores. Si eliminas una variante Classic de servidor físico (cuya facturación es mensual), se te cobrará el mes completo, aunque la elimines a mitad de mes. Los trabajadores de VPC, incluidos los de servidor físico, se facturan por horas.

   1. Elimine la agrupación de nodos trabajadores con el tipo de máquina antiguo. Al eliminar una agrupación de nodos trabajadores se eliminan todos los nodos trabajadores de la agrupación en todas las zonas. El proceso puede tardar varios minutos en completarse.

       ibmcloud ks worker-pool rm --worker-pool WORKER-POOL --cluster CLUSTER
       ```
   2. Verifique que la agrupación de nodos trabajadores se ha eliminado.
   ```sh {: pre}
       ibmcloud ks worker-pool ls --cluster CLUSTER
       ```
   

6. Verifique que los nodos trabajadores se han eliminado del clúster.

   ibmcloud ks worker ls --cluster CLUSTER
   

7. Repita estos pasos para actualizar otras agrupaciones de nodos trabajadores o nodos trabajadores autónomos a distintas versiones.

Gestión de actualizaciones automáticas para Fluentd

Cuando crea una configuración de registro para un origen en el clúster a fin de reenviar a un servidor externo, se crea un componente Fluentd en el clúster. Para cambiar las configuraciones de registro o de filtro, el componente Fluentd debe estar en la última versión. De forma predeterminada, las actualizaciones automáticas del componente están habilitadas.

Para ejecutar los siguientes comandos, debe disponer del rol de acceso a la plataforma IAM IBM Cloud de administrador para el clúster.

Puede gestionar las actualizaciones automáticas del componente Fluentd de las maneras siguientes.

• Para comprobar si las actualizaciones automáticas están habilitadas, ejecute el mandato ibmcloud ks logging autoupdate get --cluster CLUSTER.
• Desactiva las actualizaciones automáticas ejecutando el. ibmcloud ks logging autoupdate disablecomando
• Si las actualizaciones automáticas están inhabilitadas pero tiene que modificar la configuración, tiene dos opciones:
  • Activar las actualizaciones automáticas para sus pods Fluentd.

      ibmcloud ks logging autoupdate enable --cluster CLUSTER
      ```
  * Forzar una actualización única cuando utilice un mandato de registro que incluya la opción `--force-update`. Tus pods se actualizan a la última versión del componente Fluentd, pero Fluentd no se actualizará automáticamente en el futuro.
          Mandato de ejemplo
  
  ```sh {: pre}
      ibmcloud ks logging config update --cluster CLUSTER --id LOG-CONFIG-ID --type LOG-TYPE --force-update
      ```
  

Gestión de actualizaciones automáticas para los ALB de Ingress

Controle cuándo se actualiza el componente de equilibrador de carga de aplicación (ALB) de Ingress. Para obtener información sobre cómo mantener los ALB actualizados, consulte Gestión del ciclo de vida de ALB de Ingress.