Container Service for Kubernetes:FAQ sur le service

Quelles instances CLB un cluster ACK crée-t-il par défaut ?

Si le module complémentaire Nginx Ingress Controller est installé lors de la création du cluster, celui-ci crée deux instances CLB :

• CLB du serveur API : endpoint du serveur API. Toutes les requêtes du cluster transitent par cette instance sur le port TCP 6443. Les backends sont les pods du serveur API ou les instances ECS master.

• CLB du Nginx Ingress Controller : associé au service nginx-ingress-controller dans kube-system. Se lie dynamiquement aux pods Ingress Controller pour l'équilibrage de charge des requêtes externes. Écoute sur les ports TCP 80 et 443.

Comment choisir entre les politiques de trafic externe Local et Cluster ?

Les politiques de trafic externe Local et Cluster diffèrent selon le plugin réseau. Consultez Politiques de trafic externe : Local et Cluster.

Pourquoi ma configuration CLB a-t-elle été modifiée ?

Le CCM utilise une API déclarative et met automatiquement à jour la configuration du CLB en fonction de la définition du service. Les modifications directes apportées dans la console CLB peuvent être écrasées.

Comment les poids des nœuds sont-ils calculés en mode Local ?

L'exemple suivant utilise un pod d'application (app=nginx) déployé sur trois instances ECS et exposé via un service.

Comment activer la vidange de connexion pour un service LoadBalancer ?

Ajoutez les annotations suivantes au service. Après la suppression d'un serveur backend, l'instance CLB continue de traiter les connexions existantes pendant la durée du délai de vidange.

• service.beta.kubernetes.io/alibaba-cloud-loadbalancer-connection-drain

• service.beta.kubernetes.io/alibaba-cloud-loadbalancer-connection-drain-timeout

Consultez Activer la vidange de connexion pour un écouteur.

Comment lister toutes les instances CLB d'un cluster ?

1. Connectez-vous au cluster à l'aide de kubectl.

2. Récupérez le nom, le namespace, l'adresse IP et le type d'adresse de chaque service LoadBalancer. Exemple de sortie :

      kubectl get services -A -ojson | jq '.items[] | select(.spec.type == "LoadBalancer") | {name: .metadata.name, namespace: .metadata.namespace, ip: .status.loadBalancer.ingress[0].ip, lb_type: .metadata.annotations."service.beta.kubernetes.io/alibaba-cloud-loadbalancer-address-type"}'

      {
        "name": "test",
        "namespace": "default",
        "ip": "192.168.*.*",
        "lb_type": "intranet"
      }
      {
        "name": "nginx-ingress-lb",
        "namespace": "kube-system",
        "ip": "47.97.*.*",
        "lb_type": "null"
      }

Comment activer le renommage du CLB pour les anciennes versions du CCM ?

Le CCM v1.9.3.10 et les versions ultérieures taguent automatiquement les instances CLB pour prendre en charge le renommage. Pour les instances CLB créées par des versions antérieures du CCM, ajoutez le tag manuellement.

Cette procédure s'applique uniquement aux instances CLB créées par le CCM v1.9.3.10 ou une version antérieure. Le type de service doit être LoadBalancer.

1. Connectez-vous au nœud master du cluster. Consultez Se connecter à un cluster ACK à l'aide de kubectl.

2. Affichez le type de service et l'adresse IP. Remplacez ${namespace} et ${service} par le namespace et le nom du service réels.

      kubectl get svc -n ${namespace} ${service}

   # kubectl get svc -n ${namespace} ${service}
   nginx-local   LoadBalancer   172.19.xxx.xxx   47.111.xxx.xxx   8900:31598/TCP   33d

3. Générez le tag pour l'instance CLB :

      kubectl get svc -n ${namespace} ${service} -o jsonpath="{.metadata.uid}"|awk -F "-" '{print "kubernetes.do.not.delete: "substr("a"$1$2$3$4$5,1,32)}'

   # kubectl get svc -n ${namespace} ${service} -o jsonpath="{.metadata.uid}"|awk -F "-" '{print "ku
   kubernetes.do.not.delete: xxx

4. Connectez-vous à la console CLB. À l'aide de l'adresse IP obtenue à l'étape 2, recherchez l'instance CLB dans la région correspondante.

5. Ajoutez un tag à l'instance CLB en utilisant la clé et la valeur de l'étape 3 (éléments 1 et 2 de la figure précédente). Consultez Créer et gérer une instance CLB.

Pourquoi une adresse IP CLB est-elle inaccessible depuis le cluster ?

