Olá, Habr! Apresento a sua atenção uma tradução do artigo autor Matt Klein.
Desta vez, eu “queria e traduzia” a descrição dos componentes da malha de serviço, do plano de dados e do plano de controle. Esta descrição me pareceu a mais compreensível e interessante e, o mais importante, levando à compreensão de “É mesmo necessário?”
À medida que a ideia 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, tenho visto um aumento proporcional na confusão entre todo o comunidade de tecnologia sobre como comparar e contrastar diferentes soluções.
A situação é melhor resumida pela seguinte série de tweets que escrevi em julho:
Confusão de malha de serviço nº 1: Linkerd ~ = Nginx ~ = Haproxy ~ = Envoy. Nenhum deles é igual ao Istio. Istio é algo completamente diferente. 1 /
Os primeiros são simplesmente planos de dados. Sozinhos eles não fazem nada. Eles devem estar com vontade de algo mais. 2/
Istio é um exemplo de plano de controle que une as peças. Esta é outra camada. /fim
Os tweets anteriores mencionam vários projetos diferentes (Linkerd, NGINX, HAProxy, Envoy e Istio), mas o mais importante é apresentar os conceitos gerais de plano de dados, malha de serviço e plano de controle. Neste post, darei um passo atrás e falarei sobre o que quero dizer com os termos “plano de dados” e “plano de controle” em um nível muito alto e, em seguida, falarei sobre como os termos se aplicam aos projetos mencionados nos tweets.
O que é realmente uma malha de serviço?
Figura 1: Visão geral da malha de serviço
Figura 1 ilustra o conceito de malha de serviço em seu 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 é passado por meio de um proxy local para os clusters de serviços externos apropriados. Dessa forma, a instância da aplicação desconhece a rede como um todo e apenas conhece seu proxy local. Com efeito, a rede do sistema distribuído foi removida do serviço.
Plano de dados
Em uma malha de serviço, um servidor proxy localizado localmente para a aplicação executa as seguintes tarefas:
- Descoberta de serviço. Quais serviços/aplicativos estão disponíveis para sua aplicação?
- Verificação de saúde. As instâncias de serviço retornadas pela descoberta de serviço estão íntegras e prontas para aceitar o tráfego de rede? Isso pode incluir verificações de integridade ativas (por exemplo, resposta/verificação de integridade) e passivas (por exemplo, uso de 3 erros 5xx consecutivos como indicação de um estado de serviço não íntegro).
- Roteamento. Ao receber uma solicitação para "/foo" de um serviço REST, para qual cluster de serviço a solicitação deve ser enviada?
- Balanceamento de carga. Depois que um cluster de serviço for selecionado durante o roteamento, para qual instância de serviço a solicitação deverá ser enviada? Com que tempo limite? Com quais configurações de interrupção do circuito? Se a solicitação falhar, ela deverá ser tentada novamente?
- Autenticação e autorização. Para solicitações recebidas, o serviço de chamada pode ser identificado/autorizado criptograficamente usando mTLS ou algum outro mecanismo? Se for reconhecido/autorizado, é permitido chamar a operação solicitada (endpoint) no serviço ou deve ser retornada uma resposta não autenticada?
- Observabilidade. Estatísticas detalhadas, logs/logs e dados de rastreamento distribuídos devem ser gerados para cada solicitação, para que os operadores possam entender o fluxo de tráfego distribuído e os problemas de depuração à medida que surgirem.
O plano de dados é responsável por todos os pontos anteriores da malha de serviço. Na verdade, o proxy local do serviço (sidecar) é o plano de dados. Em outras palavras, o plano de dados é responsável por transmitir, encaminhar e monitorar condicionalmente cada pacote de rede enviado de ou para um serviço.
O plano de controle
A abstração de rede que um proxy local fornece no plano de dados é mágica (?). No entanto, como o proxy realmente sabe sobre a rota "/foo" para o serviço B? Como podem ser usados os dados de descoberta de serviço preenchidos por solicitações de proxy? Como são configurados os parâmetros de balanceamento de carga, timeout, interrupção de circuito, etc.? Como você implanta um aplicativo usando o método azul/verde ou o método de transição de tráfego elegante? Quem define as configurações de autenticação e autorização em todo o sistema?
Todos os itens acima estão sob o controle do plano de controle da malha de serviço. O plano de controle pega um conjunto de proxies sem estado isolados e os transforma em um sistema distribuído.
Acho que a razão pela qual muitos tecnólogos consideram confusos os conceitos separados de plano de dados e plano de controle é porque para a maioria das pessoas o plano de dados é familiar, enquanto o plano de controle é estranho/incompreendido. Há muito tempo que trabalhamos com roteadores e switches de rede física. Entendemos que os pacotes/solicitações precisam ir do ponto A ao ponto B e que podemos usar hardware e software para fazer isso. A nova geração de proxies de software são simplesmente versões sofisticadas das ferramentas que usamos há muito tempo.
Figura 2: Plano de controle humano
No entanto, já utilizamos planos de controle há muito tempo, embora a maioria dos operadores de rede possa não associar esta parte do sistema a nenhum componente tecnológico. A razão é simples:
A maioria dos aviões de controle em uso hoje são... nós.
На figura 2 mostra o que chamo de “plano de controle humano”. Neste tipo de implantação, que ainda é muito comum, um operador humano provavelmente mal-humorado cria configurações estáticas - potencialmente através de scripts - e as implanta através de algum processo especial para todos os proxies. Os proxies então começam a usar essa configuração e a processar o plano de dados usando as configurações atualizadas.
Figura 3: Plano de controle de malha de serviço avançado
На 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 irritada) que toma decisões de alto nível em relação a todo o sistema como um todo.
- IU do plano de controle: Uma pessoa interage com algum tipo de interface de 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 aos parâmetros globais de configuração do sistema, como:
- Controle de implantação, transição de tráfego azul/verde e/ou gradual
- Opçõ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, configurações de interrupção de circuito, etc.
- Agendador de carga de trabalho: os serviços são executados na infraestrutura por meio de algum tipo de sistema de agendamento/orquestração, como Kubernetes ou Nomad. O escalonador é responsável por carregar o serviço junto com seu proxy local.
- Descoberta de serviço. Quando o agendador inicia e interrompe instâncias de serviço, ele relata o status de funcionamento ao sistema de descoberta de serviço.
- APIs de configuração de proxy secundário : Os proxies locais extraem dinamicamente o estado de vários componentes do sistema usando um modelo eventualmente consistente sem intervenção do operador. Todo o sistema, que consiste em todas as instâncias de serviço e servidores proxy locais em execução atualmente, converge em última análise em um ecossistema. A API universal de plano de dados do Envoy é um exemplo de como isso funciona na prática.
Essencialmente, o objetivo do plano de controle é definir a política que será aceita pelo plano de dados. Aviões de controle mais avançados removerão mais peças de alguns sistemas do operador e exigirão menos operação manual, desde que funcionem corretamente!...
Plano de dados e plano de controle. Resumo do plano de dados vs. plano de controle
- Plano de dados da malha de serviço: afeta todos os pacotes/solicitações no sistema. Responsável pela descoberta de aplicações/serviços, verificação de integridade, roteamento, balanceamento de carga, autenticação/autorização e observabilidade.
- Plano de controle da malha de serviço: fornece política e configuração para todos os planos de dados em execução 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 entendido a explicação acima, vamos dar uma olhada no estado atual do projeto de malha de serviço.
- Planos de dados: Linkerd, NGINX, HAProxy, Envoy, Traefik
- Aviões de controle: Istio, Nelson, SmartStack
Em vez de entrar numa análise aprofundada de cada uma das soluções acima, abordarei brevemente alguns dos pontos que acredito estarem a causar grande parte da confusão no ecossistema neste momento.
Linkerd foi um dos primeiros servidores proxy de plano de dados para a malha de serviço no início de 2016 e fez um trabalho fantástico ao aumentar a conscientização e a atenção para o modelo de design da malha de serviço. Cerca de 6 meses depois disso, Envoy ingressou na Linkerd (embora estivesse na Lyft desde o final de 2015). Linkerd e Envoy são os dois projetos mencionados com mais frequência quando se discute malhas de serviço.
O Istio foi anunciado em maio de 2017. Os objetivos do projeto Istio são muito semelhantes ao plano de controle estendido mostrado em figura 3. Envoy for Istio é o proxy padrão. Assim, Istio é o plano de controle e Envoy é o plano de dados. Em pouco tempo, o Istio gerou muito entusiasmo e outros planos de dados começaram a ser integrados como substitutos do Envoy (tanto o Linkerd quanto o NGINX demonstraram integração com o Istio). O fato de diferentes planos de dados poderem ser usados dentro do mesmo plano de controle significa que o plano de controle e o plano de dados não estão necessariamente fortemente acoplados. Uma API como a API genérica do plano de dados do Envoy pode formar uma ponte entre duas partes do sistema.
Nelson e SmartStack ajudam a ilustrar melhor a separação entre o plano de controle e o plano de dados. Nelson usa o Envoy como proxy e constrói um plano de controle confiável para a malha de serviço com base na pilha HashiCorp, ou seja, Nômade, etc SmartStack foi talvez o primeiro de uma nova onda de malhas de serviço. SmartStack constrói um plano de controle em torno do HAProxy ou NGINX, demonstrando a capacidade de dissociar o plano de controle da malha de serviço do plano de dados.
A arquitetura de microsserviços com malha de serviço está ganhando cada vez mais atenção (com razão!), e cada vez mais projetos e fornecedores estão começando a trabalhar nessa direção. Nos próximos anos veremos muita inovação tanto no plano de dados quanto no plano de controle, bem como uma maior mistura de diferentes componentes. Em última análise, a arquitetura de microsserviços deve se tornar mais transparente e mágica (?) para a operadora.
Esperemos que cada vez menos irritado.
Principais conclusões
- Uma malha de serviço consiste em duas partes diferentes: o plano de dados e o plano de controle. Ambos os componentes são necessários e sem eles o sistema não funcionará.
- Todos estão familiarizados com o plano de controle e, neste ponto, o plano de controle pode ser você!
- Todos os planos de dados competem entre si em recursos, desempenho, configurabilidade e extensibilidade.
- Todos os planos de controle competem entre si em recursos, configurabilidade, extensibilidade e facilidade de uso.
- Um plano de controle pode conter as abstrações e APIs corretas para que vários planos de dados possam ser usados.
Fonte: habr.com