Alexandre Vazquez

Maximizando la Calidad de la Configuración de Kubernetes con Kubeconform: Una Potente Herramienta para la Validación y Gestión Fluida de Kubernetes

por
Maximizando la Calidad de la Configuración de Kubernetes con Kubeconform: Una Potente Herramienta para la Validación y Gestión Fluida de Kubernetes

La API de Kubernetes cambia bastante, y sabemos que en cada nueva versión, están agregando nuevas capacidades al mismo tiempo que están desaprobando las antiguas, por lo que es una evolución constante, como ya mencionamos en artículos anteriores, como puedes ver aquí respecto a Autoscaling v2 y Autoscaling Vertical.

Algunos de estos cambios están relacionados con el cambio en la apiVersion de algunos objetos, y probablemente ya hayas sufrido de ese v1/alpha pasando a v1/beta o simplemente moviéndose a un v1 final y desaprobando el anterior. Por lo tanto, al final, es crucial asegurarse de que tu manifiesto esté sincronizado con la versión objetivo que estás implementando, y algunas herramientas pueden ayudarnos con eso, incluyendo Kubeconform.

¿Qué es Kubeconform?

Kubeconform es una poderosa utilidad diseñada para ayudar en la gestión y validación de configuraciones de Kubernetes. A medida que Kubernetes continúa ganando popularidad como la plataforma de orquestación de contenedores preferida, asegurar la corrección y consistencia de los archivos de configuración se vuelve crucial. Kubeconform aborda esta necesidad proporcionando un conjunto de herramientas integral para validar archivos de configuración de Kubernetes contra estándares predefinidos o reglas personalizadas.

Kubeconform admite múltiples versiones de Kubernetes, lo que te permite validar archivos de configuración contra diferentes versiones de API. Esta flexibilidad es beneficiosa al trabajar con clústeres que ejecutan diferentes versiones de Kubernetes o al migrar aplicaciones entre conjuntos con configuraciones variables.

Otra gran característica de Kubeconform es su capacidad para hacer cumplir las mejores prácticas y estándares en las configuraciones de Kubernetes. Te permite definir reglas, como hacer cumplir etiquetas adecuadas, límites de recursos o políticas de seguridad, y luego valida tus archivos de configuración contra estas reglas. Esto ayuda a detectar posibles problemas desde el principio y asegura que tus implementaciones cumplan con las pautas establecidas.

¿Cómo instalar Kubeconform?

Kubeconform se puede instalar desde diferentes fuentes, las más usuales son las estándar para tu entorno usando gestores de paquetes como brew, apt o similares, o simplemente obteniendo los binarios desde su página de GitHub: https://github.com/yannh/kubeconform/releases.

Maximizando la Calidad de la Configuración de Kubernetes con Kubeconform: Una Potente Herramienta para la Validación y Gestión Fluida de Kubernetes

¿Cómo lanzar Kubeconform desde la Línea de Comandos?

Kubeconform se distribuye como un pequeño binario destinado a ser ejecutado en la interfaz CLI y trata de mantener su interfaz mínima para asegurar la compatibilidad. Por lo tanto, recibe un argumento con el archivo o carpeta con los archivos de manifiesto que deseas verificar, como puedes ver aquí:

Maximizando la Calidad de la Configuración de Kubernetes con Kubeconform: Una Potente Herramienta para la Validación y Gestión Fluida de Kubernetes

Luego tienes varias opciones para hacer otras cosas, como las que se muestran a continuación:

-ignore-filename-pattern valor

expresión regular que especifica rutas a ignorar (se puede especificar varias veces)

-ignore-missing-schemas

omitir archivos con esquemas faltantes en lugar de fallar

-Kubernetes-version cadena

versión de Kubernetes contra la cual validar, por ejemplo: 1.18.0 (por defecto «master»)

-output cadena

formato de salida – json, junit, pretty, tap, text (por defecto «text»)

-reject cadena

lista separada por comas de tipos o GVKs a rechazar

-skip cadena

lista separada por comas de tipos o GVKs a ignorar

-strict

no permitir propiedades adicionales no en el esquema o claves duplicadas

-summary

imprimir un resumen al final (ignorado para salida junit)

Casos de uso de Kubeconform

Existen diferentes casos de uso donde Kubeconform puede desempeñar un buen papel. Uno es respecto a las actualizaciones de Kubernetes, a veces necesitas asegurarte de que tu manifiesto actual seguirá funcionando en la nueva versión a la que se actualizará el clúster, y con esta herramienta, podemos asegurarnos de que nuestro YAML sigue siendo compatible con la última versión obteniéndolo directamente del entorno y validándolo adecuadamente.

Otro aspecto notable de Kubeconform es su integración perfecta en los pipelines de CI/CD existentes. Puedes incorporar fácilmente kubeconform como un paso en tu pipeline para validar automáticamente los archivos de configuración de Kubernetes antes de implementarlos. Al hacerlo, puedes detectar errores de configuración temprano en el proceso de desarrollo, reducir el riesgo de fallos de implementación y mantener una alta consistencia de configuración.

Además de sus capacidades de validación, kubeconform proporciona comentarios útiles y sugerencias para mejorar tus archivos de configuración de Kubernetes. Resalta problemas específicos o desviaciones de las reglas definidas y ofrece orientación sobre cómo abordarlos. Esto simplifica el proceso de resolución de problemas y ayuda a los desarrolladores y administradores a familiarizarse más con las mejores prácticas y estándares de configuración de Kubernetes.

Conclusión

