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 comandobmctl 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 comandobmctl 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 de192.168.122.0/23
(512 direcciones), en lugar del CIDR predeterminado192.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 usachmod
para otorgar abmctl
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
a1.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.- 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.
- Haz referencia a las claves JSON descargadas en los campos asociados
gkeConnectAgentServiceAccountKeyPath
ygkeConnectRegisterServiceAccountKeyPath
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 comandobmctl 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
es5
, 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 deconcurrentNodes
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.