Red Hat OpenShift Service Mesh 3: actualización de la versión de prueba para desarrolladores

A principios de este año, anunciamos que estaría disponible como versión de prueba para desarrolladores un nuevo operador para Istio en Red Hat OpenShift destinado a la próxima generación de OpenShift Service Mesh (versión 3). En esa publicación, se proporciona información importante sobre los cambios que se aplicarán a OpenShift Service Mesh en 2024. Desde entonces, seguimos desarrollando el  operador Sail, brindando soporte a los clientes que utilizan OpenShift Service Mesh 2 y recopilando comentarios sobre nuestros planes para Service Mesh 3. Si bien el nuevo operador sigue siendo una versión de prueba para desarrolladores, en esta publicación, se brindarán novedades, se analizarán los planes futuros y se ofrecerá orientación inicial sobre la manera en que los usuarios de OpenShift Service Mesh pueden prepararse para su versión 3.

Novedades sobre Service Mesh 3.0

El operador de Kubernetes de Service Mesh 3 se desarrolla actualmente bajo el nombre de operador Sail y está disponible como operador de Kubernetes comunitario en el OperatorHub de OpenShift. El operador Sail de Kubernetes se actualiza todas las noches, por lo que sigue siendo un trabajo en curso y está sujeto a cambios. Es posible que evolucione y termine siendo diferente a lo que se describe en esta publicación de blog, así que, por el momento, solo utilícelo para experimentar. Consulte el archivo README que se incluye para obtener la información más reciente sobre el operador de Kubernetes.

Planeamos trasladar este operador comunitario a la organización upstream istio-ecosystem para lograr una mayor colaboración comunitaria y, al mismo tiempo, aportar mejoras al proyecto principal de Istio para mejorar la compatibilidad de Istio con OpenShift. Los artefactos de productos downstream de OpenShift Service Mesh 3 estarán ubicados en la organización openshift-service-mesh que se creó recientemente, mientras que la organización maistra se seguirá usando en Service Mesh 2.

Un operador de Kubernetes para Istio… y solo Istio

Como se analizó en la publicación anterior del blog, OpenShift Service Mesh 3 se basará en un nuevo operador de Kubernetes para Istio. A diferencia del operador de Kubernetes actual de OpenShift Service Mesh 2, el nuevo solo gestionará los recursos de Istio y no intentará configurar integraciones de Istio, como Kiali. Los operadores de Kubernetes de productos con soporte independiente gestionarán los elementos complementarios, como Kiali, los indicadores, el seguimiento y otros.

Cuando se lanzó por primera vez el operador Sail, el recurso personalizado para instalar el plano de control de Istio se denominaba IstioHelmInstall. Se cambió el nombre de este recurso a "Istio" para reflejar que es responsable de crear y gestionar una sola instancia de Istio (un plano de control y un plano de datos).

A diferencia del recurso personalizado ServiceMeshControlPlane que se utiliza en OpenShift Service Mesh 2, el recurso de Istio usa valores de Helm de Istio upstream para definir la configuración de Istio. Esto facilita a los usuarios el traslado de los ejemplos de configuración de la comunidad a OpenShift Service Mesh 3. También ayuda a garantizar que nuestros esfuerzos futuros para mejorar la configuración se realicen en colaboración con la comunidad de Istio. No descartamos una convergencia futura con la API del operador de Istio de la comunidad, la cual se usa con el proceso de instalación de istioctl y la instalación del operador de Istio upstream no recomendada.

Nuestros próximos esfuerzos incluirán el perfeccionamiento de la organización de la configuración y mejoras para optimizar el soporte que se brinda a las funciones, como las revisiones de Istio, las actualizaciones de tipo canary y la arquitectura multiempresa. Consulte el archivo README del operador de Kubernetes para obtener la información más actualizada.

Selección de versiones

Cuando lanzamos el operador Sail por primera vez, implementaba la última versión de Istio, de hecho, la rama Master de Istio, que se encontraba en desarrollo. Si bien esto fue conveniente para experimentar con lo último de la comunidad de Istio, en la mayoría de los casos, los usuarios deberían usar una versión oficial de Istio para asegurarse de su estabilidad y de su compatibilidad con istioctl y las integraciones, como Kiali.

Ahora utilizamos de forma predeterminada la versión más reciente de Istio, que en este momento es la 1.20. Configúrela en el campo version en las definiciones de recursos personalizados (CRD) de Istio. Al crear una nueva instancia con la consola de OpenShift, ahora aparece un menú desplegable que permite seleccionar una versión de Istio de una lista de las que están disponibles, las cuales se detallan en el archivo versions.yaml, que se actualiza cada vez que hay una nueva.

