Prácticas recomendadas para la alta disponibilidad con OpenShift

En este documento, se describen las prácticas recomendadas para lograr una alta disponibilidad (HA) con cargas de trabajo de Red Hat OpenShift Container Platform en Compute Engine. En este documento, se abordan las estrategias a nivel de la aplicación para ayudarte a garantizar que tus cargas de trabajo sigan teniendo alta disponibilidad cuando se produzcan fallas. Estas estrategias te ayudan a eliminar los puntos únicos de falla y a implementar mecanismos para la conmutación por error y la recuperación automáticas.

Este documento está dirigido a arquitectos de plataformas y aplicaciones, y supone que tienes experiencia en la implementación de OpenShift. Para obtener más información sobre cómo implementar OpenShift, consulta la documentación de Red Hat.

Distribuye las implementaciones en varias zonas

Te recomendamos que implementes OpenShift en varias zonas dentro de unaGoogle Cloud región. Este enfoque ayuda a garantizar que, si una zona experimenta una interrupción, los nodos del plano de control del clúster sigan funcionando en las otras zonas en las que se distribuye la implementación. Para implementar OpenShift en varias zonas, especifica una lista de zonas Google Cloud de la misma región en tu archivoinstall-config.yaml.

Para tener un control más preciso sobre las ubicaciones en las que se implementan los nodos, te recomendamos que definas políticas de posición de VM que garanticen que las VMs se distribuyan en diferentes dominios de fallas en la misma zona. Aplicar una política de posición de propagación a los nodos de tu clúster ayuda a reducir la cantidad de nodos que se ven afectados de forma simultánea por interrupciones específicas de la ubicación. Para obtener más información sobre cómo crear una política de distribución para clústeres existentes, consulta Crea y aplica políticas de posición distribuida a las VMs.

Del mismo modo, para evitar que se programen varios Pods en el mismo nodo, te recomendamos que uses reglas de antiafinidad de Pods. Estas reglas distribuyen las réplicas de la aplicación en varias zonas. En el siguiente ejemplo, se muestra cómo implementar reglas de antiafinidad de Pods:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
  namespace: my-app-namespace
spec:
  replicas: 3
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
    spec:
      # Pod Anti-Affinity: Prefer to schedule new pods on nodes in different zones.
      affinity:
        podAntiAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
          - labelSelector:
              matchLabels:
                app: my-app
            topologyKey: topology.kubernetes.io/zone
      containers:
      - name: my-app-container
        image: quay.io/myorg/my-app:latest
        ports:
        - containerPort: 8080

Para los servicios sin estado, como los front-ends web o las APIs de REST, te recomendamos que ejecutes varias réplicas de Pod para cada servicio o ruta. Este enfoque garantiza que el tráfico se enrute automáticamente a los Pods en las zonas disponibles.

Administra la carga de forma proactiva para evitar el exceso de asignación de recursos

Te recomendamos que administres de forma proactiva la carga de tu aplicación para evitar el exceso de asignación de recursos. El exceso de compromiso puede generar un rendimiento deficiente del servicio bajo carga. Puedes ayudar a evitar la sobreasignación estableciendo límites de solicitudes de recursos. Para obtener una explicación más detallada, consulta Administra los recursos de tu pod. Además, puedes ajustar automáticamente la escala de las réplicas hacia arriba o hacia abajo según la CPU, la memoria o las métricas personalizadas con el escalador automático horizontal de Pods.

También te recomendamos que uses los siguientes servicios de balanceo de cargas:

  • Operador de entrada de OpenShift. El operador de Ingress implementa controladores de Ingress basados en HAProxy para controlar el enrutamiento a tus Pods. Específicamente, te recomendamos que configures el acceso global para el controlador de Ingress, lo que permite que los clientes de cualquier región dentro de la misma red de VPC y región que el balanceador de cargas lleguen a las cargas de trabajo que se ejecutan en tu clúster. Además, te recomendamos que implementes verificaciones de estado del controlador de entrada para supervisar el estado de tus pods y reiniciar los que fallen.
  • Google Cloud Balanceo de cargas. El balanceo de cargas distribuye el tráfico entre las zonas deGoogle Cloud . Elige un balanceador de cargas que satisfaga las necesidades de tu aplicación.

