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

O complemento de malha de serviços baseado em Istio é logicamente dividido em um plano de administração (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 do plano de controle e dos 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

Azure CNI Overlay

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

Sobreposição Azure CNI com Cilium

Rotatividade (%)	Rotatividade (sidecars/s)	Capacidade do Sidecar	Memória do Istiod (GB)	CPU do Istiod
0	--	30000	41,2	15
vinte e cinco	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 do Azure CNI	Sobreposição do Azure CNI com Cilium
20000	20000

CPU e memória

Recurso	Sobreposição do Azure CNI	Sobreposição do Azure CNI 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 trabalho do proxy e o número de conexões de clientes. 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 plugins de rede: Azure CNI Overlay e Azure CNI Overlay com Cilium (plugins 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 trabalhadores de proxy
• Carga útil de 1 KB
• 1.000 QPS (consultas por segundo) em diferentes conexões de cliente
• http/1.1 protocolo e segurança mútua da camada de transporte (TLS) habilitados
• 26 pontos de dados coletados

CPU e memória

O uso de memória e CPU tanto para os proxies de cliente quanto de servidor, para 16 conexões 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.

Azure CNI Overlay	Overlay de CNI do Azure com Cilium

Escalonamento

Personalização do dimensionamento automático horizontal de pods (HPA)

O HPA (dimensionamento automático de pod horizontal) está habilitado para as implantações de istiod e de gateway de entrada/saída. 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 do Istio para obter detalhes sobre como as configurações do HPA são aplicadas em ambas as revisões durante uma atualização canary.

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 rede 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. No entanto, ao usar um gateway de saída de complemento Istio, a resolução ServiceEntry deve ser definida como DNS.
• Aumente o TTL (tempo de vida útil) caso você controle os domínios que estão sendo resolvidos.
• Limite o escopo do ServiceEntry com exportTo.