Container Service for Kubernetes:Meilleures pratiques pour le contrôleur NGINX Ingress

• Améliorer les performances et la stabilité du contrôleur NGINX Ingress

  • Utiliser un nombre approprié de réplicas et définir des limites de ressources

  • Utiliser des nœuds dédiés pour améliorer les performances et la stabilité de NGINX Ingress

  • Optimiser les performances de NGINX Ingress

  • Configurer HPA pour le contrôleur NGINX Ingress afin d'activer la mise à l'échelle automatique

  • Configurer un hook preStop adapté pour les services backend

• Améliorer l'observabilité du contrôleur NGINX Ingress

• Fonctionnalités avancées du contrôleur NGINX Ingress

  • Utiliser plusieurs contrôleurs NGINX Ingress

  • Accéder au contrôleur NGINX Ingress depuis l'intérieur d'un cluster

  • Utiliser WAF

  • Mettre en œuvre des déploiements blue-green ou des versions canary avec le contrôleur NGINX Ingress

  • Transmettre les requêtes non HTTP via le contrôleur NGINX Ingress

• Références

Nombre approprié de réplicas et limites de ressources

Par défaut, un contrôleur NGINX Ingress installé lors de la création du cluster ou depuis la page Add-ons dispose de deux réplicas. Ajustez ce nombre en fonction de vos besoins métier. Répartissez les pods du contrôleur NGINX Ingress sur différents nœuds pour éviter la contention des ressources et les points de défaillance uniques. Vous pouvez également attribuer des nœuds dédiés pour garantir les performances et la stabilité. Pour plus d'informations, consultez la section Utiliser des nœuds dédiés pour améliorer les performances et la stabilité de NGINX Ingress. Afin d'éviter les interruptions de trafic dues à des événements d'épuisement de la mémoire (OOM), ne définissez pas de limites de ressources pour le contrôleur NGINX Ingress. Si vous devez absolument définir des limites, fixez la limite CPU à au moins 1 000 millicœurs et la limite de mémoire à au moins 2 GiB.

Utiliser des nœuds dédiés

• Pour répondre à des exigences élevées en matière de stabilité, attribuez des nœuds dédiés au contrôleur Ingress afin d'éviter toute contention des ressources. Pour plus d'informations, consultez Déployer un contrôleur NGINX Ingress hautement disponible.

• Dans les scénarios à charge élevée, configurez également le contrôleur Ingress pour qu'il prenne en charge les applications générant un trafic important. Pour plus d'informations, consultez Configurer le contrôleur NGINX Ingress pour les scénarios à charge élevée.

Optimiser les performances de NGINX Ingress

L'optimisation des performances du contrôleur NGINX Ingress repose principalement sur deux axes : le réglage des paramètres système et celui des paramètres NGINX.

• Réglage des paramètres système : les systèmes d'exploitation Alibaba Cloud intègrent des optimisations par défaut pour les paramètres courants. Parmi les autres paramètres système susceptibles de nécessiter un ajustement figurent la taille maximale de la file d'attente système (backlog) et la plage de ports disponibles. Le réglage de ces paramètres permet à NGINX de gérer une forte concurrence et évite les échecs de connexion aux backends dus à l'épuisement des ports.

• Réglage des paramètres NGINX :

  • Ajustez le nombre maximal de connexions par processus worker pour permettre au contrôleur NGINX Ingress de gérer une forte concurrence.

  • Augmentez le délai d'expiration de la connexion : contrairement au comportement par défaut de NGINX, le contrôleur NGINX Ingress utilise des connexions keep-alive pour envoyer des requêtes aux pods backend. Augmentez donc le délai d'expiration de la connexion afin qu'une seule connexion puisse traiter davantage de requêtes, réduisant ainsi la surcharge liée à la création de nouvelles connexions.

  • Définissez le délai d'expiration keep-alive : configurez le délai d'expiration keep-alive des services backend de manière à ce qu'il soit supérieur ou égal au délai d'expiration de la connexion du contrôleur NGINX Ingress, qui est par défaut de 900 s dans les clusters ACK.

