Traffic Management

Na aba TRAFFIC MANAGEMENT você consegue ver e aplicar regras de roteamento de tráfego no âmbito de um serviço. Tais regras permitem definir o critério a ser utilizado para rotear o tráfego das requisições entre diferentes versões implantadas de um mesmo serviço. Para acessá-la, selecione um serviço na listagem da tela Services (ou depois de clicar sobre um mesh na tela Meshes).

Aba "Traffic Management"

É nesta aba que você pode orquestrar o lançamento de versões de um serviço seguindo as configurações de tráfego que você determinar. Isso reduz os riscos associados ao lançamento de uma nova versão, assim como o downtime da sua operação, já que você consegue tanto implementar testes quanto configurar uma troca gradual do tráfego real de uma versão antiga para uma versão nova.

O Sensedia Service Mesh oferece dois tipos de regras de roteamento de tráfego. São eles:

Traffic Routing: Permite redirecionar o tráfego das requisições a outras versões do serviço de acordo com critérios definidos.
Shadow Traffic: Permite um teste específico de uma versão nova. Ao invés de redirecionar uma parte das requisições para serem respondidas pela versão nova, um percentual das requisições já tratadas pelo serviço antigo é roteado para a nova versão, que não responde a essas requisições. Isso permite testar a versão nova com requisições reais, mas sem qualquer impacto no tráfego produtivo do serviço.

Ao longo desta página, você verá como configurar cada um desses tipos de regra de roteamento.

Como o Sensedia Service Mesh é uma aplicação Kubernetes-native, também é possível configurar essas regras pela linha de comando usando kubectl. O quadro "Criando uma regra pela linha de comando" traz um exemplo de arquivo .yaml para fazer isso.

Permissões de acesso

As ações que você poderá realizar nesta tela dependem das permissões definidas para seu usuário no Sensedia Access Control.

A tabela a seguir apresenta as permissões possíveis e as respectivas ações:

Permissão	Descrição
List Traffic Routings	Permite a visualização na lista de regras das informações básicas de uma regra de Traffic Routing criada para um serviço.
List Shadow Traffics	Permite a visualização na lista de regras das informações básicas de uma regra de Shadow Traffic criada para um serviço.
Read Traffic Routings	Permite a visualização da configuração de uma regra de Traffic Routing criada para um serviço. Não possibilita, contudo, a edição da regra.
Read Shadow Traffics	Permite a visualização da configuração de uma regra de Shadow Traffic criada para um serviço. Não possibilita, contudo, a edição da regra.
Write Traffic Routings	Permite a edição, exclusão e a criação de regras de Traffic Routing para os serviços.
Write Shadow Traffics	Permite a edição, exclusão e a criação de regras de Shadow Traffic para os serviços.

Permissão

Descrição

List Traffic Routings

Permite a visualização na lista de regras das informações básicas de uma regra de Traffic Routing criada para um serviço.

List Shadow Traffics

Permite a visualização na lista de regras das informações básicas de uma regra de Shadow Traffic criada para um serviço.

Read Traffic Routings

Permite a visualização da configuração de uma regra de Traffic Routing criada para um serviço. Não possibilita, contudo, a edição da regra.

Read Shadow Traffics

Permite a visualização da configuração de uma regra de Shadow Traffic criada para um serviço. Não possibilita, contudo, a edição da regra.

Write Traffic Routings

Permite a edição, exclusão e a criação de regras de Traffic Routing para os serviços.

Write Shadow Traffics

Permite a edição, exclusão e a criação de regras de Shadow Traffic para os serviços.

Listagem de regras de roteamento

As regras de roteamento criadas estarão visíveis na listagem da aba TRAFFIC MANAGEMENT para o serviço correspondente.

Visualizando as regras de roteamento criadas para um serviço específico

As informações da listagem de regras de roteamento configuradas para o serviço incluem:

