Ola Habr! Presento á súa atención a tradución do artigo "Plan de datos de malla de servizo vs plano de control" autor Matt Klein.

Esta vez, "quería e traducín" a descrición de ambos os compoñentes da malla de servizo, o plano de datos e o plano de control. Esta descrición pareceume a máis comprensible e interesante, e o máis importante que levou á comprensión de "É necesario en absoluto?"

Como a idea dunha "malla de servizo" se fixo cada vez máis popular nos últimos dous anos (Artigo orixinal 10 de outubro de 2017) e aumentou o número de participantes no espazo, vin un aumento proporcional da confusión entre todo o conxunto. comunidade tecnolóxica sobre como comparar e contrastar diferentes solucións.

A situación resúmese mellor coa seguinte serie de chíos que escribín en xullo:

Confusión de malla de servizo #1: Linkerd ~ = Nginx ~ = Haproxy ~ = Envoy. Ningún deles é igual a Istio. Istio é algo completamente diferente. 1/

Os primeiros son simplemente planos de datos. Por si sós non fan nada. Deben estar de humor para algo máis. 2/

Istio é un exemplo de plano de control que une as partes. Esta é outra capa. /fin

Os tweets anteriores mencionan varios proxectos diferentes (Linkerd, NGINX, HAProxy, Envoy e Istio), pero o máis importante é introducir os conceptos xerais de plano de datos, malla de servizo e plano de control. Neste post, vou dar un paso atrás e falarei do que quero dicir cos termos "plano de datos" e "plano de control" a un nivel moi alto, e despois falarei de como se aplican os termos aos proxectos mencionados nos chíos.

Que é realmente unha malla de servizo?

Figura 1: Visión xeral da malla de servizo

Imaxe 1 ilustra o concepto de malla de servizo no seu nivel máis básico. Hai catro clusters de servizos (AD). Cada instancia de servizo está asociada a un servidor proxy local. Todo o tráfico de rede (HTTP, REST, gRPC, Redis, etc.) dunha única instancia de aplicación pasa a través dun proxy local aos clústeres de servizos externos apropiados. Deste xeito, a instancia da aplicación descoñece a rede no seu conxunto e só coñece o seu proxy local. En efecto, a rede do sistema distribuído foi eliminada do servizo.

Plano de datos

Nunha malla de servizo, un servidor proxy situado localmente para a aplicación realiza as seguintes tarefas:

• Descubrimento do servizo. Que servizos/aplicacións están dispoñibles para a súa aplicación?
• Control de saúde. As instancias de servizo que devolveu o descubrimento do servizo son saudables e listas para aceptar tráfico de rede? Isto pode incluír comprobacións de saúde activas (por exemplo, resposta/comprobación de saúde) e pasivas (por exemplo, usando 3 erros 5xx consecutivos como indicación dun estado de servizo non saudable).
• Enrutamento. Cando se recibe unha solicitude a "/foo" dun servizo REST, a que clúster de servizos se debe enviar a solicitude?
• Equilibrio de carga. Unha vez seleccionado un clúster de servizos durante o enrutamento, a que instancia de servizo debe enviarse a solicitude? Con que tempo morto? Con que configuracións de corte de circuíto? Se a solicitude falla, debería tentala de novo?
• Autenticación e autorización. Para as solicitudes entrantes, pódese identificar/autorizar criptográficamente o servizo de chamada mediante mTLS ou algún outro mecanismo? Se é recoñecido/autorizado, está permitido chamar á operación solicitada (punto final) no servizo ou debería devolverse unha resposta non autenticada?
• Observabilidade. Débense xerar estatísticas detalladas, rexistros/rexistros e datos de rastrexo distribuídos para cada solicitude para que os operadores poidan entender o fluxo de tráfico distribuído e os problemas de depuración a medida que xurdan.

