Istio: En marcha

Capítulo 1. Presentación de la Malla de Servicios

Este trabajo se ha traducido utilizando IA. Agradecemos tus opiniones y comentarios: [e-mail]

¿Qué es una malla de servicios?

Las mallas de servicios proporcionan servicios de red basados en políticas para las cargas de trabajo conectadas a la red, imponiendo el comportamiento deseado de la red ante condiciones y topología que cambian constantemente. Las condiciones que cambian pueden ser la carga, la configuración, los recursos (incluidos los que afectan a la topología de la infraestructura y la aplicación de los recursos intracluster e intercluster que entran y salen) y las cargas de trabajo que se despliegan.

Fundamentos

Las mallas de servicios son una capa de infraestructura direccionable que te permite gestionar tanto la modernización de las cargas de trabajo monolíticas (o de otro tipo) existentes como la expansión de los microservicios. Las mallas de servicios son una capa de infraestructura direccionable llevada a pleno rendimiento. Son beneficiosas en entornos monolíticos, pero culparemos al movimiento de microservicios y contenedores -el enfoque nativo de la nube para diseñar servicios escalables y suministrados de forma independiente- de su rápida aparición. Los microservicios han hecho estallar lo que eran comunicaciones internas de aplicaciones en una malla de llamadas a procedimientos remotos (RPC) de servicio a servicio transportadas a través de redes. Entre sus muchas ventajas, los microservicios democratizan la elección del lenguaje y la tecnología entre equipos de servicio independientes, equipos que crean nuevas funciones rápidamente a medida que entregan software de forma iterativa y continua (normalmente como servicio).

Siendo tan vasto el campo de las redes, no es de extrañar que haya muchas diferencias sutiles y casi imperceptibles entre conceptos similares. En esencia, las mallas de servicios proporcionan una red impulsada por el desarrollador, que da prioridad a los servicios: una red cuyo objetivo principal es evitar que los desarrolladores de aplicaciones tengan que incorporar en su código aspectos relacionados con la red (por ejemplo, la capacidad de recuperación); y una red que permite a los operadores definir de forma declarativa el comportamiento de la red, la identidad de los nodos y el flujo de tráfico mediante políticas.

Podría parecer la reencarnación de las redes definidas por software (SDN), pero las mallas de servicios se diferencian sobre todo por su énfasis en un enfoque centrado en el desarrollador, no en el administrador de red. En su mayor parte, las mallas de servicios actuales se basan enteramente en software (aunque podrían llegar implementaciones basadas en hardware). Aunque el término red basada en la intención se utiliza sobre todo en redes físicas, dado el control declarativo basado en políticas que proporcionan las mallas de servicios, es justo comparar una malla de servicios con una SDN nativa de la nube. La Figura 1-1 muestra una visión general de la arquitectura de la malla de servicios. (En el Capítulo 2 explicamos lo que significa ser nativo de la nube).

Figura 1-1. Si no tiene plano de control, no es una malla de servicio.

Las mallas de servicio se construyen utilizando proxies de servicio. Los proxies de servicio del plano de datos transportan el tráfico. El tráfico se intercepta de forma transparente utilizando reglas iptable en el espacio de nombres del pod.

Esta capa uniforme de infraestructura combinada con implementaciones de servicios se denomina comúnmente malla de servicios. Istio convierte microservicios dispares en una malla de servicios integrada inyectando sistémicamente un proxy entre todas las rutas de red, haciendo que cada proxy conozca a los demás, y poniéndolos bajo control centralizado; formando así una malla de servicios.

Navegar hacia una malla de servicios

Tanto si el reto al que te enfrentas es la gestión de una flota de microservicios como la modernización de tus servicios existentes no contenedorizados, puedes encontrarte navegando en una malla de servicios. Cuantos más microservicios se implementen, mayores serán estos retos.

Bibliotecas de clientes: ¿Las Primeras Mallas de Servicio?

Para hacer frente a la complicada tarea de gestionar microservicios, algunas organizaciones han empezado a utilizar bibliotecas de clientes como marcos para estandarizar las implementaciones. Algunos consideran que estas bibliotecas son las primeras mallas de servicios. La Figura 1-2 ilustra cómo el uso de una biblioteca requiere que tu arquitectura tenga código de aplicación que amplíe o utilice primitivas de la(s) biblioteca(s) elegida(s). Además, tu arquitectura necesita acomodar el uso potencial de múltiples marcos de trabajo específicos del lenguaje y/o servidores de aplicaciones para ejecutarlos.

Figura 1-2. Arquitectura de servicios que utiliza bibliotecas cliente acopladas a la lógica de la aplicación

Las dos ventajas de al crear bibliotecas de clientes son que los recursos consumidos se contabilizan localmente para todos y cada uno de los servicios, y que los desarrolladores pueden elegir por sí mismos entre una biblioteca existente o crear una nueva biblioteca específica para el lenguaje. Con el tiempo, sin embargo, las desventajas de utilizar bibliotecas cliente hicieron que surgieran las mallas de servicios. Su inconveniente más significativo es el estrecho acoplamiento de los problemas de infraestructura con el código de la aplicación. El diseño no uniforme y específico del lenguaje de las bibliotecas cliente hace que su funcionalidad y comportamiento sean incoherentes, lo que da lugar a características de observabilidad deficientes, prácticas a medida para aumentar los servicios que son más o menos controlables entre sí, y una seguridad posiblemente comprometida. La adopción al por mayor de estas bibliotecas de resiliencia específicas de un lenguaje puede resultar costosa para las organizaciones, y pueden ser difíciles de encajar en aplicaciones "brownfield" o totalmente impracticables de incorporar a las arquitecturas existentes.

