martes, 17 de abril de 2018

Istio ¿Que es? ¿Por que lo necesitas?


En google cloud español hablamos de Istio usando este articulo  creado por @grapesfrog
¿Qué es Istio? esto es lo que nos dice la web de Istio:

Istio proporciona:
  • Equilibrio de carga automático para tráfico HTTP, gRPC, WebSocket y TCP.
  • Control detallado del comportamiento del tráfico con reglas de enrutamiento, reintentos, failovers e inyección de fallas.
  • Una capa de política conectable y una API de configuración que admite controles de acceso, límites de velocidad y cuotas.
  • Métricas, registros y rastreos automáticos para todo el tráfico dentro de un clúster, incluido el ingress y la salida del clúster.
  • Asegura la autenticación de servicio a servicio con la gestion de identidad entre servicios en un clúster.
Para agreguar soporte de Istio a los servicios mediante la implementación de un "proxy sidecar" especial (un contenedor de ayuda) en su entorno.

Una vez que el "proxy sidecar "está instalado, toda la comunicación de red entre los (micro) servicios se realiza a través de este proxy. Además, toda la comunicación de red se configura y gestiona utilizando la funcionalidad de control de Istio.

Istio es una malla de servicio. La definición que uso cuando pienso en malla de servicio es esta: "Una capa de infraestructura dedicada para hacer que la comunicación de servicio a servicio sea segura, eficiente y confiable"

Sin embargo, si, como yo, comenzaste en los documentos de concepto tienen esto: "El término malla de servicio se usa a menudo para describir la red de microservicios que conforman dichas aplicaciones y las interacciones entre ellas.

Como una malla de servicio crece en tamaño y complejidad, puede ser más difícil de entender y administrar. Sus requisitos pueden incluir descubrimiento, balanceo de carga, recuperación de fallas, métricas y monitoreo, y con frecuencia requisitos operativos más complejos como pruebas A / B, lanzamientos "canarios",  limitación de velocidad, control de acceso y autenticación de extremo a extremo. Istio proporciona una solución completa para satisfacer los diversos requisitos de las aplicaciones de microservicio al proporcionar información de comportamiento y control operacional sobre la malla de servicio en general. "

¡Puede que te hayas confundido como yo después de leer eso! Terminé desviandome y exploré los "interwebs" en lo que era el consenso general con respecto a qué diablos es realmente una malla de servicio. Parece que la definición que uso es, por uso general de mi muestra no representativa, una elección razonable. Pero lo que faltaba era el detalle para separarlo de una herramienta de orquestación como k8s.

Istio se usa junto con K8 y no sería una cosa sin k8s u otras herramientas de orquestación de contenedores. NO hace orquestación y, en realidad, parece estar diseñado para abordar la complejidad operativa y de red de la gestión de grandes soluciones basadas en microservicios. ¡Entonces es una superposición que se añade  a algo así como k8s!.

Entonces sé lo que es Istio y lo que te ofrece, pero ¿a qué desafíos operacionales se está enfrentando en realidad?

Desde el por qué utilizar la página de Istio en sus estados, proporciona una cantidad de capacidades clave uniformemente en una red de servicios:
  • La gestión del tráfico
  • Observabilidad
  • Policy enforcement
  • Servicio de identidad y seguridad

Para que yo realmente entienda el valor de Istio, me pase por este tutorial,  así que usé este gran codelab

El codelab de Istio me presentó los cuatro componentes principales  de control de Istio:
  • Pilot: maneja la configuración y programación de los "sidecares proxy."
  • Mixer: maneja las decisiones de política para su tráfico y reúne telemetría.
  • Ingress: maneja las solicitudes entrantes desde fuera de su clúster.
  • CA: la autoridad de certificación.

Eche un vistazo a la página de conceptos de arquitectura de Istio para entender cómo estos componentes se juntan

El codelab me mostro las router-rules: la parte de traffic mgt

También probé algunas de las diversas tareas de Istio.io, ya que necesitaba entender cómo se trataba con las otras áreas para las que se diseñó.

Sugerencia: mantenga su clúster con la aplicación en funcionamiento si también decide probar mas conceptos fuera del codelab cuando haya terminado. Lo terminarás usándolo de todos modos.

Así que tenía una comprensión rudimentaria de cómo se dirigía a esas áreas, pero si uso un k8 administrado configurado como GKE (bueno, sabías que elegiría eso, ¿verdad?) ¿Cómo encaja Istio en todo caso?

Nota: Sí, hay más detalles de los que cubro aquí, pero me concentro en los aspectos que sentí que me ayudaron a decidir por qué necesitaría usar Istio.

Acceso del desarrollador / usuario final del clúster

GKE usa una combinación de IAM y RBAC, y sí, hay mucho para entender.

Para otorgar más permisos granulados a los usuarios de su clúster que los otorgados por Cloud IAM, usa espacios de nombre y RBAC, por ejemplo, para restringir el acceso a grupos específicos o para excluir el acceso a secretos.

Istio RBAC introduce dos roles centrados en los servicios
  • ServiceRole define un rol para el acceso a servicios en la malla.
  • ServiceRoleBinding otorga un rol a los sujetos (por ejemplo, un usuario, un grupo, un servicio).

Son objetos K8s CustomResourceDefinition (CRD). Y IAM sigue siendo una cosa que debes entender.

Identidad del servicio

GKE puede usar cuentas de servicio para administrar qué servicios de GCP pueden usar las aplicaciones que se ejecutan en GKE. Las claves para estas cuentas de servicio se almacenan como secretos.

