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

Pré-requisitos

Conclua os seguintes itens:

• Dois vSwitches em zonas diferentes na mesma VPC do cluster ACK. Consulte Criar e gerenciar um vSwitch.

• Controlador ALB Ingress instalado no cluster. Consulte Gerencie o controlador ALB Ingress.

  Para clusters dedicados ACK, conceda permissões ao cluster para acessar o ALB Ingress. Consulte Autorizar um cluster dedicado ACK a acessar o controlador ALB Ingress .

• AlbConfig criado. Consulte Crie um AlbConfig.

• kubectl conectado ao cluster ACK. Consulte Obter o arquivo kubeconfig de um cluster e usar kubectl para conectar-se ao cluster.

Anotações canary

Todo Ingress canary requer a anotação alb.ingress.kubernetes.io/canary: "true". Sem ela, o Ingress canary entra em conflito com a produção em vez de rotear o tráfego paralelamente.

As anotações abaixo controlam a divisão de tráfego:

Prioridade das regras: baseada em header > baseada em cookie > baseada em peso.

Observações de uso

• Regras baseadas em header e cookie não podem compartilhar um Ingress com regras baseadas em peso. Use Ingresses separados ou custom routing rules para condições complexas.

• O host do Ingress canary deve corresponder exatamente ao host do Ingress de produção.

• Defina a prioridade explicitamente com alb.ingress.kubernetes.io/order quando múltiplos Ingresses canary compartilharem um host, em vez de depender da ordenação lexicográfica.

Etapa 1: Implantar o Service de produção

Implante o Deployment, o Service e o Ingress de produção.

1. Crie o arquivo tea-deploy.yaml e aplique-o:

   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. Crie o arquivo tea-svc.yaml e aplique-o:

   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. Crie o arquivo tea-ingress.yaml e aplique-o:

   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

Etapa 2: Implantar o Service canary e as regras de roteamento

Implante o Service canary com dois Ingresses canary: um roteia por header e o outro divide o tráfego restante por peso.

Antes de aplicar os Ingresses canary:

• Defina alb.ingress.kubernetes.io/canary: "true" em todo Ingress canary. Sem isso, o Ingress canary entra em conflito com a produção.

• O campo host deve corresponder exatamente ao host do Ingress de produção (demo.domain.ingress.top neste exemplo).

• Regras baseadas em header e baseadas em peso devem estar em Ingresses separados.

1. Crie o arquivo canary-deploy.yaml e aplique-o:

   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. Crie o arquivo canary-svc.yaml e aplique-o:

   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. Crie um Ingress canary baseado em header. Requisições com location: hz são roteadas para canary-svc; outros headers seguem para a próxima regra. Crie o arquivo canary-header-ingress.yaml e aplique-o:

   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. Crie um Ingress canary baseado em peso. Requisições sem correspondência são divididas 50/50 entre os Services de produção e canary. Crie o arquivo canary-weight-ingress.yaml e aplique-o:

   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

Verifique a implantação canary

1. Obtenha o endereço da instância ALB:

   kubectl get ing

   Saída esperada:

   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. Verifique se as requisições com o header location: hz sempre chegam ao canary:

   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

   Todas as 10 respostas retornam new. A regra de header tem a maior prioridade e roteia todas as requisições correspondentes para o canary.

3. Confirme que as requisições sem um header correspondente são divididas aproximadamente 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

   As respostas alternam entre new (canary) e old (produção), aproximadamente metade para cada. Headers sem correspondência (por exemplo, location: bj) seguem a mesma divisão baseada em peso.

Etapa 3: Promover a nova versão

Após a estabilização do canary, redirecione todo o tráfego de produção para o novo Service e exclua os Ingresses canary.

1. Atualize o arquivo tea-ingress.yaml para apontar para 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. Exclua os Ingresses canary:

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

3. Verifique se todo o tráfego chega à nova versão:

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

   Todas as 10 respostas retornam new. A versão antiga do Service foi totalmente descontinuada.

Próximas etapas

• Consulte Advanced ALB Ingress configurations para redirecionamentos de HTTP para HTTPS, regras de roteamento personalizadas e mais.

• Para solução de problemas, consulte Ingress FAQ.