Trabajar en red es difícil. Crear una biblioteca cliente que elimine la contención del cliente introduciendo fluctuaciones y un algoritmo de retroceso exponencial en el cálculo del tiempo del siguiente intento de reintento no es necesariamente fácil, como tampoco lo es intentar garantizar el mismo comportamiento en diferentes bibliotecas cliente (con los distintos lenguajes y versiones de esas bibliotecas). Coordinar las actualizaciones de las bibliotecas cliente es difícil en entornos grandes, ya que las actualizaciones requieren cambios de código, lanzar una nueva versión de la aplicación y, potencialmente, tiempo de inactividad de la aplicación.

La Figura 1-3 muestra cómo con un proxy de servicio junto a cada instancia de aplicación, las aplicaciones ya no necesitan disponer de bibliotecas de resiliencia específicas del lenguaje para la ruptura de circuitos, tiempos de espera, reintentos, descubrimiento de servicios, equilibrio de carga, etc. Las mallas de servicios parecen cumplir la promesa de que las organizaciones que implementan microservicios podrían por fin hacer realidad el sueño de utilizar los mejores marcos y lenguajes para sus trabajos individuales, sin preocuparse por la disponibilidad de bibliotecas y patrones para cada plataforma.

Figura 1-3. Arquitectura de servicios que utiliza proxies de servicio desacoplados de la lógica de la aplicación

¿Por qué necesitas uno?

Llegados a este punto, puede que estés pensando: "Tengo un orquestador de contenedores. ¿Por qué necesito otra capa de infraestructura?". Con la generalización de los microservicios y los contenedores, los orquestadores de contenedores proporcionan gran parte de lo que necesita el clúster (nodos y contenedores). Se centran en gran medida en la programación, el descubrimiento y la salud, principalmente a nivel de infraestructura (necesariamente), dejando a los microservicios con necesidades no cubiertas a nivel de servicio. Una malla de servicios es una capa de infraestructura dedicada a hacer que la comunicación entre servicios sea segura, rápida y fiable, que a veces depende de un orquestador de contenedores o de la integración con otro sistema de descubrimiento de servicios. Las mallas de servicios pueden desplegarse como una capa separada sobre los orquestadores de contenedores, pero no los necesitan, ya que los componentes del plano de control y datos pueden desplegarse independientemente de la infraestructura de contenedores. En el Capítulo 3, veremos cómo se despliega a menudo un agente de nodo (incluido un proxy de servicio) como componente del plano de datos en entornos sin contenedores.

La malla de servicios Istio se adopta comúnmente a la carta. El personal de las organizaciones con las que hemos hablado están adoptando las mallas de servicio principalmente por la observabilidad que aportan mediante la instrumentación del tráfico de red. Muchas instituciones financieras, en particular, están adoptando las mallas de servicio principalmente como sistema para gestionar el cifrado del tráfico de servicio a servicio.

Sea cual sea el catalizador, las organizaciones lo están adoptando a toda prisa. Y las mallas de servicios no sólo son valiosas en entornos nativos de la nube, para ayudar en la considerable tarea de ejecutar microservicios. Muchas organizaciones que ejecutan servicios monolíticos (los que se ejecutan en máquinas metálicas o virtuales, dentro o fuera de las instalaciones) anticipan con entusiasmo el uso de mallas de servicios debido al impulso modernizador que sus arquitecturas existentes recibirán de esta implementación.

La Figura 1-4 describe las capacidades de los orquestadores de contenedores (un asterisco indica una capacidad esencial). Las mallas de servicios suelen depender de estas capas subyacentes. El enfoque de la capa inferior lo proporcionan los orquestadores de contenedores.

Figura 1-4. Capacidades y enfoque de la orquestación de contenedores frente a las necesidades a nivel de servicio

¿No tenemos ya esto en nuestras plataformas de contenedores?

Los contenedores simplifican y proporcionan un empaquetamiento genérico, no específico de un lenguaje, de aplicaciones y una gestión esencial del ciclo de vida . Como plataforma genérica, no específica de un lenguaje, los orquestadores de contenedores asumen la responsabilidad de formar clusters, programar eficazmente sus recursos y gestionar las construcciones de aplicaciones de nivel superior (implementaciones, servicios, afinidad de servicios, antiafinidad, comprobación de la salud, escalado, etc.). La Tabla 1-1 muestra cómo los orquestadores de contenedores suelen llevar incorporados mecanismos de descubrimiento de servicios: equilibrio de carga con direcciones IP virtuales. Los algoritmos de equilibrio de carga soportados suelen ser de naturaleza simplista (round robin, aleatorio) y actúan como una única IP virtual para comunicarse con los pods backend.

