Cómo iniciar Istio usando Kubernetes en producción. Parte 1

¿Qué es istio ? Esta es la denominada malla de servicio, una tecnología que agrega una capa de abstracción a través de la red. Interceptamos todo o parte del tráfico en el clúster y realizamos un conjunto específico de operaciones con él. Cual? Por ejemplo, hacemos enrutamiento inteligente, o implementamos el enfoque de interruptor de circuito, podemos organizar un "despliegue canario", cambiando parcialmente el tráfico a una nueva versión del servicio, y podemos limitar las interacciones externas y controlar todos los viajes desde el clúster a la red externa. Es posible establecer reglas de política para controlar campañas entre diferentes microservicios. Finalmente, podemos obtener el mapa completo de interacción a través de la red y hacer que la colección unificada de métricas sea completamente transparente para las aplicaciones.

Sobre el mecanismo de trabajo se puede encontrar en la documentación oficial . Istio es una herramienta realmente poderosa que puede resolver muchos problemas y problemas. En este artículo, me gustaría responder las preguntas básicas que generalmente surgen al comienzo del trabajo con Istio. Esto te ayudará a lidiar con eso más rápido.

Principio de funcionamiento

Istio consta de dos zonas principales: plano de control y plano de datos. El plano de control contiene los componentes principales que aseguran el correcto funcionamiento del resto. En la versión actual (1.0), el plano de control tiene tres componentes principales: Piloto, Mezclador, Ciudadela. No consideraremos Citadel, es necesario generar certificados para garantizar TLS mutuo entre servicios. Echemos un vistazo más de cerca al dispositivo y al propósito del Pilot and Mixer.



Pilot es el principal componente de control que difunde toda la información sobre lo que tenemos en el clúster: servicios, sus puntos finales y reglas de enrutamiento (por ejemplo, reglas para el despliegue de Canarias o reglas de disyuntores).

Mezclador: un componente opcional del plano de control, que proporciona la capacidad de recopilar métricas, registros y cualquier información sobre interacciones de red. También supervisa el cumplimiento de las normas de la Política y el cumplimiento de los límites de las tarifas.

El plano de datos se implementa utilizando contenedores proxy de sidecar. Por defecto, se utiliza el poderoso servidor proxy enviado . Se puede reemplazar por otra implementación, por ejemplo nginx (nginmesh).

Para que Istio funcione de forma completamente transparente para las aplicaciones, existe un sistema de inyección automática. La última implementación es adecuada para versiones de Kubernetes 1.9+ (webhook de admisión mutacional). Para las versiones de Kubernetes 1.7, 1.8, es posible utilizar Initializer.

Los contenedores de sidecar se conectan al Pilot a través del protocolo GRPC, que permite optimizar el modelo de impulsar los cambios que ocurren en el clúster. GRPC comenzó a usarse en Envoy desde la versión 1.6, en Istio se ha usado desde la versión 0.8 y es un agente piloto, un contenedor en golang sobre enviado, que configura los parámetros de lanzamiento.

Pilot y Mixer son componentes completamente sin estado, todo el estado se guarda en la memoria. La configuración para ellos se especifica como Recursos personalizados de Kubernetes, que se guardan en etcd.
Istio-agent recibe la dirección piloto y le abre una secuencia GRPC.

Como dije, Istio implementa toda la funcionalidad completamente transparente para las aplicaciones. Veamos cómo. El algoritmo es el siguiente:

1. Implemente una nueva versión del servicio.
2. Dependiendo del enfoque de inyectar el contenedor de sidecar, se agregan un contenedor de istio-init y un contenedor de istio-agent (enviado) en la etapa de aplicación de la configuración, o ya se pueden insertar manualmente en la descripción Pod de la entidad Kubernetes.
3. El contenedor istio-init es un script que aplica las reglas de iptables para el hogar. Hay dos opciones para configurar el ajuste de tráfico en el contenedor de agente de istio: use las reglas de redireccionamiento de iptables, o TPROXY . Al momento de escribir, se utiliza el enfoque predeterminado con reglas de redireccionamiento. En istio-init es posible configurar qué tráfico necesita ser interceptado y enrutado a istio-agent. Por ejemplo, para interceptar todo el tráfico entrante y saliente, debe establecer los parámetros -i y -b en * . Puede especificar puertos específicos para ser interceptados. Para no interceptar una subred específica, puede especificarla utilizando el indicador -x .
4. Después de la ejecución de los contenedores init, se lanzan los principales, incluido el agente piloto (enviado). Se conecta al Pilot ya implementado a través de GRPC y recibe información sobre todos los servicios existentes y las políticas de enrutamiento en el clúster. Según los datos recibidos, configura los clústeres y les asigna directamente los puntos finales de nuestras aplicaciones en el clúster de Kubernetes. También vale la pena señalar un punto importante: el enviado configura dinámicamente los oyentes (IP, pares de puertos) que comienza a escuchar. Por lo tanto, cuando las solicitudes ingresan al pod, se redirigen usando las reglas de redireccionamiento de iptables en el sidecar, el enviado ya puede procesar con éxito estas conexiones y comprender dónde enviar el tráfico. También en esta etapa, se envía información al Mezclador, que discutiremos más adelante, y se envían tramos de rastreo.

