Nesta página, descrevemos as práticas recomendadas para criar, configurar e operar clusters do GKE On-Prem para acomodar cargas de trabalho que se aproximam dos limites de escalonabilidade do Kubernetes.
Limites de escalonabilidade
Considere os seguintes limites ao projetar seus aplicativos no GKE On-Prem:
Cada cluster de administrador é compatível com até 20 clusters de usuário, incluindo clusters de alta disponibilidade (HA) e de não HA.
Cada cluster de usuário é compatível com até:
250 nós
7.500 pods
500 Serviços LoadBalancer no modo de balanceamento de carga agrupado (Sawaw) ou 250 Serviços LoadBalancer no 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.
Como entender os limites
Como o GKE On-Prem é um sistema complexo com uma grande superfície de integração, a escalonabilidade de cluster envolve muitas dimensões relacionadas. Por exemplo, o GKE On-Prem 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 250 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, não é possível reproduzir os números exatos quando o ambiente subjacente é o fator limitante.
Como se preparar para escalonar
Ao se preparar para escalonar, considere os requisitos e as limitações para a infraestrutura do vSphere, a rede do Kubernetes, o GKE Hub, o Cloud Logging e o Cloud Monitoring.
Infraestrutura do vSphere
Nesta seção, você verá sobre questões de escalonabilidade para requisitos de CPU, memória, armazenamento, disco e E/S de rede, além de endereços IP de nós.
Requisitos de armazenamento, CPU e memória
Os requisitos a seguir se aplicam às VMs do plano de controle:
O plano de controle do cluster do administrador e os nós de complementos aceitam até 20 clusters de usuário, incluindo clusters de usuários de alta disponibilidade e não HA. Portanto, nenhum ajuste é necessário no cluster de administração.
A configuração de VM do plano de controle de cluster de usuário padrão (4 CPUs, 8 GB de memória e 40 GB de armazenamento) é a configuração mínima necessária para executar até 250 nós em um cluster de usuário.
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 On-Prem requer um endereço IP ou DHCP atribuído estaticamente.
Por exemplo, 308 endereços IP são necessários em uma configuração com um cluster de usuário não HA com 50 nós e um cluster de usuário HA com 250 nós. A tabela a seguir mostra o detalhamento dos endereços IP:
| Tipo de nó | Número de endereços IP |
|---|---|
| VM de plano de controle do cluster do administrador | 1 |
| VMs do nó do complemento do cluster de administrador | 3 |
| VM do plano de controle do cluster do usuário 1 (não HA) | 1 |
| VMs do nó do cluster do usuário 1 | 50 |
| VMs do plano de controle do cluster do usuário 2 (HA) | 3 |
| VMs de nós do cluster do usuário 2 | 250 |
| Total | 308 |
Rede do Kubernetes
Nesta seção, você verá considerações sobre escalonabilidade do bloco de CIDR de pod e dos serviços do Kubernetes.
Bloco CIDR de pod
O bloco CIDR de pod é o bloco CIDR para todos os pods em um cluster de usuário. A partir desse intervalo, blocos /24 menores são atribuídos 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 |
|---|---|
| /19 | 32 |
| /18 | 64 |
| /17 | 128 |
| /16 | 256 |
O bloco de CIDR de pod padrão é 192.168.0.0/16, que é compatível com 256 nós. O bloco de CIDR de pod padrão permite criar um cluster com 250 nós, que é o número máximo de nós compatíveis com o GKE On-Prem em um cluster de usuário.
Serviços do Kubernetes
Nesta seção, você verá considerações sobre a escalonabilidade do bloco CIDR de serviço e do balanceador de carga.
Bloco de CIDR de serviço
O bloco CIDR de serviço é o bloco CIDR de todos os Serviços em um cluster de usuário. Os Serviços discutidos nesta seção se referem aos Serviços do Kubernetes com o tipo LoadBalancer.
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 |
|---|---|
| /20 | 4.096 |
| /19 | 8.192 |
| /18 | 16.384 |
O valor padrão é 10.96.0.0/12, compatível com 1.048.576 serviços. O bloco de CIDR de serviço padrão permite criar um cluster com 500 serviços, que é o número máximo de serviços compatíveis com o GKE On-Prem em um cluster de usuário.
Balanceador de carga
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 | 250 | 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.
Hub 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:
Cloud Logging e Cloud Monitoring
O Cloud Logging e o Cloud Monitoring ajudam você a rastrear os recursos.
Como executar muitos nós em um cluster de usuário
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 stackdriver-log-aggregator, 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 | stackdriver-log-aggregator | 150 m | 170 m | 1,6 G | 1,7 G |
| 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 | stackdriver-log-aggregator | 220 m | 1100 m | 1,6 G | 1,8 G |
| 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 | stackdriver-log-aggregator | 450 m | 1800 m | 1,7 G | 1,9 G |
| prometheus-server | 400 m | 2500 m | 6,5 G | 16 G | |
| stackdriver-prometheus-sidecar | 400 m | 1300 m | 7,5 G | 12 G | |
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.
Como executar vários clusters de usuários em um cluster de administrador
O uso de CPU e memória dos componentes de geração de registros e monitoramento implantados em uma escala de cluster de administrador de acordo com o número de clusters de usuários.
Veja na tabela a seguir a quantidade de CPU e memória do nó do cluster de administrador necessária para executar um grande número de clusters de usuários:
| Número de clusters de usuários | 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 |
Por exemplo, se houver dois nós de cluster de administrador e cada um tiver 4 CPUs e 16 GB de memória, execute de 0 a 10 clusters de usuários. Para criar mais de 10 clusters de usuário, primeiro é preciso redimensionar a memória do nó do cluster de administrador de 16 GB para 32 GB.
Para alterar a memória do nó do cluster de administrador, edite a configuração MachineDeployment:
Execute este comando:
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG edit machinedeployment gke-admin-node
ADMIN_CLUSTER_KUBECONFIG é o caminho do arquivo kubeconfig do cluster de administrador.
Altere o campo
spec.template.spec.providerSpec.value.machineVariables.memorypara32768.Salve a edição. Os nós de cluster de administrador são recriados com memória de 32 GB.
Componentes do sistema de escalonamento automático
O GKE On-Prem 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 On-Prem 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 250 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.
O GKE On-Prem executa automaticamente o escalonamento horizontal ao escalonar o número de réplicas dos seguintes componentes do sistema:
kube-dns é a solução de DNS usada para descoberta de serviços no GKE On-Prem. Ele é executado como uma implantação em nós de trabalho do cluster de usuário. O GKE On-Prem 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 N nós e núcleos C, você pode esperar pelo número máximo de réplicas (N/16, C/256). O kube-dns foi atualizado desde o GKE On-Prem 1.4 para compatibilidade com 1.500 solicitações simultâneas por segundo.
calico-typha é um componente para suporte à rede de pods no GKE On-Prem. Ele é executado como uma implantação em nós de trabalho do cluster de usuário. O GKE On-Prem dimensiona automaticamente o número de réplicas com base no número de nós no cluster. Há uma réplica de calico-typha em um cluster com menos de 200 nós e duas réplicas em um cluster com 200 ou mais nós.
ingress-gateway/istio-pilot são os componentes para suporte à entrada de cluster e são executados como uma implantação em nós de trabalho de clusters de usuários. Dependendo da quantidade de tráfego que o gateway de entrada está processando, o GKE On-Prem 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.
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 250 nós, considere escaloná-lo em estágios entre 80 a 160 a 250, o que ajuda a reduzir a carga na infraestrutura do vSphere.
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_seconds
- etcd_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 On-Prem, 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.