Menú desplegable del selector de versiones de Istio

El futuro operador de Kubernetes del producto OpenShift Service Mesh 3, que se basará en el operador Sail, gestionará las versiones de OpenShift Service Mesh de manera similar. Si bien este campo version es similar al campo version del recurso ServiceMeshControlPlane en Service Mesh 2.x, una diferencia notable es que los usuarios pueden especificar una versión hasta el nivel de versión del parche Z (por ejemplo, 3.1.1). Aunque solo admitiremos las versiones de parches más recientes de OpenShift Service Mesh, esta función permitirá a los usuarios anclar una versión de parche Z en particular o volver a ella, lo que les proporcionará un mayor control y flexibilidad para la gestión de las actualizaciones de los parches.

Validación de la configuración

El campo principal para configurar Istio con las nuevas definiciones de recursos personalizados (CRD) es el campo values. Este poderoso campo permite a los usuarios hacer referencia a los valores de configuración de Helm para Istio directamente. Agregamos validación a este campo para detectar valores de configuración inexistentes y otros errores de configuración basados en las validaciones protobuf de Istio upstream.

Estas validaciones también permiten gestionar el campo values de la siguiente manera:

$ oc explain istio.spec.values 
KIND:     Istio 
VERSION:  operator.istio.io/v1alpha1 
RESOURCE: values <Object> 
DESCRIPTION: 
    Values defines the values to be passed to the Helm chart when installing 
    Istio. 
FIELDS: 
  base <Object> 
  cni <Object> 
  defaultRevision <string> 
  global <Object> 
  istio_cni <Object> 
  istiodRemote <Object> 
  meshConfig <> 
  ownerName <string> 
  pilot <Object> 
  revision <string> 
  revisionTags <[]string> 
  sidecarInjectorWebhook <Object> 
  telemetry <Object> 
  ztunnel <>

Dado que puede haber ocasiones en las que se desee anular estas validaciones, por ejemplo, para acceder a la configuración experimental que aún no forma parte del esquema protobuf de Istio, también incluimos un campo rawValues, que es idéntico al campo values excepto que no está validado.

Tenga en cuenta que los campos resource, values y rawValues de Istio siguen siendo experimentales y están sujetos a cambios. Consulte el archivo README del proyecto para obtener la información más reciente.

Estado y configuración de Istio

Debe validar el estado del plano de control una vez que haya aplicado la configuración de Istio. Hágalo con el siguiente comando:

$ kubectl get istioundefinedundefinedundefined

NAME         READY  STATUS VERSION AGE

istio-sample True  Healthy v1.20.0 62sundefinedundefined

O bien, utilice el campo status:

Definición de recursos personalizados de Istio

Cuando se expande el campo status.appliedValues, se puede usar para validar que la configuración se aplicó como se esperaba usando el campo spec.values.

Istio en OpenShift

Como parte de nuestra iniciativa de colaboración con la comunidad de Istio, seguimos contribuyendo a Istio upstream para mejorar la compatibilidad de Istio con OpenShift. Esto lo hacemos en nuestro propio beneficio (a fin de simplificar nuestro trabajo para producir Istio) y en el de la comunidad, los clientes y los partners, ya que nuestras contribuciones facilitan la ejecución de la versión comunitaria de Istio en OpenShift y proporcionan una ruta de incorporación sencilla a nuestra OpenShift Service Mesh compatible.

Un ejemplo de este esfuerzo fue eliminar la necesidad de otorgar el privilegio anyuid de restricción del contexto de seguridad (SCC) a los elementos de los planos de control y de datos de Istio, como se destacó recientemente en Istio 1.20. Haremos contribuciones similares de manera permanente, la más importante de las cuales será el cambio que se requiera para que la malla Ambient de Istio funcione en OpenShift.

Prácticas recomendadas para las puertas de enlace

Cuando se anunció este operador de Kubernetes, instalaba automáticamente las puertas de enlace, de manera similar a lo que ocurre con el perfil de configuración de instalación predeterminado de Istio. Esto coincide con OpenShift Service Mesh 2.x, que crea puertas de enlace predeterminadas de entrada y de salida que se denominan istio-ingressgateway e istio-egressgateway respectivamente.

Si bien estas puertas de enlace que se crean de forma automática son convenientes para comenzar, no proporcionan la capacidad de configuración necesaria para los entornos de producción. También creemos firmemente que las puertas de enlace se crean y gestionan mejor con sus aplicaciones en el plano de datos en lugar de en el plano de control. Crear y gestionar las puertas de enlace junto con sus aplicaciones es una mejor práctica de seguridad, ya que permite limitar el alcance de la puerta de enlace a un conjunto más pequeño de aplicaciones para que pueda adoptar el ciclo de vida de las aplicaciones en lugar del ciclo del plano de control.

