Configure an end-to-end canary release based on an ALB gateway - Microservices Engine: Central de Documentação do Alibaba Cloud

Uma liberação canário padrão abrange apenas um serviço por vez. Quando uma versão canário de um serviço upstream chama um serviço downstream, a solicitação retorna à versão base do serviço downstream, o que pode causar incompatibilidade. A liberação canário de ponta a ponta resolve esse problema ao rotear o tráfego tagueado pelas versões canário de todos os serviços na cadeia de chamadas, mesmo quando alguns serviços não possuem implantação canário. O Microservices Engine (MSE) propaga automaticamente o contexto canário entre as chamadas de serviço a serviço. Combinado com o Application Load Balancer (ALB) Ingress para divisão de tráfego no gateway, esse recurso oferece liberação canário de ponta a ponta sem exigir alterações no código da sua aplicação.

Como funciona

O ALB Ingress divide o tráfego de entrada por nome de domínio e envia o tráfego canário para a versão canário do primeiro serviço. Em seguida, o MSE propaga a tag canário por cada chamada subsequente, garantindo que todo serviço downstream roteie a solicitação para sua própria versão canário.

Fluxo de chamadas neste exemplo:

Client request --> ALB Ingress gateway --> Application A --> Application B --> Application C

Solicitações para www.aliyundoc.com são direcionadas ao ambiente base (versões estáveis de todas as aplicações).
Solicitações para www.example.com são direcionadas ao ambiente canário (versões canário de todas as aplicações).

Implementation process

O MSE organiza a liberação canário de ponta a ponta com base em dois conceitos:

Grupo de lanes: conjunto de aplicações que participam de uma cadeia de chamadas.
Lane: ambiente de isolamento de tráfego (como "canário") dentro de um grupo de lanes. Cada lane é identificada por uma tag, por exemplo gray.

Cenário de exemplo

Arquitetura da aplicação neste exemplo:

Gateway ALB Ingress: divide o tráfego na camada de ingresso.
Três aplicações Spring Cloud: centro de transações (Aplicação A), centro de commodities (Aplicação B) e centro de inventário (Aplicação C).
Nacos: gerencia a descoberta de serviços entre as aplicações.
Métodos de acesso: via cliente ou HTML.

A Aplicação A pode ser uma aplicação Spring Boot. A ordem das chamadas é: Gateway ALB Ingress > Aplicação A > Aplicação B > Aplicação C.

O roteamento baseado em domínio separa o ambiente base do ambiente canário:

Domínio	Ambiente
`www.aliyundoc.com`	Base (versões estáveis)
`www.example.com`	Canário (novas versões)

Scenario architecture

Observações de uso

Se o cluster utilizar o plug-in de rede Flannel, os serviços de backend do gateway ALB Ingress deverão ser do tipo NodePort ou LoadBalancer.
O vSwitch do gateway ALB Ingress deve estar na mesma Virtual Private Cloud (VPC) do cluster Container Service for Kubernetes (ACK). Para verificar as regiões suportadas, consulte Regiões e zonas suportadas.

Pré-requisitos

Antes de começar, verifique se você tem:

Um cluster ACK executando Kubernetes V1.18 ou posterior. Consulte Criar um cluster gerenciado ACK ou Criar um cluster dedicado ACK (descontinuado).
kubectl conectado ao cluster ACK. Consulte Obter kubeconfig do cluster e conectar usando kubectl.
O componente ALB Ingress Controller instalado no cluster. Instale-o durante a criação do cluster selecionando ALB Ingress para Ingress na etapa Component Configuration ou instale-o posteriormente na página Add-ons. Consulte Gerenciar componentes.
Microservices Governance Professional Edition ativado na página Microservice Governance. Consulte Visão geral de faturamento do Microservices Governance.
MSE Microservices Governance habilitado para as aplicações no cluster ACK. Consulte Habilitar Microservices Governance para aplicações de microsserviços Java em um cluster ACK ou ACS.

Habilitar o MSE Microservices Governance

Ative o Microservices Governance no nível de namespace ou para uma única aplicação.

Opção 1: Habilitar por namespace

Faça login no console do MSE e selecione uma região na barra de navegação superior.
No painel de navegação à esquerda, escolha Microservices Governance > Application Governance.
Na página Application list, clique em ACK Application Access.
Na caixa de diálogo ACK Application Access, defina os parâmetros a seguir e clique em OK.

ACK namespace access dialog