O plano de datos é responsable de todos os puntos anteriores da malla de servizo. De feito, o proxy local do servizo (sidecar) é o plano de datos. Noutras palabras, o plano de datos é responsable de transmitir, reenviar e supervisar condicionalmente cada paquete de rede que se envía a ou dende un servizo.

O plano de control

A abstracción de rede que proporciona un proxy local no plano de datos é máxica(?). Non obstante, como sabe o proxy sobre a ruta "/foo" ao servizo B? Como se poden usar os datos de descubrimento de servizos que se encheran mediante solicitudes de proxy? Como se configuran os parámetros para o equilibrio de carga, tempo de espera, corte de circuito, etc.? Como se implementa unha aplicación usando o método azul/verde ou o método de transición de tráfico elegante? Quen configura as opcións de autenticación e autorización de todo o sistema?

Todos os elementos anteriores están baixo o control do plano de control da malla de servizo. O plano de control toma un conxunto de proxies sen estado illados e convérteos nun sistema distribuído.

Creo que a razón pola que moitos tecnólogos consideran confusos os conceptos separados de plano de datos e plano de control é porque para a maioría da xente o plano de datos é familiar mentres que o plano de control é estraño/incomprendido. Levamos moito tempo traballando con enrutadores e conmutadores de rede físicas. Entendemos que os paquetes/solicitudes deben ir do punto A ao punto B e que podemos usar hardware e software para facelo. A nova xeración de proxies de software son simplemente versións fantásticas das ferramentas que usamos durante moito tempo.

Figura 2: Plano de control humano

Non obstante, levamos moito tempo usando planos de control, aínda que a maioría dos operadores de rede quizais non asocien esta parte do sistema con ningún compoñente tecnolóxico. O motivo é sinxelo:
A maioría dos avións de control que se usan hoxe son... nós.

En Figura 2 mostra o que eu chamo o "plano de control humano". Neste tipo de despregamento, que aínda é moi común, un operador humano probablemente malhumorado crea configuracións estáticas -potencialmente a través de scripts- e desprégaas mediante algún proceso especial a todos os proxies. A continuación, os proxies comezan a usar esta configuración e comezan a procesar o plano de datos mediante a configuración actualizada.

Figura 3: plano de control de malla de servizo avanzado

En Figura 3 mostra o plano de control "estendido" da malla de servizo. Consta das seguintes partes:

• O humano: Aínda hai unha persoa (con sorte menos enfadada) que toma decisións de alto nivel con respecto a todo o sistema no seu conxunto.
• IU do plano de control: Unha persoa interactúa con algún tipo de interface de usuario para controlar o sistema. Pode ser un portal web, unha aplicación de liña de comandos (CLI) ou algunha outra interface. Usando a interface de usuario, o operador ten acceso aos parámetros globais de configuración do sistema, como:
  • Control de despregamento, transición de tráfico azul/verde e/ou gradual
  • Opcións de autenticación e autorización
  • Especificacións da táboa de enrutamento, por exemplo cando a aplicación A solicita información sobre "/foo" o que ocorre
  • Configuración do equilibrador de carga, como tempo de espera, reintentos, axustes de corte de circuítos, etc.
• Programador de carga de traballo: Os servizos execútanse na infraestrutura mediante algún tipo de sistema de programación/orquestración, como Kubernetes ou Nomad. O programador é responsable de cargar o servizo xunto co seu proxy local.
• Descubrimento do servizo. Cando o programador inicia e detén as instancias do servizo, informa o estado de saúde ao sistema de detección do servizo.
• API de configuración de proxy de sidecar : Os proxies locais extraen dinámicamente o estado de varios compoñentes do sistema usando un modelo eventualmente consistente sen intervención do operador. Todo o sistema, composto por todas as instancias de servizo en execución e servidores proxy locais, conflúe finalmente nun ecosistema. A API de plano de datos universal de Envoy é un exemplo de como isto funciona na práctica.

