Directiva de soporte técnico de Red Hat OpenShift en Azure 4.0

Ciertas configuraciones de los clústeres de la versión 4 de Red Hat OpenShift en Azure pueden afectar a la compatibilidad del clúster. La versión 4 de Red Hat OpenShift en Azure permite a los administradores de clúster realizar cambios en los componentes internos del clúster, pero no se admiten todos los cambios. La directiva de soporte técnico siguiente comparte qué modificaciones infringen la directiva y anulan el soporte técnico de Microsoft y Red Hat.

Nota:

Las características con la marca de vista previa de tecnología en la plataforma de contenedores de OpenShift no se admiten en Red Hat OpenShift en Azure.

Requisitos de configuración de clústeres

Proceso

  • El clúster debe tener al menos tres nodos de trabajo y tres nodos maestros.
  • No escale los trabajos del clúster a cero ni intente realizar un cierre del clúster. No se admite la desasignación o desactivación de cualquier máquina virtual del grupo de recursos de clúster.
  • Si usa nodos de infraestructura, no ejecute ninguna carga de trabajo no designada en ellos, ya que esto puede afectar a la estabilidad del clúster y al Acuerdo de Nivel de Servicio. Además, se recomienda tener tres nodos de infraestructura; una en cada zona de disponibilidad. Consulte Implementar nodos de infraestructura en un clúster de Red Hat OpenShift (ARO) en Azure para obtener más información.
  • No se admiten nodos de ejecución que no sean de Red Hat Enterprise Linux CoreOS. Por ejemplo, no puede usar un nodo de proceso de RHEL.
  • No intente quitar ni reemplazar un nodo maestro. Se trata de una operación de alto riesgo que puede causar problemas con etcd, pérdida permanente de red y pérdida de acceso y capacidad de administración por parte de ARO SRE. Si cree que se debe reemplazar o quitar un nodo maestro, póngase en contacto con el soporte técnico antes de realizar cambios.

Operadores

  • Todos los operadores de clúster de OpenShift deben permanecer en estado administrado. La lista de operadores de clústeres se puede devolver mediante la ejecución de oc get clusteroperators.

Administración de cargas de trabajo

  • No añada taints que impidan la programación de componentes predeterminados de OpenShift.
  • Para evitar interrupciones derivadas del mantenimiento del clúster, las cargas de trabajo en clúster deben configurarse con procedimientos de alta disponibilidad, entre los que se incluyen, la afinidad de pods y la antiafinidad, los presupuestos de interrupciones de pods y el escalado adecuado.
  • No ejecute cargas de trabajo adicionales en los nodos del plano de control. Aunque se pueden programar en los nodos del plano de control, provoca problemas de estabilidad y uso de recursos adicionales que pueden afectar a todo el clúster.
  • No se admite la ejecución de cargas de trabajo personalizadas (incluidos los operadores instalados desde el centro de operadores u otros operadores proporcionados por Red Hat) en los nodos de infraestructura.

Registro y supervisión

  • No quite ni modifique el servicio Prometheus del clúster predeterminado, excepto para modificar la programación de la instancia predeterminada de Prometheus.
  • No quite ni modifique el Alertmanager svc del clúster predeterminado, el receptor predeterminado ni ninguna regla de alerta predeterminada, excepto para agregar otros receptores para notificar a sistemas externos.
  • No quite ni modifique el registro de servicios de Red Hat OpenShift en Azure (pods mdsd).

Red y seguridad

  • El grupo de seguridad de red proporcionado por ARO no se puede modificar ni reemplazar. Cualquier intento de modificarlo o reemplazarlo se revertirá.
  • Todas las máquinas virtuales del clúster deben tener acceso directo de salida a Internet, al menos a los puntos de conexión de Azure Resource Manager (ARM) y del registro de servicios (Geneva). No se admite ningún tipo de proxy HTTPS.
  • El servicio Red Hat OpenShift en Azure accede al clúster a través del servicio Private Link. No quite ni modifique el acceso al servicio.
  • No se admite la migración de SDN de OpenShift a OVN.

Administración de clústeres

  • No quite ni modifique el secreto de extracción del clúster "arosvc.azurecr.io".
  • No invalide ninguno de los objetos MachineConfig del clúster (por ejemplo, la configuración de kubelet) de ningún modo.
  • No establezca ninguna opción unsupportedConfigOverrides. Establecer estas opciones impide que la versión secundaria se actualice.
  • No coloque directivas dentro de su suscripción o grupo de administración que impidan que los SRE realicen un mantenimiento normal en el clúster de Red Hat OpenShift en Azure. Por ejemplo, no se requieren etiquetas en el grupo de recursos del clúster administrado por RP de Red Hat OpenShift en Azure.
  • No evite la asignación de denegación configurada como parte del servicio o realice tareas administrativas que normalmente están prohibidas por la asignación de denegación.
  • OpenShift se basa en la capacidad de etiquetar automáticamente los recursos de Azure. Si ha configurado una directiva de etiquetado, no aplique más de 10 etiquetas definidas por el usuario a los recursos del grupo de recursos administrados.