Kubeconform es una utilidad invaluable para los usuarios de Kubernetes que buscan implementaciones confiables y consistentes. Empodera a los equipos para mantener un alto estándar de calidad de configuración, reduce la probabilidad de configuraciones erróneas y mejora la estabilidad y seguridad general de las aplicaciones basadas en Kubernetes.

📚 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.

Explorando las Políticas de Seguridad de Istio para una Protección Mejorada de la Malla de Servicios con 3 Objetos

por
Explorando las Políticas de Seguridad de Istio para una Protección Mejorada de la Malla de Servicios con 3 Objetos

Las Políticas de Seguridad de Istio son cruciales para asegurar los microservicios dentro de un entorno de malla de servicios. Hemos discutido Istio y las capacidades que puede introducir a tus cargas de trabajo de Kubernetes. Sin embargo, hoy vamos a ser más detallados respecto a los diferentes objetos y recursos que nos ayudarían a hacer nuestras cargas de trabajo mucho más seguras y a reforzar la comunicación entre ellas. Estos objetos incluyen los objetos PeerAuthentication, RequestAuthentication y AuthorizationPolicy.

PeerAuthentication: Aplicando seguridad en la comunicación de pod a pod

PeerAuthentication se centra en asegurar la comunicación entre servicios aplicando autenticación y autorización mutua TLS (Transport Layer Security). Permite a los administradores definir políticas de autenticación para cargas de trabajo basadas en la fuente de las solicitudes, como namespaces específicos o cuentas de servicio. Configurar PeerAuthentication asegura que solo los servicios autenticados y autorizados puedan comunicarse, previniendo el acceso no autorizado y los ataques de intermediarios. Esto se puede lograr dependiendo del valor del modo donde se define este objeto siendo STRICT para solo permitir comunicación mTLS, PERMISSIVE para permitir ambos tipos de comunicación, DISABLE para prohibir la conexión mTLS y mantener el tráfico inseguro, y UNSET para usar la opción heredada. Este es un ejemplo de la definición del objeto:

apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
  name: default
  namespace: foo
spec:
  mtls:
    mode: PERMISSIVE

RequestAuthentication: Definiendo métodos de autenticación para cargas de trabajo de Istio

RequestAuthentication, por otro lado, proporciona un control detallado sobre la autenticación de solicitudes entrantes. Permite a los administradores especificar reglas y requisitos para validar y autenticar solicitudes entrantes basadas en factores como la validación de JWT (JSON Web Tokens), claves API o métodos de autenticación personalizados. Con RequestAuthentication, los propietarios de servicios pueden aplicar mecanismos de autenticación específicos para diferentes puntos finales o rutas, asegurando que solo los clientes autenticados puedan acceder a recursos protegidos. Aquí puedes ver un ejemplo de un objeto RequestAuthentication:

apiVersion: security.istio.io/v1beta1
kind: RequestAuthentication
metadata:
  name: jwt-auth-policy
  namespace: my-namespace
spec:
  selector:
    matchLabels:
      app: my-app
  jwtRules:
    - issuer: "issuer.example.com"
      jwksUri: "https://example.com/.well-known/jwks.json"

Como se comentó, la validación de JWT es el enfoque más utilizado ya que los tokens JWT se están convirtiendo en el estándar de la industria para validaciones entrantes y el protocolo de autorización OAuth V2. Aquí puedes definir las reglas que el JWT necesita cumplir para ser considerado una solicitud válida. Pero el RequestAuthentication solo describe los “métodos de autenticación” soportados por las cargas de trabajo pero no lo aplica ni proporciona detalles sobre la Autorización.

Eso significa que si defines que una carga de trabajo necesita usar autenticación JWT, enviar la solicitud con el token validará ese token y asegurará que no esté expirado. Cumple con todas las reglas que has especificado en la definición del objeto, pero también permitirá pasar solicitudes sin token alguno, ya que solo estás definiendo lo que las cargas de trabajo soportan pero no lo aplicas. Para hacer eso, necesitamos introducir el último objeto de este conjunto, el objeto AuthorizationPolicy.

AuthorizationPolicy: Definición de Políticas de Autorización Detalladas para Políticas de Istio

AuthorizationPolicy ofrece potentes capacidades de control de acceso para regular el flujo de tráfico dentro de la malla de servicios. Permite a los administradores definir reglas y condiciones basadas en atributos como fuente, destino, encabezados e incluso carga útil de la solicitud para determinar si una solicitud debe ser permitida o denegada. AuthorizationPolicy ayuda a aplicar reglas de autorización detalladas, otorgando o denegando acceso a recursos o acciones específicas basadas en las políticas definidas. Solo los clientes autorizados con permisos apropiados pueden acceder a puntos finales específicos o realizar operaciones particulares dentro de la malla de servicios. Aquí puedes ver un ejemplo de un objeto Authorization Policy:

apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: rbac-policy
  namespace: my-namespace
spec:
  selector:
    matchLabels:
      app: my-app
  rules:
    - from:
        - source:
            principals: ["user:user@example.com"]
      to:
        - operation:
            methods: ["GET"]

Aquí puedes ser tan detallado como necesites; puedes aplicar reglas sobre la fuente de la solicitud para asegurar que solo algunas recomendaciones puedan pasar (por ejemplo, solicitudes que provienen de un token JWT para usar en combinación con el objeto RequestAuthentication), pero también reglas sobre el destino, si esto va a un host o ruta específica o método o una combinación de ambos. Además, puedes aplicar reglas de PERMITIR o DENEGAR (o incluso PERSONALIZADAS) y definir un conjunto de ellas, y todas se aplicarán en su conjunto. La evaluación se determina por las siguientes reglas como se indica en la Documentación Oficial de Istio:

  • Si hay políticas PERSONALIZADAS que coinciden con la solicitud, evalúa y niega la solicitud si el resultado de la evaluación es denegado.
  • Si hay políticas de DENEGAR que coinciden con la solicitud, niega la solicitud.
  • Si no hay políticas de PERMITIR para la carga de trabajo, permite la solicitud.
  • Si alguna de las políticas de PERMITIR coincide con la solicitud, permite la solicitud. Niega la solicitud.
