Articles

Cómo inyectar secretos en pods para mejorar la seguridad con Hashicorp Vault en 5 minutos

por
Cómo inyectar secretos en pods para mejorar la seguridad con Hashicorp Vault en 5 minutos
Tabla de contenidos
  1. Introducción
  2. Habilitando la Autenticación de Kubernetes en Hashicorp
  3. Definiendo una Cuenta de Servicio de Kubernetes y Definiendo una Política

Introducción

Este artículo cubrirá cómo inyectar secretos en Pods usando Hashicorp Vault. En artículos anteriores, cubrimos cómo instalar Hashicorp Vault en Kubernetes, configurar y crear secretos en Hashicorp, y cómo herramientas como TIBCO BW pueden recuperarlos. Sin embargo, hoy vamos a dar un paso más allá.

La razón por la cual inyectar secretos en pods es muy importante es que permite que la aplicación dentro del pod sea transparente en torno a cualquier comunicación con Hashicorp. Después de todo, para las aplicaciones, el secreto será solo un archivo regular ubicado en una ruta específica dentro del contenedor. No necesita preocuparse si este archivo proviene de un Secreto de Hashicorp o de un recurso totalmente diferente.

Este enfoque de inyección facilita el enfoque poliglota del ecosistema de Kubernetes porque libera cualquier responsabilidad de la aplicación subyacente. Lo mismo ocurre con enfoques de inyección como Istio o mucho más.

Pero, expliquemos cómo funciona este enfoque para inyectar secretos en Pods usando Hashicorp Vault. Como parte de la instalación junto al servidor de vault que hemos instalado (o varios si has hecho una instalación distribuida), hemos visto otro pod bajo el nombre de value-agent-injector, como puedes ver en la imagen a continuación:

Inyectar Secretos en Pods: Pod del Inyector de Vault

Este agente será responsable de escuchar los nuevos despliegues que realices y, basado en las anotaciones que tenga este despliegue, lanzará un sidecar junto a tu aplicación y enviará la configuración para poder conectarse al vault y descargar los secretos requeridos y montarlos como archivos dentro de tu pod como se muestra en la imagen a continuación:

Inyectar Secretos en Pods: Progreso de Inyección
Flujo de autenticación de Kubernetes de Vault

Para hacer eso, necesitamos realizar varios pasos como parte de la configuración que vamos a incluir en las próximas secciones del artículo

Habilitando la Autenticación de Kubernetes en Hashicorp

Lo primero que necesitamos hacer en esta etapa es habilitar la Autenticación de Kubernetes en Hashicorp. Este método permite a los clientes autenticarse con un Token de Cuenta de Servicio de Kubernetes. Hacemos eso con el siguiente comando:

 Vault auth enable kubernetes

Vault acepta un token de servicio de cualquier cliente en el clúster de Kubernetes. Durante la autenticación, Vault verifica que el token de la cuenta de servicio sea válido consultando un endpoint de revisión de tokens de Kubernetes. Ahora, necesitamos configurar este método de autenticación proporcionando la ubicación de nuestra API de Kubernetes, y para hacer eso, necesitamos ejecutar el siguiente comando:

 vault write auth/kubernetes/config 
    kubernetes_host="https://$KUBERNETES_PORT_443_TCP_ADDR:443"

Definiendo una Cuenta de Servicio de Kubernetes y Definiendo una Política

Ahora, crearemos una Cuenta de Servicio de Kubernetes que ejecutará nuestros pods, y a esta cuenta de servicio se le permitirá recuperar el secreto que generamos en el artículo anterior.

Para hacer eso, comenzaremos con la creación de la cuenta de servicio ejecutando este comando desde fuera del pod:

kubectl create sa internal-app

Esto creará una nueva cuenta de servicio bajo el nombre de internal-app, y ahora vamos a generar una política dentro del servidor de Hashicorp Vault usando este comando dentro del pod del servidor de vault:

 vault policy write internal-app - <<EOF
path "internal/data/database/config" {
  capabilities = ["read"]
}
EOF

Y ahora, asociamos esta política con la cuenta de servicio ejecutando este comando también dentro del pod del servidor de vault:

  vault write auth/kubernetes/role/internal-app 
    bound_service_account_names=internal-app 
    bound_service_account_namespaces=default 
    policies=internal-app 
    ttl=24h

Y eso es prácticamente toda la configuración que necesitamos hacer en el lado de Vault para poder inyectar secretos en pods usando Hashicorp Vault. Ahora, necesitamos configurar nuestra aplicación en consecuencia haciendo las siguientes modificaciones:

  • Especificar el ServiceAccountName en el despliegue para que sea el que creamos previamente: internal-app
  • Especificar las anotaciones específicas para inyectar los secretos de vault y la configuración de esos secretos.

Comencemos con el primer punto. Necesitamos agregar el serviceAccountName a nuestro archivo YAML de Manifiesto de Kubernetes como se muestra a continuación:

Inyectar Secretos en Pods: Definición del Nombre de la Cuenta de Servicio

Y con respecto al segundo punto, lo resolveríamos agregando varias anotaciones a nuestro despliegue, como se muestra a continuación:

Inyectar Secretos en Pods: Anotaciones

Las anotaciones utilizadas para inyectar secretos en pods son las siguientes:

  • vault.hashicorp.com/agent-inject: ‘true’: Esto le dice al inyector de vault que nos gustaría inyectar el agente sidecar en este despliegue y tener la configuración de Vault. Esto es necesario para hacer cualquier configuración adicional
  • vault.hashicorp.com/role: internal-app: Este es el rol de vault que vamos a usar cuando solicitemos secretos e información al vault para asegurarnos de que solo accedemos a los secretos que hemos permitido según la política que creamos en la sección anterior
  • vault.hashicorp.com/agent-inject-secret-secret-database-config.txt: internal/data/database/config: Esta será una anotación por cada secreto que planeamos agregar, y se compone de tres partes:
    • vault.hashicorp.com/agent-inject-secret- esta parte es fija
    • secret-database-config.txt esta parte será el nombre del archivo que se crea bajo /vault/secrets dentro de nuestro pod
    • internal/data/database/config Este es el camino dentro del vault de nuestro secreto para ser vinculado a ese archivo.

¡Y eso es todo! Si desplegamos ahora nuestro despliegue veremos las siguientes cosas:

  • Nuestra aplicación de despliegue se ha lanzado con tres contenedores en lugar de uno porque dos de ellos están relacionados con Hashicorp Vault, como puedes ver en la imagen a continuación:
Cómo inyectar secretos en pods para mejorar la seguridad con Hashicorp Vault en 5 minutos
  • vault-agent-init será el contenedor que establece la conexión con el servidor de vault porque cualquier contenedor comienza y realiza la primera descarga e inyección de secretos en el pod según la configuración proporcionada.
  • vault-agent será el contenedor que se ejecuta como un observador para detectar cualquier modificación en los secretos relacionados y actualizarlos.
Cómo inyectar secretos en pods para mejorar la seguridad con Hashicorp Vault en 5 minutos

Y ahora, si vamos al contenedor principal, veremos en la ruta /vault/secrets que el secreto ha sido finalmente inyectado como se esperaba:

Cómo inyectar secretos en pods para mejorar la seguridad con Hashicorp Vault en 5 minutos

Y así es como fácilmente y sin ningún conocimiento sobre la aplicación subyacente podemos inyectar secretos en pods usando Hashicorp Vault.

