Articles — Alexandre Vazquez

Apache NetBeans sigue siendo mi opción preferida para el desarrollo en Java

2022-05-062021-06-22 por Alexandre Vazquez

Descubre cuáles son las razones por las que, para mí, Apache NetBeans sigue siendo el mejor IDE de Java que puedes usar

Permíteme empezar desde el principio. Siempre he sido un Desarrollador Java desde mi tiempo en la Universidad. Aunque primero aprendí otro lenguaje de programación menos conocido (Modula-2), rápidamente pasé a Java para hacer todas las diferentes tareas y prácticamente cada tarea en mi camino como estudiante y luego como ingeniero de software.

Siempre estaba buscando el mejor IDE que pudiera encontrar para acelerar mis tareas de programación. La principal opción era Eclipse en la universidad, pero nunca fui fan de Eclipse, y eso se convirtió en un problema.

Si estás en la industria del Software Empresarial, habrás notado que prácticamente todas las herramientas basadas en Desarrolladores están basadas en Eclipse porque su licencia y la comunidad detrás lo hacen la mejor opción. Pero nunca pensé que Eclipse fuera un gran IDE, era demasiado flexible pero al mismo tiempo demasiado complejo.

Así que en ese momento es cuando descubrí NetBeans. Creo que la primera versión que probé fue en la rama 3.x, y Sun Microsystem lo desarrolló en ese momento. Era mucho mejor que Eclipse. De hecho, la cantidad de plugins disponibles no era comparable con Eclipse, pero las cosas que hacía, las hacía increíblemente bien.

Para mí, si necesito declarar por qué en ese momento NetBeans era mejor que Eclipse, probablemente las principales cosas serían estas:

Simplicidad en la Configuración de Ejecución: Aún creo que la mayoría de los IDE de Java hacen las cosas demasiado complejas solo para ejecutar el código. NetBeans simplemente ejecuta sin necesidad de crear una Configuración de Ejecución y configurarla (puedes hacerlo, pero no estás obligado a hacerlo)
Mejor Apariencia: Esto se basa más en una preferencia personal, pero prefiero la configuración predeterminada de NetBeans en comparación con Eclipse.

Así que por eso, NetBeans se convirtió en mi aplicación predeterminada para hacer mi Programación Java, pero Oracle llegó, y las cosas cambiaron un poco. Con la adquisición de Sun Microsystems por parte de Oracle, NetBeans se estancó como muchos otros proyectos de código abierto. Durante años no hubo muchas actualizaciones y progreso.

No es que hayan dejado de lado el producto, pero Oracle tenía un IDE diferente en ese momento, JDeveloper, que era la opción principal. Esto es fácil de entender. Continué siendo leal a NetBeans incluso cuando teníamos otro gran competidor: IntelliJ IDEA.

Esta es la opción elegante, la que la mayoría de los desarrolladores usan hoy en día para la programación en Java, y puedo entender por qué. He intentado varias veces en mi idea tratar de sentir las mismas sensaciones que otros tuvieron, y pude leer los diferentes artículos, y reconozco algunas de las ventajas de la solución:

Mejor rendimiento: Está claro que el tiempo de respuesta del IDE es mejor con IntelliJ IDEA que con NetBeans porque no proviene de un viaje de casi 20 años, y pudo comenzar desde cero y usar enfoques modernos para la GUI.
Menos Recursos de Memoria: Seamos honestos: Todos los IDE consumen toneladas de memoria. Ninguno lo hace genial aquí (a menos que estés hablando de editores de texto con compilador de Java; esa es otra historia). NetBeans de hecho requiere más recursos para funcionar correctamente.

Así que, hice el cambio y comencé a usar la solución de JetBrains, pero nunca me convenció, porque para mí sigue siendo demasiado complejo. Muchas cosas elegantes, pero menos enfoque en las que necesito. O, simplemente porque estaba demasiado acostumbrado a cómo NetBeans hace las cosas, no pude hacer el cambio mental que se requiere para adoptar una nueva herramienta.

Y entonces… cuando todo parecía perdido, algo increíble sucedió: NetBeans fue donado a la Fundación Apache y se convirtió en Apache NetBeans. Parece una nueva vida para la herramienta proporcionando cosas simples como el Modo Oscuro y manteniendo la solución actualizada con el progreso en el Desarrollo de Java.

Así que, hoy, Apache NetBeans sigue siendo mi IDE preferido, y no podría recomendar más el uso de esta increíble herramienta. Y estos son los puntos principales que me gustaría destacar aquí:

Mejor Gestión de Maven: Para mí, la forma y la simplicidad con la que puedes gestionar tu proyecto Maven con NetBeans está fuera de esta liga. Es simple y se enfoca en el rendimiento, agregando una nueva dependencia sin ir al archivo pom.xml, actualizando dependencias sobre la marcha.
Configuración de Ejecución: Nuevamente, esto sigue siendo un diferenciador. Cuando estoy codificando algo rápido debido a un nuevo tipo de utilidad, no me gusta perder tiempo creando configuraciones de ejecución o agregando un plugin maven exec a mi pom.xml para ejecutar el software que acabo de codificar. En su lugar, necesito hacer clic en Ejecutar, un botón verde, y dejar que la magia comience.
No hay necesidad de todo lo demás: Las cosas evolucionan demasiado rápido en el mundo de la programación Java, pero incluso hoy, nunca siento que me falte alguna capacidad o algo en mi IDE NetBeans que podría obtener si me muevo a una alternativa más moderna. Así que, no hay concesiones aquí a este nivel.

Así que, soy consciente de que probablemente mi elección se deba a que tengo una visión sesgada de esta situación. Después de todo, esta ha sido mi solución principal durante más de una década, y simplemente estoy acostumbrado a ella. Pero me considero una persona abierta, y si viera una diferencia clara, no tendría dudas en abandonar NetBeans como lo hice con muchas otras soluciones en el pasado (Evernote, OneNote, Apple Mail, Gmail, KDE Basket, Things, Wunderstling.. )

Así que, si tienes curiosidad por ver cómo ha progresado Apache NetBeans, por favor echa un vistazo a la última versión y dale una oportunidad. O, si sientes que no conectas con la herramienta actual, dale una oportunidad de nuevo. ¡¡¡Quizás tengas la misma visión sesgada que yo!!!

Portainer: Un software visionario y un viaje de evolución

2026-01-272021-06-14 por Alexandre Vazquez

Descubre el estado actual de las primeras interfaces gráficas para contenedores docker y cómo proporciona una solución para las plataformas de contenedores modernas

Quiero comenzar este artículo con una historia que no estoy seguro de que todos ustedes, increíbles lectores, conozcan. Hubo un tiempo en que no había interfaces gráficas para monitorear tus contenedores. Fue hace mucho tiempo, entendiendo mucho tiempo como podemos hacerlo en el mundo de los contenedores. Tal vez esto fue en 2014-2015 cuando Kubernetes estaba en su etapa inicial, y también, Docker Swarm acababa de ser lanzado y parecía la solución más confiable.

Así que la mayoría de nosotros no teníamos una plataforma de contenedores como tal. Simplemente ejecutábamos nuestros contenedores desde nuestras propias laptops o pequeños servidores para empresas de vanguardia usando comandos de docker directamente y sin más ayuda que la herramienta CLI. Como puedes ver, las cosas han cambiado mucho desde entonces, y si te gustaría refrescar esa visión, puedes consultar el artículo compartido a continuación:

