Deploy multiple NGINX Ingress controllers in Alibaba Cloud ACK for traffic isolation - Container Service for Kubernetes

Installez des contrôleurs NGINX Ingress indépendants via Helm aux côtés du contrôleur Add-ons par défaut afin de créer des points d'entrée de trafic dédiés pour différents services ou environnements. Isolez le trafic à l'aide d'instances SLB exposées sur Internet et internes distinctes, ou fournissez différentes configurations et versions de contrôleur pour des applications spécifiques. Cette approche garantit une isolation complète des pannes et des configurations, contrairement à un seul contrôleur partagé.

Important

Les contrôleurs installés via Helm diffèrent du contrôleur Add-ons par défaut :

Fonctionnalités intégrées : Le contrôleur Add-ons inclut des fonctionnalités supplémentaires telles que le déploiement canari, la journalisation et la surveillance, ainsi que l'inspection du cluster.
Responsabilité : Vous gérez le cycle de vie des contrôleurs installés via Helm, y compris les mises à niveau, la configuration et le dépannage.

Fonctionnement

Chaque contrôleur possède un nom IngressClass unique. Définissez le champ spec.ingressClassName dans un Ingress pour cibler un contrôleur spécifique. Seul le contrôleur correspondant applique les règles, ce qui permet d'isoler le trafic.

Exemple : isolation du trafic exposé sur Internet et du trafic interne.

Prérequis

Le cluster doit exécuter la version 1.22 ou ultérieure.