Esencialmente, o propósito do plano de control é establecer a política que finalmente será aceptada polo plano de datos. Os planos de control máis avanzados eliminarán máis partes dalgúns sistemas do operador e requirirán menos operación manual, sempre que funcionen correctamente!...

Plano de datos e plano de control. Plan de datos vs. resumo do plano de control

• Plano de datos de malla de servizo: Afecta a cada paquete/solicitude do sistema. Responsable do descubrimento de aplicacións/servizos, comprobación de saúde, enrutamento, equilibrio de carga, autenticación/autorización e observabilidade.
• Plano de control de malla de servizo: Ofrece políticas e configuración para todos os planos de datos en execución dentro da rede de servizo. Non toca ningún paquete/solicitude do sistema. O plano de control converte todos os planos de datos nun sistema distribuído.

Panorama actual do proxecto

Unha vez entendida a explicación anterior, vexamos o estado actual do proxecto de malla de servizo.

• Planos de datos: Linkerd, NGINX, HAProxy, Envoy, Traefik
• Planos de control: Istio, Nelson, SmartStack

En lugar de entrar nunha análise en profundidade de cada unha das solucións anteriores, abordarei brevemente algúns dos puntos que creo que están a causar gran parte da confusión no ecosistema agora mesmo.

Linkerd foi un dos primeiros servidores proxy de planos de datos para a malla de servizo a principios de 2016 e fixo un traballo fantástico de sensibilización e atención sobre o modelo de deseño de malla de servizo. Uns 6 meses despois diso, Envoy uniuse a Linkerd (aínda que estivo con Lyft desde finais de 2015). Linkerd e Envoy son os dous proxectos que se mencionan con máis frecuencia cando se fala de mallas de servizo.

Istio anunciouse en maio de 2017. Os obxectivos do proxecto Istio son moi similares ao plano de control ampliado que se mostra Figura 3. Envoy for Istio é o proxy predeterminado. Así, Istio é o plano de control e Envoy é o plano de datos. En pouco tempo, Istio xerou moita emoción e outros avións de datos comezaron a integrarse como substituto de Envoy (tanto Linkerd como NGINX demostraron a integración con Istio). O feito de que se poidan utilizar diferentes planos de datos dentro do mesmo plano de control significa que o plano de control e o plano de datos non están necesariamente unidos estreitamente. Unha API como a API do plano de datos xenérico de Envoy pode formar unha ponte entre dúas partes do sistema.

Nelson e SmartStack axudan a ilustrar aínda máis a separación do plano de control e do plano de datos. Nelson usa Envoy como o seu proxy e constrúe un plano de control fiable para a malla de servizo baseado na pila HashiCorp, é dicir. Nómade, etc. SmartStack foi quizais o primeiro dunha nova onda de mallas de servizo. SmartStack constrúe un plano de control arredor de HAProxy ou NGINX, demostrando a capacidade de desvincular o plano de control da malla de servizo do plano de datos.

A arquitectura de microservizos cunha malla de servizos está a gañar cada vez máis atención (con razón!), e cada vez máis proxectos e provedores comezan a traballar nesta dirección. Durante os próximos anos veremos moita innovación tanto no plano de datos como no plano de control, así como unha maior mestura de diferentes compoñentes. En definitiva, a arquitectura de microservizos debería facerse máis transparente e máxica (?) para o operador.
Esperemos que cada vez menos irritados.

As claves para levar

• Unha malla de servizo consta de dúas partes diferentes: o plano de datos e o plano de control. Os dous compoñentes son necesarios e sen eles o sistema non funcionará.
• Todo o mundo está familiarizado co plano de control e, neste momento, o plano de control podes ser ti!
• Todos os planos de datos compiten entre si en funcións, rendemento, configurabilidade e extensibilidade.
• Todos os planos de control compiten entre si en funcións, configurabilidade, extensibilidade e facilidade de uso.
• Un plano de control pode conter as abstraccións e as API correctas para que se poidan utilizar varios planos de datos.

Fonte: www.habr.com