Cómo definir presupuestos de interrupción de Pods

Te recomendamos que definas presupuestos de interrupción para especificar la cantidad mínima de Pods que tu aplicación requiere que estén disponibles durante las interrupciones, como eventos de mantenimiento o actualizaciones. En el siguiente ejemplo, se muestra cómo definir un presupuesto de interrupción:

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: my-app-pdb
  namespace: my-app-namespace
spec:
  # Define how many pods need to remain available during a disruption.
  # At least one of "minAvailable" or "maxUnavailable" must be specified.
  minAvailable: 2
  selector:
    matchLabels:
      app: my-app

A fin de obtener más información, consulta Especificando un presupuesto de disrupción para tu aplicación.

Usa almacenamiento que admita la alta disponibilidad y la replicación de datos

Para las cargas de trabajo con estado que requieren almacenamiento de datos persistente fuera de los contenedores, recomendamos las siguientes prácticas recomendadas.

Prácticas recomendadas para el disco

Si necesitas almacenamiento en disco, usa una de las siguientes opciones:

Después de seleccionar una opción de almacenamiento, instala su controlador en tu clúster:

El operador de disco persistente de CSI proporciona una clase de almacenamiento que puedes usar para crear solicitudes de volúmenes persistentes (PVC). En el caso de Filestore, debes crear la clase de almacenamiento de Filestore.

Prácticas recomendadas para bases de datos

Si necesitas una base de datos, usa una de las siguientes opciones:

Después de instalar el operador de la base de datos, configura un clúster con varias instancias. En el siguiente ejemplo, se muestra la configuración de un clúster con los siguientes atributos:

  • Se crea un clúster de PostgreSQL llamado my-postgres-cluster con tres instancias para lograr alta disponibilidad.
  • El clúster usa la clase de almacenamiento regionalpd-balanced para el almacenamiento duradero y replicado en todas las zonas.
  • Se inicializa una base de datos llamada mydatabase con un usuario myuser, cuyas credenciales se almacenan en un secreto de Kubernetes llamado my-database-secret.
  • El acceso de superusuario está inhabilitado para mejorar la seguridad.
  • La supervisión está habilitada para el clúster.
apiVersion: postgresql.cnpg.io/v1
kind: Cluster
metadata:
  name: my-postgres-cluster
  namespace: postgres-namespace
spec:
  instances: 3
  storage:
    size: 10Gi
    storageClass: regionalpd-balanced
  bootstrap:
    initdb:
      database: mydatabase
      owner: myuser
      secret:
        name: my-database-secret
  enableSuperuserAccess: false
  monitoring:
    enabled: true
---
apiVersion: 1
kind: Secret
metadata:
  name: my-database-secret
  namespace: postgres-namespace
type: Opaque
data:
  username: bXl1c2Vy # Base64-encoded value of "myuser"
  password: c2VjdXJlcGFzc3dvcmQ= # Base64-encoded value of "securepassword"

Externaliza el estado de la aplicación

Te recomendamos que muevas el estado de la sesión o el almacenamiento en caché a almacenes compartidos en memoria (por ejemplo, Redis) o almacenes de datos persistentes (por ejemplo, Postgres, MySQL) que estén configurados para ejecutarse en modo de alta disponibilidad.

Resumen de prácticas recomendadas

En resumen, implementa las siguientes prácticas recomendadas para lograr una alta disponibilidad con OpenShift:

  • Distribuye las implementaciones en varias zonas
  • Administra la carga de forma proactiva para evitar el exceso de asignación de recursos
  • Cómo definir presupuestos de interrupción de Pods
  • Usa funciones de replicación de datos de alta disponibilidad
  • Externaliza el estado de la aplicación

¿Qué sigue?