o tipo da regra (Traffic Routing ou Shadow Traffic, identificado por um ícone na coluna TYPE);
nome identificador da regra de roteamento (coluna NAME);
tipo da conexão da regra, que pode ser interna (Internal) ou externa (External) (coluna CONNECTION TYPE);
caminho (ou URI) da API que expõe o serviço — ressaltando que o mesmo serviço pode ter mais de uma regra configurada com paths diferentes (coluna PATH);
nome identificador da(-s) versão(-ões) do serviço recebendo o tráfego (coluna DESTINATION);
status da regra — que pode ser "provisionado" (Provisioned), "não-gerenciado" (Unmanaged), "desabilitado" (Disabled) ou com erro (Error) — (coluna STATUS);
data e horário de criação da regra (coluna CREATED AT).

A coluna ENABLED inclui um botão que permite desabilitar ou habilitar a regra.

A coluna ACTIONS contém dois botões que permitem:

editar a configuração da regra;
excluir a regra.

Traffic Routing

A funcionalidade Traffic Routing permite redirecionar o tráfego das requisições para versões diferentes do mesmo microsserviço de acordo com um critério.

Há dois tipos de critério disponíveis para se definir como se dará o redirecionamento do tráfego: por Weight ou por Header.

Traffic Routing por peso (weight): estabelece um critério probabilístico por peso (porcentagem de requisições) para redirecionar o tráfego. Por exemplo: pode-se redirecionar 80% das requisições para a primeira versão de um serviço e as 20% restantes para uma segunda versão desse mesmo serviço.
Traffic Routing por header: valida a presença de metadado na requisição (um header) com nome e valor pré-determinados para redirecionar as requisições para as versões implantadas do serviço.

Para esses dois tipos, é possível redirecionar o tráfego para conexões externas (requisições que vêm de fora do mesh) ou conexões internas (requisições de outros serviços do mesh).

Criando uma regra de Traffic Routing por peso (weight)

Para criar uma nova regra para o serviço selecionado, clique no botão ADD NEW RULE da aba TRAFFIC MANAGEMENT.

Uma janela modal se abrirá para a configuração da regra. Os campos a serem preenchidos variam de acordo com o tipo de conexão do serviço: external no caso de serviços expostos externamente, e internal para serviços expostos somente a outros serviços do mesh.

Serviços internos

No caso de serviços internos, os campos a serem preenchidos são estes:

Type: tipo da regra (escolha a opção Traffic Routing).
Name: nome identificador da regra.

O nome deve ser único para o mesh/namespace do qual o serviço faz parte.
Port: porta que expõe o serviço no Kubernetes.
Enable mTLS: checkbox que deve ser marcada para habilitar conexão com segurança do tipo mTLS.
Connection Type: tipo da conexão do serviço, que pode ser externa ou interna (nesse caso, escolher Internal).
Path: caminho da API que expõe o serviço (opcional).
Split by: campo para definir o tipo de política de roteamento, se por porcentagem de requisições (weight) ou por validação de cabeçalho (header). No caso, escolher Weight.

Campos da seção DESTINATIONS:

Traffic Name: nome identificador da versão do serviço.
Version: valor da versão do serviço.
Weight: especificar a porcentagem de requisições que será destinada à versão em questão do serviço.

Os três campos indicados acima são replicados automaticamente de acordo com o número de versões implementadas para o serviço.

A soma de todas as porcentagens informadas nos campos Weight da regra sendo configurada deverá ser igual a 100%.

Serviços externos

No caso de serviços externos (selecionando a opção "External" no campo Connection Type), além dos mesmos campos dos serviços internos, há a seção INGRESS CONFIGURATION, que contém a opção Bind to default ingress. Se essa opção for marcada, o Istio Ingress Gateway será utilizado para expor externamente os serviços presentes no cluster (padrão).

Caso deseje utilizar outro ingress, a opção Bind to default ingress deve ser desmarcada. Note que neste caso serão necessárias configurações de instalação adicionais.

Leia sobre como integrar o Ingress NGINX.