Discover Your Perfect Tool for Managing Kubernetes

Maximizing the productivity of working with Kubernetes Environment with a tool for each persona Photo by Christina @ wocintechchat.com on Unsplash We all know that Kubernetes is the default environment for all our new applications we developed we will build. The flavor of that Kubernetes platform can be of different ways and forms, but one thing is […]

Y en ese momento, un proyecto de código abierto proporciona la solución más increíble porque no sabíamos que necesitábamos eso hasta que lo usamos, y esa opción era portainer. Portainer proporciona una interfaz web muy impresionante donde puedes ver todos los contenedores docker desplegados en tu host docker y desplegar como otra plataforma.

Fue el primero y generó un impacto tremendo, incluso generó una serie de otros proyectos que fueron nombrados: el portainer de… como dodo el portainer de la infraestructura de Kubernetes en ese momento.

Pero tal vez te preguntes… ¿y cómo está portainer? ¿sigue siendo portainer una cosa? Sigue vivo y coleando, como puedes ver en su página de proyecto de GitHub: https://github.com/portainer/portainer, con el último lanzamiento a finales de mayo de 2021.

Ahora tienen una versión Business pero aún como Community Edition, que es la que voy a estar analizando aquí con más detalle en otro artículo. Aún así, me gustaría proporcionar algunos aspectos destacados iniciales:

El proceso de instalación sigue el mismo enfoque que los lanzamientos iniciales para ser otro componente de tu clúster. Las opciones para ser utilizadas en Docker, Docker Swarm o Kubernetes cubren todas las soluciones principales que todas las empresas utilizan.

Welcome | Portainer Documentation

Ahora proporciona una lista de plantillas de aplicaciones similar a la lista del Catálogo de Openshift, y también puedes crear las tuyas propias. Esto es muy útil para las empresas que suelen depender de estas plantillas para permitir a los desarrolladores usar un enfoque común de despliegue sin necesidad de hacer todo el trabajo.

Las capacidades de Gestión de Equipos pueden definir usuarios con acceso a la plataforma y agrupar a esos usuarios como parte del equipo para una gestión de permisos más granular.
Soporte multi-registro: Por defecto, se integrará con Docker Hub, pero también puedes agregar tus propios registros y poder extraer imágenes directamente de esos directamente desde la GUI.

En resumen, esta es una gran evolución de la herramienta portainer mientras mantiene el mismo espíritu que todos los antiguos usuarios amaban en ese momento: Simplicidad y Enfoque en lo que un Administrador o Desarrollador necesita saber, pero también agregando más características y capacidades para mantener el ritmo de la evolución en la industria de plataformas de contenedores.

📚 Want to dive deeper into Kubernetes? This article is part of our comprehensive Kubernetes Architecture Patterns guide, where you’ll find all fundamental and advanced concepts explained step by step.

Promtail: Conecta Registros y Métricas en Tu Monitorización

2026-04-212021-06-08 por Alexandre Vazquez

Promtail es la solución cuando necesitas proporcionar métricas que solo están presentes en los rastros de registro del software que necesitas monitorear para proporcionar una plataforma de monitoreo consistente

Es un entendimiento común que tres pilares en el mundo de la observabilidad nos ayudan a obtener una vista completa del estado de nuestras propias plataformas y sistemas: Registros, Trazas y Métricas.

Para proporcionar un resumen de las diferencias entre cada uno de ellos:

Las métricas son los contadores sobre el estado de los diferentes componentes desde una vista técnica y de negocio. Así que aquí podemos ver cosas como el consumo de CPU, el número de solicitudes, el uso de memoria o disco…
Los registros son los diferentes mensajes que cada una de las piezas de software en nuestra plataforma proporciona para entender su comportamiento actual y detectar algunas situaciones no esperadas.
La traza es la diferente información sobre el flujo de solicitudes de extremo a extremo a través de la plataforma con los servicios y sistemas que han sido parte de ese flujo y datos relacionados con esa solicitud concreta.

Tenemos soluciones que afirman abordar todos ellos, principalmente en el software empresarial con Dynatrace, AppDynamics y similares. Y por otro lado, intentamos ir con una solución específica para cada uno de ellos que podamos integrar fácilmente juntos y hemos discutido mucho sobre esas opciones en artículos anteriores.

Pero, algunas situaciones en ese software no funcionan siguiendo este camino porque vivimos en la era más heterogénea. Todos abrazamos, en algún nivel, el enfoque políglota en las nuevas plataformas. En algunos casos, podemos ver que el software está utilizando rastros de registro para proporcionar datos relacionados con métricas u otros asuntos, y aquí es cuando necesitamos confiar en piezas de software que nos ayuden a «arreglar» esa situación, y Promtail hace específicamente eso.

Promtail es principalmente un reenviador de registros similar a otros como fluentd o fluent-bit de CNCF o logstash del stack ELK. En este caso, esta es la solución de Grafana Labs, y como puedes imaginar, esto es parte del stack de Grafana con Loki para ser el «cerebro» que cubrimos en este artículo que te recomiendo que eches un vistazo si aún no lo has leído:

Promtail tiene dos formas principales de comportarse como parte de esta arquitectura, y la primera es muy similar a otras en este espacio, como comentamos antes. Nos ayuda a enviar nuestros rastros de registro desde nuestros contenedores a la ubicación central que principalmente será Loki y puede ser una diferente y proporcionar las opciones habituales para jugar y transformar esos rastros como podemos hacer en otras soluciones. Puedes ver todas las opciones en el enlace a continuación, pero como puedes imaginar, esto incluye transformación, filtrado, análisis, y así sucesivamente.

Stages

Stages Esta seccion es una colección de todas las etapas Sopportas en una tuberá. Parsing etapas: docker: Extraer datos parsendo la linea de log usando la …

Pero lo que hace a promtail tan diferente es solo una de las acciones que puedes hacer, y esa acción es metrics. Metrics proporciona una forma específica de, basado en los datos que estamos leyendo de los registros, crear métricas de Prometheus que un servidor de Prometheus puede recolectar. Eso significa que puedes usar los rastros de registro que estás procesando que pueden ser algo como esto:

[2021–06–06 22:02.12] Nueva solicitud recibida para customer_id: 123

[2021–06–06 22:02.12] Nueva solicitud recibida para customer_id: 191

[2021–06–06 22:02.12] Nueva solicitud recibida para customer_id: 52

Con esta información aparte de enviar esas métricas a la ubicación central para crear una llamada de métrica, por ejemplo: `total_request_count` que será generada por el agente promtail y también expuesta por él y siendo capaz también de usar un enfoque de métricas incluso para sistemas o componentes que no proporcionan una forma estándar de hacer eso como una API de métricas formal.

Y la forma de hacer esto está muy bien integrada con la configuración. Esto se hace con una etapa adicional (así es como llamamos a las acciones que podemos hacer en Promtail) que se llama metrics.

El esquema de esa etapa de métrica es sencillo, y si estás familiarizado con Prometheus, verás lo directo que es desde una definición de métricas de Prometheus a este fragmento:

# Un mapa donde la clave es el nombre de la métrica y el valor es un tipo de
# métrica específico.
metrics:
  [<string>: [ <metric_counter> | <metric_gauge> | <metric_histogram> ] ...]

Así que comenzamos definiendo el tipo de métricas que nos gustaría definir, y tenemos las habituales: contador, gauge o histograma, y para cada uno de ellos, tenemos un conjunto de opciones para poder declarar nuestras métricas como puedes ver aquí para una Métrica de Contador

