O GKE em Bare Metal foi projetado para limitar o escopo das falhas e priorizar funcionalidades essenciais para a continuidade dos negócios. Neste documento, explicamos como a funcionalidade dos clusters é afetada quando há uma falha. Essas informações podem ajudar você a priorizar áreas a serem resolvidas.
Se precisar de mais ajuda, entre em contato com o Cloud Customer Care.A funcionalidade principal do GKE em Bare Metal inclui as seguintes categorias:
- Executar cargas de trabalho: as cargas de trabalho atuais podem continuar em execução. Essa é a consideração mais importante para manter a continuidade dos negócios. Mesmo que o cluster tenha um problema, as cargas de trabalho atuais podem continuar em execução sem interrupção.
- Gerencie cargas de trabalho: é possível criar, atualizar e excluir cargas de trabalho. Essa é a segunda consideração mais importante para escalonar cargas de trabalho quando o tráfego aumenta, mesmo que o cluster tenha um problema.
- Gerenciar clusters de usuários: é possível gerenciar nós, atualizar, fazer upgrade e excluir clusters de usuários. Isso é menos importante do que as considerações sobre o ciclo de vida do aplicativo. Se houver capacidade disponível nos nós existentes, a incapacidade de modificar clusters de usuário não afetará as cargas de trabalho do usuário.
- Gerenciar clusters de administrador: é possível atualizar e fazer upgrade do cluster de administrador.
- Para implantações que usam clusters de administrador e usuário separados, essa é a consideração menos importante, porque o cluster de administrador não hospeda nenhuma carga de trabalho do usuário. Se o cluster de administrador tiver um problema, as cargas de trabalho do aplicativo em outros clusters continuarão em execução sem interrupção.
- Se você usar outros modelos de implantação, como híbridos ou independentes, o cluster de administrador executará cargas de trabalho do aplicativo. Se o cluster de administrador tiver um problema e o plano de controle estiver inativo, também não será possível gerenciar cargas de trabalho de aplicativos ou componentes de cluster de usuário.
As seções a seguir usam essas categorias de funcionalidade principal para descrever o impacto de tipos específicos de cenários de falha. Quando há interrupção como parte de um cenário de falha, a duração (ordem) da interrupção também é observada, quando possível.
Falhas nos nós
Um nó no GKE em Bare Metal pode parar de funcionar ou ficar inacessível na rede. Dependendo do pool de nós e do cluster de que a máquina com falha faz parte, há vários modos de falha diferentes.
Nó do plano de controle
Na tabela a seguir, descrevemos o comportamento dos nós que fazem parte do plano de controle do GKE em Bare Metal:
| Executar cargas de trabalho | Gerenciar cargas de trabalho | Gerenciar clusters de usuários | Gerenciar clusters do administrador | |
|---|---|---|---|---|
| Interrupção (duração) | Sem interrupção | Possível interrupção (desconhecido) | Possível interrupção (desconhecido) | Possível interrupção (desconhecido) |
| Explicação | — | Se a falha do nó afetar o único nó do plano de controle em um cluster de usuário não altamente disponível (HA) ou se ele afetar pelo menos metade dos nós do plano de controle em um cluster de usuário de alta disponibilidade, há { 101}. O quórum do plano de controle do cluster de usuário é perdido. | Se a falha do nó afetar um único nó do plano de controle em um cluster de administrador não relacionado a alta disponibilidade ou se ele afetar pelo menos metade dos nós do plano de controle em um cluster de administrador de alta disponibilidade, haverá interrupção. O quórum do plano de controle do cluster de administrador é perdido. | Se a falha do nó afetar um único nó do plano de controle em um cluster de administrador não relacionado a alta disponibilidade ou se ele afetar pelo menos metade dos nós do plano de controle em um cluster de administrador de alta disponibilidade, haverá interrupção. O quórum do plano de controle do cluster de administrador é perdido. |
| Recuperação | — | Para saber mais, veja como se recuperar de uma perda de quórum. | Para saber mais, veja como se recuperar de uma perda de quórum. | Para saber mais, veja como se recuperar de uma perda de quórum. |
| Prevenção | — | Implante clusters de usuários no modo de alta disponibilidade para minimizar a possibilidade de interrupções. | Implante clusters de administrador no modo de alta disponibilidade para minimizar a possibilidade de interrupções. | Implante clusters de administrador no modo de alta disponibilidade para minimizar a possibilidade de interrupções. |
Nó do balanceador de carga
Na tabela a seguir, descrevemos o comportamento dos nós que hospedam os balanceadores de carga no GKE em Bare Metal. Esta orientação se aplica somente aos balanceadores de carga em pacote com o modo de camada 2. Para balanceamento de carga manual, consulte os modos de falha dos seus balanceadores de carga externos:
| Executar cargas de trabalho | Gerenciar cargas de trabalho | Gerenciar clusters de usuários | Gerenciar clusters do administrador | |
|---|---|---|---|---|
| Interrupção (duração) | Possível interrupção (varia) | Possível interrupção (varia) | Possível interrupção (varia) | Possível interrupção (varia) |
| Explicação | Se as cargas de trabalho externas dependem do balanceador de carga do plano de dados para se comunicarem com as do cluster e você tiver apenas um nó, vai haver interrupção. | O endereço IP virtual do plano de controle do cluster de usuário reside em um nó do balanceador de carga. Se o pool de nós do balanceador de carga do cluster de usuário não estiver alta, há uma interrupção. | O endereço IP virtual do plano de controle do cluster de administrador reside em um nó do balanceador de carga. Se o pool de nós do balanceador de carga do cluster de administrador não estiver alta, há uma interrupção. | O endereço IP virtual do plano de controle do cluster de administrador reside em um nó do balanceador de carga. Se o pool de nós do balanceador de carga do cluster de administrador não estiver alta, há uma interrupção. |
| Recuperação | Se houver vários nós do balanceador de carga, o failover do MetalLB acontecerá em alguns segundos. Se não estiver alta disponibilidade, considere implantar outros nós do balanceador de carga. |
Se estiver em alta, o failover é automático e está em ordem de segundos. Se não estiver alta disponibilidade, considere implantar outros nós do balanceador de carga |
Se estiver em alta, o failover é automático e está em ordem de segundos. Se não estiver alta disponibilidade, considere implantar outros nós do balanceador de carga. |
Se estiver em alta, o failover é automático e está em ordem de segundos. Se não estiver alta disponibilidade, considere implantar outros nós do balanceador de carga. |
| Prevenção | Para minimizar a possibilidade de interrupção, implante os pools de nós do balanceador de carga no modo de alta disponibilidade. | Para minimizar a possibilidade de interrupção, implante os pools de nós do balanceador de carga no modo de alta disponibilidade. | Para minimizar a possibilidade de interrupção, implante os pools de nós do balanceador de carga no modo de alta disponibilidade. | Para minimizar a possibilidade de interrupção, implante os pools de nós do balanceador de carga no modo de alta disponibilidade. |
Nó de trabalho
Na tabela a seguir, descrevemos o comportamento dos nós de trabalho no GKE em bare metal:
| Executar cargas de trabalho | Gerenciar cargas de trabalho | Gerenciar clusters de usuários | Gerenciar clusters do administrador | |
|---|---|---|---|---|
| Interrupção (duração) | Possível interrupção (ordem de segundos) | Sem interrupção | Sem interrupção | Sem interrupção |
| Explicação | As Se os aplicativos do usuário tiverem capacidade de carga de trabalho extra e estiverem espalhados por vários nós, a interrupção não é observável por clientes que implementam novas tentativas. O |
— | — | — |
| Recuperação | Se o cluster não tiver capacidade disponível, implante mais nós espalhados por várias zonas de falha e mova as cargas de trabalho com falha para os novos nós. | — | — | — |
| Prevenção | Implante nós espalhados por várias zonas de falha. Implante cargas de trabalho com várias réplicas distribuídas por várias zonas de falha para minimizar a possibilidade de interrupção. |
— | — | — |
Falha no armazenamento
O armazenamento no GKE em Bare Metal pode parar de funcionar ou ficar inacessível na rede. Dependendo do armazenamento com falha, há vários modos de falha diferentes.
etcd
O conteúdo dos diretórios /var/lib/etcd e /var/lib/etcd-events poderá
ser corrompido se houver uma queda de energia do nó ou uma
falha subjacente de armazenamento. A tabela a seguir descreve o comportamento
da funcionalidade principal devido a falhas do etcd:
| Executar cargas de trabalho | Gerenciar cargas de trabalho | Gerenciar clusters de usuários | Gerenciar clusters do administrador | |
|---|---|---|---|---|
| Interrupção (duração) | Sem interrupção | Possível interrupção (desconhecido) | Possível interrupção (desconhecido) | Possível interrupção (desconhecido) |
| Explicação | Se as cargas de trabalho atuais não dependerem do plano de controle do Kubernetes, elas continuarão funcionando sem interrupções. | Se etcd falhar em um único cluster de usuário do plano de controle ou falhar em pelo menos metade dos nós do plano de controle em um cluster de usuário de alta disponibilidade, haverá interrupção. O quórum do plano de controle do cluster de
usuário é perdido. |
Se etcd falhar em um único cluster de administrador do plano de controle ou falhar em menos da metade dos nós do plano de controle em um cluster de administrador de alta disponibilidade, haverá interrupção. O quórum do plano de controle do cluster
de administrador é perdido. |
Se etcd falhar em um único cluster de administrador do plano de controle ou falhar em menos da metade dos nós do plano de controle em um cluster de administrador de alta disponibilidade, haverá interrupção. O quórum do plano de controle do cluster
de administrador é perdido. |
| Recuperação | — | Para saber mais, veja como se recuperar de uma perda de quórum. | Para saber mais, veja como se recuperar de uma perda de quórum. | Para saber mais, veja como se recuperar de uma perda de quórum. |
| Prevenção | — | Para minimizar a possibilidade de interrupção, implante clusters de usuário no modo de alta disponibilidade. | Para minimizar a possibilidade de interrupção, implante clusters de administrador no modo de alta disponibilidade. | Para minimizar a possibilidade de interrupção, implante clusters de administrador no modo de alta disponibilidade. |
Aplicativo do usuário PersistentVolume
A tabela a seguir descreve o comportamento do recurso principal devido à
falha de um PersistentVolume:
| Executar cargas de trabalho | Gerenciar cargas de trabalho | Gerenciar clusters de usuários | Gerenciar clusters do administrador | |
|---|---|---|---|---|
| Interrupção (duração) | Possível interrupção (desconhecido) | Sem interrupção | Sem interrupção | Sem interrupção |
| Explicação | As cargas de trabalho que usam o PersistentVolume com falha |
— | — | — |
| Recuperação | — | — | — | — |
| Prevenção | Para minimizar a possibilidade de interrupção, implante a carga de trabalho do usuário no modo de alta disponibilidade. | — | — | — |
Disco fluente corrompido
A corrupção de um disco do Fluent Bit não afeta as principais funcionalidades, mas afeta a capacidade de coletar e inspecionar registros no Google Cloud.
O evento SIGSEGV às vezes pode ser observado em registros de
stackdriver-log-forwarder. Esse erro pode ser causado pelos registros
armazenados em buffer no disco.
O Fluent Bit tem um mecanismo para filtrar os blocos corrompidos. Esse recurso está disponível na versão fluent-bit (v1.8.3) usada no GKE em Bare Metal.
De LoadBalancer IP
Se todos os endereços IP nos pools atribuídos estiverem ocupados, os serviços
LoadBalancer recém-criados não poderão adquirir um endereço IP LoadBalancer. Esse
cenário afeta a capacidade dos clientes do serviço de se comunicarem com os
serviços LoadBalancer.
Para se recuperar desse esgotamento de endereços IP, atribua mais endereços IP ao pool de endereços modificando o recurso personalizado do cluster.
Validade do certificado
O GKE em Bare Metal gera uma autoridade certificadora (CA) autoassinada durante o processo de instalação do cluster. A CA tem validade de 10 anos e é responsável pela geração de certificados, que expiram após um ano. Alterne os certificados regularmente para evitar a inatividade do cluster. Para fazer isso, faça upgrade do cluster, que é o método recomendado. Se não for possível fazer upgrade do cluster, execute uma rotação de CA sob demanda. Para mais informações sobre certificados de cluster, consulte Certificados e requisitos de ICP na documentação do Kubernetes.
Se os certificados do cluster tiverem expirado, eles precisarão ser renovados manualmente.
| Executar cargas de trabalho | Gerenciar cargas de trabalho | Gerenciar clusters de usuários | Gerenciar clusters do administrador | |
|---|---|---|---|---|
| Interrupção (duração) | Sem interrupção | Possível interrupção (desconhecido) | Possível interrupção (desconhecido) | Possível interrupção (desconhecido) |
| Explicação | Se as cargas de trabalho do usuário não se comunicarem com os componentes do plano de controle do Kubernetes, não haverá interrupções. | Se as autoridades certificadoras dos clusters de usuário expirarem, haverá uma interrupção. | Se as autoridades certificadoras dos clusters de administrador expirarem, haverá uma interrupção. | Se as autoridades certificadores para clusters de usuário expirarem, haverá interrupção. |
| Recuperação | — | Siga as etapas para renovar manualmente os certificados no cluster de usuário. |
Siga as etapas para renovar manualmente os certificados no cluster de usuário. |
Siga as etapas para renovar manualmente os certificados no cluster de usuário. |
| Prevenção | Configure os monitores para expiração do certificado. Um exemplo de
métrica kubelet_certificate_manager_server_expiration_seconds pode
ser encontrado na lista de métricas. |
|||
Falhas no upgrade
| Executar cargas de trabalho | Gerenciar cargas de trabalho | Gerenciar clusters de usuários | Gerenciar clusters do administrador | |
|---|---|---|---|---|
| Interrupção (duração) | Sem interrupção | Sem interrupção | Possível interrupção (desconhecido) | Possível interrupção (desconhecido) |
| Explicação | Se o upgrade falhar no plano de controle do cluster de usuário, não haverá interrupções nas cargas de trabalho atuais. Se o upgrade falhar em um nó de trabalho específico, as cargas de trabalho nele serão drenadas e movidas para outros nós íntegros se houver capacidade extra neles. |
O upgrade será interrompido se um dos nós do plano de controle não for atualizado. O cluster ainda vai funcionar se o upgrade falhar se o cluster de usuário for HA. | Se o upgrade falhar no plano de controle do cluster de administrador, haverá interrupção até que ele seja concluído. | Se o upgrade falhar no plano de controle do cluster de administrador, haverá interrupção até que ele seja concluído. |
| Recuperação | — | — | O upgrade pode ser repetido. Para mais informações, veja como diagnosticar problemas de upgrade e retomar. | O upgrade pode ser repetido. Para mais informações, veja como diagnosticar problemas de upgrade e retomar. |
| Prevenção | — | — | Para saber mais, veja como criar um backup antes do upgrade. | Para saber mais, veja como criar um backup antes do upgrade. |
A seguir
Para mais informações sobre problemas conhecidos do produto e soluções alternativas, confira Problemas conhecidos do GKE em Bare Metal.
- Se precisar de mais ajuda, entre em contato com o Cloud Customer Care.