Desenvolvimento e teste de aplicativos com foco na resiliência

Saiba como o Red Hat OpenShift on IBM Cloud lida com a manutenção do plano de controle, como as atualizações de manutenção afetam as cargas de trabalho em execução e como testar e projetar suas aplicações para garantir alta resiliência.

Visão geral da arquitetura do cluster e das responsabilidades

O Red Hat OpenShift on IBM Cloud é um serviço Kubernetes gerenciado. Em cada cluster, a arquitetura é dividida em dois planos com [responsabilidades distintas de propriedade](/docs/openshift?topic=openshift-responsibilities_Kubernetes Service):

Plano de controle
Administrado por IBM. Inclui o servidor da API do Kubernetes, o etcd, o gerenciador de controladores e o agendador.
Plano de dados
Gerenciado por você. Inclui nós de trabalho, pods de aplicativos, configurações de armazenamento e complementos de rede.
Responsabilidades de gestão pelo plano de controle e pelo plano de dados do cluster
Avião Gerenciado por Componentes
Plano de controle IBM Servidor de API, etcd, gerenciador de controladores, agendador
Plano de dados Você Nós de trabalho, pods de aplicativos, armazenamento, complementos de rede

IBM aplica regularmente atualizações de versão de patch ao plano de controle. Essas atualizações corrigem vulnerabilidades de segurança, aplicam correções críticas de bugs e garantem que os clusters continuem em conformidade com os requisitos de segurança d IBM. Compreender como esses patches são aplicados ajuda você a tomar decisões bem fundamentadas sobre a arquitetura da sua aplicação.

Os aplicativos em execução em ambientes de nuvem estão expostos a condições dinâmicas, incluindo interrupções transitórias na rede, manutenção da infraestrutura de hospedagem e latência de serviços de terceiros. O projeto e os testes voltados para a resiliência em todas as condições garantem cargas de trabalho de produção confiáveis.

Como o “ IBM ” aplica patches no plano de controle

Os componentes do plano de controle de cada cluster do Red Hat OpenShift on IBM Cloud são executados em uma configuração de alta disponibilidade (HA). Várias réplicas de cada componente são distribuídas por zonas de disponibilidade independentes, de modo que não exista nenhum ponto único de falha no plano de controle.

Quando uma atualização de patch é aplicada, o IBM utiliza uma estratégia de recriação contínua. As réplicas são atualizadas sequencialmente:

  • O servidor da API do Kubernetes permanece acessível durante toda a atualização.
  • As operações do cluster, como agendamento, autoescala e verificações de integridade, continuam sem interrupção.
  • IBM proporciona um intervalo de desligamento gradual para permitir que as conexões em andamento sejam concluídas antes que um pod seja removido.

As atualizações de patch do plano de controle são projetadas de forma a não causar impacto nas aplicações dos usuários em execução no plano de dados. Seus pods, serviços e cargas de trabalho continuam funcionando normalmente nos nós de trabalho durante todo o processo.

Impacto na carga de trabalho durante as atualizações do plano de controle

Como o plano de dados é gerenciado pelo usuário, as correções no plano de controle d IBM não reiniciam, não reprogramam nem modificam seus nós de trabalho ou os pods de aplicativos em execução.

No entanto, aplicativos ou ferramentas que fazem chamadas frequentes e diretas à API do Kubernetes (como controladores personalizados, operadores, pipelines de CI/CD ou agentes de monitoramento que acompanham o estado do cluster) devem lidar com erros transitórios da API de maneira adequada. Siga as práticas recomendadas gerais para o Kubernetes:

  • Implemente uma lógica de repetição de tentativas com recuo exponencial para todas as chamadas de API.
  • Evite depender de conexões abertas persistentes com o servidor da API sem uma lógica de reconexão.

Simulação de cenários para testar a resiliência das aplicações

Para garantir a confiabilidade da resiliência das aplicações, simule condições de falha de produção em um ambiente que não seja de produção antes que ocorram manutenções programadas ou interrupções inesperadas.

Durante qualquer simulação, monitore seus aplicativos em busca de sinais de falha: reinicializações inesperadas de pods, picos nos logs de erros, tempos de resposta prejudicados ou solicitações de clientes perdidas. Utilize essas observações para aprimorar a lógica de novas tentativas, otimizar as verificações de integridade ou ajustar a topologia das réplicas.

A execução de comandos de gerenciamento de cluster (como a atualização do mestre ou o redimensionamento do pool de trabalhadores) requer acesso à plataforma como Administrador ou Operador, além de permissões para o serviço de gerenciamento de cluster. Se você for um desenvolvedor de aplicativos sem acesso à infraestrutura de cluster, entre em contato com o administrador do cluster para executar essas simulações.

Simulação de uma correção no plano de controle com uma atualização do plano de controle

Ao acionar uma atualização do plano de controle, inicia-se o processo de atualização gradual que o IBM utiliza durante as atualizações de patch. Este teste verifica se sua aplicação e suas ferramentas lidam com as transições entre réplicas do plano de controle de maneira tranquila.

  1. Inicie uma atualização do plano de controle no seu cluster.

    ibmcloud oc cluster master refresh --cluster CLUSTER_NAME_OR_ID

  2. Verifique se suas aplicações continuam processando o tráfego sem interrupções e se os terminais voltados para o cliente permanecem responsivos.