# El tipo de métrica. Debe ser Counter.
type: Counter

# Describe la métrica.

[description: <string>]

# Define un nombre de prefijo personalizado para la métrica. Si no está definido, el nombre predeterminado «promtail_custom_» será prefijado.

[prefix: <string>]

# Clave del mapa de datos extraídos para usar en la métrica, # por defecto al nombre de la métrica si no está presente.

[source: <string>]

# Los valores de las etiquetas en las métricas son dinámicos, lo que puede causar que las métricas exportadas se vuelvan obsoletas (por ejemplo, cuando un flujo deja de recibir registros). # Para prevenir el crecimiento ilimitado del endpoint /metrics, cualquier métrica que no haya sido actualizada dentro de este tiempo será eliminada. # Debe ser mayor o igual a ‘1s’, si no está definido el valor predeterminado es ‘5m’

[max_idle_duration: <string>]

config: # Si está presente y es verdadero, todas las líneas de registro serán contadas sin # intentar coincidir la fuente con el mapa extraído. # Es un error especificar `match_all: true` y también especificar un `value`

[match_all: <bool>]

# Si está presente y es verdadero, todos los bytes de la línea de registro serán contados. # Es un error especificar `count_entry_bytes: true` sin especificar `match_all: true` # Es un error especificar `count_entry_bytes: true` sin especificar `action: add`

[count_entry_bytes: <bool>]

# Filtra los datos de origen y solo cambia la métrica # si el valor objetivo coincide exactamente con la cadena proporcionada. # Si no está presente, todos los datos coincidirán.

[value: <string>]

# Debe ser «inc» o «add» (insensible a mayúsculas). Si # se elige inc, el valor de la métrica aumentará en 1 por cada # línea de registro recibida que pase el filtro. Si se elige add, # el valor extraído debe ser convertible a un flotante positivo # y su valor se sumará a la métrica. action: <string>

Y con eso, tendrás tu métrica creada y expuesta, solo esperando que un servidor de Prometheus la recolecte. Si te gustaría ver todas las opciones disponibles, toda esta documentación está disponible en la documentación de Grafana Labs que puedes consultar en el enlace:

metrics

metrics stage The metrics stage is an action stage that allows for defining and updating metrics based on data from the extracted map. Note that created …

Espero que encuentres esto interesante y una forma útil de mantener toda tu información de observabilidad gestionada correctamente usando la solución adecuada y proporcionar una solución para estas piezas de software que no siguen tu paradigma.

Mejora tu estrategia de implementación con Canarying en Kubernetes

2026-01-142021-05-04 por Alexandre Vazquez

Ahorra tiempo y dinero en tu plataforma de aplicaciones implementando aplicaciones de manera diferente en Kubernetes.

Venimos de una época en la que implementamos una aplicación utilizando un proceso aparente y lineal. La forma tradicional es más o menos así:

Esperar hasta un fin de semana o algún momento en que la carga sea baja y el negocio pueda tolerar cierta indisponibilidad del servicio.
Programamos el cambio y avisamos a todos los equipos involucrados para que estén listos para gestionar el impacto.
Implementamos la nueva versión y tenemos a todos los equipos durante la prueba funcional que necesitan hacer para asegurarse de que funciona bien, y esperamos a que ocurra la carga real.
Monitoreamos durante las primeras horas para ver si ocurre algo malo, y en caso de que sí, establecemos un proceso de reversión.
Tan pronto como todo va bien, esperamos hasta el próximo lanzamiento en 3-4 meses.

Pero esto ya no es válido. El negocio exige que TI sea ágil, cambie rápidamente y no pueda permitirse hacer ese tipo de esfuerzo de recursos cada semana o, peor aún, cada día. ¿Crees que es posible reunir a todos los equipos cada noche para implementar los últimos cambios? No es factible en absoluto. Entonces, la tecnología avanza para ayudarnos a resolver mejor ese problema, y aquí es donde Canarying vino a ayudarnos.

Introducción a los Despliegues Canary

Los despliegues canary (o simplemente Canarying, como prefieras) no son algo nuevo, y mucha gente ha estado hablando mucho sobre ello:

bliki: CanaryRelease

A canary release occurs when you roll out a new version of some software to a small subset of your user base to see if there are any problems before you make it available to everyone.

Google - Site Reliability Engineering

Release engineering is a term we use to describe all the processes and artifacts related to getting code from a repository into a running production system. Automating releases can help avoid many of the traditional pitfalls associated with release engineering: the toil of repetitive and manual task…

Ha estado aquí por algún tiempo, pero antes no era ni fácil ni práctico implementarlo. Básicamente se basa en implementar la nueva versión en producción, pero aún manteniendo el tráfico apuntando a la versión antigua de la aplicación y solo comienzas a desviar parte del tráfico a la nueva versión.

Basado en ese pequeño subconjunto de solicitudes, monitoreas cómo se desempeña la nueva versión en diferentes niveles, nivel funcional, nivel de rendimiento, etc. Una vez que te sientes cómodo con el rendimiento que está proporcionando, simplemente desvías todo el tráfico a la nueva versión y deprecias la versión antigua.

Los beneficios que vienen con este enfoque son enormes:

No necesitas un gran entorno de pruebas como antes porque puedes hacer algunas de las pruebas con datos reales en producción sin afectar tu negocio y la disponibilidad de tus servicios.
Puedes reducir el tiempo de comercialización y aumentar la frecuencia de los despliegues porque puedes hacerlo con menos esfuerzo y personas involucradas.
Tu ventana de despliegue se ha extendido mucho ya que no necesitas esperar una ventana de tiempo específica, y debido a eso, puedes implementar nuevas funcionalidades con más frecuencia.

Implementando Despliegue Canary en Kubernetes

Para implementar Despliegue Canary en Kubernetes, necesitamos proporcionar más flexibilidad en cómo se enruta el tráfico entre nuestros componentes internos, que es una de las capacidades que se extienden al usar un Service Mesh. Ya discutimos los beneficios de usar un Service Mesh como parte de tu entorno, pero si deseas volver a echar un vistazo, por favor consulta este artículo:

Technology wars: API Management Solution vs Service Mesh

Service Mesh vs. API Management Solution: is it the same? Are they compatible? Are they rivals? Photo by Alvaro Reyes on Unsplash When we talk about communication in a distributed cloud-native world and especially when we are talking about container-based architectures based on Kubernetes platform like AKS, EKS, Openshift, and so on, two technologies generate a lot […]

Tenemos varios componentes tecnológicos que pueden proporcionar esas capacidades, pero así es como podrás crear las rutas de tráfico para implementar esto. Para ver cómo puedes echar un vistazo al siguiente artículo sobre una de las opciones predeterminadas que es Istio:

Integrating Istio with BWCE Applications

Introduction Services Mesh is one the “greatest new thing” in our PaaS environments. No matter if you’re working with K8S, Docker Swarm, pure-cloud with EKS or AWS, you’ve heard and probably tried to know how can be used this new thing that has so many advantages because it provides a lot of options in handling […]

Pero poder enrutar el tráfico no es suficiente para implementar un enfoque completo de despliegue canary. También necesitamos poder monitorear y actuar en base a esas métricas para evitar la intervención manual. Para hacer esto, necesitamos incluir diferentes herramientas para proporcionar esas capacidades: Prometheus es la opción de facto para monitorear cargas de trabajo implementadas en el entorno de Kubernetes, y aquí puedes obtener más información sobre cómo ambos proyectos trabajan juntos.

