Aumenta la disponibilidad de las apps con estado con el operador de HA con estado

Autopilot Estándar

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.
Nota: Para las instalaciones de gcloud CLI existentes, asegúrate de configurar las propiedades compute/region y compute/zone. Cuando configuras las ubicaciones predeterminadas, puedes evitar errores en gcloud CLI como el siguiente: One of [--zone, --region] must be supplied: Please specify location.

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.

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 como true. Esto aplica de manera forzosa el almacenamiento regional.
- HighAvailabilityApplication.spec.policy.failoverSettings se configura como AfterNodeUnreachable. 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