Container Service for Kubernetes:Perform canary releases with ALB Ingresses in an ACK cluster

Prérequis

Effectuez les opérations suivantes :

• Deux vSwitch dans différentes zones au sein du même VPC que le cluster ACK. Consultez Créer et gérer un vSwitch.

• Contrôleur Ingress ALB installé dans le cluster. Consultez Gérer le contrôleur Ingress ALB.

  Pour les clusters dédiés ACK, accordez au cluster les permissions nécessaires pour accéder à Ingress ALB. Consultez Autoriser un cluster dédié ACK à accéder au contrôleur Ingress ALB .

• AlbConfig créé. Consultez Créer un AlbConfig.

• kubectl connecté au cluster ACK. Consultez Obtenir le fichier kubeconfig d'un cluster et utiliser kubectl pour se connecter au cluster.

Annotations canaries

Chaque Ingress canari nécessite l'annotation alb.ingress.kubernetes.io/canary: "true". Sans celle-ci, l'Ingress canari entre en conflit avec la production au lieu de router le trafic conjointement.

Ces annotations contrôlent la répartition du trafic :

Priorité des règles : basé sur l'en-tête > basé sur le cookie > basé sur le poids.

Notes d'utilisation

• Les règles basées sur les en-têtes et les cookies ne peuvent pas partager un Ingress avec des règles basées sur le poids. Utilisez des Ingress distincts ou règles de routage personnalisées pour des conditions complexes.

• L'hôte de l'Ingress canari doit correspondre exactement à l'hôte de l'Ingress de production.

• Définissez explicitement la priorité avec alb.ingress.kubernetes.io/order lorsque plusieurs Ingress canaris partagent un hôte, plutôt que de compter sur l'ordre lexicographique.

Étape 1 : Déployer le Service de production

Déployez le Deployment, le Service et l'Ingress de production.

1. Créez tea-deploy.yaml et appliquez-le :

   apiVersion: apps/v1
   kind: Deployment
   metadata:
     name: tea
   spec:
     replicas: 1
     selector:
       matchLabels:
         app: tea
     template:
       metadata:
         labels:
           app: tea
       spec:
         containers:
         - name: tea
           image: registry.cn-hangzhou.aliyuncs.com/acs-sample/old-nginx:latest
           ports:
           - containerPort: 80

   kubectl apply -f tea-deploy.yaml

2. Créez tea-svc.yaml et appliquez-le :

   apiVersion: v1
   kind: Service
   metadata:
     name: tea-svc
   spec:
     ports:
     - port: 80
       targetPort: 80
       protocol: TCP
     selector:
       app: tea
     type: NodePort

   kubectl apply -f tea-svc.yaml

3. Créez tea-ingress.yaml et appliquez-le :

   apiVersion: networking.k8s.io/v1
   kind: Ingress
   metadata:
     name: tea-ingress
   spec:
     ingressClassName: alb
     rules:
      - host: demo.domain.ingress.top  # Replace with your domain name, resolved to the load balancer IP.
        http:
         paths:
         - path: /
           pathType: Prefix
           backend:
             service:
               name: tea-svc
               port:
                 number: 80

   kubectl apply -f tea-ingress.yaml

Étape 2 : Déployer le Service canari et les règles de routage

Déployez le Service canari avec deux Ingress canaris : l'un route par en-tête, l'autre répartit le trafic restant par poids.

Avant d'appliquer les Ingress canaris :

• Définissez alb.ingress.kubernetes.io/canary: "true" sur chaque Ingress canari. Sans cela, l'Ingress canari entre en conflit avec la production.

• Le champ host doit correspondre exactement à l'hôte de l'Ingress de production (demo.domain.ingress.top dans cet exemple).

• Les règles basées sur les en-têtes et celles basées sur le poids doivent figurer sur des Ingress distincts.

1. Créez canary-deploy.yaml et appliquez-le :

   apiVersion: apps/v1
   kind: Deployment
   metadata:
     name: canary
   spec:
     replicas: 1
     selector:
       matchLabels:
         app: canary
     template:
       metadata:
         labels:
           app: canary
       spec:
         containers:
         - name: canary
           image: registry.cn-hangzhou.aliyuncs.com/acs-sample/new-nginx:latest
           ports:
           - containerPort: 80

   kubectl apply -f canary-deploy.yaml

2. Créez canary-svc.yaml et appliquez-le :

   apiVersion: v1
   kind: Service
   metadata:
     name: canary-svc
   spec:
     ports:
     - port: 80
       targetPort: 80
       protocol: TCP
     selector:
       app: canary
     type: NodePort

   kubectl apply -f canary-svc.yaml

