Nesta página, descrevemos as práticas recomendadas para criar, configurar e operar clusters do Google Distributed Cloud para acomodar cargas de trabalho que se aproximem dos limites de escalonabilidade do Kubernetes.
Regras de nome do cluster
Para cada projeto do Google Cloud:
- Cada cluster de usuário precisa ter um nome exclusivo em todos os clusters de administrador que estejam dentro de um único projeto do Google Cloud.
Limites de escalonabilidade
Considere os seguintes limites ao projetar seus aplicativos no GKE no VMware:
Cada cluster de administrador é compatível com até 100 clusters de usuário, incluindo clusters de alta disponibilidade (HA, na sigla em inglês) e clusters de não alta disponibilidade, usando o modo de balanceamento de carga agrupado (Seesaw ou MetalLB) ou o modo de balanceamento de carga integrado (F5).
Cada cluster de usuário é compatível com até:
500 nós usando o modo de balanceamento de carga em pacote (Seesaw ou MetalLB) ou 250 nós usando o modo de balanceamento de carga integrado (F5)
15,000 Pods
500 serviços LoadBalancer usando o modo de balanceamento de carga agrupado (Seesaw ou MetalLB) ou 250 LoadBalancer Services usando o modo de balanceamento de carga integrado (F5).
Para cada nó, é possível criar no máximo 110 pods (cada pod pode consistir em 1 a 2 contêineres). Isso inclui pods que executam serviços complementares do sistema.
Noções básicas sobre os limites
Como o GKE no VMware é um sistema complexo com uma grande superfície de integração, a escalonabilidade de cluster envolve muitas dimensões relacionadas. Por exemplo, o GKE no VMware pode escalonar pelo número de nós, pods ou Serviços. A extensão de mais de uma dimensão no momento pode causar problemas mesmo em clusters menores. Por exemplo, programar 110 pods por nó em um cluster de 500 nós pode sobrecarregar o número de pods, pods por nó e nós.
Veja os Limites de escalonabilidade do Kubernetes para mais detalhes.
Os limites de escalabilidade também são confidenciais para a configuração e o hardware do vSphere em que seu cluster está sendo executado. Esses limites são verificados em um ambiente que é provavelmente diferente do seu. Portanto, talvez o ambiente não seja o fator limitante para reproduzir os números exatos.
Como se preparar para escalonar
Ao se preparar para escalonar os clusters de administrador ou os clusters de usuários, considere os requisitos e limitações a seguir.
Requisitos de armazenamento, CPU e memória
Consulte os requisitos de CPU, RAM e armazenamento para cada VM individual.
Requisitos de E/S de disco e rede
As cargas de trabalho com uso intensivo de dados e alguns componentes do plano de controle são sensíveis à latência de E/S do disco e da rede. Por exemplo, 500 IOPS sequenciais (por exemplo, um SSD local típico ou um dispositivo de bloco virtualizado de alto desempenho) normalmente são necessários para desempenho e estabilidade do etcd em um cluster com dezenas de nós e milhares de pods.
Endereço IP do nó
Cada nó do GKE no VMware requer um endereço IP ou DHCP atribuído estaticamente.
Por exemplo, 307 endereços IP são necessários em uma configuração com um cluster de usuário que não seja de alta disponibilidade com 50 nós e um cluster de usuário de alta disponibilidade com 250 nós.
A tabela a seguir mostra o detalhamento dos endereços IP:
| Tipo de nó | Número de endereços IP |
|---|---|
| VMs do plano de controle do cluster de administrador | 3 |
| VM do plano de controle do cluster do usuário 1 (não HA) | 1 |
| VMs de nó de trabalho do cluster de usuário 1 | 50 |
| VMs do plano de controle do cluster do usuário 2 (HA) | 3 |
| VMs de nós de trabalho do cluster de usuário 2 | 250 |
| Total | 307 |
Como executar vários clusters de usuários em um cluster de administrador
Ao se preparar para executar muitos clusters de usuário em um cluster de administrador, execute as etapas a seguir ao criar o cluster de administrador.
Bloco de CIDR de pod no cluster de administrador
O bloco de CIDR de pod é o bloco de CIDR de todos os pods em um cluster de administrador. Ele é configurado por meio do campo network.podCIDR no admin-cluster.yaml.
A partir desse intervalo, blocos /24 menores são atribuídos a cada nó. Se todos os clusters de usuário tiverem o Controlplane V2 ativado, o cluster de administrador terá apenas três nós e haverá muitos endereços IP de pod disponíveis. No entanto, cada vez que você cria um cluster de usuário que usa o kubeception em vez do Controlplane V2, um ou três nós são adicionados ao cluster de administrador:
Cada cluster de usuário do kubeception de alta disponibilidade (HA) adiciona três nós ao cluster de administrador.
Cada cluster de usuário do kubeception que não é de alta disponibilidade adiciona um nó ao cluster de administrador.
Se você precisar de um cluster de administrador de nó N, será preciso garantir que o bloco CIDR do pod seja grande o suficiente para aceitar blocos N /24.
A tabela a seguir descreve o número máximo de nós compatíveis com diferentes tamanhos de bloco de CIDR de pod:
| Tamanho do bloco de CIDR de pod | Número máximo de nós compatíveis |
|---|---|
| /18 | 64 |
| /17 | 128 |
| /16 | 256 |
| /15 | 512 |
O bloco CIDR padrão de um cluster administrador é 192.168.0.0/16, que é compatível com 256 nós.
Em um cluster de administrador com 100 clusters de usuário do kubeception de alta disponibilidade, há três nós do plano de controle do cluster de administrador e 300 nós do plano de controle do cluster de usuário. O número total de nós é 303 (mais de 256). Portanto, é preciso atualizar o bloco CIDR do pod para /15 para oferecer suporte a até 100 clusters de usuário do kubeception de alta disponibilidade.
Para configurar o bloco CIDR do pod, defina o campo network.podCIDR no arquivo
de configuração do cluster de administrador.
Bloco de CIDR de serviço no cluster de administrador
O bloco CIDR de serviço é o bloco CIDR de todos os Serviços em um cluster de administrador.
Ele é configurado por meio do campo network.serviceCIDR no admin-cluster.yaml.
A tabela a seguir descreve o número máximo de serviços compatíveis com diferentes tamanhos de bloco de CIDR de serviço:
| Tamanho do bloco de CIDR de serviço | Número máximo de serviços permitido |
|---|---|
| /24 | 256 |
| /23 | 512 |
| /22 | 1.024 |
O valor padrão é 10.96.232.0/24, compatível com 256 serviços.
Cada cluster de usuário do Kubeception usa 6 serviços, e o plano de controle do cluster de administrador usa 14 serviços. Portanto, para executar 100 clusters de usuário do kubeception, é preciso alterar o bloco CIDR de serviço no cluster de administrador para usar um intervalo /22.
Cloud Logging e Cloud Monitoring
O Cloud Logging e o Cloud Monitoring ajudam você a rastrear os recursos.
O uso da CPU e da memória dos componentes de geração de registros e monitoramento implantados em um cluster de administrador é escalonado de acordo com o número de clusters de usuário do Kubeception.
Na tabela a seguir, descrevemos a quantidade de CPU e memória do nó do cluster de administrador necessárias para executar um grande número de clusters de usuário do Kubeception:
| Número de clusters de usuário do Kubeception | CPU do nó do cluster do administrador | Memória do nó do cluster de administrador |
|---|---|---|
| 0 a 10 | 4 CPUs | 16 GB |
| 11 a 20 | 4 CPUs | 32 GB |
| 20 a 100 | 4 CPUs | 90 GB |
Por exemplo, se houver dois nós de cluster de administrador e cada um tiver 4 CPUs e 16 GB de memória, será possível executar de 0 a 10 clusters de usuário do Kubeception. Para criar mais de 20 clusters de usuário do Kubeception, primeiro redimensione a memória do nó do cluster de administrador de 16 GB para 90 GB.
Hub do GKE
Por padrão, é possível registrar até 15 clusters de usuário.
Para registrar mais clusters no Hub do GKE, envie uma solicitação para aumentar a cota no console do Google Cloud:
Como executar muitos nós e pods em um cluster de usuário
Ao se preparar para executar muitos nós e pods em um cluster de usuário, execute as etapas a seguir ao criar o cluster de usuário.
Bloco de CIDR de pod no cluster do usuário
O bloco CIDR de pod é o bloco CIDR para todos os pods em um cluster de usuário. Ele é configurado por meio do campo network.podCIDR no user-cluster.yaml.
A partir desse intervalo, um bloco /24 menor é atribuído a cada nó. Se você precisar de um cluster com N nós, certifique-se de que esse bloco seja grande o suficiente para suportar N blocos /24.
A tabela a seguir descreve o número máximo de nós compatíveis com diferentes tamanhos de bloco de CIDR de pod:
| Tamanho do bloco de CIDR de pod | Número máximo de nós compatíveis |
|---|---|
| /18 | 64 |
| /17 | 128 |
| /16 | 256 |
| /15 | 512 |
O bloco de CIDR de pod padrão é 192.168.0.0/16, que é compatível com 256 nós. Por exemplo, para criar um cluster com 500 nós, é preciso alterar o bloco de CIDR de pod no cluster de usuário para usar um intervalo /15.
Bloco de CIDR de serviço no cluster do usuário
O bloco CIDR de serviço é o bloco CIDR de todos os Serviços em um cluster de usuário. Ele é configurado por meio do campo network.serviceCIDR no user-cluster.yaml.
A tabela a seguir descreve o número máximo de serviços compatíveis com diferentes tamanhos de bloco de CIDR de serviço:
| Tamanho do bloco de CIDR de serviço | Número máximo de serviços permitido |
|---|---|
| /21 | 2.048 |
| /20 | 4.096 |
| /19 | 8.192 |
| /18 | 16.384 |
Nós do plano de controle do cluster de usuários
O uso da memória dos componentes do plano de controle do cluster de usuário é escalonado de acordo com o número de nós no cluster.
A tabela a seguir fornece a CPU e a memória necessárias para um nó do plano de controle do cluster de usuário, dependendo do tamanho do cluster do usuário:
| Número de nós do cluster de usuário | CPU do nó do plano de controle | Memória do nó do plano de controle |
|---|---|---|
| 0 a 20 | 3 CPUs | 5 GB |
| 21 a 75 | 3 CPUs | 6 GB |
| 76 a 250 | 4 CPUs | 8 GB |
| 251 a 500 | 4 CPUs | 16 GB |
Por exemplo, para criar mais de 250 nós em um cluster de usuário, é necessário usar nós de plano de controle do cluster do usuário com pelo menos 16 GB de memória.
A especificação do nó do plano de controle do cluster de usuário pode ser alterada por meio do campo masterNode no user-cluster.yaml.
Dataplane V2
Para clusters de usuários de 500 nós usando o Dataplane V2, recomendamos 120 GB de memória e 32 núcleos de CPU para os nós do plano de controle do cluster de usuários.
Cloud Logging e Cloud Monitoring
O Cloud Logging e o Cloud Monitoring ajudam você a rastrear os recursos.
O uso de CPU e memória dos agentes no cluster implantados em um cluster de usuário escalona em termos de número de nós e pods em um cluster de usuário.
Os componentes do Cloud Logging e Monitoring, como prometheus-server,
stackdriver-prometheus-sidecar e , têm
diferentes usos de recurso de CPU e memória com base no número de nós e no
número de pods. Antes de escalonar o cluster, defina a
solicitação e o limite de recursos de acordo com a utilização média estimada desses
componentes. A tabela a seguir mostra estimativas para a quantidade média de uso
de cada componente:
| Número de nós | Nome do contêiner | Uso estimado da CPU | Uso estimado da memória | ||
|---|---|---|---|---|---|
| 0 pods/nó | 30 pods/nó | 0 pods/nó | 30 pods/nó | ||
| 3 a 50 | prometheus-server | 100 m | 390 m | 650 M | 1,3 G |
| stackdriver-prometheus-sidecar | 100 m | 340 m | 1,5 G | 1,6 G | |
| 51 a 100 | prometheus-server | 160 m | 500 m | 1,8 G | 5,5 G |
| stackdriver-prometheus-sidecar | 200 m | 500 m | 1,9 G | 5,7 G | |
| 101 a 250 | prometheus-server | 400 m | 2500 m | 6,5 G | 16 G |
| stackdriver-prometheus-sidecar | 400 m | 1300 m | 7,5 G | 12 G | |
| 250 a 500 | prometheus-server | 1200m | 2600m | 22G | 25G |
| stackdriver-prometheus-sidecar | 400 m | 2250m | 65G | 78G | |
Verifique se os nós são grandes o suficiente para programar os componentes do Cloud Logging e do Cloud Monitoring. Uma maneira de fazer isso é criar um cluster pequeno primeiro, editar os recursos do componente Cloud Logging e Cloud Monitoring de acordo com a tabela acima, criar um pool de nós para acomodar os componentes, e, em seguida, escalonar gradualmente o cluster para um tamanho maior.
É possível optar por manter um pool de nós apenas grande o suficiente para os componentes de monitoramento e geração de registros para impedir que outros pods sejam programados no pool de nós. Para fazer isso, você precisa adicionar os seguintes taints ao pool de nós:
taints:
- effect: NoSchedule
key: node-role.gke.io/observability
Isso impede que outros componentes sejam programados no pool de nós e impede que as cargas de trabalho do usuário sejam removidas devido ao consumo de recursos dos componentes de monitoramento.
Balanceador de carga
Os Serviços discutidos nesta seção se referem aos Serviços do Kubernetes com o tipo LoadBalancer.
Há um limite no número de nós no cluster e no número de serviços que podem ser configurados no balanceador de carga.
Para balanceamento de carga em pacote (Seesaw), também há um limite no número de
verificações de integridade. O número de verificações de integridade depende do número de nós e
do número de serviços locais de tráfego. Um serviço local de tráfego é um serviço que
tem sua externalTrafficPolicy definida como Local.
A tabela a seguir descreve o número máximo de serviços, nós e verificações de integridade para balanceamento de carga em pacote (Seesaw) e balanceamento de carga integrado (F5):
| Balanceamento de carga em pacote (Seesaw) | Balanceamento de carga integrado (F5) | |
|---|---|---|
| Número máximo de serviços | 500 | 250 2 |
| Número máximo de nós | 500 | 250 2 |
| Máximo de verificações de integridade | N + (L * N) <= 10K, em que N é o número de nós e L é o número de serviços locais de tráfego 1 | N/A 2 |
1 Por exemplo, suponha que você tenha 100 nós e 99 serviços locais de tráfego. Então, o número de verificações de integridade é 100 + (99 * 100) = 10.000, que está dentro do limite de 10 mil.
2 Consulte a seção F5 para mais informações. Esse número é afetado por fatores como o número do modelo do hardware F5, a CPU/memória da instância virtual e as licenças.
Componentes do sistema de escalonamento automático
O GKE no VMware escalona automaticamente os componentes do sistema no cluster de acordo com o número de nós, sem a necessidade de alterar as configurações. Use as informações nesta seção para planejamento de recursos.
O GKE no VMware realiza automaticamente o escalonamento vertical escalonando as solicitações/limites de CPU e memória dos seguintes componentes do sistema usando redimensionador de complementos:
O kube-state-metrics é uma implantação em execução nos nós de trabalho de cluster que ouvem o servidor da API do Kubernetes e gera métricas sobre o estado dos objetos. Os limites e as solicitações da CPU e da memória são escalonados com base no número de nós.
A tabela a seguir descreve as solicitações/limites de recursos definidos pelo sistema, considerando o número de nós em um cluster:
Número de nós Aproximadamente 1 solicitação/limite de CPU (mili) Aproximadamente1 solicitação/limite de memória (Mi) 3 a 5 105 110 6 a 500 100 + num_nodes 100 + (2 * num_nodes) 1 Há uma margem de +/-5% para reduzir o número de reinicializações do componente durante o dimensionamento.
Por exemplo, em um cluster com 50 nós, a solicitação/limite da CPU é definida como 150m/150m, e a solicitação/limite da memória são definidos como 200 Mi/200Mi. Em um cluster com 250 nós, a solicitação/limite da CPU é definida como 350m/350 m, e a solicitação/limite da memória são definidos como 600Mi.
metrics-server é uma implantação em execução em nós de trabalho de cluster usada por pipelines de escalonamento automático integrados ao Kubernetes. Os limites e as solicitações da CPU e da memória são escalonados com base no número de nós.
O GKE no VMware executa automaticamente o escalonamento horizontal nos clusters do administrador e no cluster do usuário aumentando o número de réplicas dos seguintes componentes do sistema:
core-dns é a solução de DNS usada para descoberta de serviços no GKE no VMware. Ele é executado como uma implantação em nós de trabalho do cluster de usuário. O GKE no VMware escalona automaticamente o número de réplicas de acordo com o número de nós e os núcleos da CPU no cluster. A cada adição/exclusão de 16 nós ou 256 núcleos, uma réplica é aumentada/diminuída. Se você tiver um cluster de
Nnós e núcleosC, esperamax(N/16, C/256)réplicas.calico-typha é um componente para suporte à rede de pods no GKE no VMware. Ele é executado como uma implantação em nós de trabalho do cluster de usuário. O GKE no VMware escalona automaticamente o número de réplicas de calico-typha com base no número de nós no cluster:
Número de nós (N) Número de réplicas de calico-typha N = 1 1 1 < N < 200 2 N >= 200 3 ou mais O ingress-gateway do Istio é o componente para oferecer suporte à entrada do cluster e é executado como uma implantação nos nós de trabalho do cluster de usuário. Dependendo da quantidade de tráfego que o gateway de entrada está processando, o GKE no VMware usa o Escalonador automático de pod horizontal para escalonar o número de réplicas com base no uso da CPU, com um mínimo de 2 réplicas e máximo de cinco réplicas.
O proxy de rede konnectivity (KNP, na sigla em inglês) fornece um proxy no nível TCP para saída de nós do plano de controle do cluster de usuário. Ele encaminha o tráfego de saída kube-apiserver para o usuário destinado aos nós do cluster de usuário. O agente do konnectivity é executado como uma implantação em nós de trabalho do cluster de usuário. O Google Distributed Cloud escalona automaticamente o número de réplicas de agentes de conectividade com base no número de nós no cluster.
Número de nós (N) Número de réplicas do agente do konnectivity 1 <= N <= 6 N 6 < N < 10 6 10 <= N < 100 8 N >= 100 12 or more
Práticas recomendadas
Nesta seção, você verá as práticas recomendadas para dimensionar seus recursos.
Escalone seu cluster em etapas
A criação de um nó do Kubernetes envolve a clonagem do modelo de imagem do SO do nó em um novo arquivo de disco, que é uma operação do vSphere com uso intensivo de E/S. Não há isolamento de E/S entre a operação de clone e as operações de E/S de carga de trabalho. Se houver muitos nós sendo criados ao mesmo tempo, as operações de clone serão muito demoradas e poderão afetar o desempenho e a estabilidade do cluster e das cargas de trabalho atuais.
Garanta que o cluster seja escalonado em etapas, dependendo dos recursos do vSphere. Por exemplo, para redimensionar um cluster de 3 a 500 nós, considere fazê-lo em estágios de 150 a 350 a 500, o que ajuda a reduzir a carga na infraestrutura do vSpheres.
Otimize o desempenho de E/S do disco do etcd
O etcd é um armazenamento de chave-valor usado como armazenamento de apoio do Kubernetes para todos os dados de cluster. O desempenho e a estabilidade dele são essenciais para a integridade de um cluster e são sensíveis à latência de E/S do disco e da rede.
Otimize o desempenho de E/S do armazenamento de dados do vSphere usado para as VMs do plano de controle seguindo estas recomendações:
- Siga os requisitos de hardware do etcd.
- Use SSD ou todo o armazenamento flash.
A latência de algumas centenas de milissegundos indica um gargalo na E/S do disco ou rede e pode resultar em um cluster não íntegro. Monitore e defina limites de alerta para as seguintes métricas de latência de E/S do etcd:
etcd_disk_backend_commit_duration_secondsetcd_disk_wal_fsync_duration_seconds
Otimize o desempenho de E/S do disco de inicialização de nós
Os pods usam armazenamento temporário para as operações internas, como salvar arquivos temporários. O armazenamento temporário é consumido pela camada gravável do contêiner, pelo diretório de registros e pelos volumes emptyDir. O armazenamento temporário é proveniente do sistema de arquivos do nó do GKE no VMware, que é apoiado pelo disco de inicialização do nó.
Como não há isolamento de E/S de armazenamento nos nós do Kubernetes, os aplicativos que consomem uma E/S extremamente alta no armazenamento temporário podem causar instabilidade do nó ao privar componentes do sistema como o Kubelet e o daemon do Docker de recursos.
Verifique se as características de desempenho de E/S do armazenamento de dados em que os discos de inicialização estão provisionados podem fornecer o desempenho certo para o uso do armazenamento temporário e o tráfego de geração de registros.
Monitore a contenção de recursos físicos
Esteja ciente das proporções de vCPU para pCPU e sobrecarga da memória. Uma proporção abaixo do ideal ou uma contenção de memória nos hosts físicos pode causar degradação no desempenho da VM. É preciso monitorar a utilização de recursos físicos no nível do host e alocar recursos suficientes para executar os clusters grandes.