Dockerfile de Múltiples Etapas: Enfoque Asombroso para Optimizar el Tamaño de tu Contenedor

por
Dockerfile de Múltiples Etapas: Enfoque Asombroso para Optimizar el Tamaño de tu Contenedor
Tabla de contenidos
  1. ¿Qué es un patrón de Dockerfile de múltiples etapas?
  2. ¿Por qué el patrón de construcción de múltiples etapas ayuda a reducir el tamaño de las imágenes de contenedores?
  3. ¿Cómo defines un Dockerfile de múltiples etapas?
  4. ¿Cómo copias recursos de una etapa a otra?
  5. ¿Cuál es la mejora que puedes obtener?
  6.  ¿Dónde puedo leer más sobre esto?

El Dockerfile de múltiples etapas es el patrón que puedes usar para asegurar que tu imagen de Docker esté en un tamaño optimizado. Ya hemos cubierto la importancia de mantener el tamaño de tu imagen de Docker al mínimo y qué herramientas podrías usar, como dive, para entender el tamaño de cada una de tus capas. Pero hoy, vamos a seguir un enfoque diferente y ese enfoque es una construcción de múltiples etapas para nuestros contenedores Docker.

¿Qué es un patrón de Dockerfile de múltiples etapas?

El Dockerfile de múltiples etapas se basa en el principio de que el mismo Dockerfile puede tener diferentes sentencias FROM y cada una de las sentencias FROM inicia una nueva etapa de la construcción.

Patrón de Dockerfile de múltiples etapas

¿Por qué el patrón de construcción de múltiples etapas ayuda a reducir el tamaño de las imágenes de contenedores?

La razón principal por la que el uso de patrones de construcción de múltiples etapas ayuda a reducir el tamaño de los contenedores es que puedes copiar cualquier artefacto o conjunto de artefactos de una etapa a otra. Y esa es la razón más importante. ¿Por qué? Porque eso significa que todo lo que no copias es descartado y no estás llevando todos estos componentes no requeridos de capa en capa, generando un tamaño innecesario mayor de la imagen final de Docker.

¿Cómo defines un Dockerfile de múltiples etapas?

Primero, necesitas tener un Dockerfile con más de un FROM. Como se comentó, cada uno de los FROM indicará el inicio de una etapa del Dockerfile de múltiples etapas. Para diferenciarlos o referenciarlos, puedes nombrar cada una de las etapas del Dockerfile usando la cláusula AS junto al comando FROM, como se muestra a continuación:

 FROM eclipse-temurin:11-jre-alpine AS builder

Como una buena práctica, también puedes agregar una nueva etiqueta de etapa con el mismo nombre que proporcionaste antes, pero eso no es necesario. Así que, en resumen, un Dockerfile de múltiples etapas será algo como esto:

FROM eclipse-temurin:11-jre-alpine AS builder
LABEL stage=builder
COPY . /
RUN apk add  --no-cache unzip zip && zip -qq -d /resources/bwce-runtime/bwce-runtime-2.7.2.zip "tibco.home/tibcojre64/*"
RUN unzip -qq /resources/bwce-runtime/bwce*.zip -d /tmp && rm -rf /resources/bwce-runtime/bwce*.zip 2> /dev/null


FROM  eclipse-temurin:11-jre-alpine 
RUN addgroup -S bwcegroup && adduser -S bwce -G bwcegroup

¿Cómo copias recursos de una etapa a otra?

Esta es la otra parte importante aquí. Una vez que hemos definido todas las etapas que necesitamos, y cada una está haciendo su parte del trabajo, necesitamos mover datos de una etapa a la siguiente. Entonces, ¿cómo podemos hacer eso?

La respuesta es usando el comando COPY. COPY es el mismo comando que usas para mover datos desde tu almacenamiento local a la imagen del contenedor, por lo que necesitarás una forma de diferenciar que esta vez no lo estás copiando desde tu almacenamiento local sino desde otra etapa, y aquí es donde vamos a usar el argumento --from. El valor será el nombre de la etapa que aprendimos a declarar en la sección anterior. Así que un comando COPY completo será algo como el fragmento mostrado a continuación:

 COPY --from=builder /resources/ /resources/

¿Cuál es la mejora que puedes obtener?

Esa es la parte esencial y dependerá de cómo se crean tus Dockerfiles e imágenes, pero el factor principal que puedes considerar es el número de capas que tiene tu imagen actual. Cuanto mayor sea el número de capas, más significativo será el ahorro que probablemente puedas lograr en la cantidad de la imagen final del contenedor en un Dockerfile de múltiples etapas.

La razón principal es que cada capa duplicará parte de los datos, y estoy seguro de que no necesitarás todos los datos de la capa en la siguiente. Y usando el enfoque comentado en este artículo, obtendrás una forma de optimizarlo.

 ¿Dónde puedo leer más sobre esto?

Si quieres leer más, debes saber que el Dockerfile de múltiples etapas está documentado como una de las mejores prácticas en la página web oficial de Docker, y tienen un gran artículo sobre esto por Alex Ellis que puedes leer aquí.

Dependencia de Helm: Descubre Cómo Funciona

por
Dependencia de Helm: Descubre Cómo Funciona
Tabla de contenidos
  1. ¿Qué es una Dependencia de Helm?
  2. ¿Cómo declaramos una Dependencia de Helm?
  3. ¿Cómo declaro una Dependencia Condicional de Helm?
  4. ¿Cómo declaro una Dependencia de Helm con una versión diferente?

La Dependencia de Helm es una parte crítica para entender cómo funciona Helm, ya que es la forma de establecer relaciones entre diferentes paquetes de helm. Hemos hablado mucho aquí sobre qué es Helm, y algunos temas relacionados, e incluso proporcionamos algunos trucos si creas tus gráficos.

Entonces, como se comentó, Helm Chart no es más que un paquete que colocas alrededor de los diferentes objetos de Kubernetes que necesitan ser desplegados para que tu aplicación funcione. La comparación habitual es que es similar a un Paquete de Software. Cuando instalas una aplicación que depende de varios componentes, todos esos componentes se empaquetan juntos, y aquí es lo mismo.

¿Qué es una Dependencia de Helm?

Una Dependencia de Helm no es más que la forma en que defines que tu Chart necesita otro chart para funcionar. Por supuesto, puedes crear un Helm Chart con todo lo que necesitas para desplegar tu aplicación, pero a veces te gustaría dividir ese trabajo en varios charts simplemente porque son fáciles de mantener o el caso de uso más común porque quieres aprovechar otro Helm Chart que ya está disponible.

Un caso de uso puede ser una aplicación web que requiere una base de datos, por lo que puedes crear en tu Helm Chart todos los archivos YAML para desplegar tu aplicación web y tu base de datos en Kubernetes, o puedes tener tus archivos YAML para tu aplicación web (Deployment, Services, ConfigMaps,…) y luego decir: Y necesito una base de datos y para proporcionarla voy a usar este chart.

Esto es similar a cómo funciona con los paquetes de software en sistemas UNIX; tienes tu paquete que hace el trabajo, como, por ejemplo, A, pero para que ese trabajo se realice, requiere la biblioteca L, y para asegurar que cuando estás instalando A, la Biblioteca L ya esté allí o si no, se instalará, declaras que tu aplicación A depende de la Biblioteca L, así que aquí es lo mismo. Declaras que tu Chart depende de otro Chart para funcionar. Y eso nos lleva al siguiente punto.

