Container Service for Kubernetes:Container networking FAQ

Index

Quelle est la différence entre les modes de réseau ENI partagé et ENI exclusif de Terway ?

Terway propose deux modes d'allocation d'ENI pour les Pods.

• Mode ENI partagé : Plusieurs Pods partagent les ENI sur chaque nœud. Il s'agit du mode par défaut et le plus efficace en termes de ressources. Il est requis pour l'accélération réseau (DataPathv2 ou IPvlan+eBPF).

• Mode ENI exclusif : Chaque Pod dispose de sa propre ENI dédiée. Ce mode offre les meilleures performances et isolation, mais consomme considérablement plus de ressources ENI.

Consultez la rubrique Utiliser le plug-in de réseau Terway.

Comment savoir si mon cluster ACK utilise Terway en mode ENI partagé ou ENI exclusif ?

Comment vérifier si mon mode ENI partagé Terway utilise DataPathv2 ou l'ancien IPvlan+eBPF pour l'accélération réseau ?

Seul le mode ENI partagé prend en charge l'accélération réseau (DataPathv2 ou IPvlan+eBPF). DataPathv2 a remplacé IPvlan+eBPF dans Terway v1.8.0 et versions ultérieures ; les nouveaux clusters utilisent exclusivement DataPathv2.

Vérifiez la valeur eniip_virtual_type dans la ConfigMap eni-config de l'espace de noms kube-system.

1. Exécutez la commande suivante pour récupérer les données de la ConfigMap eni-config :

   kubectl get cm eni-config -n kube-system -o yaml

2. Dans la sortie, vérifiez la valeur du champ eniip_virtual_type :

   • datapathv2 : Votre cluster utilise l'accélération actuelle DataPathv2.

   • ipvlan : Votre cluster utilise l'ancienne accélération IPvlan+eBPF.

   • Si le champ est absent, l'accélération réseau est désactivée.

Le trafic contourne-t-il IPVS lors de l'utilisation des modes d'accélération réseau de Terway (DataPathv2 ou IPvlan+eBPF) ?

Oui, pour le trafic Pod-vers-Service au sein du cluster, les modes d'accélération de Terway contournent IPVS.

Lorsque l'accélération est activée, Terway utilise eBPF pour traduire directement les adresses de service en adresses IP de Pod backend dans le noyau, contournant ainsi kube-proxy IPVS et la pile réseau du nœud pour une latence réduite et un débit plus élevé.

Consultez la rubrique Plug-in de réseau Terway.

Est-il possible de changer le plug-in de réseau CNI sur un cluster ACK existant ?

Non, vous ne pouvez pas modifier le plug-in de réseau CNI (par exemple, passer de Flannel à Terway) sur un cluster ACK existant.

Le plug-in est défini lors de la création du cluster. Pour effectuer un changement, créez un nouveau cluster et migrez vos charges de travail.

Consultez la rubrique Créer un cluster ACK managé.

Pourquoi mes Pods ne peuvent-ils pas accéder à Internet après avoir ajouté un nouveau vSwitch pour Terway dans mon cluster ACK ?

Le nouveau vSwitch ne dispose probablement pas de route vers Internet, ce qui empêche les Pods utilisant ses adresses IP d'établir des connexions sortantes.

Solution

Configurez une règle SNAT pour le bloc CIDR du nouveau vSwitch à l'aide d'une passerelle NAT afin d'accorder l'accès Internet aux Pods.

Consultez la rubrique Activer l'accès Internet pour un cluster.

Mes nœuds sont NotReady après la mise à niveau de mon cluster vers Kubernetes 1.16+. Comment résoudre une incompatibilité Flannel ?

Ce problème survient lorsque vous mettez à jour manuellement l'image Flannel sans adapter sa configuration CNI aux versions plus récentes de Kubernetes.

Cause

Kubernetes 1.16+ exige un champ cniVersion dans la configuration CNI. Les anciennes configurations Flannel ne comportent pas ce champ, ce qui entraîne le passage des nœuds à l'état NotReady.

Solution

Ajoutez le champ cniVersion au ConfigMap Flannel.

Étapes

1. Modifiez le ConfigMap kube-flannel-cfg :

   kubectl edit cm kube-flannel-cfg -n kube-system 

   Dans les données net-conf.json , ajoutez "cniVersion": "0.3.1" à l'objet de configuration.

   "name": "cb0",   
   "cniVersion":"0.3.1",
   "type": "flannel",

