Desempenho do complemento de malha de serviço Istio e escala

O complemento de malha de serviço baseado em Istio é logicamente dividido em um painel de controle (istiod) e um plano de dados. O plano de dados é composto por proxies de sidecar Envoy dentro de pods de carga de trabalho. O Istiod gerencia e configura esses proxies Envoy. Este artigo apresenta o desempenho do plano de dados e do painel de controle para a revisão asm-1-19, incluindo consumo de recursos, capacidade do sidecar e sobrecarga de latência. Além disso, ele fornece sugestões para lidar com as possíveis sobrecargas dos recursos durante períodos de carga pesada. Este artigo também aborda como personalizar o dimensionamento para o plano de controle e gateways.

Desempenho do painel de controle

Os requisitos de CPU e memória do Istiod se correlacionam com a taxa de alterações de implantação e configuração e o número de proxies conectados. Os cenários testados foram:

• Rotatividade de pod: examina o impacto da rotatividade de pod em istiod. Para reduzir variáveis, apenas um serviço é usado para todos os sidecars.
• Vários serviços: examina o impacto de vários serviços no máximo de sidecars que o Istiod pode gerenciar (capacidade de sidecar), em que cada serviço tem sidecars de N, totalizando o máximo geral.

Especificações de teste

• Uma instância istiod com configurações padrão
• Dimensionamento automático horizontal de pod desabilitado
• Testado com dois plug-ins de rede: Sobreposição de CNI (Interface de Rede de Contêiner) do Azure e Sobreposição de CNI do Azure com Cilium (plug-ins de rede recomendados para clusters de grande escala)
• SKU do nó: Standard D16 v3 (16 vCPU, memória de 64 GB)
• Versão do Kubernetes: 1.28.5
• Revisão do Istio: asm-1-19

Rotatividade de pod

A estrutura ClusterLoader2 foi usada para determinar o número máximo de sidecars que o Istiod pode gerenciar quando há rotatividade de sidecar. A porcentagem de rotatividade é definida como a porcentagem de sidecars que reduziram ou aumentaram durante o teste. Por exemplo, 50% de rotatividade para 10.000 sidecars significaria que 5.000 sidecars foram reduzidos e, em seguida, 5.000 sidecars foram aumentados. As porcentagens de rotatividade testadas foram determinadas a partir da porcentagem de rotatividade típica durante as distribuições de implantação (maxUnavailable). A rotatividade foi calculada determinando o número total de sidecars com rotatividade (aumento e redução) ao longo do tempo real necessário para concluir o processo de rotatividade.

Capacidade do Sidecar, CPU e memória do Istiod

Sobreposição de CNI do Azure

Rotatividade (%)	Rotatividade (sidecars/s)	Capacidade do Sidecar	Memória do Istiod (GB)	CPU do Istiod
0	--	25000	32,1	15
25	31,2	15000	22.2	15
50	31,2	15000	25.4	15

Sobreposição de CNI do Azure com Cilium

Rotatividade (%)	Rotatividade (sidecars/s)	Capacidade do Sidecar	Memória do Istiod (GB)	CPU do Istiod
0	--	30000	41,2	15
25	41.7	25000	36.1	16
50	37,9	25000	42.7	16

Vários serviços

A estrutura do ClusterLoader2 foi usada para determinar o número máximo de sidecars istiod que podem ser gerenciados com 1.000 serviços. Os resultados podem ser comparados com o teste de rotatividade de 0% (um serviço) no cenário de rotatividade de pods. Cada serviço tinha sidecars N que contribuíam para a contagem máxima geral de sidecars. O uso de recursos do servidor de API foi observado para determinar se houve algum estresse significativo causado pelo complemento.

Capacidade do Sidecar

Sobreposição de CNI do Azure	Sobreposição de CNI do Azure com Cilium
20000	20000

CPU e memória

Recurso	Sobreposição de CNI do Azure	Sobreposição de CNI do Azure com Cilium
Memória do Servidor de API (GB)	38,9	9.7
CPU do Servidor de API	6.1	4.7
Memória do Istiod (GB)	40,4	42,6
CPU do Istiod	15	16

Desempenho do plano de dados

