Compartilhar via

Diretrizes de linha de base de operações para o Red Hat OpenShift no Azure

  • Artigo

O Red Hat OpenShift no Azure fornece clusters OpenShift altamente escalonáveis e totalmente gerenciados sob demanda. Ao projetar corretamente sua solução com o gerenciamento e o monitoramento em mente, você pode trabalhar para a excelência operacional e o sucesso do cliente.

Considerações sobre o design

Considere os seguintes fatores:

  • Examine a matriz de responsabilidades do Red Hat OpenShift no Azure para entender como as responsabilidades dos clusters são compartilhadas entre a Microsoft, o Red Hat e os clientes.
  • Esteja ciente dos limites da máquina virtual do Azure e das regiões com suporte. Verifique se há capacidade disponível para implantar recursos.
  • Conheça maneiras de isolar as cargas de trabalho logicamente em um cluster e fisicamente em clusters separados.
  • Conheça maneiras de ajudar o Kubernetes a entender a integridade de suas cargas de trabalho.
  • Lembre-se de vários tamanhos de máquinas virtuais e o efeito de usar um ou outro.
  • Esteja ciente de maneiras de monitorar e registrar o Red Hat OpenShift no Azure para obter insights sobre a integridade de seus recursos e prever possíveis problemas. O cluster e os aplicativos em execução na parte superior podem gerar muitos eventos. Use alertas para ajudar a diferenciar entre entradas de log para fins históricos e entradas que exigem ação imediata.
  • Esteja ciente de atualizações e atualizações importantes do sistema. As atualizações críticas de patch são aplicadas aos clusters automaticamente pelos engenheiros de confiabilidade do site (SRE) do Red Hat OpenShift no Azure. Os clientes que desejam instalar as atualizações de patch com antecedência são gratuitos para fazer isso.
  • Esteja ciente das limitações de recursos do cluster e das cargas de trabalho individuais.
  • Lembre-se das diferenças entre o dimensionador automático de pod horizontal e o dimensionamento automático do cluster.
  • Examine o ciclo de vida de suporte e entenda a política de suporte de versão. O Red Hat OpenShift no Azure dá suporte apenas às versões secundárias atuais e anteriores em disponibilidade geral da Plataforma de Contêiner do Red Hat OpenShift. As solicitações de suporte exigem que o cluster esteja dentro de uma versão com suporte.
  • Examine os requisitos de configuração do cluster para manter a capacidade de suporte do cluster.
  • Examine a rede entre namespaces para proteger o tráfego dentro do cluster usando a política de rede.

Recomendações sobre design

  • O Red Hat OpenShift no Azure tem um ecossistema de operador avançado e deve ser usado para executar e automatizar atividades operacionais com eficiência e precisão.
  • Adicione investigações de integridade aos pods para monitorar a integridade do aplicativo. Verifique se os pods contêm livenessProbe e readinessProbe. Use investigações de inicialização para determinar o ponto em que o aplicativo foi iniciado.
  • Use tamanhos de máquina virtual grandes o suficiente para conter várias instâncias de contêiner para que você obtenha os benefícios do aumento da densidade, mas não tão grande que o cluster não possa lidar com a carga de trabalho de um nó com falha.
  • Regular as funções de cluster usando plug-ins de admissão, que normalmente são usados para impor a política de segurança, limitações de recursos ou requisitos de configuração.
  • Use solicitações de pod e limites para gerenciar os recursos de computação em um cluster. Solicitações e limites de pod informam o agendador do Kubernetes, que atribui recursos de computação a um pod. Restringir o consumo de recursos em um projeto usando intervalos de limite.
  • Otimize os valores de solicitação de CPU e memória e maximize a eficiência dos recursos de cluster usando o dimensionador automático de pod vertical.
  • O console Web do OpenShift contém todas as métricas no nível do nó. Estabeleça um processo de monitoramento usando a integração embutida do Prometheus ou do Container Insights.
    • O Prometheus vem pré-instalado e configurado para os clusters do Red Hat OpenShift 4.x no Azure.
    • O Container Insights pode ser habilitado integrando o cluster ao Kubernetes habilitado para Azure Arc.
    • O registro em log do OpenShift implanta agregadores de log, armazenamento e componentes de visualização.
  • Automatize o processo de entrega de aplicativos por meio de práticas de DevOps e soluções de CI/CD, como Pipelines/GitOps fornecidos pela Plataforma de Contêiner do OpenShift.
  • Defina ClusterAutoScaler e MachineAutoScaler para dimensionar computadores quando o cluster ficar sem recursos para dar suporte a mais implantações.
  • Implante verificações de integridade do computador para reparar automaticamente computadores danificados em um pool de computadores.
  • Dimensione pods para atender à demanda usando o dimensionador automático de pod horizontal.
  • Use um sistema de alertas para fornecer notificações quando as coisas precisarem de ação direta: alertas de métrica do Container Insights ou interface do usuário de alertas interna.