Kubernetes gestiona el registro/desalojo de instancias en el grupo en función de su estado de salud y de si coinciden con un predicado de agrupación (etiquetas y selectores). Entonces, los servicios pueden utilizar DNS para el descubrimiento de servicios y el equilibrio de carga, independientemente de su implementación. No hay necesidad de bibliotecas o clientes de registro especiales específicos del lenguaje. Los orquestadores de contenedores nos han permitido trasladar las preocupaciones de red sencillas fuera de las aplicaciones y dentro de la infraestructura, liberando el ecosistema colectivo de tecnología de infraestructura para avanzar nuestro enfoque a capas superiores.

Ahora ya entiendes cómo las mallas de servicio complementan las capas subyacentes: ¿qué pasa con otras capas?

Paisaje y Ecosistema

El panorama de las mallas de servicios es un floreciente ecosistema de herramientas que no está relegado a las aplicaciones nativas de la nube; de hecho, también aporta mucho valor a las cargas de trabajo no contenedorizadas y que no son microservicios. A medida que vayas comprendiendo el papel que desempeña una malla de servicios en las implementaciones y el valor que aporta, podrás empezar a seleccionar una malla de servicios e integrarla con tus herramientas actuales.

Paisaje

¿Cómo debes seleccionar una malla de servicios? De las muchas mallas de servicios disponibles en la actualidad, sus importantes diferencias no hacen fácil discernir qué es realmente una malla de servicios y qué no lo es. Con el tiempo, cada vez convergen más sus capacidades, lo que facilita su caracterización y comparación.

Curiosamente, pero no por ello sorprendente, muchas mallas de servicios se han basado en algunos de los mismos proxies, como Envoy y NGINX.

Ecosistema

En cuanto a cómo encaja una malla de servicios con otras tecnologías del ecosistema, ya hemos visto las bibliotecas de clientes y los orquestadores de contenedores. Las pasarelas API abordan algunas necesidades similares y suelen desplegarse en un orquestador de contenedores como proxy de perímetro. Los proxies de borde proporcionan servicios con gestión de Capa 4 (L4) a Capa 7 (L7), al tiempo que utilizan el orquestador de contenedores para la fiabilidad, disponibilidad y escalabilidad de la infraestructura de contenedores.

Las pasarelas API interactúan con las mallas de servicios de una forma que desconcierta a muchos, dado que las pasarelas API (y los proxies sobre los que se construyen) van desde las tradicionales a las alojadas en la nube, pasando por las pasarelas API de microservicios. Estas últimas pueden estar representadas por una colección de pasarelas API de código abierto orientadas a microservicios, que utilizan el enfoque de envolver proxies L7 existentes que incorporan funciones de integración nativa del orquestador de contenedores y de autoservicio para desarrolladores (por ejemplo, HAProxy, Traefik, NGINX o Envoy).

Con respecto a las mallas de servicios, las pasarelas API están diseñadas para aceptar tráfico de fuera de tu organización o red y distribuirlo internamente. Las pasarelas API exponen tus servicios como API gestionadas, centradas en el tránsito de tráfico norte-sur (dentro y fuera de la malla de servicios). No son tan adecuadas para la gestión del tráfico dentro de la malla de servicios (este-oeste) necesariamente, porque requieren que el tráfico viaje a través de un proxy central, y añaden un salto de red. Las mallas de servicio están diseñadas principalmente para gestionar el tráfico este-oeste interno a la malla de servicio.

Dada su naturaleza complementaria, a menudo encontrarás pasarelas API y mallas de servicios desplegadas en combinación. Las pasarelas de API trabajan con otras funciones de gestión de API para gestionar los análisis, los datos empresariales, los servicios de proveedores adjuntos y la implementación del control de versiones. En la actualidad, existen solapamientos y lagunas entre las capacidades de las mallas de servicios, las pasarelas API y los sistemas de gestión de API. A medida que las mallas de servicios adquieren nuevas capacidades, los casos de uso se solapan más.

La red crítica y falible

Como se ha señalado, en las Implementaciones de microservicios, la red está directa y críticamente implicada en cada transacción, cada invocación de la lógica empresarial y cada solicitud hecha a la aplicación. La fiabilidad y la latencia de la red están entre las principales preocupaciones de las aplicaciones modernas nativas de la nube. Una aplicación nativa de la nube puede comprender cientos de microservicios, cada uno con muchas instancias que pueden ser reprogramadas constantemente por un orquestador de contenedores.

Entendiendo la centralidad de la red, quieres que tu red sea lo más inteligente y resistente posible. Debería serlo:

• Encamina el tráfico lejos de los fallos para aumentar la fiabilidad agregada de un clúster.

• Evita sobrecargas no deseadas, como rutas de alta latencia o servidores con cachés frías.

• Asegúrate de que el tráfico que fluye entre los servicios es seguro frente a ataques triviales.

• Proporciona información destacando las dependencias inesperadas y las causas de los fallos en la comunicación de los servicios.

• Te permiten imponer políticas en la granularidad de los comportamientos de servicio, no sólo en el nivel de conexión.

Además, no querrás escribir toda esta lógica en tu aplicación.