2. Redémarrez les pods Flannel :

   kubectl delete pod -n kube-system -l app=flannel

   Les nœuds devraient alors passer à l'état Ready .

Comment résoudre les problèmes de latence réseau immédiatement après le démarrage d'un Pod ?

Symptôme

Un délai notable (de quelques secondes) s'écoule avant qu'un Pod nouvellement démarré puisse communiquer sur le réseau.

Cause

Le moteur NetworkPolicy de Terway introduit ce délai lors du calcul et de l'application des règles eBPF ou des entrées iptables pour le nouveau Pod.

Solution

Si vous n'utilisez pas de politiques réseau, désactivez cette fonctionnalité pour éliminer ce délai de démarrage.

1. Modifiez le ConfigMap eni-config de Terway :

   kubectl edit cm -n kube-system eni-config 

   Dans la section data.eni_conf , ajoutez l'indicateur disable_network_policy: "true" .

   disable_network_policy: "true"

2. Facultatif :Si vous n'utilisez pas la dernière version de Terway, effectuez sa mise à niveau dans la console.

   1. Connectez-vous à la console ACK. Dans le volet de navigation de gauche, cliquez sur Clusters.

   2. Sur la page Clusters , cliquez sur le nom de votre cluster. Dans le volet de navigation de gauche, cliquez sur Add-ons .

   3. Sur la page Add-ons , cliquez sur l'onglet Networking , puis cliquez sur Upgrade pour le module complémentaire Terway.

   4. Dans la boîte de dialogue qui s'affiche, suivez les instructions pour terminer la configuration et cliquez sur OK .

3. Redémarrez les pods Terway :

    kubectl delete pod -n kube-system -l app=terway-eniip

Pourquoi mes Pods rencontrent-ils des erreurs de connexion lorsqu'ils tentent d'accéder à un Service qu'ils exposent eux-mêmes (hairpinning) ?

Ce problème, appelé « hairpinning », se produit lorsqu'un Pod tente d'accéder à un Service qui renvoie le trafic vers lui-même. Le comportement dépend de votre plug-in réseau.

Cause

Solution recommandée

• Utiliser un Service Headless : Un Service Headless ne possède pas d'adresse ClusterIP et contourne kube-proxy . La résolution DNS pointe directement vers les adresses IP des Pods, éliminant ainsi les boucles réseau.

  Consultez la documentation Services Headless.

• Recréez le cluster avec le plug-in réseau Terway.

• Modifiez la configuration Flannel, puis recréez le plug-in Flannel et ses pods.

Solutions alternatives

• Activer le mode Hairpin dans Flannel (non recommandé) : Vous pouvez activer manuellement le hairpinning, mais les mises à niveau risquent d'écraser cette configuration.

1. Modifiez le ConfigMap kube-flannel-cfg dans l'espace de noms kube-system .

kubectl edit cm kube-flannel-cfg -n kube-system

2. Ajoutez hairpinMode: true à la section delegate de la configuration CNI.

Exemple :

cni-conf.json: |
    {
      "name": "cb0",
      "cniVersion":"0.3.1",
      "type": "flannel",
      "delegate": {
        "isDefaultGateway": true,
        "hairpinMode": true
      }
    }

3. Redémarrez tous les pods Flannel, puis recréez vos pods d'application.

kubectl delete pod -n kube-system -l app=flannel   

• Utiliser le plug-in Terway : Le plug-in réseau Terway gère correctement le trafic hairpin par défaut. Si cette fonctionnalité est essentielle, envisagez de créer un nouveau cluster avec Terway.

Quelle est la différence entre les plug-ins réseau Terway et Flannel pour un cluster Kubernetes ACK ?

Le choix du plug-in réseau approprié dépend de vos exigences spécifiques en matière de fonctionnalités et de performances.

Quelle est la bonne méthode pour planifier le réseau d'un cluster ACK ?

Une planification réseau appropriée est cruciale pour éviter l'épuisement des adresses IP et les conflits réseau. Avant de créer un cluster, vous devez déterminer trois blocs CIDR clés :

1. CIDR du VPC et des vSwitch : Il s'agit de l'espace d'adressage de vos nœuds ECS. Assurez-vous qu'il est suffisamment large pour accueillir vos nœuds actuels et futurs.