Parâmetro	Descrição
Cluster type	Selecione ACK Cluster, ACK Serverless Cluster ou ACS Cluster. Se você ainda não autorizou o ACK a chamar o MSE, clique em Please Authorize.
Cluster Name/ID	Selecione o cluster desejado. Use a busca por palavra-chave, se necessário.
ack-onepilot	Exibe o status da instalação. Se não estiver instalado, o sistema fará a instalação automaticamente ao selecionar o cluster. Ao usar um usuário Resource Access Management (RAM) sem as permissões necessárias, acesse o console do ACK, abra os detalhes do cluster, clique em Add-ons, localize ack-onepilot e clique em Install. Consulte Componente ack-onepilot e Instalar e atualizar o componente de governança de microsserviços do MSE.
Access Type	Selecione Namespace Access.
Cluster Namespace	Selecione o namespace de destino.
Microservices Governance Namespace	Selecione um namespace de governança.

Nota

Após a instalação do ack-onepilot, um agente é injetado automaticamente, o que pode aumentar o tempo de inicialização da aplicação em até 10 segundos.

Nota

Se o cluster não estiver em uma destas regiões (Qingdao, Hangzhou, Pequim, Xangai, Shanghai-Finance Cloud, Shenzhen, Hong Kong (China), Singapura, Frankfurt, Sydney, Vale do Silício ou Virgínia), garanta que ele tenha acesso à Internet e possa se conectar a acm.aliyun.com:8080.

Opção 2: Habilitar para uma única aplicação

Faça login no console do MSE e selecione uma região na barra de navegação superior.
No painel de navegação à esquerda, escolha Microservices Governance > Application Governance.
Na página Application list, clique em ACK Application Access.
Na caixa de diálogo ACK Application Access, defina os parâmetros a seguir e clique em OK.

Single application access dialog

Parâmetro	Descrição
Cluster type	Selecione ACK Cluster, ACK Serverless Cluster ou ACS Cluster. Se você ainda não autorizou o ACK a chamar o MSE, clique em Please Authorize.
Cluster Name/ID	Selecione o cluster desejado. Use a busca por palavra-chave, se necessário.
ack-onepilot	Exibe o status da instalação. Consulte a Opção 1 acima para mais detalhes.
Access Type	Selecione Single Application Access.
Access Procedure	Siga estas etapas: 1. Acesse Workloads > Deployments no console do ACK e mude para o namespace da aplicação. 2. Localize a aplicação de destino e clique em View In YAML. 3. Adicione os rótulos abaixo e clique em Update.

spec:
  template:
    metadata:
      labels:
        # Set to "on" to enable MSE governance. The value must be enclosed in double quotation marks.
        msePilotAutoEnable: "on"
        # Specify the governance namespace. If the namespace does not exist, it is created automatically.
        mseNamespace: default
        # Specify the application name for MSE. The name must be enclosed in double quotation marks.
        msePilotCreateAppName: "your-deployment-name"

Etapa 1: Implantar as aplicações de demonstração

Implante as versões base e canário das Aplicações A, B e C, além de um servidor Nacos para descoberta de serviços. Cada aplicação possui duas implantações: uma versão base e uma versão canário tagueada com alicloud.service.tag: gray.

Faça login no console do ACK. No painel de navegação à esquerda, clique em Clusters.
Na página Clusters, localize seu cluster e clique no nome dele. No painel de navegação à esquerda, escolha Workloads > Deployments.
Selecione um namespace e clique em Create from YAML. Copie o conteúdo YAML a seguir e clique em Create.

# Base version of Application A (transaction center)
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: spring-cloud-a
spec:
  replicas: 2
  selector:
    matchLabels:
      app: spring-cloud-a
  template:
    metadata:
      labels:
        msePilotCreateAppName: spring-cloud-a
        app: spring-cloud-a
    spec:
      containers:
      - env:
        - name: JAVA_HOME
          value: /usr/lib/jvm/java-1.8-openjdk/jre
        image: registry.cn-hangzhou.aliyuncs.com/mse-governance-demo/spring-cloud-a:3.0.1
        imagePullPolicy: Always
        name: spring-cloud-a
        ports:
        - containerPort: 20001
        livenessProbe:
          tcpSocket:
            port: 20001
          initialDelaySeconds: 10
          periodSeconds: 30

