Container Service for Kubernetes:Dépannage des problèmes de service

Répartition de charge inégale entre les backends CLB

Cause : L'algorithme de planification CLB n'est pas adapté au modèle de trafic.

Symptôme : Distribution inégale des requêtes sur les serveurs backend.

Solution :

• Pour les services avec externalTrafficPolicy: Local, ajoutez l'annotation service.beta.kubernetes.io/alibaba-cloud-loadbalancer-scheduler:"wrr" pour utiliser la planification par tourniquet pondéré (weighted round-robin).

• Pour les services utilisant des connexions persistantes, ajoutez l'annotation service.beta.kubernetes.io/alibaba-cloud-loadbalancer-scheduler:"wlc" pour la planification par moindre connexion pondérée (weighted least connections). Cela empêche une connexion longue durée de monopoliser le trafic.

Erreur 503 lors des mises à jour d'applications

Cause : La vidange de connexion (connection draining) ou l'arrêt gracieux des pods n'est pas configuré. Lors des mises à jour progressives, CLB peut router le trafic vers des pods en cours de terminaison.

Symptôme : Erreur 503 lors de l'accès au CLB pendant une mise à jour d'application.

Solution :

1. Ajoutez l'annotation service.beta.kubernetes.io/alibaba-cloud-loadbalancer-connection-drain pour activer la vidange de connexion. Consultez la rubrique Opérations courantes de gestion des écouteurs.

2. Configurez readinessProbe et preStop sur le pod :

   • readinessProbe : Les pods rejoignent les backends CLB uniquement après avoir réussi la sonde. Définissez la fréquence de la sonde, le délai initial et le seuil d'échec en fonction du temps de démarrage de votre application. Des délais trop courts provoquent des redémarrages répétés des pods.

   • preStop et terminationGracePeriodSeconds : Définissez preStop sur la durée nécessaire à votre application pour traiter les requêtes en cours. Définissez terminationGracePeriodSeconds sur une valeur d'au moins 30 secondes supérieure à preStop.

   apiVersion: v1
   kind: Pod
   metadata:
     name: nginx
     namespace: default
   spec:
     containers:
     - name: nginx
       image: nginx
       # Liveness probe
       livenessProbe:
         failureThreshold: 3
         initialDelaySeconds: 30
         periodSeconds: 30
         successThreshold: 1
         tcpSocket:
           port: 5084
         timeoutSeconds: 1
       # Readiness probe
       readinessProbe:
         failureThreshold: 3
         initialDelaySeconds: 30
         periodSeconds: 30
         successThreshold: 1
         tcpSocket:
           port: 5084
         timeoutSeconds: 1
       # Graceful termination
       lifecycle:
         preStop:
           exec:
             command:
             - sleep
             - 30
     terminationGracePeriodSeconds: 60

CLB inaccessible depuis l'intérieur du cluster

Cause : externalTrafficPolicy: Local est défini sur le service. kube-proxy transfère uniquement le trafic vers les pods situés sur le même nœud que l'origine de la requête. Si le nœud ne possède aucun pod backend pour le service, la connexion échoue. Cela affecte le trafic intra-cluster routé vers l'adresse CLB. Consultez kube-proxy adds external-lb address to node-local iptables rule.

Symptôme : Le CLB est accessible depuis l'extérieur du cluster, mais les connexions échouent depuis l'intérieur.

Solution : Utilisez l'une des approches suivantes :

• Accès via ClusterIP ou nom de service (recommandé pour l'accès intra-cluster) : Utilisez le ClusterIP ou le nom DNS du service au lieu de l'adresse CLB. Pour Ingress, le nom du service est nginx-ingress-lb.kube-system.

• Passer à externalTrafficPolicy: Cluster : Le trafic intra-cluster atteint le service quel que soit l'emplacement des pods, mais l'IP source du client n'est pas conservée. Pour modifier le service Ingress :

  Avec un CLB Ingress, les pods ne peuvent accéder aux services exposés via Ingress/CLB qu'à partir du nœud exécutant le pod Ingress.

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

• Utiliser externalTrafficPolicy: Cluster avec le pass-through ENI (Terway uniquement) : Si votre cluster utilise Terway avec des ENI ou plusieurs IPs par ENI, définissez externalTrafficPolicy: Cluster et ajoutez l'annotation service.beta.kubernetes.io/backend-type: "eni". Cela conserve l'IP source et permet l'accès intra-cluster. Consultez la rubrique Utilisation d'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

CLB inaccessible depuis l'extérieur du cluster

Cause : Une liste de contrôle d'accès (ACL) bloque l'IP du client, le groupe vServer du CLB ne possède aucun backend, ou la vérification d'état (health check) échoue.

Symptôme : L'instance CLB est inaccessible depuis l'extérieur du cluster.

Solution :

1. Vérifiez la présence d'événements d'erreur de service et résolvez-les. Consultez la section Événements d'erreur de service et solutions.

   kubectl -n {your-namespace} describe svc {your-svc-name}

2. Vérifiez si une ACL est configurée sur l'instance CLB. Le cas échéant, assurez-vous qu'elle autorise le trafic entrant depuis l'IP du client. Consultez la rubrique Gestion des accès aux ressources (RAM).

3. Vérifiez si le groupe vServer du CLB est vide. S'il l'est, assurez-vous qu'un pod est associé au service et qu'il est en cours d'exécution. S'il est indisponible, résolvez d'abord le problème du pod. Consultez la rubrique Dépannage des problèmes de pod.

4. Vérifiez si la vérification d'état de l'écouteur CLB réussit. En cas d'échec, assurez-vous que le pod répond correctement. Consultez la FAQ sur la vérification d'état CLB.

Impossible de se connecter au service HTTPS backend

Cause : Avec un certificat sur l'écouteur CLB, CLB termine le TLS et transmet le HTTP aux backends. Si targetPort pointe vers un port HTTPS (par exemple, 443), le pod rejette la requête en texte clair avec l'erreur « The plain HTTP request was sent to HTTPS port ».

Symptôme : Les connexions backend échouent après la configuration du HTTPS sur l'écouteur CLB.

Solution : Définissez targetPort sur le port HTTP du pod. Par exemple, si Nginx sert le HTTPS sur le port 443, définissez targetPort sur 80.

apiVersion: v1
kind: Service
metadata:
  annotations:
    service.beta.kubernetes.io/alibaba-cloud-loadbalancer-protocol-port: "https:443"
    service.beta.kubernetes.io/alibaba-cloud-loadbalancer-cert-id: "${YOUR_CERT_ID}"
  name: nginx
  namespace: default
spec:
  ports:
  - name: http
    port: 80
    protocol: TCP
    targetPort: 80
  - name: https
    port: 443
    protocol: TCP
    targetPort: 80
  selector:
    run: nginx
  type: LoadBalancer