Tu resumen semanal de lo que encontré más relevante en el ecosistema nativo de la nube.
Resumen
En esta edición, decidí traer algunos artículos introductorios para proporcionar la base de conceptos importantes en la industria ahora, pero también que seguirán siendo relevantes en el futuro próximo.
Comenzaremos hablando sobre la gestión y operación de grandes cargas de trabajo en Kubernetes con el uso del conocido gestor de paquetes para cargas de trabajo nativas de la nube, Helm, donde tendrás una gran visión de qué es y cómo empezar a usarlo en tu clúster.
Continuaremos con uno de los cambios de juego en la gestión de operaciones e infraestructura, como el movimiento GitOps, y veremos cómo esto impactará en todo tipo de roles, incluso en los desarrolladores en su camino.
Y terminaremos con un artículo que cubre los protocolos más utilizados hoy en día para exponer servicios sincrónicos (REST, GraphQL y gRPC) para que puedas conocer las características de cada uno de ellos y dónde usar uno u otro.
Historias
Cita
La forma de empezar es dejar de hablar y comenzar a hacer.
Walt Disney
Envíame tus comentarios
Contáctame usando este enlace para darme tu opinión y comentarios sobre esta nueva edición y también para recomendar cualquier otra historia que creas que debería llegar a este lugar.
Serverless siempre ha sido considerado el siguiente paso en el viaje a la nube. Sabes a lo que me refiero: comienzas desde tu VM en las instalaciones, luego te mueves a tener contenedores en una plataforma PaaS, y luego intentas encontrar tu próxima parada en este viaje que es serverless.
Evolución tecnológica definida basada en la perspectiva de abstracción de infraestructura
Serverless es la idea de olvidarse de la infraestructura y centrarse solo en tus aplicaciones. No hay necesidad de preocuparse por dónde se ejecutará o la gestión de la infraestructura subyacente. Serverless comenzó como un sinónimo del paradigma de Función como Servicio (FaaS). Fue popularizado primero por las funciones de Amazon Lambda y luego por todos los principales proveedores de nube.
Comenzó como una alternativa al enfoque de contenedores que probablemente requiere muchas habilidades técnicas para gestionar y ejecutar a escala de producción, pero este ya no es el caso.
Hemos visto cómo el enfoque serverless ha llegado a cualquier plataforma a pesar de este punto de partida. Siguiendo los mismos principios, tenemos diferentes plataformas cuyo enfoque es abstraer todos los aspectos técnicos para la parte operativa y proporcionar una plataforma donde puedas poner tu lógica en ejecución. Prácticamente cada plataforma SaaS cubre este enfoque, pero me gustaría destacar algunos ejemplos para aclarar:
netlify es una plataforma que te permite desplegar tu aplicación web sin necesidad de gestionar nada más que el código necesario para ejecutarla.
TIBCO Cloud Integration es una solución iPaaS que proporciona todos los recursos técnicos que podrías necesitar para que puedas centrarte en desplegar tus servicios de integración.
Pero yendo más allá, prácticamente cada servicio proporcionado por las principales plataformas en la nube como Azure, AWS o GCP sigue el mismo principio. La mayoría de ellos (mensajería, aprendizaje automático, almacenamiento, etc.) abstraen toda la infraestructura subyacente para que puedas centrarte en el servicio real.
Volviendo al ecosistema de Kubernetes, tenemos dos capas diferentes de ese enfoque. La principal es el servicio de Kubernetes gestionado que todas las grandes plataformas proporcionan donde toda la gestión de Kubernetes (nodos maestros, componentes internos de Kubernetes) son transparentes para ti y te centras todo en los trabajadores. Y el segundo nivel es lo que puedes obtener en el mundo de AWS con la arquitectura tipo EKS + Fargate donde ni siquiera existen los nodos de trabajo, tienes tus pods que se desplegarán en una máquina que pertenece a tu clúster pero no necesitas preocuparte por ello, ni gestionar nada relacionado con eso.
Así que, como hemos visto, el enfoque serverless está llegando a todas las áreas, pero este no es el alcance de este artículo. La idea aquí es tratar de centrarse en serverless como sinónimo de Función como Servicio (FaaS) y cómo podemos llevar la experiencia FaaS a nuestro ecosistema productivo de K8S. Pero comencemos con las preguntas iniciales:
¿Por qué querríamos hacer eso?
Esta es la cosa más emocionante de preguntar: ¿cuáles son los beneficios que proporciona este enfoque? Función como Servicio sigue el enfoque de escala cero. Eso significa que la función no se carga si no se está ejecutando, y esto es importante, especialmente cuando eres responsable de tu infraestructura o al menos estás pagando por ella.
Imagina un microservicio normal escrito en cualquier tecnología, la cantidad de recursos que puede usar depende de su carga, pero incluso sin ninguna carga, necesitas algunos recursos para mantenerlo en funcionamiento; principalmente, estamos hablando de memoria que necesitas mantener en uso. La cantidad real dependerá de la tecnología y del desarrollo en sí, pero puede moverse de algunos MB a algunos cientos. Si consideramos todos los microservicios que una empresa significativa puede tener, obtendrás una diferencia de varios GB que estás pagando y que no están proporcionando ningún valor.
Pero más allá de la gestión de infraestructura, este enfoque también juega muy bien con otro de los últimos enfoques arquitectónicos, la Aplicación Basada en Eventos (EDA), porque podemos tener servicios que están dormidos solo esperando el evento correcto para despertarlos y comenzar a procesar.
Entonces, en resumen, el enfoque serverless te ayuda a obtener tu sueño de infraestructura optimizada y habilitar diferentes patrones también de manera eficiente. Pero, ¿qué pasa si ya poseo la infraestructura? Será lo mismo porque ejecutarás más servicios en la misma infraestructura, por lo que aún obtendrás el uso optimizado de tu infraestructura actual.
¿Qué necesitamos para habilitar eso?
Lo primero que necesitamos saber es que no todas las tecnologías o marcos son adecuados para ejecutarse en este enfoque. Eso se debe a que necesitas cumplir con algunos requisitos para poder hacerlo como un enfoque exitoso, como se muestra a continuación:
Inicio Rápido: Si tu lógica no está cargada antes de que una solicitud llegue al servicio, necesitarás asegurarte de que la lógica pueda cargarse rápidamente para evitar impactar al consumidor del servicio. Eso significa que necesitarás una tecnología que pueda cargarse en una pequeña cantidad de tiempo, generalmente hablando en el rango de microsegundos.
Sin Estado: Como tu lógica no se va a cargar en un modo continuo, no es adecuada para servicios con estado.
Descarte: Similar al punto anterior, debe estar listo para un apagado elegante de manera robusta.
¿Cómo hacemos eso?
Varios marcos nos permiten obtener todos esos beneficios que podemos incorporar en nuestro ecosistema de Kubernetes, como los siguientes:
KNative: Este es el marco que la Fundación CNCF apoya y se está incluyendo por defecto en muchas distribuciones de Kubernetes como Red Hat Openshift Platform.
Inicio – Knative
Documentación de Knative
OpenFaaS: Este es un marco muy utilizado creado por Alex Ellis que apoya la misma idea.
Inicio
Funciones Serverless Hechas Simples con Kubernetes.
Es cierto que hay otras alternativas como Apache OpenWhisk, Kubeless o Fission, pero son menos utilizadas en el mundo actual y principalmente la mayoría de las alternativas han sido elegidas entre OpenFaaS y KNative, pero si quieres leer más sobre otras alternativas te dejaré un artículo sobre la CNCF cubriéndolas para que puedas echar un vistazo por ti mismo:
Marcos de Código Abierto Serverless: OpenFaaS, Knative, & más | Fundación de Computación Nativa en la Nube
Publicado originalmente en el blog de Epsagon por Ran Ribenzaft, cofundador y CTO en Epsagon Este artículo discutirá algunos de los marcos mencionados anteriormente y profundizará en OpenFaaS y Knative para…
Tu resumen semanal de lo que encontré más relevante en el ecosistema nativo de la nube.
Resumen
En esta edición, decidí traer algunos artículos que cubren diferentes perspectivas de varios temas relevantes que solemos tratar aquí, como: Automatización, Seguridad o Mensajería.
Comenzaremos con una mirada profunda a los aspectos internos de uno de los sistemas de mensajería más populares como Kafka, con varios videos veremos los principios de este gran sistema para poder usarlo al máximo.
Continuaremos hablando nuevamente sobre seguridad, esta vez sobre las nuevas características incluidas en Docker Desktop, enfocándonos en crear una lista de materiales de las imágenes.
Y terminaremos con un artículo sobre una de las herramientas de código abierto más famosas para la automatización como Terraform y cuáles son los próximos pasos para escalar tu plataforma usando Terraform. ¡Espero que te guste esta selección tanto como a mí!
Historias
Cita
Si estableces tus metas ridículamente altas y es un fracaso, fracasarás por encima del éxito de los demás. –
James Cameron
Envíame tus comentarios
Contáctame usando este enlace para darme tu opinión y comentarios sobre esta nueva edición y también para recomendar cualquier otra historia que creas que debería llegar a este lugar.
ServiceMonitor y PodMonitor son términos que comenzarás a ver más a menudo cuando se hable de usar Prometheus. Hemos cubierto mucho sobre Prometheus en artículos anteriores. Es una de las principales referencias cuando hablamos de monitoreo en un entorno nativo de la nube y está especialmente enfocado en el ecosistema de Kubernetes.
Prometheus tiene un nuevo modelo de implementación bajo el Marco del Operador de Kubernetes en tiempos recientes. Eso ha generado varios cambios en términos de recursos y cómo configuramos varios aspectos del monitoreo de nuestras cargas de trabajo. Algunos de estos conceptos ahora se gestionan como Definición de Recurso Personalizado (CRD) que se incluyen para simplificar la configuración del sistema y estar más alineados con las capacidades de la propia plataforma de Kubernetes. Esto es genial pero, al mismo tiempo, cambia cómo necesitamos usar esta excelente herramienta de monitoreo para cargas de trabajo nativas de la nube.
Hoy, cubriremos dos de estos nuevos CRDs, uno de los más relevantes: ServiceMonitor y PodMonitor. Estos son los nuevos objetos que especifican los recursos que estarán bajo el alcance de monitoreo para la plataforma, y cada uno de ellos cubre un tipo diferente de objeto, como puedes imaginar: Servicios y Pods.
Cada uno de ellos tiene su archivo de definición con sus campos y metadatos particulares, y para destacarlos, presentaré un ejemplo para cada uno de ellos a continuación:
Como puedes ver, las definiciones de los componentes son muy similares y muy intuitivas, enfocándose en el selector para detectar qué pods o servicios debemos monitorear y algunos datos sobre el objetivo específico del monitoreo, para que Prometheus sepa cómo extraerlos.
Si deseas echar un vistazo más en detalle a cualquier opción que puedas configurar en este CRD, te recomendaría que eches un vistazo a esta URL que incluye una documentación detallada campo por campo de los CRDs más comunes:
PodMonitor.monitoring.coreos.com/v1
Documentación automática para tus Definiciones de Recursos Personalizados.
Estos componentes pertenecerán a la definición de tus cargas de trabajo, lo que significa que la creación y el mantenimiento de estos objetos serán responsabilidad de los desarrolladores de la aplicación.
Eso es genial por varias razones:
Incluirá el aspecto de Monitoreo del propio componente, por lo que nunca olvidarás agregar la configuración de un componente específico. Eso significa que se puede incluir en los archivos YAML duplicados o en el Helm Chart o en recursos de Kustomize como otro recurso necesario.
Descentralizará la configuración de monitoreo haciéndola más ágil, y progresará a medida que lo hagan los componentes de software.
Reducirá el impacto en otros componentes monitoreados ya que no hay necesidad de actuar en ningún archivo o recurso estándar, por lo que cualquier carga de trabajo diferente continuará funcionando como se espera.
Ambos objetos son muy similares en sus propósitos ya que ambos extraen todos los endpoints que coinciden con el selector que agregamos. Entonces, ¿en qué casos debería usar uno u otro?
La respuesta será sencilla. Por defecto, optarás por un ServiceMonitor porque proporcionará las métricas del propio servicio y de cada uno de los endpoints que tiene el servicio, por lo que cada uno de los pods que están implementando el servicio será descubierto y extraído como parte de esta acción.
Entonces, ¿en qué casos debería usar PodMonitor? Donde la carga de trabajo que estás tratando de monitorear no actúa detrás de un servicio, por lo que al no haber un servicio definido, no puedes usar ServiceMonitor. ¿Quieres algunos ejemplos de eso? ¡Traigamos algunos!
Servicios que interactúan usando otros protocolos que no son basados en HTTP, como Kafka, SQS/SNS, JMS, o similares.
Componentes como CronJobs, DaemonSets, o que no exponen ningún modelo de conexión entrante.
Así que espero que este artículo te ayude a entender la principal diferencia entre esos objetos y profundizar un poco más en cómo funcionan los nuevos recursos del Marco del Operador Prometheus. Continuaremos cubriendo otros aspectos en próximos artículos.
Tu Resumen Semanal de lo que Encontré Más Relevante en el Ecosistema Nativo de la Nube.
Resumen
En esta edición, decidí traer algunos artículos que cubren diferentes aspectos de las «políticas» nativas de la nube.
Comenzaremos con un análisis profundo de la decisión de Grafana Labs de lanzar Mimir y cómo eso afecta a otros proyectos de código abierto como Cortex, que está siendo utilizado en varias grandes empresas y otras soluciones.
Continuaremos hablando sobre las razones detrás de la sorprendente decisión de que el proyecto Istio finalmente sea reconocido como un proyecto de la CNCF.
Y terminaremos con un artículo que intenta eliminar algunos de los pensamientos iniciales de que lo nativo de la nube y Kubernetes solo es útil para entornos de nube pública y cómo también pueden ayudarte a modernizar mientras mantienes y gestionas tu propio hardware. ¡Acompáñame en este viaje!
Historias
Cita
No vayas donde el camino pueda llevar, ve en cambio donde no hay camino y deja un rastro.
Ralph Waldo Emerson
Envíame tus comentarios
Contáctame usando este enlace para darme tu opinión y comentarios sobre esta nueva edición y también para recomendar cualquier otra historia que creas que debería llegar a este lugar.
Todos sabemos cómo las cargas de trabajo nativas de la nube y Kubernetes han cambiado la forma en que hacemos las cosas. Hay muchos beneficios que vienen con el efecto de la contenedorización y las plataformas de orquestación como Kubernetes, y hemos discutido mucho sobre ello: escalabilidad, autocuración, autodescubrimiento, resiliencia, y así sucesivamente.
Pero se han planteado algunos desafíos, la mayoría de ellos en el aspecto operativo en el que tenemos muchos proyectos enfocados en abordar, pero generalmente olvidamos lo que el embajador ha definido como el “ciclo de desarrollo interno”.
El “ciclo de desarrollo interno” es el flujo de trabajo productivo que cada desarrollador sigue al trabajar en una nueva aplicación, servicio o componente. Este flujo iterativo es donde codificamos, probamos lo que hemos codificado y arreglamos lo que no funciona o mejoramos lo que ya tenemos.
Este flujo ha existido desde el principio de los tiempos; no importa si estabas codificando en C usando la biblioteca STD o COBOL a principios de 1980 o haciendo nodejs con los últimos marcos y bibliotecas a tu disposición.
Hemos visto movimientos hacia hacer este ciclo interno más efectivo, especialmente en el desarrollo front-end. Tenemos muchas opciones para ver el último cambio que hemos hecho en el código, solo guardando el archivo. Pero por primera vez, cuando el movimiento hacia una plataforma basada en contenedores, este flujo hace que los desarrolladores sean menos productivos.
La razón principal es que el número de tareas que un desarrollador necesita hacer ha aumentado. Imagina este conjunto de pasos que necesitamos realizar:
Construir la aplicación
Construir la imagen del contenedor
Desplegar la imagen del contenedor en Kubernetes
Estas acciones no son tan rápidas como probar tus cambios localmente, haciendo que los desarrolladores sean menos productivos que antes, que es lo que el proyecto “telepresencia” está tratando de resolver.
La telepresencia es un proyecto incubador de la CNCF que ha centrado mucha atención recientemente porque se ha incluido OOTB en las últimas versiones del componente Docker Desktop. Basado en sus propias palabras, esta es la definición del proyecto de telepresencia:
La telepresencia es una herramienta de código abierto que permite a los desarrolladores codificar y probar microservicios localmente contra un clúster de Kubernetes remoto. La telepresencia facilita flujos de trabajo de desarrollo más eficientes aliviando la necesidad de preocuparse por otras dependencias de servicio.
Ok, entonces, ¿cómo podemos empezar? Vamos a sumergirnos juntos. Lo primero que necesitamos hacer es instalar la telepresencia en nuestro clúster de Kubernetes:
Instalar | Telepresencia
Instalar Instalar Telepresencia ejecutando los comandos a continuación para tu sistema operativo. Si no eres el administrador de tu clúster, necesitarás administraci…
Nota: También hay una forma de instalar telepresencia usando Helm en tu clúster siguiendo estos pasos:
Ahora crearé un contenedor simple que alojará una aplicación Golang que expone un servicio REST simple y lo haré más accesible; seguiré el tutorial que está disponible a continuación; tú también puedes hacerlo.
Tutorial: Desarrollando una API RESTful con Go y Gin – El Lenguaje de Programación Go
Este tutorial introduce los conceptos básicos de escribir un servicio web RESTful API con Go
y el marco web Gin (Gin).
Una vez que tengamos nuestra aplicación golang lista, vamos a generar el contenedor a partir de ella, usando el siguiente Dockerfile:
FROM golang:latest
RUN apt-get update
RUN apt-get upgrade -y
ENV GOBIN /go/bin
WORKDIR /app
COPY *.go ./
RUN go env -w GO111MODULE=off
RUN go get .
RUN go build -o /go-rest
EXPOSE 8080
CMD [ "/go-rest" ]
Luego, una vez que tengamos la aplicación, la subiremos al servidor de Kubernetes y la ejecutaremos como un despliegue, como puedes ver en la imagen a continuación:
Una vez que tengamos eso, es el momento de comenzar a ejecutar la telepresencia, y comenzaremos a conectarnos al clúster usando el siguiente comando telepresence connect, y mostrará una salida como esta:
Luego vamos a listar los puntos finales disponibles para interceptar con el comando telepresence list y veremos nuestro servicio-rest que hemos expuesto antes:
Ahora, ejecutaremos el interceptor específico, pero antes de eso, vamos a hacer el truco para que podamos conectarlo a nuestro Visual Studio Code. Generaremos un archivo launch.json en Visual Studio Code con el siguiente contenido:
{
// Usa IntelliSense para aprender sobre posibles atributos.
// Pasa el ratón para ver descripciones de atributos existentes.
// Para más información, visita: https://go.microsoft.com/fwlink/?linkid=830387
"version": "0.2.0",
"configurations": [
{
"name": "Lanzar con archivo env",
"type": "go",
"request": "launch",
"mode": "debug",
"program": "1",
"envFile": "NULL/go-debug.env"
}
]
}
La parte interesante aquí es el argumento envFile que apunta a un archivo inexistente go-debug.env en la misma carpeta, por lo que necesitamos asegurarnos de que generamos ese archivo cuando hacemos la intercepción. Así que usaremos el siguiente comando:
Y ahora, podemos comenzar nuestra sesión de depuración en Visual Studio Code y tal vez agregar un punto de interrupción y algunas líneas, como puedes ver en la imagen a continuación:
Entonces, ahora, si golpeamos el pod en Kubernetes, veremos cómo se alcanza el punto de interrupción como si estuviéramos en una sesión de depuración local.
Eso significa que podemos inspeccionar variables y todo, cambiar el código o hacer lo que necesitemos para acelerar nuestro desarrollo!
Tu resumen semanal de lo que encontré más relevante en el ecosistema nativo de la nube.
Resumen
En esta edición, tenemos una mezcla de cosas, desde tutoriales técnicos hasta análisis y contexto histórico sobre decisiones importantes de código abierto.
Comenzaremos con una mirada para extender las opciones tradicionales de escalabilidad en Kubernetes más allá de las capacidades predeterminadas del Horizontal Pod Autoscaler (HPA) utilizando el proyecto KEDA para escalar basado en el retraso del consumidor de Kafka.
Continuaremos hablando sobre las razones detrás de la decisión de eliminar Dockershim del proyecto Kubernetes, que finalmente es una realidad con el lanzamiento de la versión 1.24.
Y terminaremos con un artículo que proporciona algunas soluciones a la preocupación habitual de la explosión de la observabilidad en las grandes arquitecturas y cómo podemos abordarlo.
¡Acompáñame en este viaje!
Historias
Cita
El futuro pertenece a aquellos que creen en la belleza de sus sueños.
Eleanor Roosevelt
Envíame tus comentarios
Contáctame usando este enlace para darme tu opinión y comentarios sobre esta nueva edición y también para recomendar cualquier otra historia que creas que debería llegar a este lugar.
Todos sabemos que Openshift es una distribución de Kubernetes excepcional y una de las más utilizadas, principalmente cuando se habla de implementaciones en la nube privada. Basado en la sólida reputación de Red Hat Enterprise Linux, Openshift pudo crear un producto sólido que se está convirtiendo casi en un estándar para la mayoría de las empresas.
Proporciona muchas extensiones del estilo de Kubernetes Vanilla, incluyendo algunos de los estándares de la industria de código abierto como Prometheus, Thanos y Grafana para el monitoreo de métricas o la pila ELK para la agregación de registros, pero también incluye sus extensiones como las Rutas de Openshift.
Las Rutas de Openshift fueron la solución inicial antes de que el concepto de Ingress fuera una realidad dentro del estándar. Ahora, también se implementa siguiendo ese patrón para mantener la compatibilidad. Está respaldado por HAProxy, uno de los proxies inversos más conocidos disponibles en la comunidad de código abierto.
Una de las partes complicadas por defecto es saber cómo depurar cuando una de tus rutas no funciona como se espera. La forma en que creas rutas es tan fácil que cualquiera puede hacerlo en unos pocos clics, y si todo funciona como se espera, eso es genial.
Pero si no es así, los problemas comienzan porque, por defecto, no obtienes ningún registro sobre lo que está sucediendo. Pero eso es lo que vamos a resolver aquí.
Primero, hablaremos un poco más sobre cómo se configura esto. Actualmente (versión 4.8 de Openshift), esto se implementa, como dije, usando HAProxy por defecto, así que si estás usando otra tecnología como ingresses como Istio o Nginx, este artículo no es para ti (pero no olvides dejar un comentario si un artículo similar sería de tu interés para que también pueda llevarlo al backlog 🙂 )
Desde la perspectiva de la implementación, esto se implementa usando el Marco de Operadores, por lo que el ingreso se despliega como un Operador, y está disponible en el espacio de nombres openshift-ingress-operator.
pods del operador de ingreso en el ecosistema de Openshift
Entonces, como esto es un operador, se han instalado varias Definiciones de Recursos Personalizados (CRD) para trabajar con esto, una de las más interesantes de este artículo. Este CRD es Controladores de Ingreso.
Instancias de Ingreso en el Ecosistema de Openshift
Por defecto, solo verás una instancia llamada default. Esta es la que incluye la configuración del ingreso que se está desplegando, por lo que necesitamos agregar aquí una configuración adicional para tener también los registros.
Archivo YAML del controlador de ingreso
El fragmento que necesitamos es el que se muestra a continuación bajo el parámetro spec que comienza la definición de la especificación del IngressController en sí:
Esto hará que se despliegue otro contenedor en los pods del enrutador en el espacio de nombres openshift-ingress siguiendo el patrón sidecar llamado logs.
Pods del enrutador en la instalación de Openshift
Este contenedor imprimirá los registros de las solicitudes que llegan al componente de ingreso, por lo que la próxima vez que tu consumidor no pueda llamar a tu servicio, podrás ver las solicitudes entrantes con todos sus metadatos y saber al menos qué está haciendo mal:
Registros de acceso de la Ruta de Openshift
Como puedes ver, ¡simple y fácil! Si ya no lo necesitas, puedes eliminar la configuración nuevamente y guardarla, y la nueva versión se implementará y volverá a la normalidad.
Tu resumen semanal de lo que encontré más relevante en el ecosistema nativo de la nube.
Resumen
La gestión de costos en la nube es el tema de esta edición y espero haberte traído una perspectiva diferente para primero pensar en cómo mejorar la gestión de costos en la nube, pero también en cómo las herramientas y técnicas que tenemos a nuestra disposición pueden optimizar los costos en la nube.
Comenzaremos con una mirada a cómo podemos aplicar técnicas de FinOps en nuestros clústeres de Kubernetes para asegurarnos de obtener todos los datos que necesitamos de nuestras cargas de trabajo de Kubernetes.
Continuaremos hablando sobre los riesgos de costos en la nube más desde una perspectiva de gestión y cómo puedes protegerte contra ellos.
Y terminaremos con un viaje educativo para entender cómo funcionan los costos en la nube y por qué son tan complicados de entender.
¡Acompáñame en este viaje!
Historias
Cita
Primero, ten un ideal práctico definido y claro; una meta, un objetivo. Segundo, ten los medios necesarios para lograr tus fines; sabiduría, dinero, materiales y métodos. Tercero, ajusta todos tus medios a ese fin.
Aristóteles
Envíame tus comentarios
Contáctame usando este enlace para darme tu opinión y comentarios sobre esta nueva edición y también para recomendar cualquier otra historia que creas que debería llegar a este lugar.
Modelos de Despliegue para una Arquitectura Escalable de Agregación de Logs usando Loki
Desplegar Solución Escalable de Loki
Desplegar un Loki escalable no es una tarea sencilla. Ya hemos hablado sobre Loki en publicaciones anteriores en el sitio, y se está volviendo cada vez más popular, y su uso se vuelve mucho más regular cada día. Es por eso que creo que tiene sentido incluir otra publicación sobre la Arquitectura de Loki.
Loki tiene varias ventajas que lo promueven como una opción predeterminada para desplegar una Pila de Agregación de Logs. Una de ellas es su escalabilidad porque puedes ver a través de diferentes modelos de despliegue cuántos componentes te gustaría desplegar y sus responsabilidades. Así que el objetivo del tema es mostrarte cómo desplegar una solución escalable de Loki y esto se basa en dos conceptos: componentes disponibles y cómo los agrupas.
Así que comenzaremos con los diferentes componentes:
ingester: responsable de escribir datos de logs en backends de almacenamiento a largo plazo (DynamoDB, S3, Cassandra, etc.) en la ruta de escritura y devolver datos de logs para consultas en memoria en la ruta de lectura.
distributor: responsable de manejar flujos entrantes por parte de los clientes. Es el primer paso en la ruta de escritura para los datos de logs.
query-frontend: servicio opcional que proporciona los puntos finales de la API del querier y puede usarse para acelerar la ruta de lectura.
querier: servicio que maneja consultas usando el lenguaje de consulta LogQL, obteniendo logs de los ingesters y del almacenamiento a largo plazo.
ruler: responsable de evaluar continuamente un conjunto de consultas configurables y realizar una acción basada en el resultado.
Luego puedes unirlos en diferentes grupos, y dependiendo del tamaño de estos grupos, tienes una topología de despliegue diferente, como se muestra a continuación:
Modo de Despliegue Monolítico de Loki
Monolito: Como puedes imaginar, todos los componentes se ejecutan juntos en una sola instancia. Esta es la opción más simple y se recomienda como un punto de partida de 100 GB / día. Incluso puedes escalar este despliegue, pero escalará todos los componentes simultáneamente, y debería tener un estado de objeto compartido.
Modo de Despliegue Escalable Simple de Loki
Modelo de Despliegue Escalable Simple: Este es el segundo nivel, y puede escalar hasta varios TB de logs por día. Consiste en dividir los componentes en dos perfiles diferentes: lectura y escritura.
Modo de Despliegue de Microservicios de Loki
Microservicios: Eso significa que cada componente será gestionado de manera independiente, dándote todo el poder en tus manos para escalar cada uno de estos componentes por separado.
Definir el modelo de despliegue de cada instancia es muy fácil, y se basa en un solo parámetro llamado target. Así que dependiendo del valor del target seguirá uno de los modelos de despliegue anteriores:
all (por defecto): Se desplegará en modo monolítico.
write: Será la ruta de escritura en el modelo de despliegue escalable simple
read: Será el grupo de lectura en el modelo de despliegue escalable simple
ingester, distributor, query-frontend, query-scheduler, querier, index-gateway, ruler, compactor: Valores individuales para desplegar un solo componente para el modelo de despliegue de microservicios.
El argumento target ayudará para un tipo de despliegue on-premises. Aún así, si estás usando Helm para la instalación, Loki ya proporciona diferentes charts de helm para los otros modelos de despliegue:
Pero todos esos charts de helm se basan en el mismo principio comentado anteriormente sobre definir el rol de cada instancia usando el argumento target, como puedes ver en la imagen a continuación:
