Compartir a través de

Guía de línea de base de operaciones para Red Hat OpenShift en Azure

  • Artículo

Red Hat OpenShift en Azure proporciona clústeres de OpenShift de alta escalabilidad y totalmente administrados a petición. Mediante el correcto diseño de su solución que tenga en cuenta la administración y la supervisión, puede trabajar hacia la excelencia operativa y el éxito de los clientes.

Consideraciones de diseño

Tenga en cuenta los siguientes factores:

  • Revise la matriz de responsabilidades de Red Hat OpenShift en Azure para comprender cómo se comparten las responsabilidades de los clústeres entre Microsoft, Red Hat y los clientes.
  • Tenga en cuenta los límites de máquinas virtuales de Azure y las regiones admitidas. Asegúrese de que hay capacidad disponible para implementar recursos.
  • Tenga en cuenta las formas de aislar lógicamente las cargas de trabajo dentro de un clúster y físicamente en clústeres independientes.
  • Tenga en cuenta las maneras de ayudar a que Kubernetes conozca el estado de las cargas de trabajo.
  • Tenga en cuenta los distintos tamaños de máquina virtual y el efecto de usar uno u otro.
  • Tenga en cuenta las formas de supervisar y registrar Red Hat OpenShift en Azure para obtener información sobre el estado de los recursos y prever posibles problemas. Tanto el clúster como las aplicaciones que se ejecutan en la parte superior pueden generar muchos eventos. El uso de alertas para ayudar a diferenciar entre las entradas del registro con fines históricos y para entradas que requieren una acción inmediata.
  • Tenga en cuenta las actualizaciones y actualizaciones importantes del sistema. Las actualizaciones de revisión críticas se aplican automáticamente a los clústeres por parte de los ingenieros de confiabilidad de sitios de Red Hat OpenShift en Azure. Los clientes que deseen instalar las actualizaciones de revisión con anterioridad pueden hacerlo libremente.
  • Tenga en cuenta las limitaciones de recursos del clúster y las cargas de trabajo individuales.
  • Tenga en cuenta las diferencias entre un escalador automático de pods horizontal y un escalador automático de clústeres.
  • Revise el ciclo de vida de soporte técnico y comprenda la directiva de soporte técnico de la versión. Red Hat OpenShift en Azure solo admite la versión secundaria actual y anteriores disponibles con carácter general de Red Hat OpenShift Container Platform. Las solicitudes de soporte técnico requieren que el clúster esté dentro de una versión compatible.
  • Revise los requisitos de configuración del clúster para mantener la compatibilidad del clúster.
  • Revise las redes entre espacios de nombres para proteger el tráfico dentro del clúster mediante la directiva de red.

Recomendaciones de diseño

  • Red Hat OpenShift en Azure tiene un ecosistema de operadores enriquecido y debe usarse para realizar y automatizar actividades operativas con eficacia y precisión.
  • Agregue sondeos de estado a los pods para supervisar el estado de la aplicación. Asegúrese de que los pods contienen livenessProbe y readinessProbe. Use sondeos de inicio para determinar el punto en el que se ha iniciado la aplicación.
  • Use tamaños de máquina virtual lo suficientemente grandes como para contener varias instancias de contenedor con el fin de obtener las ventajas de aumentar la densidad, pero no tan grande como para que el clúster no pueda controlar la carga de trabajo de un nodo con errores.
  • Regule las funciones de clúster mediante complementos de admisión, que se usan normalmente para aplicar la directiva de seguridad, las limitaciones de recursos o los requisitos de configuración.
  • Use las solicitudes y los límites de pod para administrar los recursos de proceso dentro de un clúster. Las solicitudes y los límites de pod informan al programador de Kubernetes sobre los recursos de proceso que se asignan un pod. Restrinja el consumo de recursos en un proyecto mediante intervalos de límite.
  • Optimice los valores de solicitud de CPU y memoria y maximice la eficacia de los recursos del clúster mediante el escalador automático de pods vertical.
  • Red Hat OpenShift en Azure 4.x, la consola web de OpenShift contiene todas las métricas en el nivel de nodo. Establezca un proceso de supervisión mediante la integración integrada de Prometheus o Container Insights.
    • Prometheus viene preinstalado y configurado para los clústeres de Red Hat OpenShift en Azure 4.x.
    • Container Insights se puede habilitar mediante la incorporación del clúster a Kubernetes habilitado para Azure Arc.
    • El registro de OpenShift implementa agregadores de registros, almacenamiento y componentes de visualización.
  • Automatice el proceso de entrega de aplicaciones a través de prácticas de DevOps y soluciones de CI/CD, como Pipelines/GitOps proporcionados por OpenShift Container Platform.
  • Defina ClusterAutoScaler y MachineAutoScaler para escalar máquinas cuando el clúster se queda sin recursos para admitir más implementaciones.
  • Implemente comprobaciones de estado de la máquina para reparar automáticamente las máquinas dañadas en un grupo de máquinas.
  • Escale pods para satisfacer la demanda mediante el escalador automático horizontal de pods.
  • Use un sistema de alertas para proporcionar notificaciones cuando necesite una acción directa: alertas de métricas de Container Insights o interfaz de usuario de alertas integrada.

