Actualiza los clústeres

Cuando instalas una versión nueva de bmctl, puedes actualizar los clústeres existentes que se crearon con una versión anterior. Actualizar un clúster a la versión más reciente de GKE en Bare Metal proporciona funciones adicionales y correcciones a tu clúster. También garantiza que tu clúster permanezca compatible. Puedes actualizar los clústeres de administrador, híbrido, independiente o de usuario con el comando de bmctl upgrade cluster.

Consideraciones sobre la actualización

En las siguientes secciones, se describen las reglas y las prácticas recomendadas que debes tener en cuenta antes de actualizar un clúster.

Funciones de vista previa

Las funciones de vista previa están sujetas a cambios y se proporcionan solo con fines de prueba y evaluación. No uses funciones de vista previa en tus clústeres de producción. No garantizamos que los clústeres que usan características de vista previa se puedan actualizar. En algunos casos, bloqueamos de forma explícita las actualizaciones para los clústeres que usan las funciones de vista previa.

Para obtener información sobre los cambios rotundos relacionados con las actualizaciones, consulta las notas de la versión.

SELinux

Si deseas habilitar SELinux para proteger tus contenedores, debes asegurarte de que SELinux esté habilitado en el modo Enforced en todas tus máquinas anfitrión. A partir de la versión 1.9.0 o posterior de GKE en Bare Metal, puedes habilitar o inhabilitar SELinux antes o después de la creación de un clúster o sus actualizaciones. SELinux está habilitado de forma predeterminada en Red Hat Enterprise Linux (RHEL) y CentOS. Si SELinux está inhabilitado en tus máquinas anfitrión o no estás seguro, consulta Protege tus contenedores con SELinux a fin de obtener instrucciones para habilitarlo.

GKE en Bare Metal admite SELinux solo en los sistemas RHEL y CentOS.

Actualiza las comprobaciones preliminares

Las verificaciones previas se ejecutan como parte de la actualización del clúster para validar el estado de los clústeres y los nodos. La actualización del clúster no continúa si las verificaciones previas fallan. Para obtener más información sobre las comprobaciones preliminares, consulta Comprende las comprobaciones preliminares.

A fin de verificar si los clústeres están listos para una actualización, ejecuta la verificación previa antes de ejecutar la actualización. Para obtener más información, consulta Verificaciones previas de actualizaciones.

Cantidad de nodos

Si tu clúster tiene más de 51 nodos, la operación de actualización estándar, que usa un clúster de arranque, es susceptible a fallas. Las fallas se deben a la cantidad limitada de direcciones IP del Pod asignadas al clúster de arranque. El rango de direcciones IP predeterminado disponible para los Pods del clúster de arranque usa una máscara de /24 en la notación de bloques CIDR.

Existen dos soluciones para esta situación:

(Recomendado) Usa la marca --use-bootstrap=false con el comando bmctl upgrade cluster para realizar una actualización in situ. Esta marca hace que la actualización omita por completo el clúster de arranque y la limitación de la dirección del Pod relacionada. Ten en cuenta que existe un problema conocido de actualización local para los clústeres de la versión 1.13.0. Si tu clúster está en la versión 1.13.0, consulta el problema conocido para obtener una solución alternativa y más información.
Usa la marca --bootstrap-cluster-pod-cidr con el comando bmctl upgrade cluster para aumentar la cantidad de direcciones IP del Pod asignadas al clúster de arranque. Por ejemplo, cuando especificas --bootstrap-cluster-pod-cidr=192.168.122.0/23, los Pods que se ejecutan en la operación de actualización pueden usar direcciones IP de 192.168.122.0/23 (512 direcciones), en lugar del CIDR predeterminado 192.168.122.0/24 (256 direcciones). Estas direcciones agregadas deben desbloquear las actualizaciones para los clústeres con un máximo de 52 nodos.

Como máximo, la cantidad de pods que se ejecutan de forma simultánea durante una actualización puede ser cinco veces la cantidad de nodos. Para asegurarte de que la actualización se realice correctamente, especifica un bloque CIDR que contenga una cantidad de direcciones IP que sea cinco veces la cantidad de nodos. Esta marca requiere direcciones IP internas.
Si no quieres usar ninguna de las opciones anteriores, puedes usar la marca --skip-bootstrap-cidr-check para omitir la validación. Sin embargo, pasar este argumento significa que la actualización podría fallar debido a que no hay suficientes direcciones IP disponibles en el CIDR del Pod para el clúster de arranque.