Flujo de validación de la Política de Autorización de: https://istio.io/latest/docs/concepts/security/

Esto proporcionará todos los requisitos que podrías necesitar para poder hacer una definición completa de todas las políticas de seguridad necesarias.

 Conclusión

En conclusión, las Políticas de Seguridad de Istio proporcionan mecanismos robustos para mejorar la seguridad de los microservicios dentro de un entorno de malla de servicios. Los objetos PeerAuthentication, RequestAuthentication y AuthorizationPolicy ofrecen un conjunto de herramientas integral para aplicar controles de autenticación y autorización, asegurando la comunicación segura y el control de acceso dentro de la malla de servicios. Al aprovechar estas Políticas de Seguridad de Istio, las organizaciones pueden fortalecer la postura de seguridad de sus microservicios, protegiendo datos sensibles y previniendo el acceso no autorizado o actividades maliciosas dentro de su entorno de malla de servicios.

Seguridad en Kubernetes: Un Viaje Colaborativo para Todos los Roles

por
Seguridad en Kubernetes: Un Viaje Colaborativo para Todos los Roles

La seguridad de Kubernetes es uno de los aspectos más críticos hoy en día en el mundo de TI. Kubernetes se ha convertido en la columna vertebral de la gestión moderna de infraestructuras, permitiendo a las organizaciones escalar y desplegar aplicaciones en contenedores con facilidad. Sin embargo, el poder de Kubernetes también conlleva la responsabilidad de garantizar que se implementen medidas de seguridad robustas. Esta responsabilidad no puede recaer únicamente en los desarrolladores o los operadores. Requiere un esfuerzo colaborativo donde ambas partes trabajen juntas para mitigar riesgos y vulnerabilidades potenciales.

Aunque los enfoques de DevOps e Ingeniería de Plataformas son bastante estándar, todavía hay tareas responsables de diferentes equipos, incluso aunque hoy en día existan equipos de plataforma y de proyecto.

Aquí verás tres formas fáciles de mejorar la seguridad de Kubernetes desde las perspectivas de desarrollo y operaciones:

Sin Vulnerabilidades en Imágenes de Contenedores

El escaneo de vulnerabilidades en imágenes de contenedores es algo crucial en los desarrollos actuales porque el número de componentes desplegados en el sistema ha crecido exponencialmente, así como su opacidad. El escaneo de vulnerabilidades utilizando herramientas como Trivy o las opciones integradas en nuestros entornos locales de Docker como Docker Desktop o Rancher Desktop es obligatorio, pero ¿cómo puedes usarlo para hacer tu aplicación más segura?

  • Responsabilidad del desarrollador:
    • Usar solo imágenes base estándar permitidas, bien conocidas
    • Reducir, al mínimo, el número de componentes y paquetes a instalar con tu aplicación (mejor Alpine que Debian)
    • Usar un enfoque de múltiples etapas para incluir solo lo que necesitarás en tus imágenes.
    • Realizar un escaneo de vulnerabilidades localmente antes de hacer push
  • Responsabilidad del operador:
    • Forzar la descarga de todas las imágenes base para el registro de contenedores corporativo
    • Imponer el escaneo de vulnerabilidades al hacer push, generando alertas y evitando el despliegue si no se cumplen los criterios de calidad.
    • Realizar escaneos de vulnerabilidades regulares para imágenes en tiempo de ejecución y generar incidentes para los equipos de desarrollo basados en los problemas descubiertos.

Sin Privilegios Adicionales en Imágenes de Contenedores

Ahora que nuestra aplicación no incluye ninguna vulnerabilidad, necesitamos asegurarnos de que la imagen no esté permitida para hacer lo que no debería, como elevar privilegios. Ve lo que puedes hacer dependiendo de tu rol:

  • Responsabilidad del desarrollador:
    • Nunca crear imágenes con usuario root y usar opciones de contexto de seguridad en tus archivos de manifiesto de Kubernetes
    • Probar tus imágenes con todas las capacidades posibles eliminadas a menos que se necesiten por alguna razón específica
    • Hacer que tu sistema de archivos sea de solo lectura y usar volúmenes para las carpetas requeridas en tu aplicación.
  • Responsabilidad del operador:

Restringir la visibilidad entre componentes

Cuando diseñamos aplicaciones hoy en día, se espera que necesiten conectarse a otras aplicaciones y componentes, y las capacidades de descubrimiento de servicios en Kubernetes son excelentes en cómo podemos interactuar. Sin embargo, esto también permite que otras aplicaciones se conecten a servicios a los que tal vez no deberían. Ve lo que puedes hacer para ayudar en ese aspecto dependiendo de tu rol y responsabilidad:

  • Responsabilidad del desarrollador:
    • Asegurarse de que tu aplicación tenga políticas adecuadas de autenticación y autorización para evitar cualquier uso no autorizado de tu aplicación.
  • Responsabilidad de operación:
    • Gestionar a nivel de plataforma la visibilidad de red de los componentes, pero denegar todo el tráfico por defecto y permitir las conexiones requeridas por diseño usando Políticas de Red.
    • Usar herramientas de Service Mesh para tener un enfoque central para la autenticación y autorización.
    • Usar herramientas como Kiali para monitorear el tráfico de red y detectar patrones de tráfico irrazonables.