Quieres una gestión de Capa 5, una red que dé prioridad a los servicios; quieres una malla de servicios.

El valor de una malla de servicios

Actualmente, las mallas de servicios proporcionan una forma uniforme de conectar, asegurar, gestionar y monitorizar microservicios.

Observabilidad

Las mallas de servicios te dan visibilidad, resistencia y control del tráfico, así como control de seguridad sobre los servicios de aplicaciones distribuidas. Aquí se promete mucho valor. Las mallas de servicios se implementan de forma transparente y proporcionan visibilidad y control del tráfico sin necesidad de modificar el código de la aplicación (para más detalles, consulta el Capítulo 2).

En esta, su primera generación, las mallas de servicios tienen un gran potencial para aportar valor; Istio, en particular. Tendremos que esperar a ver qué capacidades de segunda generación surgen cuando las mallas de servicios se adopten de forma tan ubicua como lo han sido los contenedores y los orquestadores de contenedores.

Control del tráfico

Las mallas de servicios proporcionan un control granular y declarativo sobre el tráfico de red para determinar, por ejemplo, hacia dónde se encamina una solicitud para realizar una liberación canaria. Las características de resistencia suelen incluir la ruptura de circuitos, el equilibrio de carga consciente de la latencia, el descubrimiento de servicios eventualmente coherentes, los reintentos, los tiempos de espera y los plazos (para más detalles, consulta el Capítulo 8).

Seguridad

Cuando las organizaciones utilizan una malla de servicios, obtienen una poderosa herramienta para aplicar los requisitos de seguridad, política y cumplimiento en toda la empresa. La mayoría de las mallas de servicios proporcionan una autoridad de certificación (AC) que gestiona las claves y los certificados para asegurar la comunicación entre servicios. La asignación de una identidad verificable a cada servicio de la malla es clave para determinar qué clientes están autorizados a hacer peticiones a los distintos servicios, así como para cifrar ese tráfico de peticiones. Los certificados se generan por servicio y proporcionan una identidad única para ese servicio. Normalmente, se utilizan proxies de servicio (ver Capítulo 5) para asumir la identidad del servicio y realizar la gestión del ciclo de vida de los certificados (generación, distribución, actualización y revocación) en nombre del servicio (para más información, ver Capítulo 6).

Modernización de la infraestructura existente (adaptación de una implementación)

Muchas personas consideran que si no ejecutan muchos servicios, no necesitan añadir una malla de servicios a su arquitectura de implementación. Esto no es cierto. Las mallas de servicios ofrecen mucho valor independientemente del número de servicios que estés ejecutando. El valor que aportan sólo aumenta con el número de servicios que ejecutas y con el número de ubicaciones desde las que se despliegan tus servicios.

Aunque algunos proyectos totalmente nuevos pueden permitirse el lujo de incorporar una malla de servicios desde el principio, la mayoría de las organizaciones tendrán servicios existentes (monolitos o de otro tipo) que tendrán que incorporar a la malla. En lugar de un contenedor, estos servicios podrían estar ejecutándose en máquinas virtuales o en hosts bare-metal. Las mallas de servicios ayudan a la modernización, permitiendo a las organizaciones actualizar su inventario de servicios sin reescribir las aplicaciones, adoptar microservicios o nuevos lenguajes, o trasladarse a la nube.

Puedes utilizar servicios de fachada para descomponer los monolitos. También podrías adoptar un patrón estrangulador de construcción de servicios en torno al monolito heredado para exponer un conjunto de API más amigable para el desarrollador.

Las organizaciones pueden obtener soporte de observabilidad (por ejemplo, métricas, registros y trazas), así como gráficos de dependencias o servicios para cada uno de sus servicios (microservicios o no), a medida que adoptan una malla de servicios. En cuanto al rastreo, el único cambio necesario dentro del servicio es reenviar determinadas cabeceras HTTP. Las mallas de servicios son útiles para adaptar el rastreo de observabilidad uniforme y ubicuo a las infraestructuras existentes con el menor cambio de código.

Desacoplamiento en la capa 5

Una consideración importante a la hora de digerir el valor de una malla de servicios es el fenómeno de desacoplamiento de los equipos de servicios de y la velocidad de entrega que esto permite, como se demuestra en la Figura 1-5.

Figura 1-5. Capa 5 (L5), donde se encuentran Desarrollo y Operaciones

Al igual que los microservicios ayudan a desacoplar los equipos de características, crear una malla de servicios ayuda a desacoplar a los operadores de los procesos de desarrollo y lanzamiento de características de la aplicación, dando a su vez a los operadores un control declarativo sobre cómo funciona su capa de servicios. Crear una malla de servicios no sólo desacopla a los equipos, sino que elimina la difusión de responsabilidades entre ellos y permite la uniformidad de las normas de práctica entre las organizaciones de nuestro sector. Considera esta lista de tareas:

• Identificar cuándo romper un circuito y facilitarlo.

• Establece plazos de servicio de principio a fin.

• Asegúrate de que se generan trazas distribuidas y se propagan a los sistemas de monitoreo backend.

• Niega a los usuarios de la cuenta "Acme" el acceso a las versiones beta de tus servicios.