¿Cómo declaramos una Dependencia de Helm?

Este es el siguiente punto; ahora que entendemos qué es una Dependencia de Helm conceptualmente y tenemos un caso de uso, ¿cómo podemos hacer eso en nuestro Helm Chart?

Todo el trabajo se realiza en el archivo Chart.yml. Si recuerdas, el archivo Chart.yml es el archivo donde declaras todos los metadatos de tu Helm Chart, como el nombre, la versión del chart, la versión de la aplicación, la URL de ubicación, el icono y mucho más. Y generalmente tiene una estructura como esta:

apiVersion: v2
name: MyChart
description: My Chart Description
type: application
version: 0.2.0
appVersion: "1.16.0"

Así que aquí podemos agregar una sección dependencies y, en esa sección es donde vamos a definir los charts de los que dependemos. Como puedes ver en el fragmento a continuación:

apiVersion: v2
name: MyChart
description: My Chart Description
type: application
version: 0.2.0
appVersion: "1.16.0"
dependencies:
- name: Dependency
  version: 1.0.0
  repository: "file:///location_of_my_chart"

Aquí estamos declarando Dependency como nuestra Dependencia de Helm. Especificamos la versión que nos gustaría usar (similar a la versión que decimos en nuestro chart), y eso nos ayudará a asegurar que proporcionaremos la misma versión que ha sido probada como parte de la resolución de la dependencia y también la ubicación usando una URL que puede ser una URL externa si esto está apuntando a un Helm Chart que está disponible en internet o fuera de tu computadora o usando una Ruta de Archivo en caso de que estés apuntando a un recurso local en tu máquina.

Eso hará el trabajo de definir la dependencia de helm, y de esta manera, cuando instales tu chart usando el comando helm install, también proporcionará la dependencia.

¿Cómo declaro una Dependencia Condicional de Helm?

Hasta ahora, hemos aprendido cómo declarar una dependencia, y cada vez que aprovisiono mi aplicación, también proporcionará la dependencia. Pero generalmente nos gustaría tener un enfoque más detallado para eso. Imagina el mismo escenario anterior: Tenemos nuestra Aplicación Web que depende de la Base de Datos, y tenemos dos opciones, podemos aprovisionar la base de datos como parte de la instalación de la aplicación web, o podemos apuntar a una base de datos externa y en ese caso, no tiene sentido aprovisionar la Dependencia de Helm. ¿Cómo podemos hacer eso?

Entonces, fácil, porque uno de los parámetros opcionales que puedes agregar a tu dependencia es condition y hacer exactamente eso, condition te permite especificar una bandera en tu values.yml que en el caso sea igual a true, proporcionará la dependencia pero en el caso sea igual a false omitirá esa parte similar al fragmento mostrado a continuación:

 apiVersion: v2
name: MyChart
description: My Chart Description
type: application
version: 0.2.0
appVersion: "1.16.0"
dependencies:
- name: Dependency
  version: 1.0.0
  repository: "file:///location_of_my_chart"
  condition: database.enabled

Y con eso, estableceremos el parámetro enabled bajo database en nuestro values.yml a true si nos gustaría aprovisionarlo.

¿Cómo declaro una Dependencia de Helm con una versión diferente?

Como se muestra en los fragmentos anteriores, ofrecemos que cuando declaramos una Dependencia de Helm, especificamos la versión; esa es una forma segura de hacerlo porque asegura que cualquier cambio realizado en el chart de helm no afectará tu paquete. Sin embargo, al mismo tiempo, no puedes estar al tanto de correcciones de seguridad o parches en el chart que te gustaría aprovechar en tu implementación.

Para simplificar eso, tienes la opción de definir la versión de una manera más flexible usando el operador ~ en la definición de la versión, como puedes ver en el fragmento a continuación:

apiVersion: v2
name: MyChart
description: My Chart Description
type: application
version: 0.2.0
appVersion: "1.16.0"
dependencies:
- name: Dependency
  version: ~1.0.0
  repository: "file:///location_of_my_chart"
  condition: database.enabled

Esto significa que cualquier parche realizado en el chart será aceptado, por lo que esto es similar a que este chart usará la última versión de 1.0.X. Sin embargo, no usará la versión 1.1.0, por lo que eso permite tener más flexibilidad, pero al mismo tiempo mantener las cosas seguras y protegidas en caso de un cambio importante en el Chart del que dependes. Esta es solo una forma de definir eso, pero la flexibilidad es enorme ya que las versiones de Chart usan «Versiones Semánticas», Puedes aprender y leer más sobre eso aquí: https://github.com/Masterminds/semver.

Trivy: Logra escanear imágenes locales de Docker con éxito

por
Trivy: Logra escanear imágenes locales de Docker con éxito

Escanear imágenes de Docker o, para ser más honestos, escanear tus imágenes de contenedores se está convirtiendo en una de las tareas cotidianas a realizar como parte del desarrollo de tu aplicación. El cambio de ritmo de cuán fácilmente surgen las nuevas vulnerabilidades, la explosión de dependencias que tiene cada una de las imágenes de contenedores y la cantidad de implementaciones por empresa hacen que sea bastante complejo mantener el ritmo para asegurar que puedan mitigar los problemas de seguridad.

Ya cubrimos este tema hace algún tiempo cuando la herramienta Docker Desktop introdujo la opción de escaneo basada en una integración con Synk y, más recientemente, con el último lanzamiento de Lens. Esta es una de las opciones para verificar las imágenes de contenedores de la versión “corporativa” de la herramienta. Y desde hace algún tiempo también, los registros centrales de la Nube han proporcionado tal como un ECR, incluyendo la opción de Escaneo como una de las capacidades para cualquier imagen implementada allí.

Pero, ¿qué pasa si ya te estás moviendo de Docker Desktop a otra opción, como podman o Rancher Desktop? ¿Cómo puedes escanear tus imágenes de docker?

Varios escáneres pueden usarse para escanear tus imágenes de contenedores localmente, y algunos de ellos son más fáciles de configurar que otros. Uno de los más conocidos es Clair, que también se está utilizando como parte del registro RedHat Quay y tiene mucha tracción. Funciona en un modo cliente-servidor que es excelente para ser utilizado por diferentes equipos que requieren una implementación más “empresarial”, generalmente estrechamente relacionada con un Registro. Sin embargo, no se adapta bien para ejecutarse localmente ya que requiere varios componentes y relaciones.

Como una opción fácil para probar localmente, tienes Trivy. Trivy es una herramienta interesante desarrollada por AquaSecurity. Puede que recuerdes la empresa ya que es la que está detrás de otros desarrollos relacionados con la seguridad en Kubernetes, como KubeBench, que ya cubrimos en el pasado.

En sus propias palabras, “Trivy es un escáner de seguridad integral. Es confiable, rápido y sencillo de usar y funciona donde lo necesites.”

¿Cómo instalar Trivy?

El proceso de instalación es relativamente fácil y está documentado para cada plataforma importante aquí. Sin embargo, al final, se basa en paquetes binarios disponibles como RPM, DEB, Brew, MacPorts, o incluso una imagen de Docker.

¿Cómo escanear imágenes de Docker con Trivy?

Una vez instalado, puedes simplemente ejecutar los comandos como este:

 trivy image python:3.4-alpine

