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

Artigo
03/11/2024

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.
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 ou substituir 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.

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 substitua nenhum dos objetos MachineConfig do cluster (por exemplo, a configuração do kubelet) de forma alguma.
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:

Um respondente primário do SRE é alertado sobre um novo incidente e inicia uma investigação inicial.
Após a investigação inicial, o incidente recebe um líder de incidente, que coordena os esforços de recuperação.
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.
O incidente foi recuperado.
O incidente está documentado e uma análise de causa raiz (RCA) é executada dentro de cinco dias úteis após o incidente.
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