Olá Habr! Apresento a você a tradução do artigo "Service mesh data plane vs control control" de Matt Klein .



Dessa vez, desejei e traduzi a descrição dos dois componentes da malha de serviço, plano de dados e plano de controle. Essa descrição me pareceu a mais compreensível e interessante, e o mais importante, levando à compreensão de "Isso é mesmo necessário?"

Como a idéia de uma “malha de serviço” se tornou cada vez mais popular nos últimos dois anos (artigo original em 10 de outubro de 2017) e o número de participantes no espaço aumentou, eu vi um aumento proporcional de confusão entre toda a comunidade técnica sobre como comparar e contraste diferentes soluções.

A situação é melhor descrita na seguinte série de tweets que escrevi em julho:

Confusão com a malha de serviço (malha de serviço) nº 1: Linkerd ~ = Nginx ~ = Haproxy ~ = Enviado. Nenhum deles é igual ao Istio. Istio é algo completamente diferente. 1 /

O primeiro são apenas planos de dados. Eles mesmos não fazem nada. Eles precisam ser ajustados para algo mais. 2 /

O Istio é um exemplo de um plano de controle que liga partes. Esta é uma camada diferente. / end

Os tweets anteriores mencionaram vários projetos diferentes (Linkerd, NGINX, HAProxy, Envoy e Istio), mas, mais importante, introduziram os conceitos gerais de um plano de dados, uma malha de serviço e um plano de controle. Neste post, darei um passo atrás e direi o que quero dizer com os termos "plano de dados" e "plano de controle" em um nível muito alto. Depois, mostrarei como os termos se relacionam com os projetos mencionados. em tweets.

O que é uma malha de serviço (realmente)?

Figura 1: Visão geral da malha de serviço

A Figura 1 ilustra o conceito de uma malha de serviço no nível mais básico. Existem quatro clusters de serviço (AD). Cada instância de serviço está associada a um servidor proxy local. Todo o tráfego de rede (HTTP, REST, gRPC, Redis etc.) de uma única instância de aplicativo é transmitido através de um servidor proxy local para os clusters de serviços externos correspondentes. Portanto, a instância do aplicativo não conhece a rede como um todo e apenas conhece seu proxy local. De fato, a rede do sistema distribuído era remota do serviço.

Plano de dados

Em uma malha de serviço, um servidor proxy localizado localmente para o aplicativo executa as seguintes tarefas:

• Descoberta de serviço Quais serviços / serviços / aplicativos estão disponíveis para o seu aplicativo?
• Verificação de integridade As instâncias de serviço retornadas pela descoberta de serviço estão operacionais e prontas para aceitar o tráfego de rede? Isso pode incluir verificações de saúde ativas (por exemplo, verificação da resposta / verificação de saúde) ou passivas (por exemplo, usando 3 erros 5xx consecutivos como uma indicação do estado não íntegro do serviço).
• Encaminhamento Tendo recebido uma solicitação para "/ foo" do serviço REST, para qual cluster de serviço a solicitação deve ser enviada?
• Balanceamento de carga Após a seleção de um cluster de serviços durante o roteamento, para qual instância do serviço a solicitação deve ser enviada? Que tempo limite? Quais configurações para interrupção de circuito? Se a solicitação falhar, deve ser repetida?
• Autenticação e autorização Para solicitações de entrada, o serviço de chamada pode ser identificado / autorizado criptograficamente usando mTLS ou algum outro mecanismo? Se for identificado / autorizado, é permitido chamar a operação solicitada (terminal) no serviço ou deve ser retornada uma resposta não autenticada?
• Observabilidade Para cada solicitação, estatísticas detalhadas, logs / logs e dados de rastreamento distribuídos devem ser gerados para que os operadores possam entender o fluxo de tráfego distribuído e os problemas de depuração à medida que surgem.