Esto realizará las siguientes tareas:

  • Actualizar la base de datos del repositorio con todas las vulnerabilidades
  • Descargar la imagen en caso de que no esté disponible localmente
  • Detectar los lenguajes y componentes presentes en esa imagen
  • Validar las imágenes y generar un resultado

¿Qué salida proporciona Trivy?

Como ejemplo, esta es la salida para el python:3.4-alpine a partir de hoy:

Escanear imágenes de Docker con Trivy

Obtendrás una tabla con una fila por cada biblioteca o componente que haya detectado una vulnerabilidad mostrando el nombre de la Biblioteca y la exposición relacionada con ella con el código CVE. El código CVE es generalmente cómo se refieren a las vulnerabilidades ya que están presentes en un repositorio común con todas sus descripciones y detalles. Además de eso, muestra la severidad de la vulnerabilidad basada en el informe existente. También proporciona la versión actual detectada en la imagen y en caso de que haya una versión diferente que haya solucionado esa vulnerabilidad, la versión inicial que ha resuelto esa vulnerabilidad, y finalmente, un título para proporcionar un poco más de contexto sobre la vulnerabilidad:

Trivy: Logra escanear imágenes locales de Docker con éxito

Si una Biblioteca está relacionada con más de una vulnerabilidad, dividirá las celdas en esa fila para acceder a los diferentes datos para cada vulnerabilidad.

Nomad vs Kubernetes: 1 contendiente emergente desafiando al rey probado

por
Nomad vs Kubernetes: 1 contendiente emergente desafiando al rey probado
Tabla de contenidos
  1. ¿Cuáles son las principales características de Nomad?
  2. Nomad vs Kubernetes: ¿Cómo funciona Nomad?
  3.  ¿Es Nomad un reemplazo para Kubernetes?

Nomad es la alternativa de Hashicorp al patrón típico de usar una plataforma basada en Kubernetes como la única forma de orquestar tus cargas de trabajo de manera eficiente. Nomad es un proyecto iniciado en 2019, pero está ganando mucha más relevancia hoy en día después de 95 lanzamientos, y la versión actual de este artículo es 1.4.1, como puedes ver en su perfil de GitHub.

Nomad aborda los desafíos tradicionales de aislar el ciclo de vida de la aplicación para el ciclo de vida de operación de la infraestructura donde reside esa aplicación. Sin embargo, en lugar de ir completamente a una aplicación basada en contenedores, intenta proporcionar una solución de manera diferente.

¿Cuáles son las principales características de Nomad?

Basado en su propia definición, como puedes leer en su perfil de GitHub, ya destacan algunos de los puntos de diferencia con respecto al estándar de facto de la industria:

Nomad es un orquestador de cargas de trabajo fácil de usar, flexible y de alto rendimiento que puede desplegar una mezcla de aplicaciones de microservicios, por lotes, contenedorizadas y no contenedorizadas

Fácil de usar: Esta es la primera afirmación que incluyen en su definición porque el enfoque de Nomad es mucho más simple que alternativas como Kubernetes porque funciona con un enfoque de binario único donde tiene todas las capacidades necesarias ejecutándose como un agente de nodo basado en su propio «vocabulario» que puedes leer más en su documentación oficial.

Flexibilidad: Esta es la otra cosa crítica que proporcionan, un hipervisor, una capa intermedia entre la aplicación y la infraestructura subyacente. No se limita solo a aplicaciones de contenedores, sino que también admite este tipo de despliegue. También permite desplegarlo como parte de un enfoque tradicional de máquina virtual. Los casos de uso principales destacados son ejecutar aplicaciones estándar de Windows, lo cual es complicado cuando se habla de despliegues de Kubernetes; aunque los contenedores de Windows han sido una cosa durante mucho tiempo, su adopción no está al mismo nivel, como puedes ver en el mundo de los contenedores de Linux.

Integración con Hashicorp: Como parte del portafolio de Hashicorp, también incluye una integración perfecta con otros proyectos de Hashicorp como Hashicorp Vault, que hemos cubierto en varios artículos, o Hashicorp Consul, que ayuda a proporcionar capacidades adicionales en términos de seguridad, gestión de configuración y comunicación entre las diferentes cargas de trabajo.

Nomad vs Kubernetes: ¿Cómo funciona Nomad?

Como se comentó anteriormente, Nomad cubre todo con un enfoque de componente único. Un binario de Nomad es un agente que puede trabajar en modo servidor o modo cliente, dependiendo del rol de la máquina que lo ejecuta.

Así que Nomad se basa en un clúster de Nomad, un conjunto de máquinas que ejecutan un agente de Nomad en modo servidor. Esos servidores se dividen dependiendo del rol de líder o seguidores. El líder realiza la mayor parte de la gestión del clúster, y los seguidores pueden crear planes de programación y enviarlos al líder para su aprobación y ejecución. Esto se representa en la imagen a continuación de la página oficial de Hashicorp Nomad:

Nomad vs Kubernetes: 1 Contendiente Contra el Rey de la Orquestación
Arquitectura simple de Nomad de nomadproject.io

Una vez que tenemos el clúster listo, necesitamos crear nuestros trabajos, y un trabajo es una definición de la tarea que nos gustaría ejecutar en el clúster de Nomad que hemos configurado previamente. Una tarea es la unidad de trabajo más pequeña en Nomad. Aquí es donde la flexibilidad llega a Nomad porque el controlador de tareas ejecuta cada tarea, permitiendo que diferentes controladores ejecuten varias cargas de trabajo. Así es como siguiendo el mismo enfoque, tendremos un controlador de Docker para ejecutar nuestro despliegue de contenedores o un controlador de ejecución para ejecutarlo sobre una infraestructura virtual. Aún así, puedes crear tus controladores de tareas siguiendo un mecanismo de complementos que puedes leer más sobre aquí.

Los trabajos y las tareas se definen utilizando un enfoque basado en texto, pero no siguiendo el tipo habitual de archivos YAML o JSON, sino un formato diferente, como puedes ver en la imagen a continuación (haz clic aquí para descargar el archivo completo del repositorio de muestras de GitHub Nomad):

 ¿Es Nomad un reemplazo para Kubernetes?

Nomad vs Kubernetes: 1 Contendiente Contra el Rey de la Orquestación

Es una pregunta compleja de responder, e incluso Hashicorp ha documentado diferentes estrategias. Sin duda, puedes usar Nomad para ejecutar despliegues basados en contenedores en lugar de ejecutarlos en Kubernetes. Pero al mismo tiempo, también posicionan la solución junto a Kubernetes para ejecutar algunas cargas de trabajo en una solución y otras en la otra.

Al final, ambos intentan resolver y abordar los mismos desafíos en términos de escalabilidad, compartición y optimización de infraestructura, agilidad, flexibilidad y seguridad de los despliegues tradicionales.

Kubernetes se centra en diferentes tipos de cargas de trabajo, pero todo sigue el mismo modo de despliegue (basado en contenedores) y adopta paradigmas recientes (basados en servicios, patrones de microservicios, liderados por API, etc.) con una arquitectura robusta que permite una excelente escalabilidad, rendimiento, flexibilidad y con niveles de adopción en la industria que se ha convertido en la única alternativa de facto actual para plataformas modernas de orquestación de cargas de trabajo.

Pero, al mismo tiempo, también requiere esfuerzo en la gestión y transformación de aplicaciones existentes a nuevos paradigmas.