Criando uma regra pela linha de comando

Para criar uma regra de Traffic Routing por peso via kubectl, aplique um arquivo .yaml como o do exemplo a seguir:

apiVersion: networking.sensedia.com/v1
kind: TrafficRouting
metadata:
  name: tr-reviews
  namespace: bookinfo
spec:
  connectionType: Internal
  enabled: true
  port: 9999
  serviceName: reviews
  traffic:
    - name: traffic-name-v1
      version: v1
      weight: 80
    - name: traffic-name-v2
      version: v2
      weight: 20

A configuração da regra nesse arquivo se dá por meio dos seguintes campos:

.kind: especifica o tipo de objeto a ser criado; nesse caso, um objeto do tipo TrafficRouting;
.metadata.name: define um nome para identificar o recurso;
.metadata.namespace: mesh/namespace do qual o serviço faz parte;
.spec.connectionType: tipo da conexão da regra, Internal ou External;
.spec.enabled: habilita (enabled: true) ou desabilita (enabled: false) a regra;
.spec.port: porta que expõe o serviço no Kubernetes;
.spec.serviceName: especifica o serviço para o qual a regra será aplicada;
.spec.traffic.name: nome identificador do destino do tráfego;
.spec.traffic.version: valor da versão do serviço à qual o tráfego será roteado;
.spec.traffic.weight: porcentagem de requisições que será destinada à versão do serviço informada.

O arquivo .yaml do exemplo acima configura para o serviço reviews do namespace bookinfo uma regra de Traffic Routing de conexão interna que destina 80% das requisições à versão v1 desse serviço e os 20% restantes à versão v2.

Criando uma regra de Traffic Routing do tipo header

A regra de Traffic Routing do tipo header utiliza como critério a presença de um header com nome e valor pré-determinados para rotear as requisições entre as versões configuradas dos serviços.

Para criar uma nova regra para o serviço selecionado, clique no botão ADD NEW RULE da aba TRAFFIC MANAGEMENT.

Serviços internos

No caso de serviços internos, os campos a serem preenchidos são estes:

Type: tipo da regra (escolha o tipo Traffic Routing).
Name: nome identificador da regra.

O nome deve ser único para o mesh/namespace do qual o serviço faz parte.
Port: porta que expõe o serviço no Kubernetes.
Enable mTLS: checkbox que deve ser marcada para habilitar conexão com segurança do tipo mTLS.
Connection Type: tipo da conexão do serviço, que pode ser externa ou interna (nesse caso, escolher Internal).
Path: caminho da API que expõe o serviço (opcional).
Split by: campo para definir o tipo de política de roteamento, se por porcentagem de requisições (weight) ou por validação de cabeçalho (header). No caso, escolher Header.

Campos da seção DESTINATION:

Traffic Name: nome identificador da versão do serviço (que pode ser igual ao campo Version ou mais descritivo).
Version: valor da versão do serviço.
Header: campo para inserir o nome do header que será validado para encaminhar as requisições.
Value: campo para inserir o valor do header que será validado para encaminhar as requisições.

Se quiser, é possível adicionar mais de um header a um destino. Nesse caso, todos os headers inseridos devem estar contidos em uma requisição para que ela seja roteada à versão em questão. Para incluir um header adicional, clique no ícone + ao lado do campo Value.

Também é possível adicionar outros destinos para a mesma Traffic Routing do tipo header. Para fazer isso, clique no botão + ADD DESTINATION. Você pode adicionar quantos headers quiser ao novo destino criado.

Serviços externos

Caso deseje utilizar outro ingress, a opção Bind to default ingress deve ser desmarcada. Note que neste caso serão necessárias configurações de instalação adicionais.

Leia sobre como integrar o Ingress NGINX.

Assim como para serviços internos, é possível adicionar múltiplos destinos para a mesma Traffic Routing, bem como incluir mais de um header por destino.

Criando uma regra pela linha de comando