Kubernetes Service Discovery for Prometheus

In previous posts, we described how to set up Prometheus to work with your TIBCO BusinessWorks Container Edition apps, and you can read more about it here. In that post, we described that there were several ways to update Prometheus about the services that ready to monitor. And we choose the most simple at that […]

Y para gestionar el proceso general, puedes tener una herramienta de Despliegue Continuo para poner algo de gobernanza alrededor de eso usando opciones como Spinnaker o usando alguna de las extensiones para las herramientas de Integración Continua como GitLab o GitHub:

Using Spinnaker for Automated Canary Analysis

Automated canary analysis lets you partially roll out a change then evaluate it against the current deployment to assess its performance.

Resumen

En este artículo, cubrimos cómo podemos evolucionar un modelo de despliegue tradicional para mantener el ritmo de la innovación que los negocios requieren hoy y cómo las técnicas de despliegue canary pueden ayudarnos en ese viaje, y los componentes tecnológicos necesarios para configurar esta estrategia en tu propio entorno.

Opciones mejoradas de AutoScaling para aplicaciones impulsadas por eventos

2026-01-142021-04-12 por Alexandre Vazquez

KEDA proporciona un entorno rico para escalar su aplicación aparte del enfoque tradicional de HPA usando CPU y Memoria

El escalado automático es una de las grandes ventajas de los entornos nativos de la nube y nos ayuda a proporcionar un uso optimizado de las operaciones. Kubernetes ofrece muchas opciones para hacerlo, siendo una de ellas el enfoque del Escalador Automático de Pods Horizontal (HPA). HPA es la forma en que Kubernetes detecta si es necesario escalar alguno de los pods, y se basa en métricas como el uso de CPU o memoria. https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/ A veces esas métricas no son suficientes para decidir si el número de réplicas que tenemos disponibles es suficiente. Otras métricas pueden proporcionar una mejor perspectiva, como el número de solicitudes o el número de eventos pendientes.

Escalado Automático Basado en Eventos de Kubernetes (KEDA)

Aquí es donde KEDA viene a ayudar. KEDA significa Escalado Automático Basado en Eventos de Kubernetes y proporciona un enfoque más flexible para escalar nuestros pods dentro de un clúster de Kubernetes. Se basa en escaladores que pueden implementar diferentes fuentes para medir el número de solicitudes o eventos que recibimos de diferentes sistemas de mensajería como Apache Kafka, AWS Kinesis, Azure EventHub y otros sistemas como InfluxDB o Prometheus. KEDA funciona como se muestra en la imagen a continuación:

Tenemos nuestro ScaledObject que vincula nuestra fuente de eventos externa (es decir, Apache Kafka, Prometheus ..) con el Despliegue de Kubernetes que nos gustaría escalar y registrar eso en el clúster de Kubernetes. KEDA monitoreará la fuente externa y, basado en las métricas recopiladas, comunicará al Escalador Automático de Pods Horizontal para escalar la carga de trabajo según lo definido.

Probando el Enfoque con un Caso de Uso

Entonces, ahora que sabemos cómo funciona, haremos algunas pruebas para verlo en vivo. Vamos a mostrar cómo podemos escalar rápidamente una de nuestras aplicaciones usando esta tecnología. Y para hacer eso, lo primero que necesitamos hacer es definir nuestro escenario. En nuestro caso, el escenario será una aplicación nativa de la nube simple desarrollada usando una aplicación Flogo que expone un servicio REST. El primer paso que necesitamos hacer es desplegar KEDA en nuestro clúster de Kubernetes, y hay varias opciones para hacerlo: gráficos Helm, Operación o archivos YAML. En este caso, vamos a usar el enfoque de gráficos Helm. Entonces, vamos a escribir los siguientes comandos para agregar el repositorio helm y actualizar los gráficos disponibles, y luego desplegar KEDA como parte de nuestra configuración de clúster:

helm repo add kedacore https://kedacore.github.io/charts
helm repo update
helm install keda kedacore/keda

Después de ejecutar este comando, KEDA se despliega en nuestro clúster K8S, y al escribir el siguiente comando kubectl get all proporcionará una situación similar a esta:

pod/keda-operator-66db4bc7bb-nttpz 2/2 Running 1 10m
pod/keda-operator-metrics-apiserver-5945c57f94-dhxth 2/2 Running 1 10m

Ahora, vamos a desplegar nuestra aplicación. Como ya se comentó, para hacerlo vamos a usar nuestra Aplicación Flogo, y el flujo será tan simple como este:

La aplicación expone un servicio REST usando /hello como el recurso.
Las solicitudes recibidas se imprimen en la salida estándar y se devuelve un mensaje al solicitante

Una vez que tenemos nuestra aplicación desplegada en nuestra aplicación de Kubernetes, necesitamos crear un ScaledObject que sea responsable de gestionar la escalabilidad de ese componente:

Usamos Prometheus como un disparador, y debido a eso, necesitamos configurar dónde está alojado nuestro servidor Prometheus y qué consulta nos gustaría hacer para gestionar la escalabilidad de nuestro componente. En nuestro ejemplo, usaremos el flogo_flow_execution_count que es la métrica que cuenta el número de solicitudes que son recibidas por este componente, y cuando esto tiene una tasa superior a 100, lanzará una nueva réplica. Después de golpear el servicio con una Prueba de Carga, podemos ver que tan pronto como el servicio alcanza el umbral, lanza una nueva réplica para comenzar a manejar solicitudes como se esperaba.

Todo el código y los recursos están alojados en el repositorio de GitHub que se muestra a continuación: https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/

Resumen

Este post ha mostrado que tenemos opciones ilimitadas para decidir las opciones de escalabilidad para nuestras cargas de trabajo. Podemos usar las métricas estándar como CPU y memoria, pero si necesitamos ir más allá, podemos usar diferentes fuentes externas de información para activar ese escalado automático.

Arquitectura Orientada a Eventos: Mejorando la Capacidad de Respuesta de su Empresa para Tener Éxito

2022-09-152021-04-06 por Alexandre Vazquez

La arquitectura impulsada por eventos proporciona más agilidad para enfrentar los cambios de un ecosistema de clientes más exigente.

Tabla de contenidos

¿Qué es un Evento?
EDA vs Arquitecturas Tradicionales
Capas de una Arquitectura Impulsada por Eventos
Resumen

El mercado está cambiando a una velocidad que requiere estar listo para cambiar muy rápidamente, los clientes se están volviendo cada vez más exigentes y necesitamos ser capaces de entregar lo que esperan, y para hacerlo necesitamos una arquitectura que sea lo suficientemente receptiva para poder adaptarse al ritmo que se requiere.

Las arquitecturas impulsadas por eventos (generalmente conocidas como EDA) son arquitecturas donde los eventos son la parte crucial y diseñamos componentes listos para manejar esos eventos de la manera más eficiente. Una arquitectura que está lista para reaccionar a lo que sucede a nuestro alrededor en lugar de simplemente establecer un camino específico para nuestros clientes.

Este enfoque proporciona muchos beneficios a las empresas debido a sus características, pero al mismo tiempo requiere una mentalidad diferente y un conjunto diferente de componentes en su lugar.

¿Qué es un Evento?

