Comprobar si hay una actualización de versión disponible con la CLI de IBM Cloud

1. Inicie sesión en IBM Cloud. Incluya la opción --sso si tiene una cuenta federada.

   ibmcloud login [--sso]
   

2. Liste los clústeres de Satellite de su cuenta.

   ibmcloud ks cluster ls --provider satellite
   

3. Liste los nodos de trabajador en el clúster cuya versión desee actualizar. En la salida, compruebe si hay un asterisco (*) con un mensaje que indique que hay disponible una actualización de versión.

   ibmcloud ks worker ls -c CLUSTER_NAME_OR_ID
   

   Salida de ejemplo

   ID                Primary IP       Flavor   State    Status   Zone     Version   
   sat-worker-<ID>   <IP_address>     upi      normal   Ready    zone-1   4.5.35_1534_openshift*   
   * To update to 4.5.37_1537_openshift version, run 'ibmcloud ks worker replace'. Review and make any required version changes before you update: 'https://ibm.biz/upworker'
   

Comprobar si hay una actualización de versión disponible desde la consola de IBM Cloud

1. Inicie sesión en la consola deSatellite.
2. Pulse en la ubicación que tenga los hosts que desee actualizar.
3. Pulse en la pestaña Hosts.
4. En la lista de hosts, pulse en el enlace al Clúster del host que desee actualizar. Se abrirá una nueva pestaña con los detalles del clúster de Red Hat OpenShift on IBM Cloud.
5. Pulse en la pestaña Nodos de trabajador.
6. En la columna Versión, busca un icono de información que indique Update available al hacer clic en él. Si no hay ninguna actualización disponible, no habrá ningún icono.
7. Determine si la actualización de versión es una actualización principal, menor o de parche.

Aplicar actualizaciones de versión a los hosts de nodo trabajador de uno en uno

1. Opcional: Conecte y asigne hosts adicionales al clúster de servicio para manejar la capacidad de cálculo mientras se actualizan los hosts existentes.

2. Identifique los hosts de nodo trabajador. Los hosts de nodo trabajador no tienen infrastructure listados en la columna Cluster de la salida, sino que tienen el nombre del clúster.

3. Actualice los nodos trabajadores individualmente ejecutando el mandato ibmcloud ks worker update.

   ibmcloud ks worker update -c CLUSTER_NAME_OR_ID --worker WORKER_ID
   

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

   kubectl get nodes
   

   Si la actualización ha fallado, debe aplicar actualizaciones de versión sustituyendo hosts.

Aplique actualizaciones de versión a los hosts de nodo trabajador con un ConfigMap

Puede desplegar actualizaciones en todos los hosts de nodo trabajador con un ConfigMap. Especifique qué nodos se deben actualizar utilizando etiquetas. También puede especificar

1. Opcional: Conecte y asigne hosts adicionales al clúster de servicio para manejar la capacidad de cálculo mientras se actualizan los hosts existentes.

2. Identifique los hosts de nodo trabajador. Los hosts de nodo trabajador no se listan como Infrastructure.

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. Puede utilizar las etiquetas para especificar qué nodos de trabajador se deben actualizar.

   kubectl get nodes -o yaml
   

   Salida de ejemplo

   labels:
     arch: amd64
     beta.kubernetes.io/arch: amd64
     beta.kubernetes.io/instance-type: upi
     beta.kubernetes.io/os: linux
     failure-domain.beta.kubernetes.io/region: us-east
     failure-domain.beta.kubernetes.io/zone: us-east-2
     ibm-cloud.kubernetes.io/iaas-provider: upi
     ibm-cloud.kubernetes.io/internal-ip: 10.241.0.4
     ibm-cloud.kubernetes.io/machine-type: upi
     ibm-cloud.kubernetes.io/os: REDHAT_8_64
     ibm-cloud.kubernetes.io/region: us-east
     ibm-cloud.kubernetes.io/worker-id: sat-satellitei-5bd83963cdfedc7668c9040879c88113a134c4e7
     ibm-cloud.kubernetes.io/worker-pool-id: cbtljodw089nltg8k210-9a3f763
     ibm-cloud.kubernetes.io/worker-pool-name: default
     ibm-cloud.kubernetes.io/worker-version: 4.7.59_1583_openshift
     ibm-cloud.kubernetes.io/zone: us-east-2
     kubernetes.io/arch: amd64
     kubernetes.io/hostname: satellite-ibm-host-3
     kubernetes.io/os: linux
     node-role.kubernetes.io/master: ""
     node-role.kubernetes.io/worker: ""
     node.kubernetes.io/instance-type: upi
     node.openshift.io/os_id: rhel
     privateVLAN: "1"
     topology.kubernetes.io/region: us-east
     topology.kubernetes.io/zone: us-east-2
   

4. Crea un ConfigMap y define las reglas de indisponibilidad para tus nodos de trabajo. El siguiente ejemplo muestra dos comprobaciones, la defaultcheck.json y una plantilla de comprobación. Puede utilizar esta comprobación de ejemplo para definir reglas para todos los nodos trabajadores que no coincidan con ninguna de las comprobaciones que ha definido en ConfigMap (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. Define hasta 10 comprobaciones en un ConfigMap. Si añade más comprobaciones, se pasan por alto.

   Ejemplo

   apiVersion: v1
   kind: ConfigMap
   metadata:
     name: ibm-cluster-update-configuration
     namespace: kube-system
   data:
     drain_timeout_seconds: "120"
     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.

   defaultcheck.json

   Cuando actualiza nodos trabajadores en hosts de Satellite, solo el 20% de los nodos trabajadores del clúster pueden no estar disponibles a la vez.

   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.

   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. Comprueba que se haya creado el ConfigMap.

   kubectl get configmap --namespace kube-system
   

7. Actualice los nodos trabajadores listándolos por ID.

   ibmcloud ks worker update --cluster <cluster_name_or_ID> --worker <worker_node1_ID> --worker <worker_node2_ID>
   

8. Opcional: Comprueba los eventos que activa el servicio ConfigMap y los posibles 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
   

   Si la actualización ha fallado, debe aplicar actualizaciones de versión sustituyendo hosts.

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.