3. Créez un Ingress canari basé sur l'en-tête. Les requêtes contenant location: hz sont acheminées vers canary-svc ; les autres en-têtes passent à la règle suivante. Créez canary-header-ingress.yaml et appliquez-le :

   apiVersion: networking.k8s.io/v1
   kind: Ingress
   metadata:
     annotations:
       alb.ingress.kubernetes.io/canary: "true"
       alb.ingress.kubernetes.io/canary-by-header: "location"
       alb.ingress.kubernetes.io/canary-by-header-value: "hz"
     name: canary-header-ingress
     namespace: default
   spec:
     ingressClassName: alb
     rules:
       - host: demo.domain.ingress.top  # Must match the production Ingress host exactly.
         http:
           paths:
             - backend:
                 service:
                   name: canary-svc
                   port:
                     number: 80
               path: /
               pathType: Prefix

   kubectl apply -f canary-header-ingress.yaml

4. Créez un Ingress canari basé sur le poids. Les requêtes ne correspondant pas sont réparties à 50/50 entre les Services de production et canari. Créez canary-weight-ingress.yaml et appliquez-le :

   apiVersion: networking.k8s.io/v1
   kind: Ingress
   metadata:
     annotations:
       alb.ingress.kubernetes.io/canary: "true"
       alb.ingress.kubernetes.io/canary-weight: "50"
     name: canary-weight-ingress
     namespace: default
   spec:
     ingressClassName: alb
     rules:
       - host: demo.domain.ingress.top  # Must match the production Ingress host exactly.
         http:
           paths:
             - backend:
                 service:
                   name: canary-svc
                   port:
                     number: 80
               path: /
               pathType: Prefix

   kubectl apply -f canary-weight-ingress.yaml

Vérifier le déploiement canari

1. Obtenez l'adresse de l'instance ALB :

   kubectl get ing

   Résultat attendu :

   NAME                    CLASS   HOSTS                     ADDRESS                                              PORTS   AGE
   canary-header-ingress   alb     demo.domain.ingress.top   alb-ny3ute4r8yevni****.cn-chengdu.alb.aliyuncs.com   80      8m23s
   canary-weight-ingress   alb     demo.domain.ingress.top   alb-ny3ute4r8yevni****.cn-chengdu.alb.aliyuncs.com   80      8m16s
   tea-ingress             alb     demo.domain.ingress.top   alb-ny3ute4r8yevni****.cn-chengdu.alb.aliyuncs.com   80      7m5s

2. Vérifiez que les requêtes portant location: hz atteignent toujours le canari :

   for i in $(seq 1 10); do curl -s -H "Host:demo.domain.ingress.top" -H "location:hz" http://alb-ny3ute4r8yevni****.cn-chengdu.alb.aliyuncs.com; done

   Les 10 réponses retournent new. La règle d'en-tête possède la priorité la plus élevée et achemine toutes les requêtes correspondantes vers le canari.

3. Vérifiez que les requêtes sans en-tête correspondant sont réparties environ à 50/50 :

   for i in $(seq 1 10); do curl -s -H "Host:demo.domain.ingress.top" http://alb-ny3ute4r8yevni****.cn-chengdu.alb.aliyuncs.com; done

   Les réponses alternent entre new (canari) et old (production), soit environ la moitié pour chacune. Les en-têtes non correspondants (par exemple, location: bj) suivent la même répartition basée sur le poids.

Étape 3 : Promouvoir la nouvelle version

Une fois le canari stabilisé, redirigez tout le trafic de production vers le nouveau Service et supprimez les Ingress canaris.

1. Mettez à jour tea-ingress.yaml pour pointer vers canary-svc :

   apiVersion: networking.k8s.io/v1
   kind: Ingress
   metadata:
     name: tea-ingress
   spec:
     ingressClassName: alb
     rules:
      - host: demo.domain.ingress.top
        http:
         paths:
         - path: /
           pathType: Prefix
           backend:
             service:
               name: canary-svc  # Changed from tea-svc.
               port:
                 number: 80

   kubectl apply -f tea-ingress.yaml

2. Supprimez les Ingress canaris :

   kubectl delete ing canary-weight-ingress canary-header-ingress

3. Vérifiez que tout le trafic atteint la nouvelle version :

   for i in $(seq 1 10); do curl -s -H "Host:demo.domain.ingress.top" http://alb-ny3ute4r8yevni****.cn-chengdu.alb.aliyuncs.com; done

   Les 10 réponses retournent new. L'ancienne version du Service est entièrement obsolète.

Étapes suivantes

• Consultez Configurations avancées des Ingress ALB pour les redirections HTTP vers HTTPS, les règles de routage personnalisées, etc.

• Consultez FAQ sur les Ingress pour le dépannage.