La identidad de los procesos que se ejecutan en un pod son las cuentas de servicio de k8  junto con RBAC. Istio usa istio-auth, que proporciona una fuerte autenticación de servicio a servicio y usuario final mediante el uso de TLS mutuo, con una función de administración de identidades y credenciales integrada. Istio-auth usa cuentas de servicio k8s
En la web de Istio hacen un buen trabajo al explicar cómo funciona, así que voy a copiar una pequeña imagen del diagrama de arquitectura aquí.

Imagen de la arquitectura istio-auth

Itsio no proporciona nada para ayudar con el uso de cuentas de servicio GCP. Es muy temprano pero está en la hoja de ruta de los planes para el desarrollo futuro.

Istio-auth es agradable y las mejoras planeadas van a valer la pena esperar. Me inquieta la complejidad de la seguridad, ya que inevitablemente conduce a errores en la configuración, así que espero una alineación más perfecta entre los tipos de cuentas de servicio.

Controles de red

GKE (para k8s versión 1.7.6 +) usa las políticas de red de k8s para administrar qué pods y servicios pueden comunicarse. Esto es relativamente sencillo de configurar. Istio también tiene políticas de red, pero no son las políticas de k8 que usted conoce y usa, ¿cuál es la diferencia y por qué ambas? Esta publicación lo explica bien, así que no repetiré el razonamiento aquí, pero esta tabla resume las diferencias y por qué necesita ambas



Istio usa "envoys" como un "proxy sidecar". Envoy opera en la capa de aplicación del modelo OSI así que en la capa 7 ... Estoy parafraseando que el blog lo explica en detalle.
Necesita ambos tipos de políticas.

Varios clusters

Lo que Istio sí tiene y lo que no está de más es mezclar los adaptadores de red En pocas palabras, se abstraen del backend subyacente para ofrecer funcionalidad básica, como registro, supervisión, cuotas, verificación de ACL y más. Expone una sola API consistente, independiente de los backends en uso. ¡Así como GCS expone una única API independientemente de la clase de almacenamiento que use!

Creo que esta imagen de la publicación del blog sobre el modelo del adaptador mezclador captura en una imagen y explica  el punto de los adaptadores del mezclador




Hay una primera demostración de lo que creo que es una de las características más útiles del potencial de istio que realmente utiliza una máquina virtual para alojar una base de datos MySQL para la base de datos utilizada en el codelab e incorporar eso como parte de la malla que el clúster GKE es miembro de. Una malla para gobernarlos a todos (¡sé que no puedo evitarlo!)

La gestión del tráfico

Si hiciste el codelab habrás visto lo fácil que era usar istio para dirigir el tráfico usando reglas de ruta. Con K8 también puede gestionar el tráfico mediante implementaciones "canarias" y dirigir una parte del tráfico a una versión de su aplicación de manera similar a istio, pero Istio es mucho más flexible en este caso al permitirle establecer porcentajes de tráfico detallados y controlar el tráfico. usando otros criterios como en el laboratorio de códigos.

Descubrimiento de servicio

El registro del servicio se realiza en k8s. Istio abstrae los mecanismos subyacentes de descubrimiento de servicios y los conforma en un formato de consumibles estándar por parte de los sidecars enviados.

Audit Logging y monitoreo

Más allá del registro estándar que proporciona GKE, GKE puede integrarse con StackDriver Logging para recopilar, procesar y almacenar de forma persistente registros de contenedores, registros del sistema y eventos sobre la actividad en el clúster, como la programación de Pods. También puede integrarse con StackDriver Monitoring para recopilar las métricas del sistema (mediciones de la infraestructura del clúster, como el uso de la CPU o de la memoria) y las métricas personalizadas (métricas específicas de la aplicación).

Istio hace uso de prometheus para registrar y monitorear junto con grafana como front-end de presentación de datos. Me encanta la configuración del gráfico de servicio que le da una representación gráfica de su malla de servicio. También puede usar Elasticsearch con kibana y fluentd

Entonces, ¿necesito Istio?

Istio's traffic mgt es realmente agradable y el modelo de adaptador que mezcla y facilita la gestión de una malla que cubre múltiples clústeres y máquinas virtuales. Me gusta que Istio haga que pienses en los servicios y no tanto en pods y nodos, sin decir que no tienes que preocuparte por ellos, ¡pero hablar de servicios parece correcto!

Si necesita administrar un clúster distribuido, entonces Istio debe estar en su lista de compras. Si necesita más flexibilidad con traffic mgt de lo que los k8s pueden ofrecer nuevamente, Istio valdría la pena examinarlo.

Si tiene los recursos para jugar con algo que se encuentra en un estado de inicio de desarrollo, entonces vale la pena comprender el Istio. La curva de aprendizaje es baja si ya usa k8s.

Recuerde que es una superposición, por lo que aún necesita hacer cosas en la capa de k8, como configurar las políticas de red de k8 para complementar las políticas de red de istio.

Es pronto, así que no hace todas las cosas que esperarías / espero que lo haga aún. No puede evitar intercambiar las API de proveedor e Istio para realizar un trabajo completo.

¡Un dashboar sería bueno para visualizar la configuración de malla ya que del YAML se cansará uno rápidamente! Sí, puede configurar cuadros de mando para visualizar las métricas con la aplicación de dashboar que prefiera, pero me gustaría verla integrada con StackDriver

Conclusion , después de aprender un poco sobre Istio en general, me gusta lo que promete.