Nesta página, descrevemos as práticas recomendadas para planejar e projetar clusters muito grandes.
Por que fazer o planejamento para grandes clusters do GKE
Todo sistema de computação, incluindo o Kubernetes, tem alguns limites de arquitetura. Exceder os limites pode afetar o desempenho do cluster ou pode causar inatividade no mesmo caso. Siga as práticas recomendadas e execute as ações recomendadas para garantir que os clusters executem as cargas de trabalho de maneira confiável em escala.
Práticas recomendadas para dividir cargas de trabalho entre vários clusters
É possível executar suas cargas de trabalho em um cluster grande e único. Essa abordagem é mais fácil de gerenciar, mais econômica e fornece melhor utilização de recursos do que vários clusters. No entanto, em alguns casos, é preciso dividir a carga de trabalho em vários clusters:
- Consulte Casos de uso de vários clusters para saber mais sobre os requisitos gerais e cenários para usar vários clusters.
- Além disso, do ponto de vista da escalonabilidade, divida seu cluster quando ele puder exceder um dos limites descritos na seção abaixo ou uma das cotas do GKE. Reduzir qualquer risco para atingir os limites do GKE, reduz o risco de inatividade ou outros problemas de confiabilidade.
Se você decidir dividir o cluster, use o gerenciamento de frotas para simplificar o gerenciamento de uma frota com vários clusters.
Limites e práticas recomendadas
Para garantir que sua arquitetura seja compatível com clusters de grande escala do GKE, analise os seguintes limites e práticas recomendadas relacionadas. Ultrapassar esses limites pode causar uma degradação no desempenho do cluster ou problemas de confiabilidade.
Essas práticas recomendadas se aplicam a qualquer cluster padrão do Kubernetes sem extensões instaladas. A extensão de clusters do Kubernetes com webhooks ou definições de recursos personalizados (CRDs, na sigla em inglês) é comum, mas pode restringir sua capacidade de escalonar o cluster.
A tabela a seguir estende as principais cotas e limites do GKE. Você também precisa se familiarizar com os limites do Kubernetes de código aberto para clusters de grande escala.
Os requisitos de versão do GKE mencionados na tabela se aplicam aos nós e ao plano de controle.
| Limite do GKE | Descrição | Práticas recomendadas |
|---|---|---|
| O tamanho do banco de dados etcd | O tamanho máximo do banco de dados etcd é de 6 GB. Se você estiver executando um cluster muito grande com dezenas de milhares de recursos, as instâncias do etcd poderão exceder esse limite. É possível verificar o nível de utilização dos clusters no console do Google Cloud. | Se você ultrapassar esse limite, o GKE poderá marcar as instâncias do etcd
como não íntegras. Isso faz com que o plano de controle
dos clusters não responda.
Se você ultrapassar esse limite, entre em contato com o suporte do Google Cloud. |
| Tamanho total dos objetos etcd por tipo | O tamanho total de todos os objetos do tipo de recurso fornecido não pode exceder 800 MB. Por exemplo, é possível criar 750 MB de instâncias de pod e 750 MB de Secrets, mas não 850 MB de Secrets. Se você criar mais de 800 MB de objetos, isso pode fazer com que o Kubernetes ou os controladores personalizados não inicializem e causem interrupções. |
Mantenha o tamanho total de todos os objetos de cada tipo armazenados no etcd abaixo de 800 MB. Isso se aplica especialmente a clusters que usam muitos Secrets ou ConfigMaps de tamanho grande ou um grande volume de CRDs. |
| Número de serviços para clusters em que o GKE Dataplane V2 não está ativado | O desempenho de iptables usado pelo kube-proxy será afetado se alguma das seguintes situações ocorrer:
Esse 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 Como expor aplicativos usando serviços. |
| Número de serviços por namespace | O número de variáveis de ambiente geradas para os Serviços pode ultrapassar os limites do shell. Isso pode causar falhas nos pods na inicialização. |
Mantenha o número de serviços por namespace abaixo de 5.000. É possível desativar o preenchimento dessas variáveis de ambiente. Consulte a documentação para saber como definir Saiba mais em Como expor aplicativos usando os serviços. |
| Número de pods por trás de um único serviço para clusters em que o GKE Dataplane V2 não está ativado |
Cada nó executa um kube-proxy que usa relógios para monitorar qualquer alteração de serviço. Quanto maior for o cluster, mais dados relacionados a alterações serão processados pelo agente. Isso é especialmente visível em clusters com mais de 500 nodes. As informações sobre os endpoints são divididas
entre Os objetos de endpoint ainda estão disponíveis para componentes, mas qualquer endpoint com mais de mil pods é truncado automaticamente. |
Mantenha o número de pods protegidos por um serviço menor que 10 mil. Saiba mais em Como expor aplicativos usando serviços. |
| Número de pods por trás de um único serviço para clusters em que o GKE Dataplane V2 está ativado |
O GKE Dataplane V2 contém limites para o número de pods expostos por um único serviço. O mesmo limite é aplicável aos clusters do Autopilot que usam o GKE Dataplane V2. |
No GKE 1.23 e versões anteriores, mantenha o número de pods por trás de um único serviço menor que 1.000. No GKE 1.24 e posterior, mantenha o número de pods por trás de um único serviço menor que 10.000. Para saber mais, consulte Como expor aplicativos usando serviços. |
| Registros DNS por serviço sem comando |
O número de registros DNS por serviço headless é limitado para kube-dns e Cloud DNS. |
Mantenha o número de registros DNS por serviço headless abaixo de 1.000 para kube-dns e 3.500/2.000 (IPv4/IPv6) para Cloud DNS. |
| Número de todos os endpoints de serviço | O número de endpoints em todos os Serviços pode atingir os limites. Isso pode aumentar a latência da programação ou resultar em uma impossibilidade de programar novos endpoints. |
Mantenha o número de endpoints em todos os serviços abaixo de 64.000. O GKE Dataplane V2, que é o plano de dados padrão do GKE, depende de mapas do eBPF que estão atualmente limitados a 64.000 endpoints em todos os Serviços. |
| Número de objetos do escalonador automático horizontal de pods por cluster |
Cada escalonador automático de pod horizontal (HPA) é processado a cada 15 segundos. Ter mais de 300 objetos de HPA pode causar degradação linear do desempenho. |
Mantenha o número de objetos de HPA dentro do limite. Caso contrário, você poderá notar uma degradação linear da frequência de processamento de HPA. Por exemplo,no GKE 1.22 com 2.000 HPAs, um único HPA será reprocessado a cada 1 minuto e 40 segundos. Para saber mais, consulte Escalonamento automático com base no uso de recursos e escalonamento automático horizontal do pod horizontal. |
| Número de pods por nó | O GKE tem um limite absoluto de 256 pods por node. Isso pressupõe uma média de dois ou menos contêineres por pod. Se você aumentar o número de contêineres por pod, esse limite poderá ser menor porque o GKE aloca mais recursos por contêiner. |
Recomendamos o uso de nodes de trabalho com pelo menos uma vCPU a cada 10 pods. Para saber mais, consulte Como fazer upgrade manual de um cluster ou pool de nodes. |
| Taxa de alterações no pod. |
O Kubernetes tem limites internos que afetam a taxa de criação ou exclusão de pods (desligamento de pods) em resposta ao escalonamento de solicitações. Outros fatores, como exclusão de um pod que faz parte de um Serviço, também podem afetar essa taxa de desligamento de pods. Nos clusters com até 500 nós, a taxa média é de 20 pods criados por segundo e 10 pods excluídos por segundo. Para clusters com mais de 500 nós, a taxa média é de 100 pods criados por segundo e 50 pods excluídos por segundo. |
Considere a limitação da taxa de criação e exclusão de pods ao planejar como escalonar as cargas de trabalho. Os pods compartilham a mesma capacidade de exclusão com outros tipos de recursos (por exemplo, EndpointSlices). É possível reduzir a capacidade de exclusão ao definir pods como parte de um serviço. Para permitir que o escalonador automático de cluster remova efetivamente os pods de nós subutilizados, evite PodDisruptionBudgets muito restritivos e períodos de carência de encerramento longos. As tolerâncias de caracteres curinga também não são recomendadas, porque podem fazer com que as cargas de trabalho sejam programadas em nós que estão em processo de remoção. |
| Número de relógios abertos | Os nodes criam um relógio para cada Secret e ConfigMaps que você configura para pods. A quantidade combinada de relógios criados por todos os nodes pode gerar uma carga significativa no plano de controle do cluster. Ter mais de 200 mil visualizações por cluster pode afetar o tempo de inicialização do cluster. Esse problema pode fazer com que o plano de controle seja reiniciado com frequência. |
Definir nós maiores para diminuir a probabilidade e a gravidade dos problemas causados por um grande número de relógios. Uma densidade de pods mais alta (menos nodes de tamanho grande) pode reduzir o número de verificações e reduzir a gravidade do problema. Para saber mais, consulte a comparação de séries de máquina. |
| Número de secrets por cluster se a criptografia de secrets na camada de aplicativos estiver ativada | Um cluster precisa descriptografar todos os secrets durante a inicialização quando a criptografia de secrets da camada de aplicativos está ativada. Se você armazenar mais de 30.000 secrets, o cluster poderá ficar instável durante a inicialização ou upgrades, causando falhas temporárias de carga de trabalho. | Armazene menos de 30.000 secrets ao usar a criptografia de secrets na camada de aplicativos. Para saber mais, consulte Criptografar secrets na camada do aplicativo. |
| Largura de banda de registro por nó |
Há um limite na quantidade máxima de registros enviados por cada node para a API Cloud Logging. O limite padrão varia entre 100 Kbps e 500 Kbps, dependendo da carga. É possível elevar o limite para 10 Mbps implantando uma configuração de agente do Logging de alta capacidade de processamento. Se você ultrapassar esse limite, as entradas de registro poderão ser descartadas. |
Configure a geração de registros para permanecer dentro dos limites padrão ou configure um agente do Logging de alta capacidade. Para saber mais, consulte Como aumentar a capacidade do agente do Logging. |
| Limites do Backup para GKE |
É possível usar o Backup para GKE para fazer backup e restaurar as cargas de trabalho do GKE. O Backup para GKE está sujeito a limites que precisam ser considerados ao definir os planos de backup. |
Analise os limites do Backup para GKE. Se for possível que sua carga de trabalho exceda esses limites, recomendamos criar vários planos de backup para particionar o backup e permanecer dentro dos limites. |
| Limites do Config Connector |
É possível usar o Config Connector para gerenciar recursos do Google Cloud por meio do Kubernetes. O Config Connector tem dois modos de operação:
|
Cada instância do Config Connector tem uma solicitação de CPU 0,1 e um limite de memória de 512 MB. Portanto, ele não tem bom escalonamento para uma grande quantidade de recursos gerenciados. Recomendamos que você não tenha mais de 25.000 recursos do Google Cloud por instância única do Config Connector. Essa limitação é apenas para fins de referência porque a quantidade de memória usada depende do tipo de recurso e de casos de uso específicos. Ao gerenciar um número maior de recursos gerenciados, recomendamos o uso do modo de namespace para limitar o número de recursos manipulados por cada instância do Config Connector. Recomendamos usar até 500 namespaces com o Config Connector no modo de namespace.
Cada instância do Config Connector abre muitas conexões
watch
para o kube-apiserver. Um grande número dessas instâncias pode sobrecarregar o plano de controle do cluster do GKE,
especialmente durante upgrades do plano de controle, quando as conexões do relógio precisam ser reinicializadas. Recomendamos o uso de vários clusters do GKE para gerenciar o número de recursos que não puderam ser divididos para se ajustarem aos limites especificados acima. Consulte as diretrizes de escalonabilidade do Config Controller para saber mais detalhes. |