Como resultado, obtenemos una red completa de servidores proxy enviados, que podemos configurar desde un punto (piloto). Todas las solicitudes entrantes y salientes pasan por enviado. Además, solo se intercepta el tráfico TCP. Esto significa que la dirección IP del servicio Kubernetes se resuelve usando kube-dns sobre UDP sin cambiar. Luego, después de resolver, la solicitud saliente es interceptada y procesada por un enviado, que ya decide a qué punto final enviar la solicitud (o no, en el caso de políticas de acceso o algoritmos de disparo del interruptor automático).

Con Pilot resuelto, ahora necesita comprender cómo funciona el Mezclador y por qué es necesario. Puedes leer la documentación oficial aquí .

El mezclador en su forma actual tiene dos componentes: istio-telemetría, istio-policy (antes de la versión 0.8 era un componente de istio-mixer). Ambos son mezcladores, cada uno de los cuales es responsable de su tarea. La telemetría de Istio recibe a través de GRPC desde el sidecar. Informe de contenedores sobre quién va a dónde y con qué parámetros. Istio-policy acepta solicitudes de verificación para verificar si se cumplen las reglas de la política. Las comprobaciones de Poilicy se llevan a cabo, por supuesto, no para cada solicitud, sino que se almacenan en caché en el cliente (en sidecar) durante un tiempo determinado. Las verificaciones de informes se envían por solicitudes por lotes. Más adelante veremos cómo configurar y qué parámetros necesita enviar.

Se supone que Mixer es un componente de alta disponibilidad que proporciona trabajo ininterrumpido en la recopilación y procesamiento de datos de telemetría. El sistema resulta como un búfer multinivel. Inicialmente, los datos se almacenan en el lado del sidecar de los contenedores, luego en el lado del mezclador y luego se envían a los llamados backends del mezclador. Como resultado, si alguno de los componentes del sistema falla, el búfer crece y se bloquea después de la recuperación del sistema. Los backends del mezclador son los puntos finales para enviar datos de telemetría: statsd, newrelic, etc. Puede escribir su backend, es bastante simple y veremos cómo hacerlo.



En resumen, el esquema de trabajo con istio-telemetría es el siguiente.

1. El servicio 1 envía una solicitud al servicio 2.
2. Al salir del servicio 1, la solicitud se envuelve en su propio sidecar.
3. El enviado Sidecar monitorea cómo pasa la solicitud de servicio 2 y prepara la información necesaria.
4. Luego lo envía a istio-telemetría utilizando la solicitud de informe.
5. Istio-telemetry determina si se debe enviar este Informe a los servidores, a qué datos y qué datos enviar.
6. Istio-telemetry envía los datos del Informe al backend si es necesario.

Ahora veamos cómo implementar en el sistema Istio, que consta solo de los componentes principales (piloto y enviado de sidecar).

Primero, veamos la configuración principal (malla) que Pilot lee:

 apiVersion: v1 kind: ConfigMap metadata: name: istio namespace: istio-system labels: app: istio service: istio data: mesh: |- #      tracing  (pilot  envoy'  ,     ) enableTracing: false #     mixer endpoint',  sidecar      #mixerCheckServer: istio-policy.istio-system:15004 #mixerReportServer: istio-telemetry.istio-system:15004 #   ,    envoy  Pilot (    envoy proxy) rdsRefreshDelay: 5s # default   envoy sidecar defaultConfig: #   rdsRefreshDelay discoveryRefreshDelay: 5s #    (     envoy) configPath: "/etc/istio/proxy" binaryPath: "/usr/local/bin/envoy" #    sidecar  (, ,      tracing span') serviceCluster: istio-proxy # ,    envoy  ,        drainDuration: 45s parentShutdownDuration: 1m0s #    REDIRECT  iptables.    TPROXY. #interceptionMode: REDIRECT # ,     admin   sidecar  (envoy) proxyAdminPort: 15000 # ,     trace'  zipkin  (     ,       ) zipkinAddress: tracing-collector.tracing:9411 # statsd     envoy  () # statsdUdpAddress: aggregator:8126 #    Mutual TLS controlPlaneAuthPolicy: NONE # ,     istio-pilot  ,     service discovery  sidecar  discoveryAddress: istio-pilot.istio-system:15007 