Por otro lado, Nomad intenta abordarlo de manera diferente, minimizando el cambio de la aplicación existente para aprovechar los beneficios de la plataforma y reduciendo la sobrecarga de gestión y complejidad que una plataforma de Kubernetes habitual proporciona, dependiendo de la situación.

Plantillas de Helm en Archivos: Cómo Personalizar el Contenido de ConfigMaps Simplificado en 10 Minutos

por
Plantillas de Helm en Archivos: Cómo Personalizar el Contenido de ConfigMaps Simplificado en 10 Minutos

Las plantillas de Helm en archivos, como el contenido de ConfigMaps o el contenido de Secrets, son uno de los requisitos más comunes cuando estás en el proceso de crear un nuevo gráfico de helm. Como ya sabes, el gráfico de Helm es cómo usamos Kubernetes para empaquetar nuestros recursos de aplicación y YAML en un solo componente que podemos gestionar de una vez para facilitar el proceso de mantenimiento y operación.

Visión General de las Plantillas de Helm

Por defecto, el proceso de plantillas funciona con archivos YAML, permitiéndonos usar algunas variables y algunas funciones lógicas para personalizar y templar nuestros recursos YAML de Kubernetes según nuestras necesidades.

Entonces, en resumen, solo podemos tener archivos yaml dentro de la carpeta de plantillas de un YAML. Pero a veces nos gustaría hacer el mismo proceso en ConfigMaps o Secrets o ser más concretos con el contenido de esos ConfigMaps, por ejemplo, archivos de propiedades y así sucesivamente.

Plantillas de Helm en Archivos: Cómo Personalizar el Contenido de ConfigMaps Simplificado
Plantillas de Helm en Archivos: Visión General de las Plantillas de Helm mostrando los Archivos fuera de las plantillas que usualmente se requieren

Como puedes ver, es bastante normal tener diferentes archivos como archivos de configuración json, archivos de propiedades, scripts de shell como parte de tu gráfico de helm, y la mayoría de las veces te gustaría dar un enfoque dinámico a su contenido, y es por eso que usar Plantillas de Helm en Archivos es tan importante para ser el enfoque principal de este artículo

Funciones de Ayuda de Helm para Gestionar Archivos

Por defecto, Helm nos proporciona un conjunto de funciones para gestionar archivos como parte del gráfico de helm para simplificar el proceso de incluirlos como parte del gráfico, como el contenido de ConfigMap o Secret. Algunas de estas funciones son las siguientes:

  • .Files.Glob: Esta función permite encontrar cualquier patrón de archivos internos que coincida con el patrón, como el siguiente ejemplo:
    { range $path, $ := .Files.Glob ".yaml" }
  • .Files.Get: Esta es la opción más simple para reunir el contenido de un archivo específico que conoces la ruta completa dentro de tu gráfico de helm, como el siguiente ejemplo: {{ .Files.Get "config1.toml" | b64enc }}

Incluso puedes combinar ambas funciones para usarlas juntas como en el siguiente ejemplo:

 {{ range $path, $_ :=  .Files.Glob  "**.yaml" }}
      {{ $.Files.Get $path }}
{{ end }}

Luego puedes combinar eso una vez que tengas el archivo que deseas usar con algunas funciones de ayuda para introducir fácilmente en un ConfigMap y un Secret como se explica a continuación:

  • .AsConfig : Usa el contenido del archivo para ser introducido como ConfigMap manejando el patrón: nombre-del-archivo: contenido-del-archivo
  • .AsSecrets: Similar al anterior, pero haciendo la codificación base64 para los datos.

Aquí puedes ver un ejemplo real de usar este enfoque en una situación real de gráfico de helm:

apiVersion: v1
kind: Secret
metadata:
  name: zones-property
  namespace: {{ $.Release.Namespace }}
data: 
{{ ( $.Files.Glob "tml_zones_properties.json").AsSecrets | indent 2 }}

Puedes encontrar más información sobre eso aquí. Pero esto solo nos permite tomar el archivo tal cual e incluirlo en un ConfigMap. No nos permite hacer ninguna lógica o sustitución al contenido como parte de ese proceso. Entonces, si queremos modificar esto, este no es un ejemplo válido.

¿Cómo Usar Plantillas de Helm en Archivos como ConfigMaps o Secrets?

En caso de que podamos hacer algunas modificaciones al contenido, necesitamos usar la siguiente fórmula:

apiVersion: v1
kind: Secret
metadata:
  name: papi-property
  namespace: {{ $.Release.Namespace }}
data:
{{- range $path, $bytes := .Files.Glob "tml_papi_properties.json" }}
{{ base $path | indent 2 }}: {{ tpl ($.Files.Get $path) $ | b64enc }}
{{ end }}

Entonces, lo que estamos haciendo aquí es primero iterar por los archivos que coinciden con el patrón usando la función .Files.Glob que explicamos antes, iterando en caso de que tengamos más de uno. Luego creamos manualmente la estructura siguiendo el patrón: nombre-del-archivo: contenido-del-archivo.

Para hacer eso, usamos la función base para proporcionar solo el nombre del archivo desde una ruta completa (y agregar la indentación adecuada) y luego usamos .Files.Get para obtener el contenido del archivo y hacer la codificación base64 usando la función b64enc porque, en este caso, estamos manejando un secreto.

El truco aquí es agregar la función tpl que permite que el contenido de este archivo pase por el proceso de plantillas; así es como todas las modificaciones que necesitamos hacer y las variables referenciadas desde el objeto .Values serán reemplazadas adecuadamente, dándote todo el poder y flexibilidad del Gráfico de Helm en archivos de texto como propiedades, archivos JSON y mucho más.

¡Espero que esto sea tan útil para ti como lo ha sido para mí al crear nuevos gráficos de helm! Y mira aquí para otros trucos usando bucles o dependencias.

Kiali 101: Comprender y Utilizar esta Herramienta Esencial de Gestión de Malla de Servicios Istio

por
Kiali 101: Comprender y Utilizar esta Herramienta Esencial de Gestión de Malla de Servicios Istio

¿Qué es Kiali?

Kiali es un proyecto de código abierto que proporciona observabilidad para tu malla de servicios Istio. Desarrollado por Red Hat, Kiali ayuda a los usuarios a entender la estructura y el comportamiento de su malla y cualquier problema que pueda surgir.

Kiali proporciona una representación gráfica de tu malla, mostrando las relaciones entre los diversos componentes de la malla de servicios, como servicios, servicios virtuales, reglas de destino y más. También muestra métricas vitales, como tasas de solicitudes y errores, para ayudarte a monitorear la salud de tu malla e identificar posibles problemas.

 ¿Cuáles son las principales capacidades de Kiali?

Una de las características clave de Kiali es su capacidad para visualizar la comunicación de servicio a servicio dentro de una malla. Esto permite a los usuarios ver rápidamente cómo están conectados los servicios y cómo se enrutan las solicitudes a través de la malla. Esto es particularmente útil para la resolución de problemas, ya que puede ayudarte a identificar rápidamente problemas con la comunicación de servicios, como reglas de enrutamiento mal configuradas o tiempos de respuesta lentos.

Kiali 101: Comprendiendo y Utilizando esta Herramienta Esencial de Gestión de Malla de Servicios

Kiali también proporciona varias herramientas para monitorear la salud de tu malla. Por ejemplo, puede alertarte sobre problemas potenciales, como una alta tasa de errores o un servicio que no responde a las solicitudes. También proporciona información de seguimiento detallada, permitiéndote ver el camino exacto que tomó una solicitud a través de la malla y dónde pudieron haber ocurrido problemas.

