IBM Cloud Docs
Actualización de clústeres, nodos trabajadores y componentes de clúster

Actualización de clústeres, nodos trabajadores y componentes de clúster

Revise las siguientes secciones para ver los pasos necesarios para mantener actualizados los nodos maestro y de trabajador del clúster.

Actualización del nodo maestro

¿Cómo sé cuándo debo actualizar el maestro?
Se le notificará en la consola, los anuncios y la CLI cuando haya actualizaciones disponibles. También puede comprobar periódicamente la página de versiones soportadas.
¿Cuántas versiones por detrás de la última puede estar la maestra?
Puede actualizar el servidor API sólo a la siguiente versión anterior a la actual (n+1).
¿Pueden mis nodos trabajadores ejecutar una versión posterior a la maestra?
Los nodos de trabajador no pueden ejecutar una versión de Kubernetes major.minor posterior a la del maestro. Además, los nodos de trabajador pueden ser únicamente de hasta dos versiones anteriores a la versión maestra (n-2). Primero, actualice el maestro a la última versión de Kubernetes. Luego actualice los nodos trabajadores del clúster.

Los nodos trabajadores pueden ejecutar versiones posteriores del parche que el maestro, como versiones de parches específicas de los nodos trabajadores para las actualizaciones de seguridad.

¿Cómo se aplican las actualizaciones de parches?
De forma predeterminada, las actualizaciones de parches para el nodo maestro se aplican automáticamente durante el curso de varios días, por lo que una versión de parche maestro podría aparecer como disponible antes de que se aplique a su nodo maestro. La automatización de actualizaciones también pasa por alto los clústeres que no están en buen estado o que tienen operaciones actualmente en curso. Ocasionalmente, IBM podría inhabilitar las actualizaciones automáticas para un fixpack maestro específico, como un parche que solo sea necesario si se actualiza un nodo maestro de una versión menor a otra. En cualquiera de estos casos, puede comprobar la información sobre la versión de Kubernetes para detectar cualquier posible impacto y optar por utilizar de forma segura el comando ibmcloud ks cluster master update usted mismo sin esperar a que se aplique la automatización de la actualización.

A diferencia de lo que sucede con el nodo maestro, debe actualizar los nodos trabajadores para cada versión de parche.

¿Qué ocurre durante la actualización maestra?
El nodo maestro está altamente disponible con tres pods de maestro de réplica. Los pods del nodo maestro tienen una actualización continua, durante la cual solo hay un pod que no está disponible al mismo tiempo. Dos instancias están activas y en ejecución para que pueda acceder y cambiar el clúster durante la actualización. Sus nodos trabajadores, apps y recursos continúan en ejecución.
¿Puedo deshacer la actualización?
No, no puede retrotraer un clúster a una versión anterior después de realizar el proceso de actualización. Asegúrese de utilizar un clúster de prueba y siga las instrucciones para abordar posibles problemas antes de actualizar el nodo maestro de producción.
¿Qué proceso puedo seguir para actualizar el maestro?
El diagrama siguiente muestra el proceso que puede realizar para actualizar el maestro.

Diagrama del proceso maestro de
Kubernetes del
del proceso maestro*

Pasos para actualizar el nodo maestro del clúster

Antes de empezar, asegúrese de que tiene el rol de acceso a la plataforma IAM Operador o Administrador.

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

  1. Revise la información sobre la versión de Kubernetes y realice cualquier actualización marcada como Update before master.

  2. Revise cualquier advertencia útil de Kubernetes, como los avisos de obsoletos.

  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 Helm, busque los plug-ins que ha instalado en su cluster.
      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. Actualice los componentes del servidor de API y del nodo maestro asociado utilizando la consola de IBM Cloud o ejecutando el ibmcloud ks cluster master updatemandato de la CLI .

  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 kubectl versiones de cliente que tengan dos o más versiones de diferencia con la versión del servidor (n +/- 2).

Cuando finalice la actualización del nodo maestro, puede actualizar los nodos trabajadores, en función del tipo de proveedor de infraestructura de clúster que tenga.

Actualización de nodos trabajadores clásicos