Comencemos por el principio. Un evento es cualquier cosa que pueda suceder y que sea importante para ti. Si piensas en un escenario donde un usuario simplemente está navegando por un sitio web de comercio electrónico, todo lo que tiene es un evento. Si llegamos al sitio de comercio electrónico porque tenía un enlace de referencia, eso es un evento.

Los eventos no solo ocurren en la vida virtual, sino también en la vida real. Una persona que simplemente entra al vestíbulo del hotel es un evento, ir frente al mostrador de recepción para hacer el check-in es otro, simplemente caminar a su habitación es otro… todo es un evento.

Los eventos en aislamiento proporcionan una pequeña pieza de información, pero juntos pueden proporcionar mucha información valiosa sobre los clientes, sus preferencias, sus expectativas y también sus necesidades. Y todo eso nos ayudará a proporcionar la experiencia más personalizada a cada uno de nuestros clientes.

EDA vs Arquitecturas Tradicionales

Las arquitecturas tradicionales funcionan en modo pull, lo que significa que un consumidor envía una solicitud a un servicio, ese servicio necesita otros componentes para hacer la lógica, obtiene la respuesta y responde. Todo está predefinido.

Los eventos funcionan de manera diferente porque operan en modo push, los eventos se envían y eso es todo, podría desencadenar una acción, muchas acciones o ninguna. Tienes una serie de componentes esperando, escuchando hasta que el evento o la secuencia de eventos que necesitan activar aparece frente a ellos y cuando lo hace, simplemente activa su lógica y como parte de esa ejecución genera uno o más eventos para poder ser consumidos nuevamente.

Para poder construir una arquitectura impulsada por eventos, lo primero que necesitamos es tener componentes impulsados por eventos. Necesitamos componentes de software que se activen en función de eventos y también generen eventos como parte de su lógica de procesamiento. Al mismo tiempo, esta secuencia de eventos también se convierte en la forma de completar flujos complejos en un modo de cooperación sin la necesidad de un componente maestro que esté al tanto de todo el flujo de principio a fin.

Simplemente tienes componentes que saben que cuando sucede esto, necesitan hacer su parte del trabajo y otros componentes escucharán la salida de esos componentes y se activarán.

Este enfoque se llama Coreografía porque funciona de la misma manera en una compañía de ballet donde cada uno de los bailarines puede estar haciendo diferentes movimientos, pero cada uno de ellos sabe exactamente lo que debe hacer y todos juntos en sincronía generan la pieza completa.

Capas de una Arquitectura Impulsada por Eventos

Ahora que tenemos componentes de software que se activan usando eventos, necesitamos alguna estructura alrededor de eso en nuestra arquitectura para cubrir todas las necesidades en la gestión de los eventos, por lo que necesitamos manejar las siguientes capas:

Ingesta de Eventos: Necesitamos una serie de componentes que nos ayuden a introducir y recibir eventos en nuestros sistemas. Como explicamos, hay toneladas y toneladas de formas de enviar eventos, por lo que es importante que ofrezcamos flexibilidad y opciones en ese proceso. Los adaptadores y las API son cruciales aquí para asegurarse de que todos los eventos puedan ser recopilados y formar parte del sistema.
Distribución de Eventos: Necesitamos un Bus de Eventos que actúe como nuestro Océano de Eventos donde todos los eventos fluyen para poder activar todos los componentes que están escuchando ese evento.
Procesamiento de Eventos: Necesitamos una serie de componentes para escuchar todos los eventos que se envían y hacerlos significativos. Estos componentes deben actuar como guardias de seguridad: Filtran los eventos que no son importantes, también enriquecen los eventos que reciben con información de contexto de otros sistemas o fuentes de datos, y transforman el formato de algunos eventos para que sea fácil de entender para todos los componentes que están esperando esos eventos.
Acción de Eventos: Necesitamos una serie de componentes que escuchen esos eventos y estén listos para reaccionar a lo que se ve en el Bus de Eventos tan pronto como detecten que esperan comenzar a hacer su lógica y enviar la salida nuevamente al bus para ser utilizada por alguien más.

Resumen

La arquitectura impulsada por eventos puede proporcionar un ecosistema mucho más ágil y flexible donde las empresas pueden abordar los desafíos actuales para ofrecer una experiencia atractiva a los usuarios y clientes y al mismo tiempo proporcionar más agilidad a los equipos técnicos al poder crear componentes que trabajen en colaboración pero acoplados de manera flexible, haciendo que los componentes y los equipos sean más autónomos.

Verificación de Salud de Kubernetes: Cómo Hacerlo Más Simple

2026-01-142021-04-02 por Alexandre Vazquez

KubeEye te apoya en la tarea de asegurar que tu clúster esté funcionando bien y asegurar que se sigan todas tus mejores prácticas.

Kubernetes se ha convertido en la nueva norma para desplegar nuestras aplicaciones y otras opciones sin servidor, por lo que la administración de estos clústeres se ha vuelto crítica para la mayoría de las empresas, y realizar una Verificación de Salud de Kubernetes adecuada se está volviendo crítico.

Esta tarea está clara que no es una tarea fácil. Como siempre, la flexibilidad y el poder que la tecnología proporciona a los usuarios (en este caso, los desarrolladores) también viene con una compensación con la complejidad de la operación y gestión. Y esto no es una excepción a eso.

Hemos evolucionado, incluyendo opciones gestionadas que simplifican toda la configuración subyacente y la gestión de bajo nivel de la infraestructura detrás de ella. Sin embargo, hay muchas cosas que deben hacerse para que la administración del clúster tenga una experiencia feliz en el viaje de un Administrador de Kubernetes.

Muchos conceptos con los que lidiar: namespaces, límites de recursos, cuotas, ingreso, servicios, rutas, crd… Cualquier ayuda que podamos obtener es bienvenida. Y con este propósito en mente, KubeEye ha nacido.

GitHub – kubesphere/kubeeye: KubeEye aims to find various problems on Kubernetes, such as application misconfiguration, unhealthy cluster components and node problems.

KubeEye aims to find various problems on Kubernetes, such as application misconfiguration, unhealthy cluster components and node problems. – GitHub – kubesphere/kubeeye: KubeEye aims to find variou…

KubeEye es un proyecto de código abierto que ayuda a identificar algunos problemas en nuestros Clústeres de Kubernetes. Usando las palabras de sus creadores:

KubeEye tiene como objetivo encontrar varios problemas en Kubernetes, como la mala configuración de aplicaciones (usando Polaris), componentes de clúster no saludables y problemas de nodos (usando Node-Problem-Detector). Además de las reglas predefinidas, también admite reglas definidas por el usuario.

Así que podemos pensar en él como un compañero que está revisando el entorno para asegurarse de que todo esté bien configurado y saludable. Además, nos permite definir reglas personalizadas para asegurarnos de que todas las acciones que los diferentes equipos de desarrollo están realizando estén de acuerdo con los estándares predefinidos y las mejores prácticas.

Así que veamos cómo podemos incluir KubeEye para hacer una verificación de salud de nuestro entorno. Lo primero que necesitamos hacer es instalarlo. En este momento, KubeEye solo ofrece una versión para sistemas basados en Linux, por lo que si estás usando otros sistemas como yo, necesitas seguir otro enfoque y escribir los siguientes comandos:

git clone https://github.com/kubesphere/kubeeye.git
cd kubeeye
make install

Después de hacer eso, terminamos con un nuevo binario en nuestro PATH llamado `ke`, y este es el único componente necesario para trabajar con la aplicación. El segundo paso que necesitamos hacer para obtener más detalles sobre esos diagnósticos es instalar el componente detector de problemas de nodos.

