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

O complemento de malha de serviço baseado em Istio é logicamente dividido em um plano 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 do Envoy. Este artigo apresenta o desempenho do plano de controle e de dados para revisão asm-1-19, incluindo consumo de recursos, capacidade do sidecar e sobrecarga de latência. Além disso, fornece sugestões para lidar com a potencial pressão sobre os 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 plano de controlo

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

• Pod churn: examina o impacto do pod churning no istiod. Para reduzir as variáveis, apenas um serviço é usado para todos os sidecars.
• Serviços múltiplos: examina o impacto de vários serviços no máximo de sidecars que o Istiod pode gerenciar (capacidade de sidecar), onde cada serviço tem N sidecars, totalizando o máximo geral.

Especificações de ensaio

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

Pod churn

A estrutura ClusterLoader2 foi usada para determinar o número máximo de sidecars que o Istiod pode gerenciar quando há agitação de sidecar. A percentagem de churn é definida como a percentagem de sidecars rodados para baixo/para cima durante o teste. Por exemplo, 50% de churn para 10.000 sidecars significaria que 5.000 sidecars foram agitados, então 5.000 sidecars foram agitados. As porcentagens de churn testadas foram determinadas a partir da porcentagem típica de churn durante as distribuições de implantação (maxUnavailable). A taxa de churn foi calculada determinando o número total de sidecars agitados (para cima e para baixo) ao longo do tempo real necessário para completar o processo de agitação.

Capacidade do sidecar e CPU e memória Istiod

Sobreposição CNI do Azure

Sobreposição CNI do Azure com Cilium

Vários serviços

A estrutura 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 churn de 0% (um serviço) no cenário de churn pod. Cada serviço tinha N sidecars contribuindo para a contagem máxima geral de sidecars. O uso de recursos do API Server foi observado para determinar se havia algum estresse significativo do complemento.

Capacidade do sidecar

CPU e memória

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 proxy e o número de conexões de cliente. Além disso, qualquer solicitação que flui através da 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.

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

Especificações de ensaio

• Testado com dois plug-ins de rede: Azure CNI Overlay e Azure CNI Overlay with Cilium (plug-ins de rede recomendados para clusters de grande escala)
• SKU do nó: D16 v5 padrão (16 vCPU, 64 GB de memória)
• Versão do Kubernetes: 1.28.5
• Dois trabalhadores por procuração
• Carga útil de 1 KB
• 1.000 consultas por segundo (QPS) em conexões de cliente variáveis
• http/1.1 protocolo e TLS (Transport Layer Security) mútuo ativado
• 26 pontos de dados recolhidos

CPU e memória

O uso de memória e CPU para o proxy de cliente e servidor 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 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 na fila e influenciando as latências médias e finais. Dependendo do padrão de tráfego, a latência real da cauda varia.

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

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

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

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

Dimensionamento

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

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

• Réplicas mínimas: 2
• Máximo de réplicas: 5
• Utilização da CPU: 80%

A seguir estão os istiod recursos HPA do gateway de entrada 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 HPA pode ser modificada através 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}}'

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 serviços já na malha roteiem ou acessem os serviços especificados. No entanto, a configuração de várias ServiceEntries com o resolution campo definido como DNS pode causar uma carga pesada nos servidores DNS (Sistema de Nomes de Domínio). As sugestões a seguir podem ajudar a reduzir a carga:

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