Container Service for Kubernetes:Optimize NetworkPolicy scalability in large Terway clusters

Contexto

O Terway implementa o NetworkPolicy por meio do agente Calico Felix. Em clusters com mais de 100 nós, cada instância do Felix monitora o servidor de API de forma independente. Isso faz com que a carga do servidor escale linearmente conforme o tamanho do cluster.

O Typha atua como intermediário entre o servidor de API e as instâncias do Felix, reduzindo o número de conexões diretas de watch.

Escolha sua abordagem:

Pré-requisitos

Antes de começar, verifique se você tem:

• Um cluster gerenciado ACK com o plugin de rede Terway e mais de 100 nós.

• kubectl conectado ao cluster.

Implante o Typha como retransmissor

Implante pelo menos 3 réplicas do Typha e adicione 1 réplica para cada 200 nós adicionais.

1. Faça login no console ACK.

2. Atualize o Terway para a versão mais recente em Gerencie componentes.

   Os complementos variam conforme o modo do Terway. Consulte Comparar modos do Terway .

3. Crie um arquivo chamado calico-typha.yaml com o conteúdo a seguir. Substitua {REGION-ID} pelo ID da sua região. Defina replicas como 1 para cada 200 nós (mínimo de 3). Para versões do Kubernetes anteriores à 1.21, altere policy/v1 para policy/v1beta1 na seção PodDisruptionBudget.

   apiVersion: v1
   kind: Service
   metadata:
     name: calico-typha
     namespace: kube-system
     labels:
       k8s-app: calico-typha
   spec:
     ports:
       - port: 5473
         protocol: TCP
         targetPort: calico-typha
         name: calico-typha
     selector:
       k8s-app: calico-typha
   
   ---
   
   apiVersion: apps/v1
   kind: Deployment
   metadata:
     name: calico-typha
     namespace: kube-system
     labels:
       k8s-app: calico-typha
   spec:
     replicas: 3  # 1 replica per 200 nodes; minimum 3
     revisionHistoryLimit: 2
     selector:
       matchLabels:
         k8s-app: calico-typha
     template:
       metadata:
         labels:
           k8s-app: calico-typha
         annotations:
           cluster-autoscaler.kubernetes.io/safe-to-evict: 'true'
       spec:
         nodeSelector:
           kubernetes.io/os: linux
         hostNetwork: true
         tolerations:
           - operator: Exists
         serviceAccountName: terway
         priorityClassName: system-cluster-critical
         containers:
         - image: registry-vpc.{REGION-ID}.aliyuncs.com/acs/typha:v3.20.2
           name: calico-typha
           ports:
           - containerPort: 5473
             name: calico-typha
             protocol: TCP
           env:
             - name: TYPHA_LOGSEVERITYSCREEN
               value: "info"
             - name: TYPHA_LOGFILEPATH
               value: "none"      # Disable file logging (not needed in Kubernetes)
             - name: TYPHA_LOGSEVERITYSYS
               value: "none"      # Disable syslog (not needed in Kubernetes)
             - name: TYPHA_CONNECTIONREBALANCINGMODE
               value: "kubernetes"  # Monitor Kubernetes API to rebalance Felix connections
             - name: TYPHA_DATASTORETYPE
               value: "kubernetes"
             - name: TYPHA_HEALTHENABLED
               value: "true"
           livenessProbe:
             httpGet:
               path: /liveness
               port: 9098
               host: localhost
             periodSeconds: 30
             initialDelaySeconds: 30
           readinessProbe:
             httpGet:
               path: /readiness
               port: 9098
               host: localhost
             periodSeconds: 10
   
   ---
   
   apiVersion: policy/v1  # Use policy/v1beta1 for Kubernetes < 1.21
   kind: PodDisruptionBudget
   metadata:
     name: calico-typha
     namespace: kube-system
     labels:
       k8s-app: calico-typha
   spec:
     maxUnavailable: 1
     selector:
       matchLabels:
         k8s-app: calico-typha
   
   ---
   
   apiVersion: apiextensions.k8s.io/v1
   kind: CustomResourceDefinition
   metadata:
     name: bgppeers.crd.projectcalico.org
   spec:
     scope: Cluster
     group: crd.projectcalico.org
     versions:
     - name: v1
       served: true
       storage: true
       schema:
         openAPIV3Schema:
           type: object
           properties:
             apiVersion:
               type: string
     names:
       kind: BGPPeer
       plural: bgppeers
       singular: bgppeer

4. Aplique o manifesto.

   kubectl apply -f calico-typha.yaml

5. Verifique se todos os pods do Typha estão em execução.

   kubectl get pods -l k8s-app=calico-typha -n kube-system

   Todos os pods devem exibir 1/1 em READY e Running em STATUS antes de prosseguir. Saída esperada:

   NAME                            READY   STATUS    RESTARTS   AGE
   calico-typha-66498ddfbd-2pzsr   1/1     Running   0          69s
   calico-typha-66498ddfbd-lrtzw   1/1     Running   0          50s
   calico-typha-66498ddfbd-scckd   1/1     Running   0          62s

6. Configure o Terway para rotear as conexões do Felix pelo Typha.

   kubectl edit cm eni-config -n kube-system

   No bloco eni_conf, adicione ou atualize:

     felix_relay_service: calico-typha
     disable_network_policy: "false"  # Omit this line if the key does not exist

7. Reinicie o Terway.

   kubectl get pod -n kube-system | grep terway | awk '{print $1}' | xargs kubectl delete -n kube-system pod

   Saída esperada:

   pod "terway-eniip-8hmz7" deleted
   pod "terway-eniip-dclfn" deleted
   pod "terway-eniip-rmctm" deleted
   ...

Desative o recurso NetworkPolicy

Se as políticas de rede não forem mais necessárias, desative o NetworkPolicy para remover a carga do servidor de API associada ao Felix.

1. Edite o ConfigMap do Terway e defina disable_network_policy como "true".

   kubectl edit cm -n kube-system eni-config

   Adicione ou atualize:

   disable_network_policy: "true"

2. Reinicie o Terway.

   kubectl get pod -n kube-system | grep terway | awk '{print $1}' | xargs kubectl delete -n kube-system pod

   Saída esperada:

   pod "terway-eniip-8hmz7" deleted
   pod "terway-eniip-dclfn" deleted
   pod "terway-eniip-rmctm" deleted
   ...

Verifique o resultado

Após implantar o Typha, monitore o tráfego nas instâncias do Server Load Balancer (SLB) para confirmar a redução da carga no servidor de API.