2. Bloc CIDR des Pods : Il s'agit de l'espace d'adressage de tous les Pods du cluster.

   • Il ne doit pas chevaucher le CIDR du VPC ni les réseaux locaux connectés.

   • Dimensionnez le bloc en fonction du nombre maximal de Pods anticipé. Choisir un bloc trop petit est une erreur courante.

3. Bloc CIDR des Services : Il s'agit de l'espace d'adressage des adresses IP virtuelles attribuées aux Services Kubernetes (ClusterIP).

   • Il ne doit pas chevaucher le CIDR du VPC ni le CIDR des Pods.

Planifiez ces plages à l'avance, car elles ne peuvent pas être modifiées après la création.

Consultez la rubrique Planification du réseau pour un cluster ACK managé.

ACK prend-il en charge hostPort pour les Pods ?

La prise en charge de hostPort dépend du plug-in réseau CNI.

• Flannel : Prend en charge hostPort .

• Terway : Ne prend pas en charge hostPort .

L'utilisation de hostPort est déconseillée. Voici les alternatives recommandées :

• Service NodePort : Expose le service sur un port statique de l'adresse IP de chaque nœud.

• Service LoadBalancer : Provisionne un équilibreur de charge cloud externe pour acheminer le trafic vers le service.

Avec Terway, les Pods sont directement accessibles au sein du VPC via leurs propres adresses IP, rendant hostPort inutile pour la communication intra-VPC.

Comment identifier le plug-in réseau et les vSwitch utilisés par mon cluster ?

Vérifiez dans la console ACK.

1. Pour trouver le plug-in réseau :

• Connectez-vous à la console ACK. Dans le volet de navigation de gauche, cliquez sur Clusters .

• Sur la page Clusters , cliquez sur le nom de votre cluster. Dans le volet de navigation de gauche, cliquez sur Cluster Information .

• Cliquez sur l'onglet Basic Information .

• Le champ Network Plug-in affiche soit Flannel , soit Terway .

2. Pour trouver le(s) vSwitch de nœud :

• Accédez à Nodes > Node Pools .

• Cliquez sur Details pour un pool de nœuds.

• Le champ Node vSwitch indique le(s) vSwitch où se trouvent les nœuds.

3. Pour trouver le(s) vSwitch de Pod (Terway uniquement) :

• Accédez à Add-ons sur la page de votre cluster.

• Recherchez le composant terway-eniip et cliquez sur Configuration.

• Le champ PodVswitchId répertorie le(s) vSwitch utilisé(s) pour l'allocation des adresses IP des Pods. (Cela ne s'applique pas à Flannel).

Comment afficher les ressources cloud utilisées par mon cluster ACK ?

Quelle est la méthode correcte pour modifier la configuration de kube-proxy dans un cluster ACK ?

Personnalisez le comportement de kube-proxy, tel que le mode (IPVS/iptables) ou le suivi des connexions, en modifiant son ConfigMap.

Procédure

1. Identifiez le ConfigMap :

   • Pour les clusters gérés ACK, vous devez uniquement modifier kube-proxy-worker.

   • Pour les clusters dédiés ACK, vous devez modifier à la fois kube-proxy-worker et kube-proxy-master.

2. Modifiez le ConfigMap :

   Recherchez le ConfigMap dans l'espace de noms kube-system et modifiez son fichier YAML. La configuration suit l'API Kubernetes standard KubeProxyConfiguration. Consultez la documentation Configuration de kube-proxy.

3. Appliquez les modifications :

   Après avoir enregistré les modifications, redémarrez les pods kube-proxy. Le contrôleur DaemonSet les recrée automatiquement avec la configuration mise à jour.

Comment augmenter la limite de suivi des connexions Linux (conntrack) sur mes nœuds ?

# Snippet from kube-proxy config.conf
conntrack:
  maxPerCore: 65536

Comment modifier l'algorithme d'équilibrage de charge IPVS dans kube-proxy ?

Comment réduire le délai d'expiration de session UDP dans le mode IPVS de kube-proxy pour résoudre les retards DNS ?