# Canary version of Application A
# "alicloud.service.tag: gray" identifies this deployment as a canary version.
# MSE uses this label to route canary-tagged traffic to these pods.
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: spring-cloud-a-new
spec:
  replicas: 2
  selector:
    matchLabels:
      app: spring-cloud-a-new
  strategy:
  template:
    metadata:
      labels:
        # This label tells MSE that the pod belongs to the "gray" (canary) lane.
        alicloud.service.tag: gray
        msePilotCreateAppName: spring-cloud-a
        app: spring-cloud-a-new
    spec:
      containers:
      - env:
        - name: JAVA_HOME
          value: /usr/lib/jvm/java-1.8-openjdk/jre
        # Enables canary context propagation across downstream calls.
        - name: profiler.micro.service.tag.trace.enable
          value: "true"
        image: registry.cn-hangzhou.aliyuncs.com/mse-governance-demo/spring-cloud-a:3.0.1
        imagePullPolicy: Always
        name: spring-cloud-a-new
        ports:
        - containerPort: 20001
        livenessProbe:
          tcpSocket:
            port: 20001
          initialDelaySeconds: 10
          periodSeconds: 30

# Base version of Application B (commodity center)
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: spring-cloud-b
spec:
  replicas: 2
  selector:
    matchLabels:
      app: spring-cloud-b
  strategy:
  template:
    metadata:
      labels:
        msePilotCreateAppName: spring-cloud-b
        app: spring-cloud-b
    spec:
      containers:
      - env:
        - name: JAVA_HOME
          value: /usr/lib/jvm/java-1.8-openjdk/jre
        image: registry.cn-hangzhou.aliyuncs.com/mse-governance-demo/spring-cloud-b:3.0.1
        imagePullPolicy: Always
        name: spring-cloud-b
        ports:
        - containerPort: 8080
        livenessProbe:
          tcpSocket:
            port: 20002
          initialDelaySeconds: 10
          periodSeconds: 30

# Canary version of Application B
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: spring-cloud-b-new
spec:
  replicas: 2
  selector:
    matchLabels:
      app: spring-cloud-b-new
  template:
    metadata:
      labels:
        alicloud.service.tag: gray
        msePilotCreateAppName: spring-cloud-b
        app: spring-cloud-b-new
    spec:
      containers:
      - env:
        - name: JAVA_HOME
          value: /usr/lib/jvm/java-1.8-openjdk/jre
        image: registry.cn-hangzhou.aliyuncs.com/mse-governance-demo/spring-cloud-b:3.0.1
        imagePullPolicy: Always
        name: spring-cloud-b-new
        ports:
        - containerPort: 8080
        livenessProbe:
          tcpSocket:
            port: 20002
          initialDelaySeconds: 10
          periodSeconds: 30

# Base version of Application C (inventory center)
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: spring-cloud-c
spec:
  replicas: 2
  selector:
    matchLabels:
      app: spring-cloud-c
  template:
    metadata:
      labels:
        msePilotCreateAppName: spring-cloud-c
        app: spring-cloud-c
    spec:
      containers:
      - env:
        - name: JAVA_HOME
          value: /usr/lib/jvm/java-1.8-openjdk/jre
        image: registry.cn-hangzhou.aliyuncs.com/mse-governance-demo/spring-cloud-c:3.0.1
        imagePullPolicy: Always
        name: spring-cloud-c
        ports:
        - containerPort: 8080
        livenessProbe:
          tcpSocket:
            port: 20003
          initialDelaySeconds: 10
          periodSeconds: 30

# Canary version of Application C
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: spring-cloud-c-new
spec:
  replicas: 2
  selector:
    matchLabels:
      app: spring-cloud-c-new
  template:
    metadata:
      labels:
        alicloud.service.tag: gray
        msePilotCreateAppName: spring-cloud-c
        app: spring-cloud-c-new
    spec:
      containers:
      - env:
        - name: JAVA_HOME
          value: /usr/lib/jvm/java-1.8-openjdk/jre
        image: registry.cn-hangzhou.aliyuncs.com/mse-governance-demo/spring-cloud-c:3.0.1
        imagePullPolicy: IfNotPresent
        name: spring-cloud-c-new
        ports:
        - containerPort: 8080
        livenessProbe:
          tcpSocket:
            port: 20003
          initialDelaySeconds: 10
          periodSeconds: 30

# Nacos server for service discovery
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nacos-server
spec:
  replicas: 1
  selector:
    matchLabels:
      app: nacos-server
  template:
    metadata:
      labels:
        app: nacos-server
    spec:
      containers:
      - env:
        - name: MODE
          value: standalone
        image: registry.cn-hangzhou.aliyuncs.com/mse-governance-demo/nacos-server:v2.1.2
        imagePullPolicy: Always
        name: nacos-server
      dnsPolicy: ClusterFirst
      restartPolicy: Always

# Nacos server service
---
apiVersion: v1
kind: Service
metadata:
  name: nacos-server
spec:
  ports:
  - port: 8848
    protocol: TCP
    targetPort: 8848
  selector:
    app: nacos-server
  type: ClusterIP