Por todos os pontos anteriores na rede de serviço (malha de serviço), o plano de dados é responsável. De fato, o proxy local do serviço (side-car) é um plano de dados. Em outras palavras, o plano de dados é responsável pela transmissão, encaminhamento e monitoramento condicionais de cada pacote de rede enviado ou enviado pelo serviço.

O plano de controle

A abstração de rede fornecida pelo proxy local no plano de dados é mágica (?). No entanto, como o proxy realmente sabe sobre a rota "/ foo" para o serviço B? Como os dados de descoberta de serviço preenchidos com solicitações de proxy podem ser usados? Como são definidas as configurações de balanceamento de carga, tempo limite, interrupção de circuito etc.? Como implantar o aplicativo usando o método azul / verde (azul / verde) ou o método de transferência gradual de tráfego? Quem define as configurações de autenticação e autorização em todo o sistema?

Todos os itens acima são gerenciados pelo plano de controle da malha de serviço. O plano de controle aceita um conjunto de servidores proxy isolados sem estado e os transforma em um sistema distribuído .

Eu acho que a razão pela qual muitos tecnólogos acham os conceitos separados do plano de dados e do plano de controle confusos é porque, para a maioria das pessoas, o plano de dados é familiar, enquanto o plano de controle é estranho / incompreensível. Trabalhamos com roteadores e comutadores de rede físicos há muito tempo. Entendemos que os pacotes / solicitações devem ir do ponto A ao ponto B e que podemos usar hardware e software para isso. A nova geração de proxies de software são simplesmente as versões modernas das ferramentas que usamos há muito tempo.


Figura 2: Plano de controle humano

No entanto, há muito tempo usamos o plano de controle, embora a maioria dos operadores de rede não possa associar essa parte do sistema a nenhum componente tecnológico. A razão para isso é simples:
A maioria dos aviões de controle usados ​​hoje em dia é ... nós .

A Figura 2 mostra o que eu chamo de "plano de controle humano". Nesse tipo de implantação, que ainda é muito comum, o operador humano, provavelmente mal-humorado, cria configurações estáticas - potencialmente usando scripts - e as implementa usando algum tipo de processo especial em todos os proxies. Em seguida, os proxies começam a usar essa configuração e começam a processar o plano de dados usando as configurações atualizadas.


Figura 3: Plano de controle de malha de serviço avançado

A Figura 3 mostra o plano de controle "estendido" da malha de serviço. Consiste nas seguintes partes:

• O Humano : Ainda existe uma pessoa (espero que menos zangada) que tome decisões de alto nível em relação a todo o sistema.
• Interface do usuário do plano de controle : uma pessoa interage com algum tipo de interface do usuário para controlar o sistema. Pode ser um portal da web, um aplicativo de linha de comando (CLI) ou alguma outra interface. Usando a interface do usuário, o operador tem acesso a parâmetros globais de configuração do sistema, como:
  
  • Gerenciamento de implantação, azul / verde e / ou com transferência gradual de tráfego
  • Configurações de autenticação e autorização
  • Especificações da tabela de roteamento, por exemplo, quando o aplicativo A solicita informações sobre "/ foo", o que acontece
  • Configurações do balanceador de carga, como tempos limite, novas tentativas, parâmetros de interrupção de circuito, etc.
• Planejador de carga de trabalho : os serviços são iniciados na infraestrutura por meio de um determinado tipo de sistema de planejamento / orquestração, como Kubernetes ou Nomad. O agendador é responsável por carregar o serviço junto com seu servidor proxy local.
• Descoberta de serviço Quando o planejador inicia e para as instâncias de serviço, ele reporta o estado de integridade ao sistema de descoberta de serviço.
• APIs de configuração de proxy de side-car : os proxies locais extraem dinamicamente o estado de vários componentes do sistema, de acordo com o modelo "consistente em última análise" sem intervenção do operador. Todo o sistema, consistindo em todas as instâncias atualmente em execução de serviços e servidores proxy locais, finalmente converge para um ecossistema. A API do plano de dados Envoy é um exemplo de como isso funciona na prática.