¿De quién es la responsabilidad: del desarrollador o del operador? Es probable que las respuestas difieran de una organización a otra; como sector, no tenemos prácticas comúnmente aceptadas. Las mallas de servicio ayudan a evitar que estas responsabilidades se pierdan o que un equipo culpe al otro por falta de responsabilidad.

La malla de servicios Istio

Emprendamos ahora nuestro viaje por la malla de servicios Istio.

Etimología del proyecto

Al ser Kubernetes una presencia tan significativa en el ecosistema nativo de la nube, su herencia etimológica griega ha dado lugar a una proliferación de proyectos asociados con nombres que empiezan por "K", así como otros con nombres de palabras griegas asociadas. Kubernetes(κυβερνήτης en el alfabeto griego) significa en griego "timonel" o "piloto". También es la palabra raíz de "cibernético" y "gobernador", términos con un significado importante en la teoría del control, y el control está en el centro del enfoque de Kubernetes.

Istio (en alfabeto griego, ιστίο) significa "vela" en griego, y se pronuncia "iss-teeh-oh". Y, por supuesto, la interfaz de línea de comandos (CLI) que acompaña a Istio, istioctl, se pronuncia "iss-teeh-oh-c-t-l", porque la utilizas para controlar Istio, no para abrazarlo.

El origen de Istio

Istio es una implementación de código abierto de una malla de servicios creada inicialmente por Google, IBM y Lyft. Lo que comenzó como un esfuerzo de colaboración entre estas organizaciones se ha ampliado rápidamente hasta incorporar contribuciones de muchas otras organizaciones e individuos. Istio es un vasto proyecto; en el ecosistema nativo de la nube, es el segundo en alcance de objetivos después de Kubernetes. Integra una serie de proyectos gobernados por la Cloud Native Computing Foundation (CNCF) como Prometheus, OpenTelemetry, Fluentd, Envoy, Jaeger, Kiali y muchos adaptadores escritos por colaboradores.

Al igual que otras mallas de servicios, Istio te ayuda a añadir resistencia y capacidad de observación a tu arquitectura de servicios de forma transparente. Las mallas de servicios no requieren que las aplicaciones sean conscientes de que se ejecutan en la malla, y el diseño de Istio no se aparta de otras mallas de servicios en este sentido. Entre el tráfico de entrada, interservicio y salida, Istio intercepta y gestiona de forma transparente el tráfico de red en nombre de la aplicación.

Utilizando Envoy como componente del plano de datos, Istio te ayuda a configurar tus aplicaciones para que tengan desplegada junto a ellas una instancia del proxy de servicio. El plano de control de Istio se compone de unos cuantos componentes que proporcionan gestión de la configuración de los proxies del plano de datos, API para operadores, ajustes de seguridad, comprobaciones de políticas y mucho más. Cubriremos estos componentes del plano de control en capítulos posteriores de este libro.

Aunque se creó originalmente para ejecutarse en Kubernetes, el diseño de Istio es agnóstico respecto a la plataforma de implementación. Por tanto, una malla de servicios basada en Istio también puede desplegarse en plataformas como OpenShift, Mesos y Cloud Foundry, así como en entornos de implementación tradicionales como máquinas virtuales y servidores bare-metal. La interoperabilidad de Consul con Istio puede ser útil en implementaciones de VM y bare-metal. Tanto si ejecutas monolitos como microservicios, Istio es aplicable:cuantos más servicios ejecutes, mayor será el beneficio.

Estado actual de Istio

Como proyecto en evolución, Istio tiene una saludable cadencia de lanzamientos, que es una forma de medir la velocidad y la salud de los proyectos de código abierto. La Figura 6-1 presenta las estadísticas de la comunidad desde mayo de 2017, cuando Istio se anunció públicamente como proyecto, hasta febrero de 2019. Durante este periodo, hubo aproximadamente 2.400 forks (usuarios de GitHub que han hecho una copia del proyecto, ya sea en el proceso de contribuir al proyecto o utilizando su código como base para sus propios proyectos) y alrededor de 15.000 estrellas (usuarios que han favorecido el proyecto y ven las actualizaciones del proyecto en su feed de actividad).

Figura 1-6. Estadísticas de contribución de Istio

Un simple número de estrellas, bifurcaciones y confirmaciones es moderadamente indicativo de la salud del proyecto en términos de velocidad, interés y apoyo. Cada una de estas métricas brutas puede mejorarse. Informar de los índices de commits, revisiones y fusiones a lo largo del tiempo quizá indique mejor la velocidad del proyecto, que se mide con mayor precisión en relación consigo mismo y con su propia línea temporal. Al determinar la salud de un proyecto, debes fijarte en si los índices de estas actividades aumentan o disminuyen, si la cadencia de publicación es coherente y con qué frecuencia y cuántos parches se publican para mejorar una publicación de características mayores o menores de baja calidad.

Cadencia

