O Google Distributed Cloud foi concebido para limitar o âmbito das falhas e dar prioridade à funcionalidade essencial para a continuidade operacional. Este documento explica como a funcionalidade dos seus clusters é afetada quando ocorre uma falha. Estas informações podem ajudar a dar prioridade às áreas a resolver se tiver um problema.
A funcionalidade essencial do Google Distributed Cloud inclui as seguintes categorias:
- Executar cargas de trabalho: as cargas de trabalho existentes podem continuar a ser executadas. Esta é a consideração mais importante para manter a continuidade do negócio. Mesmo que o seu cluster tenha um problema, as cargas de trabalho existentes podem continuar a ser executadas sem interrupção.
- Gerir cargas de trabalho: pode criar, atualizar e eliminar cargas de trabalho. Esta é a segunda consideração mais importante para dimensionar as cargas de trabalho quando o tráfego aumenta, mesmo que o cluster tenha um problema.
- Gerir clusters de utilizadores: pode gerir nós, atualizar, fazer a atualização e eliminar clusters de utilizadores. Isto é menos importante do que as considerações sobre o ciclo de vida da aplicação. Se houver capacidade disponível nos nós existentes, a incapacidade de modificar os clusters de utilizadores não afeta as cargas de trabalho dos utilizadores.
- Gerir clusters de administrador: pode atualizar o cluster de administrador.
- Para implementações que usam clusters de administrador e de utilizador separados, esta é a consideração menos importante, porque o cluster de administrador não aloja cargas de trabalho de utilizador. Se o cluster de administrador tiver um problema, as cargas de trabalho da aplicação noutros clusters continuam a ser executadas sem interrupções.
- Se usar outros modelos de implementação, como híbrido ou autónomo, o cluster de administrador executa cargas de trabalho de aplicações. Se o cluster de administrador tiver um problema e o plano de controlo estiver inativo, também não pode gerir cargas de trabalho de aplicações nem componentes do cluster de utilizador.
As secções seguintes usam estas categorias de funcionalidade essencial para descrever o impacto de tipos específicos de cenários de falha. Quando existe uma interrupção no âmbito de um cenário de falha, a duração (ordem) da interrupção também é registada, sempre que possível.
Falhas de nós
Um nó no Google Distributed Cloud pode deixar de funcionar ou ficar inacessível na rede. Consoante o conjunto de nós e o cluster do qual a máquina com falhas faz parte, existem vários modos de falha diferentes.
Nó do plano de controlo
A tabela seguinte descreve o comportamento dos nós que fazem parte do plano de controlo no Google Distributed Cloud:
| Execute cargas de trabalho | Faça a gestão das cargas de trabalho | Faça a gestão de clusters de utilizadores | Faça a gestão de clusters de administrador | |
|---|---|---|---|---|
| Interrupção (duração) | Sem interrupções | Possível interrupção (desconhecida) | Possível interrupção (desconhecida) | Possível interrupção (desconhecida) |
| Explicação | — | Se a falha do nó afetar o único nó do plano de controlo num cluster de utilizadores de não alta disponibilidade (HA) ou afetar, pelo menos, metade dos nós do plano de controlo num cluster de utilizadores de HA, ocorre uma interrupção. O quórum do plano de controlo do cluster de utilizadores é perdido. | Se a falha do nó afetar o nó do plano de controlo único num cluster de administrador não HA, ou se afetar, pelo menos, metade dos nós do plano de controlo num cluster de administrador HA, ocorre uma interrupção. O quórum do plano de controlo do cluster de administrador é perdido. | Se a falha do nó afetar o nó do plano de controlo único num cluster de administrador não HA, ou se afetar, pelo menos, metade dos nós do plano de controlo num cluster de administrador HA, ocorre uma interrupção. O quórum do plano de controlo do cluster de administrador é perdido. |
| Recuperação | — | Para mais informações, veja como recuperar de uma perda de quórum. | Para mais informações, veja como recuperar de uma perda de quórum. | Para mais informações, veja como recuperar de uma perda de quórum. |
| Prevenção | — | Implemente clusters de utilizadores no modo HA para minimizar a possibilidade de interrupção. | Implemente clusters de administrador no modo de HA para minimizar a possibilidade de interrupção. | Implemente clusters de administrador no modo de HA para minimizar a possibilidade de interrupção. |
Nó do balanceador de carga
A tabela seguinte descreve o comportamento dos nós que alojam os balanceadores de carga no Google Distributed Cloud. Estas orientações aplicam-se apenas aos equilibradores de carga agrupados com o modo de camada 2. Para o balanceamento de carga manual, consulte os modos de falha dos seus balanceadores de carga externos:
| Execute cargas de trabalho | Faça a gestão das cargas de trabalho | Faça a gestão de clusters de utilizadores | Faça a gestão de clusters de 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 dependerem do equilibrador de carga do plano de dados para comunicar com as cargas de trabalho no cluster e tiver apenas um nó do equilibrador de carga, ocorre uma interrupção. | O endereço IP virtual do plano de controlo do cluster de utilizadores reside num nó do equilibrador de carga. Se o grupo de nós do balanceador de carga do cluster do utilizador não for de alta disponibilidade, ocorre uma interrupção. | O endereço IP virtual do plano de controlo do cluster de administrador reside num nó do equilibrador de carga. Se o conjunto de nós do equilibrador de carga do cluster de administrador não for de alta disponibilidade, ocorre uma interrupção. | O endereço IP virtual do plano de controlo do cluster de administrador reside num nó do equilibrador de carga. Se o conjunto de nós do equilibrador de carga do cluster de administrador não for de alta disponibilidade, ocorre uma interrupção. |
| Recuperação | Se existirem vários nós do balanceador de carga, a comutação por falha do MetalLB ocorre em poucos segundos. Se não for HA, considere implementar nós do equilibrador de carga adicionais. |
Se tiver HA, a comutação por falha é automática e demora alguns segundos. Se não for HA, considere implementar nós do equilibrador de carga adicionais |
Se tiver HA, a comutação por falha é automática e demora alguns segundos. Se não for HA, considere implementar nós do equilibrador de carga adicionais. |
Se tiver HA, a comutação por falha é automática e demora alguns segundos. Se não for HA, considere implementar nós do equilibrador de carga adicionais. |
| Prevenção | Para minimizar a possibilidade de interrupção, implemente grupos de nós do balanceador de carga no modo de HA. | Para minimizar a possibilidade de interrupção, implemente grupos de nós do balanceador de carga no modo de HA. | Para minimizar a possibilidade de interrupção, implemente grupos de nós do balanceador de carga no modo de HA. | Para minimizar a possibilidade de interrupção, implemente conjuntos de nós do balanceador de carga no modo de HA. |
Nó trabalhador
A tabela seguinte descreve o comportamento dos nós de trabalho no Google Distributed Cloud:
| Execute cargas de trabalho | Faça a gestão das cargas de trabalho | Faça a gestão de clusters de utilizadores | Faça a gestão de clusters de administrador | |
|---|---|---|---|---|
| Interrupção (duração) | Possível interrupção (na ordem dos segundos) | Sem interrupções | Sem interrupções | Sem interrupções |
| Explicação | As Se as aplicações do utilizador tiverem capacidade de carga de trabalho adicional e estiverem distribuídas por vários nós, a interrupção não é observável pelos clientes que implementam novas tentativas. Os |
— | — | — |
| Recuperação | Se o cluster não tiver capacidade adicional, tem de implementar mais nós distribuídos por várias zonas de falha e mover as cargas de trabalho com falhas para os novos nós. | — | — | — |
| Prevenção | Implemente nós que se distribuem por várias zonas de falha. Implemente cargas de trabalho com várias réplicas distribuídas por várias zonas de falha para minimizar a possibilidade de interrupção. |
— | — | — |
Falha de armazenamento
O armazenamento no Google Distributed Cloud pode deixar de funcionar ou ficar inacessível na rede. Consoante o armazenamento que falha, existem vários modos de falha diferentes.
etcd
O conteúdo dos diretórios /var/lib/etcd e /var/lib/etcd-events pode ficar danificado se houver um desligamento inesperado do nó ou uma falha subjacente do armazenamento. A tabela seguinte descreve o comportamento da funcionalidade principal devido a falhas de etcd:
| Execute cargas de trabalho | Faça a gestão das cargas de trabalho | Faça a gestão de clusters de utilizadores | Faça a gestão de clusters de administrador | |
|---|---|---|---|---|
| Interrupção (duração) | Sem interrupções | Possível interrupção (desconhecida) | Possível interrupção (desconhecida) | Possível interrupção (desconhecida) |
| Explicação | Se as cargas de trabalho existentes não dependerem do plano de controlo do Kubernetes, continuam a funcionar sem interrupções. | Se a etcd falhar num único cluster de utilizadores do plano de controlo ou falhar em, pelo menos, metade dos nós do plano de controlo num cluster de utilizadores de HA, existe uma interrupção. O quórum do plano de controlo do cluster do utilizador é perdido. |
Se a etcd falhar num único cluster de administrador do plano de controlo ou falhar em, pelo menos, metade dos nós do plano de controlo num cluster de administrador de HA, existe uma interrupção. O quórum do plano de controlo do cluster de administrador é perdido. |
Se a etcd falhar num único cluster de administrador do plano de controlo ou falhar em, pelo menos, metade dos nós do plano de controlo num cluster de administrador de HA, existe uma interrupção. O quórum do plano de controlo do cluster de administrador é perdido. |
| Recuperação | — | Para mais informações, veja como recuperar de uma perda de quórum. | Para mais informações, veja como recuperar de uma perda de quórum. | Para mais informações, veja como recuperar de uma perda de quórum. |
| Prevenção | — | Para minimizar a possibilidade de interrupção, implemente clusters de utilizadores no modo de HA. | Para minimizar a possibilidade de interrupção, implemente clusters de administrador no modo de HA. | Para minimizar a possibilidade de interrupção, implemente clusters de administrador no modo de HA. |
Aplicação do utilizador PersistentVolume
A tabela seguinte descreve o comportamento da funcionalidade essencial devido à falha de um PersistentVolume:
| Execute cargas de trabalho | Faça a gestão das cargas de trabalho | Faça a gestão de clusters de utilizadores | Faça a gestão de clusters de administrador | |
|---|---|---|---|---|
| Interrupção (duração) | Possível interrupção (desconhecida) | Sem interrupções | Sem interrupções | Sem interrupções |
| Explicação | As cargas de trabalho que usam o PersistentVolume com falhas |
— | — | — |
| Recuperação | — | — | — | — |
| Prevenção | Para minimizar a possibilidade de interrupção, implemente a carga de trabalho do utilizador no modo de alta disponibilidade. | — | — | — |
Disco corrompido do Fluent Bit
A danificação de um disco do Fluent Bit não afeta nenhuma funcionalidade essencial, mas afeta a capacidade de recolher e inspecionar registos no Google Cloud.
Por vezes, o evento SIGSEGV pode ser observado nos registos de stackdriver-log-forwarder. Este erro pode ser causado pelos registos em buffer danificados no disco.
O Fluent Bit tem um mecanismo para filtrar e eliminar os fragmentos danificados. Esta funcionalidade está disponível na versão fluent-bit (v1.8.3) usada no Google Distributed Cloud.
Fora de LoadBalancer IPs
Se todos os endereços IP nos conjuntos atribuídos estiverem atualmente ocupados, os serviços LoadBalancer criados recentemente não podem adquirir um endereço IP LoadBalancer. Este cenário afeta a capacidade dos clientes do serviço de comunicar com os serviços LoadBalancer.
Para recuperar desta exaustão de endereços IP, atribua mais endereços IP ao conjunto de endereços modificando o recurso personalizado do cluster.
Validade do certificado
O Google Distributed Cloud gera uma autoridade de certificação (CA) autoassinada durante o processo de instalação do cluster. A CA tem um prazo de validade de 10 anos e é responsável pela geração de certificados, que expiram após um ano. Rode os certificados regularmente para evitar o tempo de inatividade do cluster. Pode rodar os certificados atualizando o cluster, que é o método recomendado. Se não conseguir atualizar o cluster, pode fazer uma rotação de CA a pedido. Para mais informações acerca dos certificados de cluster, consulte Certificados e requisitos de infraestrutura de chaves públicas na documentação do Kubernetes.
Se os certificados do cluster tiverem expirado, têm de ser renovados manualmente.
| Execute cargas de trabalho | Faça a gestão das cargas de trabalho | Faça a gestão de clusters de utilizadores | Faça a gestão de clusters de administrador | |
|---|---|---|---|---|
| Interrupção (duração) | Sem interrupções | Possível interrupção (desconhecida) | Possível interrupção (desconhecida) | Possível interrupção (desconhecida) |
| Explicação | Se as cargas de trabalho do utilizador não comunicarem com os componentes do plano de controlo do Kubernetes, não haverá interrupções. | Se as autoridades de certificação para clusters de utilizadores expirarem, vai ocorrer uma interrupção. | Se as autoridades de certificação dos clusters de administrador expirarem, vai ocorrer uma interrupção. | Se as autoridades de certificação para clusters de utilizadores expirarem, ocorre uma interrupção. |
| Recuperação | — | Siga os passos para renovar manualmente os certificados no cluster de utilizadores. |
Siga os passos para renovar manualmente os certificados no cluster de utilizadores. |
Siga os passos para renovar manualmente os certificados no cluster de utilizadores. |
| Prevenção | Configure monitorizações para a expiração de certificados. Pode encontrar um exemplo
de métrica kubelet_certificate_manager_server_expiration_seconds na lista de métricas. |
|||
Falhas na atualização
| Execute cargas de trabalho | Faça a gestão das cargas de trabalho | Faça a gestão de clusters de utilizadores | Faça a gestão de clusters de administrador | |
|---|---|---|---|---|
| Interrupção (duração) | Sem interrupções | Sem interrupções | Possível interrupção (desconhecida) | Possível interrupção (desconhecida) |
| Explicação | Se a atualização falhar no plano de controlo do cluster de utilizadores, NÃO há interrupções nas cargas de trabalho existentes. Se a atualização falhar num nó de trabalho específico, as cargas de trabalho nesse nó vão ser esgotadas e movidas para outros nós em bom estado, se existir capacidade adicional nos nós em bom estado. |
A atualização é interrompida se um dos nós do painel de controlo não for atualizado. O cluster continua a funcionar se a atualização falhar se o cluster de utilizadores tiver HA. | Se a atualização falhar no painel de controlo do cluster de administrador, ocorre uma interrupção até a atualização terminar. | Se a atualização falhar no painel de controlo do cluster de administrador, ocorre uma interrupção até a atualização terminar. |
| Recuperação | — | — | A atualização é repetível. Para mais informações, veja como diagnosticar problemas de atualização e retomar. | A atualização é repetível. Para mais informações, veja como diagnosticar problemas de atualização e retomar. |
| Prevenção | — | — | Para mais informações, consulte como criar uma cópia de segurança antes da atualização. | Para mais informações, consulte como criar uma cópia de segurança antes da atualização. |
O que se segue?
Para mais informações sobre problemas conhecidos nos produtos e soluções alternativas, consulte o artigo Problemas conhecidos do Google Distributed Cloud.
Se precisar de assistência adicional, contacte o apoio ao cliente do Google Cloud. Também pode consultar o artigo Receber apoio técnico para mais informações sobre recursos de apoio técnico, incluindo o seguinte:
- Requisitos para abrir um registo de apoio técnico.
- Ferramentas para ajudar a resolver problemas, como a configuração do ambiente, os registos e as métricas.
- Componentes suportados.