Vários fatores afetam o desempenho do sidecar, como o tamanho da solicitação, o número de threads de thread de trabalho do proxy e o número de conexões do cliente. Além disso, qualquer solicitação que flua pela malha atravessa o proxy do lado do cliente e, em seguida, o proxy do lado do servidor. Portanto, a latência e o consumo de recursos são medidos para determinar o desempenho do plano de dados.

O Fortio foi usado para criar a carga. O teste foi realizado com o repositório de benchmark do Istio que foi modificado para uso com o complemento.

Especificações de teste

• Testado com dois plug-ins de rede: Sobreposição de CNI do Azure e Sobreposição de CNI do Azure com Cilium (plug-ins de rede recomendados para clusters de grande escala)
• SKU do nó: Standard D16 v5 (16 vCPU, memória de 64 GB)
• Versão do Kubernetes: 1.28.5
• Dois trabalhos de proxy
• Conteúdo de 1 KB
• 1.000 QPS (consultas por segundo) em diferentes conexões de cliente
• Protocolo http/1.1 e TLS mútuo habilitados
• 26 pontos de dados coletados

CPU e memória

O uso de memória e CPU para o cliente e o servidor proxy para 16 conexões de cliente e 1.000 QPS em todos os cenários de plug-in de rede é de aproximadamente 0,4 vCPU e 72 MB.

Latência

O proxy de sidecar Envoy coleta dados brutos de telemetria depois de responder a um cliente, o que não afeta diretamente o tempo total de processamento da solicitação. No entanto, esse processo atrasa o início do tratamento da próxima solicitação, contribuindo para os tempos de espera da fila e influenciando as latências média e final. Dependendo do padrão de tráfego, a latência final real varia.

Os resultados a seguir avaliam o impacto da adição de proxies sidecar ao caminho de dados, mostrando a latência P90 e P99.

• Caminho de tráfego do sidecar: cliente --> cliente-sidecar --> servidor-sidecar --> servidor
• Caminho de tráfego de linha de base: cliente --> servidor

Uma comparação do desempenho da latência do plano de dados entre as versões do complemento Istio e do AKS pode ser encontrada aqui.

Sobreposição de CNI do Azure	Sobreposição de CNI do Azure com Cilium

Scaling

Personalização de dimensionamento automático de pod horizontal

O HPA (dimensionamento automático de pod horizontal) está habilitado para os pods de gateway de istiod e entrada. As configurações padrão para istiod e os gateways são:

• Número mínimo de réplicas: 2
• Número máximo de réplicas: 5
• Utilização da CPU: 80%

Observação

Para evitar conflitos com o PodDisruptionBudget, o complemento não permite definir o minReplicas abaixo do padrão inicial de 2.

Veja a seguir os recursos de HPA de gateway de istiod e entrada:

NAMESPACE           NAME                                         REFERENCE
aks-istio-ingress   aks-istio-ingressgateway-external-asm-1-19   Deployment/aks-istio-ingressgateway-external-asm-1-19

aks-istio-ingress   aks-istio-ingressgateway-internal-asm-1-19   Deployment/aks-istio-ingressgateway-internal-asm-1-19

aks-istio-system    istiod-asm-1-19                              Deployment/istiod-asm-1-19

A configuração de HPA pode ser modificada por meio de patches e edições diretas. Exemplo:

kubectl patch hpa aks-istio-ingressgateway-external-asm-1-19 -n aks-istio-ingress --type merge --patch '{"spec": {"minReplicas": 3, "maxReplicas": 6}}'

Observação

Consulte a documentação de upgrade do complemento Istio para saber como as configurações de HPA são aplicadas em ambas as revisões durante uma atualização canário.

Entrada de serviço

A definição de recurso personalizado ServiceEntry do Istio permite adicionar outros serviços ao registro de serviço interno do Istio. Um ServiceEntry permite que os serviços já na malha roteiem ou acessem os serviços especificados. No entanto, a configuração de vários ServiceEntries com o campo resolution definido como DNS pode causar uma carga pesada nos servidores DNS (Serviço de Nomes de Domínio). As sugestões a seguir podem ajudar a reduzir a carga:

• Alterne para resolution: NONE para evitar totalmente as pesquisas de DNS proxy. Adequado para a maioria dos casos de uso.
• Aumente a TTL (vida útil) se você controlar os domínios que estão sendo resolvidos.
• Limite o escopo do ServiceEntry com exportTo.