Recuperación ante desastres y continuidad empresarial (BCDR)

Su organización necesita diseñar funcionalidades de nivel de plataforma de Red Hat OpenShift en Azure adecuadas para satisfacer sus requisitos específicos. Estos servicios de aplicación tienen requisitos relacionados con el objetivo de tiempo de recuperación (RTO) y el de punto de recuperación (RPO). Hay varias consideraciones que se deben tener en cuenta para la recuperación ante desastres. El primer paso es definir un Acuerdo de Nivel de Servicio (SLA) para la infraestructura y la aplicación. Obtenga información sobre el Acuerdo de Nivel de Servicio para Red Hat OpenShift en Azure. Consulte la sección Detalles del Acuerdo de Nivel de Servicio para obtener información sobre los cálculos de tiempo de actividad mensual.

Consideraciones de diseño para la continuidad empresarial y recuperación ante desastres

Tenga en cuenta los siguientes factores:

  • El clúster de Red Hat OpenShift en Azure debe usar varios conjuntos de máquinas para proporcionar el nivel mínimo de disponibilidad para la aplicación.
  • Establezca solicitudes y límites de pods. La configuración de estos límites permite a Kubernetes lo siguiente:
    • Asignar de forma eficaz recursos de CPU y memoria a los pods.
    • Tener una mayor densidad de contenedor en un nodo.
    • Aumentar la confiabilidad con costos reducidos debido a un mejor uso del hardware.
  • Distribuir nodos en todas las zonas disponibles para una mayor disponibilidad.
    • Elija una región que admita zonas de disponibilidad.
    • Para obtener una ventaja de zona completa, todas las dependencias de servicio también deben admitir zonas. Si un servicio dependiente no admite zonas, es posible que un error de zona provoque un error en el servicio. Revisar los tipos de disco usados al distribuir la carga de trabajo entre zonas.
    • Para lograr una disponibilidad mayor a la que pueden lograr las zonas de disponibilidad, ejecute varios clústeres en diferentes regiones emparejadas. Si un recurso de Azure admite redundancia geográfica, proporcione la ubicación en la que el servicio redundante tendrá su región secundaria.
  • Cree copias de seguridad para aplicaciones y datos de forma coherente.
    • Un servicio sin estado se puede replicar de forma eficaz.
    • Si tiene que almacenar el estado en el clúster, realice una copia de seguridad de los datos con frecuencia en la región emparejada.
  • Actualizar y mantener los clústeres.
  • Para la conectividad de red si se produce una conmutación por error:
    • Si necesita distribuir el tráfico entre regiones, considere la posibilidad de usar Azure Front Door.
  • Para conmutaciones por error planeadas y no planeadas:
    • Al configurar cada servicio de Azure, elija características que admitan la recuperación ante desastres. Por ejemplo, si se elige Azure Container Registry, habilite para la replicación geográfica. Si una región deja de funcionar, puede extraer imágenes de la región replicada.
  • Mantenga las funcionalidades de ingeniería de DevOps para alcanzar los objetivos de nivel de servicio.

Recomendaciones de diseño para la continuidad empresarial y recuperación ante desastres

