Escalonabilidade

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.

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 em clusters do Anthos no VMware:

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:

  1. 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.

  2. Altere o campo spec.template.spec.providerSpec.value.machineVariables.memory para 32768.

  3. 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, é 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:

 [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:

    • core-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 N nós e núcleos C, espera max(N/16, C/256) réplicas.

    • 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.

    • 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. Os clusters do Anthos no VMware escalonam automaticamente o número de réplicas do konnectivity 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:

  • 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 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.