Lorsqu'un backend UDP (tel que CoreDNS) est supprimé, kube-proxy en mode IPVS peut bloquer le trafic vers celui-ci pendant jusqu'à 300 secondes (délai d'expiration par défaut), ce qui entraîne des retards DNS lors des déploiements ou des redémarrages.

Solution

Réduisez le délai d'expiration UDP dans la configuration de kube-proxy.

Pour Kubernetes v1.18 et versions ultérieures :

1. Modifiez le ConfigMap kube-proxy-worker (et kube-proxy-master pour les clusters dédiés) dans l'espace de noms kube-system.

2. Ajoutez ou modifiez le champ ipvs.udpTimeout. Une valeur de 10s est un choix raisonnable pour minimiser l'impact.

3. Redémarrez les pods kube-proxy pour appliquer la modification.

Pour Kubernetes v1.16 et versions antérieures :

Ces versions ne prennent pas en charge udpTimeout. Modifiez le paramètre sur chaque nœud via ipvsadm. Utilisez OOS (CloudOps Orchestration Service) pour exécuter les commandes par lots.

# This command sets the TCP, TCP-FIN, and UDP timeouts respectively.
# The third parameter '10' sets the UDP timeout to 10 seconds.
ipvsadm --set 900 120 10

Comment résoudre les problèmes courants dans un cluster à double pile IPv6 ?

• Problème : kubectl get pod n'affiche qu'une adresse IPv4.

  • Solution : Un pod peut avoir plusieurs adresses IP. Utilisez JSONPath pour toutes les afficher. Une adresse IPv6 doit être présente dans la liste podIPs.

• Problème : kubectl get svc n'affiche qu'une CLUSTER-IP IPv4.

  • Solution : Assurez-vous que le paramètre ipFamilyPolicy du service est défini sur PreferDualStack ou RequireDualStack. Affichez toutes les adresses IP du cluster avec JSONPath :

• Problème : Je ne peux pas accéder à mon pod via son adresse IPv6.

  • Cause : L'application à l'intérieur du conteneur n'écoute peut-être pas sur l'adresse any IPv6 (::). Par exemple, certains serveurs web sont configurés par défaut pour écouter sur 0.0.0.0 (IPv4 uniquement).

  • Solution : Exécutez exec dans le pod et lancez netstat -anp. Vérifiez la colonne « Local Address ». Une entrée tcp6 ou udp6 écoutant sur ::: indique qu'elle écoute correctement sur IPv6. Si ce n'est pas le cas, vous devez reconfigurer votre application.

• Problème : Mon pod est accessible via IPv6 au sein du cluster, mais pas depuis Internet.

  • Cause : L'adresse IPv6 du pod n'a pas de bande passante publique configurée.

  • Solution : Dans la console Alibaba Cloud, activez la bande passante publique pour l'adresse IPv6 via une passerelle IPv6.

• Problème : Les pods ne peuvent pas accéder à Internet via IPv6.

  • Solution : Pour activer l'accès sortant à Internet via IPv6, vous devez configurer une passerelle IPv6 pour votre VPC et vous assurer que les pods disposent d'adresses IPv6 avec la bande passante publique activée.

Mes pods sont bloqués dans l'état ContainerCreating avec des erreurs « InvalidVSwitchId.IpNotEnough ». Comment ajouter davantage d'adresses IP ?

Le vSwitch utilisé pour les adresses IP des pods a épuisé ses adresses. Ajoutez un nouveau vSwitch pour étendre le pool d'adresses IP.

Étapes

1. Créez un nouveau vSwitch : Dans la console VPC, créez un vSwitch dans la même région et la même zone de disponibilité. Utilisez un bloc CIDR large (par exemple, /19 ou inférieur).

2. Mettez à jour la configuration Terway : Dans la console ACK, accédez à Add-ons > terway-eniip > Configuration. Ajoutez l'ID du vSwitch nouvellement créé au champ PodVswitchId.

3. Redémarrez les pods Terway : Redémarrez les pods du DaemonSet Terway.

4. Vérifiez : Les nouveaux pods doivent démarrer et obtenir des adresses IP à partir du nouveau vSwitch.

Pourquoi mes pods obtiennent-ils des adresses IP à partir d'un ancien bloc CIDR de vSwitch même après avoir mis à jour la configuration Terway ?

Les ENI existants sur les nœuds restent associés à l'ancien vSwitch. Terway applique les nouveaux paramètres de vSwitch uniquement lors de la création d'un nouvel ENI.

Cause

Si un nœud possède déjà un ENI, les nouveaux pods continuent d'utiliser le pool d'adresses IP de cet ENI, ignorant les paramètres de vSwitch mis à jour. Cela se produit lors de la réutilisation de nœuds provenant d'un autre cluster ou après la modification de la configuration Terway sans recyclage des nœuds.

Solution

Effectuez une rotation des nœuds concernés pour appliquer la nouvelle configuration.

Étapes pour effectuer la rotation d'un nœud

1. Drainez et supprimez : Drainez les charges de travail en toute sécurité et supprimez le nœud du cluster.

2. Détachez les ENI : Dans la console ECS, détachez manuellement tous les ENI restants de l'instance supprimée.

3. Réajoutez le nœud : Réajoutez l'instance au cluster. Elle démarrera maintenant à neuf et créera de nouveaux ENI basés sur la configuration Terway actuelle.

J'ai ajouté un nouveau vSwitch à ma configuration Terway, mais mes pods échouent toujours à obtenir une adresse IP. Pourquoi cela se produit-il ?

Ce problème survient généralement lorsque les nœuds ont atteint leur quota maximal d'attachement d'ENI pour leur type d'instance ECS.

Cause

Bien que le nouveau vSwitch soit configuré, Terway ne peut pas créer de nouvel ENI car le nœud a atteint sa limite matérielle d'attachement d'ENI. Les ENI existants sont liés à des vSwitchs épuisés, donc aucune nouvelle adresse IP ne peut être allouée.

Solution

Effectuez une rotation des nœuds concernés pour effacer les attachements d'ENI existants et permettre de nouveaux attachements avec la configuration mise à jour.

Étapes pour effectuer la rotation d'un nœud

1. Drainez et supprimez : Drainez les charges de travail en toute sécurité et supprimez le nœud du cluster.

2. Détachez les ENI : Accédez à la console ECS et détachez manuellement tous les ENI de l'instance.

3. Réajoutez le nœud : Réajoutez l'instance au cluster. Elle pourra désormais attacher un nouvel ENI en utilisant la configuration de vSwitch mise à jour.

Comment activer l'équilibrage de charge intra-cluster pour les services ExternalIP et LoadBalancer dans un cluster Terway IPvlan existant ?

Permet aux pods d'accéder aux services LoadBalancer ou ExternalIP via leur adresse IP externe avec un trafic routé en interne. Activé par défaut dans les nouveaux clusters Terway IPvlan (v1.2.0+), mais nécessite une activation manuelle sur les clusters plus anciens.

Prérequis

• Terway v1.2.0 ou version ultérieure.

• Le cluster doit être configuré en mode IPvlan.

Solution

Activez la fonctionnalité en modifiant le ConfigMap eni-config.

Étapes

1. Modifiez le ConfigMap eni-config dans l'espace de noms kube-system :

2. Dans la section data.eni_conf, ajoutez l'indicateur in_cluster_loadbalance: "true" :

3. Redémarrez les pods Terway :

4. Vérifiez en consultant les journaux d'un nouveau pod Terway pour y trouver enable-in-cluster-loadbalance=true.

Comment attribuer des Pods à un vSwitch/plage CIDR spécifique dans un cluster Terway pour une liste d'autorisation basée sur l'IP ?

Forcez les Pods à utiliser une plage CIDR spécifique pour la liste d'autorisation basée sur l'IP en remplaçant les paramètres vSwitch par défaut de Terway pour chaque pool de nœuds.

Solution

1. Créez un ConfigMap Terway personnalisé :

   Créez un nouveau ConfigMap dans le namespace kube-system (par exemple, eni-config-fixed) qui spécifie le vSwitch dédié pour vos Pods figurant sur la liste d'autorisation.

   Cet exemple utilise vsw-2zem796p76viir02c**** et 10.2.1.0/24.

   apiVersion: v1
   data:
     eni_conf: |
       {
          "vswitches": {"cn-beijing-h":["vsw-2zem796p76viir02c****"]},
          "security_group": "sg-bp19k3sj8dk3dcd7****",
          "security_groups": ["sg-bp1b39sjf3v49c33****","sg-bp1bpdfg35tg****"]
       }
   kind: ConfigMap
   metadata:
     name: eni-config-fixed
     namespace: kube-system
   
                           

2. Configurez un pool de nœuds :

   Créez un nouveau pool de nœuds ou utilisez-en un existant. Appliquez le libellé suivant à ses nœuds : terway-config: eni-config-fixed.

3. Déployez des Pods avec un sélecteur de nœud et une tolérance :

   Déployez votre application avec un nodeSelector correspondant au libellé de l'étape 2 et une toleration pour la taint.

   apiVersion: apps/v1 # For versions earlier than 1.8.0, use apps/v1beta1.
   kind: Deployment
   metadata:
     name: nginx-fixed
     labels:
       app: nginx-fixed
   spec:
     replicas: 2
     selector:
       matchLabels:
         app: nginx-fixed
     template:
       metadata:
         labels:
           app: nginx-fixed
       spec:
         tolerations:        # Add a toleration.
         - key: "fixed"
           operator: "Equal"
           value: "true"
           effect: "NoSchedule"
         nodeSelector:
           terway-config: eni-config-fixed
         containers:
         - name: nginx
           image: nginx:1.9.0 # Replace with your actual image <image_name:tags>.
           ports:
           - containerPort: 80

   Vérification

   Les Pods de ce pool de nœuds obtiennent des adresses IP exclusivement depuis le vSwitch vsw-2zem796p76viir02c****. Ajoutez la plage CIDR de ce vSwitch à la liste d'autorisation de votre service externe.

Dans un cluster Flannel, pourquoi mes Pods peuvent-ils pinguer certaines instances ECS mais pas d'autres ?

En supposant que vos routes VPC sont correctement configurées pour le réseau superposé Flannel, ce problème est presque toujours causé par les règles du groupe de sécurité.

• Cause 1 : L'instance ECS se trouve dans le même VPC mais dans un groupe de sécurité différent.

  • Solution : Ajoutez une règle entrante au groupe de sécurité de l'instance ECS cible qui autorise le trafic provenant de la plage d'adresses IP source des nœuds de votre cluster. Pour une solution plus robuste, autorisez le trafic provenant de la plage CIDR des Pods du cluster.

• Cause 2 : L'instance ECS se trouve dans un VPC différent.

  • Solution : Les Pods doivent accéder à l'instance ECS via son adresse IP publique. Vous devez ajouter une règle entrante au groupe de sécurité de l'instance ECS qui autorise le trafic provenant de l'adresse IP de sortie publique de votre cluster (par exemple, l'IP de votre passerelle NAT).