Les versions des composants pour les clusters en version 1.20 ou antérieure ont atteint leur fin de vie ([[Annonce produit] Fin de maintenance du contrôleur NGINX Ingress v1.2 et versions antérieures](t2767923.xdita#)). Mettez à niveau manuellement un cluster ACK si nécessaire.

Déployer un nouveau contrôleur Ingress à l'aide de Helm

Sur la page Clusters ACK, cliquez sur le nom de votre cluster. Dans le volet de navigation de gauche, cliquez sur Applications > Helm.

Cliquez sur Deploy pour installer ack-ingress-nginx-v1.

Configurez les paramètres clés suivants :

Paramètre	Description
Nom de l'application	Le nom doit être unique au sein du cluster. Important Il préfixe le nom du Service : `<Nom de l'application>-ack-ingress-nginx-v1-controller` (exposé sur Internet) ou `<Nom de l'application>-ack-ingress-nginx-v1-controller-internal` (interne). La création échoue si le nom total dépasse 63 caractères.
Chart	Recherchez et sélectionnez ack-ingress-nginx-v1. Le chart ack-ingress-nginx n'est plus maintenu.
Chart Version	Pour les clusters en version 1.24 ou ultérieure : 4.0.22 ou ultérieure. Pour les clusters en version 1.22 : versions de 4.0.16 (inclusive) à 4.0.22 (exclusive).
Paramètres	Par défaut : déploie en tant que Deployment avec 2 réplicas, créant un Service LoadBalancer exposé sur Internet lié à une instance CLB. Ajustez les valeurs par défaut dans les paramètres ack-ingress-nginx-v1. Cet exemple déploie un contrôleur interne. Définissez `controller.service.external.enabled` sur `false` et `controller.service.internal.enabled` sur `true`. Important Assurez-vous que controller.ingressClassResource.name et controller.ingressClassResource.controllerValue sont uniques au sein du cluster.

Sur la page Helm, notez l'espace de noms Namespace (sous Basic Information), ainsi que le nom IngressClass et le nom du Service (sous Resource) pour une utilisation ultérieure.

Vérifier l'isolation du trafic

Ce scénario utilise des contrôleurs distincts pour le trafic exposé sur Internet et le trafic interne afin de vérifier l'isolation :

Contrôleur par défaut : déployé à partir des Add-ons, lié à une instance SLB exposée sur Internet.

Si non configuré, consultez Créer et utiliser un NGINX Ingress pour exposer un service .
Nouveau contrôleur : lié à une instance SLB interne, accessible uniquement au sein du VPC.

Déployez une application exemple et créez une règle Ingress ciblant uniquement le nouveau contrôleur.

Étape 1 : Déployer une application de test

Créez un fichier nginx.yaml.

Exemple : Deployment et Service NGINX.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx
spec:
  replicas: 1
  selector:
    matchLabels:
      run: nginx
  template:
    metadata:
      labels:
        run: nginx
    spec:
      containers:
      - image: anolis-registry.cn-zhangjiakou.cr.aliyuncs.com/openanolis/nginx:1.14.1-8.6
        imagePullPolicy: Always
        name: nginx
        ports:
        - containerPort: 80
          protocol: TCP
      restartPolicy: Always
---
apiVersion: v1
kind: Service
metadata:
  name: nginx
spec:
  ports:
  - port: 80
    protocol: TCP
    targetPort: 80
  selector:
    run: nginx
  sessionAffinity: None
  type: NodePort

Déployez l'application exemple.
```
kubectl apply -f nginx.yaml
```

Étape 2 : Créer et lier une règle Ingress

Créez un fichier ingress.yaml.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: nginx
spec:
  # Change the value to the IngressClass name you configured earlier (controller.ingressClassResource.name).
  ingressClassName: "<YOUR_INGRESS_CLASS>"
  rules:
  # The following domain name is for testing purposes. Replace it with your actual domain name in a production environment.
  - host: foo.bar.com
    http:
      paths:
      - path: /
        backend:
          service: 
            name: nginx
            port:
              number: 80
        pathType: ImplementationSpecific

Créez la règle Ingress.
```
kubectl apply -f ingress.yaml
```

Étape 3 : Tester l'accès

Obtenez les adresses IP SLB de chaque contrôleur.

Adresse IP SLB du contrôleur par défaut exposé sur Internet :

PUBLIC_IP=$(kubectl get svc -n kube-system nginx-ingress-lb -o jsonpath='{.status.loadBalancer.ingress[0].ip}')
echo "Public Ingress IP: $PUBLIC_IP"

Adresse IP SLB du nouveau contrôleur interne :

# Replace <YourNamespace> with the namespace of the new controller (for example, default).
# Replace <YourChartName> with the application name (release name) of the new controller.
INTERNAL_IP=$(kubectl get svc -n <YourNamespace> <YourChartName>-ack-ingress-nginx-v1-controller-internal -o jsonpath='{.status.loadBalancer.ingress[0].ip}')
echo "Internal Ingress IP: $INTERNAL_IP"

Accédez à l'application via le contrôleur interne (succès attendu).

Depuis un terminal au sein du VPC, envoyez une requête. Un code d'état 200 confirme que le contrôleur interne achemine correctement le trafic.
```
# Replace with the actual internal IP address.
curl -o /dev/null -s -w "%{http_code}\n" -H "Host: foo.bar.com" http://$INTERNAL_IP
```
Accédez à l'application via le contrôleur exposé sur Internet (échec attendu).

Envoyez une requête curl. Une réponse 404 Not Found confirme que le contrôleur exposé sur Internet a ignoré la règle Ingress : l'isolation du trafic fonctionne.
```
# Replace with the actual Internet-facing IP address.
curl -H "Host: foo.bar.com" http://$PUBLIC_IP
```

Déploiement en production

Planification des ressources : Configurez ces paramètres pour la haute disponibilité :
- Configurez plusieurs réplicas : controller.replicaCount
- Définissez des demandes et limites de ressources appropriées : controller.resources.requests et controller.resources.limits
- Anti-affinité des Pods : Ajoutez une règle podAntiAffinity sous controller.affinity pour planifier les Pods sur différents nœuds.
Surveillance : Définissez controller.metrics.enabled: true et controller.metrics.serviceMonitor.enabled: true. Intégrez avec Prometheus et surveillez les métriques telles que la latence des requêtes, les taux d'erreur (4xx/5xx), et configurez des règles d'alerte.
Performances : Pour les scénarios à faible latence, utilisez une instance NLB dans la configuration du Service :
- Service interne : controller.service.internal.loadBalancerClass: "alibabacloud.com/nlb"
- Service exposé sur Internet : controller.service.loadBalancerClass: "alibabacloud.com/nlb"
Maintenance des versions :
- Appliquez les correctifs de sécurité selon les notes de version du composant contrôleur NGINX Ingress.
- Pour une isolation renforcée, restreignez l'accès backend par contrôleur avec une Network Policy.

Annexe : Paramètres clés du composant

Paramètre	Description
`controller.image.repository`	Le référentiel d'images du contrôleur NGINX Ingress.
`controller.image.tag`	La version de l'image du contrôleur NGINX Ingress.
`controller.ingressClassResource.name`	Un nom IngressClass unique au sein du cluster. Ne peut pas être `nginx` (réservé au contrôleur par défaut).
`controller.ingressClassResource.controllerValue`	Une valeur de classe de contrôleur unique. Ne peut pas être `k8s.io/ingress-nginx` (réservé au contrôleur par défaut).
`controller.replicaCount`	Le nombre de réplicas de Pod du contrôleur. Définissez sur 2 ou plus pour la haute disponibilité.
`controller.service.enabled`	Indique s'il faut créer un Service LoadBalancer (exposé sur Internet ou interne) pour exposer le contrôleur.
`controller.service.external.enabled`	Si la valeur est `true`, crée un Service SLB exposé sur Internet.
`controller.service.internal.enabled`	Si la valeur est `true`, crée un Service SLB interne (VPC uniquement).
`controller.kind`	Le mode de déploiement du contrôleur Ingress : `Deployment` ou `DaemonSet`.
`controller.electionID`	L'identifiant d'élection du leader parmi les réplicas du contrôleur. Seul le Leader peut mettre à jour le statut de la ressource Ingress. Doit être unique lors du déploiement de plusieurs contrôleurs dans le même espace de noms.
`controller.metrics.enabled`	Si la valeur est `true`, active un point de terminaison de métriques Prometheus.
`controller.metrics.serviceMonitor.enabled`	Si la valeur est `true`, crée un ServiceMonitor pour la découverte automatique Prometheus. Recommandé lorsque `controller.metrics.enabled` est défini sur `true`.
`controller.service.loadBalancerClass`	Le type SLB pour les Services exposés sur Internet. `"alibabacloud.com/clb"` (Par défaut) : Utilise une instance CLB. `"alibabacloud.com/nlb"` : Utilise une instance NLB.
`controller.service.internal.loadBalancerClass`	Le type SLB pour les Services internes. `"alibabacloud.com/clb"` (Par défaut) : Utilise une instance CLB. `"alibabacloud.com/nlb"` : Utilise une instance NLB.