A continuación se muestran los procedimientos recomendados para el diseño:

  • Los clústeres de Red Hat OpenShift en Azure se aprovisionan con tres o más planos de control de nodos de trabajo. Asegúrese de que el clúster se crea en una región que admita Availability Zones para que los nodos se repartan entre las zonas.
  • Para lograr una alta disponibilidad, implemente estos nodos en diferentes Availability Zones. Puesto que necesita diferentes conjuntos de máquinas para cada zona de disponibilidad, cree al menos tres conjuntos de máquinas.
  • No ejecute cargas de trabajo adicionales en los nodos del plano de control. Aunque se pueden programar en los nodos del plano de control, provocará problemas de estabilidad y uso de recursos adicionales que pueden afectar a todo el clúster.
  • Cree conjuntos de máquinas de infraestructura para contener componentes de infraestructura. Aplique etiquetas específicas de Kubernetes a estas máquinas y, a continuación, actualice los componentes de infraestructura para que solo se ejecuten en esas máquinas.
  • Siempre que sea posible, quite el estado del servicio del interior de los contenedores. En su lugar, use una plataforma de Azure como servicio (PaaS) que admita la replicación en varias regiones.
  • Las implementaciones deben especificar los requisitos de recursos de pod. Después, el programador puede programar correctamente el pod. La confiabilidad se devalúa significativamente cuando los pods no están programados.
  • Configure varias réplicas en la implementación para controlar las interrupciones, como los errores de hardware. En el caso de los eventos planeados, como las actualizaciones, un presupuesto de interrupciones puede garantizar que exista el número necesario de réplicas de pods para controlar la carga esperada de la aplicación.
  • Use restricciones de topología de pod para programar automáticamente pods en nodos en todo el clúster.
  • Las aplicaciones pueden usar el almacenamiento para sus datos y deben garantizar la disponibilidad entre regiones si es necesario:
  • Cree una copia de seguridad de la aplicación y planee la restauración:
  • Estime los el límite del recurso de pod. Pruebe y establezca una base de referencia. Comience con valores iguales para solicitudes y límites. A continuación, ajuste los valores gradualmente hasta que haya establecido un umbral que pueda provocar inestabilidad en el clúster. Los límites de pods se pueden especificar en los manifiestos de implementación. El escalador automático de pods vertical optimiza los valores de solicitud de CPU y memoria y puede maximizar la eficacia de los recursos del clúster.
    • Las características integradas pueden controlar errores e interrupciones en la arquitectura del servicio. Estas configuraciones ayudan a simplificar la automatización del diseño y la implementación. Cuando una organización define un estándar para el Acuerdo de Nivel de Servicio, el RTO y el RPO, puede usar servicios integrados para Kubernetes y Azure a fin de lograr objetivos empresariales.
  • Considere las estrategias azules o verdes o controladas para implementar nuevas versiones de la aplicación.
  • Establezca presupuestos de interrupción de pod o prioridad de pod para limitar el número de réplicas de pod que el clúster puede quitar para las operaciones de mantenimiento, lo que garantiza la disponibilidad.
  • Aplique cuotas de recursos en espacios de nombres de servicio. La cuota de recursos de un espacio de nombres garantizará que las solicitudes y los límites de pods se establezcan correctamente en una implementación.
    • El establecimiento de cuotas de recursos en el nivel de clúster puede generar problemas al implementar servicios de asociado que no tienen las solicitudes y los límites adecuados.
  • Almacene las imágenes de contenedor en Azure Container Registry y replique geográficamente el registro en cada región.
  • Use varias regiones y ubicaciones de emparejamiento para la conectividad de Azure ExpressRoute. En caso de que se produzca una interrupción de servicio que afecte a una región de Azure o a una ubicación del proveedor de emparejamiento, una arquitectura de red híbrida redundante puede ayudarle a garantizar una conectividad entre entornos locales ininterrumpida.
  • Interconexión de regiones con el emparejamiento de redes virtuales globales. Si los clústeres necesitan comunicarse entre sí, puede conectar ambas redes virtuales entre sí a través del emparejamiento de redes virtuales. Esta tecnología conecta las redes virtuales entre sí para ofrecer un alto ancho de banda en toda la red troncal de Microsoft, incluso en distintas regiones geográficas.
  • Mediante el protocolo de difusión por proximidad basado en división TCP, Azure Front Door para conectar inmediatamente a los usuarios finales con el punto de presencia (POP) de Front Door más cercano. Más características de Azure Front Door Azure son las siguientes:
    • Finalización de TLS
    • Dominio personalizado
    • Firewall de aplicaciones web
    • Reescritura de direcciones URL
    • Afinidad de sesión

Pasos siguientes

Información sobre las consideraciones y recomendaciones de diseño para la automatización de la plataforma y DevOps en el acelerador de zonas de aterrizaje Azure.