Además de sus características de observabilidad, Kiali proporciona varias otras herramientas para gestionar tu malla de servicios. Por ejemplo, incluye un módulo de gestión de tráfico, que te permite controlar fácilmente el flujo de tráfico a través de tu malla, y un módulo de gestión de configuración, que te ayuda a gestionar y mantener los diversos componentes de tu malla.

En general, Kiali es una herramienta esencial para cualquiera que use una malla de servicios Istio. Proporciona valiosos conocimientos sobre la estructura y el comportamiento de tu malla, así como potentes herramientas de monitoreo y gestión. Ya sea que estés comenzando con Istio o seas un usuario experimentado, Kiali puede ayudar a garantizar que tu malla de servicios funcione de manera fluida y eficiente.

¿Cuáles son los principales beneficios de usar Kiali?

Los principales beneficios de usar Kiali son:

  • Mejorada observabilidad de tu malla de servicios Istio. Kiali proporciona una representación gráfica de tu malla, mostrando las relaciones entre diferentes componentes de la malla de servicios y mostrando métricas clave. Esto te permite entender rápidamente la estructura y el comportamiento de tu malla e identificar posibles problemas.
  • Facilita la resolución de problemas. La visualización de Kiali de la comunicación de servicio a servicio y la información de seguimiento detallada facilitan la identificación de problemas con la comunicación de servicios y localizar la fuente de cualquier problema.
  • Mejorada gestión del tráfico. Kiali incluye un módulo de gestión de tráfico que te permite controlar fácilmente el flujo de tráfico a través de tu malla.
  • Mejorada gestión de configuración. El módulo de gestión de configuración de Kiali te ayuda a gestionar y mantener los diversos componentes de tu malla.

¿Cómo instalar Kiali?

Hay varias formas de instalar Kiali como parte de tu implementación de Malla de Servicios, siendo la opción preferida usar el modelo de Operador disponible aquí.

Puedes instalar este operador usando Helm o OperatorHub. Para instalarlo usando Helm Charts, necesitas agregar el siguiente repositorio usando este comando:

 helm repo add kiali https://kiali.org/helm-charts

** Recuerda que una vez que agregues un nuevo repositorio, necesitas ejecutar el siguiente comando para actualizar los charts disponibles

helm repo update

Ahora, puedes instalarlo usando el comando helm install tal como en el siguiente ejemplo:

helm install 
    --set cr.create=true 
    --set cr.namespace=istio-system 
    --namespace kiali-operator 
    --create-namespace 
    kiali-operator 
    kiali/kiali-operator

Si prefieres seguir la ruta de OperatorHub, puedes usar la siguiente URL . Ahora, al hacer clic en el botón de Instalar, verás los pasos para tener el componente instalado en tu entorno de Kubernetes.

Kiali 101: Comprendiendo y Utilizando esta Herramienta Esencial de Gestión de Malla de Servicios

En caso de que desees una instalación simple de Kiali, también puedes usar el YAML de muestra disponible dentro de la carpeta de instalación de Istio usando el siguiente comando:

kubectl apply -f $ISTIO_HOME/samples/addons/kiali.yaml

¿Cómo funciona Kiali?

Kiali es solo la representación gráfica de la información disponible sobre cómo funciona la malla de servicios. Por lo tanto, no es responsabilidad de Kiali almacenar esas métricas, sino recuperarlas y dibujarlas de manera relevante para el usuario de la herramienta.

Prometheus realiza el almacenamiento de estos datos, por lo que Kiali utiliza la API REST de Prometheus para recuperar la información y dibujarla gráficamente, como puedes ver aquí:

Kiali 101: Comprendiendo y Utilizando esta Herramienta Esencial de Gestión de Malla de Servicios
  • Va a mostrar varias partes relevantes del gráfico. Mostrará el espacio de nombres seleccionado y dentro de ellos las diferentes aplicaciones (detectará una aplicación en caso de que tengas una etiqueta agregada a la carga de trabajo con el nombre app ). Dentro de cada aplicación se agregarán diferentes servicios y pods con otros íconos (triángulos para los servicios y cuadrados para los pods).
  • También mostrará cómo el tráfico llega al clúster a través de las diferentes puertas de enlace de entrada y cómo sale en caso de que tengamos alguna puerta de enlace de salida configurada.
  • Mostrará el tipo de tráfico que estamos manejando y las diferentes tasas de error basadas en el tipo de protocolo, como TCP, HTTP, y así sucesivamente, como puedes ver en la imagen a continuación. El protocolo se decide en base a una convención de nombres en el nombre del puerto del servicio con el formato esperado: nombre-del-protocolo
Kiali 101: Comprendiendo y Utilizando esta Herramienta Esencial de Gestión de Malla de Servicios

¿Puede Kiali usarse con cualquier malla de servicios?

No, Kiali está diseñado específicamente para su uso con mallas de servicios Istio.

Proporciona herramientas de observabilidad, monitoreo y gestión para mallas de servicios Istio, pero no es compatible con otras tecnologías de malla de servicios.

Si usas una malla de servicios diferente, necesitarás encontrar una herramienta adicional para gestionarla y monitorearla.

¿Existen otras alternativas a Kiali?

Aunque no puedas ver alternativas naturales a Kiali para visualizar tus cargas de trabajo y tráfico a través de la Malla de Servicios Istio, puedes usar otras herramientas para obtener las métricas que alimentan a Kiali y tener una visualización personalizada usando herramientas más genéricas como Grafana, entre otras.

Hablemos de herramientas similares a Kiali para otras Mallas de Servicios, como Linkerd, Consul Connect, o incluso Kuma. La mayoría sigue un enfoque diferente donde la parte de visualización no es un «proyecto» separado, sino que se basa en una herramienta de visualización estándar. Eso te da mucha más flexibilidad, pero al mismo tiempo, carece de la excelente visualización del tráfico que proporciona Kiali, como vistas de gráficos o la capacidad de modificar el tráfico directamente desde la vista de gráficos.

Asegure sus servicios con Istio: Guía paso a paso para configurar conexiones TLS de Istio

por
Asegure sus servicios con Istio: Guía paso a paso para configurar conexiones TLS de Istio

Introducción

La configuración de TLS en Istio es una de las características esenciales cuando habilitamos un Service Mesh. Istio Service Mesh proporciona muchas características para definir de manera centralizada y con políticas cómo se maneja la seguridad de transporte, entre otras características, en las diferentes cargas de trabajo que has desplegado en tu clúster de Kubernetes.

Una de las principales ventajas de este enfoque es que puedes hacer que tu aplicación se concentre en la lógica de negocio que necesita implementar. Estos aspectos de seguridad pueden externalizarse y centralizarse sin necesariamente incluir un esfuerzo adicional en cada aplicación que hayas desplegado. Esto es especialmente relevante si estás siguiendo un enfoque poliglota (como deberías) en las cargas de trabajo de tu clúster de Kubernetes.

Así que, esta vez vamos a hacer que nuestras aplicaciones manejen solo tráfico HTTP tanto interno como externo, y dependiendo de a dónde estemos llegando, forzaremos que esa conexión sea TLS sin que la carga de trabajo necesite ser consciente de ello. Así que, veamos cómo podemos habilitar esta configuración de TLS en Istio.

Vista del Escenario