Deux scénarios peuvent en être la cause.

Scénario 1 : CLB privé non créé par un service

Lorsqu'un pod accède à une instance CLB privée non créée par un service, l'accès échoue si le pod et un serveur backend se trouvent sur le même nœud. Il s'agit d'une limitation de la couche 4 : une instance ECS ne peut pas être à la fois un serveur backend et un client pour la même instance CLB.

Pour résoudre ce problème :

• Modifiez l'adresse IP du CLB en une adresse IP publique.

• Créez l'instance CLB via un service et définissez la politique de trafic externe sur Cluster. Kube-proxy intercepte alors le trafic lié au CLB depuis l'intérieur du cluster, contournant ainsi la limitation.

**Scénario 2 : externalTrafficPolicy: Local bloque l'accès interne**

Lorsqu'un service utilise externalTrafficPolicy: Local, l'accès interne à l'IP du CLB échoue depuis les nœuds sans pod backend. L'adresse CLB est destinée à un usage externe. Le trafic interne est intercepté par kube-proxy et routé localement (iptables ou IPVS). Si le nœud ne possède aucun pod backend local, la connexion échoue.

Consultez kube-proxy ajoute l'adresse external-lb aux règles iptables du nœud local.

Solutions (classées par recommandation) :

1. Accédez aux services en interne via ClusterIP ou le nom du service. Par exemple, le nom du service Ingress est nginx-ingress-lb.kube-system. C'est l'approche recommandée.

2. **Remplacez externalTrafficPolicy par Cluster.** Cela transfère le trafic vers tous les nœuds mais active le SNAT, empêchant ainsi le backend de récupérer l'IP réelle du client.

      kubectl edit svc nginx-ingress-lb -n kube-system

3. Utilisez le passthrough d'interface réseau élastique (ENI) sur les clusters Terway. Définissez externalTrafficPolicy sur Cluster et ajoutez l'annotation service.beta.kubernetes.io/backend-type: "eni". Cela préserve l'IP source tout en permettant l'accès interne. Consultez Utiliser des annotations pour configurer une instance Classic Load Balancer (CLB).

      apiVersion: v1
      kind: Service
      metadata:
        annotations:
          service.beta.kubernetes.io/backend-type: eni
        labels:
          app: nginx-ingress-lb
        name: nginx-ingress-lb
        namespace: kube-system
      spec:
        externalTrafficPolicy: Cluster

Quand les instances CLB sont-elles supprimées ?

Le comportement de suppression dépend du fait que le CCM ait créé l'instance CLB et de la manière dont elle a été associée au service.

Si le service réutilise une instance CLB existante (annotée avec service.beta.kubernetes.io/alibaba-cloud-loadbalancer-id: {your-slb-id}), la suppression du service ne supprime pas l'instance CLB. Sinon, la suppression du service entraîne également celle de l'instance CLB.

Que faire si je supprime accidentellement une instance CLB ?

Scénario 1 : Suppression du CLB Ingress

Les étapes suivantes utilisent Nginx Ingress comme exemple.

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

2. Sur la page Clusters, trouvez le cluster cible et cliquez sur son nom. Dans le volet de navigation de gauche, choisissez Network > Services.

3. Sélectionnez kube-system dans la liste déroulante Namespace.

   • Si nginx-ingress-lb apparaît dans la liste, cliquez sur Edit YAML dans la colonne Actions. Supprimez le champ status.loadBalancer et son contenu, puis cliquez sur OK. Le CCM reconstruit l'instance CLB.

   • Si nginx-ingress-lb n'apparaît pas, cliquez sur Create from YAML et utilisez le modèle suivant : ``yaml apiVersion: v1 kind: Service metadata: labels: app: nginx-ingress-lb name: nginx-ingress-lb namespace: kube-system spec: externalTrafficPolicy: Local ports: selector: app: ingress-nginx type: LoadBalancer ``

     • name: http port: 80 protocol: TCP targetPort: 80

     • name: https port: 443 protocol: TCP targetPort: 443

Scénario 2 : Suppression du CLB spécifique à l'application

• Si le service n'est plus nécessaire, supprimez-le.

• Si le service est toujours utilisé :

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

  2. Sur la page Clusters, trouvez le cluster cible et cliquez sur son nom. Dans le volet de navigation de gauche, choisissez Network > Services.

  3. Dans la liste déroulante Namespace, cliquez sur All Namespaces, puis trouvez le service cible.

  4. Dans la colonne Actions, cliquez sur Edit YAML. Supprimez le contenu de status.loadBalancer et cliquez sur OK. Le CCM reconstruit l'instance CLB.