Al igual que muchos proyectos de software de , la semántica de versiones de Istio se establece en un estilo familiar (para el Versionado Semántico) (por ejemplo, versión 1.1.1) y, al igual que otros proyectos, Istio define sus propios matices para la frecuencia de las versiones, estableciendo expectativas de longevidad del soporte (ver Tabla 1-1). Aunque existen versiones diarias y semanales, éstas no están soportadas y pueden no ser fiables. Sin embargo, como muestra la Tabla 1-1, las versiones mensuales son relativamente seguras y suelen estar repletas de nuevas funciones. Pero, si quieres utilizar Istio en producción, busca las versiones etiquetadas como "LTS" (Soporte a Largo Plazo). En el momento de escribir esto, 1.2.x es la última versión LTS.

Tabla 1-1. Cadencia de creación y publicación de Istio (consulta esta página de documentación de Istio)

Tipo	Nivel de apoyo	Calidad y uso recomendado
Construcción diaria	Sin apoyo	Peligroso; puede no ser totalmente fiable. Útil para la experimentación.
Liberación instantánea	Sólo se ofrece soporte para la última versión de la instantánea.	Se espera que sea estable, pero su uso en producción debe limitarse a lo que sea necesario. Normalmente sólo lo adoptan los usuarios de perímetro sangrante o los que buscan funciones específicas.
Versión LTS	La asistencia se presta hasta tres meses después de la siguiente LTS.	Segura para su implementación en producción. Se recomienda a los usuarios que se actualicen a estas versiones lo antes posible.
Parches	Igual que la versión Snapshot/LTS correspondiente.	Se anima a los usuarios a adoptar los parches tan pronto como estén disponibles para una versión determinada.

Como marco de referencia, las versiones menores de Kubernetes se producen aproximadamente cada tres meses, por lo que cada rama de versión menor se mantiene durante unos nueve meses.

En comparación, al tratarse de un sistema operativo, Ubuntu tiene necesariamente que dar prioridad a la estabilidad sobre la velocidad de publicación de características, y por eso publica sus versiones LTS cada dos años, en abril. Cabe señalar que las versiones LTS se utilizan mucho más (algo así como el 95% de todas las instalaciones de Ubuntu son versiones LTS).

Docker utiliza un calendario de lanzamientos basado en el tiempo , cuyos plazos suelen ser los siguientes:

• Los lanzamientos de Docker CE Edge son mensuales.

• Las versiones estables de Docker CE son trimestrales, con versiones de parches según sea necesario.

• Los lanzamientos de Docker EE se producen dos veces al año, con lanzamientos de parches según sea necesario.

Las actualizaciones y los parches se publican del siguiente modo:

• Las versiones de Docker EE reciben parches y actualizaciones durante al menos un año después de su publicación.

• Las versiones estables de Docker CE reciben parches y actualizaciones durante un mes después de la siguiente versión estable de Docker CE.

• Las versiones de Docker CE Edge no reciben parches ni actualizaciones tras una versión posterior de Docker CE Edge o Estable.

Libera

El plan original era que Istio tuviera un lanzamiento puntual cada trimestre, seguido de n lanzamientos de parches. Las instantáneas se concibieron como versiones mensuales que, en su mayor parte, tendrían el mismo nivel de calidad que las versiones puntuales, salvo que no son versiones compatibles y pueden contener cambios de última hora. El historial de todas las versiones está disponible en la página de versiones de Istio en GitHub. La Tabla 1-2 presenta la cadencia de lanzamientos de Istio durante un periodo de 10 meses.

Tabla 1-2. Cadencia de las versiones de Istio de junio de 2018 a abril de 2019

Fecha de publicación	Número de liberación	Días desde la última liberación
4/16/19	1.1.3	11
4/5/19	1.1.2	0
4/5/19	1.0.7	11
3/25/19	1.1.1	6
3/19/19	1.1.0	3
3/16/19	1.1.0-rc.6	2
3/14/19	1.1.0-rc.5	2
3/12/19	1.1.0-rc.4	4
3/8/19	1.1.0-rc.3	4
3/4/19	1.1.0-rc.2	5
2/27/19	1.1.0-rc.1	6
2/21/19	1.1.0-rc.0	8
2/13/19	1.1.0-snapshot.6	0
2/13/19	1.0.6	19
1/25/19	1.1.0-snapshot.5	0
1/25/19	1.1.0-snapshot.4	48
12/8/18	1.0.5	11
11/27/18	1.1.0-snapshot.3	6
11/21/18	1.0.4	26
10/26/18	1.0.3	3
10/23/18	1.1.0-snapshot.2	26
9/27/18	1.1.0-snapshot.1	21
9/6/18	1.0.2	8
8/29/18	1.1.0-snapshot.0	5
8/24/18	1.0.1	24
7/31/18	1.0.0	8
7/23/18	1.0.0-snapshot.2	3
7/20/18	1.0.0-snapshot.1	22
6/28/18	1.0.0-snapshot.0	27
6/1/18	0.8.0

Estado de las funciones

Al más puro estilo ágil, las funciones de Istio atraviesan individualmente su propio ciclo de vida (dev/alpha/beta/estable). Algunas funciones se estabilizan, mientras que otras se añaden o mejoran, como se muestra en la Tabla 1-3.