Este componente es un componente instalado en cada nodo del clúster. Ayuda a hacer más visibles para las capas superiores los problemas relacionados con el comportamiento del clúster de Kubernetes. Este es un paso opcional, pero proporcionará datos más significativos, y para instalarlo, necesitamos ejecutar el siguiente comando.

ke install npd

Y ahora estamos listos para comenzar a verificar nuestro entorno, y el orden es tan fácil como este.

ke diag

Esto proporcionará una salida similar a esta que se compone de dos tablas diferentes. La primera se centrará en el Pod y los problemas y eventos planteados como parte del estado de la plataforma, y la otra se centrará en el resto de los elementos y tipos de objetos para los Clústeres de Kubernetes.

La tabla para los problemas a nivel de pod tiene los siguientes campos:

Namespace al que pertenece el pod.
Severidad del problema.
Nombre del Pod que es responsable del problema
Hora del Evento en la que se ha planteado este evento
Razón del problema
Mensaje con la descripción detallada del problema

La segunda tabla para los otros objetos tiene la siguiente estructura:

Namespace donde se despliega el objeto que tiene un problema que está siendo detectado.
Severidad del problema.
Nombre del componente
Tipo del componente
Hora en la que se ha planteado este problema
Mensaje con la descripción detallada del problema

La salida del comando también puede mostrar otras tablas si se detectan algunos problemas a nivel de nodo.

Hoy cubrimos un tema fascinante como es la Administración de Kubernetes e introducimos una nueva herramienta que ayuda en tu tarea diaria.

¡Realmente espero que esta herramienta pueda ser añadida a tu caja de herramientas y facilite el camino para una administración feliz y saludable del Clúster de Kubernetes!

Prometheus Storage: Optimiza el uso del disco en tu implementación con estos trucos

2026-01-142021-03-12 por Alexandre Vazquez

Descubre las propiedades que te permitirán un uso optimizado de tu almacenamiento en disco y ahorros al almacenar tus datos de monitoreo

Prometheus se ha convertido en un componente estándar en nuestras arquitecturas en la nube y el almacenamiento de Prometheus se está convirtiendo en un aspecto crítico. Así que voy a suponer que si estás leyendo esto ya sabes qué es Prometheus. Si este no es el caso, por favor tómate tu tiempo para echar un vistazo a otros artículos que he creado:

Prometheus Monitoring for Microservices using TIBCO

We’re living a world with constant changes and this is even more true in the Enterprise Application world. I’ll not spend much time talking about things you already know, but just say that the microservices architecture approach and the PaaS solutions have been a game-changer for all enterprise integration technologies. This time I’d like to […]

Kubernetes Service Discovery for Prometheus

Sabemos que usualmente cuando monitoreamos usando Prometheus tenemos tantos exportadores disponibles a nuestra disposición y también que cada uno de ellos expone muchas métricas muy relevantes que necesitamos para rastrear todo lo que necesitamos y que lleva a un uso muy intensivo del almacenamiento disponible si no lo gestionamos adecuadamente.

Hay dos factores que afectan esto. El primero es optimizar el número de métricas que estamos almacenando y ya proporcionamos consejos para hacerlo en otros artículos como los que se muestran a continuación:

How it optimize the disk usage in the Prometheus database?

Learn some tricks to analyze and optimize the usage that you are doing of the TSDB and save money on your cloud deployment. Photo by Markus Spiske on Unsplash In previous posts, we discussed how the storage layer worked for Prometheus and how effective it was. But in the current times, we are of cloud computing […]

El otro es cuánto tiempo almacenamos las métricas llamado el “período de retención en Prometheus.” Y esta propiedad ha sufrido muchos cambios durante las diferentes versiones. Si te gustaría ver toda la historia, por favor echa un vistazo a este artículo de Robust Perception:

Configuring Prometheus storage retention – Robust Perception | Prometheus Monitoring Experts

How can you control how much history Prometheus keeps?

Las principales propiedades que puedes configurar son las siguientes:

storage.tsdb.retention.time: Número de días para almacenar las métricas por defecto a 15d. Esta propiedad reemplaza la obsoleta storage.tsdb.retention.
storage.tsdb.retention.size: Puedes especificar el límite de tamaño a utilizar. Este no es un límite estricto sino un mínimo, así que por favor define algún margen aquí. Unidades soportadas: B, KB, MB, GB, TB, PB, EB. Ej: “512MB”. Esta propiedad es experimental hasta ahora como puedes ver en la documentación oficial:

https://prometheus.io/docs/prometheus/latest/storage

¿Qué tal configurar esta configuración en el operador para Kubernetes? En ese caso, también tienes opciones similares disponibles en el archivo de configuración values.yaml para el chart como puedes ver en la imagen a continuación:

Esto debería ayudarte a obtener un despliegue optimizado de Prometheus que asegure todas las características que tiene Prometheus pero al mismo tiempo un uso óptimo de los recursos a tu disposición.

Además de eso, también deberías revisar las opciones de Servicio Gestionado que algunos proveedores tienen respecto a Prometheus, como los Servicios Gestionados de Amazon para Prometheus, como puedes ver en el enlace a continuación:

Amazon Prometheus Service to Provide More Availability to Your Monitoring Solution

Learn what Amazon Managed Service for Prometheus provides and how you can benefit from it. Photo by Casey Horner on Unsplash Monitoring is one of the hot topics when we talk about cloud-native architectures. Prometheus is a graduated Cloud Native Computing Foundation (CNCF) open-source project and one of the industry-standard solutions when it comes to monitoring your […]

Loki vs ELK: Una alternativa ligera al stack ELK

2026-01-142021-03-08 por Alexandre Vazquez

Aprende sobre el nuevo sistema de agregación de logs escalable horizontalmente, altamente disponible y multi-inquilino inspirado en Prometheus que puede ser la mejor opción para tu arquitectura de registro

Loki vs ELK es algo que estás leyendo y escuchando cada vez más a menudo ya que desde hace algún tiempo hay un aumento en la disputa por convertirse en el estándar de facto para las arquitecturas de agregación de logs.

Cuando hablamos de Arquitectura Nativa de la Nube, la agregación de logs es algo clave que necesitas considerar. Las viejas prácticas que seguimos en el enfoque de máquinas virtuales on-premises para el registro ya no son válidas.

Ya cubrimos este tema en mi publicación anterior que te recomiendo echar un vistazo en caso de que no la hayas leído aún, pero este no es el tema de hoy.

Three reasons why you need a Log Aggregation Architecture today

Log Aggregation are not more a commodity but a critical component in container-based platforms Photo by Olav Ahrens Røtne on Unsplash Log Management doesn’t seem like a very fantastic topic. It is not the topic that you see and says: “Oh! Amazing! This is what I was dreaming about my whole life”. No, I’m aware that […]

Elasticsearch como el núcleo y las diferentes pilas derivadas como ELK/EFK han ganado popularidad en los últimos años, siendo prácticamente la opción predeterminada de código abierto cuando hablamos de agregación de logs y una de las opciones. Los principales proveedores de nube pública también han adoptado esta solución como parte de su propia oferta, como lo proporciona el Servicio de Elasticsearch de Amazon.