Ve que hay una actualización disponible para los nodos trabajadores en un clúster de infraestructura clásica. ¿Qué significa? Como las actualizaciones y parches de seguridad se han aplicado para el servidor de API y otros componentes del nodo maestro, debe asegurarse de que los nodos trabajadores permanecen sincronizados. Puede realizar dos tipos de actualizaciones: actualizar solo la versión de parche o actualizar la versión major.minor con la versión de parche.

  • Parche: una actualización de parche de nodo trabajador incluye arreglos de seguridad. Puede actualizar el nodo trabajador clásico al último parche utilizando los mandatos ibmcloud ks worker reload o update. Tenga en cuenta que el mandato update también actualiza el nodo trabajador a la misma versión major.minor que la última versión de parche del nodo maestro, si también hay disponible una actualización de versión major.minor.
  • Major.minor: una actualización major.minor mueve la versión de Kubernetes del nodo trabajador a la misma versión que el maestro. Este tipo de actualización suele incluir cambios en la API de Kubernetes u otros comportamientos para los que debe preparar el clúster. Recuerde que los nodos de trabajador sólo pueden ser de hasta dos versiones anteriores a la versión maestra (n-2). Puede actualizar el nodo de trabajador clásico al mismo parche utilizando el mandato ibmcloud ks worker update.

Para obtener más información, consulte Tipos de actualización.

¿Qué ocurre con mis aplicaciones durante una actualización?
Si ejecuta apps como parte de un despliegue en nodos trabajadores que actualiza, las apps se replanifican en otros nodos trabajadores del clúster. Estos nodos trabajadores pueden estar en otra agrupación de nodos trabajadores o, o si tiene nodos trabajadores autónomos, es posible que las apps se planifiquen en nodos trabajadores autónomos. Para evitar el tiempo de inactividad de la app, debe asegurarse de que tiene suficiente capacidad en el clúster para gestionar la carga de trabajo.
¿Cómo puedo controlar cuántos nodos trabajadores se caen a la vez durante una actualización o recarga?
Si necesita que todos los nodos trabajadores estén en ejecución, tenga en cuenta la posibilidad de redimensionar la agrupación de nodos trabajadores o de añadir nodos trabajadores autónomos para disponer de más nodos trabajadores. Puede eliminar los nodos trabajadores adicionales después de que se haya completado la actualización.

Además, puede crear un mapa de configuración Kubernetes que especifique el número máximo de nodos trabajadores que pueden no estar disponibles en un momento dado, como durante una actualización. Los nodos trabajadores se identifican mediante etiquetas de nodo trabajador. Puede utilizar las etiquetas proporcionadas por IBM o las etiquetas personalizadas que haya añadido al nodo trabajador.

Las reglas del mapa de configuración de Kubernetes se utilizan sólo para actualizar nodos trabajadores. Estas reglas no afectan a las recargas de nodos trabajadores, lo que significa que la recarga se produce inmediatamente cuando se solicita.

¿Y si decido no definir un mapa de configuración?
Cuando no se ha definido un mapa de configuración, se utiliza el predeterminado. De forma predeterminada, el 20 % del total de nodos de trabajador de cada clúster, como máximo, pueden estar no disponibles durante el proceso de actualización.

Requisitos previos

Antes de actualizar los nodos trabajadores de la infraestructura clásica, revise los pasos de requisito previo.

Las actualizaciones a los nodos trabajadores pueden hacer que las apps y los servicios estén un tiempo inactivos. Se crea de nuevo la imagen de la máquina del nodo trabajador y se suprimen los datos si no se almacenan fuera del pod.

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

Configure un mapa de configuración para realizar una actualización continua de los nodos trabajadores clásicos.

  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. En el siguiente ejemplo se muestran cuatro configuraciones: zonecheck.json, regioncheck.json, defaultcheck.json y una plantilla de comprobación. Puede utilizar estas comprobaciones de ejemplo para definir reglas para los nodos de trabajador de una zona (zonecheck.json) o región (regioncheck.json) específica, o para todos los nodos de trabajador que no coincidan con ninguna de las comprobaciones que haya definido en el mapa de configuración (defaultcheck.json). Utilice la plantilla de comprobación para crear su propia comprobación. Para cada comprobación, para identificar un nodo trabajador, debe elegir una de las etiquetas de nodo trabajador que ha recuperado en el paso anterior.

    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. Defina 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 para esperar a que se complete el drenaje. 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. A veces, en las listas de los clústeres más antiguos pueden aparecer nodos de trabajador duplicados con el estado NotReady después de una actualización. Para eliminar los duplicados, consulte resolución de problemas.

