Versão 1.6. Esta versão não é mais compatível, conforme descrito na Política de suporte da versão do Anthos. Para ver os patches e as atualizações mais recentes sobre vulnerabilidades de segurança, exposições e problemas que afetam os clusters do Anthos no VMware (GKE On-Prem), faça o upgrade para uma versão compatível. Você pode encontrar a versão mais recente neste link.

Escalonabilidade

Nesta página, descrevemos as práticas recomendadas para criar, configurar e operar clusters do Anthos em clusters do 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é 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é:

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

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 os clusters do Anthos no VMware 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 CIDR padrão de serviço permite criar um cluster com 500 serviços, que é o número máximo de serviços compatíveis com os clusters do Anthos no VMware 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 GKE Hub, envie uma solicitação para aumentar sua cota no Console do 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:

  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.

Dataplane V2

Para 500 clusters de nós que usam o Dataplane V2, recomendamos 120 GB de memória e 32 núcleos de CPU para o plano de controle.

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

  • Os clusters do Anthos no VMware executam automaticamente o escalonamento horizontal dimensionando 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 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 os clusters do Anthos no VMware 1.4 para ser 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 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, 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 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:

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