Pourquoi les nœuds nouvellement ajoutés à mon cluster Flannel reçoivent-ils une taint NodeNetworkUnavailable ?

Cette taint signifie que le réseau du nœud n'est pas prêt. Le cloud-controller-manager (CCM) configure les routes VPC et supprime cette taint ; sa persistance indique un échec du CCM.

Causes courantes

1. La table de routage VPC est pleine : La table de routage VPC a atteint son quota et le CCM ne peut pas ajouter une nouvelle route pour la plage CIDR des Pods du nouveau nœud.

2. Plusieurs tables de routage dans le VPC : Votre VPC utilise plusieurs tables de routage, mais le CCM n'est pas configuré pour les gérer. Par défaut, il interagit uniquement avec la table de routage principale du VPC.

Solution

1. Inspectez les événements du nœud pour rechercher les messages d'erreur du CCM :

2. Si la table de routage est pleine, vous devez supprimer les routes inutilisées pour libérer de l'espace.

3. Si vous utilisez plusieurs tables de routage, configurez le CCM avec tous les ID de table de routage pertinents. Consultez Utiliser plusieurs tables de routage dans un VPC.

Pourquoi mes Pods ne parviennent-ils pas à démarrer avec l'erreur failed to allocate for range 0: no IP addresses available in range set ?

