O gateway do Alibaba Cloud Service Mesh (ASM) é um componente essencial do Istio que gerencia o tráfego de entrada e saída na borda da malha de service. Em produção, gateways não otimizados introduzem latência em cada salto de rede e tornam-se pontos únicos de falha durante eventos de dimensionamento ou interrupções regionais. Este tópico explica como otimizar cada segmento do caminho de tráfego — da resolução de Domain Name System (DNS), passando pelo balanceamento de carga, até os pods do gateway — para reduzir a latência e eliminar o tempo de inatividade.
Caminho do tráfego e alvos de otimização
Ao criar um gateway ASM, o service implanta um Deployment istio-ingressgateway no namespace istio-system do cluster Container Service for Kubernetes (ACK). O sistema associa automaticamente uma instância de Classic Load Balancer (CLB) a esse Deployment, e os pods do gateway atuam como servidores de backend da instância CLB.
Uma requisição de service percorre todos estes componentes:
Cada segmento desse caminho — resolução de DNS, balanceamento de carga, encaminhamento de rede e terminação de Transport Layer Security (TLS) — afeta a latência e a disponibilidade. As seções a seguir detalham a otimização de cada item.
Reduza a latência
Implante em várias regiões para acesso próximo
O ASM gerencia clusters ACK em múltiplas regiões e permite que os clientes se conectem ao cluster mais próximo em vez de rotear requisições por longas distâncias. A resolução inteligente de DNS mapeia cada nome de domínio para o endereço IP da instância CLB mais próxima do cliente. Essa abordagem reduz o tempo de ida e volta e distribui o tráfego geograficamente.
O balanceamento de carga entre regiões também tem suporte. Quando uma região fica sobrecarregada, o tráfego é desviado automaticamente para regiões mais saudáveis. Para obter detalhes, consulte Use ASM to implement cross-region disaster recovery and load balancing.
Selecione o plug-in CNI Terway para encaminhamento direto aos pods
O plug-in da Container Network Interface (CNI) no cluster ACK determina como a instância CLB encaminha o tráfego para os pods do gateway:
|
Plug-in CNI |
Caminho do tráfego |
Impacto na latência |
|
Terway (recomendado) |
O CLB encaminha o tráfego diretamente para os pods do gateway |
Menor latência — evita o salto extra pelo NodePort |
|
Flannel |
O CLB encaminha para o Service NodePort, que então roteia para os pods do gateway |
Maior latência — adiciona um salto de rede extra |
Utilize o plug-in CNI Terway para cargas de trabalho em produção. O encaminhamento direto aos pods elimina a sobrecarga do roteamento baseado em NodePort. Para uma comparação detalhada, consulte Terway and Flannel.
Escale com múltiplas instâncias CLB
Se uma única instância CLB não conseguir lidar com o volume de tráfego do gateway, associe várias instâncias CLB ao mesmo gateway. Cada instância distribui o tráfego independentemente para os pods do gateway e aumenta o throughput total.
Consulte Access an ASM gateway by using multiple CLB instances.
Ative a aceleração de TLS
Os gateways ASM na edição comercial suportam aceleração de TLS com tecnologia Intel Multi-Buffer. Em testes de benchmark, a ativação desse recurso melhorou as consultas por segundo (QPS) em 80%.
Nota: A melhoria de 80% no QPS foi medida em benchmarks internos da Alibaba Cloud. Os ganhos reais dependem das características da carga de trabalho, dos tamanhos das chaves dos certificados e da configuração de hardware.
Consulte Enable Multi-Buffer for TLS acceleration.
Elimine o tempo de inatividade
Configure a recuperação de desastres geográfica
Implante clusters ACK em várias regiões com redundância geográfica ativa. Se uma região inteira ficar offline, o tráfego fará failover automaticamente para clusters em outras regiões. Combinada com a resolução inteligente de DNS, essa estratégia fornece recuperação de desastres no nível da região sem intervenção manual.
Consulte Use ASM to implement cross-region disaster recovery and load balancing.
Adicione redundância de CLB
Associe múltiplas instâncias CLB a um único gateway ASM. Assim, se uma instância falhar, as outras continuarão a servir o tráfego. Essa configuração elimina o balanceador de carga como ponto único de falha.
Consulte Access an ASM gateway by using multiple CLB instances.
Distribua os pods do gateway entre nós e zonas
Espalhe os pods do gateway por diferentes nós e zonas de disponibilidade para proteger contra interrupções no nível de nó ou de zona. Use regras de anti-afinidade de pods e restrições de distribuição de topologia para controlar o posicionamento.
O exemplo a seguir mostra uma restrição de distribuição de topologia que distribui os pods do gateway uniformemente entre as zonas de disponibilidade:
apiVersion: apps/v1
kind: Deployment
metadata:
name: istio-ingressgateway
namespace: istio-system
spec:
template:
spec:
topologySpreadConstraints:
- maxSkew: 1
topologyKey: topology.kubernetes.io/zone
whenUnsatisfiable: DoNotSchedule
labelSelector:
matchLabels:
istio: ingressgateway
affinity:
podAntiAffinity:
preferredDuringSchedulingIgnoredDuringExecution:
- weight: 100
podAffinityTerm:
labelSelector:
matchLabels:
istio: ingressgateway
topologyKey: kubernetes.io/hostnamePara o procedimento completo de configuração, consulte Improve availability for the ingress gateway service of an ASM instance.
Ative o desligamento graceful para services
Configure um hook de pre-stop nos pods de service para drenar as requisições em andamento antes do encerramento do pod. Sem o desligamento graceful, as requisições ativas falham ou são perdidas durante eventos de dimensionamento e atualizações contínuas.
Ative a drenagem de conexões na instância CLB
Quando o gateway ASM escala horizontalmente (scale in ou scale out), mantenha as conexões existentes na instância CLB por um período configurável para permitir a conclusão das requisições em andamento. Ative a drenagem de conexões na instância CLB para evitar perda de tráfego durante as transições de pods.
Checklist de preparação para produção
Antes de entrar em produção, verifique a conclusão das configurações a seguir. Além dos itens de desempenho e disponibilidade abordados acima, configure também HorizontalPodAutoscaler, PodDisruptionBudget e solicitações/limites de recursos no Deployment de gateway para lidar adequadamente com dimensionamento e interrupções.
Desempenho
|
Configuração |
Status |
Observações |
|
Implantação multirregião com DNS inteligente |
Obrigatório para usuários distribuídos geograficamente |
Reduz a latência entre cliente e gateway |
|
Plug-in CNI Terway para encaminhamento direto aos pods |
Recomendado para todos os clusters de produção |
Elimina o salto do NodePort |
|
Múltiplas instâncias CLB |
Necessário quando o tráfego excede a capacidade de uma única instância |
Aumenta o throughput total |
|
Aceleração de TLS (Intel Multi-Buffer) |
Recomendado na edição comercial |
Melhoria de até 80% no QPS |
Disponibilidade
|
Configuração |
Status |
Observações |
|
Redundância geográfica ativa entre regiões |
Obrigatório para recuperação de desastres no nível da região |
Failover automático com DNS inteligente |
|
Múltiplas instâncias CLB |
Necessário para eliminar SPOF do balanceador de carga |
Fornece redundância no nível do CLB |
|
Anti-afinidade de pods e restrições de distribuição de topologia |
Obrigatório |
Distribui pods entre nós e zonas |
|
Hooks de pre-stop nos pods de service |
Obrigatório |
Drena requisições em andamento antes do encerramento |
|
Drenagem de conexões nas instâncias CLB |
Obrigatório |
Evita perda de tráfego durante o dimensionamento |
|
|
Recomendado |
Escala automaticamente os pods do gateway com base na carga |
|
|
Recomendado |
Impede que interrupções voluntárias removam muitos pods |
|
Solicitações e limites de recursos |
Recomendado |
Evita contenção de recursos e encerramentos por OOM |