Quando um cluster Kubernetes no plano de dados de uma instância do Service Mesh (ASM) usa um Classic Load Balancer (CLB) com externalTrafficPolicy: Local para o ingress gateway, os pods em alguns nós podem não conseguir acessar o endereço IP do CLB. Este tópico explica a causa e apresenta três soluções.
Sintoma
Um cluster Kubernetes foi adicionado a uma instância do ASM. Um CLB com externalTrafficPolicy definido como Local está configurado para o ingress gateway. Você observa o seguinte comportamento:
Os pods em alguns nós conseguem acessar o endereço IP do CLB do ingress gateway.
Os pods em outros nós não conseguem acessar o mesmo endereço IP do CLB.
Causa
Quando externalTrafficPolicy é Local, o kube-proxy programa regras de encaminhamento de iptables ou IP Virtual Server (IPVS) apenas nos nós que executam os pods de backend do Service do ingress gateway. Os nós sem pods do ingress gateway não possuem essas regras de encaminhamento, portanto o tráfego destinado ao endereço IP do CLB não chega ao destino.
O endereço IP do CLB é tratado como um IP externo do Service. Em vez de encaminhar o tráfego para o balanceador de carga e de volta, o kube-proxy redireciona as requisições por meio de regras locais de iptables ou IPVS. Com externalTrafficPolicy: Local, apenas os nós com endpoints locais recebem essas regras.
Para a discussão upstream do Kubernetes, consulte Por que o kube-proxy adiciona o endereço do external-lb às regras locais de iptables do nó?.
Verificar o problema
Antes de aplicar uma correção, confirme que esta causa raiz se aplica à sua situação.
Verifique quais nós executam pods do ingress gateway: Observe a coluna NODE. Os pods nesses nós conseguem acessar o IP do CLB. Os pods em outros nós não conseguem.
kubectl get pods -n istio-system -l app=istio-ingressgateway -o wideVerifique os endpoints do Service do ingress gateway: Os endereços IP listados correspondem aos pods do ingress gateway. Os nós sem esses pods não têm as regras de encaminhamento locais necessárias para acessar o IP do CLB.
kubectl get endpoints -n istio-system istio-ingressgateway(Opcional) Em um nó onde o acesso falha, verifique se não existem regras de iptables para o IP do CLB: Substitua
<CLB_IP>pelo endereço IP real do CLB. Se nenhuma saída for retornada, o nó não tem regra de encaminhamento para esse IP, o que confirma o problema.iptables-save | grep <CLB_IP>
Soluções
Escolha uma solução de acordo com seus requisitos:
| Solução | IP de origem preservado | Requer ENI | Complexidade |
|---|---|---|---|
| Acessar o ingress gateway pelo IP do cluster ou nome do Service | Sim | Não | Baixa |
Definir externalTrafficPolicy como Cluster | Não | Não | Baixa |
Usar Cluster com conexão direta por ENI | Sim | Sim | Média |
Solução 1: Acessar o ingress gateway pelo IP do cluster ou nome do Service (recomendado)
Em vez de usar o endereço IP do CLB de dentro do cluster, use o endereço IP do cluster ou o nome do Service do Kubernetes para acessar o ingress gateway:
istio-ingressgateway.istio-systemEssa abordagem funciona em todos os nós, independentemente de onde os pods do ingress gateway estejam em execução, preserva os endereços IP de origem e não exige alterações de configuração.
Solução 2: Definir externalTrafficPolicy como Cluster
Altere externalTrafficPolicy de Local para Cluster. Isso instrui o kube-proxy a programar regras de encaminhamento em todos os nós, não apenas nos que executam pods do ingress gateway.
Desvantagem: Os endereços IP de origem não são preservados. Todas as requisições parecem originar-se do IP do nó em que o kube-proxy encaminha o tráfego.
Atualize o recurso personalizado IstioGateway:
apiVersion: istio.alibabacloud.com/v1beta1
kind: IstioGateway
metadata:
name: ingressgateway
namespace: istio-system
....
spec:
externalTrafficPolicy: Cluster
....Para detalhes dos campos, consulte Campos do CRD de um gateway.
Solução 3: Usar Cluster com conexão direta por ENI
Se o cluster usa interfaces de rede elástica (ENIs) do Terway ou executa no modo ENI inclusivo, combine externalTrafficPolicy: Cluster com a anotação service.beta.kubernetes.io/backend-type: eni. Isso restaura a preservação do IP de origem por meio de conexão direta por ENI, mantendo o IP do CLB acessível de todos os nós.
Pré-requisitos: O cluster deve usar o Terway como plugin CNI, com o modo ENI ou ENI inclusivo habilitado.
Atualize o recurso personalizado IstioGateway:
apiVersion: istio.alibabacloud.com/v1beta1
kind: IstioGateway
metadata:
name: ingressgateway
namespace: istio-system
....
spec:
externalTrafficPolicy: Cluster
maxReplicas: 5
minReplicas: 2
ports:
- name: status-port
port: 15020
targetPort: 15020
- name: http2
port: 80
targetPort: 80
- name: https
port: 443
targetPort: 443
- name: tls
port: 15443
targetPort: 15443
replicaCount: 2
resources:
limits:
cpu: '2'
memory: 2G
requests:
cpu: 200m
memory: 256Mi
runAsRoot: false
serviceAnnotations:
service.beta.kubernetes.io/backend-type: eni
serviceType: LoadBalancerO campo serviceAnnotations: service.beta.kubernetes.io/backend-type: eni encaminha o tráfego diretamente por meio de ENIs e preserva os endereços IP de origem.
Para detalhes dos campos, consulte Campos do CRD de um gateway.