Pourquoi la réutilisation d'une instance CLB existante échoue-t-elle ?

Vérifiez les points suivants dans l'ordre :

1. Version du CCM : Les versions antérieures à v1.9.3.105-gfd4e547-aliyun ne prennent pas en charge la réutilisation des instances CLB. Pour obtenir des instructions de mise à niveau, consultez Mettre à niveau le composant CCM.

2. Origine de l'instance : Les instances CLB créées par le cluster ne peuvent pas être réutilisées.

3. CLB du serveur API : L'instance CLB du serveur API ne peut pas être réutilisée.

4. Incompatibilité VPC : Une instance CLB orientée vers le réseau privé doit se trouver dans le même cloud privé virtuel (VPC) que le cluster. La réutilisation inter-VPC n'est pas prise en charge.

Pourquoi les écouteurs ne sont-ils pas créés lors de la réutilisation d'une instance CLB existante ?

Vérifiez que l'annotation service.beta.kubernetes.io/alibaba-cloud-loadbalancer-force-override-listeners est définie sur "true". Sans cela, les écouteurs ne sont pas créés.

Le CCM n'écrase pas les écouteurs des instances CLB existantes par défaut :

L'écrasement des écouteurs actifs peut provoquer des interruptions de service.

Le CCM prend en charge un nombre limité de configurations backend. Pour des configurations complexes, créez les écouteurs dans la console CLB. Ne forcez le remplacement des écouteurs que lorsque leurs ports ne sont plus utilisés.

Que faire si une instance CLB reste à l'état Pending ?

1. Exécutez kubectl -n {your-namespace} describe svc {your-svc-name} pour vérifier les messages d'événement.

2. Résolvez les erreurs signalées dans les événements. Consultez Messages d'erreur de service et solutions pour obtenir des conseils.

Si aucun événement n'apparaît, consultez Pourquoi aucun événement n'est affiché pour la synchronisation Service et LoadBalancer ?

Que faire si un groupe de serveurs virtuels n'est pas mis à jour ?

1. Exécutez kubectl -n {your-namespace} describe svc {your-svc-name} pour vérifier les messages d'événement.

2. Résolvez les erreurs signalées dans les événements. Consultez Messages d'erreur de service et solutions pour obtenir des conseils.

Si aucun événement n'apparaît, consultez Pourquoi aucun événement n'est affiché pour la synchronisation Service et LoadBalancer ?

Que faire si une annotation de service ne prend pas effet ?

1. Exécutez kubectl -n {your-namespace} describe svc {your-svc-name} pour vérifier la présence d'événements d'erreur. Si des erreurs existent, consultez Messages d'erreur de service et solutions.

2. Si aucune erreur n'apparaît, vérifiez les points suivants :

   • Version du CCM : Vérifiez que la version du CCM prend en charge l'annotation. Consultez Utiliser des annotations pour configurer une instance Classic Load Balancer (CLB).

   • Présence de l'annotation : Connectez-vous à la console ACK. Sur la page Services, cliquez sur le nom du service et confirmez que l'annotation existe. Si elle est manquante, ajoutez-la. Consultez Utiliser des annotations pour configurer une instance Classic Load Balancer (CLB).

   • Syntaxe de l'annotation : Vérifiez que la clé et la valeur de l'annotation sont correctes.

Pour afficher la liste des services, consultez Gérer les services.

Pourquoi aucun événement n'est affiché pour la synchronisation Service et LoadBalancer ?

Si kubectl -n {your-namespace} describe svc {your-svc-name} n'affiche aucun événement, vérifiez la version du CCM :

• Antérieure à v1.9.3.276-g372aa98-aliyun : Les événements ne sont pas pris en charge. Mettez à niveau le CCM. Pour obtenir des instructions de mise à niveau, consultez Mettre à niveau le composant CCM.

• v1.9.3.276-g372aa98-aliyun et versions ultérieures : Soumettre un ticket pour une enquête approfondie.

Erreurs de quota et de ressources

Erreurs de configuration

Erreurs réseau

Erreurs de réutilisation du CLB

Erreurs de facturation

Comment accéder à un service NodePort ?

• Depuis l'intérieur du cluster (sur un nœud du cluster) : Utilisez ClusterIP + port, ou l'IP du nœud + NodePort du service. Le NodePort par défaut est supérieur à 30000.

• Depuis l'extérieur du cluster (au sein du même VPC) : Utilisez l'adresse IP du nœud et le NodePort du service.

