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 incorporada de GKE en Persistent Disk regional para automatizar y controlar la velocidad de StatefulSet Conmutación por error del Pod. Durante la conmutación por error, el operador controla automáticamente la detección de fallas del nodo, desconecta un volumen de un nodo con errores y garantiza la conexión de volúmenes segura al nodo de conmutación por error.

Por qué usar el operador de HA con estado

En una arquitectura con estado común para lograr una alta disponibilidad, se usan discos persistentes regionales como capa de almacenamiento. Estos discos proporcionan replicación síncrona de datos entre dos zonas de una región. Durante las fallas de nodo o de red zonal, esta arquitectura permite que tus cargas de trabajo conmutan por error (mediante la conexión forzada) al almacenamiento en otro nodo en un 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 las 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 zona única, a la vez que mantienes una ruta de conmutación por error hacia 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 de Persistent Disk regional, pero solo se puede acceder a ellos mientras tu réplica de aplicación está en buen estado. Durante una conmutación por error, tu aplicación no estará disponible temporalmente mientras tu réplica se reprograma a un nuevo nodo en buen estado. Si tu aplicación tiene un objetivo de tiempo de recuperación (RTO) muy bajo, te recomendamos usar un enfoque de varias réplicas.

Antes de comenzar

Antes de comenzar, asegúrate de haber realizado las siguientes tareas:

Habilita la API de Kubernetes Engine de Google.

Habilitar la API de Kubernetes Engine de Google

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, este 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 sean capaces de ejecutarse en todas las zonas asociadas con el almacenamiento subyacente.
Asegúrate de que la aplicación se ejecute en formas de máquina compatibles con Persistent Disk regional: E2, N1, N2 y N2D.
Asegúrate de que el controlador de CSI de Persistent Disk para Compute Engine esté habilitado. El controlador de CSI de Persistent Disk 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 de Persistent Disk desde tu clúster, consulta Habilita el controlador de CSI de Persistent Disk en un clúster existente.
Si usas una StorageClass personalizada, configura el controlador de CSI de Persistent Disk 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 a fin de configurar el operador de HA con estado para tus 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 de forma automática 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 implementarla en un clúster de Autopilot nuevo.
Clústeres estándar:
- Creación de clústeres nuevos: 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 de forma automática una StorageClass llamada standard-rwo-regional cuando el complemento está habilitado.

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 más información sobre cómo configurar el recurso de alta disponibilidad, consulta la documentación de referencia de HighAvailabilityApplication.

Consulta 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 debe compartirse por HighAvailabilityApplication y StatefulSet.
- APP_NAMESPACE: el espacio de nombres de la aplicación. Este espacio de nombres debe compartirse por HighAvailabilityApplication y StatefulSet que se protegen.
En este ejemplo:
- HighAvailabilityApplication.spec.policy.storageSettings.requireRegionalSettings se configura como true. Esto aplica el almacenamiento regional.
- HighAvailabilityApplication.spec.policy.failoverSettings se configura como AfterNodeUnreachable. Esto determina cómo se activa la eliminación forzada en caso de falla del nodo.
- HighAvailabilityApplication.spec.policy.failoverSettings.afterNodeUnreachable se configura como 20. Este 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 de forma automática la StorageClass de StatefulSet a standard-rwo-regional, que usa Persistent Disk regional.

Inspecciona el recurso HighAvailabilityApplication

Ejecuta el siguiente comando para verificar que la aplicación de ejemplo tenga habilitada la conmutación por error automatizada:

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