Usaremos esta imagen que puedes ver a continuación para tener en mente los conceptos y componentes que interactuarán como parte de las diferentes configuraciones que aplicaremos a esto.

Asegura tus servicios con Istio: Una guía paso a paso para configurar conexiones TLS en Istio
https://www.solo.io/blog/istios-networking-in-depth/
  • Usaremos la puerta de enlace de entrada para manejar todo el tráfico entrante al clúster de Kubernetes y la puerta de enlace de salida para manejar todo el tráfico saliente del clúster.
  • Tendremos un contenedor sidecar desplegado en cada aplicación para manejar la comunicación desde las puertas de enlace o la comunicación de pod a pod.

Para simplificar las aplicaciones de prueba, usaremos las aplicaciones de muestra predeterminadas que Istio proporciona, las cuales puedes encontrar aquí.

¿Cómo Exponer TLS en Istio?

Esta es la parte más fácil, ya que toda la comunicación entrante que recibirás desde el exterior entrará al clúster a través de la Puerta de Enlace de Ingreso de Istio, por lo que es este componente el que necesita manejar la conexión TLS y luego usar el enfoque de seguridad habitual para hablar con el pod que expone la lógica.

Por defecto, la Puerta de Enlace de Ingreso de Istio ya expone un puerto TLS, como puedes ver en la imagen a continuación:

Asegura tus servicios con Istio: Una guía paso a paso para configurar conexiones TLS en Istio

Así que necesitaremos definir una Puerta de Enlace que reciba todo este tráfico a través de HTTPS y lo redirija a los pods, y lo haremos como puedes ver aquí:

apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
  name: bookinfo-gateway-https
  namespace: default
spec:
  selector:
    istio: ingressgateway
  servers:
    - hosts:
        - '*'
      port:
        name: https
        number: 443
        protocol: HTTPS
      tls:
        mode: SIMPLE # habilita HTTPS en este puerto
        credentialName: httpbin-credential

Como podemos ver, es una configuración sencilla, solo agregando el puerto HTTPS en el 443 y proporcionando la configuración TLS:

Y con eso, ya podemos acceder usando SSL a las mismas páginas:

Asegura tus servicios con Istio: Una guía paso a paso para configurar conexiones TLS en Istio

¿Cómo Consumir SSL desde Istio?

Ahora que hemos generado una solicitud TLS entrante sin que la aplicación sepa nada, vamos un paso más allá y hacemos la configuración más desafiante. Configuraremos la conexión TLS/SSL para cualquier comunicación saliente fuera del clúster de Kubernetes sin que la aplicación sepa nada al respecto.

Para hacerlo, usaremos uno de los conceptos de Istio que ya hemos cubierto en un artículo específico. Ese concepto es la Entrada de Servicio de Istio que nos permite definir un punto final para gestionarlo dentro del MESH.

Aquí podemos ver el punto final de Wikipedia agregado al registro de Service Mesh:

 apiVersion: networking.istio.io/v1beta1
kind: ServiceEntry
metadata:
  name: se-app
  namespace: default
spec:
  hosts:
  - wikipedia.org
  ports:
  - name: https
    number: 443
    protocol: HTTPS
  resolution: DNS

Una vez que hemos configurado la Entrada de Servicio, podemos definir una Regla de Destino para forzar que todas las conexiones a wikipedia.org usen la configuración TLS:

apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
  name: tls-app
  namespace: default
spec:
  host: wikipedia.org
  trafficPolicy:
    tls:
      mode: SIMPLE

Comprendiendo Istio ServiceEntry: Cómo Extender tu Malla de Servicios a Puntos de Extremo Externos

por
Comprendiendo Istio ServiceEntry: Cómo Extender tu Malla de Servicios a Puntos de Extremo Externos

¿Qué es un Istio ServiceEntry?

Istio ServiceEntry es la forma de definir un punto final que no pertenece al Registro de Servicios de Istio. Una vez que el ServiceEntry es parte del registro, puede definir reglas e imponer políticas como si pertenecieran a la malla.

Istio Service Entry responde a la pregunta que probablemente te has hecho varias veces al usar una Malla de Servicios. ¿Cómo puedo hacer la misma magia con puntos finales externos que puedo hacer cuando todo está bajo el alcance de mi malla de servicios? Y los objetos Istio Service Entry proporcionan precisamente eso:

Una forma de tener una malla extendida gestionando otro tipo de carga de trabajo o, aún mejor, en palabras del propio Istio:

ServiceEntry permite agregar entradas adicionales en el registro de servicios interno de Istio para que los servicios auto-descubiertos en la malla puedan acceder/rutear a estos servicios especificados manualmente.

Estos servicios podrían ser externos a la malla (por ejemplo, APIs web) o servicios internos de la malla que no son parte del registro de servicios de la plataforma (por ejemplo, un conjunto de VMs comunicándose con servicios en Kubernetes).

¿Cuáles son las principales capacidades de Istio ServiceEntry?

Aquí puedes ver un ejemplo de la definición YAML de un Service Entry:

apiVersion: networking.istio.io/v1beta1
kind: ServiceEntry
metadata:
  name: external-svc-redirect
spec:
  hosts:
  - wikipedia.org
  - "*.wikipedia.org"
  location: MESH_EXTERNAL
  ports:
  - number: 443
    name: https
    protocol: TLS
  resolution: NONE

En este caso, tenemos un objeto external-svc-redirectServiceEntry que está manejando todas las llamadas que van a wikipedia.org, y definimos el puerto y el protocolo a utilizar (TLS – 443) y clasificamos este servicio como externo a la malla (MESH_EXTERNAL) ya que es una página web externa.

También puedes especificar más detalles dentro de la configuración de ServiceEntry, para que puedas, por ejemplo, definir un nombre de host o IP y traducirlo a un nombre de host y puerto diferentes porque también puedes especificar el modo de resolución que deseas usar para este Service Entry específico. Si ves el fragmento anterior, encontrarás un campo resolution con el valor NONE que indica que no hará ninguna resolución particular. Pero otros valores válidos son los siguientes:

  • NONE: Asume que las conexiones entrantes ya han sido resueltas (a una dirección IP de destino específica).
  • STATIC: Usa las direcciones IP estáticas especificadas en los puntos finales como las instancias de respaldo asociadas con el servicio.
  • DNS: Intenta resolver la dirección IP consultando el DNS ambiental de manera asincrónica.
  • DNSROUNDROBIN: Intenta resolver la dirección IP consultando el DNS ambiental de manera asincrónica. A diferencia de DNS, DNSROUNDROBIN solo usa la primera dirección IP devuelta cuando se necesita iniciar una nueva conexión sin depender de los resultados completos de la resolución DNS, y las referencias hechas a los hosts se mantendrán incluso si los registros DNS cambian con frecuencia, eliminando el drenaje de grupos de conexiones y el ciclo de conexiones.

Para definir el objetivo del ServiceEntry, necesitas especificar sus puntos finales utilizando un objeto WorkloadEntry. Para hacerlo, necesitas proporcionar los siguientes datos:

  • address: Dirección asociada con el punto final de la red sin el puerto.
  • ports: Conjunto de puertos asociados con el punto final
  • weight: El peso de balanceo de carga asociado con el punto final.
  • locality: La localidad asociada con el punto final. Una localidad corresponde a un dominio de falla (por ejemplo, país/región/zona).
  • network: La red permite a Istio agrupar puntos finales residentes en el mismo dominio/red L3.