Para criar uma regra de Traffic Routing do tipo header via kubectl, aplique um arquivo .yaml como o do exemplo a seguir:

apiVersion: networking.sensedia.com/v1
kind: TrafficRouting
metadata:
  name: tr-reviews-header-int
  namespace: bookinfo
spec:
  connectionType: Internal
  enabled: true
  port: 9999
  serviceName: reviews
  traffic:
    - name: reviews-v1
      version: v1
      headers:
        header-1:
          exact: value-1
        header-2:
          exact: value-2
    - name: reviews-v2
      version: v2
      headers:
        header-3:
          exact: value-3
        header-4:
          exact: value-4

A configuração da regra nesse arquivo se dá por meio dos seguintes campos:

.kind: especifica o tipo de objeto a ser criado; nesse caso, um objeto do tipo TrafficRouting;
.metadata.name: define um nome para identificar o recurso;
.metadata.namespace: mesh/namespace do qual o serviço faz parte;
.spec.connectionType: tipo da conexão da regra, Internal ou External;
.spec.enabled: habilita (enabled: true) ou desabilita (enabled: false) a regra;
.spec.port: porta que expõe o serviço no Kubernetes;
.spec.serviceName: especifica o serviço para o qual a regra será aplicada;
.spec.traffic.name: nome identificador do destino do tráfego;
.spec.traffic.version: valor da versão do serviço à qual o tráfego será roteado;
.spec.traffic.headers: nome e valor (exact) do header que será validado para encaminhar as requisições.

Shadow Traffic

Traffic shadowing é uma estratégia de implantação de versão que não impacta o tráfego de um serviço. Quando aplicada, uma nova versão do serviço é implantada recebendo uma parte das requisições já tratadas pela versão antiga, sem ter que responder a essas requisições.

Só é possível criar uma regra do tipo Shadow Traffic se houver uma Traffic Routing do tipo peso para receber 100% das requisições.

A configuração de uma política de roteamento desse tipo independe do serviço ser exposto para tráfego externo ou não. Os campos a completar são estes:

Type: tipo da regra (escolha o tipo Shadow Traffic).
Name: nome identificador da regra.

O nome deve ser único para o mesh/namespace do qual o serviço faz parte.
Port: porta que expõe o serviço no Kubernetes.

Campos da seção Mirror traffic to:

Traffic Name: nome identificador da versão do serviço que receberá uma parte das requisições, sem enviar as respostas. O nome pode ser igual ao campo Version ou mais descritivo.
Version: valor da versão do serviço.
Mirroring: porcentagem de requisições a serem espelhadas à versão indicada.

Criando uma regra pela linha de comando

Para criar uma regra de Shadow Traffic via kubectl, aplique um arquivo .yaml como o do exemplo a seguir:

apiVersion: networking.sensedia.com/v1
kind: ShadowTraffic
metadata:
  name: st-reviews
  namespace: bookinfo
spec:
  enabled: true
  port: 9999
  serviceName: reviews
  mirror:
      name: reviews-v2
      version: v2
      percentage: 80

A configuração da regra nesse arquivo se dá por meio dos seguintes campos:

.kind: especifica o tipo de objeto a ser criado; nesse caso, um objeto do tipo ShadowTraffic;
.metadata.name: define um nome para identificar o recurso;
.metadata.namespace: mesh/namespace do qual o serviço faz parte;
.spec.enabled: habilita (enabled: true) ou desabilita (enabled: false) a regra;
.spec.port: porta que expõe o serviço no Kubernetes;
.spec.serviceName: especifica o serviço para o qual a regra será aplicada;
.spec.mirror.name: nome identificador do destino da cópia do tráfego;
.spec.mirror.version: valor da versão do serviço à qual a cópia do tráfego será destinada;
.spec.mirror.percentage: porcentagem de requisições a serem espelhadas à versão indicada. Campo opcional. Se omitido, o valor a ser considerado será 100%.

Thanks for your feedback!

EDIT

How useful was this article to you?