Actualizaciones locales para clústeres autoadministrados

A partir de la versión 1.13.1 de GKE en Bare Metal, puedes realizar actualizaciones in situ en clústeres de administrador, híbridos e independientes. Una actualización en un solo lugar elimina la necesidad de un clúster de arranque, lo que simplifica el proceso y reduce los requisitos de recursos para una actualización. Antes de que puedas realizar una actualización en un solo lugar en tu clúster autoadministrado, debe estar en la versión 1.13.0 o superior.

Para realizar una actualización en un solo lugar, puedes usar bmctl o kubectl:

`bmctl`

El proceso de actualización es idéntico al proceso de actualización estándar, excepto para el comando bmctl upgrade cluster.

Para iniciar la actualización en un solo lugar, usa la marca --use-bootstrap=false con el siguiente comando de actualización:
```
bmctl upgrade cluster -c CLUSTER_NAME --use-bootstrap=false \
    --kubeconfig ADMIN_KUBECONFIG
```
Reemplaza lo siguiente:
- CLUSTER_NAME: el nombre del clúster que se actualizará
- ADMIN_KUBECONFIG: la ruta al archivo kubeconfig del clúster de administrador.

Al igual que con el proceso de actualización estándar, las verificaciones de solicitudes preliminares se ejecutan como parte de la actualización del clúster para validar el estado del nodo. Si las comprobaciones previas fallan, la actualización del clúster se detiene. Para solucionar cualquier error, examina el clúster y los registros relacionados, ya que no se crea ningún clúster de arranque.

`kubectl`

Para actualizar un clúster autoadministrado con kubectl, sigue estos pasos:

Edita el archivo de configuración del clúster para establecer anthosBareMetalVersion en la versión de destino de la actualización.
Para iniciar la actualización, ejecuta el siguiente comando:
```
kubectl apply -f CLUSTER_CONFIG_PATH
```
Reemplaza CLUSTER_CONFIG_PATH por la ruta de acceso al archivo kubeconfig del clúster.

Al igual que con el proceso de actualización estándar, las verificaciones previas se ejecutan como parte de la actualización del clúster para validar el estado de los nodos. Si las comprobaciones previas fallan, la actualización del clúster se detiene. Para solucionar cualquier error, examina el clúster y los registros relacionados, ya que no se crea ningún clúster de arranque.

Densidad del Pod

GKE en Bare Metal admite la configuración de hasta 250 Pods por nodo con nodeConfig.PodDensity.MaxPodsPerNode. Solo puedes configurar la densidad del pod durante la creación del clúster. No puedes actualizar la configuración de la densidad del pod para los clústeres existentes.

Problemas conocidos

Para obtener información sobre posibles problemas relacionados con las actualizaciones de clústeres, consulta Actualiza los clústeres de Anthos en equipos físicos en la página Problemas conocidos.

Actualiza clústeres de administrador, independiente, híbrido o de usuario

Cuando descargas e instalas una versión nueva de bmctl, puedes actualizar tus clústeres de administrador, híbridos, independientes y de usuario creados con una versión anterior. Para una versión determinada de bmctl, un clúster solo se puede actualizar a la misma versión.

Primero, descarga el bmctl más reciente, luego modifica los archivos de configuración del clúster apropiados y, luego, emite el comando bmctl upgrade cluster para completar la actualización.

Descarga el bmctl más reciente del bucket de Cloud Storage y usa chmod para otorgar a bmctl permisos de ejecución a todos los usuarios:
```
gsutil cp gs://anthos-baremetal-release/bmctl/1.14.11/linux-amd64/bmctl bmctl
chmod a+x bmctl
```

Modifica el archivo de configuración del clúster para cambiar la versión del clúster de GKE en Bare Metal de 1.13.2 a 1.14.11. A continuación, se muestra un ejemplo de una configuración de clúster de administrador:

---
apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: cluster1
  namespace: cluster-cluster1
spec:
  # Cluster type. This can be:
  #   1) admin:  to create an admin cluster. This can later be used to create user clusters.
  #   2) user:   to create a user cluster. Requires an existing admin cluster.
  #   3) hybrid: to create a hybrid cluster that runs admin cluster components and user workloads.
  #   4) standalone: to create a cluster that manages itself, runs user workloads, but does not manage other clusters.
  type: admin
  # Anthos cluster version.
  # Change the following line from 1.13.2 to 1.14.11, shown below
  anthosBareMetalVersion: 1.14.11

