Nesta página, descrevemos as práticas recomendadas para criar, configurar e operar clusters do Anthos no VMware (GKE no local) 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 em clusters do Anthos 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 modo de balanceamento de carga integrado (F5).
Cada cluster de usuário é compatível com até:
500 nós que usam o modo de balanceamento de carga com pacotes (Seesaw) ou 250 nós usando o modo de balanceamento de carga integrado (F5)
15,000 Pods
500 Serviços LoadBalancer usando modo de balanceamento de carga agrupado (Seesaw) 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.
Como entender os limites
Como os clusters do Anthos no VMware são um sistema complexo com uma grande superfície de integração, a escalonabilidade de cluster envolve muitas dimensões inter-relacionadas. Por exemplo, os clusters do Anthos no VMware podem escalonar por meio do 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 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 cluster do Anthos no nó do VMware requer um endereço IP DHCP ou estaticamente atribuído.
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 |
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 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 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ários de alta disponibilidade (cada cluster de usuário tem três nós de plano de controle), há um nó de controle de cluster de administrador, dois nós de complemento de cluster de administrador e 300 nós de plano de controle de cluster de usuário. O número total de nós é 303 (mais de 256). Portanto, você precisa atualizar o bloco CIDR de pod para /15 para oferecer suporte a até 100 clusters de usuário 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 usa seis serviços e o plano de controle do cluster de administrador usa 14 serviços. Portanto, para executar 100 clusters de usuários, é 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 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 |
| 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, 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ó de complemento do cluster de administrador, edite a configuração da 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.
Hub GKE
Por padrão, para cada projeto do Google Cloud Platform é possível registrar no máximo 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:
[Go to Quotas](https://console.cloud.google.com/apis/api/gkehub.googleapis.com/quotas){: target="console"
class="button button-primary" track-type="quotas" track-name="consoleLink" track-metadata-end-goal="modifyQuota"}
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 |
O valor padrão é 10.96.0.0/20, compatível com 4.096 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 clusters do tipo Anthos LoadBalancer no VMware compatíveis em um cluster de usuário.
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 exigidas pelo nó do plano de controle do cluster de usuário, dependendo do tamanho do cluster de 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
Os clusters do Anthos no VMware escalonam 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.
Os clusters do Anthos no VMware executam automaticamente o escalonamento vertical escalonando as solicitações/limites de CPU e memória dos seguintes componentes do sistema usando addon-resizer:
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.
Os clusters do Anthos no VMware executam 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:
kube-dns é a solução DNS usada para descoberta de serviços em clusters do Anthos no VMware. Ele é executado como uma implantação em nós de trabalho do cluster de usuário. Os clusters do Anthos no VMware escalonam automaticamente o número de réplicas de acordo com o número de nós e de núcleos de 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. O kube-dns é compatível com 1.500 solicitações simultâneas por segundo.calico-typha é um componente para suportar a rede de pods em clusters do Anthos no VMware. Ele é executado como uma implantação em nós de trabalho do cluster de usuário. Os clusters do Anthos no VMware escalonam 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 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, os clusters do Anthos no VMware usam 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 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 dos clusters do Anthos no sistema de arquivos do nó do VMware, que tem o suporte do 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.