¿Qué puedes hacer con Istio ServiceEntry?

El número de casos de uso es enorme. Una vez que un ServiceEntry es similar a lo que tienes definido un Servicio Virtual, puedes aplicar cualquier regla de destino a ellos para hacer un balanceador de carga, un cambio de protocolo, o cualquier lógica que se pueda hacer con el objeto DestinationRule. Lo mismo se aplica al resto de los CRD de Istio, como RequestAuthentication y PeerAuthorization, entre otros.

También puedes tener una representación gráfica del ServiceEntry dentro de Kiali, una representación visual para la Malla de Servicios de Istio, como puedes ver en la imagen a continuación:

Entendiendo Istio ServiceEntry: Cómo Extender Tu Malla de Servicios a Puntos Finales Externos

Como puedes definir, una malla extendida con puntos finales fuera del clúster de Kubernetes es algo que se está volviendo más común con la explosión de clústeres disponibles y los entornos híbridos cuando necesitas gestionar clústeres de diferentes topologías y no perder la gestión centralizada basada en políticas de red que la Malla de Servicios de Istio proporciona a tu plataforma.

Grafana Alerting vs AlertManager: Una Comparación de Dos Herramientas de Monitoreo Líderes

por
Grafana Alerting vs AlertManager: Una Comparación de Dos Herramientas de Monitoreo Líderes

Introducción

Las capacidades de Grafana Alerting continúan mejorando en cada nueva versión que el equipo de GrafanaLabs realiza. Especialmente con los cambios realizados en Grafana 8 y Grafana 9, se han planteado muchas preguntas sobre su uso, las capacidades soportadas y la comparación con otras alternativas.

Queremos comenzar estableciendo el contexto sobre Grafana Alerting basado en el stack habitual que desplegamos para mejorar la observabilidad de nuestras cargas de trabajo. Grafana se puede usar para cualquier carga de trabajo; hay una preferencia por algunas específicas siendo la solución más utilizada cuando hablamos de cargas de trabajo en Kubernetes.

En este tipo de despliegue, el stack que usualmente desplegamos es Grafana como la herramienta de visualización y Prometheus como el núcleo para recopilar todas las métricas, de modo que todas las responsabilidades están diferenciadas. Grafana dibuja toda la información utilizando sus excelentes capacidades de paneles, recopilando la información de Prometheus.

Grafana Alerting vs AlertManager: Una Comparación de Dos Herramientas de Monitoreo Líderes

Cuando planeamos comenzar a incluir alertas, ya que no podemos aceptar que necesitamos tener un equipo específico solo observando paneles para detectar dónde algo está fallando, necesitamos implementar una forma de enviar alertas.

Las capacidades de alerta en Grafana han estado presentes desde el principio, pero sus capacidades en las primeras etapas se han limitado a generar alertas gráficas centradas en los paneles. En lugar de eso, Prometheus actuando como el cerebro, incluye un componente llamado AlertManager que puede manejar la creación y notificación de cualquier alerta generada a partir de toda la información almacenada en Prometheus.

Las principales capacidades que Alert Manager proporciona son la definición de las alertas, agrupación de las alertas, reglas de desestimación para silenciar algunas notificaciones, y finalmente, la forma de enviar esa alerta a cualquier sistema basado en un sistema de plugins y un webhook para poder extenderlo a cualquier componente disponible.

Grafana Alerting vs AlertManager: Una Comparación de Dos Herramientas de Monitoreo Líderes

Entonces, esta es la etapa inicial, pero esto ha cambiado con las últimas versiones de Grafana en los últimos meses, como se comentó, y ahora la barrera entre ambos componentes es mucho más difusa, como vamos a ver.

¿Cuáles son las principales capacidades que Grafana Alerting ofrece hoy en día?

Grafana Alerting te permite definir reglas de alerta definiendo los criterios bajo los cuales esta alerta debería activarse. Puede tener diferentes consultas, condiciones, frecuencia de evaluación y la duración durante la cual se cumple la condición.

Esta alerta puede generarse desde cualquiera de las fuentes soportadas en Grafana, y ese es un tema muy relevante ya que no se limita a los datos de Prometheus. Con la eclosión del stack de GrafanaLabs con muchos nuevos productos como Grafana Loki y Grafana Mimir, entre otros, esto es especialmente relevante.

Una vez que cada una de las alertas se activa, puedes definir una política de notificación para decidir dónde, cuándo y cómo se enruta cada una de estas alertas. Una política de notificación también tiene un punto de contacto asociado con uno o más notificadores.

Además, puedes silenciar alertas para dejar de recibir notificaciones de una instancia de alerta específica y silenciar alertas cuando puedes definir un período en el que no se generarán o notificarán nuevas alertas.

Todo eso con poderosas capacidades de paneles utilizando todo el poder de las características de paneles de Grafana.

Grafana Alerting vs AlertManager: Una Comparación de Dos Herramientas de Monitoreo Líderes

Grafana Alerting vs Prometheus Alert Manager

Después de leer la sección anterior probablemente estés confundido porque la mayoría de las nuevas características añadidas son muy similares a las que tenemos disponibles en Prometheus AlertManager.

Entonces, en ese caso, ¿qué herramienta deberíamos usar? ¿Deberíamos reemplazar Prometheus AlertManager y comenzar a usar Grafana Alerting? ¿Deberíamos usar ambos? Como puedes imaginar, esta es una de esas preguntas que no tiene respuestas claras ya que dependerá mucho del contexto y tu escenario específico, pero permíteme darte algunas indicaciones al respecto.

  • Grafana Alerting puede ser muy poderoso si ya estás dentro del stack de Grafana. Si ya estás usando Grafana Loki (y necesitas generar alertas desde él), Grafana Mimir, o directamente Grafana cloud, probablemente Grafana Alert proporcionará un mejor ajuste para tu ecosistema.
  • Si necesitas alertas complejas definidas con consultas y cálculos complejos, Prometheus AlertManager proporcionará un ecosistema mucho más complejo y rico para generar tus alertas.
  • Si estás buscando un enfoque SaaS, Grafana Alerting también se proporciona como parte de Grafana Cloud, por lo que se puede usar sin la necesidad de ser instalado en tu ecosistema.
  • Si estás usando Grafana Alerting, necesitas considerar que el mismo componente que sirve los paneles está computando y generando las alertas, lo que requeriría capacidades adicionales de HA. Habrá una relación inevitable entre ambas características (paneles y alertas). Supongamos que eso no resuena bien contigo porque la criticidad de tu panel no es la misma que la de las alertas, o piensas que el uso de tu panel puede afectar el rendimiento de las alertas. En ese caso, Prometheus Alert Manager proporcionará un mejor enfoque ya que se ejecuta en un pod específico en aislamiento.
  • En este momento, Grafana Alerting utiliza una base de datos SQL para gestionar la duplicación entre otras características, por lo que dependiendo del número de alertas con las que necesites trabajar, podría no ser suficiente en términos de rendimiento, y el uso de la base de datos de series temporales de Prometheus puede ser una mejor opción.

Resumen

Grafana Alerting es un progreso increíble en el camino del equipo de Grafana Labs para proporcionar un stack de observabilidad de extremo a extremo con un gran ajuste en el resto del ecosistema con la opción de ejecutarlo en modo SaaS y centrarse en la facilidad de uso. Pero hay mejores opciones dependiendo de tus necesidades.