Partilhar via


Política de suporte do Azure Red Hat OpenShift 4.0

Determinadas configurações para clusters do Azure Red Hat OpenShift 4 podem afetar a capacidade de suporte do cluster. O Azure Red Hat OpenShift 4 permite que os administradores de cluster façam alterações a componentes de cluster internos, mas nem todas as alterações são suportadas. A política de suporte abaixo compartilha quais modificações violam a política e anulam o suporte da Microsoft e da Red Hat.

Nota

Os recursos marcados como Technology Preview no OpenShift Container Platform não são suportados no Azure Red Hat OpenShift.

Requisitos de configuração do cluster

Computação

  • O cluster deve ter um mínimo de três nós de trabalho e três nós mestres.
  • Não dimensione os trabalhadores do cluster para zero nem tente um desligamento do cluster. Não há suporte para deslocalizar ou desligar qualquer máquina virtual no grupo de recursos de cluster.
  • Não crie mais de 250 nós de trabalho em um cluster. 250 é o número máximo de nós que podem ser criados em um cluster. Consulte Configurar vários endereços IP por balanceador de carga de cluster ARO para obter mais informações.
  • Se você estiver usando nós de infraestrutura, não execute cargas de trabalho não designadas neles, pois isso pode afetar o Contrato de Nível de Serviço e a estabilidade do cluster. Além disso, recomenda-se ter três nós de infraestrutura; um em cada zona de disponibilidade. Consulte Implantar nós de infraestrutura em um cluster do Azure Red Hat OpenShift (ARO) para obter mais informações.
  • Não há suporte para nós de computação que não sejam RHCOS. Por exemplo, você não pode usar um nó de computação RHEL.
  • Não tente remover, substituir, adicionar ou modificar um nó mestre. Essa é uma operação de alto risco que pode causar problemas com etcd, perda permanente de rede e perda de acesso e capacidade de gerenciamento pelo ARO SRE. Se você achar que um nó mestre deve ser substituído ou removido, entre em contato com o suporte antes de fazer qualquer alteração.
  • Certifique-se de que uma ampla cota de VM esteja disponível caso os nós do plano de controle precisem ser ampliados, mantendo pelo menos o dobro da contagem de vCPU do plano de controle atual disponível.

Operadores

  • Todos os operadores do OpenShift Cluster devem permanecer em um estado gerenciado. A lista de operadores de cluster pode ser retornada executando oc get clusteroperators.

Gestão de cargas de trabalho

  • Não adicione manchas que impeçam que qualquer componente padrão do OpenShift seja agendado.
  • Para evitar interrupções resultantes da manutenção do cluster, as cargas de trabalho no cluster devem ser configuradas com práticas de alta disponibilidade, incluindo, entre outras, afinidade e antiafinidade do pod, orçamentos de interrupção do pod e dimensionamento adequado.
  • Não execute cargas de trabalho extras nos nós do plano de controle. Embora eles possam ser agendados nos nós do plano de controle, isso causa uso de recursos extras e problemas de estabilidade que podem afetar todo o cluster.
  • Não há suporte para a execução de cargas de trabalho personalizadas (incluindo operadores instalados a partir do Operator Hub ou outros operadores fornecidos pela Red Hat) em nós de infraestrutura.

Registos e monitorização

  • Não remova nem modifique o serviço Prometheus de cluster padrão, exceto para modificar o agendamento da instância padrão do Prometheus.
  • Não remova nem modifique o cluster padrão Alertmanager svc, o recetor padrão ou quaisquer regras de alerta padrão, exceto para adicionar outros recetores para notificar sistemas externos.
  • Não remova nem modifique o log do serviço Azure Red Hat OpenShift (pods mdsd).

Rede e segurança

  • O Grupo de Segurança de Rede fornecido pela ARO não pode ser modificado ou substituído. Qualquer tentativa de modificá-lo ou substituí-lo será revertida.
  • Todas as máquinas virtuais de cluster devem ter acesso direto de saída à Internet, pelo menos para os pontos de extremidade do Azure Resource Manager (ARM) e do log de serviço (Genebra). Nenhuma forma de proxy HTTPS é suportada.
  • O serviço Azure Red Hat OpenShift acessa seu cluster por meio do Private Link Service. Não remova nem modifique o acesso ao serviço.
  • A migração do OpenShift SDN para o OVN não é suportada.

Gestão do Cluster

  • Não remova nem modifique o segredo de pull do cluster 'arosvc.azurecr.io'.
  • Não crie novos objetos MachineConfig nem modifique os existentes, a menos que haja suporte explícito na documentação do Azure Red Hat OpenShift.
  • Não crie novos objetos KubeletConfig nem modifique os existentes, a menos que haja suporte explícito na documentação do Azure Red Hat OpenShift.
  • Não defina nenhuma opção de ConfigOverrides sem suporte. A definição dessas opções impede atualizações secundárias de versão.
  • Não coloque políticas em sua assinatura ou grupo de gerenciamento que impeçam SREs de executar manutenção normal no cluster do Azure Red Hat OpenShift. Por exemplo, não exija tags no grupo de recursos de cluster gerenciado pelo Azure Red Hat OpenShift RP.
  • Não contorne a atribuição de negação configurada como parte do serviço ou execute tarefas administrativas normalmente proibidas pela atribuição de negação.
  • O OpenShift depende da capacidade de marcar automaticamente os recursos do Azure. Se você configurou uma política de marcação, não aplique mais de 10 tags definidas pelo usuário aos recursos do grupo de recursos gerenciados.

Gestão de incidentes

Um incidente é um evento que resulta em uma degradação ou interrupção dos serviços do Azure Red Hat OpenShift. Os incidentes são levantados por um cliente ou membro do Customer Experience and Engagement (CEE) através de um caso de suporte, diretamente pelo sistema centralizado de monitoramento e alerta, ou diretamente por um membro da equipe ARO Site Reliability Engineer (SRE).

Dependendo do impacto no serviço e no cliente, o incidente é categorizado em termos de gravidade.

O fluxo de trabalho geral de como um novo incidente é gerenciado é descrito abaixo:

  1. Um socorrista SRE é alertado sobre um novo incidente e inicia uma investigação inicial.

  2. Após a investigação inicial, o incidente recebe um líder do incidente, que coordena os esforços de recuperação.

  3. O líder do incidente gerencia toda a comunicação e coordenação em torno da recuperação, incluindo quaisquer notificações relevantes ou atualizações de casos de suporte.

  4. O incidente está recuperado.

  5. O incidente é documentado e uma análise de causa raiz (RCA) é realizada dentro de 5 dias úteis após o incidente.

  6. Um rascunho de documento RCA é partilhado com o cliente no prazo de 7 dias úteis após o incidente.

Tamanhos de máquinas virtuais suportados

O Azure Red Hat OpenShift 4 dá suporte a instâncias de nó nos seguintes tamanhos de máquina virtual:

Nós do plano de controle

Série Tamanho vCPU Memória: 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' não suporta criptografia no host

Nós de trabalho

Fins gerais

Série Tamanho vCPU Memória: 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

Com otimização de memória

Série Tamanho vCPU Memória: 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

Com otimização de computação

Série Tamanho vCPU Memória: 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

Memória e computação otimizadas

Série Tamanho vCPU Memória: GiB
Mms* Standard_M128ms 128 3892

*Standard_M128ms' não suporta criptografia no host

Com otimização de armazenamento

Série Tamanho vCPU Memória: 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 trabalho da GPU

Série Tamanho vCPU Memória: 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

*Apenas dia 2 (ou seja, não suportado como opção de tempo de instalação)