Definir configurações de rede

Crie dois Serviços Kubernetes para a Aplicação A: um para a versão base e outro para a versão canário. O ALB Ingress roteará o tráfego para esses Serviços com base nos nomes de domínio.

# Service for the base version of Application A
apiVersion: v1
kind: Service
metadata:
  name: spring-cloud-a-base
spec:
  ports:
    - name: http
      nodePort: 32605
      port: 20001
      protocol: TCP
      targetPort: 20001
  selector:
    app: spring-cloud-a
  sessionAffinity: None
  type: NodePort

---
# Service for the canary version of Application A
apiVersion: v1
kind: Service
metadata:
  name: spring-cloud-a-gray
spec:
  ports:
    - name: http
      nodePort: 31622
      port: 20001
      protocol: TCP
      targetPort: 20001
  selector:
    app: spring-cloud-a-new
  sessionAffinity: None
  type: NodePort

Etapa 2: Configurar o roteamento do ALB Ingress

Crie um objeto AlbConfig. Consulte Criar um objeto AlbConfig.

Importante
O vSwitch do gateway ALB Ingress deve estar na mesma VPC do cluster. Caso contrário, sua operação será impactada negativamente.

Crie um recurso Ingress. Salve o YAML a seguir como gray-ingress.yaml.

Para clusters executando Kubernetes anterior à V1.19:

apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  name: demo
  namespace: default
spec:
  ingressClassName: alb
  rules:
    - host: www.aliyundoc.com
      http:
        paths:
          - path: /a
            backend:
              serviceName: spring-clud-a-base
              servicePort: 20001
    - host: www.example.com
      http:
        paths:
          - backend:
              serviceName: spring-cloud-a-gray
              servicePort: 20001
            path: /a
            pathType: ImplementationSpecific

Para clusters executando Kubernetes V1.19 ou posterior:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: cafe-ingress
spec:
  ingressClassName: alb
  rules:
   - host: www.aliyundoc.com
     http:
      paths:
      - path: /a
        pathType: ImplementationSpecific
        backend:
          service:
            name: spring-clud-a-base
            port:
              number: 20001
   - host: www.example.com
     http:
      paths:
      - path: /a
        pathType: ImplementationSpecific
        backend:
          service:
            name: spring-clud-a-base-gray
            port:
              number: 20001

Aplique o recurso Ingress:
```
kubectl apply -f gray-ingress.yaml
```

kubectl apply output

Se o campo ADDRESS estiver vazio na saída, verifique os eventos na página de detalhes do Ingress e revise os pré-requisitos para solucionar o problema.

Etapa 3: Criar grupo de lanes e lane no console do MSE

Faça login no console do MSE e selecione uma região na barra de navegação superior.
No painel de navegação à esquerda, escolha Microservices Governance > Full link Grayscale.
Clique em Create lane groups and lanes.. Se já existir um grupo de lanes, clique em + para Create Lane Group.
No painel Create Lane Group, adicione as três aplicações (spring-cloud-a, spring-cloud-b e spring-cloud-c) e clique em OK.
Na parte inferior da página Full link Grayscale, clique em Create First Split Lane. No painel Create Lane, selecione a tag gray e clique em OK.

Verificar o resultado

Envie solicitações de teste para confirmar que o tráfego flui corretamente por toda a cadeia de chamadas.

Verificar roteamento do ambiente base:

curl -H"Host:aliyundoc.base.com" http://<alb-endpoint>/a

Saída esperada:

A[172.18.XX.XX] -> B[172.18.XX.XX] -> C[172.18.XX.XX]%

Nenhum nome de aplicação possui o sufixo "gray", o que confirma que os três serviços processaram a solicitação usando suas versões base.

Verificar roteamento do ambiente canário:

curl -H"Host:www.example.com" http://<alb-endpoint>/a

Saída esperada:

Agray[172.18.XX.XX] -> Bgray[172.18.XX.XX] -> Cgray[172.18.XX.XX]%

O sufixo "gray" em cada nome de aplicação confirma que o MSE propagou o contexto canário por toda a cadeia de chamadas (da Aplicação A para B e depois para C). Isso comprova que tanto o roteamento baseado em domínio na camada ALB quanto o roteamento baseado em lanes na camada MSE estão funcionando corretamente.

Nota

Substitua <alb-endpoint> pelo endpoint real do gateway ALB Ingress (por exemplo, alb-828vagckg5omzfy49n.cn-beijing.alb.aliyuncs.com). Encontre esse endpoint na saída do comando kubectl get ingress.