Le nœud a épuisé son sous-réseau d'adresses IP de Pod. Cela est généralement causé par des fuites d'IP — des adresses IP non libérées après la suppression des Pods.

Causes courantes des fuites d'IP

• Anciennes versions de Kubernetes (< 1,20) : Des redémarrages rapides de Pods ou des CronJobs de courte durée peuvent provoquer des fuites d'IP en raison de conditions de concurrence.

• Anciennes versions de Flannel : Les versions stockant l'allocation d'IP sur le disque (/var/lib/cni/networks/) peuvent laisser des adresses IP marquées comme allouées après des arrêts inattendus.

Solution à long terme (recommandée)

1. Mettez à niveau le cluster : Mettez à niveau votre cluster ACK vers Kubernetes 1.20 ou une version ultérieure.

2. Mettez à niveau Flannel et configurez tmpfs : Mettez à niveau Flannel, puis modifiez le ConfigMap kube-flannel-cfg pour définir le répertoire de données IPAM sur /var/run/cni/networks (effacé au redémarrage). Redémarrez les nœuds après la configuration.

Solution de contournement temporaire (si vous ne pouvez pas mettre à niveau immédiatement) :

1. Drainez le nœud concerné.

2. Connectez-vous au nœud et exécutez un script de nettoyage qui compare les fichiers IP dans /var/lib/cni/networks/cb0/ avec les conteneurs en cours d'exécution (docker ps ou crictl pods), en supprimant les entrées pour les conteneurs inexistants.