Conclusión

En conclusión, la importancia de la seguridad en Kubernetes no puede ser subestimada. Requiere colaboración y responsabilidad compartida entre desarrolladores y operadores. Al enfocarse en prácticas como el escaneo de vulnerabilidades, la restricción de privilegios adicionales y la restricción de visibilidad entre componentes, las organizaciones pueden crear un entorno de Kubernetes más seguro. Al trabajar juntos, los desarrolladores y operadores pueden fortalecer el ecosistema de contenedores, protegiendo aplicaciones, datos y activos empresariales críticos de posibles brechas de seguridad. Con un enfoque colaborativo en la seguridad de Kubernetes, las organizaciones pueden aprovechar con confianza todo el potencial de esta poderosa plataforma de orquestación mientras mantienen los más altos estándares de seguridad. Al adoptar estas prácticas, las organizaciones pueden crear un entorno de Kubernetes más seguro, protegiendo sus aplicaciones y datos de amenazas potenciales.

📚 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.

Optimización del Rendimiento: Autoscaling Vertical en Kubernetes

por
Optimización del Rendimiento: Autoscaling Vertical en Kubernetes

Kubernetes ha introducido como su versión alfa en su lanzamiento de Kubernetes 1.27 la capacidad de Autoscaling Vertical de Pods para proporcionar la opción de que la carga de trabajo de Kubernetes pueda escalar utilizando el enfoque «vertical» al agregar más recursos a un pod existente. Esto aumenta las capacidades de escalado automático de sus cargas de trabajo de Kubernetes que tiene a su disposición, como KEDA o Autoscaling Horizontal de Pods.

Escalado Vertical vs Escalado Horizontal

El escalado vertical y horizontal son dos enfoques utilizados para aumentar el rendimiento y la capacidad de los sistemas informáticos, particularmente en sistemas distribuidos y computación en la nube. El escalado vertical, también conocido como escalado hacia arriba o escalado verticalmente, implica agregar más recursos, como potencia de procesamiento, memoria o almacenamiento, a una sola instancia o servidor. Esto significa actualizar los componentes de cómputo existentes o migrar a una infraestructura más potente. El escalado vertical a menudo es sencillo de implementar y requiere cambios mínimos en la arquitectura del software. Se utiliza comúnmente cuando las demandas del sistema pueden ser satisfechas por una sola infraestructura más potente.

Por otro lado, el escalado horizontal, también llamado escalado hacia afuera o escalado horizontalmente, implica agregar más instancias o servidores para distribuir la carga de trabajo. En lugar de actualizar una sola instancia, se emplean múltiples instancias, cada una manejando una parte de la carga de trabajo. El escalado horizontal ofrece la ventaja de aumentar la redundancia y la tolerancia a fallos, ya que múltiples instancias pueden compartir la carga. Además, proporciona la capacidad de manejar cargas de trabajo más grandes simplemente agregando más máquinas al clúster. Sin embargo, el escalado horizontal a menudo requiere arquitecturas de software más complejas, como balanceo de carga y sistemas de archivos distribuidos, para distribuir y gestionar eficientemente la carga de trabajo entre las máquinas.

En resumen, el escalado vertical implica mejorar las capacidades de un solo objeto, mientras que el escalado horizontal implica distribuir la carga de trabajo entre múltiples instancias. El escalado vertical es más fácil de implementar, pero puede tener limitaciones en términos de los recursos máximos disponibles en una sola máquina. El escalado horizontal proporciona mejor escalabilidad y tolerancia a fallos, pero requiere una infraestructura de software más compleja. La elección entre el escalado vertical y horizontal depende de factores como los requisitos específicos del sistema, la carga de trabajo esperada y los recursos disponibles.

¿Por qué el Autoscaling Vertical de Kubernetes?

Este es un tema interesante porque hemos estado viviendo en un mundo donde el estado era que siempre era mejor escalar hacia afuera (usando el Escalado Horizontal) en lugar de escalar hacia arriba (usando el Escalado Vertical) y especialmente este era uno de los mantras que escuchabas en desarrollos nativos de la nube. Y eso no ha cambiado porque el escalado horizontal proporciona muchos más beneficios que el escalado vertical y está bien cubierto con las capacidades de Autoscaling o proyectos paralelos como KEDA. Entonces, en ese caso, ¿por qué Kubernetes está incluyendo esta característica y por qué estamos usando este sitio para discutirlo?

Porque con la transformación de Kubernetes para ser la alternativa de facto para cualquier implementación que realices hoy en día, las características y capacidades de las cargas de trabajo que necesitas manejar se han ampliado y por eso necesitas usar diferentes técnicas para proporcionar la mejor experiencia a cada uno de los tipos de cargas de trabajo.

¿Cómo el Autoscaling Vertical de Kubernetes?

Aquí encontrarás toda la documentación sobre esta nueva característica que, como se comentó, todavía está en la etapa «alfa», por lo que es algo para probar en modo experimental en lugar de usarlo a nivel de producción Documentación de HPA

El Escalado Vertical funciona de manera que podrás cambiar los recursos asignados al pod, CPU y memoria sin necesidad de reiniciar el pod y cambiar la declaración del manifiesto, y ese es un claro beneficio de este enfoque. Como sabes, hasta ahora si quieres cambiar los recursos aplicados a una carga de trabajo necesitas actualizar el documento del manifiesto y reiniciar el pod para aplicar los nuevos cambios.

Para definir esto necesitas especificar el resizePolicy agregando una nueva sección al manifiesto del pod como puedes ver aquí:

