Esta página descreve as práticas recomendadas que pode seguir quando gerir cargas de trabalho grandes em vários clusters do GKE. Estas práticas recomendadas abrangem considerações para distribuir cargas de trabalho por vários projetos e ajustar as quotas necessárias.
Práticas recomendadas para distribuir cargas de trabalho do GKE por vários Google Cloud projetos
Para definir melhor a Google Cloud estrutura do projeto e a distribuição das cargas de trabalho do GKE, com base nos requisitos da sua empresa, recomendamos que considere as seguintes ações de conceção e planeamento:
- Siga as orientações em Decida uma hierarquia de recursos para a sua Google Cloud zona de destino para tomar decisões iniciais sobre a estrutura da sua organização para pastas e projetos. Google Cloud recomenda a utilização de elementos da hierarquia de recursos como pastas e projetos para dividir a sua carga de trabalho com base nos seus próprios limites organizacionais ou políticas de acesso.
- Considere se precisa de dividir as suas cargas de trabalho devido às quotas do projeto. Google Cloud usa quotas por projeto para restringir a utilização de recursos partilhados. Tem de seguir as recomendações descritas abaixo e ajustar as quotas do projeto para cargas de trabalho grandes. Para a maioria das cargas de trabalho, deve conseguir atingir as quotas necessárias e mais elevadas num único projeto. Isto significa que as quotas não devem ser o principal fator para dividir a sua carga de trabalho entre vários projetos. Manter as cargas de trabalho num número menor de projetos simplifica a administração das quotas e das cargas de trabalho.
- Pondere se planeia executar cargas de trabalho muito grandes (escala de centenas de milhares de CPUs ou mais). Nesse caso, dividir a carga de trabalho em vários projetos pode aumentar a disponibilidade de recursos na nuvem (como CPUs ou GPUs). Isto é possível devido à utilização da configuração otimizada da virtualização de zonas. Nesses casos, contacte o seu gestor de conta para receber apoio técnico e recomendações especiais.
Práticas recomendadas para ajustar as quotas para grandes cargas de trabalho do GKE
Esta secção descreve as diretrizes para ajustar as quotas dos Google Cloud recursos usados pelas cargas de trabalho do GKE. Ajuste as quotas dos seus projetos com base nas seguintes diretrizes. Para saber como gerir a sua quota usando a consola, consulte o artigo Ver e gerir quotas. Google Cloud
Práticas recomendadas e quotas do Compute Engine
Os clusters do GKE, executados nos modos Autopilot e Standard, usam recursos do Compute Engine para executar as suas cargas de trabalho. Ao contrário dos recursos do painel de controlo do Kubernetes que são geridos internamente pela Google Cloud, pode gerir e avaliar as quotas do Compute Engine que os seus fluxos de trabalho usam.
As quotas do Compute Engine, tanto para recursos como para APIs, são partilhadas por todos os clusters do GKE alojados no mesmo projeto e região. As mesmas quotas também são partilhadas com outros recursos do Compute Engine (não relacionados com o GKE), como instâncias de VM autónomas ou grupos de instâncias.
Os valores predefinidos da quota podem suportar várias centenas de nós de trabalho e requerem um ajuste para cargas de trabalho maiores. No entanto, como administrador da plataforma, pode ajustar proativamente as quotas do Compute Engine para garantir que os seus clusters do GKE têm recursos suficientes. Também deve considerar as necessidades futuras de recursos ao avaliar ou ajustar os valores da quota.
Quotas para recursos do Compute Engine usados por nós de trabalho do GKE
A tabela seguinte indica as quotas de recursos para os recursos do Compute Engine mais comuns usados pelos nós de trabalho do GKE. Estas quotas são configuradas por projeto e por região. As quotas têm de abranger o tamanho máximo combinado dos nós de trabalho do GKE usados pela sua carga de trabalho e também outros recursos do Compute Engine não relacionados com o GKE.
| Quota de recursos | Descrição |
|---|---|
| CPUs | Número de CPUs usadas por todos os nós de trabalho de todos os clusters. |
| Tipo de CPUs | O número de cada tipo específico de CPU usado por todos os nós de trabalho de todos os clusters. |
| Instâncias de VMs | Número de todos os nós trabalhadores. Esta quota é calculada automaticamente como 10 vezes o número de CPUs. |
| Instâncias por rede da VPC | Número de todos os nós de trabalho ligados à rede VPC. |
| Disco persistente padrão (GB) | Tamanho total dos discos de arranque persistentes padrão anexados a todos os nós de trabalho. |
| Disco persistente SSD (GB) | Tamanho total dos discos de arranque persistentes SSD associados a todos os nós de trabalho. |
| SSD local (GB) | Tamanho total dos discos efémeros SSD locais associados a todos os nós de trabalho. |
Certifique-se de que também ajusta as quotas usadas pelos recursos que a sua carga de trabalho pode exigir, como GPUs, endereços IP ou recursos preemptivos.
Quotas para chamadas da API Compute Engine
Os clusters grandes ou escaláveis requerem um número superior de chamadas API Compute Engine. O GKE faz estas chamadas à API Compute Engine durante atividades como:
- Verificar o estado dos recursos de computação.
- Adicionar ou remover novos nós ao cluster.
- Adicionar ou remover novos conjuntos de nós.
- Etiquetagem periódica de recursos.
Ao planear a arquitetura do cluster de grande dimensão, recomendamos que faça o seguinte:
- Observe o consumo de quotas do histórico.
- Ajuste as quotas conforme necessário, mantendo uma margem razoável. Pode consultar as seguintes recomendações de práticas recomendadas como ponto de partida e ajustar as quotas com base nas necessidades da sua carga de trabalho.
- Uma vez que as quotas são configuradas por região, ajuste-as apenas nas regiões onde planeia executar cargas de trabalho grandes.
A tabela seguinte lista as quotas para chamadas da API Compute Engine. Estas quotas são configuradas por projeto, de forma independente para cada região. As quotas são partilhadas por todos os clusters do GKE alojados no mesmo projeto e na mesma região.
| Quota da API | Descrição | Práticas recomendadas |
|---|---|---|
| Consultas por minuto por região | Estas chamadas são usadas pelo GKE para realizar várias verificações em relação ao estado dos vários recursos de computação. |
Para projetos e regiões com várias centenas de nós dinâmicos, ajuste este valor para 3500. Para projetos e regiões com vários milhares de nós altamente dinâmicos, ajuste este valor para 6000. |
| Pedidos de leitura por minuto por região | Estas chamadas são usadas pelo GKE para monitorizar o estado das instâncias de VMs (nós). |
Para projetos e regiões com várias centenas de nós, ajuste este valor para 12 000. Para projetos e regiões com milhares de nós, ajuste este valor para 20 000. |
| Pedidos de listagem por minuto por região | Estas chamadas são usadas pelo GKE para monitorizar o estado dos grupos de instâncias (conjuntos de nós). |
Para projetos e regiões com várias centenas de nós dinâmicos, não altere o valor predefinido, pois é suficiente. Para projetos e regiões com milhares de nós altamente dinâmicos, em vários conjuntos de nós, ajuste este valor para 2500. |
| Pedidos de referenciadores da lista de instâncias por minuto por região | Estas chamadas são usadas pelo GKE para obter informações sobre instâncias de VMs (nós) em execução. |
Para projetos e regiões com milhares de nós altamente dinâmicos, ajuste este valor para 6000. |
| Pedidos de leitura de operações por minuto por região | Estas chamadas são usadas pelo GKE para obter informações sobre as operações da API Compute Engine em curso. |
Para projetos e regiões com milhares de nós altamente dinâmicos, ajuste este valor para 3000. |
Quotas e práticas recomendadas da API Cloud Logging e da API Cloud Monitoring
Consoante a configuração do cluster, as cargas de trabalho grandes executadas em clusters do GKE podem gerar um grande volume de informações de diagnóstico. Quando excede as quotas da API Cloud Logging ou da API Cloud Monitoring, os dados de registo e monitorização podem ser perdidos. Recomendamos que configure o nível de detalhe dos registos e ajuste as quotas da API Cloud Logging e da API Cloud Monitoring para capturar informações de diagnóstico geradas. O Managed Service for Prometheus consome cotas do Cloud Monitoring.
Uma vez que cada carga de trabalho é diferente, recomendamos que faça o seguinte:
- Observe o consumo de quotas do histórico.
- Ajuste as quotas ou a configuração de registo e monitorização conforme necessário. Mantenha uma margem razoável para problemas inesperados.
A tabela seguinte apresenta as quotas para chamadas das APIs Cloud Logging e Cloud Monitoring. Estas quotas são configuradas por projeto e são partilhadas por todos os clusters do GKE alojados no mesmo projeto.
| Serviço | Quota | Descrição | Práticas recomendadas |
|---|---|---|---|
| Cloud Logging API | Solicitações de escrita por minuto | O GKE usa esta quota quando adiciona entradas a ficheiros de registo armazenados no Cloud Logging. |
A taxa de inserção de registos depende da quantidade de registos gerados pelos pods no seu cluster. Aumente a sua quota com base no número de pods, na detalhada dos registos de aplicações e na configuração de registo. Para saber mais, consulte o artigo sobre a gestão de registos do GKE. |
| Cloud Monitoring API | Pedidos de carregamento de intervalos temporais por minuto |
O GKE usa esta quota quando envia métricas do Prometheus para o Cloud Monitoring:
|
Monitorize e ajuste esta quota conforme adequado. Para saber mais, consulte o artigo sobre a gestão de métricas do GKE. |
Práticas recomendadas e quota de nós do GKE
O GKE suporta os seguintes limites:
- Até 15 000 nós num único cluster com a quota predefinida definida para 5000 nós. Esta quota é definida separadamente para cada cluster do GKE e não por projeto, como outras quotas.
- Na versão 1.31 e posteriores, o GKE suporta clusters grandes com até 65 000 nós.
Se planeia dimensionar o cluster acima de 5000 nós, siga estes passos:
- Identifique o cluster que quer dimensionar para além de 5000 nós.
- Certifique-se de que a carga de trabalho permanece dentro dos limites do cluster e das quotas do GKE após o dimensionamento.
- Certifique-se de que aumenta as quotas do Compute Engine conforme necessário para a sua carga de trabalho dimensionada.
- Certifique-se de que o tipo de disponibilidade do cluster é regional e que o cluster usa o Private Service Connect.
- Para pedir um aumento da quota do número de nós por cluster, contacte o apoio ao cliente do Google Cloud. A equipa do GKE entra em contacto consigo para garantir que a sua carga de trabalho segue as práticas recomendadas de escalabilidade e está pronta para ser dimensionada para além de 5000 nós num único cluster.
Práticas recomendadas para evitar outros limites para cargas de trabalho grandes
Limite para o número de clusters que usam o intercâmbio da rede da VPC por rede por localização
Pode criar um máximo de 75 clusters que usam o intercâmbio da rede da VPC na mesma rede da VPC por localização (as zonas e as regiões são tratadas como localizações separadas). As tentativas de criar clusters adicionais acima do limite falham com um erro semelhante ao seguinte:
CREATE operation failed. Could not trigger cluster creation:
Your network already has the maximum number of clusters: (75) in location us-central1.
Os clusters do GKE com nós privados criados antes da versão 1.29 usam o peering de rede VPC para fornecer comunicação interna entre o servidor da API Kubernetes (gerido pela Google) e os nós privados que têm apenas endereços internos.
Para resolver este problema, pode usar clusters que usam a conetividade do Private Service Connect (PSC). Os clusters com conetividade PSC oferecem o mesmo isolamento que um cluster que usa o peering de rede VPC, sem a limitação de 75 clusters. Os clusters com conetividade PSC não usam o intercâmbio das redes da VPC e não são afetados pelo limite do número de intercâmbios das VPCs.
Pode usar as instruções fornecidas em Reutilização do intercâmbio da rede da VPC para identificar se os seus clusters usam o intercâmbio da rede da VPC.
Para evitar atingir o limite ao criar novos clusters, siga estes passos:
- Certifique-se de que o seu cluster usa o PSC.
- Configure o isolamento para que os node pools se tornem privados através do parâmetro
enable-private-nodespara cada node pool. - Opcionalmente, configure o isolamento para o plano de controlo usando o parâmetro
enable-private-endpointao nível do cluster. Para saber mais, consulte o artigo Personalize o isolamento da rede.
Em alternativa, contacte a Google Cloud equipa de apoio técnico para aumentar o limite de 75 clusters através da interligação de redes VPC. Esses pedidos são avaliados caso a caso e, quando é possível aumentar o limite, é aplicado um aumento de um único dígito.
Otimize a escalabilidade e a fiabilidade com o HTTP/2
Para executar cargas de trabalho de grande escala no GKE, use o HTTP/2 em vez do HTTP/1.1. O HTTP/2 melhora o desempenho e a fiabilidade da ligação em ambientes de tráfego elevado ou latência elevada.
Vantagens do HTTP/2
Reduz o número de ligações: O HTTP/2 permite-lhe enviar muitos pedidos e receber muitas respostas através de uma ligação. Isto reduz a carga nos componentes do sistema, como balanceadores de carga, proxies e gateways de NAT.
Melhora a consistência do desempenho: com o HTTP/1.1, cada pedido precisa normalmente da sua própria ligação. Se uma ligação tiver problemas, pode atrasar ou interromper o pedido. Por exemplo, se uma ligação TCP perder pacotes ou tiver uma latência elevada, pode afetar todos os pedidos feitos nessa ligação, o que pode causar atrasos ou erros na aplicação. Com o HTTP/2, vários pedidos partilham a mesma ligação, pelo que os problemas de rede afetam todos os pedidos da mesma forma, tornando o desempenho mais previsível.
Inclui funcionalidades integradas para manter as ligações fiáveis:
Controlo de fluxo: o controlo de fluxo ajuda a gerir a quantidade de dados enviados de uma só vez. Impede que os remetentes sobrecarreguem os destinatários e ajuda a evitar o congestionamento da rede.
Frames de ping: os frames de ping são sinais leves que verificam se uma ligação ainda está ativa. Estes sinais ajudam a manter ligações persistentes e a evitar ligações interrompidas causadas por sistemas intermédios (como firewalls ou proxies) que podem fechar ligações inativas.
No HTTP/1.1, as ligações podem ser interrompidas inesperadamente se não houver tráfego durante um determinado período. Esta situação é especialmente comum quando as firewalls ou os proxies fecham ligações inativas para libertar recursos. No HTTP/2, os frames ping mantêm as ligações ativas verificando regularmente o estado da ligação.
Multiplexagem: no HTTP/1.1, quando são enviados vários pedidos ao mesmo tempo através de ligações separadas, a ordem em que as respostas são recebidas pode causar problemas se um pedido depender de outro. Por exemplo, se um pedido for concluído primeiro, mas outro tiver um atraso na rede, o resultado pode ser uma resposta incorreta ou desordenada. Este problema pode causar uma condição de corrida. O HTTP/2 evita esta situação ao fazer a multiplexagem de todos os pedidos através de uma única ligação, o que ajuda a garantir que as respostas estão corretamente alinhadas.
Práticas recomendadas para usar o HTTP/2
- Use o HTTP/2 para aplicações que processam um volume elevado de tráfego ou precisam de comunicação de baixa latência.
- Configure keepalives ao nível da aplicação para manter as ligações abertas. Para mais informações, consulte o artigo Como funcionam as associações.
- Monitorize o seu tráfego para se certificar de que usa o HTTP/2.
Para mais informações, consulte o artigo Suporte de HTTP/2 no Cloud Load Balancing.
O que se segue?
- Veja os nossos episódios sobre como criar clusters do GKE grandes.