Esta página descreve as práticas recomendadas para criar, configurar e operar clusters criados com o Google Distributed Cloud (apenas software) para VMware de forma a acomodar cargas de trabalho que se aproximam dos limites de escalabilidade do Kubernetes.
Regras de nomes de clusters
Para cada Google Cloud projeto:
- Cada cluster de utilizadores tem de ter um nome exclusivo em todos os clusters de administrador que estão num único Google Cloud projeto.
Limites de escalabilidade
Tenha em atenção os seguintes limites ao criar as suas aplicações:
Se o cluster avançado não estiver ativado:
Cada cluster de administrador suporta até 100 clusters de utilizadores, incluindo clusters de utilizadores de alta disponibilidade (HA) e não HA, através do modo de balanceamento de carga integrado (MetalLB) ou (balanceador de carga manual).
Cada cluster de utilizadores suporta até:
500 nós com o modo de balanceamento de carga integrado (MetalLB)
15 000 agrupamentos
500 serviços LoadBalancer que usam o modo de balanceamento de carga integrado (MetalLB).
Para cada nó, pode criar um máximo de 110 pods (cada pod pode consistir em 1 a 2 contentores). Isto inclui os Pods que executam serviços do sistema suplementares.
Se o cluster avançado estiver ativado
Cada cluster de administrador suporta até 100 clusters de utilizadores. Os clusters de utilizadores têm de ser clusters de alta disponibilidade (HA), que usam o modo de balanceamento de carga integrado (MetalLB) ou (balanceador de carga manual).
Cada cluster de utilizadores suporta até:
500 nós com o modo de balanceamento de carga integrado (MetalLB).
15 000 agrupamentos
500 serviços LoadBalancer que usam o modo de balanceamento de carga integrado (MetalLB).
Para cada nó, pode criar um máximo de 110 pods (cada pod pode consistir em 1 a 2 contentores). Isto inclui os Pods que executam serviços do sistema suplementares.
O número total de nós, que inclui os nós do plano de controlo do cluster de administrador + todos os nós do plano de controlo do cluster de utilizador + os nós de trabalho, não deve exceder os 500 nós.
Compreender os limites
Uma vez que o Google Distributed Cloud é um sistema complexo com uma grande superfície de integração, a escalabilidade do cluster envolve muitas dimensões interligadas. Por exemplo, o Google Distributed Cloud pode ser dimensionado através do número de nós, pods ou serviços. Esticar mais do que uma dimensão ao mesmo tempo pode causar problemas, mesmo em clusters mais pequenos. Por exemplo, agendar 110 pods por nó num cluster de 500 nós pode exceder o número de pods, pods por nó e nós.
Consulte os limites de escalabilidade do Kubernetes para ver mais detalhes.
Os limites de escalabilidade também são sensíveis à configuração do vSphere e ao hardware no qual o cluster está a ser executado. Estes limites são validados num ambiente que é provavelmente diferente do seu. Por conseguinte, pode não reproduzir os números exatos quando o ambiente subjacente é o fator limitativo.
A preparar-se para a expansão
À medida que se prepara para dimensionar os clusters de administrador ou os clusters de utilizadores, considere os seguintes requisitos e limitações.
Requisitos de CPU, memória e armazenamento
Consulte os requisitos de CPU, RAM e armazenamento para cada VM individual.
Requisitos de E/S de disco e de rede
As cargas de trabalho com grande volume de dados e determinados componentes do plano de controlo são sensíveis à latência de E/S de disco e de rede. Por exemplo, são normalmente necessários 500 IOPS sequenciais (por exemplo, um SSD local típico ou um dispositivo de blocos virtualizado de elevado desempenho) para o desempenho e a estabilidade do etcd num cluster com dezenas de nós e milhares de pods.
Endereço IP do nó
Cada nó requer um endereço IP de DHCP ou atribuído estaticamente.
Por exemplo, são necessários 307 endereços IP numa configuração com um cluster de utilizadores não de HA com 50 nós e um cluster de utilizadores de HA com 250 nós.
A tabela seguinte mostra a discriminação dos endereços IP:
| Tipo de nó | Número de endereços IP |
|---|---|
| VMs do plano de controlo do cluster de administrador | 3 |
| VM do plano de controlo do cluster de utilizadores 1 (não HA) | 1 |
| VMs de nó trabalhador do cluster de utilizadores 1 | 50 |
| VMs do plano de controlo do cluster de utilizadores 2 (HA) | 3 |
| VMs de nó trabalhador do cluster de utilizadores 2 | 250 |
| Total | 307 |
Executar muitos clusters de utilizadores num cluster de administrador
À medida que se prepara para executar muitos clusters de utilizadores num cluster de administrador, execute os seguintes passos quando criar o cluster de administrador.
Bloco CIDR de pods no cluster de administração
O bloco CIDR do Pod é o bloco CIDR para todos os Pods num cluster de administrador. É configurado através do campo network.podCIDR no admin-cluster.yaml.
A partir deste intervalo, são atribuídos blocos /24 mais pequenos a cada nó. Se todos os seus clusters de utilizadores tiverem o Controlplane V2 ativado, o cluster de administrador tem apenas três nós e existem muitos endereços IP de pods disponíveis. No entanto, sempre que cria um cluster de utilizadores que usa kubeception em vez do Controlplane V2, são adicionados um ou três nós ao cluster de administrador:
Cada cluster de utilizadores kubeception de alta disponibilidade (HA) adiciona três nós ao cluster de administrador.
Cada cluster de utilizadores kubeception sem HA adiciona um nó ao cluster de administrador.
Se precisar de um cluster de administrador de N nós, tem de garantir que o bloco CIDR de pods é suficientemente grande para suportar N blocos /24.
A tabela seguinte descreve o número máximo de nós suportados por diferentes tamanhos de blocos CIDR de pods:
| Tamanho do bloco CIDR do agrupamento | Número máximo de nós suportados |
|---|---|
| /18 | 64 |
| /17 | 128 |
| /16 | 256 |
| /15 | 512 |
O bloco CIDR de pods predefinido de um cluster de administrador é 192.168.0.0/16, que suporta 256 nós.
Num cluster de administrador com 100 clusters de utilizadores kubeception de HA, existem 3 nós do plano de controlo do cluster de administrador e 300 nós do plano de controlo do cluster de utilizadores. O número total de nós é 303 (mais de 256). Por conseguinte, tem de atualizar o bloco CIDR do pod para /15 para suportar até 100 clusters de utilizadores kubeception de HA.
Para configurar o bloco CIDR de pods, defina o campo network.podCIDR no ficheiro de configuração do cluster de administrador.
Bloco CIDR de serviço no cluster de administrador
O bloco CIDR do serviço é o bloco CIDR para todos os serviços num cluster de administrador.
É configurado através do campo network.serviceCIDR no
admin-cluster.yaml.
A tabela seguinte descreve o número máximo de serviços suportados por diferentes tamanhos de blocos CIDR de serviços:
| Tamanho do bloco CIDR do serviço | Número máximo de serviços suportados |
|---|---|
| /24 | 256 |
| /23 | 512 |
| /22 | 1024 |
O valor predefinido é 10.96.232.0/24, que suporta 256 serviços.
Cada cluster de utilizadores do kubeception usa 6 serviços e o plano de controlo do cluster de administrador usa 14 serviços. Por conseguinte, para executar 100 clusters de utilizadores do kubeception, tem de alterar o bloco CIDR do serviço no cluster de administrador para usar um intervalo /22.
Cloud Logging e Cloud Monitoring para clusters de utilizadores do kubeception
O Cloud Logging e o Cloud Monitoring ajudam a monitorizar os seus recursos.
A utilização de CPU e memória dos componentes de registo e monitorização implementados num cluster de administrador é dimensionada de acordo com o número de clusters de utilizadores do kubeception.
A tabela seguinte descreve a quantidade de CPU e memória do nó do cluster de administrador necessárias para executar um grande número de clusters de utilizadores do kubeception:
| Número de clusters de utilizadores do kubeception | CPU do nó do cluster de administrador | Memória do nó do cluster de administrador |
|---|---|---|
| 0 a 10 | 4 CPUs | 16GB |
| 11 a 20 | 4 CPUs | 32GB |
| 20 a 100 | 4 CPUs | 90GB |
Por exemplo, se existirem 2 nós de cluster de administrador e cada um tiver 4 CPUs e 16 GB de memória, pode executar 0 a 10 clusters de utilizadores do kubeception. Para criar mais de 20 clusters de utilizadores do kubeception, primeiro tem de redimensionar a memória dos nós do cluster de administrador de 16 GB para 90 GB.
Administre nós de cluster quando os clusters avançados estiverem ativados
A utilização da CPU e da memória dos componentes do ciclo de vida implementados num cluster de administrador é dimensionada de acordo com o número total de todos os nós (o número total de nós que inclui nós do plano de controlo do cluster de administrador + todos os nós do plano de controlo do cluster de utilizador + nós de trabalho)
A tabela seguinte descreve a quantidade de CPU e memória do nó do cluster de administrador necessárias para executar um grande número de todos os nós que gere:
| Número total de nós | CPU do nó do cluster de administrador | Memória do nó do cluster de administrador |
|---|---|---|
| 0 a 20 | 4 CPUs | 16GB |
| 21 a 100 | 8 CPUs | 16GB |
| 101 a 500 | 16 CPUs | 32GB |
Por exemplo, se existirem 3 nós de cluster de administrador e cada um tiver 4 CPUs e 16 GB de memória, pode executar um cluster de utilizador de HA com 14 nós de trabalho. Para criar mais de 20 clusters de utilizadores avançados, em que cada cluster de utilizadores tem mais de 10 nós, primeiro tem de redimensionar a memória do nó do cluster de administrador de 16 GB para 32 GB.
GKE Hub
Por predefinição, pode registar um máximo de 250 clusters com associações globais por frota. Para registar mais clusters no GKE Hub, pode enviar um pedido para aumentar a sua quota na Google Cloud consola:
Para mais informações sobre as quotas de clusters com base nas definições de associação, consulte o artigo Quotas de atribuição.
Executar muitos nós e pods num cluster de utilizador
À medida que se prepara para executar muitos nós e pods num cluster de utilizadores, execute os seguintes passos quando criar o cluster de utilizadores.
Bloco CIDR de pods no cluster de utilizadores
O bloco CIDR de pods é o bloco CIDR para todos os pods num cluster de utilizador. É configurado através do campo network.podCIDR no user-cluster.yaml.
A partir deste intervalo, é atribuído um bloco /24 mais pequeno a cada nó. Se precisar de um cluster de N nós, tem de garantir que este bloco é suficientemente grande para suportar N blocos /24.
A tabela seguinte descreve o número máximo de nós suportados por diferentes tamanhos de blocos CIDR de pods:
| Tamanho do bloco CIDR do agrupamento | Número máximo de nós suportados |
|---|---|
| /18 | 64 |
| /17 | 128 |
| /16 | 256 |
| /15 | 512 |
O bloco CIDR de pods predefinido é 192.168.0.0/16, que suporta 256 nós. Por exemplo, para criar um cluster com 500 nós, tem de alterar o bloco CIDR de pods no cluster de utilizador para usar um intervalo /15.
Bloco CIDR de serviço no cluster de utilizadores
O bloco CIDR de serviço é o bloco CIDR para todos os serviços num cluster de utilizadores. É configurado através do campo network.serviceCIDR no user-cluster.yaml.
A tabela seguinte descreve o número máximo de serviços suportados por diferentes tamanhos de blocos CIDR de serviços:
| Tamanho do bloco CIDR do serviço | Número máximo de serviços suportados |
|---|---|
| /21 | 2048 |
| /20 | 4096 |
| /19 | 8192 |
| /18 | 16 384 |
Nós do plano de controlo do cluster de utilizadores
A utilização de memória dos componentes do plano de controlo do cluster de utilizadores é dimensionada de acordo com o número de nós no cluster de utilizadores.
A tabela seguinte indica a CPU e a memória necessárias para um nó do plano de controlo de um cluster de utilizadores, consoante o tamanho do cluster de utilizadores:
| Número de nós do cluster de utilizadores | CPU do nó do plano de controlo | Memória do nó do plano de controlo |
|---|---|---|
| 0 a 20 | 3 CPUs | 5GB |
| 21 a 75 | 3 CPUs | 6GB |
| 76 a 250 | 4 CPUs | 8GB |
| 251 a 500 | 4 CPUs | 16GB |
Por exemplo, para criar mais de 250 nós num cluster de utilizadores, tem de usar nós do plano de controlo do cluster de utilizadores com, pelo menos, 16 GB de memória.
A especificação do nó do plano de controlo do cluster de utilizadores pode ser alterada através do campo masterNode
no user-cluster.yaml.
Dataplane v2
Para clusters de utilizadores de 500 nós que usam o Dataplane V2, recomendamos 120 GB de memória e 32 núcleos de CPU para os nós do plano de controlo do cluster de utilizadores.
Cloud Logging e Cloud Monitoring
O Cloud Logging e o Cloud Monitoring ajudam a monitorizar os seus recursos.
A utilização da CPU e da memória dos agentes no cluster implementados num cluster de utilizador é dimensionada em termos do número de nós e pods num cluster de utilizador.
Os componentes de registo e monitorização na nuvem, como o prometheus-server e o
stackdriver-prometheus-sidecar, têm uma utilização de recursos de CPU e memória diferente
com base no número de nós e no número de pods. Antes de aumentar a escala do cluster, defina o pedido e o limite de recursos de acordo com a utilização média estimada destes componentes. A tabela seguinte mostra estimativas da
quantidade média de utilização
para cada componente:
| Número de nós | Nome do contentor | Utilização estimada da CPU | Utilização de memória estimada | ||
|---|---|---|---|---|---|
| 0 pods/node | 30 pods/nó | 0 pods/node | 30 pods/nó | ||
| 3 a 50 | prometheus-server | 100m | 390m | 650 milhões | 1.3G |
| stackdriver-prometheus-sidecar | 100m | 340m | 1,5G | 1,6 G | |
| 51 a 100 | prometheus-server | 160m | 500m | 1,8 G | 5.5G |
| stackdriver-prometheus-sidecar | 200m | 500m | 1,9 G | 5,7 G | |
| 101 a 250 | prometheus-server | 400m | 2500m | 6,5G | 16G |
| stackdriver-prometheus-sidecar | 400m | 1300m | 7,5G | 12G | |
| 250 a 500 | prometheus-server | 1200m | 2600m | 22G | 25G |
| stackdriver-prometheus-sidecar | 400m | 2250m | 65G | 78G | |
Certifique-se de que tem nós suficientemente grandes para agendar os componentes do Cloud Logging e do Cloud Monitoring. Uma forma de o fazer é criar primeiro um pequeno cluster, editar os recursos dos componentes do Cloud Logging e do Cloud Monitoring de acordo com a tabela acima, criar um conjunto de nós para acomodar os componentes e, em seguida, aumentar gradualmente o tamanho do cluster.
Pode optar por manter um conjunto de nós com o tamanho suficiente para os componentes de monitorização e registo para impedir que outros pods sejam agendados para o conjunto de nós. Para o fazer, tem de adicionar as seguintes manchas ao conjunto de nós:
taints:
- effect: NoSchedule
key: node-role.gke.io/observabilityIsto impede que outros componentes sejam agendados no conjunto de nós e impede que as cargas de trabalho do utilizador sejam removidas devido ao consumo de recursos dos componentes de monitorização.
Balanceador de carga
Os serviços abordados nesta secção referem-se aos serviços do Kubernetes com o tipo LoadBalancer.
Existe um limite para o número de nós no cluster e para o número de serviços que pode configurar no equilibrador de carga.
Para o equilíbrio de carga agrupado (Seesaw), também existe um limite para o número de verificações de estado. O número de verificações de estado 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 a respetiva externalTrafficPolicy definida como Local.
A tabela seguinte descreve o número máximo de serviços, nós e verificações de estado para o balanceamento de carga integrado (F5) e o balanceamento de carga agrupado (Seesaw):
| Balanceamento de carga integrado (Seesaw) | Balanceamento de carga integrado (F5) | |
|---|---|---|
| Serviços Max | 500 | 250 2 |
| Máximo de nós | 500 | 250 2 |
| Verificações de funcionamento máximas | N + (L * N) <= 10 000, 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, suponhamos que tem 100 nós e 99 serviços locais de tráfego. O número de verificações de estado é 100 + (99 * 100) = 10 000, que está dentro do limite de 10 000.
2 Consulte a F5 para mais informações. Este número é afetado por fatores como o número do modelo de hardware F5, a CPU/memória da instância virtual e as licenças.
Componentes do sistema de escala automática
O Google Distributed Cloud dimensiona automaticamente os componentes do sistema nos clusters de utilizadores de acordo com o número de nós sem que tenha de alterar as configurações. Pode usar as informações nesta secção para o planeamento de recursos.
O Google Distributed Cloud realiza automaticamente o escalamento vertical escalando os pedidos/limites de CPU e memória dos seguintes componentes do sistema através do addon-resizer:
O kube-state-metrics é uma implementação executada em nós de trabalho do cluster que ouve o servidor da API Kubernetes e gera métricas sobre o estado dos objetos. Os pedidos e os limites de CPU e memória são dimensionados com base no número de nós.
A tabela seguinte descreve os pedidos/limites de recursos definidos pelo sistema, dado o número de nós num cluster:
Número de nós Pedido/limite de CPU aproximado1 (milésimos) Pedido/limite de memória1 aproximado (Mi) 3 a 5 105 110 6 a 500 100 + num_nodes 100 + (2 * num_nodes) 1 Existe uma margem de +/-5% para reduzir o número de reinícios de componentes durante o dimensionamento.
Por exemplo, num cluster com 50 nós, o pedido/limite de CPU está definido como 150 m/150 m e o pedido/limite de memória está definido como 200 Mi/200 Mi. Num cluster com 250 nós, o pedido/limite de CPU está definido como 350 m/350 m e o pedido/limite de memória está definido como 600 Mi.
O metrics-server é uma implementação executada em nós de trabalho do cluster que é usada por pipelines de escala automática incorporadas do Kubernetes. Os pedidos e os limites de CPU e memória são dimensionados com base no número de nós.
O Google Distributed Cloud realiza automaticamente o escalonamento horizontal nos clusters de administração e nos clusters de utilizadores, escalonando o número de réplicas dos seguintes componentes do sistema:
O core-dns é a solução de DNS usada para a descoberta de serviços. É executado como uma implementação nos nós de trabalho do cluster de utilizadores. O Google Distributed Cloud dimensiona automaticamente o número de réplicas de acordo com o número de nós e núcleos da CPU no cluster. Com cada adição/eliminação de 16 nós ou 256 núcleos, o número de réplicas é aumentado/diminuído em 1. Se tiver um cluster de
Nnós eCnúcleos, pode esperarmax(N/16, C/256)réplicas.O calico-typha é um componente para suportar a rede de pods. É executado como uma implementação nos nós de trabalho do cluster de utilizadores. O Google Distributed Cloud dimensiona automaticamente o número de réplicas do 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 Istio ingress-gateway é o componente para suportar a entrada do cluster e é executado como uma implementação nos nós de trabalho do cluster do utilizador. Consoante a quantidade de tráfego que o gateway de entrada está a processar, o Google Distributed Cloud usa o Horizontal Pod Autoscaler para dimensionar o número de réplicas com base na respetiva utilização da CPU, com um mínimo de 2 réplicas e um máximo de 5 réplicas.
O proxy de rede konnectivity (KNP) fornece um proxy ao nível do TCP para a saída dos nós do plano de controlo do cluster de utilizadores. Encaminha o tráfego de saída do kube-apiserver do utilizador destinado aos nós do cluster de utilizador. O agente de conetividade é executado como uma implementação em nós de trabalho do cluster de utilizadores. O Google Distributed Cloud dimensiona automaticamente o número de réplicas do agente de conetividade com base no número de nós no cluster.
Número de nós (N) Número de réplicas do agente de conetividade 1 <= N <= 6 N 6 < N < 10 6 10 <= N < 100 8 N >= 100 12 ou mais
Práticas recomendadas
Esta secção descreve as práticas recomendadas para dimensionar os seus recursos.
Dimensione o cluster em fases
A criação de um nó do Kubernetes envolve a clonagem do modelo de imagem do SO do nó num novo ficheiro de disco, que é uma operação do vSphere com utilização intensiva de E/S. Não existe isolamento de I/O entre a operação de clonagem e as operações de I/O da carga de trabalho. Se forem criados demasiados nós em simultâneo, as operações de clonagem demoram muito tempo a terminar e podem afetar o desempenho e a estabilidade do cluster e das cargas de trabalho existentes.
Certifique-se de que o cluster é dimensionado em fases, consoante os seus recursos do vSphere. Por exemplo, para redimensionar um cluster de 3 para 500 nós, considere escalá-lo em fases de 3 para 150, 150 para 350 e 350 para 500, o que ajuda a reduzir a carga na infraestrutura do vSphere.
Otimize o desempenho de E/S de disco do etcd
O etcd é um armazenamento de valores-chave usado como armazenamento de apoio do Kubernetes para todos os dados do cluster. O respetivo desempenho e estabilidade são fundamentais para o estado de funcionamento de um cluster e são sensíveis à latência de E/S de disco e de rede.
Otimize o desempenho de E/S do repositório de dados do vSphere usado para as VMs do plano de controlo seguindo estas recomendações:
- Siga os requisitos de hardware do etcd.
- Use um SSD ou um armazenamento totalmente flash.
Uma latência de algumas centenas de milissegundos indica um gargalo no disco ou na E/S de rede e pode resultar num cluster não saudável. Monitorize 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 arranque do nó
Os pods usam armazenamento efémero para as respetivas operações internas, como guardar ficheiros temporários. O armazenamento efémero é consumido pela camada gravável do contentor, pelo diretório de registos e pelos volumes emptyDir. O armazenamento efémero provém do sistema de ficheiros do nó, que é suportado pelo disco de arranque do nó.
Como não existe isolamento de E/S de armazenamento nos nós do Kubernetes, as aplicações que consomem E/S extremamente elevadas no respetivo armazenamento efémero podem potencialmente causar instabilidade nos nós ao privar os componentes do sistema, como o Kubelet e o daemon do Docker, de recursos.
Certifique-se de que as caraterísticas de desempenho de E/S do repositório de dados no qual os discos de arranque são aprovisionados podem oferecer o desempenho adequado para a utilização do armazenamento efémero e do tráfego de registo da aplicação.
Monitorize a contenção de recursos físicos
Tenha em atenção as proporções de vCPU para pCPU e o excesso de compromisso de memória. Uma relação subótima ou uma contenção de memória nos anfitriões físicos podem causar uma degradação do desempenho da MV. Deve monitorizar a utilização de recursos físicos ao nível do anfitrião e atribuir recursos suficientes para executar os seus clusters grandes.