3. Annulez la mise en quarantaine (uncordon) du nœud.

Comment modifier la plage CIDR des Pods, la plage CIDR des services ou les adresses IP par nœud pour un cluster ACK existant ?

Vous ne pouvez pas modifier ces paramètres réseau fondamentaux après la création d'un cluster ACK.

La plage CIDR des Pods, la plage CIDR des services et la taille du sous-réseau par nœud sont fixées lors de la création du cluster. Pour les modifier, créez un nouveau cluster avec le plan réseau correct.

Quand dois-je configurer le cloud-controller-manager (CCM) pour plusieurs tables de routage dans un cluster Flannel ?

Vous devez configurer le CCM pour gérer plusieurs tables de routage dans un cluster Flannel dans les scénarios suivants :

• Scénario 1 : Utilisation de tables de routage personnalisées

  Si les nœuds de votre cluster résident dans des sous-réseaux associés à une table de routage personnalisée (et non à la table principale), le CCM ne parviendra pas à ajouter des routes pour les plages CIDR des Pods sauf s'il est explicitement configuré avec l'ID de cette table de routage personnalisée.

• Scénario 2 : Les journaux CCM affichent l'erreur multiple route tables found (plusieurs tables de routage trouvées)

  Ce message d'erreur indique explicitement que le CCM a détecté plusieurs tables de routage dans le VPC et ne sait pas laquelle utiliser pour gérer les routes du réseau des Pods.

• Scénario 3 : Taint NodeNetworkUnavailable persistante sur les nouveaux nœuds

  Si les nouveaux nœuds restent systématiquement bloqués avec cette taint, cela indique fortement que le CCM ne peut pas configurer leurs routes, souvent en raison d'une table de routage personnalisée non configurée.

Est-il possible d'installer un plugin réseau CNI tiers sur un cluster ACK ?

Non, les clusters ACK ne prennent pas en charge l'installation ou la configuration de plugins réseau tiers.

ACK est profondément intégré à Terway et Flannel pour le routage VPC et la gestion des ENI. L'installation d'un autre plugin CNI (tel que Calico ou Cilium) entre en conflit avec le système géré et provoque une panne du réseau.

Pourquoi obtiens-je une erreur no IP addresses available in range set dans mon cluster Flannel ?

Cette erreur signifie qu'un nœud n'a plus d'adresses IP à attribuer aux nouveaux Pods à partir de son sous-réseau CIDR de Pods désigné.

Cause

Il s'agit d'une limite stricte. Dans un cluster Flannel, la plage CIDR totale des Pods est divisée en sous-réseaux plus petits, et un sous-réseau est attribué à chaque nœud. Une fois le sous-réseau d'un nœud plein, il ne peut plus créer de Pods. Ce problème résulte d'une planification réseau inadéquate.

Solution

• À court terme : Supprimez les Pods inutilisés sur le nœud concerné pour libérer des adresses IP. Vous pouvez également ajouter un nouveau nœud au cluster, qui obtiendra son propre sous-réseau d'adresses IP frais.

• À long terme : La seule solution permanente consiste à recréer le cluster avec une plage CIDR de Pods plus grande. Planifiez soigneusement votre réseau pour allouer suffisamment d'adresses IP pour le nombre attendu de nœuds et de Pods par nœud.

Qu'est-ce qui détermine le nombre maximal de Pods par nœud dans un cluster Terway ?

Le nombre maximal de Pods par nœud dans un cluster Terway est déterminé par la capacité IP du type d'instance ECS sous-jacent.

Terway attribue des adresses IP à partir des ENI attachées au nœud. Chaque type d'instance ECS possède une limite spécifique concernant :

1. Le nombre maximal d'ENI qu'il peut attacher.

2. Le nombre maximal d'adresses IP privées par ENI.

Le nombre total d'adresses IP disponibles (et donc de Pods) est calculé comme suit : (Nombre d'ENI) × (IP par ENI). Vous pouvez trouver ces limites dans la documentation Alibaba Cloud ECS pour votre type d'instance spécifique.

Qu'est-ce que le mode DataPath V2 de Terway et en quoi diffère-t-il du mode IPvlan original ?