Administración de incidentes

Un incidente es un evento que da lugar a una degradación o interrupción de los servicios Red Hat OpenShift en Azure. Los incidentes los genera un cliente o un miembro de Experiencia y compromiso del cliente (CEE) a través de un caso de soporte técnico, directamente mediante el sistema centralizado de supervisión y alerta, o directamente mediante un miembro del equipo de ingeniería de confiabilidad de sitios (SRE) de ARO.

Según el impacto en el servicio y el cliente, el incidente se clasifica en términos de gravedad.

A continuación se describe el flujo de trabajo general de cómo se administra un nuevo incidente:

  1. Se alerta a un primer respondedor de SRE de un nuevo incidente y comienza una investigación inicial.

  2. Después de la investigación inicial, al incidente se le asigna un responsable de incidente, que coordina los esfuerzos de recuperación.

  3. El responsable del incidente administra toda la comunicación y coordinación en torno a la recuperación, incluidas las notificaciones pertinentes o las actualizaciones de casos de soporte técnico.

  4. El incidente se recupera.

  5. El incidente se documenta y se realiza un análisis de la causa principal (RCA) en los 5 días laborables siguientes al incidente.

  6. Un documento borrador del RCA se comparte con el cliente en los 7 días laborables siguientes al incidente.

Tamaños de máquinas virtuales que se admiten

La versión 4 de Red Hat OpenShift en Azure admite instancias de nodo en los siguientes tamaños de máquina virtual:

Nodos del plano de control

serie Tamaño vCPU Memoria: GiB
Dsv3 Standard_D8s_v3 8 32
Dsv3 Standard_D16s_v3 16 64
Dsv3 Standard_D32s_v3 32 128
Dsv4 Standard_D8s_v4 8 32
Dsv4 Standard_D16s_v4 16 64
Dsv4 Standard_D32s_v4 32 128
Dsv5 Standard_D8s_v5 8 32
Dsv5 Standard_D16s_v5 16 64
Dsv5 Standard_D32s_v5 32 128
Dasv4 Standard_D8as_v4 8 32
Dasv4 Standard_D16as_v4 16 64
Dasv4 Standard_D32as_v4 32 128
Dasv5 Standard_D8as_v5 8 32
Dasv5 Standard_D16as_v5 16 64
Dasv5 Standard_D32as_v5 32 128
Easv4 Standard_E8as_v4 8 64
Easv4 Standard_E16as_v4 16 128
Easv4 Standard_E20as_v4 20 160
Easv4 Standard_E32as_v4 32 256
Easv4 Standard_E48as_v4 48 384
Easv4 Standard_E64as_v4 64 512
Easv4 Standard_E96as_v4 96 672
Easv5 Standard_E8as_v5 8 64
Easv5 Standard_E16as_v5 16 128
Easv5 Standard_E20as_v5 20 160
Easv5 Standard_E32as_v5 32 256
Easv5 Standard_E48as_v5 48 384
Easv5 Standard_E64as_v5 64 512
Easv5 Standard_E96as_v5 96 672
Eisv3 Standard_E64is_v3 64 432
Eis4 Standard_E80is_v4 80 504
Eids4 Standard_E80ids_v4 80 504
Eisv5 Standard_E104is_v5 104 672
Eidsv5 Standard_E104ids_v5 104 672
Esv4 Standard_E8s_v4 8 64
Esv4 Standard_E16s_v4 16 128
Esv4 Standard_E20s_v4 20 160
Esv4 Standard_E32s_v4 32 256
Esv4 Standard_E48s_v4 48 384
Esv4 Standard_E64s_v4 64 504
Esv5 Standard_E8s_v5 8 64
Esv5 Standard_E16s_v5 16 128
Esv5 Standard_E20s_v5 20 160
Esv5 Standard_E32s_v5 32 256
Esv5 Standard_E48s_v5 48 384
Esv5 Standard_E64s_v5 64 512
Esv5 Standard_E96s_v5 96 672
Fsv2 Standard_F72s_v2 72 144
Mms* Standard_M128ms 128 3892

*Standard_M128ms" no admite el cifrado en el host

Nodos de trabajo

Uso general

serie Tamaño vCPU Memoria: GiB
Dasv4 Standard_D4as_v4 4 16
Dasv4 Standard_D8as_v4 8 32
Dasv4 Standard_D16as_v4 16 64
Dasv4 Standard_D32as_v4 32 128
Dasv4 Standard_D64as_v4 64 256
Dasv4 Standard_D96as_v4 96 384
Dasv5 Standard_D4as_v5 4 16
Dasv5 Standard_D8as_v5 8 32
Dasv5 Standard_D16as_v5 16 64
Dasv5 Standard_D32as_v5 32 128
Dasv5 Standard_D64as_v5 64 256
Dasv5 Standard_D96as_v5 96 384
Dsv3 Standard_D4s_v3 4 16
Dsv3 Standard_D8s_v3 8 32
Dsv3 Standard_D16s_v3 16 64
Dsv3 Standard_D32s_v3 32 128
Dsv4 Standard_D4s_v4 4 16
Dsv4 Standard_D8s_v4 8 32
Dsv4 Standard_D16s_v4 16 64
Dsv4 Standard_D32s_v4 32 128
Dsv4 Standard_D64s_v4 64 256
Dsv5 Standard_D4s_v5 4 16
Dsv5 Standard_D8s_v5 8 32
Dsv5 Standard_D16s_v5 16 64
Dsv5 Standard_D32s_v5 32 128
Dsv5 Standard_D64s_v5 64 256
Dsv5 Standard_D96s_v5 96 384