apiVersion: v1
kind: Pod
metadata:
  name: qos-demo-5
  namespace: qos-example
spec:
  containers:
  - name: qos-demo-ctr-5
    image: nginx
    resizePolicy:
    - resourceName: cpu
      restartPolicy: NotRequired
    - resourceName: memory
      restartPolicy: RestartContainer
    resources:
      limits:
        memory: "200Mi"
        cpu: "700m"
      requests:
        memory: "200Mi"
        cpu: "700m"

Por ejemplo, en este caso definimos para los diferentes nombres de recursos la política que queremos aplicar, si vamos a cambiar la CPU asignada no requerirá un reinicio, pero en caso de que estemos cambiando la memoria, requeriría un reinicio.

Eso implica que si deseas cambiar la CPU asignada, puedes parchear directamente el manifiesto como puedes ver en el fragmento a continuación y eso proporciona una actualización de los recursos asignados:

 kubectl -n qos-example patch pod qos-demo-5 --patch '{"spec":{"containers":[{"name":"qos-demo-ctr-5", "resources":{"requests":{"cpu":"800m"}, "limits":{"cpu":"800m"}}}]}}'

¿Cuándo usar el Escalado Vertical son los escenarios objetivo?

Dependerá de muchos escenarios diferentes del caso de uso, pero también de la pila tecnológica que está utilizando tu carga de trabajo para saber cuáles de estas capacidades pueden aplicarse. Como algo normal, el cambio de CPU será fácil de adaptar a cualquier tecnología, pero el de memoria sería más difícil dependiendo de la tecnología utilizada, ya que en la mayoría de las tecnologías la memoria asignada se define en el momento del inicio.

Esto ayudará a actualizar componentes que han cambiado sus requisitos como un escenario promedio o cuando estás probando nuevas cargas de trabajo con carga en vivo y no quieres interrumpir el procesamiento actual de la aplicación o simplemente cargas de trabajo que no admiten el escalado horizontal porque están diseñadas en modo de réplica única.

 Conclusión

En conclusión, Kubernetes ha introducido el Autoscaling Vertical de Pods, permitiendo el autoscaling vertical de cargas de trabajo de Kubernetes al agregar recursos a pods existentes. El autoscaling vertical de Kubernetes permite cambios de recursos sin reiniciar pods, proporcionando flexibilidad en la gestión de asignaciones de CPU y memoria.

El autoscaling vertical de Kubernetes ofrece una opción valiosa para adaptarse a las necesidades cambiantes de las cargas de trabajo. Complementa el escalado horizontal al proporcionar flexibilidad sin la necesidad de arquitecturas de software complejas. Al combinar enfoques de escalado vertical y horizontal, los usuarios de Kubernetes pueden optimizar sus implementaciones en función de las características específicas de la carga de trabajo y los recursos disponibles.

📚 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.

Cómo usar SoapUI integrado con Maven para pruebas de automatización

por
Cómo usar SoapUI integrado con Maven para pruebas de automatización

SoapUI es una herramienta popular de código abierto utilizada para probar APIs SOAP y REST. Viene con una interfaz fácil de usar y una variedad de características para ayudarte a probar solicitudes y respuestas de API. En este artículo, exploraremos cómo usar SoapUI integrado con Maven para pruebas de automatización.

¿Por qué usar SoapUI con Maven?

Maven es una popular herramienta de automatización de construcción que simplifica la construcción y gestión de proyectos Java. Es ampliamente utilizada en la industria y tiene muchas características que la hacen una opción ideal para pruebas de automatización con SoapUI.

Al integrar SoapUI con Maven, puedes ejecutar fácilmente tus pruebas de SoapUI como parte de tu proceso de construcción de Maven. Esto te ayudará a automatizar tu proceso de pruebas, reducir el tiempo necesario para probar tus APIs y asegurarte de que tus pruebas estén siempre actualizadas.

Configuración de SoapUI y Maven

Antes de que podamos comenzar a usar SoapUI con Maven, debemos configurar ambas herramientas en nuestro sistema. Primero, descarga e instala SoapUI desde el sitio web oficial. Una vez que SoapUI esté instalado, podemos proceder con la instalación de Maven.

Para instalar Maven, sigue estos pasos:

  1. Descarga la última versión de Maven desde el sitio web oficial.
  2. Extrae el archivo descargado en un directorio de tu sistema.
  3. Agrega el directorio bin de la carpeta extraída a la variable de entorno PATH de tu sistema.
  4. Verifica que Maven esté instalado abriendo una terminal o símbolo del sistema y ejecutando el comando mvn -version.

Creación de un Proyecto Maven para Pruebas de SoapUI

Ahora que tenemos tanto SoapUI como Maven instalados, podemos crear un proyecto Maven para nuestras pruebas de SoapUI. Para crear un nuevo proyecto Maven, sigue estos pasos:

  1. Abre una terminal o símbolo del sistema y navega al directorio donde deseas crear tu proyecto.
  2. Ejecuta el siguiente comando: mvn archetype:generate -DgroupId=com.example -DartifactId=my-soapui-project -DarchetypeArtifactId=maven-archetype-quickstart -DinteractiveMode=false
  3. Esto creará un nuevo proyecto Maven con el ID de grupo com.example y el ID de artefacto my-soapui-project.

Añadiendo Pruebas de SoapUI al Proyecto Maven

