Compartilhar via


Política de suporte do Red Hat OpenShift 4.0 no Azure

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

Observação

Os recursos marcados como Visualização da tecnologia na plataforma do contêiner do OpenShift não são compatíveis com o Red Hat OpenShift no Azure.

Requisitos de configuração do cluster

Computação

  • O cluster deve ter no mínimo três nós de trabalho e três nós mestres.
  • Não dimensione os trabalhos do cluster para zero nem tente um desligamento do cluster. Não há suporte para desalocar ou desligar qualquer máquina virtual no grupo de recursos do 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 nenhuma carga de trabalho não atribuída neles, pois isso pode afetar o Contrato de Nível de Serviço e a estabilidade do cluster. Além disso, é recomendável ter três nós de infraestrutura; um em cada zona de disponibilidade. Consulte Implantar nós de infraestrutura em um cluster do Red Hat OpenShift no Azure (ARO) para obter mais informações.
  • Não há suporte para nós de computação não 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 SRE do ARO. Se você achar que um nó mestre deve ser substituído ou removido, entre em contato com o suporte antes de fazer alterações.
  • Verifique se a cota de VM ampla está disponível caso os nós do plano de controle precisem ser escalados verticalmente, mantendo pelo menos o dobro da contagem de vCPU do plano de controle atual disponível.

Operadores

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

Gerenciamento de carga de trabalho

  • Não adicione taints que impeçam o agendamento de componentes padrão do OpenShift.
  • 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 painel de controle. Embora possam ser agendados nos nós do plano de controle, isso causa problemas extras de uso e estabilidade de recursos que podem afetar todo o cluster.
  • Não há suporte para a execução de cargas de trabalho personalizadas (incluindo operadores instalados do Operator Hub ou outros operadores fornecidos pelo Red Hat) em nós de infraestrutura.

Log e monitoramento

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

Rede e segurança

  • O grupo de segurança de rede fornecido pelo ARO não pode ser modificado nem substituído. Qualquer tentativa de modificá-lo ou substituí-lo será revertida.
  • Todas as máquinas virtuais do cluster devem ter acesso direto à Internet de saída, pelo menos para os pontos de extremidade do Azure Resource Manager (ARM) e do registro em log do serviço (Geneva). Não há suporte para nenhuma forma de proxy HTTPS.
  • O serviço do Red Hat OpenShift no Azure acessa seu cluster por meio do serviço de Link Privado. Não remova nem modifique o acesso ao serviço.
  • Não há suporte para a migração do SDN do OpenShift para o OVN.

Gerenciamento de clusters

  • Não remova nem modifique o segredo de pull do cluster “arosvc.azurecr.io”.
  • Não crie novos objetos MachineConfig ou modifique os existentes, a menos que tenha suporte explícito na documentação do Red Hat OpenShift no Azure.
  • Não crie novos objetos KubeletConfig nem modifique os existentes, a menos que tenha suporte explícito na documentação do Red Hat OpenShift no Azure.
  • Não defina nenhuma opção de unsupportedConfigOverrides. Definir essas opções impede as atualizações de versões secundárias.
  • Não coloque em sua assinatura ou grupo de gerenciamento políticas que impeçam o SREs de executar a manutenção normal do cluster do Red Hat OpenShift no Azure. Por exemplo, não exija marcas no grupo de recursos de cluster gerenciado por ponto de retenção do Red Hat OpenShift no Azure.
  • 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 marcas definidas pelo usuário aos recursos no grupo de recursos gerenciados.

Gerenciamento de incidentes

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

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 respondente primário do 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 de incidente, que coordena os esforços de recuperação.

  3. O líder de incidente gerencia toda a comunicação e coordenação relacionadas à recuperação, incluindo quaisquer notificações relevantes ou atualizações de caso de suporte.

  4. O incidente foi recuperado.

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

  6. Um documento de rascunho do RCA é compartilhado com o cliente dentro de 7 dias úteis após o incidente.

Tamanhos de máquinas virtuais compatíveis

O Red Hat OpenShift no Azure 4 oferece 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 dá suporte à criptografia no host

Nó de trabalho

Propósito geral

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

Memória otimizada

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

Computação otimizada

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 dá suporte à criptografia no host

Otimizado para 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 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

*Somente dia 2 (ou seja, sem suporte como uma opção de tempo de instalação)