Pero Elasticsearch no es perfecto. Si ya lo has usado, probablemente lo sepas. Aún así, debido a que sus características son tan impresionantes, especialmente en las capacidades de búsqueda e indexación, ha sido el tipo de líder hoy en día. Pero otros temas como el uso del almacenamiento, la cantidad de poder que necesitas para manejarlo y la arquitectura con diferentes tipos de nodos (maestro, datos, ingestor) aumentan su complejidad para casos cuando necesitamos algo más pequeño.

Y para llenar este vacío es donde llega nuestro personaje principal para la publicación de hoy: Loki o Grafana Loki.

Loki es un sistema de gestión de logs creado como parte del proyecto Grafana, y ha sido creado con un enfoque diferente en mente que Elasticsearch.

Loki es un sistema de agregación de logs escalable horizontalmente, altamente disponible y multi-inquilino inspirado en Prometheus. Está diseñado para ser muy rentable y fácil de operar. No indexa el contenido de los logs, sino un conjunto de etiquetas para cada flujo de logs.

Así que, como podemos leer en la definición de su propia página arriba, cubre varios temas interesantes en comparación con Elasticsearch:

En primer lugar, aborda algunos de los puntos de dolor habituales para los clientes de ELK: Es muy rentable y fácil de operar.
Claramente dice que el enfoque no es el mismo que ELK, no vas a tener un índice completo de la carga útil para los eventos, sino que se basa en diferentes etiquetas que puedes definir para cada flujo de logs.
Prometheus inspira eso, lo cual es crítico porque permitió la idea de usar trazas de logs como métricas para potenciar nuestras soluciones de monitoreo.

Comencemos con las preguntas iniciales cuando mostramos una nueva tecnología interesante y nos gustaría comenzar a probarla.

¿Cómo puedo instalar Loki?

Loki se distribuye en diferentes versiones para ser instalado en tu entorno de la manera que lo necesites.

SaaS: proporcionado como parte de la solución de alojamiento de Grafana Cloud.
On-Premises: Proporcionado como un binario normal para descargar y ejecutar en modo on-premises.
Nube: Proporcionado como una imagen de Docker o incluso un Helm Chart para ser desplegado en tu entorno basado en Kubernetes.

Los equipos de GrafanaLabs también proporcionan Soporte Empresarial para Loki si deseas usarlo en modo de producción en tu empresa. Aún así, al mismo tiempo, todo el código está licenciado usando la Licencia Apache 2.0, por lo que puedes echar un vistazo a todo el código y contribuir a él.

¿Cómo funciona Loki?

En cuanto a la arquitectura, es muy similar a la pila ELK/EFK y sigue el mismo enfoque de “coleccionistas” e “indexadores” como tiene ELK:

Loki en sí mismo es el nodo central de la arquitectura responsable de almacenar las trazas de logs y sus etiquetas y proporciona una API para buscar entre ellas basándose en su propio lenguaje LogQL (un enfoque similar al PromQL de Prometheus).
promtail es el componente agente que se ejecuta en el borde obteniendo todas esas trazas de logs que necesitamos que pueden estar ejecutándose en una máquina on-prem o en un modo DaemonSet en nuestro propio clúster de Kubernetes. Desempeña el mismo papel que Logstash/Fluent-bit/Fluentd en la pila ELK/EFK. Promtail proporciona el modo de plugin habitual para filtrar y transformar nuestras trazas de logs como lo hacen las otras soluciones. Al mismo tiempo, proporciona una característica interesante para convertir esas trazas de logs en métricas de Prometheus que pueden ser recolectadas directamente por tu servidor Prometheus.
Grafana es la interfaz de usuario para toda la pila y desempeña un papel similar al de Kibana en la pila ELK/EFK. Grafana, entre otros plugins, proporciona integración directa con Loki como una fuente de datos para explorar esas trazas e incluirlas en los paneles.

Resumen

Grafana Loki puede ser una gran solución para tu arquitectura de registro para cubrir dos puntos: Proporcionar una solución de agregación de logs ligera para tu entorno y al mismo tiempo habilitar tus trazas de logs como una fuente para tus métricas, permitiéndote crear métricas detalladas, más orientadas al negocio que se utilizan en tus paneles y tus sistemas de monitoreo.

Linkerd como la solución para resolver tus desafíos de comunicación en la arquitectura de microservicios

2022-09-152021-02-23 por Alexandre Vazquez

El servicio Mesh Linkerd patrocinado por CNCF proporciona muchas características necesarias en las arquitecturas de microservicios actuales.

Si estás leyendo esto, probablemente ya estés al tanto de los desafíos que vienen con una arquitectura de microservicios. Podría ser porque estás leyendo sobre ellos o incluso porque los estás enfrentando ahora mismo en tu propia piel.

Uno de los desafíos más comunes es la red y la comunicación. Con la eclosión de muchos componentes que necesitan comunicación y el enfoque efímero de los desarrollos nativos de la nube, muchas características nuevas son una necesidad cuando en el pasado eran solo un «agradable de tener».

Conceptos como el registro de servicios y el descubrimiento de servicios, la autenticación de servicios, las políticas de enrutamiento dinámico y los patrones de disyuntor ya no son cosas que todas las empresas geniales están haciendo, sino algo básico para dominar la nueva arquitectura de microservicios como parte de una plataforma de arquitectura nativa de la nube, y aquí es donde el proyecto Service Mesh está aumentando su popularidad como una solución para la mayoría de estos desafíos y proporcionando estas características que se necesitan.

Si recuerdas, hace mucho tiempo, ya cubrí ese tema para presentar Istio como una de las opciones que tenemos:

Integrating Istio with BWCE Applications

Pero este proyecto creado por Google e IBM no es la única opción que tienes para proporcionar esas capacidades. Como parte de la Cloud Native Computing Foundation (CNCF), el proyecto Linkerd proporciona características similares.

Cómo instalar Linkerd

Para comenzar a usar Linkerd, lo primero que necesitamos hacer es instalar el software y para hacerlo. Necesitamos hacer dos instalaciones, una en el servidor de Kubernetes y otra en el host.

Para instalar en el host, necesitas ir a la página de lanzamientos y descargar la edición para tu sistema operativo e instalarla.

Estoy usando un sistema basado en Windows en mi ejemplo, así que uso chocolatey para instalar el cliente. Después de hacerlo, puedo ver la versión del CLI escribiendo el siguiente comando:

linkerd version

Y obtendrás una salida que dirá algo similar a esto:

PS C:WINDOWSsystem32> linkerd.exe version
Client version: stable-2.8.1
Server version: unavailable

Ahora necesitamos hacer la instalación en el servidor de Kubernetes, y para hacerlo, usamos el siguiente comando:

linkerd install | kubectl apply -f -

Y obtendrás una salida similar a esta:

