Preparations for implementing end-to-end traffic management with loose mode traffic lanes - Alibaba Cloud Service Mesh: Central de Documentação do Alibaba Cloud

As faixas de tráfego direcionam o tráfego de ponta a ponta por versões específicas de serviços com base nos cabeçalhos das requisições. Quando várias equipes desenvolvem recursos diferentes simultaneamente, essas faixas isolam o fluxo de requisições de cada equipe em toda a cadeia de chamadas e evitam contaminação cruzada entre versões. No modo permissivo, as requisições não correspondidas retornam automaticamente aos serviços de linha de base.

Este tópico aborda as etapas de preparação comuns e específicas para cada cenário. Conclua as etapas aplicáveis ao seu caso e consulte o guia do cenário correspondente.

Etapa	Tarefa	Aplica-se a
1	Crie um gateway Istio	Todos os cenários
2	Implantar serviços de exemplo	Cenário 1 e Cenário 2
3	Configure propagação de cabeçalho baggage	Cenário 3

Pré-requisitos

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

Uma instância do Service Mesh (ASM) da Enterprise Edition ou Ultimate Edition, versão 1.18.2.111 ou posterior. Para criar ou atualizar uma instância, consulte Crie uma instância ASM ou Atualize uma instância ASM
Um cluster adicionado à instância ASM. Consulte Adicionar um cluster a uma instância ASM
Um gateway de entrada ASM chamado ingressgateway. Consulte Crie um gateway de entrada

Etapa 1: Crie um gateway Istio

Crie um gateway Istio chamado ingressgateway no namespace istio-system. Esse gateway escuta na porta 80 para tráfego HTTP e aceita requisições para todos os hosts. Para mais informações, consulte Gerencie gateways Istio.

Salve o YAML abaixo em um arquivo chamado gateway.yaml:

apiVersion: networking.istio.io/v1beta1
kind: Gateway
metadata:
  name: ingressgateway
  namespace: istio-system
spec:
  selector:
    istio: ingressgateway
  servers:
    - port:
        number: 80
        name: http
        protocol: HTTP
      hosts:
        - '*'

Aplique a configuração:
```
kubectl apply -f gateway.yaml
```

Verifique se o gateway foi criado:

kubectl get gateway ingressgateway -n istio-system

Saída esperada:

NAME              AGE
ingressgateway    10s

Etapa 2: Implantar serviços de exemplo

Nota

Esta etapa aplica-se apenas ao Cenário 1 e ao Cenário 2. Se você pretende usar o Cenário 3, pule para a Etapa 3.

Ative injeção automática de proxy sidecar

Ative a injeção automática de proxy sidecar para o namespace default. Consulte Ative injeção automática de proxy sidecar.

Para obter detalhes sobre políticas de injeção, consulte Configure políticas de injeção de proxy sidecar.

Implantar os serviços

Implante três versões dos serviços de exemplo no seu cluster Container Service for Kubernetes (ACK):

kubectl apply -f https://alibabacloudservicemesh.oss-cn-beijing.aliyuncs.com/asm-labs/swimlane/v1/mock-tracing-v1.yaml
kubectl apply -f https://alibabacloudservicemesh.oss-cn-beijing.aliyuncs.com/asm-labs/swimlane/v2/mock-tracing-v2.yaml
kubectl apply -f https://alibabacloudservicemesh.oss-cn-beijing.aliyuncs.com/asm-labs/swimlane/v3/mock-tracing-v3.yaml

Verifique se todos os pods estão em execução:

kubectl get pods -n default

Todos os pods devem exibir o status Running com 2/2 containers prontos (o container da aplicação e o proxy sidecar).

Nota

Os serviços de exemplo para o Cenário 1 e o Cenário 2 são escritos em Golang. O Cenário 3 utiliza serviços baseados em Java porque o mecanismo de propagação de cabeçalho baggage possui requisitos específicos de linguagem. Para mais detalhes, consulte Injecting Auto-instrumentation.

Etapa 3: Configure propagação de cabeçalho baggage

Nota

Esta etapa aplica-se somente ao Cenário 3.

Esta etapa utiliza a capacidade de auto-instrumentação do OpenTelemetry Operator para habilitar a propagação transparente do cabeçalho baggage entre os pods de serviço, sem modificar o código da aplicação.

3a. Implantar o OpenTelemetry Operator

Conecte-se ao cluster Kubernetes adicionado à sua instância ASM e crie o namespace opentelemetry-operator-system:
```
kubectl create namespace opentelemetry-operator-system
```

Instale o OpenTelemetry Operator com Helm. Caso o Helm não esteja instalado, consulte Install Helm.