BCDR (continuidade de negócios e recuperação de desastres)

Sua organização precisa projetar recursos adequados de nível de plataforma do Red Hat OpenShift no Azure para atender aos requisitos específicos. Esses serviços de aplicativo têm requisitos relacionados ao RTO (objetivo de tempo de recuperação) e ao RPO (objetivo de ponto de recuperação). Há várias considerações a serem abordadas para recuperação de desastre. Sua primeira etapa é definir um SLA (Contrato de Nível de Serviço) para sua infraestrutura e aplicativo. Saiba mais sobre o SLA do Red Hat OpenShift no Azure. Confira a seção Detalhes do SLA para obter informações sobre cálculos mensais de tempo de atividade.

Considerações de design para BCDR

Considere os seguintes fatores:

  • O cluster do Red Hat OpenShift no Azure deve usar vários conjuntos de computadores para fornecer o nível mínimo de disponibilidade para seu aplicativo.
  • Defina solicitações e limites de pod. Definir esses limites permite que o Kubernetes:
    • Atribua com eficiência recursos de CPU e memória aos pods.
    • Tenha densidade de contêiner mais alta em um nó.
    • Aumente a confiabilidade com custos reduzidos devido ao melhor uso do hardware.
  • Distribua nós em todas as zonas disponíveis para maior disponibilidade.
    • Escolha uma região que oferece suporte às Zonas de Disponibilidade.
    • Para o benefício zonal completo, todas as dependências de serviço também devem dar suporte às zonas. Se um serviço dependente não der suporte às zonas, é possível que uma falha de zona possa causar a falha desse serviço. Examine os tipos de disco usados ao distribuir a carga de trabalho entre zonas.
    • Para maior disponibilidade além do que Zonas de Disponibilidade pode alcançar, execute vários clusters em diferentes regiões emparelhadas. Se um recurso do Azure oferecer suporte à redundância geográfica, forneça o local em que o serviço redundante terá sua região secundária.
  • Crie consistentemente backups para aplicativos e dados.
    • Um serviço sem estado pode ser replicado de forma eficiente.
    • Se você precisar armazenar o estado no cluster, fazer o back-up dos dados que estão com frequência na região emparelhada.
  • Atualize e mantenha seus clusters.
  • Para conectividade de rede se ocorrer um failover:
    • Se você precisar distribuir o tráfego em diferentes regiões, considere usar o Azure Front Door.
  • Para failovers planejados e não planejados:
    • Ao configurar cada serviço do Azure, escolha os recursos que dão suporte à recuperação de desastre. Por exemplo, se Registro de Contêiner do Azure for escolhido, habilite-o para replicação geográfica. Se uma região ficar inativa, você ainda poderá fazer pull de imagens da região replicada.
  • Mantenha os recursos de DevOps de engenharia para atingir as metas de nível de serviço.

Recomendações de design para BCDR

