El objetivo de éste artículo es indicar una estrategia de instalación, configuración y tuneo de istio 1.5, para el establecimiento una arquitectura base y el plano de control de un sistema mesh service, tanto en un cluster de producción compatible con k8s como en uno de prueba como es el caso de minikube.
Para ello utilizaremos la interfaz de la línea de comando de istio (istioctl), las opciones del IstioOperator, los perfiles de configuración que ofrece istio, la creación automática de yaml a partir de perfiles, su customización según nuestros intereses y las características del cluster y por último veremos como convertir los yaml de istio en yaml standard de k8s compatibles por lo tanto con cualquier cluster que soporte kubernetes.
En primer lugar vamos a descargar e instalar istio 1.5, para ello accedemos a la página oficial a descargas(https://istio.io/docs/setup/getting-started/#download) y desde allí accedemos a github https://github.com/istio/istio/releases y nos descargamos la última estable.
En el momento de éste artículo es la 1.5.2. De todas las disponibles descargamos istio-1.5.2-win.zip para el caso de windows o istio-1.5.2-linux.tar.gz para el caso de linux o mac. Comentar que vamos a trabajar sobre windows en este artículo.
Lo siguiente es descomprimirlo donde queramos y añadir la ruta …istio-1.5.1\bin a la variable «path» del sistema operativo, para poder acceder a istioctl.exe
Es importante comentar un hecho bastante relevante de la release 1.5 y es que con esta release aparece un componente monolítico denominado istiod que aglutina en un único pod toda la funcionalidad del plano de control. De esta forma todo lo que quedaba cubierto anteriormente con los microservicios: Pilot,Galley,Citadel,Mixer y el inyector del sidecar se centraliza en istiod. Y aunque parezca antagónico que una arquitectura para la gestión de microservicios sustituya a microservicios por una pieza monolítica, lo cierto es que en este caso supone una ventaja que el plano de control esté concentrado tanto para su mantenimiento y evolución como para la instalación y configuración.Otro cambio a destacar es la configuración por defecto de la comunicación segura (mTLS) entre microservicios, que pasa a usar el Secret discovery service de Envoy para la distribución de los certificados (SDS de Envoy) en vez de la creación y distribución de secretos para cada servicio.
Si accedemos a https://istio.io/docs/setup/additional-setup/config-profiles/ vemos que Istio ofrece varios perfiles de configuración.
Pues bien nosotros vamos a centrarnos en 2 de ellos: demo y default.
El perfil demo es el adecuado para entornos de desarrollo y default para un cluster real de producción. Aunque como iremos viendo en el caso del perfil default, es un buen punto de partida, pero es necesario realizar bastante tuneo para que esté disponible para un cluster de producción, el demo sinembargo si que está practicamente listo para usarse sin demasiado retoque.
Vamos a realizar una comparativa entre ambos perfiles a varios niveles, en primer lugar vamos realizar un análisis superficial para observar que pods se instalan con cada perfil.
Vamos a usar un cluster minikube vacío con un mínimo de 4GB de RAM y preferiblemente 8GB(*) y vamos a instalar ambos perfiles. Primero uno y después otro ya que la configuración es única.La idea es comprobar lo que se instala con cada uno. Para ello utilizaremos istioctl que es la interfaz de linea de comandos que está sustituyendo a helm. Más adelante profundizaremos sobre ello y sobre IstioOperator.
Si ejecutamos istioctl manifest apply --set profile=demo y esperamos un poco a que arranquen y consultamos los pods del name-space istio-system, mediante kubectl get po -n isitio-system
Vemos que con el perfil demo tenemos una instalación bastante completa, con los componentes core: istiod (por supuesto) istio-ingressgateway, istio-egressgateway pero también utilidades (addons como los denomina Istio) de gran valor como Kiali,Jaeger,Grafana o Prometheus.
En el caso del perfil default solo se instalan: istiod,istio-ingressgateway y prometheus.
Si consultamos la página oficial de Istio vemos que es lo que indica.
De este modo y desde el punto de vista de los componentes en el perfil default ,el recomendado para producción, no incluye los componentes de telemetría que por un lado suponen un consumo pero por otro lado son de gran utilidad. Pues bien entre las opciones de istioctl se encuentra la de añadir componentes a un perfil, de este modo si queremos añadir kiali y grafana al perfil default, nos bastaría con ejecutar el siguiente comando que puede extenderse a todos los addons.
istioctl manifest apply --set profile=default --set addonComponents.kiali.enabled=true--set addonComponents.kiali.enabled=true A continuación vamos a realizar un análisis que nos va a aportar bastante más información.Vamos a comparar los archivos de configuración yaml asociados a cada perfil y veremos como a parte de los componentes instalados por defecto existen bastantes más diferencias.
Para obtener el yaml asociado al pefil ejecutamos el comando
istioctl profile dump "el nombre perfil que queramos"
De esta forma nos aparece el contenido en consola, pero tenemos la opción de guardarlo en un fichero (mejor opción) como vemos en la imagen de abajo.
Veamos que diferencias tenemos entre ambos yaml.
Por un lado y como ya sabíamos en el perfil default no están habilitados grafana, kiali, tracing(jaeger), egressGateway y eso se pone de manifiesto con enabled: false. En caso de necesitarse alguno de ellos, que desde mi punto de vista son todos necesarios, habría que cambiar el valor a true y de ese modo los tendríamos disponibles. Por otro lado si queremos acceder desde un browser a los componentes de telemetría, algo recomendable, debemos establecer el NodePort.
Si tomamos como ejemplo a kiali
Habría que añadir el service del tipo NodePort tal y como se indica en la imagen previa. El acceso desde el browser seria por el puerto 31000.
Es importante comentar que este cambio en la configuración debemos realizarlo también en el perfil demo si queremos acceder a Kiali,Jaeger,Grafana desde el browser.
Si nos fijamos en el ingressGateways vemos que hay bastantes diferencias de configuración en temas aspectos relacionados con la disponibilidad,la capacidad y el rendimiento del entorno.
En primer lugar para el cluster de producción se está aumentando el número de replicas posibles hasta un máximo de 5 lo cual parece una estrategia bastante lógica para evitar la indisponibilidad en las peticiones, ya que en caso de existir una única replica y producirse un problema en ella el sistema quedaría sin tráfico hasta que se reiniciara el ingressGateways. Con está configuración sin embargo la garantía de disponibilidad de tráfico es practicamente absoluta.
El hecho que pueda establecerse un intervalo de replicas es posible a que se encuentre habilitado el autoescalado
Otro elemento a tener en cuenta es la dotación de cpu y memoria RAM como podemos observar en el cluster de producción los valores son mucho más altos lo cual es bastante lógico ya que al tratarse de un entorno productivo la carga va a ser mucho mayor que en un entorno de desarrollo. La elección de éstos valores no es tarea fácil y depende de las necesidades del sistema como ocurre siempre en los entornos de producción
Otro aspecto a tener en cuenta es el referente a las trazas en el caso del perfil demo está configurado para el 100% de las mismas, en un entorno real eso es penalizante. En el caso del perfil default no hay nada configurado y eso corresponde con un 2% de las trazas.
Veamos por último una peculiaridad común a ambos perfiles.
El valor del kind de los yaml generados por istioctl son del tipo IstioOperator el cual no es compatible con el yaml standard de k8s, de hecho si intentamos instalarlo con kubectl, nos lo indica y no nos permite la instalación.
IstioOperator es el operador compatible con k8s que utiliza la herramienta istioctl que como comentamos previamente sustituye a helm que se encuentra en proceso de deprecación desde la release 1.4
En https://istio.io/docs/reference/config/istio.operator.v1alpha1/ podeis consultar todas las opciones de IstioOperator.
Mediante el siguiente comando podemos generar un yaml compatible con k8s e instalable por lo tanto en cualquier cluster que admita kubernetes. Puntualizar que voy a utilizar el perfil demo ya que el despliegue se realizará en minikube pero para un cluster real sería lo mismo pero usando istio-perfil-default.yaml. En cuanto a la propiedad que indico es debido a que minikube es un cluster que no admite token de terceros y por eso ha de indicarse el valor first-party-jwt parsa la propiedad values.global.jwtPolicy.
El yaml generado istio-configuration-demo.yaml si que es compatible con k8s
Y podemos instalarlo con kubectl sin problemas en nuestro cluster.
Y con los todos los pods necesarios
Por último es importante indicar, que una vez instalado istio y antes de desplegar nuestros microservicios, debemos indicar el namespace de nuestras aplicaciones, para permitir la inyección automática de los sidecar-proxy.
kubectl label namespace default istio-injection=enabled
En éste caso se indica a default como namespace pero debeis indicar el vuestro en caso de ser otro.