Por lo tanto, optamos por eliminar estas puertas de enlace del plano de control para guiar a los usuarios a crearlas junto con sus aplicaciones mediante inserción o la API de Kubernetes. istio-ingressgateway e istio-egressgateway, como se especifica en ServiceMeshControlPlane de OpenShift Service Mesh 2.x, no se incluirán en Service Mesh 3.0. En su lugar, proporcionaremos configuraciones de ejemplo de puertas de enlace para la aplicación Bookinfo mediante la inserción de puertas de enlace y la API de puertas de enlace de Kubernetes.

Con la inserción de puertas de enlace, estas se crean y gestionan como cualquier otra carga de trabajo en Kubernetes u OpenShift mediante un recurso de implementación que se incorpora a un proxy de Envoy. Este enfoque otorga el control completo de la puerta de enlace al propietario de la aplicación. Es la forma recomendada de crear y gestionar las puertas de enlace en OpenShift Service Mesh 2.3 y versiones posteriores.

Con la API de puertas de enlace en versión de prueba a partir de OpenShift Service Mesh 2.4, se crea y configura una instancia de implementación de puerta de enlace con cada instancia de puerta de enlace.

Estas opciones permiten que las puertas de enlace se creen y gestionen con aplicaciones, idealmente como parte de un flujo de trabajo de GitOps.

API de puertas de enlace de Kubernetes

La API de puertas de enlace de Kubernetes representa la próxima generación de API para diseñar redes en Kubernetes. En comparación con la API de entrada de Kubernetes actual, ofrece una flexibilidad y una capacidad de ampliación mucho mayores para gestionar las redes en una empresa de gran tamaño. Si bien inicialmente estaba destinado a gestionar el tráfico norte/sur de clientes fuera del clúster, creció para incluir el tráfico este/oeste, incluido el de Service Mesh. La iniciativa GAMMA se creó para definir la forma en que la API de puertas de enlace puede cubrir los casos prácticos de la malla de servicios. Istio ahora incluye ejemplos de configuración de la API de puertas de enlace para la mayoría de las tareas documentadas, como la gestión del tráfico.

Si bien la API de puertas de enlace sigue siendo una función en versión de prueba en OpenShift Service Mesh 2.4 y debe habilitarse con un indicador de función, ahora está disponible de forma general en la comunidad. La versión 1.0 de la API está disponible en Istio 1.20 (que se incluirá con OpenShift Service Mesh 2.6 y versiones posteriores). Istio planea hacer que la API de puertas de enlace sea la API predeterminada para toda la gestión del tráfico en el futuro, mientras continúa admitiendo las API de Istio (Gateway, VirtualService, DestinationRule, etc.) por ahora.

Nuestro entusiasmo por el potencial del proyecto de la API de puertas de enlace  para proporcionar un estándar común para las redes de Kubernetes va mucho más allá de la malla de servicios.

Estamos desarrollando una implementación de OpenShift Ingress basada en esta API que los usuarios pueden implementar independientemente de una malla de servicio a través del operador de entrada de la API de puertas de enlace. Para obtener más información sobre este trabajo y la API de puertas de enlace, consulte esta publicación del blog y la actualización más reciente.

Mientras tanto, el equipo que produjo 3Scale API Management trabaja en el proyecto Kuadrant.io, el cual aprovechará la API de puertas de enlace para abordar casos prácticos relacionados con la forma en que el tráfico externo ingresa a las puertas de enlace de entrada, como la conectividad entre varios clústeres, el equilibrio de carga global, la limitación de velocidad, la autorización y muchos más. Podrá encontrar información sobre este proyecto en una próxima publicación del blog.

Comience a utilizar los complementos de Istio, como Kiali

Un cambio notable en OpenShift Service Mesh 3.0 es que el operador de Kubernetes solo gestionará Istio. Las integraciones, como Kiali, el seguimiento de entornos distribuidos y los indicadores, se instalarán y gestionarán de forma independiente. Si bien esto agregará pasos a la experiencia de inicio, creemos que, al tener más modularidad y flexibilidad en la configuración de estos elementos, valdrá la pena.