Simulação de atualizações de roteamento de rede por meio da adição e remoção de nós de trabalho

A adição e a remoção de nós de trabalho fazem com que o Kubernetes atualize a lógica interna de roteamento de rede em todo o cluster, simulando as condições que ocorrem quando os nós são reiniciados durante a manutenção da infraestrutura.

  1. Ajuste o tamanho do seu conjunto de nós de trabalho para adicionar um nó de trabalho temporário.

    ibmcloud oc worker-pool resize --cluster CLUSTER_NAME_OR_ID --worker-pool WORKER_POOL_NAME --size-per-zone NEW_SIZE

  2. Monitore os logs do seu aplicativo e a latência de resposta enquanto o novo nó de trabalho é inicializado e se junta à rede do cluster.

  3. Quando o teste estiver concluído, remova o nó de trabalho de teste.

    Para realizar a remoção seletiva do nó de trabalho específico criado na etapa 1:

    1. Isole e esvazie o nó de trabalho antes de excluí-lo, para garantir que as cargas de trabalho sejam reprogramadas de forma adequada.
       oc cordon NODE_NAME
   oc drain NODE_NAME --ignore-daemonsets --delete-emptydir-data
    1. Exclua o nó de trabalho do cluster.
       ibmcloud oc worker rm --cluster CLUSTER_NAME_OR_ID --worker WORKER_ID
    1. Redefina a capacidade do pool de trabalhadores para o valor original usando o comando ibmcloud oc worker-pool resize com o valor original de --size-per-zone .

    Como alternativa, em uma abordagem menos direcionada, você pode simplesmente redimensionar o conjunto de workers de volta ao seu tamanho original usando o comando ibmcloud oc worker-pool resize da etapa 1, sem excluir explicitamente um nó específico.

Práticas recomendadas para a resiliência da carga de trabalho

A resiliência do seu aplicativo durante eventos no cluster depende de como suas cargas de trabalho são projetadas e configuradas. Aplique as seguintes práticas recomendadas às especificações da sua carga de trabalho do Kubernetes:

Execute várias réplicas para cada carga de trabalho

Uma implantação com réplica única não tolera interrupções. Defina spec.replicas como, no mínimo, 2 (de preferência, 3 ou mais para cargas de trabalho de produção), para que a perda ou o reescalonamento de um único pod não cause tempo de inatividade.

Distribua réplicas entre zonas e nós de trabalho

Configure as regras de anti-afinidade d topologySpreadConstraints s ou pods na configuração da sua implantação. A distribuição de pods por várias zonas de disponibilidade e nós de trabalho evita que uma interrupção em uma única zona ou uma operação de manutenção em um único nó provoque a indisponibilidade simultânea de todas as réplicas.

Configurar Orçamentos de Interrupção de Pods (PDBs)

Um recurso PodDisruptionBudget especifica o número mínimo ou a porcentagem mínima de pods que devem permanecer disponíveis durante interrupções voluntárias, como a drenagem de nós ou atualizações do cluster. Defina um PDB para cada carga de trabalho crítica, a fim de evitar que as operações administrativas removam mais pods do que sua aplicação pode suportar.

Definir sondas de prontidão e de atividade

Configure os testes de prontidão e de atividade nas especificações dos seus contêineres:

  • Sondas de prontidão: Certifique-se de que o Kubernetes encaminhe o tráfego apenas para pods que estejam inicializados e prontos para atender às solicitações.
  • Sondas de integridade: Ative o recurso “ Kubernetes ” para reiniciar automaticamente os contêineres que entrarem em um estado de impasse ou de falha.

Definir solicitações e limites adequados de recursos

Especifique solicitações e limites realistas de CPU e memória para cada contêiner. As solicitações garantem que o agendador do Kubernetes aloque pods em nós com capacidade suficiente. Os limites impedem que um único contêiner consuma recursos excessivos e prejudique as cargas de trabalho localizadas no mesmo nó de trabalho.

Implementar o gerenciamento de desligamento gradual

Quando um pod é encerrado, o Kubernetes envia um sinal SIGTERM antes de enviar SIGKILL``. Projete seu aplicativo para detectar um erro de “ SIGTERM ”, interromper a aceitação de novas conexões, concluir as transações em andamento e encerrar a operação de forma adequada. Defina um valor adequado para terminationGracePeriodSeconds na especificação do seu pod para dar ao seu aplicativo tempo suficiente para escoar o tráfego.

Evite depender de conexões de longa duração com o servidor da API

Kubernetes As solicitações de monitoramento e as conexões de streaming (como oc exec, redirecionamentos de porta ou monitoramentos personalizados por clientes de API) se conectam diretamente a uma réplica específica do plano de controle. Quando essa réplica é atualizada durante uma atualização de patch, a conexão é encerrada. As cargas de trabalho e as ferramentas devem implementar uma lógica de reconexão automática com recuo exponencial.

Utilize lógica de repetição de tentativas e disjuntores de circuito

Quando seu aplicativo interagir com a API do Kubernetes, bancos de dados externos ou microsserviços a jusante, implemente uma lógica de repetição de tentativas com recuo exponencial e jitter. Utilize padrões de disjuntor para evitar falhas em cascata quando uma dependência a montante ou a jusante estiver temporariamente indisponível.

Próximas etapas