Memoria optimizada

serie Tamaño vCPU Memoria: GiB
Easv4 Standard_E4as_v4 4 32
Easv4 Standard_E8as_v4 8 64
Easv4 Standard_E16as_v4 16 128
Easv4 Standard_E20as_v4 20 160
Easv4 Standard_E32as_v4 32 256
Easv4 Standard_E48as_v4 48 384
Easv4 Standard_E64as_v4 64 512
Easv4 Standard_E96as_v4 96 672
Easv5 Standard_E8as_v5 8 64
Easv5 Standard_E16as_v5 16 128
Easv5 Standard_E20as_v5 20 160
Easv5 Standard_E32as_v5 32 256
Easv5 Standard_E48as_v5 48 384
Easv5 Standard_E64as_v5 64 512
Easv5 Standard_E96as_v5 96 672
Esv3 Standard_E4s_v3 4 32
Esv3 Standard_E8s_v3 8 64
Esv3 Standard_E16s_v3 16 128
Esv3 Standard_E32s_v3 32 256
Esv4 Standard_E4s_v4 4 32
Esv4 Standard_E8s_v4 8 64
Esv4 Standard_E16s_v4 16 128
Esv4 Standard_E20s_v4 20 160
Esv4 Standard_E32s_v4 32 256
Esv4 Standard_E48s_v4 48 384
Esv4 Standard_E64s_v4 64 504
Esv5 Standard_E4s_v5 4 32
Esv5 Standard_E8s_v5 8 64
Esv5 Standard_E16s_v5 16 128
Esv5 Standard_E20s_v5 20 160
Esv5 Standard_E32s_v5 32 256
Esv5 Standard_E48s_v5 48 384
Esv5 Standard_E64s_v5 64 512
Esv5 Standard_E96s_v5 96 672
Edsv5 Standard_E96ds_v5 96 672
Eisv3 Standard_E64is_v3 64 432
Eis4 Standard_E80is_v4 80 504
Eids4 Standard_E80ids_v4 80 504
Eisv5 Standard_E104is_v5 104 672
Eidsv5 Standard_E104ids_v5 104 672

Proceso optimizado

serie Tamaño vCPU Memoria: GiB
Fsv2 Standard_F4s_v2 4 8
Fsv2 Standard_F8s_v2 8 16
Fsv2 Standard_F16s_v2 16 32
Fsv2 Standard_F32s_v2 32 64
Fsv2 Standard_F72s_v2 72 144

Optimizado para memoria y para proceso

serie Tamaño vCPU Memoria: GiB
Mms* Standard_M128ms 128 3892

*Standard_M128ms" no admite el cifrado en el host

Almacenamiento optimizado

serie Tamaño vCPU Memoria: GiB
L4s Standard_L4s 4 32
L8s Standard_L8s 8 64
L16s Standard_L16s 16 128
L32s Standard_L32s 32 256
L8s_v2 Standard_L8s_v2 8 64
L16s_v2 Standard_L16s_v2 16 128
L32s_v2 Standard_L32s_v2 32 256
L48s_v2 Standard_L48s_v2 48 384
L64s_v2 Standard_L64s_v2 64 512
L8s_v3 Standard_L8s_v3 8 64
L16s_v3 Standard_L16s_v3 16 128
L32s_v3 Standard_L32s_v3 32 256
L48s_v3 Standard_L48s_v3 48 384
L64s_v3 Standard_L64s_v3 64 512

Carga de trabajo de GPU

serie Tamaño vCPU Memoria: GiB
NC4asT4v3 Standard_NC4as_T4_v3 4 28
NC6sV3 Standard_NC6s_v3 6 112
NC8asT4v3 Standard_NC8as_T4_v3 8 56
NC12sV3 Standard_NC12s_v3 12 224
NC16asT4v3 Standard_NC16as_T4_v3 16 110
NC24sV3 Standard_NC24s_v3 24 448
NC24rsV3 Standard_NC24rs_v3 24 448
NC64asT4v3 Standard_NC64as_T4_v3 64 440
ND96asr_v4* Standard_ND96asr_v4 96 900
ND96amsr_A100_v4* Standard_ND96amsr_A100_v4 96 1924
NC24ads_A100_v4* Standard_NC24ads_A100_v4 24 220
NC48ads_A100_v4* Standard_NC48ads_A100_v4 48 440
NC96ads_A100_v4* Standard_NC96ads_A100_v4 96 880

*Solo Day-2 (es decir, no se admite como opción de hora de instalación)