En este documento, se describen las prácticas recomendadas y consideraciones para actualizar GKE en Bare Metal. Aprenderás a prepararte para las actualizaciones de clústeres y las prácticas recomendadas a seguir antes de la actualización. Estas prácticas recomendadas ayudan a reducir los riesgos asociados con las actualizaciones de los clústeres.
Si tienes varios entornos, como test, development y production, te recomendamos que comiences con el entorno menos crítico, como test, y verifiques la funcionalidad de actualización. Después de verificar que la actualización se realizó de forma correcta, continúa con el siguiente entorno. Repite este proceso hasta que actualices los entornos de producción. Este enfoque te permite pasar de un punto crítico al siguiente y verificar que la actualización y tus cargas de trabajo se ejecuten de forma correcta.
Lista de tareas de actualización
Te sugerimos que sigas todas las prácticas recomendadas de este documento. Usa la siguiente lista de tareas para hacer un seguimiento de tu progreso. Cada elemento de la lista se vincula a una sección de este documento con más información:
Una vez completadas estas verificaciones, puedes iniciar el proceso de actualización. Supervisa el progreso hasta que todos los clústeres se actualicen de forma correcta.
Planifica la actualización
Las actualizaciones pueden ser invasivas. Antes de comenzar la actualización, planifica con cuidado para asegurarte de que el entorno y las aplicaciones estén listos y preparados.
Estima el compromiso de tiempo y planifica un período de mantenimiento
La cantidad de tiempo que lleva actualizar un clúster varía según la cantidad de nodos y la densidad de la carga de trabajo que se ejecuta en ellos. Para completar de forma correcta una actualización de clúster, usa un período de mantenimiento con tiempo suficiente.
Para calcular una estimación aproximada de la actualización, usa 10 minutes * the number of
nodes en la actualización de un solo nodo simultáneo.
Por ejemplo, si tienes cincuenta nodos en un clúster, el tiempo de actualización total sería de alrededor de quinientos minutos: 10 minutes * 50 nodes = 500 minutes.
Verifica la compatibilidad de otros componentes de Anthos
Si el clúster ejecuta componentes de Anthos, como Anthos Service Mesh o Config Management, comprueba la matriz de compatibilidad de Anthos y verifica las versiones compatibles con GKE en Bare Metal antes y después de la actualización.
La verificación de compatibilidad se basa en el clúster de administrador o de usuario en el que se implementa Anthos Service Mesh o Config Management.
Verifica el uso de recursos del clúster
Verifica el uso actual de recursos del clúster a fin de asegurarte de que los Pods se puedan evacuar cuando se desvíe el nodo y de que haya suficientes recursos en el clúster que se está actualizando para administrar la actualización. Para verificar el uso de recursos de tu clúster, usa los paneles personalizados de Google Cloud's operations suite.
Puedes usar comandos, como kubectl top nodes, para obtener el uso actual de los recursos del clúster, pero los paneles pueden proporcionar una vista más detallada de los recursos que se consumen con el tiempo. Estos datos de uso de recursos pueden ayudar a indicar cuándo una actualización causaría la menor interrupción, por ejemplo, durante los fines de semana o las noches, según la carga de trabajo en ejecución y los casos de uso.
El tiempo de actualización del clúster de administrador puede ser menos crítico que el de los clústeres de usuario, ya que la actualización de un clúster de administrador no suele generar tiempo de inactividad en la aplicación. Sin embargo, sigue siendo importante verificar los recursos gratuitos antes de comenzar una actualización del clúster de administrador. Además, la actualización del clúster de administrador puede implicar cierto riesgo y, por lo tanto, se recomienda durante períodos de uso menos activos cuando el acceso de administración al clúster es menos crítico.
Recursos del plano de control del clúster de administrador
Todos los trabajos y controladores de actualización se ejecutan en los nodos del plano de control del clúster de administrador. Verifica el consumo de recursos de estos nodos del plano de control para conocer los recursos de procesamiento disponibles. Por lo general, el proceso de actualización requiere 1,000 millicores de CPU (1,000 mCPU) y de 2 a 3 GiB de RAM para cada conjunto de controladores del ciclo de vida. Ten en cuenta que la unidad de CPU “mCPU” significa “milésima de un núcleo” y, por lo tanto, 1,000 millicores equivalen a un núcleo en cada nodo para cada conjunto de controladores del ciclo de vida. Para reducir los recursos de procesamiento adicionales requeridos durante una actualización, intenta mantener los clústeres de usuario en la misma versión.
En la siguiente implementación de ejemplo, los dos clústeres de usuario se encuentran en versiones diferentes a las del clúster de administrador:
| Clúster de administrador | Clúster de usuario 1 | Clúster de usuario 2 |
|---|---|---|
| 1.13.3 | 1.13.0 | 1.13.2 |
En el controlador de administrador, se implementa un conjunto de controladores de ciclo de vida para cada versión en uso. En este ejemplo, hay tres conjuntos de controladores de ciclo de vida: 1.13.3, 1.13.0 y 1.13.2. Cada conjunto de controladores de ciclo de vida consume un total de 1,000 mCPU y 3 GiB de RAM. El consumo total actual de recursos de estos controladores de ciclo de vida es de 3,000 mCPU y 9 GiB de RAM.
Si el clúster de usuario 2 se actualiza a 1.13.3, ahora hay dos conjuntos de controladores del ciclo de vida: 1.13.3 y 1.13.0:
| Clúster de administrador | Clúster de usuario 1 | Clúster de usuario 2 |
|---|---|---|
| 1.13.3 | 1.13.0 | 1.13.3 |
Los controladores de ciclo de vida ahora consumen un total de 2,000 mCPU y 6 GiB de RAM.
Si el clúster de usuario 1 se actualiza a 1.13.3, la flota ahora se ejecutará en la misma versión: 1.13.3:
| Clúster de administrador | Clúster de usuario 1 | Clúster de usuario 2 |
|---|---|---|
| 1.13.3 | 1.13.3 | 1.13.3 |
Ahora solo hay un conjunto de controladores de ciclo de vida que consumen un total de 1, 000 mCPU y 3 GiB de RAM.
En el siguiente ejemplo, todos los clústeres de usuario son de la misma versión. Si se actualiza el clúster de administrador, solo se usan dos conjuntos de controladores del ciclo de vida, por lo que se reduce el consumo de recursos de procesamiento:
| Clúster de administrador | Clúster de usuario 1 | Clúster de usuario 2 |
|---|---|---|
| 1.14.0 | 1.13.3 | 1.13.3 |
En este ejemplo, los controladores de ciclo de vida vuelven a consumir un total de 2,000 mCPU y 6 GiB de RAM hasta que todos los clústeres de usuario se actualizan a la misma versión que el clúster de administrador.
Si los nodos del plano de control no tienen recursos de procesamiento adicionales durante la actualización, es posible que veas Pods como anthos-cluster-operator, capi-controller-manager, cap-controller-manager o cap-kubeadm-bootstraper en estado Pending. Para resolver este problema, actualiza algunos de los clústeres de usuario a la misma versión a fin de consolidar las versiones y reducir la cantidad de controladores del ciclo de vida en uso. Si tu actualización ya está bloqueada, también puedes usar kubectl edit deployment para editar las implementaciones pendientes a fin de reducir las solicitudes de CPU y RAM, de modo que se ajusten al plano de control del clúster de administrador.
En la siguiente tabla, se detallan los requisitos de los recursos de procesamiento para diferentes situaciones de actualización:
| Clúster | Los recursos del clúster de administrador son obligatorios |
|---|---|
| Actualización del clúster de usuario | Actualiza a la misma versión de otros clústeres: N/A Actualiza a una versión diferente de otros clústeres de administrador o de usuario: 1,000 mCPU y 3 GiB de RAM Los clústeres de usuario de un clúster híbrido tienen los mismos requisitos de recursos. |
| Actualización del clúster de administrador (con clúster de usuario) | 1,000 mCPU y 3 GiB de RAM |
| Actualización del clúster híbrido (sin clúster de usuario) | Aumento de 1,000 mCPU y 3 GiB de RAM. Los recursos se muestran después de su uso. |
| Independiente | Aumento de 200 mCPU y 1 GiB de RAM. Los recursos se muestran después de su uso. |
Crea una copia de seguridad de los clústeres
Antes de iniciar una actualización, crea una copia de seguridad de los clústeres con el comando bmctl backup cluster.
Debido a que el archivo de copia de seguridad contiene información sensible, almacénalo de forma segura.
Verifica que los clústeres estén configurados y funcionen correctamente
Para verificar el estado de un clúster antes de una actualización, ejecuta bmctl check cluster en el clúster. El comando ejecuta verificaciones avanzadas, como para identificar los nodos que no están configurados de forma correcta o que tienen Pods que están atascados.
Cuando ejecutas el comando bmctl upgrade cluster para actualizar los clústeres, se ejecutan algunas comprobaciones preliminares. El proceso de actualización se detiene si estas verificaciones no se realizan de forma correcta. Es mejor identificar y solucionar estos problemas de forma proactiva con el comando bmctl check cluster, en lugar de depender de las comprobaciones previas que existen para proteger los clústeres de cualquier posible daño.
Revisa las implementaciones de cargas de trabajo del usuario
Hay dos áreas que se deben considerar para las cargas de trabajo de los usuarios: el desvío y la compatibilidad con las APIs.
Vaciado de cargas de trabajo
La carga de trabajo del usuario en un nodo se vacía durante una actualización. Si la carga de trabajo tiene una sola réplica o todas las réplicas están en el mismo nodo, el vaciado de cargas de trabajo puede causar interrupciones en los servicios que se ejecutan en el clúster. Ejecuta tus cargas de trabajo con varias réplicas. El número de réplica debe ser superior al número de nodo simultáneo.
Para evitar una actualización detenida, el proceso de desvío de actualización hasta la 1.14 no respeta los presupuestos de interrupción de Pods (PDB). Las cargas de trabajo pueden ejecutarse en un estado degradado y la menor réplica de entrega sería total
replica number - concurrent upgrade number.
Compatibilidad de API
Para la compatibilidad de la API, verifica la compatibilidad de la API de la carga de trabajo con la versión secundaria más reciente de Kubernetes cuando actualices la versión secundaria. Si es necesario, actualiza la carga de trabajo a una versión compatible. Cuando sea posible, el equipo de ingeniería de Anthos proporcionará instrucciones para identificar las cargas de trabajo mediante APIs incompatibles, como las APIs de Kubernetes 1.22 obsoletas.
Si usas Anthos Service Mesh, Config Management o algún otro componente de GKE Enterprise, verifica si la versión instalada es compatible con la versión nueva de GKE en Bare Metal. Para obtener información sobre la compatibilidad de la versión de los componentes de GKE Enterprise, consulta Asistencia para la versión y la actualización de Anthos.
Audita el uso de webhooks
Verifica si el clúster tiene webhooks, en especial, recursos de Pod para fines de auditoría, como el controlador de políticas. El proceso de desvío durante la actualización del clúster puede interrumpir el servicio de webhook del controlador de políticas, lo que puede hacer que la actualización se detenga o tarde mucho tiempo. Te recomendamos que inhabilites estos webhooks de manera temporal o uses una implementación con alta disponibilidad (HA).
Cómo revisar el uso de las funciones de versión preliminar
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.
Comprueba el estado de 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.
No cambies la configuración de 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. No intentes cambiar la configuración de densidad del Pod durante una actualización.
Asegúrate de que los nodos del plano de control y del balanceador de cargas no estén en modo de mantenimiento
Asegúrate de que los nodos del plano de control y del balanceador de cargas no estén en mantenimiento antes de iniciar una actualización. Si algún nodo está en modo de mantenimiento, la actualización se detiene para garantizar que los grupos de nodos del plano de control y del balanceador de cargas estén lo suficientemente disponibles.
¿Qué sigue?
- Actualiza los clústeres de Anthos alojados en Bare Metal
- Obtén más información sobre el ciclo de vida y las etapas de las actualizaciones.
- Soluciona problemas de actualización de clústeres