Ahora que tenemos un proyecto Maven, podemos añadir nuestras pruebas de SoapUI al proyecto. Para hacer esto, sigue estos pasos:

  1. Crea un nuevo proyecto de SoapUI abriendo SoapUI y seleccionando Archivo > Nuevo Proyecto SOAP.
  2. Sigue las indicaciones para crear un nuevo proyecto, incluyendo especificar el archivo WSDL y el endpoint para tu API.
  3. Una vez que tu proyecto esté creado, crea un nuevo conjunto de pruebas y añade tus casos de prueba.
  4. Guarda tu proyecto de SoapUI.

A continuación, necesitamos añadir nuestro proyecto de SoapUI a nuestro proyecto Maven. Para hacer esto, sigue estos pasos:

  1. En el directorio de tu proyecto Maven, crea un nuevo directorio llamado src/test/resources.
  2. Copia tu archivo de proyecto de SoapUI (.xml) a este directorio.
  3. En el archivo pom.xml de tu proyecto Maven, añade el siguiente código:
<build>
  <plugins>
    <plugin>
      <groupId>com.smartbear.soapui</groupId>
      <artifactId>soapui-maven-plugin</artifactId>
      <version>5.6.0</version>
      <configuration>
        <projectFile>1/src/test/resources/my-soapui-project.xml</projectFile>
        <outputFolder>1/target/surefire-reports</outputFolder>
        <junitReport>true</junitReport>
        <exportwAll>true</exportwAll>
      </configuration>
      <executions>
        <execution>
          <phase>test</phase>
          <goals>
            <goal>test</goal>
          </goals>
        </execution>
      </executions>
    </plugin>
  </plugins>
</build>

Este código configura el plugin de Maven de SoapUI para ejecutar nuestras pruebas de SoapUI durante la fase de test del proceso de construcción de Maven.

Creando Aserciones en Proyectos de SoapUI

Ahora que hemos añadido nuestras pruebas de SoapUI a nuestro proyecto Maven, podemos crear aserciones para validar las respuestas de nuestras llamadas a la API. Para crear aserciones en SoapUI, sigue estos pasos:

  1. Abre tu proyecto de SoapUI y navega al caso de prueba donde deseas crear una aserción.
  2. Haz clic derecho en el paso que deseas validar y selecciona Añadir Aserción.
  3. Elige el tipo de aserción que deseas crear (por ejemplo, Contiene, XPath Match, Códigos de Estado HTTP Válidos, etc.).
  4. Configura la aserción de acuerdo a tus necesidades.
  5. Guarda tu proyecto de SoapUI.
Cómo usar SoapUI integrado con Maven para pruebas de automatización

Ejecutando Pruebas de SoapUI con Aserciones Usando Maven

Ahora que hemos añadido nuestras pruebas de SoapUI y aserciones a nuestro proyecto Maven, podemos ejecutarlas usando Maven. Para ejecutar tus pruebas de SoapUI con Maven y validar las respuestas usando aserciones, sigue estos pasos:

  1. Abre una terminal o símbolo del sistema y navega al directorio de tu proyecto Maven.
  2. Ejecuta el siguiente comando: mvn clean test
  3. Esto ejecutará tus pruebas de SoapUI y generará un informe en el directorio target/surefire-reports de tu proyecto Maven.

Durante la ejecución de la prueba, si alguna aserción falla, la prueba fallará y se mostrará un mensaje de error en la consola. Al crear aserciones, podemos asegurarnos de que nuestras llamadas a la API estén devolviendo las respuestas esperadas.

Conclusión

En este artículo, hemos aprendido cómo usar SoapUI integrado con Maven para pruebas de automatización, incluyendo cómo crear aserciones en proyectos de SoapUI. Al usar estas dos herramientas juntas, podemos automatizar nuestro proceso de pruebas, reducir el tiempo necesario para probar nuestras APIs y asegurarnos de que nuestras pruebas estén siempre actualizadas. Si estás buscando comenzar con pruebas de automatización usando SoapUI y Maven, ¡prueba este tutorial!

¿Cómo habilitar la sesión persistente en tus cargas de trabajo de Kubernetes usando Istio?

por
¿Cómo habilitar la sesión persistente en tus cargas de trabajo de Kubernetes usando Istio?

Istio te permite configurar Sticky Session, entre otras características de red, para tus cargas de trabajo de Kubernetes. Como hemos comentado en varios artículos sobre Istio, istio despliega una malla de servicios que proporciona un plano de control central para tener toda la configuración relacionada con los aspectos de red de tus cargas de trabajo de Kubernetes. Esto cubre muchos aspectos diferentes de la comunicación dentro de la plataforma de contenedores, como la seguridad que cubre el transporte seguro, la autenticación o la autorización, y, al mismo tiempo, características de red, como el enrutamiento y la distribución de tráfico, que es el tema principal del artículo de hoy.

Estas capacidades de enrutamiento son similares a lo que un Balanceador de Carga tradicional de Nivel 7 puede proporcionar. Cuando hablamos de Nivel 7, nos referimos a los niveles convencionales que componen la pila OSI, donde el nivel 7 está relacionado con el Nivel de Aplicación.

Una configuración de Sticky Session o Afinidad de Sesión es una de las características más comunes que puedes necesitar implementar en este escenario. El caso de uso es el siguiente:

¿Cómo habilitar Sticky Session en tus cargas de trabajo de Kubernetes usando Istio?

Tienes varias instancias de tus cargas de trabajo, por lo que diferentes réplicas de pods en una situación de Kubernetes. Todos estos pods detrás del mismo servicio. Por defecto, redirigirá las solicitudes de manera round-robin entre las réplicas de pods en un estado Ready, por lo que Kubernetes entiende que están listas para recibir la solicitud a menos que lo definas de manera diferente.

