Os aplicativos em execução nos clusters do Google Kubernetes Engine (GKE) precisam estar preparados para interrupções, como upgrades de nós e outros eventos de manutenção. Os aplicativos com estado, que geralmente precisam de tempo para interromper E/S de maneira limpa e se desconectar do armazenamento, são especialmente vulneráveis a interrupções. É possível usar recursos do Kubernetes, como orçamentos de interrupção de pod (PDBs, na sigla em inglês) e sondagens de prontidão, para ajudar a manter os aplicativos disponíveis. durante os upgrades.
O GKE monitora os clusters e usa o serviço Recomendador para fornecer orientações sobre como otimizar o uso da plataforma. O GKE detecta oportunidades para preparar suas cargas de trabalho para interrupção e fornece orientação sobre como atualizar seus PDBs ou sondagens de prontidão para maximizar a resiliência de cargas de trabalho à interrupção. Por exemplo, se um StatefulSet não estiver protegido por um PDB, o cluster poderá remover todos os pods de uma só vez durante um upgrade de nó. Para evitar isso, o GKE fornece orientações para criar um PDB para que a maioria dos pods possam permanecer em execução durante um upgrade.
Para ver as condições específicas em que o GKE fornece orientações relacionadas a interrupções, consulte Quando o GKE identifica cargas de trabalho com vulnerabilidade a interrupção.
Para saber mais sobre como gerenciar insights e recomendações dos Recommenders, consulte Otimizar o uso do GKE com insights e recomendações.
Identifique cargas de trabalho vulneráveis com interrupções
O GKE gera insights que identificam as cargas de trabalho vulneráveis a interrupções do cluster. Para conseguir esses insights, siga as instruções para visualizar insights e recomendações usando a CLI do Google Cloud ou a API Recommender. Use os subtipos listados na seção a seguir para filtrar insights específicos. Esses insights não estão disponíveis no Console do Google Cloud.
Quando o GKE identifica cargas de trabalho vulneráveis a interrupções
Consulte a tabela a seguir para cenários em que o GKE fornece informações e recomendações e o subtipo relevante:
Subtipo de insight | Descrição | Ação |
---|---|---|
PDB_UNPROTECTED_STATEFULSET |
Alerta quando existe um StatefulSet em que nenhum rótulo PDB existente corresponde aos rótulos do seletor de pod do StatefulSet. Isso significa que todos os pods no StatefulSet podem ser removidos durante um evento, como um upgrade de nó. | Adicione um PDB com rótulos correspondentes aos do campo do seletor de pod do StatefulSet. Especifique nesse PDB quanto de uma interrupção pode ser tolerada pelo StatefulSet. A recomendação associada a esse insight sugere quais rótulos um PDB precisa definir para cobrir o StatefulSet mencionado. |
PDB_UNPERMISSIVE |
Alerta quando é impossível aderir a um PDB correspondente a um pod para qualquer atividade de manutenção, como um upgrade de nó. Um PDB precisa permitir que pelo menos um pod seja interrompido. Portanto, o GKE viola esse PDB para manutenção necessária após uma hora. | Ajuste a configuração minAvailable do PDB para que seja menor que a contagem total de pods ou a configuração maxUnavailable para maior que zero. |
PDB_STATEFULSET_WITHOUT_PROBES |
Alerta quando um StatefulSet é configurado com um PDB, mas sem sondagens de prontidão. Portanto, o PDB não é tão eficaz em avaliar a prontidão do aplicativo. Os PDBs respeitam as sondagens de prontidão ao analisar quais pods podem ser contados como íntegros. Portanto, se um pod coberto por um PDB não tiver uma sondagem de prontidão configurada, ele terá visibilidade limitada para verificar se o pod está íntegro ou se está funcionando. | Adicione sondagens de preparo a pods em StatefulSets para o PDB mencionado no insight. Também recomendamos que você adicione sondagens de ativação. |
Implemente as orientações para melhorar a prontidão da interrupção
Se você recebeu insights e recomendações para cargas de trabalho no seu cluster e quer melhorar a prontidão de interrupção, implemente as instruções descritas na recomendação e a ação para esse subtipo de insight, conforme visto no seção anterior.
As recomendações são avaliadas uma vez por dia. Portanto, pode levar até 24 horas para que elas sejam resolvidas após a implementação das alterações. Caso tenha se passado menos de 24 horas desde que você implementou a orientação da recomendação, marque-a como resolvida. Se você não quiser implementar a recomendação, dispense-a.
A seguir
- Para saber mais sobre como garantir confiabilidade e tempo de atividade do cluster do GKE, consulte Práticas recomendadas de operações do GKE Day 2.
- Para saber mais sobre possíveis interrupções nos pods no Kubernetes, consulte Interrupções.