Todos los componentes principales del plano de control se encuentran en el espacio de nombres istio-system en Kubernetes.

Como mínimo necesitamos desplegar solo Pilot. Para hacer esto, usaremos esta configuración.

Y configure manualmente el sidecar de inyección del contenedor.

Contenedor de inicio:

 initContainers: - name: istio-init args: - -p - "15001" - -u - "1337" - -m - REDIRECT - -i - '*' - -b - '*' - -d - "" image: istio/proxy_init:1.0.0 imagePullPolicy: IfNotPresent resources: limits: memory: 128Mi securityContext: capabilities: add: - NET_ADMIN 

Y sidecar:

  name: istio-proxy args: - "bash" - "-c" - | exec /usr/local/bin/pilot-agent proxy sidecar \ --configPath \ /etc/istio/proxy \ --binaryPath \ /usr/local/bin/envoy \ --serviceCluster \ service-name \ --drainDuration \ 45s \ --parentShutdownDuration \ 1m0s \ --discoveryAddress \ istio-pilot.istio-system:15007 \ --discoveryRefreshDelay \ 1s \ --connectTimeout \ 10s \ --proxyAdminPort \ "15000" \ --controlPlaneAuthPolicy \ NONE env: - name: POD_NAME valueFrom: fieldRef: fieldPath: metadata.name - name: POD_NAMESPACE valueFrom: fieldRef: fieldPath: metadata.namespace - name: INSTANCE_IP valueFrom: fieldRef: fieldPath: status.podIP - name: ISTIO_META_POD_NAME valueFrom: fieldRef: fieldPath: metadata.name - name: ISTIO_META_INTERCEPTION_MODE value: REDIRECT image: istio/proxyv2:1.0.0 imagePullPolicy: IfNotPresent resources: requests: cpu: 100m memory: 128Mi limits: memory: 2048Mi securityContext: privileged: false readOnlyRootFilesystem: true runAsUser: 1337 volumeMounts: - mountPath: /etc/istio/proxy name: istio-envoy 

Para que todo se inicie correctamente, debe obtener ServiceAccount, ClusterRole, ClusterRoleBinding, CRD for Pilot, cuyas descripciones se pueden encontrar aquí .

Como resultado, el servicio en el que inyectamos el sidecar enviado debe comenzar con éxito, obtener todo el descubrimiento del piloto y procesar las solicitudes.

Es importante comprender que todos los componentes del plano de control son aplicaciones sin estado y pueden escalarse horizontalmente sin ningún problema. Todos los datos están en etcd como descripciones personalizadas de los recursos de Kubernetes.

Istio también (hasta ahora experimentalmente) tiene la capacidad de ejecutarse fuera del clúster y la capacidad de observar y buscar el descubrimiento de servicios entre varios clústeres de Kubernetes. Puedes leer más sobre esto aquí .

Para una instalación de múltiples clústeres, se deben considerar las siguientes restricciones:

1. Pod CIDR y Service CIDR deben ser únicos en todos los clústeres y no deben superponerse.
2. Todos los CIDR de Pod deben estar disponibles desde cualquier CIDR de Pod entre clústeres.
3. Todos los servidores API de Kubernetes deben ser accesibles entre sí.

Esta es la información inicial para ayudarlo a comenzar con Istio. Sin embargo, todavía hay muchas trampas. Por ejemplo, características de enrutamiento de tráfico externo (hacia el exterior del clúster), enfoques para depurar los sidecar, perfilar, configurar un mezclador y escribir un backend de mezclador personalizado, configurar un mecanismo de rastreo y su operación usando enviado.
Consideraremos todo esto en las siguientes publicaciones. Haga sus preguntas, intentaré cubrirlas.