Tabla 1-3. Categorías de estado de las funciones de Istio (consulta: https://oreil.ly/qV8b0)

	Alfa	Beta	Estable
Propósito	Demostrable; funciona de extremo a extremo, pero tiene limitaciones	Utilizable en producción, ya no es un juguete	Fiables, curtidos en la producción.
API	No hay garantías de compatibilidad con versiones anteriores	Las API están versionadas	Fiables, aptas para la producción. Las API están versionadas, con conversión automática de versiones para compatibilidad con versiones anteriores.
Rendimiento	No cuantificado ni garantizado	No cuantificado ni garantizado	El rendimiento (latencia/escala) está cuantificado, documentado, con garantías contra la regresión.
Política de amortización	Ninguno	Débil: tres meses	Fiables y firmes. Se avisará con un año de antelación antes de realizar cambios.

Futuro

Los grupos de trabajo están iterando sobre los diseños hacia una arquitectura v2, incorporando lo aprendido del funcionamiento de Istio a escala y los comentarios de usabilidad de los usuarios. Con cada vez más gente conociendo las mallas de servicios en el futuro, la facilidad de adopción será clave para ayudar a las masas a alcanzar con éxito la tercera fase de su viaje nativo en la nube → contenedores → orquestadores → mallas.

Qué no es Istio

Istio no tiene en cuenta capacidades específicas que puedas encontrar en otras mallas de servicios, o que ofrezca el software del plano de gestión. Esto se debe a que está sujeta a cambios o a que suele ampliarse con software de terceros.

Con la destacada excepción de facilitar el rastreo distribuido, Istio no es una solución de monitoreo del rendimiento de las aplicaciones (APM) de caja blanca. La generación de telemetría adicional que rodea e introspecciona el tráfico de red y las solicitudes de servicio que está disponible con Istio sí proporciona visibilidad adicional de caja negra. De las métricas y registros disponibles con Istio, éstas proporcionan una visión de los flujos de tráfico de red, incluyendo origen, destino, latencia y errores; métricas de servicio de nivel superior, no métricas de aplicación personalizadas expuestas por cargas de trabajo individuales o registro a nivel de clúster.

Los complementos de Istio integran los registros a nivel de servicio con el mismo sistema de monitoreo backend que podrías estar utilizando para el registro a nivel de clúster (por ejemplo, Fluentd, Elasticsearch, Kibana). Además, Istio utiliza la misma recopilación de métricas y alarmas, que bien podría ser la misma utilidad (por ejemplo, Prometheus) que ya estés utilizando.

No se trata sólo de microservicios

Kubernetes no lo hace todo. ¿La infraestructura del futuro estará totalmente basada en Kubernetes? No es probable. No todas las aplicaciones, especialmente las diseñadas para ejecutarse fuera de contenedores, encajan bien en Kubernetes (actualmente, al menos). La cola de la tecnología de la información es bastante larga, teniendo en cuenta que los mainframes de hace décadas siguen utilizándose hoy en día.

Ninguna tecnología es la panacea. Los monolitos son más fáciles de comprender, porque gran parte de la aplicación está en un solo lugar. Puedes rastrear las interacciones de sus distintas partes dentro de un sistema (o de un conjunto limitado de sistemas más o menos estancados). Sin embargo, los monolitos no escalan, en términos de equipos de desarrollo y líneas de código.

Los monolitos no distribuidos seguirán existiendo durante mucho tiempo. Las mallas de servicios ayudan a su modernización y pueden proporcionar fachadas que faciliten la arquitectura evolutiva. La implementación de una pasarela de malla de servicios como fachada inteligente frente al monolito será un enfoque que muchos adoptarán para estrangular su monolito desviando las solicitudes basadas en la ruta (o de otro tipo). Este enfoque es gradual, y conduce a la migración de partes del monolito a microservicios modernos, o simplemente actúa como medida provisional a la espera de un rediseño totalmente nativo de la nube.

Terminología

He aquí algunos términos importantes relacionados con Istio que debes conocer y tener en cuenta en :

Nube

Un proveedor específico de servicios en la nube.

Grupo

Un conjunto de nodos Kubernetes con maestros API comunes.

Configurar almacén

Un sistema que almacena la configuración fuera del propio plano de control, por ejemplo, etcd en una implementación Kubernetes de Istio o incluso un simple sistema de archivos.

Gestión de contenedores

Se define vagamente como la virtualización del SO proporcionada por pilas de software como Kubernetes, OpenShift, Cloud Foundry, Apache Mesos, etc.

Medio ambiente

El entorno informático presentado por varios proveedores de infraestructura como servicio (IaaS), como Azure Cloud Services, AWS, Google Cloud Platform, IBM Cloud, Red Hat Cloud computing, o un grupo de máquinas virtuales o físicas que se ejecutan in situ o en centros de datos alojados.

Malla

Conjunto de cargas de trabajo con un control administrativo común; bajo la misma entidad rectora (por ejemplo, un plano de control).

Multientorno (también conocido como híbrido)

Describe entornos heterogéneos en los que cada uno puede diferir en la implementación y el despliegue de los siguientes componentes de infraestructura:

Límites de la red

Ejemplo: un componente utiliza la entrada local, y el otro utiliza la entrada que opera en la nube.

Sistemas de identidad

Ejemplo: un componente tiene LDAP, el otro tiene cuentas de servicio.

Sistemas de nombres como DNS

Ejemplo: DNS local, DNS basado en Cónsul.

Marcos de orquestación de máquinas virtuales/contenedores/procesos

Ejemplo: un componente tiene máquinas virtuales locales gestionadas localmente, y el otro tiene contenedores gestionados por Kubernetes que ejecutan servicios.

Multiarrendamiento

Servicios lógicamente aislados, pero físicamente integrados, que se ejecutan bajo el mismo plano de control de la malla de servicios Istio.

Red

Un conjunto de puntos finales directamente interconectados (puede incluir una red privada virtual [VPN]).

Nomenclatura segura

Proporciona la correspondencia entre el nombre de un servicio y los principales de carga de trabajo autorizados a ejecutar las cargas de trabajo que implementan un servicio.

Servicio

Un grupo delineado de comportamientos relacionados dentro de una malla de servicios. Los servicios se nombran utilizando un nombre de servicio, y las políticas de Istio, como el equilibrio de carga y el enrutamiento, se aplican a los nombres de servicio. Un servicio se materializa normalmente mediante uno o más puntos finales de servicio.

Punto final del servicio

La manifestación alcanzable por la red de un servicio. Los puntos finales son expuestos por las cargas de trabajo. No todos los servicios tienen puntos finales de servicio.

Malla de servicio

Un conjunto compartido de nombres e identidades que permite la aplicación de políticas comunes y la recopilación de telemetría. Los nombres de servicio y los principales de carga de trabajo son únicos dentro de una malla.

Nombre del servicio

Un nombre único para un servicio que lo identifica dentro de la malla de servicios. No se puede cambiar el nombre de un servicio y mantener su identidad: cada nombre de servicio es único. Un servicio puede tener varias versiones, pero un nombre de servicio es independiente de la versión. Los nombres de servicio son accesibles en la configuración de Istio como los atributos source.service y destination.service.

Servicio proxy

El componente del plano de datos que gestiona el tráfico en nombre de los servicios de aplicación.

Sidecar

Una metodología de programación conjunta de contenedores de utilidades con contenedores de aplicaciones agrupados en la misma unidad lógica de programación. En el caso de Kubernetes, un pod.

Carga de trabajo

Proceso/binario desplegado por operadores en Istio, normalmente representado por entidades como contenedores, pods o VMs. Una carga de trabajo puede exponer cero o más puntos finales de servicio; una carga de trabajo puede consumir cero o más servicios. Cada carga de trabajo tiene asociado un único nombre de servicio canónico, pero también puede representar nombres de servicio adicionales.

Nombre de la carga de trabajo

Nombre único para una carga de trabajo, que la identifica dentro de la malla de servicios. A diferencia del nombre del servicio y del principal de la carga de trabajo, el nombre de la carga de trabajo no es una propiedad fuertemente verificada y no debe utilizarse al aplicar listas de control de acceso (ACL). Los nombres de las cargas de trabajo son accesibles en la configuración de Istio como los atributos source.name y destination.name.

Carga de trabajo principal

Identifica la autoridad verificable bajo la que se ejecuta una carga de trabajo. La autenticación servicio-a-servicio de Istio se utiliza para producir el principal de la carga de trabajo. Por defecto, los principales de la carga de trabajo se ajustan al formato SPIFFE ID. Varias cargas de trabajo pueden compartir un principal de carga de trabajo, pero cada carga de trabajo tiene un único principal de carga de trabajo canónico. Éstos son accesibles en la configuración de Istio como los atributos source.user y destination.user.

Zona (plano de control de Istio)

Conjunto de componentes necesarios para Istio. Esto incluye Galera, Mezclador, Piloto y Ciudadela.

• Una única zona está representada por un único almacén lógico de Galera.

• Todos los Mezcladores y Pilotos conectados a la misma Galera se consideran parte de la misma zona, independientemente de dónde funcionen.

• Una sola zona puede funcionar de forma independiente, incluso si todas las demás zonas están desconectadas o inaccesibles.

• Una misma zona sólo puede contener un único entorno.

• Las zonas no se utilizan para identificar servicios o cargas de trabajo en la malla de servicios. Cada nombre de servicio y carga de trabajo principal pertenece a la malla de servicios en su conjunto, no a una zona individual.

• Cada zona pertenece a una única malla de servicio. Una malla de servicio abarca una o varias zonas.

• En relación con los clústeres (por ejemplo, los clústeres de Kubernetes) y la compatibilidad con multientornos, una zona puede tener varias instancias de éstos. Pero los usuarios de Istio deberían preferir configuraciones más sencillas. Debería ser relativamente trivial ejecutar los componentes del plano de control en cada clúster o entorno y limitar la configuración a un clúster por zona.

Los operadores necesitan un control independiente y un conjunto de herramientas flexibles para garantizar que ejecutan microservicios seguros, conformes, observables y resistentes. Los desarrolladores necesitan liberarse de los problemas de infraestructura y poder experimentar con distintas funciones de producción, e implementar versiones canarias sin afectar a todo el sistema. Istio añade la gestión del tráfico a los microservicios y crea una base para capacidades de valor añadido como la seguridad, el monitoreo, el enrutamiento, la gestión de la conectividad y la política.