Pero en algunos casos, principalmente cuando estás tratando con una aplicación web o cualquier aplicación con estado que maneja el concepto de una sesión, podrías querer que la réplica que procesa la primera solicitud también maneje el resto de las solicitudes durante la vida útil de la sesión.

Por supuesto, podrías hacer eso fácilmente simplemente enrutando todo el tráfico a una solicitud, pero en ese caso, perderíamos otras características como el balanceo de carga de tráfico y HA. Entonces, esto generalmente se implementa usando políticas de Afinidad de Sesión o Sticky Session que proporcionan lo mejor de ambos mundos: la misma réplica manejando todas las solicitudes de un usuario, pero distribución de tráfico entre diferentes usuarios.

¿Cómo funciona Sticky Session?

El comportamiento detrás de esto es relativamente fácil. Veamos cómo funciona.

Primero, lo importante es que necesitas «algo» como parte de tus solicitudes de red que identifique todas las solicitudes que pertenecen a la misma sesión, para que el componente de enrutamiento (en este caso, este rol lo desempeña istio) pueda determinar qué parte necesita manejar estas solicitudes.

Este «algo» que usamos para hacer eso, puede ser diferente dependiendo de tu configuración, pero generalmente, esto es una Cookie o un Encabezado HTTP que enviamos en cada solicitud. Por lo tanto, sabemos que la réplica maneja todas las solicitudes de ese tipo específico.

¿Cómo implementa Istio el soporte para Sticky Session?

En el caso de usar Istio para desempeñar este rol, podemos implementar eso usando una Regla de Destino específica que nos permite, entre otras capacidades, definir la política de tráfico para definir cómo queremos que se divida el tráfico y para implementar el Sticky Session necesitamos usar la característica “consistentHash”, que permite que todas las solicitudes que se computan al mismo hash sean enviadas a la réplica.

Cuando definimos las características de consistentHash, podemos decir cómo se creará este hash y, en otras palabras, qué componentes se usarán para generar este hash, y esto puede ser una de las siguientes opciones:

  • httpHeaderName: Usa un Encabezado HTTP para hacer la distribución de tráfico
  • httpCookie: Usa una Cookie HTTP para hacer la distribución de tráfico
  • httpQueryParameterName: Usa una Cadena de Consulta para hacer la Distribución de Tráfico.
  • maglev: Usa el Balanceador de Carga Maglev de Google para hacer la determinación. Puedes leer más sobre Maglev en el artículo de Google.
  • ringHash: Usa un enfoque de hash basado en anillo para el balanceo de carga entre los pods disponibles.

Entonces, como puedes ver, tendrás muchas opciones diferentes. Aún así, solo las tres primeras serían las más utilizadas para implementar una sesión persistente, y generalmente, la opción de Cookie HTTP (httpCookie) será la preferida, ya que se basaría en el enfoque HTTP para gestionar la sesión entre clientes y servidores.

Ejemplo de Implementación de Sticky Session usando TIBCO BW

Definiremos una carga de trabajo TIBCO BW muy simple para implementar un servicio REST, sirviendo una respuesta GET con un valor codificado. Para simplificar el proceso de validación, la aplicación registrará el nombre de host del pod para que rápidamente podamos ver quién está manejando cada una de las solicitudes:

¿Cómo habilitar Sticky Session en tus cargas de trabajo de Kubernetes usando Istio?

Desplegamos esto en nuestro clúster de Kubernetes y lo exponemos usando un servicio de Kubernetes; en nuestro caso, el nombre de este servicio será test2-bwce-srv

Además de eso, aplicamos la configuración de istio, que requerirá tres (3) objetos de istio: gateway, servicio virtual y la regla de destino. Como nuestro enfoque está en la regla de destino, intentaremos mantenerlo lo más simple posible en los otros dos objetos:

 apiVersion: networking.istio.io/v1beta1
kind: Gateway
metadata:
  name: default-gw
spec:
  selector:
    istio: ingressgateway
  servers:
  - hosts:
    - '*'
    port:
      name: http
      number: 80
      protocol: HTTP

Servicio Virtual:

apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: test-vs
spec:
  gateways:
  - default-gw
  hosts:
  - test.com
  http:
  - match:
    - uri:
        prefix: /
    route:
    - destination:
        host: test2-bwce-srv
        port:
          number: 8080

Y finalmente, la DestinationRule usará una httpCookie que llamaremos ISTIOD, como puedes ver en el fragmento a continuación:

apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
    name: default-sticky-dr
    namespace: default
spec:
    host: test2-bwce-srv.default.svc.cluster.local
    trafficPolicy:
      loadBalancer:
        consistentHash:
          httpCookie: 
            name: ISTIOID
            ttl: 60s

Ahora, que ya hemos comenzado nuestra prueba, y después de lanzar la primera solicitud, obtenemos una nueva Cookie que es generada por istio mismo que se muestra en la ventana de respuesta de Postman:

¿Cómo habilitar la sesión persistente en tus cargas de trabajo de Kubernetes usando Istio?

Esta solicitud ha sido manejada por una de las réplicas disponibles del servicio, como puedes ver aquí:

¿Cómo habilitar la sesión persistente en tus cargas de trabajo de Kubernetes usando Istio?

Todas las solicitudes subsiguientes de Postman ya incluyen la cookie, y todas ellas son manejadas desde el mismo pod:

¿Cómo habilitar la sesión persistente en tus cargas de trabajo de Kubernetes usando Istio?

Mientras que el registro de la otra réplica está vacío, ya que todas las solicitudes han sido enrutadas a ese pod específico.

¿Cómo habilitar la sesión persistente en tus cargas de trabajo de Kubernetes usando Istio?

Resumen

