Os gateways de entrada são o ponto de entrada de tráfego para os serviços em uma instância do Service Mesh (ASM). Se um pod do gateway falhar e não houver outros pods disponíveis, seus serviços ficarão inacessíveis. A distribuição dos pods do gateway entre vários nós ou zonas de disponibilidade evita que uma única falha interrompa todo o caminho de entrada.
A abordagem de configuração varia conforme o tipo de cluster:
|
Tipo de cluster |
Mecanismo de HA |
Motivo |
|
Cluster ACK |
Antiafinidade de pods |
Distribui os pods do gateway entre nós ou zonas por meio de regras de agendamento do Kubernetes |
|
Cluster ACK Serverless |
Anotações de pods ECI |
Distribui os pods entre zonas (clusters serverless não suportam antiafinidade de pods) |
Pré-requisitos
Instância do ASM criada. Para mais informações, consulte Criar uma instância do ASM.
Cluster do Container Service for Kubernetes (ACK) ou cluster ACK Serverless. Para mais informações, consulte Criar um cluster gerenciado do ACK ou Criar um cluster ACK Serverless.
Distribuir pods com antiafinidade (clusters ACK)
Em clusters ACK, adicione uma regra podAntiAffinity ao YAML do IstioGateway para impedir que o agendador aloque múltiplos pods do gateway no mesmo nó ou na mesma zona.
Distribuir pods entre nós
Defina topologyKey como kubernetes.io/hostname para limitar a execução a apenas um pod do gateway por nó.
O exemplo de YAML do IstioGateway abaixo inclui o bloco affinity para antiafinidade no nível de nó. A tabela seguinte detalha os campos de antiafinidade.
apiVersion: istio.alibabacloud.com/v1beta1
kind: IstioGateway
metadata:
name: ingressgateway-1
namespace: istio-system
spec:
clusterIds:
- "c954ee9df88f64f229591f0ea4c61****"
cpu:
targetAverageUtilization: 80
externalTrafficPolicy: Local
maxReplicas: 4
minReplicas: 2
ports:
- name: status-port
port: 15020
targetPort: 15020
- name: http2
port: 80
targetPort: 80
- name: https
port: 443
targetPort: 80
- name: tls
port: 15443
targetPort: 15443
replicaCount: 1
resources:
limits:
cpu: '2'
memory: 2G
requests:
cpu: 200m
memory: 256Mi
sds:
enabled: true
resources:
requests:
cpu: 100m
memory: 128Mi
limits:
cpu: 2000m
memory: 1024Mi
serviceType: LoadBalancer
# --- Pod anti-affinity: spread pods across nodes ---
affinity:
podAntiAffinity:
preferredDuringSchedulingIgnoredDuringExecution:
- podAffinityTerm:
labelSelector:
matchExpressions:
- key: app
operator: In
values:
- istio-ingressgateway-1
topologyKey: kubernetes.io/hostname # One pod per node
weight: 100
rollingMaxSurge: "100%"
rollingMaxUnavailable: "25%"Campos de antiafinidade:
|
Campo |
Valor |
Efeito |
|
|
(regra flexível) |
O agendador tenta respeitar esta regra, mas agenda o pod mesmo se nenhum nó compatível estiver disponível. |
|
|
|
Seleciona pods com o rótulo |
|
|
|
Define o domínio de falha como nós individuais. Cada nó executa, no máximo, um pod do gateway. |
|
|
|
Determina a prioridade da regra. Valores maiores aumentam a influência da regra durante a avaliação dos nós candidatos pelo agendador. |
Distribuir pods entre zonas
Para proteger contra falhas no nível de zona, altere topologyKey para topology.kubernetes.io/zone. O restante da configuração permanece idêntico.
Substitua o bloco affinity por:
affinity:
podAntiAffinity:
preferredDuringSchedulingIgnoredDuringExecution:
- podAffinityTerm:
labelSelector:
matchExpressions:
- key: app
operator: In
values:
- istio-ingressgateway-1
topologyKey: topology.kubernetes.io/zone # One pod per zone
weight: 100Essa configuração faz com que o agendador distribua os pods do gateway de modo que cada zona de disponibilidade execute, no máximo, um pod com o rótulo app=istio-ingressgateway-1.
Distribuir pods entre zonas com anotações ECI (clusters ACK Serverless)
Clusters ACK Serverless executam pods como Elastic Container Instance (ECI) e não suportam o mecanismo padrão de antiafinidade de pods do Kubernetes. Use anotações específicas de pods ECI para distribuir os pods do gateway entre as zonas de disponibilidade.
Etapa 1: Configurar múltiplas zonas
Configure vários vSwitches em zonas diferentes no cluster ACK Serverless. Para obter instruções, consulte Criar ECIs em várias zonas.
Etapa 2: Adicionar anotações de zona ao gateway de entrada
No YAML do IstioGateway, adicione uma seção podAnnotations para especificar os IDs dos vSwitches e a estratégia de agendamento. O exemplo a seguir distribui os pods ECI aleatoriamente entre as zonas especificadas.
apiVersion: istio.alibabacloud.com/v1beta1
kind: IstioGateway
metadata:
name: ingressgateway
namespace: istio-system
spec:
clusterIds:
- "c954ee9df88f64f229591f0ea4c61****"
cpu:
targetAverageUtilization: 80
externalTrafficPolicy: Local
maxReplicas: 4
minReplicas: 2
ports:
- name: status-port
port: 15020
targetPort: 15020
- name: http2
port: 80
targetPort: 80
- name: https
port: 443
targetPort: 80
- name: tls
port: 15443
targetPort: 15443
replicaCount: 1
resources:
limits:
cpu: '2'
memory: 2G
requests:
cpu: 200m
memory: 256Mi
sds:
enabled: true
resources:
requests:
cpu: 100m
memory: 128Mi
limits:
cpu: 2000m
memory: 1024Mi
serviceType: LoadBalancer
# --- ECI zone distribution annotations ---
podAnnotations:
k8s.aliyun.com/eci-vswitch: "vsw-bp1b07j0miob3khtn****,vsw-bp12b85hh323se8ft****" # vSwitch IDs in different zones
k8s.aliyun.com/eci-schedule-strategy: "VSwitchRandom" # Distribute pods randomly across zones
rollingMaxSurge: "100%"
rollingMaxUnavailable: "25%"Referência de anotações:
|
Anotação |
Descrição |
|
|
IDs de vSwitch separados por vírgula. Cada vSwitch deve pertencer a uma zona diferente dentro da mesma Virtual Private Cloud (VPC). Substitua os IDs de exemplo pelos seus próprios IDs de vSwitch. |
|
|
Estratégia de agendamento para pods ECI. Defina como |