Container Service for Kubernetes:Best practices for the NGINX Ingress controller

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

  • Utiliser des réplicas et des limites de ressources appropriés

  • 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 l'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 à l'aide du contrôleur NGINX Ingress

  • Proxyser les requêtes non HTTP à l'aide du contrôleur NGINX Ingress

• Références

Répliques et limites de ressources appropriées

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. Vous pouvez ajuster ce nombre en fonction de vos besoins métier. Assurez-vous que les pods du contrôleur NGINX Ingress sont répartis sur différents nœuds afin d'é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. Pour é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 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 la contention des ressources. Pour plus d'informations, consultez Déployer un contrôleur NGINX Ingress hautement disponible.

• Dans les scénarios à charge élevée, vous pouvez également configurer le contrôleur Ingress pour qu'il prenne en charge les applications à fort trafic. 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 sur deux axes principaux : le réglage des paramètres système et le réglage des paramètres NGINX.

• Réglage des paramètres système : les systèmes d'exploitation Alibaba Cloud incluent des optimisations par défaut pour les paramètres courants. Parmi les autres paramètres système que vous pourriez avoir besoin d'ajuster figurent la taille maximale de la file d'attente système (backlog) et la plage de ports disponibles. Le réglage des paramètres système permet de s'assurer que NGINX peut gérer une concurrence élevée et évite les échecs de connexion aux backends dus à l'épuisement des ports.

• Réglage des paramètres NGINX :

  • L'ajustement du nombre maximal de connexions par processus worker garantit que le contrôleur NGINX Ingress peut gérer une concurrence élevée.

  • 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. Par conséquent, augmentez le délai d'expiration de la connexion afin de permettre à une seule connexion de 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 pour les 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 secondes 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 exigences spécifiques, vous pouvez optimiser davantage les paramètres système et NGINX en utilisant les champs pertinents dans le 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 est 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 de termination 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 termination, les requêtes en cours peuvent échouer. En raison de problèmes de synchronisation, une partie du nouveau trafic pourrait encore être routée vers le pod terminé, entraînant une perte de trafic.

Pour éviter toute perte de trafic lors des mises à jour progressives, configurez un hook preStop dans vos pods de service backend. Ce hook permet au pod de continuer à traiter les requêtes en cours après la suppression de son point de terminaison, empêchant 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 et 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 vers le 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 n'est exécuté 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é lors de l'accès à l'adresse Classic Load Balancer (CLB) associée depuis l'intérieur du cluster. Ainsi, pour l'accès intra-cluster, utilisez le ClusterIP 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-acceder, ce qui peut entraîner des échecs réseau dus à 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

Vous pouvez mettre 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.

Proxyser les requêtes non HTTP