• DataPath V2 est le plan de données de nouvelle génération pour la fonctionnalité d'accélération réseau de Terway, servant d'amélioration au mode IPvlan+eBPF original.

  Points clés

  • Par défaut pour les nouveaux clusters : Pour les clusters créés avec Terway v1.8.0 ou une version ultérieure où l'accélération IPvlan est activée, DataPath V2 est utilisé par défaut.

  • Rétrocompatibilité : Les clusters existants qui utilisaient déjà l'ancien mode IPvlan continueront à l'utiliser même après la mise à niveau du composant Terway. Le plan de données n'est pas migré automatiquement pour éviter les interruptions.

  • Avantages : DataPath V2 offre une compatibilité et des performances améliorées par rapport à l'implémentation originale.

Que signifient les différents statuts de Pod tels que Pending et ContainerCreating dans un contexte de réseau Terway ?

Le statut du Pod reflète la progression de l'initialisation du réseau dans un environnement Terway.

• Pending : Le planificateur n'a pas encore attribué le Pod à un nœud. Cela est généralement dû à des contraintes de ressources (CPU, mémoire) ou à des règles de planification (taints, affinité). Terway n'est pas encore impliqué à ce stade.

• ContainerCreating : Le Pod est planifié et le plugin CNI configure son réseau (attachement de l'ENI, attribution d'IP). Les retards ici indiquent souvent des problèmes de ressources réseau, tels que l'épuisement des adresses IP dans le vSwitch.

• Running : Tous les conteneurs du Pod ont été créés et Terway a configuré avec succès son réseau. Le Pod devrait maintenant être opérationnel et accessible.

Inspectez les détails avec kubectl describe pod <pod-name>.

Pourquoi la mise à niveau de mon composant Terway a-t-elle échoué avec l'erreur eip pool is not supported ?

Cette erreur se produit car la fonctionnalité de pool EIP (Elastic IP) a été dépréciée et supprimée des versions récentes du composant Terway.

Solution

Avant la mise à niveau, migrez la gestion des EIP de Terway vers le composant ack-extend-network-controller, qui gère désormais les attributions d'EIP de Pod.

Pourquoi mes Pods échouent-ils parfois à se créer dans un cluster Terway avec l'erreur can't found dev by mac ?

L'erreur failed to do add; error parse config, can't found dev by mac... signifie que Terway n'a pas pu trouver l'ENI correspondant à l'adresse MAC attendue sur le nœud.

Il existe deux causes courantes :

1. Attachement asynchrone de l'ENI (problème transitoire) :

   • Explication : Une ENI nouvellement attachée prend un certain temps pour s'initialiser dans le système d'exploitation. Si le plugin CNI configure le réseau pendant cette fenêtre, il ne parvient pas à trouver le périphérique.

   • Solution : Il s'agit d'un problème de synchronisation transitoire. Le plugin CNI réessaie automatiquement. Si le Pod atteint l'état Running, ignorez ces erreurs de journal.

2. Échec du pilote du nœud (problème persistant) :

   • Explication : Si l'erreur persiste, le pilote du nœud a peut-être échoué à initialiser l'ENI en raison d'une insuffisance de mémoire d'ordre supérieur.

   • Solution : Redémarrer l'instance ECS concernée résoudra généralement cet échec au niveau du pilote.

Quels éléments dois-je prendre en compte lors de la configuration d'un domaine de cluster personnalisé pour mon cluster ACK ?

Le domaine de cluster (par défaut : cluster.local) est le suffixe DNS pour tous les services intra-cluster. Si vous le personnalisez lors de la création du cluster, vous devez respecter ces règles pour éviter les conflits de résolution DNS.

• Ne peut pas être modifié : Le domaine de cluster ne peut être défini qu'au moment de la création du cluster et ne peut pas être modifié ultérieurement.

• Doit être unique : Le domaine de cluster ne doit pas chevaucher les domaines publics externes ou les zones DNS privées que vous utilisez (par exemple, dans Alibaba Cloud DNS PrivateZone).

Pourquoi est-ce important ?

CoreDNS gère toutes les requêtes de domaine de cluster en interne et ne les transfère pas en amont (pour des raisons de sécurité et de performance).

Si votre domaine de cluster est mycompany.com et que vous avez un site public à www.mycompany.com, les Pods ne peuvent pas résoudre www.mycompany.com car CoreDNS traite mycompany.com comme une zone interne uniquement et refuse de transférer la requête.