Cubrimos en este artículo la razón detrás de la necesidad de una sesión persistente en la carga de trabajo de Kubernetes y cómo podemos lograr eso usando las capacidades de la Malla de Servicios de Istio. Así que, espero que esto pueda ayudar a implementar esta configuración en tus cargas de trabajo que puedas necesitar hoy o en el futuro.

📚 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.

Kubernetes Autoscaling 1.26: ¿Un cambio de juego para los usuarios de KEDA?

por
Kubernetes Autoscaling 1.26: ¿Un cambio de juego para los usuarios de KEDA?

Introducción

El autoescalado de Kubernetes ha sufrido un cambio dramático. Desde el lanzamiento de Kubernetes 1.26, todos los componentes deben migrar sus objetos HorizontalPodAutoscaler de la versión v1 a la nueva versión v2 que ha estado disponible desde Kubernetes 1.23.

HorizontalPodAutoscaler es un componente crucial en cualquier carga de trabajo desplegada en un clúster de Kubernetes, ya que la escalabilidad de esta solución es uno de los grandes beneficios y características clave de este tipo de entorno.

Un poco de Historia

Kubernetes ha introducido una solución para la capacidad de autoescalado desde la versión Kubernetes 1.3 hace mucho tiempo, en 2016. Y la solución se basaba en un bucle de control que se ejecuta en un intervalo específico que puedes configurar con los parámetros de la propiedad --horizontal-pod-autoscaler-sync-period que pertenecen al kube-controller-manager.

Entonces, una vez durante este período, obtendrá las métricas y evaluará a través de la condición definida en el componente HorizontalPodAutoscaler. Inicialmente, se basaba en los recursos de cómputo utilizados por el pod, memoria principal y CPU.

Kubernetes Autoscaling 1.26: ¿Un cambio de juego para los usuarios de KEDA?

Esto proporcionó una excelente característica, pero con el paso del tiempo y la adopción del entorno de Kubernetes, se ha mostrado un poco limitado para manejar todos los escenarios que deberíamos tener, y aquí es donde otros proyectos impresionantes que hemos discutido aquí, como KEDA entran en escena para proporcionar un conjunto de características mucho más flexible.

Capacidades de Autoescalado de Kubernetes Introducidas v2

Con el lanzamiento de la v2 de los objetos de la API de Autoescalado, hemos incluido una gama de capacidades para mejorar la flexibilidad y las opciones disponibles ahora. Las más relevantes son las siguientes:

  • Escalado en métricas personalizadas: Con el nuevo lanzamiento, puedes configurar un objeto HorizontalPodAutoscaler para escalar usando métricas personalizadas. Cuando hablamos de métricas personalizadas, hablamos de cualquier métrica generada desde Kubernetes. Puedes ver una guía detallada sobre el uso de métricas personalizadas en la documentación oficial
  • Escalado en múltiples métricas: Con el nuevo lanzamiento, también tienes la opción de escalar basado en más de una métrica. Así que ahora el HorizontalPodAutoscaler evaluará cada condición de regla de escalado, propondrá un nuevo valor de escala para cada una de ellas, y tomará el valor máximo como el final.
  • Soporte para la API de Métricas: Con el nuevo lanzamiento, el controlador de los componentes de HoriztalPodAutoscaler recupera métricas de una serie de APIs registradas, como metrics.k8s.io, custom.metrics.k8s.io, external.metrics.k8s.io. Para más información sobre las diferentes métricas disponibles, puedes echar un vistazo a la propuesta de diseño
  • Comportamiento de Escalado Configurable: Con el nuevo lanzamiento, tienes un nuevo campo, behavior, que permite configurar cómo se comportará el componente en términos de actividad de escalado hacia arriba o hacia abajo. Así, puedes definir diferentes políticas para el escalado hacia arriba y otras para el escalado hacia abajo, limitar el número máximo de réplicas que se pueden agregar o eliminar en un período específico, para manejar los problemas con los picos de algunos componentes como las cargas de trabajo de Java, entre otros. También, puedes definir una ventana de estabilización para evitar el estrés cuando la métrica aún está fluctuando.

Kubernetes Autoscaling v2 vs KEDA

Hemos visto todos los nuevos beneficios que proporciona Autoscaling v2, así que estoy seguro de que la mayoría de ustedes se están haciendo la misma pregunta: ¿Está Kubernetes Autoscaling v2 matando a KEDA?

Desde las últimas versiones de KEDA, KEDA ya incluye los nuevos objetos bajo el grupo autoscaling/v2 como parte de su desarrollo, ya que KEDA se basa en los objetos nativos de Kubernetes, y simplifica parte del proceso que necesitas hacer cuando quieres usar métricas personalizadas o externas, ya que tienen escaladores disponibles para prácticamente todo lo que podrías necesitar ahora o incluso en el futuro.

Pero, incluso con eso, todavía hay características que KEDA proporciona que no están cubiertas aquí, como las capacidades de escalado “desde cero” y “a cero” que son muy relevantes para tipos específicos de cargas de trabajo y para obtener un uso muy optimizado de los recursos. Aún así, es seguro decir que con las nuevas características incluidas en el lanzamiento de autoscaling/v2, la brecha ahora es más pequeña. Dependiendo de tus necesidades, puedes optar por las capacidades listas para usar sin incluir un nuevo componente en tu arquitectura.

📚 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.

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.

📚 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.

Optimiza Tu Service Mesh con Istio y Extremos Externos

por
Optimiza Tu Service Mesh con Istio y Extremos 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 al mesh.

Istio Service Entry responde a la pregunta que probablemente te has hecho varias veces al usar una Service Mesh. ¿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.

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

📚 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.