Próximos pasos:

  • Repita el proceso de actualización con otras agrupaciones de nodos trabajadores.
  • Informe a los desarrolladores que trabajan en el clúster para que actualicen su CLI de kubectl a la versión del maestro de Kubernetes.
  • Si el panel de control de Kubernetes no muestra gráficos de utilización, suprima el pod kube-dashboard.

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

Después de configurar el mapa de configuración por primera vez, puede actualizar posteriormente los nodos trabajadores mediante la consola de IBM Cloud.

Para actualizar nodos trabajadores desde la consola:

  1. Complete los pasos de requisito previo y configure un mapa de configuración para controlar el modo en que se actualizan los nodos trabajadores.
  2. En el menú de la consola IBM Cloud Icono de menú, 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 el clúster, debe reiniciar los pods de Portworx en los nodos trabajadores actualizados. Para obtener más información, consulte las Limitaciones de Portworx.

Actualización de nodos trabajadores de VPC

Usted nota que una actualización está disponible para sus nodos trabajadores en un cluster VPC. ¿Qué significa? Como las actualizaciones y parches de seguridad se han aplicado para el servidor de API y otros componentes del nodo maestro, debe asegurarse de que los nodos trabajadores permanecen sincronizados. Puede realizar dos tipos de actualizaciones: actualizar solo la versión de parche o actualizar la versión major.minor con la versión de parche.

Si tiene Portworx desplegado en el clúster, siga los pasos necesarios para actualizar los nodos de trabajador de VPC con volúmenes de Portworx.

  • Parche: una actualización de parche de nodo trabajador incluye arreglos de seguridad. Puede actualizar el nodo trabajador de VPC al parche más reciente mediante el mandato ibmcloud ks worker replace.
  • Major.minor: una actualización major.minor mueve la versión de Kubernetes del nodo trabajador a la misma versión que el maestro. Este tipo de actualización suele incluir cambios en la API de Kubernetes u otros comportamientos para los que debe preparar el clúster. Recuerda que tus nodos trabajadores sólo pueden estar hasta dos versiones por detrás de la versión maestra (n-2). Puede actualizar el nodo trabajador de la VPC al mismo parche utilizando el comando ibmcloud ks worker replace con la opción --update.
¿Qué ocurre con mis aplicaciones durante una actualización?
Si ejecuta apps como parte de un despliegue en nodos trabajadores que actualiza, las apps se replanifican en otros nodos trabajadores del clúster. Estos nodos trabajadores pueden estar en otra agrupación de nodos trabajadores. Para evitar el tiempo de inactividad de su aplicación, debe asegurarse de que dispone de capacidad suficiente en el clúster para soportar la carga de trabajo, por ejemplo redimensionando sus grupos de trabajadores. Para obtener más información, consulte Adición de nodos trabajadores a clústeres clásicos o Adición de nodos trabajadores a clústeres de VPC.
¿Qué le ocurre a mi nodo trabajador durante una actualización?
El nodo trabajador de VPC se sustituye eliminando el nodo trabajador anterior y suministrando un nuevo nodo trabajador que se ejecuta en la versión major.minor o en el parche actualizado. El nodo trabajador de sustitución se crea en la misma zona y en la misma agrupación de nodos trabajadores, y con el mismo tipo que el nodo trabajador suprimido. Sin embargo, al nodo trabajador de sustitución se le asigna una nueva dirección IP privada y pierde las marcas o etiquetas personalizadas que ha aplicado al nodo trabajador antiguo (las marcas o etiquetas de la agrupación de nodos trabajadores se siguen aplicando al nodo trabajador de sustitución).
¿Qué ocurre si sustituyo varios nodos trabajadores al mismo tiempo?
Si sustituye varios nodos trabajadores al mismo tiempo, se suprimen y se sustituyen simultáneamente, no uno por uno. Asegúrese de que tiene suficiente capacidad en el clúster para volver a planificar las cargas de trabajo antes de sustituir los nodos trabajadores.
¿Qué ocurre si no se crea un nodo trabajador de sustitución?
No se crea un nodo trabajador de sustitución si la agrupación de nodos trabajadores no tiene el reequilibrio automático habilitado.