Essencialmente, o objetivo do plano de controle é estabelecer uma política que será finalmente adotada pelo plano de dados. Planos de controle mais avançados removerão mais partes de alguns sistemas do operador e exigirão menos controle manual, desde que funcionem corretamente! ..

Plano de dados e plano de controle. Resumo do plano de dados x plano de controle

• Plano de dados da malha de serviço : afeta todos os pacotes / solicitações no sistema. Responsável pela descoberta de aplicativos / serviços, verificações de integridade, roteamento, balanceamento de carga, autenticação / autorização e observabilidade.
• Plano de controle de malha de serviço : fornece política e configuração para todos os planos de dados em funcionamento na rede de serviço. Não toca em nenhum pacote / solicitação no sistema. O plano de controle transforma todos os planos de dados em um sistema distribuído.

Cenário atual do projeto

Tendo descoberto a explicação acima, vejamos o status atual do projeto “service mesh”.

• Planos de dados : Linkerd, NGINX, HAProxy, Enviado, Traefik
• Aviões de controle : Istio, Nelson, SmartStack

Em vez de realizar uma análise aprofundada de cada uma das soluções acima, vou abordar brevemente alguns pontos que, na minha opinião, causam a maior parte da confusão no ecossistema no momento.

No início de 2016, o Linkerd foi um dos primeiros servidores proxy do plano de dados para a malha de serviço e fez um trabalho fantástico de sensibilização e atenção ao modelo de design de malha de serviço. Cerca de 6 meses depois disso, o Enviado ingressou na Linkerd (embora esteja na Lyft desde o final de 2015). Linkerd e Envoy são dois dos projetos mais mencionados ao discutir redes de serviços.

Istio foi anunciado em maio de 2017. Os objetivos do projeto Istio são muito semelhantes ao plano de controle estendido mostrado na Figura 3 . O Enviado para Istio é o servidor proxy padrão. Assim, Istio é o plano de controle e Envoy é o plano de dados. Em pouco tempo, o Istio causou muitos distúrbios e outros planos de dados começaram a se integrar como um substituto do Envoy (o Linkerd e o NGINX demonstraram integração com o Istio). O fato de você poder usar planos de dados diferentes no mesmo plano de controle significa que o plano de controle e o plano de dados não estão necessariamente intimamente relacionados. Uma API como a API do plano de dados universal da Envoy pode formar uma ponte entre duas partes do sistema.

Nelson e SmartStack ajudam a ilustrar ainda mais a separação entre o plano de controle e o plano de dados. Nelson usa o Envoy como seu proxy e constrói um plano de controle confiável da malha de serviço com base na pilha HashiCorp, ou seja, Nomad etc. O SmartStack é talvez o primeiro de uma nova onda de redes de serviço. O SmartStack forma um plano de controle em torno de um HAProxy ou NGINX, demonstrando a capacidade de dissociar um plano de controle de uma malha de serviço e de um plano de dados.

Uma arquitetura de microsserviço com uma malha de serviço está atraindo mais atenção (certo!), E mais e mais projetos e fornecedores estão começando a trabalhar nessa direção. Nos próximos anos, veremos muitas inovações tanto no plano de dados quanto no plano de controle, além de outras misturas dos vários componentes. Por fim, a arquitetura de microsserviço deve se tornar mais transparente e mágica (?) Para o operador.
Espero cada vez menos irritado.

Pontos principais (Principais tópicos)

• Uma malha de serviço (malha de serviço) consiste em duas partes diferentes: um plano de dados e um plano de controle. Ambos os componentes são necessários e, sem eles, o sistema não funcionará.
• Todo mundo está familiarizado com o plano de controle, e agora você pode ser o plano de controle!
• Todos os planos de dados competem entre si em funções, desempenho, configurabilidade e extensibilidade.
• Todos os planos de controle competem em função, configurabilidade, extensibilidade e usabilidade.
• Um único plano de controle pode conter as abstrações e APIs corretas para que vários planos de dados possam ser usados.