Le composant NGINX Ingress inclut des paramètres de réglage par défaut qui offrent des performances optimales dans la plupart des scénarios. Si vous avez des besoins spécifiques, optimisez davantage les paramètres système et NGINX en utilisant les champs pertinents dans la ConfigMap. Pour plus d'informations sur les ConfigMaps, consultez ConfigMaps.

Mise à l'échelle automatique avec HPA

Dans la plupart des cas, le contrôleur NGINX Ingress peut absorber les pics de trafic soudains. Si la capacité par défaut s'avère insuffisante pour vos scénarios à charge élevée, configurez un Horizontal Pod Autoscaler (HPA) pour mettre à l'échelle automatiquement le contrôleur NGINX Ingress. Pour plus d'informations, consultez Utiliser Horizontal Pod Autoscaler (HPA).

Voici un exemple de configuration YAML :

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: nginx-ingress-controller-hpa
  namespace: kube-system
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: nginx-ingress-controller
  minReplicas: 2
  maxReplicas: 5
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 50

Configurer un hook preStop

Lors d'une mise à jour progressive d'un service backend, le contrôleur NGINX Ingress supprime le point de terminaison d'un pod en cours d'arrêt tout en maintenant les connexions pour les requêtes en cours de traitement. Si un pod de service backend s'arrête immédiatement après réception du signal de terminaison, les requêtes en cours peuvent échouer. En raison de problèmes de synchronisation, une partie du nouveau trafic peut encore être acheminée vers le pod arrêté, entraînant une perte de trafic.

Pour éviter toute perte de trafic lors des mises à jour progressives, configurez un hook preStop dans les pods de votre service backend. Ce hook permet au pod de continuer à traiter les requêtes en cours après la suppression de son point de terminaison, évitant ainsi les interruptions de service.

apiVersion: apps/v1
kind: Deployment
spec:
  template:
    spec:
      containers:
      - name: app
        lifecycle:
          # Configure a preStop hook to wait for 30 seconds before exiting.
          # The sleep command must be available in the container.
          preStop:
            exec:
              command:
              - sleep
              - "30"

Log Service et Managed Service for Prometheus

Utiliser plusieurs contrôleurs NGINX Ingress

Vous pouvez avoir besoin de déployer plusieurs contrôleurs NGINX Ingress dans un cluster, par exemple pour isoler le trafic interne du trafic externe. Pour plus d'informations, consultez Déployer plusieurs contrôleurs Ingress pour l'isolation du trafic.

Accès intra-cluster

Dans un cluster, le trafic destiné au point de terminaison externe d'un service LoadBalancer (l'adresse IP publique du contrôleur NGINX Ingress) est généralement intercepté et transféré par iptables ou IPVS. Lorsque externalTrafficPolicy est défini sur Local et qu'aucun pod NGINX Ingress ne s'exécute sur un nœud, des problèmes de connectivité réseau surviennent. Par défaut, le contrôleur NGINX Ingress dans un cluster ACK utilise un service LoadBalancer en mode Local. Par conséquent, vous pouvez rencontrer des problèmes de connectivité lorsque vous accédez à l'adresse Classic Load Balancer (CLB) associée depuis l'intérieur du cluster. Pour l'accès intra-cluster, utilisez l'IP Cluster du service ou le nom de domaine interne (nginx-ingress-lb.kube-system). Évitez également les scénarios où le contrôleur NGINX Ingress tente de s'auto-accesser, ce qui peut entraîner des pannes réseau dues à des problèmes de hairpinning. Pour plus d'informations sur la résolution de ce problème, consultez Impossible d'accéder à l'instance SLB d'un service LoadBalancer depuis l'intérieur d'un cluster Kubernetes.

Utiliser WAF

Déploiements blue-green ou versions canary

Mettez en œuvre une version canary avec le contrôleur NGINX Ingress en utilisant la fonctionnalité disponible dans la console ACK ou en ajoutant manuellement une annotation. Pour plus d'informations, consultez Utiliser NGINX Ingress pour mettre en œuvre des versions canary et des déploiements blue-green.

Transmettre les requêtes non HTTP