En el último
artículo, examinamos los componentes básicos de Service Mesh Istio, nos familiarizamos con el sistema y respondimos las preguntas básicas que generalmente surgen al comienzo del trabajo con Istio. En esta parte veremos cómo organizar la recopilación de información de rastreo a través de la red.
Lo primero que encuentran muchos desarrolladores y administradores de sistemas cuando escuchan las palabras que rastrea Service Mesh. De hecho, agregamos un servidor proxy especial a cada nodo de red a través del cual pasa todo el tráfico TCP. Parece que ahora puede enviar fácilmente información sobre todas las interacciones de red en la red. Desafortunadamente, en realidad hay muchos matices que deben tenerse en cuenta. Miremos a ellos.
Concepto erróneo número uno: podemos obtener datos sobre viajes a través de la red de forma gratuita
De hecho, relativamente gratis, solo podemos conectar los nodos de nuestro sistema mediante flechas y la velocidad de datos que pasa entre los servicios (de hecho, solo el número de bytes por unidad de tiempo). Sin embargo, en la mayoría de los casos, nuestros servicios se comunican mediante algún tipo de protocolo de nivel de aplicación, como HTTP, gRPC, Redis, etc. Y, por supuesto, queremos ver la información de rastreo precisamente de acuerdo con estos protocolos, queremos ver la tasa de solicitudes, no la tasa de datos. Queremos entender la latencia de las solicitudes de nuestro protocolo. Finalmente, queremos ver la ruta completa por la que pasa la solicitud desde que ingresa a nuestro sistema hasta que recibe una respuesta del usuario. Este problema no se resuelve tan fácilmente.
Para comenzar, veamos cómo se ve el envío de trazos de rastreo desde el punto de vista de la arquitectura en Istio. Como recordamos de la primera parte, Istio tiene un componente separado para recolectar telemetría, que se llama Mixer. Sin embargo, en la versión actual 1.0. * El envío se realiza directamente desde servidores proxy, es decir, con proxy enviado. El proxy de Envoy admite el envío de tramos de rastreo a través del protocolo zipkin fuera de la caja. Se pueden conectar otros protocolos, pero solo a través del complemento. Con Istio, obtenemos inmediatamente el proxy enviado enviado y configurado, que solo admite el protocolo zipkin. Si queremos utilizar, por ejemplo, el protocolo Jaeger y enviar tramos de rastreo a través de UDP, entonces necesitaremos ensamblar nuestra imagen de istio-proxy. Hay soporte para complementos personalizados para istio-proxy, sin embargo, todavía está en la versión alfa. Por lo tanto, si queremos prescindir de una gran cantidad de configuraciones personalizadas, la gama de tecnologías utilizadas para almacenar y recibir tramos de rastreo se reduce. De hecho, de los sistemas principales, ahora puede usar Zipkin, o Jaeger, pero enviar todo allí usando un protocolo compatible con Zipkin (que es mucho menos eficiente). El protocolo zipkin implica enviar toda la información de rastreo a los recolectores que utilizan el protocolo HTTP, que es bastante costoso.
Como dije, queremos rastrear protocolos a nivel de aplicación. Y esto significa que los servidores proxy que están al lado de cada servicio deben comprender qué tipo de interacción está ocurriendo ahora. De manera predeterminada, Istio establece el tipo para todos los puertos TCP simples, lo que significa que no se enviarán seguimientos. Para poder enviar rastreos, primero debe habilitar esta opción en la configuración de malla principal y, lo que es más importante, cambiar el nombre de todos los puertos de las entidades de servicio kubernetes de acuerdo con el protocolo utilizado en el servicio. Es decir, por ejemplo, así:
apiVersion: v1 kind: Service metadata: name: nginx spec: ports: - port: 80 targetPort: 80 name: http selector: app: nginx
También puede usar nombres compuestos, como http-magic (Istio ve http y reconoce este puerto como punto final http). El formato es: proto-extra.
Para no parchear una gran cantidad de configuraciones para definir un protocolo, puede usar una solución alternativa sucia: parchear un componente Pilot en un momento en que solo
ejecuta la lógica de definición de protocolo . Al final, por supuesto, necesitará cambiar esta lógica a estándar e ir a la convención de nomenclatura para todos los puertos.
Para entender si el protocolo está realmente definido correctamente, debe ingresar a cualquiera de los contenedores de sidecar con proxy enviado y realizar una solicitud al puerto de administración de la interfaz de enviado con location / config_dump. En la configuración resultante, debe mirar la operación de campo de servicio deseada. Se usa en Istio como un identificador de a dónde va la solicitud. Para personalizar el valor de este parámetro en Istio (luego lo veremos en nuestro sistema de rastreo), es necesario especificar el indicador serviceCluster en la etapa de lanzamiento del contenedor del sidecar. Por ejemplo, se puede calcular así a partir de variables obtenidas de los kubernetes API hacia abajo:
--serviceCluster ${POD_NAMESPACE}.$(echo ${POD_NAME} | sed -e 's/-[a-z0-9]*-[a-z0-9]*$//g')Aquí hay un buen ejemplo para comprender cómo funciona el rastreo en el enviado.
El punto final en sí mismo para enviar tramos de rastreo también debe especificarse en los indicadores de inicio del proxy del enviado, por ejemplo:
--zipkinAddress tracing-collector.tracing:9411Concepto erróneo número dos: podemos obtener de forma económica los rastros completos de la aprobación de solicitudes para el sistema
Lamentablemente, esto no es así. La complejidad de la implementación depende de cómo ya haya implementado la interacción de los servicios. Por qué
El hecho es que para que istio-proxy comprenda la correspondencia de las solicitudes entrantes a un servicio con las que provienen del mismo servicio, no es suficiente solo interceptar todo el tráfico. Necesita tener algún tipo de identificador de enlace. El proxy HTTP de Envoy utiliza encabezados especiales, según los cuales el enviado comprende qué solicitud de servicio en particular genera solicitudes específicas para otros servicios. Lista de tales encabezados:
- x-request-id,
- x-b3-traceid,
- x-b3-spanid,
- x-b3-parentspanid,
- x-b3-muestreado,
- x-b3-flags,
- x-ot-span-context.
Si tiene un solo punto, por ejemplo, un cliente base donde puede agregar dicha lógica, entonces todo está bien, solo necesita esperar a que todos los clientes actualicen esta biblioteca. Pero si tiene un sistema muy heterogéneo y no hay unificación en la campaña de los servicios a los servicios a través de la red, lo más probable es que este sea un gran problema. Sin la adición de dicha lógica, toda la información de rastreo será solo "hermana". Es decir, obtenemos todas las interacciones entre servicios, pero no se unirán en una sola cadena de paso a través de la red.
Conclusión
Istio proporciona una herramienta conveniente para recopilar información de rastreo a través de la red, sin embargo, debe comprender que para la implementación deberá adaptar su sistema y tener en cuenta las características de la implementación de Istio. Como resultado, debe resolver dos puntos principales: determinar el protocolo de la capa de aplicación (que debe ser compatible con el proxy enviado) y configurar el reenvío de información sobre la conectividad de las solicitudes al servicio a partir de las solicitudes del servicio (utilizando encabezados, en el caso del protocolo HTTP). Cuando se resuelven estos problemas, obtenemos una herramienta poderosa que le permite recopilar información de la red de forma transparente, incluso en sistemas muy heterogéneos escritos en muchos idiomas y marcos diferentes.
En el próximo artículo sobre Service Mesh, consideraremos uno de los mayores problemas de Istio: el alto consumo de memoria de cada contenedor proxy de sidecar y discutiremos cómo lidiar con él.