Cuando actualizas clústeres a 1.14.11, debes registrar los clústeres con Connect en la flota de tu proyecto, si aún no se registran.
1. Crea cuentas de servicio de forma manual y recupera los archivos de claves JSON como se describe en Configura cuentas de servicio para usar con Connect en la página Habilita servicios de Google y cuentas de servicio.
2. Haz referencia a las claves JSON descargadas en los campos asociados gkeConnectAgentServiceAccountKeyPath y gkeConnectRegisterServiceAccountKeyPath del archivo de configuración del clúster.
Usa el comando de bmctl upgrade cluster para completar la actualización:
```
bmctl upgrade cluster -c CLUSTER_NAME --kubeconfig ADMIN_KUBECONFIG
```
Reemplaza lo siguiente:
- CLUSTER_NAME: el nombre del clúster que se actualizará
- ADMIN_KUBECONFIG la ruta al archivo kubeconfig del clúster de administrador
Las verificaciones previas se ejecutan como parte de la actualización del clúster para validar el estado de los clústeres y los nodos. La actualización del clúster no continúa si las verificaciones previas fallan.

Actualizaciones en paralelo de nodos

En una actualización típica de un clúster, cada nodo del clúster se actualiza de forma secuencial, uno tras otro. En esta sección, se muestra cómo configurar tu clúster para que varios nodos se actualicen en paralelo cuando actualices tu clúster.

La actualización de nodos en paralelo acelera las actualizaciones de los clústeres, en especial para los que tienen cientos de nodos. Las actualizaciones paralelas de los nodos se configuran por grupo de nodos, y solo los nodos de un grupo de nodo trabajador se pueden actualizar en paralelo. Los nodos del plano de control o los grupos de nodos del balanceador de cargas solo se pueden actualizar uno a la vez.

Las actualizaciones paralelas de nodos trabajadores son una función de versión preliminar, así que no la uses en tus clústeres de producción.

Cómo realizar una actualización paralela

Para realizar una actualización paralela de nodos en un grupo de nodo trabajador, haz lo siguiente:

Agrega la anotación preview.baremetal.cluster.gke.io/parallel-upgrade: "enable" al archivo de configuración del clúster:

---
gcrKeyPath: /path/to/gcr-sa
gkeConnectAgentServiceAccountKeyPath: /path/to/gke-connect
gkeConnectRegisterServiceAccountKeyPath: /path/to/gke-register
sshPrivateKeyPath: /path/to/private-ssh-key
cloudOperationsServiceAccountKeyPath: /path/to/logging-sa
---
apiVersion: v1
kind: Namespace
metadata:
  name: cluster-cluster1
---
apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: cluster1
  namespace: cluster-cluster1
  annotations:
    baremetal.cluster.gke.io/maintenance-mode-deadline-seconds: "180"
    preview.baremetal.cluster.gke.io/parallel-upgrade: "enable"
    ...

Agrega una sección upgradeStrategy al manifiesto del grupo de nodo trabajador. Este manifiesto debe estar en el archivo de configuración del clúster. Si aparece en un archivo de manifiesto independiente, el comando bmctl upgrade cluster no actuará sobre él. Por ejemplo:
```
---
apiVersion: baremetal.cluster.gke.io/v1
kind: NodePool
metadata:
  name: np1
  namespace: cluster-ci-bf8b9aa43c16c47
spec:
  clusterName: ci-bf8b9aa43c16c47
  nodes:
  - address:  10.200.0.7
  - address:  10.200.0.8
  - address:  10.200.0.9
  upgradeStrategy:
    parallelUpgrade:
      concurrentNodes: 5
  
```
En este ejemplo, el valor del campo concurrentNodes es 5, lo que significa que se actualizarán 5 nodos en paralelo. El valor mínimo (y predeterminado) de este campo es 1 y el valor máximo permitido es la cantidad de nodos en el grupo de nodo trabajador. Sin embargo, te recomendamos que configures este valor no más del 3% de la cantidad total de nodos en tu clúster. Si el valor de concurrentNodes es demasiado alto, las cargas de trabajo pueden verse comprometidas durante una actualización paralela.
Actualiza el clúster como se describe en la sección anterior Actualiza los clústeres de administrador, independientes, híbridos o de usuario.

Cómo inhabilitar las actualizaciones paralelas de nodos

Para inhabilitar las actualizaciones paralelas de los nodos, configura la anotación preview.baremetal.cluster.gke.io/parallel-upgrade como disable en el archivo de configuración del clúster.