Istio e Kubernetes en produción. Parte 2. Trazado

No último Artigo Observamos os compoñentes básicos de Service Mesh Istio, familiarizamos co sistema e respondemos ás principais preguntas que adoitan xurdir ao comezar a traballar con Istio. Nesta parte veremos como organizar a recollida de información de rastrexo nunha rede.

O primeiro que se lles ocorre a moitos desenvolvedores e administradores de sistemas cando escoitan as palabras Service Mesh é rastrexar. De feito, engadimos un servidor proxy especial a cada nodo de rede polo que pasa todo o tráfico TCP. Parece que agora é posible enviar facilmente información sobre todas as interaccións da rede na rede. Desafortunadamente, en realidade hai moitos matices que hai que ter en conta. Mirámolos.

Equívoco número un: podemos obter datos de sendeirismo en liña de balde.

De feito, de xeito relativamente gratuíto, só podemos conectar os nodos do noso sistema mediante frechas e a velocidade de datos que pasa entre os servizos (de feito, só o número de bytes por unidade de tempo). Non obstante, na maioría dos casos, os nosos servizos comunícanse mediante algún tipo de protocolo de capa de aplicación, como HTTP, gRPC, Redis, etc. E, por suposto, queremos ver información de rastrexo específicamente para estes protocolos; queremos ver a taxa de solicitude, non a taxa de datos. Queremos comprender a latencia das solicitudes mediante o noso protocolo. Finalmente, queremos ver o camiño completo que leva unha solicitude desde o inicio de sesión no noso sistema ata a recepción dunha resposta do usuario. Este problema xa non é tan fácil de resolver.

En primeiro lugar, vexamos como son os trazados de envío desde o punto de vista arquitectónico en Istio. Como lembramos desde a primeira parte, Istio ten un compoñente separado chamado Mixer para recoller telemetría. Non obstante, na versión actual 1.0.*, o envío realízase directamente desde servidores proxy, é dicir, desde o proxy de envoy. O proxy de Envoy admite o envío de intervalos de rastrexo usando o protocolo zipkin fóra da caixa. É posible conectar outros protocolos, pero só a través dun complemento. Con Istio recibimos inmediatamente un proxy enviado montado e configurado, que só admite o protocolo zipkin. Se queremos usar, por exemplo, o protocolo Jaeger e enviar tramos de trazado a través de UDP, necesitaremos construír a nosa propia imaxe istio-proxy. Hai soporte para complementos personalizados para istio-proxy, pero aínda está na versión alfa. Polo tanto, se queremos prescindir dunha gran cantidade de configuracións personalizadas, a gama de tecnoloxías utilizadas para almacenar e recibir espazos de trazado redúcese. Dos sistemas principais, de feito, agora podes usar o propio Zipkin, ou Jaeger, pero envialo todo alí usando o protocolo compatible con zipkin (que é moito menos eficiente). O propio protocolo zipkin implica o envío de toda a información de rastrexo aos recolectores a través do protocolo HTTP, que é bastante caro.

Como xa dixen, queremos rastrexar protocolos a nivel de aplicación. Isto significa que os servidores proxy que están xunto a cada servizo deben comprender que tipo de interacción está a suceder agora. Por defecto, Istio configura todos os portos para que sexan TCP simples, o que significa que non se enviarán rastros. Para que se envíen rastrexos, debes, en primeiro lugar, activar esta opción na configuración da malla principal e, o que é moi importante, nomear todos os portos das entidades do servizo kubernetes de acordo co protocolo que se utiliza no servizo. Isto é, por exemplo, así:

apiVersion: v1
kind: Service
metadata:
  name: nginx
spec:
  ports:
  - port: 80
    targetPort: 80
    name: http
  selector:
    app: nginx

Tamén pode usar nomes compostos como http-magic (Istio verá http e recoñecerá ese porto como un punto final http). O formato é: proto-extra.

Para non parchear unha gran cantidade de configuracións para determinar o protocolo, podes usar unha solución sucia: parchear o compoñente Pilot no momento en que só está realiza a lóxica de definición do protocolo. Ao final, por suposto, será necesario cambiar esta lóxica a estándar e cambiar a unha convención de nomenclatura para todos os portos.

Para comprender se o protocolo está realmente definido correctamente, cómpre entrar en calquera dos contenedores sidecar con proxy de Envoy e facer unha solicitude ao porto de administración da interface de Envoy coa localización /config_dump. Na configuración resultante, cómpre mirar o campo de operación do servizo desexado. Utilízase en Istio como identificador de onde se realiza a solicitude. Para personalizar o valor deste parámetro en Istio (logo verémolo no noso sistema de rastrexo), é necesario especificar a bandeira serviceCluster na fase de lanzamento do contedor sidecar. Por exemplo, pódese calcular así a partir de variables obtidas da API descendente de kubernetes:

--serviceCluster ${POD_NAMESPACE}.$(echo ${POD_NAME} | sed -e 's/-[a-z0-9]*-[a-z0-9]*$//g')

Un bo exemplo para entender como funciona o rastrexo en enviado aquí.

O propio punto final para enviar intervalos de rastrexo tamén se debe especificar nas marcas de inicio do proxy de Envoy, por exemplo: --zipkinAddress tracing-collector.tracing:9411

Equívoco número dous: podemos obter de xeito económico trazos completos de solicitudes a través do sistema fóra da caixa

Desafortunadamente, non é así. A complexidade da implementación depende de como xa implementou a interacción dos servizos. Por que é iso?

O caso é que para que istio-proxy poida entender a correspondencia das solicitudes entrantes a un servizo coas que saen do mesmo servizo, non abonda con simplemente interceptar todo o tráfico. Necesitas ter algún tipo de identificador de comunicación. O proxy HTTP Envoy utiliza cabeceiras especiais, mediante as cales Envoy entende que solicitude específica ao servizo xera solicitudes específicas a outros servizos. Lista de devanditos encabezados:

• x-request-id,
• x-b3-traceid,
• x-b3-spanid,
• x-b3-parentspanid,
• x-b3-mostrado,
• x-b3-bandeiras,
• x-ot-span-context.

Se tes un único punto, por exemplo, un cliente básico, no que podes engadir esa lóxica, entón todo está ben, só tes que esperar a que esta biblioteca se actualice para todos os clientes. Pero se tes un sistema moi heteroxéneo e non hai unificación para pasar dun servizo a outro a través da rede, é probable que isto sexa un gran problema. Sen engadir esa lóxica, toda a información de rastrexo será só de "nivel único". É dicir, recibiremos todas as interaccións entre servizos, pero non estarán pegadas en cadeas de paso únicas pola rede.

Conclusión

Istio ofrece unha ferramenta conveniente para recoller información de rastrexo nunha rede, pero debes entender que para a súa implementación terás que adaptar o teu sistema e ter en conta as características da implementación de Istio. Como resultado, hai que resolver dous puntos principais: definir o protocolo de nivel de aplicación (que debe ser compatible co proxy de envoy) e configurar o reenvío de información sobre a conexión de solicitudes ao servizo a partir das solicitudes do servizo (utilizando cabeceiras). , no caso do protocolo HTTP). Cando se resolven estes problemas, dispoñemos dunha poderosa ferramenta que nos permite recoller información da rede de forma transparente, incluso en sistemas moi heteroxéneos escritos en moitas linguaxes e marcos diferentes.

No seguinte artigo sobre Service Mesh, analizaremos un dos maiores problemas con Istio: o gran consumo de RAM de cada contedor de proxy sidecar e analizaremos como podes xestionalo.

Fonte: www.habr.com