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

O complemento de malha de serviços baseado em Istio é logicamente dividido num plano de controlo (istiod) e num plano de dados. O plano de dados é composto por proxies sidecar Envoy dentro de pods de aplicação. O Istiod gerencia e configura esses proxies do Envoy. Este artigo apresenta o desempenho tanto do plano de controlo como do plano de dados para a revisão asm-1-19, incluindo o consumo de recursos, a capacidade do sidecar e a 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 é utilizado 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ó: Standard D16 v3 (16 vCPU, 64 GB de memória)
• Versão do Kubernetes: 1.28.5
• Istio revisão: asm-1-19

Churn de Pod

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 rotatividade é definida como a percentagem de sidecars ajustados para menos/mais durante o teste. Por exemplo, 50% de rotatividade para 10.000 sidecars significaria que 5.000 sidecars foram removidos e 5.000 sidecars foram adicionados. 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 pod churn. Cada serviço tinha N sidecars que contribuíam para a contagem geral máxima 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 complemento.

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ó: Standard D16 v5 (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 Segurança de Camada de Transporte (TLS) mútua ativada
• 26 pontos de dados recolhidos

CPU e memória

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

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 sidecar proxies 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 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

Horizontal pod autoscaling (HPA) está habilitado para istiod e as implantações de gateway de entrada/saída. 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 recursos HPA do gateway ingress:

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 campo resolution 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 completamente as pesquisas de DNS de 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 (Time To Live) se controlar os domínios a serem resolvidos.
• Limite o escopo ServiceEntry com exportTo.