Prácticas recomendadas para conseguir una alta disponibilidad con OpenShift

En este documento se describen las prácticas recomendadas para conseguir una alta disponibilidad (HA) con cargas de trabajo de Red Hat OpenShift Container Platform en Compute Engine. Este documento se centra en las estrategias a nivel de aplicación para ayudarte a asegurarte de que tus cargas de trabajo sigan teniendo una alta disponibilidad cuando se produzcan errores. Estas estrategias te ayudan a eliminar puntos únicos de fallo e implementar mecanismos de conmutación por error y recuperación automáticas.

Este documento está dirigido a arquitectos de plataformas y aplicaciones, y presupone que tiene 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.

Extender los despliegues en varias zonas

Te recomendamos que implementes OpenShift en varias zonas de unaGoogle Cloud región. Este enfoque ayuda a asegurar que, si una zona sufre una interrupción, los nodos del plano de control del clúster sigan funcionando en las otras zonas en las que se haya distribuido la implementación. Para implementar OpenShift en varias zonas, especifica una lista de zonas de la misma región en el archivo install-config.yaml. Google Cloud

Para controlar con precisión las ubicaciones en las que se implementan los nodos, te recomendamos que definas políticas de colocación de VMs que aseguren que las VMs se distribuyan entre diferentes dominios de error de la misma zona. Aplicar una política de colocación dispersa a los nodos de tu clúster ayuda a reducir el número de nodos que se ven afectados simultáneamente por interrupciones específicas de la ubicación. Para obtener más información sobre cómo crear una política de dispersión para clústeres, consulta Crear y aplicar políticas de colocación de dispersión a 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 las aplicaciones 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

En el caso de los servicios sin estado, como los front-ends web o las APIs REST, te recomendamos que ejecutes varias réplicas de pods para cada servicio o ruta. De esta forma, el tráfico se dirige automáticamente a los pods de las zonas disponibles.

Gestionar la carga de forma proactiva para evitar que se asignen demasiados recursos

Te recomendamos que gestiones de forma proactiva la carga de tu aplicación para evitar que se comprometan demasiados recursos. Si se compromete demasiado, el rendimiento del servicio puede ser deficiente cuando haya carga. Para evitar que se asignen más recursos de los disponibles, puedes definir límites de solicitudes de recursos. Para obtener una explicación más detallada, consulta el artículo sobre gestión de recursos de pods. Además, puedes aumentar o reducir automáticamente el número de réplicas en función de la CPU, la memoria o las métricas personalizadas mediante la herramienta de autoescalado horizontal de pods.

También te recomendamos que utilices los siguientes servicios de balanceo de carga:

  • Operador de entrada de OpenShift. El operador de entrada implementa controladores de entrada basados en HAProxy para gestionar el enrutamiento a tus pods. En concreto, te recomendamos que configures el acceso global para el controlador de entrada, lo que permite que los clientes de cualquier región de la misma red de VPC y región que el balanceador de carga accedan a las cargas de trabajo que se ejecutan en tu clúster. Además, te recomendamos que implementes comprobaciones de estado del controlador de entrada para monitorizar el estado de tus pods y reiniciar los que fallen.
  • Google Cloud Balanceo de carga. El balanceo de carga distribuye el tráfico entre lasGoogle Cloud zonas. Elige un balanceador de carga que se ajuste a las necesidades de tu aplicación.

Definir coberturas para interrupciones de pods

Te recomendamos que definas presupuestos de interrupción para especificar el número mínimo de pods que tu aplicación necesita 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

Para obtener más información, consulta Especificar un presupuesto de interrupción para tu aplicación.

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

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

Prácticas recomendadas para 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 tu clúster:

El operador de disco persistente de CSI proporciona una clase de almacenamiento que puedes usar para crear reclamaciones de volumen persistente. 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:

Después de instalar el operador de la base de datos, configura un clúster con varias instancias. En el ejemplo siguiente 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 ofrecer alta disponibilidad.
  • El clúster usa la clase de almacenamiento regionalpd-balanced para el almacenamiento duradero y replicado en 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 monitorización está habilitada en 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"

Externalizar el estado de la aplicación

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

Resumen de las prácticas recomendadas

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

  • Extender los despliegues en varias zonas
  • Gestionar la carga de forma proactiva para evitar que se asignen demasiados recursos
  • Definir coberturas para interrupciones de pods
  • Usar las funciones de replicación de datos de alta disponibilidad
  • Externalizar el estado de la aplicación

Siguientes pasos