Requisitos previos

Antes de actualizar los nodos trabajadores de la infraestructura VPC, revise los pasos de requisito previo.

Las actualizaciones a los nodos trabajadores pueden hacer que las apps y los servicios estén un tiempo inactivos. Se elimina la máquina del nodo trabajador y se suprimen los datos si no se almacenan fuera del pod.

Actualización de nodos trabajadores de VPC en la CLI

Complete los siguientes pasos para actualizar sus nodos trabajadores mediante la CLI.

  1. Complete los pasos de requisito previo.
  2. Opcional: Añada capacidad a su cluster redimensionando el pool de trabajadores. Los pods del nodo trabajador se pueden volver a planificar y pueden seguir ejecutándose en los nodos trabajadores añadidos durante la actualización. Para obtener más información, consulte Adición de nodos trabajadores a clústeres clásicos o Adición de nodos trabajadores a clústeres de VPC.
  3. Obtenga una lista de los nodos trabajadores del clúster y anote el ID y la IP principal del nodo trabajador que desea actualizar.
    ibmcloud ks worker ls --cluster CLUSTER
  4. Sustituya el nodo trabajador por actualizar la versión de parche o la versión major.minor que coincida con la versión del nodo maestro.
    • Para actualizar el nodo trabajador a la misma versión major.minor que el maestro, por ejemplo de 1.31 a 1.32, incluya la opción --update.
      ibmcloud ks worker replace --cluster CLUSTER --worker WORKER-NODE-ID --update
    • Para actualizar el nodo trabajador a la última versión del parche en la misma versión major.minor, como de 1.31.8_1530 a 1.31.9_1533, no incluya la opción --update.
      ibmcloud ks worker replace --cluster CLUSTER --worker WORKER-NODE-ID
  5. Repita estos pasos para cada nodo trabajador que deba actualizar.
  6. Opcional: Después de que los nodos de trabajador reemplazados estén en estado Listo, redimensione el grupo de trabajadores para satisfacer la capacidad de clúster que desee. Para obtener más información, Adición de nodos trabajadores a clústeres de VPC.

Si ejecuta Portworx en el clúster de VPC, debe conectar manualmente el volumen de Block Storage for VPC al nuevo nodo trabajador.

Actualización de nodos trabajadores de VPC en la consola

Puede actualizar los nodos trabajadores de VPC en la consola. Antes de empezar, considere la posibilidad de añadir nodos de trabajo al clúster para evitar el tiempo de inactividad de sus aplicaciones.

  1. Complete los pasos de requisito previo.
  2. En el menú de la consola IBM Cloud Icono de menú, 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.

Actualización de las versiones (tipos de máquina)

Antes de empezar:

Para actualizar las versiones:

  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.
      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.
      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 o VPC.
      • Clústeres clásicos:
        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:
        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. Elimine el nodo trabajador antiguo. Nota: Si va a eliminar una versión que se factura mensualmente (como las nativas), se le facturará todo el mes.

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

¿Cómo se reduce la escala de las agrupaciones de nodos trabajadores?

Cuando disminuye el número de nodos trabajadores en una agrupación de nodos trabajadores, como por ejemplo durante una actualización de nodo trabajador o con el mandato ibmcloud ks worker-pool resize, los nodos trabajadores se priorizan para su supresión basándose en varias propiedades, incluido el estado, la salud y la versión.

Esta lógica de prioridad no es relevante para el complemento del programa de escalado automático.

En la tabla siguiente se muestra el orden en el que se prioriza la supresión de los nodos trabajadores.

Puede ejecutar el mandato ibmcloud ks worker ls para ver todas las propiedades de nodo trabajador listadas en la tabla.