Veja a seguir as melhores práticas para seu design:

  • Os clusters do Red Hat OpenShift no Azure são provisionados com três nós do painel de controle e três ou mais nós de trabalho. Verifique se o cluster foi criado em uma região que dá suporte a Zonas de Disponibilidade para que os nós sejam distribuídos entre as zonas.
  • Para alta disponibilidade, implante esses nós em diferentes Zonas de Disponibilidade. Como você precisa de conjuntos de computadores diferentes para cada Zona de Disponibilidade, crie pelo menos três conjuntos de computadores.
  • Não execute cargas de trabalho extras nos nós do painel de controle. Embora elas possam ser agendadas nos nós do painel de controle, isso causará uso adicional de recursos e problemas de estabilidade que podem afetar todo o cluster.
  • Crie conjuntos de computadores de infraestrutura para manter componentes de infraestrutura. Aplique rótulos específicos do Kubernetes a esses computadores e atualize os componentes de infraestrutura para serem executados apenas nesses computadores.
  • Sempre que possível, remova o estado do serviço de dentro de contêineres. Em vez disso, use uma PaaS (plataforma como serviço) do Azure que dá suporte à replicação em várias regiões.
  • As implantações devem especificar os requisitos de recursos do pod. O agendador pode agendar o pod adequadamente. A confiabilidade deprecia significativamente quando os pods não são agendados.
  • Configure várias réplicas na implantação para lidar com interrupções como falhas de hardware. Para eventos planejados, como atualizações e upgrades, um orçamento de interrupção pode garantir que exista o número necessário de réplicas de pod para lidar com a carga esperada do aplicativo.
  • Use restrições de topologia de pod para agendar automaticamente pods em nós em todo o cluster.
  • Seus aplicativos podem usar o armazenamento para seus dados e devem garantir a disponibilidade entre regiões, se necessário:
  • Criar backup de aplicativo e planejar a restauração:
  • Estimar limites de recursos do pod. Teste e estabeleça uma linha de base. Comece com valores iguais para solicitações e limites. Em seguida, ajuste gradualmente os valores até que você tenha estabelecido um limite que pode causar instabilidade no cluster. Os limites de pod podem ser especificados em seus manifestos de implantação. O dimensionador automático de pod vertical otimiza os valores de solicitação de CPU e memória e pode maximizar a eficiência dos recursos de cluster.
    • Os recursos internos podem lidar com falhas e interrupções na arquitetura de serviço. Essas configurações ajudam a simplificar a automação de design e de implantação. Quando uma organização define um padrão para o SLA, RTO e RPO, ela pode usar serviços integrados ao Kubernetes e ao Azure para atingir as metas de negócios.
  • Considere estratégias azuis/verdes ou canários para implantar novas versões do aplicativo.
  • Defina os orçamentos de interrupção de pod/prioridade do pod para limitar o número de réplicas de pod que o cluster tem permissão para remover para operações de manutenção, garantindo assim a disponibilidade.
  • Impor cotas de recursos em namespaces de serviço. A cota de recursos em um namespace garantirá que as solicitações de pod e os limites sejam definidos corretamente em uma implantação.
    • Definir as cotas de recursos no nível do cluster pode causar problemas ao implantar serviços de parceiros que não têm solicitações e limites adequados.
  • Armazene suas imagens de contêiner em Registro de Contêiner do Azure e replique geograficamente o registro para cada região.
  • Use várias regiões e locais de emparelhamento para a conectividade do Azure ExpressRoute. Se ocorrer uma interrupção que afete uma região do Azure ou local do provedor de emparelhamento, uma arquitetura de rede híbrida redundante poderá ajudar a garantir a conectividade interlocal ininterrupta.
  • Regiões de interconexão com emparelhamento de rede virtual global. Se os clusters precisarem se comunicar entre si, a conexão de ambas as redes virtuais entre si pode ser feita por meio do emparelhamento de rede virtual. Essa tecnologia interconecta redes virtuais entre si para fornecer alta largura de banda na rede de backbone da Microsoft, mesmo em diferentes regiões geográficas.
  • Use o protocolo anycast baseado em TCP dividido, Azure Front Door, para conectar prontamente os usuários finais ao POP do Front Door mais próximo (ponto de presença). Mais recursos do Azure Front Door incluem:
    • Encerramento de TLS
    • Domínio personalizado
    • Firewall do Aplicativo Web
    • Reconfiguração de URL
    • Afinidade de sessão

Próximas etapas

Saiba mais sobre considerações e recomendações de design para automação de plataforma e DevOps em suas zonas de destino do Azure.