Prácticas recomendadas para la alta disponibilidad con OpenShift

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

Este documento está dirigido a arquitectos de plataformas y aplicaciones, y se supone que tienes cierta 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 una región deGoogle Cloud . 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 Google Cloud zonas de la misma región en tu archivo install-config.yaml.

Para obtener un control detallado sobre las ubicaciones en las que se implementan los nodos, te recomendamos definir políticas de ubicación de VM que garanticen que las VMs se distribuyan entre diferentes dominios de fallas en la misma zona. Aplicar una política de posición de distribució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 pod:

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 servicios sin estado, como frontends web o 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 la sobrecompromisión de recursos

Te recomendamos que administres de forma proactiva la carga de tu aplicación para evitar una sobrecomitencia de recursos. La sobrecompromisión puede provocar un rendimiento deficiente del servicio cuando hay carga. Puedes ayudar a evitar la sobrecompromisión configurando límites de solicitudes de recursos. Para obtener una explicación más detallada, consulta Cómo administrar los recursos de tu pod. Además, puedes aumentar o disminuir automáticamente la escala de las réplicas 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 entrada 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 accedan 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 fallan.
  • 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.

Define 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 para estar disponible durante 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 un almacenamiento que admita la HA y la replicación de datos

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

Prácticas recomendadas para los discos

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

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

Por último, establece un StorageClass para tu disco:

En el siguiente ejemplo, se muestra cómo configurar una StorageClass:

kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
  name: regionalpd-balanced
provisioner: PROVISIONER
parameters:
  type: DISK-TYPE
  replication-type: REPLICATION-TYPE
volumeBindingMode: WaitForFirstConsumer
reclaimPolicy: Delete
allowVolumeExpansion: true
allowedTopologies:
  - matchLabelExpressions:
      - key: topology.kubernetes.io/zone
        values:
          - europe-west1-b
          - europe-west1-a

Prácticas recomendadas para la base de datos

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

Después de instalar el operador de 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 la 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 Secret de Kubernetes llamado my-database-secret.
  • El acceso de superusuario está inhabilitado para mayor 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 la caché a almacenes en memoria compartidos (por ejemplo, Redis) o almacenes de datos persistentes (por ejemplo, Postgres, MySQL) que estén configurados para ejecutarse en modo HA.

Resumen de prácticas recomendadas

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

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

¿Qué sigue?