Prioridad para los nodos trabajadores suprimidos durante la reducción de la agrupación de nodos trabajadores.
Prioridad Propiedad Descripción
1 Estado del nodo trabajador Los nodos trabajadores en estados que no funcionan o que funcionan mal se priorizan para su eliminación. Esta lista muestra los estados ordenados de la prioridad más alta a la más baja: provision_failed, deploy_failed, deleting, provision_pending, provisioning, deploying, provisioned, reloading_failed, reloading, deployed.
2 Salud del nodo de trabajador Los nodos trabajadores en mal estado se priorizan sobre los nodos trabajadores en buen estado. Esta lista muestra los estados de salud ordenados de mayor a menor prioridad: critical, warning, pending, unsupported, normal.
3 Versión de nodo trabajador Los nodos trabajadores que se ejecutan en versiones anteriores tienen una prioridad más alta para su supresión.
4 Entorno de colocación elegido Sólo para trabajadores que se ejecutan en un host dedicado. Los nodos trabajadores que se ejecutan en un host dedicado que tiene la opción DesiredPlacementDisabled establecida en true tienen una prioridad más alta para su supresión.
5 orden alfabético Después de priorizar los nodos de trabajador basándose en los factores listados anteriormente, se suprimen por orden alfabético. Tenga en cuenta que, basándose en los convenios de ID de nodo trabajador, los ID de los trabajadores de los clústeres clásicos y de VPC se correlacionan con la edad, por lo que los nodos trabajadores más antiguos se eliminan primero.

Actualización de los componentes de un clúster

El clúster de IBM Cloud Kubernetes Service se suministra con componentes, como Ingress, que se instalan automáticamente cuando se suministra el clúster. De forma predeterminada, IBM actualiza automáticamente estos componentes. No obstante, puede inhabilitar las actualizaciones automáticas de algunos componentes y actualizarlos manualmente de forma independiente de los nodos maestro y trabajador.

¿Qué componentes por defecto puedo actualizar independientemente del clúster?
Opcionalmente, puede inhabilitar las actualizaciones automáticas para los componentes siguientes:
¿Hay componentes que no pueda actualizar por separado del clúster?
Sí. El clúster se despliega con los siguientes componentes gestionados y recursos asociados que no se pueden cambiar, excepto para escalar pods o editar mapas de configuración para obtener determinadas mejoras de rendimiento. Si intenta modificar uno de estos componentes de despliegue, se restauran sus valores originales con un intervalo regular cuando se actualizan con el clúster maestro. Sin embargo, tenga en cuenta que los recursos que cree asociados a dichos componentes, como las políticas de red de Calico que cree para que las implementen los componentes de despliegue de Calico, no se actualizan.
  • Componentes de calico
  • Componentes de coredns
  • ibm-cloud-provider-ip
  • ibm-file-plugin
  • ibm-keepalived-watcher
  • ibm-master-proxy
  • ibm-storage-watcher
  • Componentes de kubernetes-dashboard
  • metrics-server
  • Componentes de olm-operator y catalog (1.16 y posterior)
  • vpn
¿Puedo instalar otros plug-ins o complementos además de los componentes por defecto?
Sí. IBM Cloud Kubernetes Service proporciona otros plugins y complementos que puede seleccionar para añadir prestaciones al clúster. Por ejemplo, quizás desee utilizar diagramas de Helm para instalar el complemento de almacenamiento en bloque o strongSwan VPN. O bien, es posible que desee habilitar complementos gestionados por IBM en el clúster, como por ejemplo Istio. Debe actualizar estos diagramas de Helm y complementos por separado, siguiendo las instrucciones de los archivos readme de los diagramas de Helm o siguiendo los pasos para actualizar complementos gestionados.

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.

Puede gestionar las actualizaciones automáticas del componente Fluentd de las maneras siguientes. Nota: Para ejecutar los siguientes comandos, debe tener la función de acceso a la plataforma Administrador IBM Cloud IAM para el clúster.

  • Para comprobar si las actualizaciones automáticas están habilitadas, ejecute el mandato ibmcloud ks logging autoupdate get --cluster CLUSTER.
  • Desactive las actualizaciones automáticas ejecutando el comando ibmcloud ks logging autoupdate disable.
  • 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. Nota: los pods se actualizan a la última versión del componente Fluentd, pero Fluentd no se actualiza automáticamente. Mandato de ejemplo

      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.

Actualización de complementos gestionados

Los complementos de clúster gestionados de IBM Cloud Kubernetes Service son una forma sencilla de mejorar su clúster con capacidades de código abierto, como Istio. La versión de la herramienta de código abierto que añade al clúster se prueba en IBM y se aprueba para ser utilizada en IBM Cloud Kubernetes Service. Para actualizar los complementos gestionados que ha habilitado en el clúster a las últimas versiones, consulte Actualización de complementos gestionados.