El operador de alta disponibilidad (HA) con estado te permite usar la integración integrada de GKE con el disco persistente regional para automatizar y controlar la velocidad de la conmutación por error de Pod de StatefulSet. Durante la conmutación por error, el operador controla automáticamente la detección de fallas de nodos, la desvinculación de un volumen de un nodo con fallas y la vinculación segura del volumen al nodo de conmutación por error.
Por qué usar el operador de HA con estado
Para lograr la alta disponibilidad, una arquitectura con estado común usa discos persistentes regionales como la capa de almacenamiento. Estos discos proporcionan replicación síncrona de datos entre dos zonas de una región. Durante las fallas de redes zonales o de nodos, esta arquitectura permite que tus cargas de trabajo conmuten por error (a través de la conexión forzada) réplicas para el almacenamiento en otro nodo en una zona diferente.
El operador de HA con estado te permite realizar las siguientes optimizaciones:
- Mejora el tiempo de recuperación de aplicaciones de una sola réplica: Si usas solo una réplica, puedes usar el operador de HA con estado y cambiar el almacenamiento zonal por el almacenamiento regional cuando se aprovisione tu aplicación, para aumentar la durabilidad y la disponibilidad de los datos en caso de que falle un nodo.
- Reduce los costos de herramientas de redes entre zonas: Replicar datos en varias zonas puede ser costoso para aplicaciones de alta capacidad de procesamiento. Puedes usar el operador de HA con estado para ejecutar tu aplicación en una sola zona y, al mismo tiempo, mantener una ruta de conmutación por error a una zona alternativa que se ajuste al ANS de tu aplicación.
Limitaciones
Con una arquitectura de operador de HA con estado de una sola réplica, GKE conserva tus datos en dos zonas a través del disco persistente regional, pero solo se puede acceder a los datos mientras la réplica de tu aplicación está en buen estado. Durante una conmutación por error, tu aplicación no estará disponible temporalmente mientras la réplica se reprograme a un nodo nuevo en buen estado. Si tu aplicación tiene un objetivo de tiempo de recuperación (RTO) muy bajo, te recomendamos que uses un enfoque de varias réplicas.
Antes de comenzar
Antes de comenzar, asegúrate de haber realizado las siguientes tareas:
- Habilita la API de Google Kubernetes Engine. Habilitar la API de Google Kubernetes Engine
- Si deseas usar Google Cloud CLI para esta tarea, instala y, luego, inicializa gcloud CLI. Si ya instalaste gcloud CLI, ejecuta
gcloud components update
para obtener la versión más reciente.
Requisitos
- El plano de control y los nodos de tu clúster deben ejecutar la versión 1.28 de GKE o una posterior.
- Cuando usas el operador de HA con estado, se configura de forma automática el StatefulSet vinculado para usar discos persistentes regionales. Sin embargo, eres responsable de garantizar que los Pods estén configurados para usar estos discos y que puedan ejecutarse en todas las zonas asociadas con el almacenamiento subyacente.
- Asegúrate de que tu aplicación se ejecute en formas de máquina que admita el disco persistente regional: E2, N1, N2 y N2D.
- Asegúrate de que el controlador de CSI del disco persistente para Compute Engine esté habilitado. El controlador de CSI del disco persistente está habilitado de forma predeterminada en los clústeres nuevos de Autopilot y Standard, y no se puede inhabilitar ni editar cuando se usa Autopilot. Si necesitas agregar de forma manual el controlador de CSI del disco persistente desde tu clúster, consulta Habilita el controlador de CSI del disco persistente en un clúster existente.
- Si usas una StorageClass personalizada, configura el controlador CSI del disco persistente con el aprovisionador
pd.csi.storage.gke.io
y estos parámetros:availability-class: regional-hard-failover
replication-type: regional-pd
Configura y usa el operador de HA con estado
Sigue estos pasos para configurar el operador de HA con estado para las cargas de trabajo con estado:
- Habilita el complemento
StatefulHA
- Instala un recurso HighAvailabilityApplication.
- Instala un StatefulSet.
- Inspecciona el recurso HighAvailabilityApplication.
Habilita el complemento StatefulHA
Para usar el operador de HA con estado, el complemento StatefulHA
debe estar habilitado en tu clúster.
Clústeres de Autopilot: GKE habilita automáticamente el complemento
StatefulHA
durante la creación del clúster. Si deseas usar el operador de HA con estado para una carga de trabajo existente, vuelve a implementar tu carga de trabajo en un clúster nuevo de Autopilot.Clústeres estándar:
- Creación de un clúster nuevo: Sigue las instrucciones de la CLI de gcloud para crear un clúster estándar y agrega la siguiente marca:
--add-on=StatefulHA
. - Clúster estándar existente: sigue las instrucciones de la CLI de gcloud para actualizar la configuración de un clúster estándar y usa la siguiente marca a fin de habilitar el complemento:
--update-addons=StatefulHA=ENABLED
.
- Creación de un clúster nuevo: Sigue las instrucciones de la CLI de gcloud para crear un clúster estándar y agrega la siguiente marca:
GKE instala automáticamente una StorageClass llamada
standard-rwo-regional
por ti cuando se habilita el complemento.
Instala un recurso HighAvailabilityApplication
HighAvailabilityApplication
es un recurso de Kubernetes que simplifica la configuración de StatefulSet y aumenta la disponibilidad de los pods en GKE.
El operador de HA con estado concilia los recursos HighAvailabilityApplication
en GKE.
En la especificación HighAvailabilityApplication
, debes configurar HighAvailabilityApplication.spec.resourceSelection.resourceKind
como StatefulSet
.
Para obtener información sobre cómo configurar el recurso HighAvailability, consulta la documentación de referencia de HighAvailabilityApplication
.
Revisa el siguiente ejemplo para PostgreSQL:
Guarda el siguiente manifiesto como un archivo llamado
stateful-ha-example-resource.yaml
:kind: HighAvailabilityApplication apiVersion: ha.gke.io/v1 metadata: name: APP_NAME namespace: APP_NAMESPACE spec: resourceSelection: resourceKind: StatefulSet policy: storageSettings: requireRegionalStorage: true failoverSettings: forceDeleteStrategy: AfterNodeUnreachable afterNodeUnreachable: afterNodeUnreachableSeconds: 20
Reemplaza lo siguiente:
- APP_NAME: el nombre de una aplicación en tu clúster que deseas proteger. Este nombre se debe compartir tanto por HighAvailabilityApplication como por StatefulSet.
- APP_NAMESPACE: el espacio de nombres de la aplicación. Este espacio de nombres debe compartirse por los recursos HighAvailabilityApplication y StatefulSet que se protegen.
En este ejemplo:
HighAvailabilityApplication.spec.policy.storageSettings.requireRegionalSettings
se configura comotrue
. Esto aplica de manera forzosa el almacenamiento regional.HighAvailabilityApplication.spec.policy.failoverSettings
se configura comoAfterNodeUnreachable
. Esto determina cómo se activa la eliminación forzosa en la falla del nodo.HighAvailabilityApplication.spec.policy.failoverSettings.afterNodeUnreachable
se configura como 20. Es el tiempo de espera para forzar la eliminación de un Pod después de que el nodo en el que se ejecuta se marca como inaccesible.
Crea el recurso. El recurso
HighAvailabilityApplication
identifica un StatefulSet con un espacio de nombres y un nombre coincidentes.kubectl apply -f stateful-ha-example-resource.yaml
Instala un StatefulSet
Instala un StatefulSet. Por ejemplo, puedes instalar un StatefulSet de PostgreSQL con Helm (Helm viene preinstalado con Cloud Shell):
helm install postgresql oci://registry-1.docker.io/bitnamicharts/postgresql \
--namespace=APP_NAMESPACE \
--set fullnameOverride=APP_NAME
El recurso HighAvailabilityApplication
modifica automáticamente la StorageClass de StatefulSet a standard-rwo-regional
, que usa el disco persistente regional.
Inspecciona el recurso HighAvailabilityApplication
Ejecuta el siguiente comando para verificar que la aplicación de ejemplo tenga habilitada la conmutación por error automática:
kubectl describe highavailabilityapplication APP_NAME
El resultado debería ser similar al ejemplo siguiente:
Status:
Conditions:
Last Transition Time: 2023-08-09T23:59:52Z
Message: Application is protected
Observed Generation: 1
Reason: ApplicationProtected
Status: True
Type: Protected