Esta página descreve as práticas recomendadas que pode seguir ao planear e conceber clusters de tamanho muito grande.
Por que motivo deve planear clusters do GKE grandes
Todos os sistemas informáticos, incluindo o Kubernetes, têm alguns limites arquitetónicos. Exceder os limites pode afetar o desempenho do seu cluster ou, em alguns casos, até causar indisponibilidades. Siga as práticas recomendadas e execute as ações recomendadas para garantir que os seus clusters executam as cargas de trabalho de forma fiável em grande escala.
Limitações de clusters do GKE grandes
Quando o GKE dimensiona um cluster para um grande número de nós, o GKE esforça-se por alterar a quantidade de recursos disponíveis para corresponder às necessidades do seu sistema, mantendo-se dentro dos seus objetivos ao nível do serviço (SLOs). OGoogle Cloud suporta clusters grandes. No entanto, com base no seu exemplo de utilização, tem de considerar as limitações dos clusters grandes para responder melhor aos seus requisitos de escala da infraestrutura.
Esta secção descreve as limitações e as considerações ao conceber clusters GKE grandes com base no número esperado de nós.
Clusters com até 5000 nós
Quando criar a arquitetura do cluster para dimensionar até 5000 nós, considere as seguintes condições:
- Disponível apenas para o cluster regional.
- Apenas disponível para clusters que usam o Private Service Connect.
- A migração de clusters zonais para regionais requer a recriação do cluster para desbloquear um nível de quota de nós superior.
Se espera dimensionar o cluster para além de 5000 nós, contacte o apoio técnico ao cliente da nuvem para aumentar o tamanho do cluster e o limite de quota.
Clusters com mais de 5000 nós
O GKE suporta clusters padrão grandes com até 15 000 nós. Na versão 1.31 e posteriores, o GKE suporta clusters grandes com até 65 000 nós. O limite de 65 000 destina-se a ser usado para executar cargas de trabalho de IA em grande escala.
Se espera dimensionar o seu cluster para 15 000 ou 65 000 nós, conclua as seguintes tarefas:
Considere as seguintes limitações:
- O redimensionador automático de clusters não é suportado. Em alternativa, aumente ou diminua a escala dos seus conjuntos de nós através da API GKE.
- A rede múltipla não é suportada.
- Os serviços com mais de 100 pods têm de ser sem interface.
- Cada pod deve ser executado no seu próprio nó, com exceção dos DaemonSets do sistema. Para definir o agendamento de pods em nós específicos, pode usar a afinidade ou a antiafinidade de pods do Kubernetes.
- A migração de clusters zonais para regionais requer a recriação do cluster para desbloquear um nível de quota de nós superior.
- A migração para clusters que usam o Private Service Connect requer que recrie o cluster para desbloquear o nível de quota de nós mais elevado.
Contacte o apoio técnico ao cliente da nuvem para aumentar o tamanho do cluster e o limite de quotas para 15 000 ou 65 000 nós, consoante as suas necessidades de escalabilidade.
Práticas recomendadas para dividir cargas de trabalho entre vários clusters
Pode executar as suas cargas de trabalho num único cluster grande. Esta abordagem é mais fácil de gerir, mais rentável e oferece uma melhor utilização dos recursos do que vários clusters. No entanto, em alguns casos, tem de considerar dividir a sua carga de trabalho em vários clusters:
- Reveja os exemplos de utilização de vários clusters para saber mais acerca dos requisitos gerais e dos cenários de utilização de vários clusters.
- Além disso, do ponto de vista da escalabilidade, divida o cluster quando este puder exceder um dos limites descritos na secção abaixo ou uma das quotas do GKE. Diminuir qualquer risco de atingir os limites do GKE reduz o risco de tempo de inatividade ou outros problemas de fiabilidade.
Se decidir dividir o cluster, use a gestão de frotas para simplificar a gestão de uma frota com vários clusters.
Limites e práticas recomendadas
Para garantir que a sua arquitetura suporta clusters do GKE em grande escala, reveja os seguintes limites e práticas recomendadas relacionadas. Exceder estes limites pode causar uma degradação do desempenho do cluster ou problemas de fiabilidade.
Estas práticas recomendadas aplicam-se a qualquer cluster Kubernetes predefinido sem extensões instaladas. A extensão de clusters do Kubernetes com webhooks ou definições de recursos personalizados (CRDs) é comum, mas pode restringir a sua capacidade de dimensionar o cluster.
A tabela seguinte expande as principais quotas e limites do GKE. Também deve familiarizar-se com os limites do Kubernetes de código aberto para clusters de grande escala.
Os requisitos da versão do GKE mencionados na tabela aplicam-se aos nós e ao plano de controlo.
| Limite do GKE | Descrição | Práticas recomendadas |
|---|---|---|
| O tamanho da base de dados etcd | O tamanho máximo da base de dados etcd é de 6 GB. Deve monitorizar proativamente o tamanho da base de dados etcd do cluster e configurar alertas para receber notificações quando a utilização se aproximar deste limite. Exceder o limite pode causar problemas no plano de controlo. | Pode usar os seguintes recursos para ajudar a monitorizar a sua utilização:
Para mais informações sobre como responder quando se aproxima do limite, consulte o artigo Identifique clusters onde a utilização do etcd se está a aproximar do limite. |
| Tamanho total dos objetos etcd por tipo | O tamanho total de todos os objetos do tipo de recurso indicado não deve exceder 800 MB. Por exemplo, pode criar 750 MB de instâncias de Pod e 750 MB de segredos, mas não pode criar 850 MB de segredos. Se criar mais de 800 MB de objetos, isto pode fazer com que o Kubernetes ou os controladores personalizados não sejam inicializados e causem interrupções. |
Mantenha o tamanho total de todos os objetos de cada tipo armazenados no etcd abaixo de 800 MB. Isto aplica-se especialmente a clusters que usam muitos segredos ou ConfigMaps de grande dimensão, ou um volume elevado de CRDs. |
| Número de serviços para clusters onde o GKE Dataplane V2 não está ativado | O desempenho do iptables usado pelo kube-proxy degrada-se se ocorrer alguma das seguintes situações:
Este limite é eliminado quando o GKE Dataplane V2 está ativado. |
Mantenha o número de serviços no cluster abaixo de 10 000. Para saber mais, consulte o artigo Expor aplicações através de serviços. |
| Número de serviços por espaço de nomes | O número de variáveis de ambiente geradas para os serviços pode exceder os limites da shell. Isto pode fazer com que os Pods falhem no arranque. |
Mantenha o número de serviços por espaço de nomes abaixo de 5000. Pode recusar o preenchimento dessas variáveis de ambiente. Consulte a documentação sobre como definir Para saber mais, consulte o artigo Expor aplicações através de serviços. |
| Número de pods atrás de um único serviço para clusters onde o GKE Dataplane V2 não está ativado |
Cada nó executa um kube-proxy que usa watches para monitorizar qualquer alteração do serviço. Quanto maior for um cluster, mais dados relacionados com alterações o agente processa. Isto é especialmente visível em clusters com mais de 500 nós. As informações sobre os pontos finais estão divididas
entre Os objetos de ponto final continuam disponíveis para componentes, mas qualquer ponto final acima de 1000 pods é automaticamente truncado. |
Mantenha o número de pods atrás de um único serviço inferior a 10 000. Para saber mais, consulte o artigo sobre expor aplicações através de serviços. |
| Número de pods atrás de um único serviço para clusters onde o GKE Dataplane V2 está ativado |
O GKE Dataplane V2 contém limites no número de pods expostos por um único serviço. O mesmo limite aplica-se aos clusters do Autopilot, uma vez que usam o GKE Dataplane V2. |
No GKE 1.23 e anterior, mantenha o número de pods atrás de um único serviço inferior a 1000. No GKE 1.24 e posterior, mantenha o número de pods atrás de um único serviço inferior a 10 000. Para saber mais, consulte o artigo Expor aplicações através de serviços. |
| Registos de DNS por serviço sem interface |
O número de registos de DNS por serviço sem cabeça é limitado para o kube-dns e o Cloud DNS. |
Mantenha o número de registos de DNS por serviço sem cabeça abaixo de 1000 para o kube-dns e 3500/2000 (IPv4/IPv6) para o Cloud DNS. |
| Número de todos os pontos finais de serviço | O número de pontos finais em todos os serviços pode atingir limites. Isto pode aumentar a latência de programação ou resultar na incapacidade de programar novos pontos finais. |
Mantenha o número de todos os pontos finais em todos os serviços abaixo de 260 000. O GKE Dataplane V2, que é o plano de dados predefinido para o GKE Autopilot, baseia-se em mapas eBPF que estão atualmente limitados a 260 000 pontos finais em todos os serviços. |
| Número de objetos do redimensionador automático horizontal de pods por cluster |
Cada redimensionador automático horizontal de pods (HPA) é processado a cada 15 segundos. Mais de 300 objetos HPA podem causar uma degradação linear do desempenho. |
Mantenha o número de objetos HPA dentro deste limite. Caso contrário, pode ocorrer uma degradação linear da frequência de processamento de HPA. Por exemplo,no GKE 1.22 com 2000 HPAs, um único HPA é novamente processado a cada 1 minuto e 40 segundos. Para saber mais, consulte a autoscaling com base na utilização de recursos e a escalabilidade da autoscaling horizontal de pods. |
| Número de pods por nó | O GKE tem um limite rígido de 256 pods por nó. Isto pressupõe uma média de dois ou menos contentores por agrupamento. Se aumentar o número de contentores por Pod, este limite pode ser inferior porque o GKE atribui mais recursos por contentor. |
Recomendamos que use nós de trabalho com, pelo menos, uma vCPU por cada 10 pods. Para saber mais, consulte o artigo sobre como atualizar manualmente um cluster ou um conjunto de nós. |
| Taxa de alterações de pods |
O Kubernetes tem limites internos que afetam a taxa de criação ou eliminação de pods (churn de pods) em resposta a pedidos de escalabilidade. Fatores adicionais, como a eliminação de um pod que faz parte de um serviço, também podem afetar esta taxa de rotatividade de pods. Para clusters com até 500 nós, pode esperar uma taxa média de 20 pods criados por segundo e 20 pods eliminados por segundo. Para clusters com mais de 500 nós, pode esperar uma taxa média de 100 pods criados por segundo e 100 pods eliminados por segundo. |
Tenha em consideração o limite de taxa de criação e eliminação de pods quando planear como dimensionar as suas cargas de trabalho. Os pods partilham a mesma taxa de transferência de eliminação com outros tipos de recursos (por exemplo, EndpointSlices). Pode reduzir o débito de eliminação quando define pods como parte de um serviço. Para permitir que o Cluster Autoscaler remova eficazmente pods de nós subutilizados, evite PodDisruptionBudgets demasiado restritivos e períodos de tolerância de rescisão longos. As tolerâncias com carateres universais também são desaconselhadas, uma vez que podem fazer com que as cargas de trabalho sejam agendadas em nós que estão em processo de remoção. |
| Número de relógios abertos | Os nós criam uma observação para cada segredo e ConfigMaps que configurar para os pods. A quantidade combinada de observações criadas por todos os nós pode gerar uma carga substancial no plano de controlo do cluster. Ter mais de 200 000 observações por cluster pode afetar o tempo de inicialização do cluster. Este problema pode fazer com que o plano de controlo seja reiniciado com frequência. |
Defina nós maiores para diminuir a probabilidade e a gravidade dos problemas causados por um grande número de observações. Uma densidade de pods mais elevada (menos nós de grande dimensão) pode reduzir o número de monitorizações e mitigar a gravidade do problema. Para saber mais, consulte a comparação das séries de máquinas. |
| Número de segredos por cluster se a encriptação de segredos da camada de aplicação estiver ativada | Um cluster tem de desencriptar todos os segredos durante o arranque do cluster quando a encriptação de segredos da camada de aplicação está ativada. Se armazenar mais de 30 000 segredos, o cluster pode ficar instável durante o arranque ou as atualizações, o que provoca interrupções da carga de trabalho. | Armazene menos de 30 000 Secrets quando usar a encriptação de Secrets da camada de aplicação. Para saber mais, consulte o artigo sobre como encriptar segredos na camada de aplicação. |
| Registe a largura de banda por nó |
Existe um limite para a quantidade máxima de registos enviados por cada nó para a API Cloud Logging. O limite predefinido varia entre 100 Kbps e 500 Kbps, consoante a carga. Para clusters padrão, pode aumentar o limite para 10 MiB implementando uma configuração do agente de registo de elevado débito. Exceder este limite pode fazer com que as entradas de registo sejam ignoradas. |
Configure o registo em registo para permanecer dentro dos limites predefinidos ou configure um agente de registo em registo de elevado débito. Para saber mais, consulte o artigo Ajustar o débito do registo. |
| Node pools | Ter um grande número de conjuntos de nós pode afetar a latência do dimensionamento automático da infraestrutura, porque aumenta o conjunto de nós que podem ser potencialmente adicionados ao cluster. As funcionalidades como a separação de cargas de trabalho ou as classes de computação personalizadas aumentam o número de pools de nós. | Mantenha o número de pools de nós abaixo de 200. |
| Limites da Cópia de segurança do GKE |
Pode usar a cópia de segurança do GKE para fazer cópias de segurança e restaurar as suas cargas de trabalho do GKE. A Cópia de segurança do GKE está sujeita a limites que tem de ter em atenção ao definir os seus planos de cópia de segurança. |
Reveja os limites da Cópia de segurança do GKE. Se for possível que a sua carga de trabalho exceda estes limites, recomendamos que crie vários planos de cópia de segurança para particionar a cópia de segurança e permanecer dentro dos limites. |
| Limites do Config Connector |
Pode usar o Config Connector para gerir Google Cloud recursos através do Kubernetes. O Config Connector tem dois modos de funcionamento:
|
Para ver detalhes sobre os limites de recursos, consulte as diretrizes de escalabilidade do controlador de configuração. Para informações sobre a gestão de um grande número de recursos, consulte as práticas recomendadas do Config Connector. |