PS C:WINDOWSsystem32> linkerd install | kubectl apply -f -
namespace/linkerd created
clusterrole.rbac.authorization.k8s.io/linkerd-linkerd-identity created
clusterrolebinding.rbac.authorization.k8s.io/linkerd-linkerd-identity created
serviceaccount/linkerd-identity created
clusterrole.rbac.authorization.k8s.io/linkerd-linkerd-controller created
clusterrolebinding.rbac.authorization.k8s.io/linkerd-linkerd-controller created
serviceaccount/linkerd-controller created
clusterrole.rbac.authorization.k8s.io/linkerd-linkerd-destination created
clusterrolebinding.rbac.authorization.k8s.io/linkerd-linkerd-destination created
serviceaccount/linkerd-destination created
role.rbac.authorization.k8s.io/linkerd-heartbeat created
rolebinding.rbac.authorization.k8s.io/linkerd-heartbeat created
serviceaccount/linkerd-heartbeat created
role.rbac.authorization.k8s.io/linkerd-web created
rolebinding.rbac.authorization.k8s.io/linkerd-web created
clusterrole.rbac.authorization.k8s.io/linkerd-linkerd-web-check created
clusterrolebinding.rbac.authorization.k8s.io/linkerd-linkerd-web-check created
clusterrolebinding.rbac.authorization.k8s.io/linkerd-linkerd-web-admin created
serviceaccount/linkerd-web created
customresourcedefinition.apiextensions.k8s.io/serviceprofiles.linkerd.io created
customresourcedefinition.apiextensions.k8s.io/trafficsplits.split.smi-spec.io created
clusterrole.rbac.authorization.k8s.io/linkerd-linkerd-prometheus created
clusterrolebinding.rbac.authorization.k8s.io/linkerd-linkerd-prometheus created
serviceaccount/linkerd-prometheus created
clusterrole.rbac.authorization.k8s.io/linkerd-linkerd-proxy-injector created
clusterrolebinding.rbac.authorization.k8s.io/linkerd-linkerd-proxy-injector created
serviceaccount/linkerd-proxy-injector created
secret/linkerd-proxy-injector-tls created
mutatingwebhookconfiguration.admissionregistration.k8s.io/linkerd-proxy-injector-webhook-config created
clusterrole.rbac.authorization.k8s.io/linkerd-linkerd-sp-validator created
clusterrolebinding.rbac.authorization.k8s.io/linkerd-linkerd-sp-validator created
serviceaccount/linkerd-sp-validator created
secret/linkerd-sp-validator-tls created
validatingwebhookconfiguration.admissionregistration.k8s.io/linkerd-sp-validator-webhook-config created
clusterrole.rbac.authorization.k8s.io/linkerd-linkerd-tap created
clusterrole.rbac.authorization.k8s.io/linkerd-linkerd-tap-admin created
clusterrolebinding.rbac.authorization.k8s.io/linkerd-linkerd-tap created
clusterrolebinding.rbac.authorization.k8s.io/linkerd-linkerd-tap-auth-delegator created
serviceaccount/linkerd-tap created
rolebinding.rbac.authorization.k8s.io/linkerd-linkerd-tap-auth-reader created
secret/linkerd-tap-tls created
apiservice.apiregistration.k8s.io/v1alpha1.tap.linkerd.io created
podsecuritypolicy.policy/linkerd-linkerd-control-plane created
role.rbac.authorization.k8s.io/linkerd-psp created
rolebinding.rbac.authorization.k8s.io/linkerd-psp created
configmap/linkerd-config created
secret/linkerd-identity-issuer created
service/linkerd-identity created
deployment.apps/linkerd-identity created
service/linkerd-controller-api created
deployment.apps/linkerd-controller created
service/linkerd-dst created
deployment.apps/linkerd-destination created
cronjob.batch/linkerd-heartbeat created
service/linkerd-web created
deployment.apps/linkerd-web created
configmap/linkerd-prometheus-config created
service/linkerd-prometheus created
deployment.apps/linkerd-prometheus created
deployment.apps/linkerd-proxy-injector created
service/linkerd-proxy-injector created
service/linkerd-sp-validator created
deployment.apps/linkerd-sp-validator created
service/linkerd-tap created
deployment.apps/linkerd-tap created
configmap/linkerd-config-addons created
serviceaccount/linkerd-grafana created
configmap/linkerd-grafana-config created
service/linkerd-grafana created
deployment.apps/linkerd-grafana created

Ahora podemos verificar que la instalación se ha realizado correctamente usando el comando:

linkerd check

Y si todo se ha hecho correctamente, obtendrás una salida como esta:

PS C:WINDOWSsystem32> linkerd check
kubernetes-api
--------------
√ can initialize the client
√ can query the Kubernetes API

kubernetes-version
------------------
√ is running the minimum Kubernetes API version
√ is running the minimum kubectl version

linkerd-existence
-----------------
√ 'linkerd-config' config map exists
√ heartbeat ServiceAccount exist
√ control plane replica sets are ready
√ no unschedulable pods
√ controller pod is running
√ can initialize the client
√ can query the control plane API

linkerd-config
--------------
√ control plane Namespace exists
√ control plane ClusterRoles exist
√ control plane ClusterRoleBindings exist
√ control plane ServiceAccounts exist
√ control plane CustomResourceDefinitions exist
√ control plane MutatingWebhookConfigurations exist
√ control plane ValidatingWebhookConfigurations exist
√ control plane PodSecurityPolicies exist

linkerd-identity
----------------
√ certificate config is valid
√ trust anchors are using supported crypto algorithm
√ trust anchors are within their validity period
√ trust anchors are valid for at least 60 days
√ issuer cert is using supported crypto algorithm
√ issuer cert is within its validity period
√ issuer cert is valid for at least 60 days
√ issuer cert is issued by the trust anchor

Luego podemos ver el panel de Linkerd usando el siguiente comando:

linkerd dashboard

Despliegue de las aplicaciones

Usaremos las mismas aplicaciones que usamos hace algún tiempo para desplegar istio, así que si quieres recordar lo que están haciendo, necesitas mirar de nuevo ese artículo.

He subido el código a mi repositorio de GitHub, y puedes encontrarlo aquí: https://github.com/alexandrev/bwce-linkerd-scenario

Para desplegar, necesitas tener tus imágenes de docker subidas a un registro de docker, y usaré Amazon ECR como el repositorio de docker que voy a usar.

Así que necesito construir y subir esas imágenes con los siguientes comandos:

docker build -t provider:1.0 .
docker tag provider:1.0 938784100097.dkr.ecr.eu-west-2.amazonaws.com/provider-linkerd:1.0
docker push 938784100097.dkr.ecr.eu-west-2.amazonaws.com/provider-linkerd:1.0

docker build -t consumer:1.0 .
docker tag consumer:1.0 938784100097.dkr.ecr.eu-west-2.amazonaws.com/consumer-linkerd:1.0
docker push 938784100097.dkr.ecr.eu-west-2.amazonaws.com/consumer-linkerd:1.0

Y después de eso, vamos a desplegar las imágenes en el clúster de Kubernetes:

kubectl apply -f .provider.yaml

kubectl apply -f .consumer.yaml

Y ahora podemos ver esas aplicaciones en el Panel de Linkerd en el espacio de nombres predeterminado:

Y ahora, podemos alcanzar el endpoint del consumidor usando el siguiente comando:

kubectl port-forward pod/consumer-v1-6cd49d6487-jjm4q 6000:6000

Y si alcanzamos el endpoint, obtuvimos la respuesta esperada del proveedor.

Y en el panel, podemos ver las estadísticas del proveedor:

Además, Linkerd por defecto proporciona un panel de Grafana donde puedes ver más métricas, puedes llegar allí usando el enlace de grafana que tiene el panel.

Cuando entras, podrías ver algo como el panel que se muestra a continuación:

Resumen

Con todo este proceso, hemos visto lo fácil que podemos desplegar un servicio mesh de linkerd en nuestro clúster de Kubernetes y cómo las aplicaciones pueden integrarse e interactuar con ellos. En los próximos posts, profundizaremos en las características más avanzadas que nos ayudarán en los nuevos desafíos que vienen con la arquitectura de Microservicios.