helm repo add open-telemetry https://open-telemetry.github.io/opentelemetry-helm-charts
helm install  \
    --namespace=opentelemetry-operator-system \
    --version=0.46.0 \
    --set admissionWebhooks.certManager.enabled=false \
    --set admissionWebhooks.certManager.autoGenerateCert=true \
    --set manager.image.repository="registry-cn-hangzhou.ack.aliyuncs.com/acs/opentelemetry-operator" \
    --set manager.image.tag="0.92.1" \
    --set kubeRBACProxy.image.repository="registry-cn-hangzhou.ack.aliyuncs.com/acs/kube-rbac-proxy" \
    --set kubeRBACProxy.image.tag="v0.13.1" \
    --set manager.collectorImage.repository="registry-cn-hangzhou.ack.aliyuncs.com/acs/opentelemetry-collector" \
    --set manager.collectorImage.tag="0.97.0" \
    --set manager.opampBridgeImage.repository="registry-cn-hangzhou.ack.aliyuncs.com/acs/operator-opamp-bridge" \
    --set manager.opampBridgeImage.tag="0.97.0" \
    --set manager.targetAllocatorImage.repository="registry-cn-hangzhou.ack.aliyuncs.com/acs/target-allocator" \
    --set manager.targetAllocatorImage.tag="0.97.0" \
    --set manager.autoInstrumentationImage.java.repository="registry-cn-hangzhou.ack.aliyuncs.com/acs/autoinstrumentation-java" \
    --set manager.autoInstrumentationImage.java.tag="1.32.1" \
    --set manager.autoInstrumentationImage.nodejs.repository="registry-cn-hangzhou.ack.aliyuncs.com/acs/autoinstrumentation-nodejs" \
    --set manager.autoInstrumentationImage.nodejs.tag="0.49.1" \
    --set manager.autoInstrumentationImage.python.repository="registry-cn-hangzhou.ack.aliyuncs.com/acs/autoinstrumentation-python" \
    --set manager.autoInstrumentationImage.python.tag="0.44b0" \
    --set manager.autoInstrumentationImage.dotnet.repository="registry-cn-hangzhou.ack.aliyuncs.com/acs/autoinstrumentation-dotnet" \
    --set manager.autoInstrumentationImage.dotnet.tag="1.2.0" \
    --set manager.autoInstrumentationImage.go.repository="registry-cn-hangzhou.ack.aliyuncs.com/acs/opentelemetry-go-instrumentation" \
    --set manager.autoInstrumentationImage.go.tag="v0.10.1.alpha-2-aliyun" \
    opentelemetry-operator open-telemetry/opentelemetry-operator

Verifique se o Operator está em execução:

kubectl get pod -n opentelemetry-operator-system

Saída esperada:

NAME                                      READY   STATUS    RESTARTS   AGE
opentelemetry-operator-854fb558b5-pvllj   2/2     Running   0          1m

Ambos os containers (2/2) devem estar com o status Running.

3b. Configure auto-instrumentação

O recurso Instrumentation informa ao OpenTelemetry Operator como injetar instrumentação nos pods de serviço. A configuração propagators: [baggage] ativa a propagação do cabeçalho W3C Baggage, da qual as faixas de tráfego dependem para passar o contexto de roteamento entre serviços.

Escolha a configuração adequada ao seu ambiente:

Opção A: OpenTelemetry Collector não implantado

Utilize esta configuração quando precisar apenas da propagação de cabeçalho baggage para faixas de tráfego, sem coletar métricas ou rastros. O amostrador always_off desativa a coleta de rastros, e OTEL_METRICS_EXPORTER: none desabilita a exportação de métricas, impedindo a geração de dados de telemetria.

Salve o YAML a seguir em um arquivo chamado instrumentation.yaml:

apiVersion: opentelemetry.io/v1alpha1
kind: Instrumentation
metadata:
  name: demo-instrumentation
spec:
  env:
  - name: OTEL_METRICS_EXPORTER
    value: none
  propagators:
  - baggage
  sampler:
    argument: "1"
    type: always_off

Opção B: OpenTelemetry Collector implantado

Use esta opção quando houver um OpenTelemetry Collector no cluster e você desejar coletar tanto rastros quanto cabeçalhos baggage. O amostrador parentbased_traceidratio com argumento "1" amostra 100% dos rastros.

Salve o YAML abaixo em um arquivo chamado instrumentation.yaml:

apiVersion: opentelemetry.io/v1alpha1
kind: Instrumentation
metadata:
  name: demo-instrumentation
spec:
  propagators:
    - baggage
  sampler:
    type: parentbased_traceidratio
    argument: "1"

Importante

Se um OpenTelemetry Collector não estiver implantado, a Coleta de Métricas e a Análise de Rastreamento não poderão ser ativadas. Para coletar dados de rastreamento do ASM no Managed Service for OpenTelemetry, consulte Coletar dados de rastreamento do ASM no Managed Service for OpenTelemetry.

Aplique o recurso Instrumentation no namespace default:

kubectl apply -f instrumentation.yaml -n default

Verifique o recurso Instrumentation:

kubectl describe instrumentation demo-instrumentation -n default

A saída deve mostrar os propagadores configurados e as definições do amostrador.

Nota

A etapa de anotação necessária para ativar a auto-instrumentação em pods individuais é abordada no Cenário 3. A implantação de um OpenTelemetry Collector está fora do escopo deste tópico. Para coletar dados de rastreamento do ASM, consulte Coletar dados de rastreamento do ASM no Managed Service for OpenTelemetry.

Próximos passos

Prossiga para o cenário que corresponde ao seu caso de uso:

Cenário	Quando usar	Etapas obrigatórias
Cenário 1: Cabeçalho baggage não propagado pela aplicação	Os serviços não repassam o cabeçalho baggage	Etapa 1, Etapa 2
Cenário 2: Cabeçalho baggage propagado pela aplicação	Os serviços já propagam o cabeçalho baggage no código da aplicação	Etapa 1, Etapa 2
Cenário 3: Propagação transparente de cabeçalho baggage	Propagação automática de baggage sem alterar o código da aplicação	Etapa 1, Etapa 3