• Depuis l'extérieur du VPC (depuis un autre VPC ou Internet) : Exposez le service en tant que type LoadBalancer et accédez-y via son endpoint externe.

Si la politique de trafic externe est Local, vérifiez que le nœud auquel vous accédez héberge un pod backend du service. Consultez Politiques de trafic externe : Local et Cluster .

Comment configurer un écouteur pour un service NodePort ?

Le CCM prend en charge la configuration des écouteurs uniquement pour les services LoadBalancer. Changez le type de service de NodePort à LoadBalancer.

Comment configurer la plage de ports NodePort ?

Le paramètre --service-node-port-range du serveur API (ServiceNodePortRange) contrôle la plage de ports pour les services NodePort et LoadBalancer. La plage par défaut est de 30000 à 32767. Dans les clusters ACK Pro, personnalisez les paramètres du plan de contrôle pour ajuster cette plage. Consultez Personnaliser les paramètres du plan de contrôle pour un cluster ACK Pro.

Gardez les points suivants à l'esprit :

• Évitez les conflits de plage de ports. La plage NodePort ne doit pas chevaucher le paramètre noyau net.ipv4.ip_local_port_range , qui contrôle les numéros de port locaux disponibles pour les applications sur le nœud. La valeur par défaut de ip_local_port_range est de 32768 à 60999.

• Les plages par défaut sont sûres. Avec les paramètres ACK par défaut, ServiceNodePortRange (30000-32767) et ip_local_port_range (32768-60999) ne se chevauchent pas. Si l'une des plages a été étendue et qu'elles se chevauchent désormais, des exceptions réseau sporadiques peuvent survenir. Dans les cas graves, les contrôles d'intégrité échouent et les nœuds passent hors ligne. Restaurez les valeurs par défaut ou ajustez les deux plages pour éliminer le chevauchement.

• Reconfigurez les services existants après les modifications. Après avoir ajusté la plage de ports, certains services NodePort ou LoadBalancer peuvent encore utiliser des ports dans la plage ip_local_port_range . Exécutez kubectl edit <service-name> et modifiez le champ spec.ports.nodePort pour utiliser un NodePort inutilisé.

Que faire si la mise à niveau du CCM échoue ?

Consultez L'échec de la vérification de mise à niveau de Cloud Controller Manager (CCM) .

Comment ajouter les autorisations requises pour une mise à niveau du CCM dans un cluster ACK dédié ?

Les versions ultérieures du CCM introduisent des API Alibaba Cloud qui nécessitent des autorisations supplémentaires de Resource Access Management (RAM). Par exemple, la version 2.11.2 ajoute la gestion des routes pour les réseaux Flannel, et la version 2.12.1 ajoute la gestion par lots pour Network Load Balancer (NLB).

Avant de mettre à niveau vers la version 2.11.2 ou ultérieure dans un cluster ACK dédié, accordez les autorisations requises au rôle RAM du cluster :

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

2. Sur la page Clusters , trouvez le cluster cible et cliquez sur son nom. Dans le volet de navigation de gauche, cliquez sur Cluster Information .

3. Cliquez sur l'onglet Basic Information , puis cliquez sur le nom du rôle pour Master RAM Role .

4. Dans la console RAM, cliquez sur Permissions > Policies dans le volet de navigation de gauche. Trouvez la stratégie personnalisée qui commence par k8sMasterRolePolicy-Ccm- et cliquez sur le nom de la stratégie.

   Pour les clusters plus anciens, cette stratégie peut ne pas exister. Sélectionnez plutôt une stratégie personnalisée dont le nom commence par k8sMasterRolePolicy- .

5. Cliquez sur Edit Policy Document et ajoutez l'autorisation nlb:ListAsynJobs aux autorisations NLB. Pour les clusters Flannel, ajoutez également les autorisations vpc:CreateRouteEntries et vpc:DeleteRouteEntries aux autorisations VPC.

   "nlb:ListServerGroupServers",
           "nlb:GetJobStatus",
           "nlb:LoadBalancerLeaveSecurityGroup",
           "nlb:LoadBalancerJoinSecurityGroup",
           "nlb:ListAsynJobs"
         ],
         "Resource": "*",
         "Effect": "Allow"
       },

   },
   {
     "Action": [
       "vpc:Describe*",
       "vpc:DeleteRouteEntry",
       "vpc:CreateRouteEntry",
       "vpc:CreateRouteEntries",
       "vpc:DeleteRouteEntries"
     ],
     "Resource": "*",
     "Effect": "Allow"
   }
   ]
   }

6. Soumettez les modifications et procédez à la mise à niveau du CCM.