En esta página, se explica cómo configurar determinados componentes de GKE On-Prem para alta disponibilidad (HA) y cómo recuperarse de los desastres.
Funcionalidad principal
GKE On-Prem está diseñado para garantizar que las fallas estén aisladas en un área funcional tanto como sea posible y priorizar la funcionalidad que es crítica para la continuidad empresarial.
La funcionalidad principal de GKE On-Prem tiene las siguientes categorías:
Ciclo de vida de la aplicación
Las cargas de trabajo existentes pueden ejecutarse de forma continua. Esta es la funcionalidad más importante para garantizar la continuidad del negocio.
Puedes crear, actualizar y borrar cargas de trabajo. Esta es la segunda funcionalidad más importante, ya que GKE On-Prem necesita escalar cargas de trabajo cuando el tráfico aumenta.
Ciclo de vida del clúster de usuario
Puedes agregar, actualizar, mejorar y borrar clústeres de usuario. Esto es menos importante porque la imposibilidad de modificar clústeres de usuarios no afecta las cargas de trabajo.
Ciclo de vida del clúster de administrador
Puedes actualizar y mejorar el clúster de administrador. Esto es lo menos importante debido a que el clúster de administrador no aloja ninguna carga de trabajo de usuario.
Modos de falla
Los siguientes tipos de fallas pueden afectar el rendimiento de los clústeres de GKE On-Prem.
Falla del host de ESXi
Un host de ESXi que ejecuta instancias de máquina virtual (VM) y aloja nodos de Kubernetes puede dejar de funcionar o convertirse en partición de la red.
| Cargas de trabajo existentes | Crea, actualiza y borra cargas de trabajo | Ciclo de vida de clúster de usuario | Ciclo de vida del clúster de administrador |
|---|---|---|---|
| Interrupción posible + recuperación automática |
Interrupción posible + recuperación automática |
Interrupción + recuperación automática |
Interrupción + recuperación automática |
Los Pods que se ejecutan en las VM alojadas en el host con errores se interrumpen y se reprograman automáticamente en otras VM en buen estado. Si las aplicaciones de usuario tienen capacidad de carga de trabajo libre y se distribuyen entre varios nodos, la interrupción no se puede observar para los clientes que implementan reintentos. |
Si la falla del host afecta la VM del plano de control en un clúster de usuario sin alta disponibilidad o más de una VM de plano de control en un clúster de usuario con alta disponibilidad, habrá interrupción. | Si la falla del host afecta la VM del plano de control o las VM de trabajador en el clúster de administrador, habrá interrupción. | Si la falla del host afecta la VM del plano de control en el clúster de administrador, habrá interrupción. |
| La alta disponibilidad de vSphere reinicia de forma automática las VM en hosts en buen estado. | La alta disponibilidad de vSphere reinicia de forma automática las VM en hosts en buen estado. | La alta disponibilidad de vSphere reinicia de forma automática las VM en hosts en buen estado. | La alta disponibilidad de vSphere reinicia de forma automática las VM en hosts en buen estado. |
| Implementa cargas de trabajo de alta disponibilidad para minimizar las posibilidades de interrupción. | Usa clústeres de usuario de alta disponibilidad para minimizar la posibilidad de interrupción. |
Falla de VM
Es posible que una VM se borre de forma inesperada o que un disco de arranque se dañe. Además, una VM puede verse comprometida debido a problemas del sistema operativo.
| Cargas de trabajo existentes | Crea, actualiza y borra cargas de trabajo | Ciclo de vida de clúster de usuario | Ciclo de vida del clúster de administrador |
|---|---|---|---|
| Interrupción posible + recuperación automática |
Interrupción posible + recuperación automática |
Interrupción + recuperación automática o manual |
Interrupción + recuperación manual |
Los Pods que se ejecutan en las VM de trabajador con errores se interrumpen y Kubernetes los reprograma automáticamente en otras VM en buen estado. Si las aplicaciones de usuario tienen capacidad de carga de trabajo libre y se distribuyen entre varios nodos, la interrupción no se puede observar para los clientes que implementan reintentos. |
Si la VM del plano de control en un clúster de usuario sin alta disponibilidad o más de una VM de plano de control en un clúster de usuario con alta disponibilidad fallan, habrá interrupción. | Si la VM del plano de control o las VM de trabajador en el clúster de administrador fallan, habrá interrupción. | Si la VM del plano de control en el clúster de administrador falla, habrá interrupción. |
| La VM con errores se recupera automáticamente si se habilita la reparación automática del nodo en el clúster de usuarios. | La VM con errores se recupera automáticamente si la reparación automática de nodos está habilitada en el clúster del administrador. | La VM de trabajador con errores en el clúster de administrador se recupera de forma automática si la reparación automática de nodos está habilitada en el clúster de administrador. Debes recuperar de forma manual la VM del plano de control con errores en el clúster de administrador. Para obtener ayuda, comunícate con Atención al cliente de Google. |
Debes recuperar de forma manual la VM del plano de control con errores en el clúster de administrador. Para obtener ayuda, comunícate con el servicio de Atención al cliente de Google. |
| Implementa cargas de trabajo de alta disponibilidad para minimizar las posibilidades de interrupción. | Usa clústeres de usuario de alta disponibilidad para minimizar la posibilidad de interrupción. |
Falla de almacenamiento
El contenido de un archivo VMDK puede estar dañado debido a que el sistema no funciona correctamente o una falla del almacén de datos puede causar pérdida de datos etcd y PersistentVolumes (PV).
Falla de etcd
| Cargas de trabajo existentes | Crea, actualiza y borra cargas de trabajo | Ciclo de vida de clúster de usuario | Ciclo de vida del clúster de administrador |
|---|---|---|---|
| Sin interrupciones | Interrupción posible + recuperación manual |
Interrupción + recuperación manual |
Interrupción + recuperación manual |
| Si el almacenamiento de etcd en un clúster de usuario sin alta disponibilidad o más de una réplica de etcd en un clúster de usuario con alta disponibilidad falla, habrá interrupción. | Si el almacenamiento de etcd en un clúster de usuario sin alta disponibilidad o más de una réplica de etcd en un clúster de usuario con alta disponibilidad falla, habrá interrupción. Si la réplica de etcd en un clúster de administrador falla, habrá interrupción. |
Si la réplica de etcd en un clúster de administrador falla, habrá interrupción. | |
| GKE On-Prem proporciona un proceso manual para recuperarse de la falla. | GKE On-Prem proporciona un proceso manual para recuperarse de la falla. | GKE On-Prem proporciona un proceso manual para recuperarse de la falla. |
Falla de PV de la aplicación del usuario
| Cargas de trabajo existentes | Crea, actualiza y borra cargas de trabajo | Ciclo de vida de clúster de usuario | Ciclo de vida del clúster de administrador |
|---|---|---|---|
| Interrupción posible | Sin interrupciones | Sin interrupciones | Sin interrupciones |
Las cargas de trabajo que usan el PV con errores se ven afectadas. Implementa cargas de trabajo de alta disponibilidad para minimizar las posibilidades de interrupción. |
Falla del balanceador de cargas
Una falla del balanceador de cargas puede afectar las cargas de trabajo del usuario que exponen los servicios de tipo LoadBalancer.
| Cargas de trabajo existentes | Crea, actualiza y borra cargas de trabajo | Ciclo de vida de clúster de usuario | Ciclo de vida del clúster de administrador |
|---|---|---|---|
| Interrupción + recuperación manual |
|||
|
Habrá algunos segundos de interrupción hasta que el balanceador de cargas en espera recupere la conexión VIP del plano de control del administrador. La interrupción del servicio puede ser de hasta 2 segundos cuando se usa Seesaw y hasta 300 segundos cuando se usa F5. La alta disponibilidad de Seesaw detecta el error automáticamente y falla en el uso de la instancia de copia de seguridad. GKE On-Prem proporciona un proceso manual para recuperarse de una falla de Seesaw. |
|||
Habilita la alta disponibilidad
vSphere y GKE On-Prem proporcionan una serie de funciones que contribuyen a la alta disponibilidad (HA).
vSphere HA y vMotion
Te recomendamos que habilites las siguientes dos funciones en el clúster de vCenter que aloja tus clústeres de GKE On-Prem:
Estas características mejoran la disponibilidad y la recuperación en caso de que un host de ESXi falle.
La alta disponibilidad de vCenter usa varios hosts ESXi configurados como clústeres a fin de proporcionar una recuperación rápida de las interrupciones y una alta disponibilidad rentable para aplicaciones que se ejecutan en máquinas virtuales. Te recomendamos que aprovisiones el clúster de vCenter con hosts adicionales y habilites vSphere HA Host Monitoring con Host Failure Response configurado como Restart VMs. Las VM se pueden reiniciar de forma automática en otros hosts disponibles en caso de que falle el host de ESXi.
vMotion permite la migración en vivo de VM sin tiempo de inactividad de un host de ESXi a otro. Para el mantenimiento planificado del host, puedes usar la migración en vivo de vMotion a fin de evitar el tiempo de inactividad de la aplicación por completo y garantizar la continuidad del negocio.
Clúster de administrador
GKE On-Prem no admite la ejecución de varios planos de control para el clúster de administrador. Sin embargo, la falta de disponibilidad del plano de control del administrador no afecta la funcionalidad existente del clúster de usuarios ni las cargas de trabajo que se ejecuten en los clústeres de usuario.
Existen dos nodos de complementos en un clúster de administrador. Si una está inactiva, la otra aún puede entregar las operaciones del clúster de administrador. Para la redundancia, GKE On-Prem distribuye los servicios de complementos críticos, como kube-dns, en ambos nodos de complementos.
Si configuras antiAffinityGroups.enabled como true en el archivo de configuración de clústeres de administrador, GKE On-Prem crea de forma automática reglas de antiafinidad de vSphere DRS para el agregado en nodos locales, lo que genera que se distribuyan en dos hosts físicos para la alta disponibilidad.
Clúster de usuario
Puedes habilitar la lata disponibilidad en un clúster de usuarios si configuras masterNode.replicas como 3 en el archivo de configuración de clústeres de usuario. Esto da como resultado tres nodos en el clúster de administrador, cada uno de los cuales ejecuta un plano de control para el clúster de usuarios. Cada uno de esos nodos también ejecuta una réplica de etcd. El clúster de usuario continúa funcionando mientras haya un plano de control en ejecución y un quórum de etcd. Un quórum de etcd requiere que dos de las tres réplicas de etcd funcionen.
Si configuras antiAffinityGroups.enabled como true en el archivo de configuración de clústeres de administrador, GKE On-Prem crea de forma automática reglas de antiafinidad de vSphere DRS para los tres nodos que ejecutan el plano de control del clúster de usuarios.
Esto hace que esas VM se distribuyan en tres hosts físicos.
GKE On-Prem también crea reglas antiafinidad de vSphere DRS para los nodos trabajadores en tu clúster de usuario, lo que genera que esos nodos se propaguen en, al menos, tres hosts físicos. Se usan varias reglas de antiafinidad de DRS por grupo de nodos del clúster de usuario según la cantidad de nodos. Esto garantiza que los nodos trabajadores puedan encontrar hosts para ejecutar, incluso cuando la cantidad de hosts sea menor que la cantidad de VM en el grupo de nodos del clúster de usuario. Te recomendamos que incluyas hosts físicos adicionales en tu clúster de vCenter. Además, configura DRS para que esté automatizada por completo, de modo que en caso de que un host no esté disponible, DRS puede reiniciar automáticamente las VM en otros hosts disponibles sin infringir las reglas de antiafinidad de las VM.
GKE On-Prem mantiene una etiqueta de nodo especial, onprem.gke.io/failure-domain-name, cuyo valor se establece en el nombre de host de ESXi subyacente. Las aplicaciones de usuario que quieren alta disponibilidad pueden configurar reglas podAntiAffinity con esta etiqueta como topologyKey para garantizar que sus Pods de aplicación se distribuyan en diferentes VM y hosts físicos.
También puedes configurar varios grupos de nodos para un clúster de usuarios con diferentes almacenes de datos y etiquetas especiales de nodo. Del mismo modo, puedes configurar reglas de podAntiAffinity con esa etiqueta de nodo especial como topologyKey para lograr una mayor disponibilidad ante fallas del almacén de datos.
Para tener alta disponibilidad en las cargas de trabajo de usuario, asegúrate de que el clúster de usuarios tenga una cantidad suficiente de réplicas en nodePools.replicas, lo que garantiza la cantidad deseada de nodos trabajadores del clúster de usuario en la condición en ejecución.
Puedes usar almacenes de datos distintos para los clústeres de administración y los clústeres de usuarios a fin de aislar sus fallas.
Balanceador de cargas
Existen dos tipos de balanceadores de cargas que puedes usar para la alta disponibilidad.
Balanceador de cargas de Seesaw en paquetes
Para el elemento Balanceador de cargas de Seesaw en paquetes, puedes habilitar la alta disponibilidad mediante la configuración de loadBalancer.seesaw.enableHA como true en el archivo de configuración del clúster.
También debes habilitar una combinación de aprendizaje MAC, transmisiones falsificadas y el modo abundante en el grupo de puertos del balanceador de cargas.
Con la alta disponibilidad, se configuran dos balanceadores de cargas en modo activo/pasivo. Si el balanceador de cargas activo tiene un problema, el tráfico falla en el balanceador de cargas pasivo.
Durante una actualización de un balanceador de cargas, existe un tiempo de inactividad. Si la alta disponibilidad está habilitada en el balanceador de cargas, el tiempo de inactividad máximo es de dos segundos.
Balanceador de cargas BIG-IP de F5 integrado
La plataforma BIG-IP de F5 ofrece varios servicios para ayudarte a mejorar la seguridad, la disponibilidad y el rendimiento de tus aplicaciones. Para GKE On-Prem, BIG-IP proporciona acceso externo y servicios de balanceo de cargas L3/4.
Para obtener más información, consulta la alta disponibilidad de BIG-IP.
Recupera un clúster dañado
En las siguientes secciones, se describe cómo recuperar un clúster dañado.
Recuperación ante fallas del host de ESXi
GKE On-Prem se basa en HA de vSphere para proporcionar recuperación ante un error de host de ESXi. La HA de vSphere puede supervisar de forma continua los hosts de ESXi y reiniciar automáticamente las VM en otros hosts cuando sea necesario. Esto es transparente para los usuarios de GKE On-Prem.
Recuperación ante fallas de VM
Las fallas de VM pueden incluir lo siguiente:
Eliminación inesperada de una VM
El daño del disco de arranque de VM Por ejemplo, un disco de arranque se convirtió en solo lectura debido a los registros de diario de spam.
Falla en el inicio de VM debido a problemas de configuración de red o disco de bajo rendimiento. Por ejemplo, una VM no puede iniciarse porque no se le puede asignar una dirección IP por algún motivo.
Se dañó el sistema de archivos de superposición de Docker.
Pérdida de la VM del plano de control del administrador debido a una falla de actualización.
Problemas del sistema operativo
Las fallas de VM que se analizan en esta sección no incluyen el daño o la pérdida de datos en los discos de datos PV o etcd conectados a la VM. Para eso, consulta Recuperación ante fallas de almacenamiento.
GKE On-Prem proporciona un mecanismo de recuperación automático para los nodos de complementarios de administrador, los planos de control de usuario y los nodos de usuario. Esta función de reparación automática de nodos se puede habilitar por clúster de administrador y clúster de usuario.
La VM del plano de control del administrador es especial en el sentido de que no la administra un clúster de Kubernetes, y su disponibilidad no afecta la continuidad del negocio. Para recuperar las fallas de las VM del plano de control del administrador, comunícate con Atención al cliente de Google.
Recuperación ante fallas de almacenamiento
Algunas de las fallas de almacenamiento pueden mitigarse mediante HA de vSphere y vSAN sin afectar a GKE On-Prem. Sin embargo, algunas fallas de almacenamiento pueden aparecer a nivel de vSphere que provocan el daño o la pérdida de datos en varios componentes de GKE On-Prem.
La información con estado de un clúster y las cargas de trabajo de usuario se almacenan en los siguientes lugares:
etcd
Cada clúster (clúster de administrador y de usuario) tiene una base de datos de etcd que almacena el estado (objetos de Kubernetes) del clúster.
Volúmenes persistentes
Lo usan los componentes del sistema y las cargas de trabajo del usuario.
Recuperación ante daños o pérdidas de datos de etcd
Kubernetes usa la base de datos de etcd para almacenar todo el estado del clúster, incluidos los manifiestos de las aplicaciones del usuario. Las operaciones del ciclo de vida de la aplicación dejarían de funcionar si la base de datos de etcd del clúster de usuario está dañada o se pierde. Las operaciones del ciclo de vida del clúster de usuario dejarán de funcionar si la base de datos de etcd del clúster de administrador está dañada o se pierde.
etcd no proporciona un mecanismo integrado y confiable para detectar la corrupción de datos. Debes buscar los registros de los Pods de etcd si sospechas que los datos de etcd están dañados o se pierden.
Un Pod de etcd pendiente, con errores y con una falla de repetición no siempre implica que los datos de etcd estén dañados o se pierden. Esto podría deberse a la existencia de errores en las VM que alojan los Pods de etcd. Debes realizar la siguiente recuperación de etcd solo para el daño o la pérdida de datos.
Para poder recuperar (el estado reciente del clúster) de la corrupción o pérdida de datos similares, se debe crear una copia de seguridad de los datos de etcd después de cualquier operación de ciclo de vida del clúster (por ejemplo, crear, actualizar o mejorar). Para crear una copia de seguridad de los datos de etcd, consulta Crea una copia de seguridad de un clúster de administrador y Crea una copia de seguridad de un clúster de usuario.
Restablecer los datos de etcd hace que el clúster tenga un estado anterior. En otras palabras, si se realiza una copia de seguridad antes de que se implemente una aplicación y, luego, se usa para restablecer el clúster, la aplicación no se ejecutará en el clúster restablecido. Por ejemplo, si usas la instantánea etcd de un clúster de administrador que se crea una instantánea antes de crear un clúster de usuario, entonces se quita el plano de control del clúster del usuario restablecido en el clúster de administrador restablecido. Por lo tanto, te recomendamos crear una copia de seguridad del clúster después de cada operación de clúster crítica.
La falla del daño o pérdida de datos de etcd puede ocurrir en los siguientes casos:
Un nodo único de un clúster de etcd de tres nodos (clúster de usuario de alta disponibilidad) se bloquea de forma permanente debido al daño o pérdida de datos. En este caso, solo un nodo se dañó y el quórum de etcd aún existe. Esto puede ocurrir en un clúster de alta disponibilidad, en el que los datos de una de las réplicas de etcd están dañados o se perdieron. El problema se puede solucionar sin pérdida de datos si se reemplaza la réplica de etcd con errores por una nueva en estado inicial.
Dos nodos de un clúster de etcd de tres nodos (clúster de usuario de alta disponibilidad) se rompen de forma permanente debido al daño o pérdida de datos. El quórum se pierde, por lo que no ayuda reemplazar las réplicas de etcd fallidas por otras nuevas. El estado del clúster debe restablecerse a partir de los datos de la copia de seguridad. Para obtener más información, consulta Restablece un clúster de usuario desde una copia de seguridad (HA).
Un clúster de etcd de un solo nodo (clúster del administrador o clúster de usuario sin alta disponibilidad) se rompe de forma permanente debido al daño o pérdida de datos. El quórum se pierde, por lo que debes crear un clúster nuevo a partir de la copia de seguridad. Para obtener más información, consulta Restablece un clúster de usuario desde una copia de seguridad (sin alta disponibilidad).
Recuperación ante daños o pérdidas de PV de la aplicación del usuario
Los clientes de GKE On-Prem pueden usar determinadas soluciones de almacenamiento de socios a fin de crear copias de seguridad y restablecer PersistentVolumes de aplicaciones de usuario.
Si deseas obtener la lista de socios de almacenamiento calificados de GKE On-Prem, consulta Socios de almacenamiento de Anthos Ready.
Recuperación ante fallas del balanceador de cargas
Para el balanceo de cargas en paquetes (Seesaw), puedes recuperar los errores mediante la recreación del balanceador de cargas. Para volver a crear el balanceador de cargas, actualiza Seesaw a la misma versión que se muestra en Actualiza el balanceador de cargas del clúster de administrador.
En el caso de fallas del balanceador de cargas del clúster de administrador, es posible que el plano de control esté fuera del alcance. Como resultado, debes ejecutar la actualización en la VM del plano de control del administrador en la que se puede acceder al plano de control.
Para los balanceadores de cargas integrados (F5), consulta con compatibilidad con F5.
Usa varios clústeres para la recuperación ante desastres
La implementación de aplicaciones en varios clústeres en varios vCenters o plataformas de Anthos puede proporcionar una mayor disponibilidad global y limitar el radio de efecto durante las interrupciones.
Esta configuración usa el clúster de Anthos existente en el centro de datos secundario para la recuperación ante desastres en lugar de configurar un clúster nuevo. A continuación, se ofrece un resumen de alto nivel para lograrlo:
Crear otro clúster de administrador y clúster de usuarios en el centro de datos secundario En esta arquitectura de varios clústeres, exigimos que los usuarios tengan dos clústeres de administrador en cada centro de datos, y cada clúster de administrador ejecuta un clúster de usuario.
El clúster de usuario secundario tiene una cantidad mínima de nodos trabajadores (tres) y es una espera activa (siempre en ejecución).
Las implementaciones de las aplicaciones se pueden replicar en los dos vCenters mediante Anthos Config Management, o el enfoque preferido usará una cadena de herramientas de DevOps de aplicación (CI/CD, Spinnaker) existente.
En caso de un desastre, se puede cambiar el tamaño del clúster de usuarios a la cantidad de nodos.
Además, se requiere un cambio de DNS para enrutar el tráfico entre los clústeres al centro de datos secundario.