Para ayudar a que los usuarios comiencen rápidamente, agregamos instrucciones al archivo README del operador de Kubernetes para configurar Istio con Istioctl, puertas de enlace de muestra, Prometheus, Jaeger y Kiali. De esta manera, se proporciona un entorno de demostración/desarrollo más o menos equivalente a lo que ofrece OpenShift Service Mesh 2.x en la actualidad. También se brinda una vista previa del flujo de trabajo de instalación que planeamos ofrecer en OpenShift Service Mesh 3, donde Istio se instalará solo y los complementos se instalarán de forma independiente. Por supuesto, Service Mesh 3.0 con soporte usará operadores de Kubernetes de productos compatibles para cada uno de los complementos de Istio con una distribución compatible de Istioctl. Estas configuraciones de complementos de Istio de la comunidad son solo para fines de demostración y desarrollo, por lo que no deben usarse para entornos de producción.

Preparación para Service Mesh 3.0

Los usuarios de OpenShift Service Mesh 2 pueden llevar a cabo varias actividades hoy en preparación para adoptar Service Mesh 3.0.

Es importante recordar que OpenShift Service Mesh 3 seguirá basándose en Istio, y que las API estables de Istio que probablemente usen los usuarios finales no cambiarán. Lo que cambiará en OpenShift Service Mesh 3 y requerirá la migración son los recursos de configuración del plano de control, como ServiceMeshControlPlane y ServiceMeshMemberRoll . Por lo general, son los administradores o los equipos de plataforma, en lugar de los propietarios de las aplicaciones, los encargados de gestionar estos recursos. Continuaremos explorando las formas en que los administradores pueden migrar las configuraciones actuales del plano de control a las configuraciones de Service Mesh 3.

La configuración específica de la aplicación (recursos de Istio como VirtualServices, DestinationRules e, incluso, PeerAuthentication) no cambiará. Por lo tanto, los usuarios deben sentirse seguros de que pueden comenzar a usar OpenShift Service Mesh 2 o expandir su uso sin tener que migrar las configuraciones específicas de aplicaciones o servicios cuando migren a OpenShift Service Mesh 3.

Hay algunas acciones que los usuarios pueden realizar hoy mismo para facilitar la migración a OpenShift Service Mesh 3.0. Además de usar la versión más reciente de OpenShift Service Mesh (2.4 o superior), los usuarios pueden:

• Adoptar la inserción de puertas de enlace o migrar a ella para crear y gestionar las puertas de enlace de Istio con sus aplicaciones en lugar de con el plano de control de Istio (que es la forma predeterminada en Service Mesh 2.0). Como se describió anteriormente, el plano de control en 3.0 no creará puertas de enlace.
• Si no se requieren varios planos de control, use el modo de todo el clúster. Con él, el Istiod se ejecuta como un recurso del nivel del clúster. Este será el modo predeterminado en Service Mesh 3.0, con la posibilidad de crear varios planos de control con la prometedora función para ello.
• Configure Service Mesh para que use la supervisión de la carga de trabajo del usuario de OpenShift o la determinación del estado interno de los sistemas de Red Hat Advanced Cluster Management para registrar los indicadores. Esto proporcionará una stack de supervisión del nivel de producción con alertas, que será mucho más configurable y extensible que la stack de indicadores instalada con OpenShift Service Mesh 2.x (y que se eliminará en Service Mesh 3).
• Use recursos Kiali y Jaeger configurados de forma externa en lugar de configurarlos directamente dentro del recurso ServiceMeshControlPlane. Además de proporcionar más flexibilidad para gestionar Kiali y Jaeger, estos se configurarán de forma independiente en Service Mesh 3.

Más adelante, publicaremos una entrada en el blog en la que profundizaremos sobre cada uno de estos temas.

Próximos pasos para OpenShift Service Mesh

Nuestro próximo lanzamiento será OpenShift Service Mesh 2.5 (basado en Istio 1.18) a principios de 2024. También decidimos lanzar una versión 2.6 basada en Istio 1.20 o versión posterior en 2024 para asegurarnos de que los clientes tengan al menos un año de soporte superpuesto para actualizar OpenShift Service Mesh 2 a 3. La versión 2.6 también nos dará tiempo adicional para recopilar comentarios sobre OpenShift Service Mesh 3 mientras se encuentra en estado de versión de prueba.

Para OpenShift Service Mesh 3, seguimos desarrollando el nuevo operador de Kubernetes, lo que incluye ajustar las definiciones de recursos personalizados para que se gestione mejor la configuración de Istio y agregar funciones que permitan admitir mejor las actualizaciones tipo canary de los planos de control de Istio. Tenemos programado lanzar la versión de prueba a fines del primer trimestre de 2024 y que esté disponible para el público general en la segunda mitad de 2024. Por supuesto, estos objetivos están sujetos a cambios. Continuaremos brindando soporte a los clientes en OpenShift Service Mesh 2.x hasta que tengamos una OpenShift Service Mesh 3 que nos enorgullezca ofrecer de manera general.

Visite esta página para obtener más información sobre Red Hat OpenShift Service Mesh.