Descubre las propiedades que te permitirán un uso optimizado de tu almacenamiento en disco y ahorros al almacenar tus datos de monitoreo
Prometheus se ha convertido en un componente estándar en nuestras arquitecturas en la nube y el almacenamiento de Prometheus se está convirtiendo en un aspecto crítico. Así que voy a suponer que si estás leyendo esto ya sabes qué es Prometheus. Si este no es el caso, por favor tómate tu tiempo para echar un vistazo a otros artículos que he creado:
Prometheus Monitoring for Microservices using TIBCO
We’re living a world with constant changes and this is even more true in the Enterprise Application world. I’ll not spend much time talking about things you already know, but just say that the microservices architecture approach and the PaaS solutions have been a game-changer for all enterprise integration technologies. This time I’d like to […]
Kubernetes Service Discovery for Prometheus
In previous posts, we described how to set up Prometheus to work with your TIBCO BusinessWorks Container Edition apps, and you can read more about it here. In that post, we described that there were several ways to update Prometheus about the services that ready to monitor. And we choose the most simple at that […]
Sabemos que usualmente cuando monitoreamos usando Prometheus tenemos tantos exportadores disponibles a nuestra disposición y también que cada uno de ellos expone muchas métricas muy relevantes que necesitamos para rastrear todo lo que necesitamos y que lleva a un uso muy intensivo del almacenamiento disponible si no lo gestionamos adecuadamente.
Hay dos factores que afectan esto. El primero es optimizar el número de métricas que estamos almacenando y ya proporcionamos consejos para hacerlo en otros artículos como los que se muestran a continuación:
How it optimize the disk usage in the Prometheus database?
Learn some tricks to analyze and optimize the usage that you are doing of the TSDB and save money on your cloud deployment. Photo by Markus Spiske on Unsplash In previous posts, we discussed how the storage layer worked for Prometheus and how effective it was. But in the current times, we are of cloud computing […]
El otro es cuánto tiempo almacenamos las métricas llamado el “período de retención en Prometheus.” Y esta propiedad ha sufrido muchos cambios durante las diferentes versiones. Si te gustaría ver toda la historia, por favor echa un vistazo a este artículo de Robust Perception:
How can you control how much history Prometheus keeps?
Las principales propiedades que puedes configurar son las siguientes:
storage.tsdb.retention.time: Número de días para almacenar las métricas por defecto a 15d. Esta propiedad reemplaza la obsoleta storage.tsdb.retention.
storage.tsdb.retention.size: Puedes especificar el límite de tamaño a utilizar. Este no es un límite estricto sino un mínimo, así que por favor define algún margen aquí. Unidades soportadas: B, KB, MB, GB, TB, PB, EB. Ej: “512MB”. Esta propiedad es experimental hasta ahora como puedes ver en la documentación oficial:
¿Qué tal configurar esta configuración en el operador para Kubernetes? En ese caso, también tienes opciones similares disponibles en el archivo de configuración values.yaml para el chart como puedes ver en la imagen a continuación:
values.yml para el Helm Chart del Operador de Prometheus
Esto debería ayudarte a obtener un despliegue optimizado de Prometheus que asegure todas las características que tiene Prometheus pero al mismo tiempo un uso óptimo de los recursos a tu disposición.
Además de eso, también deberías revisar las opciones de Servicio Gestionado que algunos proveedores tienen respecto a Prometheus, como los Servicios Gestionados de Amazon para Prometheus, como puedes ver en el enlace a continuación:
Amazon Prometheus Service to Provide More Availability to Your Monitoring Solution
Learn what Amazon Managed Service for Prometheus provides and how you can benefit from it. Photo by Casey Horner on Unsplash Monitoring is one of the hot topics when we talk about cloud-native architectures. Prometheus is a graduated Cloud Native Computing Foundation (CNCF) open-source project and one of the industry-standard solutions when it comes to monitoring your […]
Aprende sobre el nuevo sistema de agregación de logs escalable horizontalmente, altamente disponible y multi-inquilino inspirado en Prometheus que puede ser la mejor opción para tu arquitectura de registro
Loki vs ELK es algo que estás leyendo y escuchando cada vez más a menudo ya que desde hace algún tiempo hay un aumento en la disputa por convertirse en el estándar de facto para las arquitecturas de agregación de logs.
Cuando hablamos de Arquitectura Nativa de la Nube, la agregación de logs es algo clave que necesitas considerar. Las viejas prácticas que seguimos en el enfoque de máquinas virtuales on-premises para el registro ya no son válidas.
Ya cubrimos este tema en mi publicación anterior que te recomiendo echar un vistazo en caso de que no la hayas leído aún, pero este no es el tema de hoy.
Three reasons why you need a Log Aggregation Architecture today
Log Aggregation are not more a commodity but a critical component in container-based platforms Photo by Olav Ahrens Røtne on Unsplash Log Management doesn’t seem like a very fantastic topic. It is not the topic that you see and says: “Oh! Amazing! This is what I was dreaming about my whole life”. No, I’m aware that […]
Elasticsearch como el núcleo y las diferentes pilas derivadas como ELK/EFK han ganado popularidad en los últimos años, siendo prácticamente la opción predeterminada de código abierto cuando hablamos de agregación de logs y una de las opciones. Los principales proveedores de nube pública también han adoptado esta solución como parte de su propia oferta, como lo proporciona el Servicio de Elasticsearch de Amazon.
Pero Elasticsearch no es perfecto. Si ya lo has usado, probablemente lo sepas. Aún así, debido a que sus características son tan impresionantes, especialmente en las capacidades de búsqueda e indexación, ha sido el tipo de líder hoy en día. Pero otros temas como el uso del almacenamiento, la cantidad de poder que necesitas para manejarlo y la arquitectura con diferentes tipos de nodos (maestro, datos, ingestor) aumentan su complejidad para casos cuando necesitamos algo más pequeño.
Y para llenar este vacío es donde llega nuestro personaje principal para la publicación de hoy: Loki o Grafana Loki.
Loki es un sistema de gestión de logs creado como parte del proyecto Grafana, y ha sido creado con un enfoque diferente en mente que Elasticsearch.
Loki es un sistema de agregación de logs escalable horizontalmente, altamente disponible y multi-inquilino inspirado en Prometheus. Está diseñado para ser muy rentable y fácil de operar. No indexa el contenido de los logs, sino un conjunto de etiquetas para cada flujo de logs.
Así que, como podemos leer en la definición de su propia página arriba, cubre varios temas interesantes en comparación con Elasticsearch:
En primer lugar, aborda algunos de los puntos de dolor habituales para los clientes de ELK: Es muy rentable y fácil de operar.
Claramente dice que el enfoque no es el mismo que ELK, no vas a tener un índice completo de la carga útil para los eventos, sino que se basa en diferentes etiquetas que puedes definir para cada flujo de logs.
Prometheus inspira eso, lo cual es crítico porque permitió la idea de usar trazas de logs como métricas para potenciar nuestras soluciones de monitoreo.
Comencemos con las preguntas iniciales cuando mostramos una nueva tecnología interesante y nos gustaría comenzar a probarla.
¿Cómo puedo instalar Loki?
Loki se distribuye en diferentes versiones para ser instalado en tu entorno de la manera que lo necesites.
SaaS: proporcionado como parte de la solución de alojamiento de Grafana Cloud.
On-Premises: Proporcionado como un binario normal para descargar y ejecutar en modo on-premises.
Nube: Proporcionado como una imagen de Docker o incluso un Helm Chart para ser desplegado en tu entorno basado en Kubernetes.
Los equipos de GrafanaLabs también proporcionan Soporte Empresarial para Loki si deseas usarlo en modo de producción en tu empresa. Aún así, al mismo tiempo, todo el código está licenciado usando la Licencia Apache 2.0, por lo que puedes echar un vistazo a todo el código y contribuir a él.
En cuanto a la arquitectura, es muy similar a la pila ELK/EFK y sigue el mismo enfoque de “coleccionistas” e “indexadores” como tiene ELK:
Loki en sí mismo es el nodo central de la arquitectura responsable de almacenar las trazas de logs y sus etiquetas y proporciona una API para buscar entre ellas basándose en su propio lenguaje LogQL (un enfoque similar al PromQL de Prometheus).
promtail es el componente agente que se ejecuta en el borde obteniendo todas esas trazas de logs que necesitamos que pueden estar ejecutándose en una máquina on-prem o en un modo DaemonSet en nuestro propio clúster de Kubernetes. Desempeña el mismo papel que Logstash/Fluent-bit/Fluentd en la pila ELK/EFK. Promtail proporciona el modo de plugin habitual para filtrar y transformar nuestras trazas de logs como lo hacen las otras soluciones. Al mismo tiempo, proporciona una característica interesante para convertir esas trazas de logs en métricas de Prometheus que pueden ser recolectadas directamente por tu servidor Prometheus.
Grafana es la interfaz de usuario para toda la pila y desempeña un papel similar al de Kibana en la pila ELK/EFK. Grafana, entre otros plugins, proporciona integración directa con Loki como una fuente de datos para explorar esas trazas e incluirlas en los paneles.
Resumen
Grafana Loki puede ser una gran solución para tu arquitectura de registro para cubrir dos puntos: Proporcionar una solución de agregación de logs ligera para tu entorno y al mismo tiempo habilitar tus trazas de logs como una fuente para tus métricas, permitiéndote crear métricas detalladas, más orientadas al negocio que se utilizan en tus paneles y tus sistemas de monitoreo.
El servicio Mesh Linkerd patrocinado por CNCF proporciona muchas características necesarias en las arquitecturas de microservicios actuales.
Si estás leyendo esto, probablemente ya estés al tanto de los desafíos que vienen con una arquitectura de microservicios. Podría ser porque estás leyendo sobre ellos o incluso porque los estás enfrentando ahora mismo en tu propia piel.
Uno de los desafíos más comunes es la red y la comunicación. Con la eclosión de muchos componentes que necesitan comunicación y el enfoque efímero de los desarrollos nativos de la nube, muchas características nuevas son una necesidad cuando en el pasado eran solo un «agradable de tener».
Conceptos como el registro de servicios y el descubrimiento de servicios, la autenticación de servicios, las políticas de enrutamiento dinámico y los patrones de disyuntor ya no son cosas que todas las empresas geniales están haciendo, sino algo básico para dominar la nueva arquitectura de microservicios como parte de una plataforma de arquitectura nativa de la nube, y aquí es donde el proyecto Service Mesh está aumentando su popularidad como una solución para la mayoría de estos desafíos y proporcionando estas características que se necesitan.
Si recuerdas, hace mucho tiempo, ya cubrí ese tema para presentar Istio como una de las opciones que tenemos:
Integrating Istio with BWCE Applications
Introduction Services Mesh is one the “greatest new thing” in our PaaS environments. No matter if you’re working with K8S, Docker Swarm, pure-cloud with EKS or AWS, you’ve heard and probably tried to know how can be used this new thing that has so many advantages because it provides a lot of options in handling […]
Pero este proyecto creado por Google e IBM no es la única opción que tienes para proporcionar esas capacidades. Como parte de la Cloud Native Computing Foundation (CNCF), el proyecto Linkerd proporciona características similares.
Cómo instalar Linkerd
Para comenzar a usar Linkerd, lo primero que necesitamos hacer es instalar el software y para hacerlo. Necesitamos hacer dos instalaciones, una en el servidor de Kubernetes y otra en el host.
Para instalar en el host, necesitas ir a la página de lanzamientos y descargar la edición para tu sistema operativo e instalarla.
Estoy usando un sistema basado en Windows en mi ejemplo, así que uso chocolatey para instalar el cliente. Después de hacerlo, puedo ver la versión del CLI escribiendo el siguiente comando:
linkerd version
Y obtendrás una salida que dirá algo similar a esto:
PS C:WINDOWSsystem32> linkerd.exe version
Client version: stable-2.8.1
Server version: unavailable
Ahora necesitamos hacer la instalación en el servidor de Kubernetes, y para hacerlo, usamos el siguiente comando:
linkerd install | kubectl apply -f -
Y obtendrás una salida similar a esta:
PS C:WINDOWSsystem32> linkerd install | kubectl apply -f -
namespace/linkerd created
clusterrole.rbac.authorization.k8s.io/linkerd-linkerd-identity created
clusterrolebinding.rbac.authorization.k8s.io/linkerd-linkerd-identity created
serviceaccount/linkerd-identity created
clusterrole.rbac.authorization.k8s.io/linkerd-linkerd-controller created
clusterrolebinding.rbac.authorization.k8s.io/linkerd-linkerd-controller created
serviceaccount/linkerd-controller created
clusterrole.rbac.authorization.k8s.io/linkerd-linkerd-destination created
clusterrolebinding.rbac.authorization.k8s.io/linkerd-linkerd-destination created
serviceaccount/linkerd-destination created
role.rbac.authorization.k8s.io/linkerd-heartbeat created
rolebinding.rbac.authorization.k8s.io/linkerd-heartbeat created
serviceaccount/linkerd-heartbeat created
role.rbac.authorization.k8s.io/linkerd-web created
rolebinding.rbac.authorization.k8s.io/linkerd-web created
clusterrole.rbac.authorization.k8s.io/linkerd-linkerd-web-check created
clusterrolebinding.rbac.authorization.k8s.io/linkerd-linkerd-web-check created
clusterrolebinding.rbac.authorization.k8s.io/linkerd-linkerd-web-admin created
serviceaccount/linkerd-web created
customresourcedefinition.apiextensions.k8s.io/serviceprofiles.linkerd.io created
customresourcedefinition.apiextensions.k8s.io/trafficsplits.split.smi-spec.io created
clusterrole.rbac.authorization.k8s.io/linkerd-linkerd-prometheus created
clusterrolebinding.rbac.authorization.k8s.io/linkerd-linkerd-prometheus created
serviceaccount/linkerd-prometheus created
clusterrole.rbac.authorization.k8s.io/linkerd-linkerd-proxy-injector created
clusterrolebinding.rbac.authorization.k8s.io/linkerd-linkerd-proxy-injector created
serviceaccount/linkerd-proxy-injector created
secret/linkerd-proxy-injector-tls created
mutatingwebhookconfiguration.admissionregistration.k8s.io/linkerd-proxy-injector-webhook-config created
clusterrole.rbac.authorization.k8s.io/linkerd-linkerd-sp-validator created
clusterrolebinding.rbac.authorization.k8s.io/linkerd-linkerd-sp-validator created
serviceaccount/linkerd-sp-validator created
secret/linkerd-sp-validator-tls created
validatingwebhookconfiguration.admissionregistration.k8s.io/linkerd-sp-validator-webhook-config created
clusterrole.rbac.authorization.k8s.io/linkerd-linkerd-tap created
clusterrole.rbac.authorization.k8s.io/linkerd-linkerd-tap-admin created
clusterrolebinding.rbac.authorization.k8s.io/linkerd-linkerd-tap created
clusterrolebinding.rbac.authorization.k8s.io/linkerd-linkerd-tap-auth-delegator created
serviceaccount/linkerd-tap created
rolebinding.rbac.authorization.k8s.io/linkerd-linkerd-tap-auth-reader created
secret/linkerd-tap-tls created
apiservice.apiregistration.k8s.io/v1alpha1.tap.linkerd.io created
podsecuritypolicy.policy/linkerd-linkerd-control-plane created
role.rbac.authorization.k8s.io/linkerd-psp created
rolebinding.rbac.authorization.k8s.io/linkerd-psp created
configmap/linkerd-config created
secret/linkerd-identity-issuer created
service/linkerd-identity created
deployment.apps/linkerd-identity created
service/linkerd-controller-api created
deployment.apps/linkerd-controller created
service/linkerd-dst created
deployment.apps/linkerd-destination created
cronjob.batch/linkerd-heartbeat created
service/linkerd-web created
deployment.apps/linkerd-web created
configmap/linkerd-prometheus-config created
service/linkerd-prometheus created
deployment.apps/linkerd-prometheus created
deployment.apps/linkerd-proxy-injector created
service/linkerd-proxy-injector created
service/linkerd-sp-validator created
deployment.apps/linkerd-sp-validator created
service/linkerd-tap created
deployment.apps/linkerd-tap created
configmap/linkerd-config-addons created
serviceaccount/linkerd-grafana created
configmap/linkerd-grafana-config created
service/linkerd-grafana created
deployment.apps/linkerd-grafana created
Ahora podemos verificar que la instalación se ha realizado correctamente usando el comando:
linkerd check
Y si todo se ha hecho correctamente, obtendrás una salida como esta:
PS C:WINDOWSsystem32> linkerd check
kubernetes-api
--------------
√ can initialize the client
√ can query the Kubernetes API
kubernetes-version
------------------
√ is running the minimum Kubernetes API version
√ is running the minimum kubectl version
linkerd-existence
-----------------
√ 'linkerd-config' config map exists
√ heartbeat ServiceAccount exist
√ control plane replica sets are ready
√ no unschedulable pods
√ controller pod is running
√ can initialize the client
√ can query the control plane API
linkerd-config
--------------
√ control plane Namespace exists
√ control plane ClusterRoles exist
√ control plane ClusterRoleBindings exist
√ control plane ServiceAccounts exist
√ control plane CustomResourceDefinitions exist
√ control plane MutatingWebhookConfigurations exist
√ control plane ValidatingWebhookConfigurations exist
√ control plane PodSecurityPolicies exist
linkerd-identity
----------------
√ certificate config is valid
√ trust anchors are using supported crypto algorithm
√ trust anchors are within their validity period
√ trust anchors are valid for at least 60 days
√ issuer cert is using supported crypto algorithm
√ issuer cert is within its validity period
√ issuer cert is valid for at least 60 days
√ issuer cert is issued by the trust anchor
Luego podemos ver el panel de Linkerd usando el siguiente comando:
linkerd dashboard
Página web inicial del panel después de una instalación limpia de Linkerd
Despliegue de las aplicaciones
Usaremos las mismas aplicaciones que usamos hace algún tiempo para desplegar istio, así que si quieres recordar lo que están haciendo, necesitas mirar de nuevo ese artículo.
Para desplegar, necesitas tener tus imágenes de docker subidas a un registro de docker, y usaré Amazon ECR como el repositorio de docker que voy a usar.
Así que necesito construir y subir esas imágenes con los siguientes comandos:
Y si alcanzamos el endpoint, obtuvimos la respuesta esperada del proveedor.
Respuesta de muestra proporcionada por el proveedor
Y en el panel, podemos ver las estadísticas del proveedor:
Panel de Linkerd mostrando las estadísticas del flujo
Además, Linkerd por defecto proporciona un panel de Grafana donde puedes ver más métricas, puedes llegar allí usando el enlace de grafana que tiene el panel.
Enlace de Grafana en el Panel de Linkerd
Cuando entras, podrías ver algo como el panel que se muestra a continuación:
Panel de Grafana mostrando las estadísticas de linkerd
Resumen
Con todo este proceso, hemos visto lo fácil que podemos desplegar un servicio mesh de linkerd en nuestro clúster de Kubernetes y cómo las aplicaciones pueden integrarse e interactuar con ellos. En los próximos posts, profundizaremos en las características más avanzadas que nos ayudarán en los nuevos desafíos que vienen con la arquitectura de Microservicios.
Nunca he sido corredor en mi vida hasta hace poco. Siempre fui un chico de deportes de equipo. Siempre disfruto de la competencia y el trabajo en equipo, así que correr no era lo mío, pero en algún momento, necesitaba hacer algo para cambiar mi vida.
La razón de eso es clara, después de ganar más de 20 kg en mis días de universidad y vida adulta, estaba afectando mi salud tanto física como mentalmente.
Ahora, después de dos maratones, varias medias maratones y muchas carreras de 10k, puedo contarte mi experiencia y especialmente algunos de los beneficios inesperados después de unirme a este movimiento que probablemente no conoces aún si no estás en esto o si ya lo estás, espero que leer esto pueda poner una sonrisa en tu cara.
#1 Tendrás Tu Propio Momento Para Encontrarte A Ti Mismo
Correr es un deporte que puedes practicar por ti mismo y prácticamente en cualquier lugar. Lo único que necesitas para empezar es un par de zapatillas y tu motivación para salir y empezar a correr.
Eso significa que es cuando estás solo en un momento privado con tu propia mente. Descubrí que este es un gran momento para organizar mi cabeza. No solo para liberar todo el estrés de mi vida diaria y abrazar este momento mío para ser más feliz, sino también para ser más saludable.
No tengo una rutina clara respecto a este tema o alguna técnica de meditación que haga. Depende de lo que necesite en cada momento.
Algunos días necesito escuchar música para liberar todo después de un mal día en el trabajo o para cargar mis baterías para comenzar mi día completamente, o necesito escuchar mis podcasts de una manera íntima en la que pueda concentrarme mucho más en su contenido de lo que probablemente pueda hacer en mi vida normal.
Pero otros días, uso ese tiempo para concentrarme en resolver un problema que tengo en el trabajo (cómo resolver este problema de producción, cómo implementar esta característica que no tenía clara, cómo enfocar esta presentación que necesito hacer…) o incluso para pensar en mi vida y metas para el futuro.
#2 Serás Parte De Una Comunidad
Los corredores son parte de la misma comunidad, y nadie puede cambiar eso. Incluso personas como yo que siempre corren solas y no son parte de ningún club de corredores que se reúnen para hacer el entrenamiento definido pertenecen a esta hermandad.
Es una experiencia extraña cuando te levantas para hacer nuestra carrera matutina, y te encuentras por unos segundos con otra persona haciendo lo mismo que tú. Es una conexión extraña que sientes con esa persona. Probablemente incluso lo/la saludes aunque no lo/la conozcas solo porque ambos saben que son parte del mismo club secreto y comparten algo en común.
Esto es aún mejor si te unes a otras comunidades de corredores como Publicaciones de Corredores, Podcast o Club de Corredores, como estaba diciendo. No importa el ritmo que tengas o cuántas maratones hayas hecho. Tan pronto como te pongas las zapatillas y salgas a la carretera, eres parte del club. Te has unido a la fuerza.
#3 Sentirás El Espíritu De Competencia
No hay nada comparable con la sensación de correr en un gran evento. Tuve la oportunidad de hacer dos maratones hasta que la pandemia nos detuvo a todos, y fue en Madrid 2019 y Valencia 2019, y la experiencia fue la mejor de mi vida. Todo el público apoyándote todo el camino, todos los otros corredores sufriendo contigo y al mismo tiempo disfrutando cada uno de los km desde el inicio hasta el final.
Toda la gente que encuentras cada 10 km te encuentras cada domingo por la mañana cuando el resto de la gente apenas se está levantando y preparando su café, y tú estás en la carretera tratando de superar tu mejor marca personal.
Porque cada vez que corres, estás tratando de superarte. Estás tratando de ser la mejor versión de ti mismo, lo que te ayuda en todos los aspectos de tu vida.
#4 Encontrarás Otra Forma De Descubrir La Ciudad
Usualmente hago dos tipos de sesiones de entrenamiento dependiendo de mi horario y lo que mi cuerpo y mente están demandando para esa sesión. Algunas de ellas que son entrenamientos específicos (series, fartlek, etc.) requieren hacerse en un lugar específico, pero la mayoría del tiempo, solo corro sin la necesidad de estar en un lugar específico y me ayuda a descubrir la ciudad de una manera muy diferente.
Sigo lo que llamo “el camino de las luces verdes”, así que empiezo sin un itinerario específico en mente. Sigo las “luces verdes” en el paso de peatones porque odio detenerme cuando estoy corriendo, así que eso me hace correr por calles en las que nunca he estado (es increíble lo poco que conoces de una ciudad en la que vives) o si estás en otra ciudad por razones de ocio o negocios, es una manera increíble de descubrir una ciudad de una manera muy diferente para abrazarla completamente y conectarte con ella y sentir su alma de una manera muy diferente.
Resumen
Espero que estos puntos destacados siembren dentro de ti si estabas pensando en darle una oportunidad a la Vida de Corredor, y probablemente en este momento estás mirando las zapatillas que tienes en tu armario esperando ser parte de tu rutina desde ahora. Y si ya eres un Corredor, espero que disfrutes y tal vez estés de acuerdo con algunos de estos como los grandes beneficios que usualmente no se mencionan cuando leemos sobre los beneficios de correr.
Aprende qué proporciona el Servicio Administrado de Amazon para Prometheus y cómo puedes beneficiarte de él.
El monitoreo es uno de los temas candentes cuando hablamos de arquitecturas nativas de la nube. Prometheus es un proyecto de código abierto graduado de la Cloud Native Computing Foundation (CNCF) y una de las soluciones estándar de la industria cuando se trata de monitorear tu implementación nativa de la nube, especialmente cuando Kubernetes está involucrado.
Siguiendo su propia filosofía de proporcionar un servicio administrado para algunos de los proyectos de código abierto más utilizados pero totalmente integrado con el ecosistema de AWS, AWS lanza una vista previa general (en el momento de escribir este artículo): Servicio Administrado de Amazon para Prometheus (AMP).
Lo primero es definir qué es el Servicio Administrado de Amazon para Prometheus y qué características proporciona. Así que, esta es la definición de Amazon del servicio:
Un servicio de monitoreo totalmente administrado compatible con Prometheus que facilita el monitoreo de aplicaciones en contenedores de manera segura y a escala.
Y me gustaría dedicar algo de tiempo a algunas partes de esta oración.
Servicio totalmente administrado: Entonces, esto será alojado y manejado por Amazon, y solo vamos a interactuar con él usando API como lo hacemos con otros servicios de Amazon como EKS, RDS, MSK, SQS/SNS, y así sucesivamente.
Compatible con Prometheus: Entonces, eso significa que incluso si esta no es una instalación pura de Prometheus, la API será compatible. Así que los clientes de Prometheus que pueden usar Grafana u otros para obtener la información de Prometheus funcionarán sin cambiar sus interfaces.
Servicio a escala: Amazon, como parte del servicio administrado, se encargará de la escalabilidad de la solución. No necesitas definir un tipo de instancia o cuánta RAM o CPU necesitas. Esto será manejado por AWS.
Entonces, eso suena perfecto. Así que puedes pensar que vas a eliminar tu servidor de Prometheus, y comenzará a usar este servicio. Tal vez incluso estés escribiendo algo como helm delete prom… ¡ESPERA ESPERA!
Porque en este punto, esto no va a reemplazar tu servidor local de Prometheus, pero permitirá la integración con él. Así que, eso significa que tu servidor de Prometheus actuará como un recolector para toda la solución de monitoreo escalable que AMP está proporcionando, algo como puedes ver en la imagen a continuación:
Arquitectura de Referencia para el Servicio de Prometheus de Amazon
Entonces, todavía vas a necesitar un servidor de Prometheus, eso es correcto, pero toda la complejidad se evitará y se aprovechará en el servicio administrado: La configuración de almacenamiento, alta disponibilidad, optimización de API, y así sucesivamente, se te proporcionará directamente.
Ingesta de información en el Servicio Administrado de Amazon para Prometheus
En este momento, hay dos formas de ingresar datos en el Servicio de Prometheus de Amazon:
Desde un servidor de Prometheus existente usando la capacidad y configuración de remote_write, lo que significa que cada serie que es recolectada por el Prometheus local será enviada al Servicio de Prometheus de Amazon.
Usando AWS Distro para OpenTelemetry para integrarse con este servicio usando el Receptor de Prometheus y los componentes Exportador de Escritura Remota de AWS Prometheus para obtener eso.
Resumen
Así que esta es una forma de proporcionar una instalación de nivel empresarial aprovechando todo el conocimiento que AWS tiene al alojar y gestionar esta solución a escala y optimizada en términos de rendimiento. Puedes centrarte en los componentes que necesitas para obtener las métricas ingresadas en el servicio.
Estoy seguro de que este no será el último movimiento de AWS en temas de observabilidad y gestión de métricas. Estoy seguro de que continuarán proporcionando más herramientas a las manos de los desarrolladores y arquitectos para definir soluciones optimizadas tan fácilmente como sea posible.
3 beneficios de usar GraphQL en tu API que deberías tener en cuenta.
Todos sabemos que las APIs son el nuevo estándar cuando desarrollamos cualquier pieza de software. Todos los enfoques de paradigma más recientes se basan en una cantidad distribuida de componentes creados con un enfoque colaborativo en mente que necesitan trabajar juntos para proporcionar más valor a todo el ecosistema.
Hablando de la parte técnica, una API se ha convertido en sinónimo de usar REST/JSON para exponer esas APIs como un nuevo estándar. Pero esta no es la única opción incluso en el mundo de solicitud/respuesta sincrónica, y estamos comenzando a ver un cambio en esta selección por defecto de REST como la única opción en esta área.
GraphQL ha surgido como una alternativa que también funciona desde que Facebook lo introdujo en 2015. Durante estos cinco años de existencia, su adopción está creciendo fuera de las paredes de Facebook, pero esto todavía está lejos de los usos del público en general, como muestra el siguiente gráfico de Google Trends.
Gráfico de Google Trends que muestra el interés en REST vs. GraphQL en los últimos cinco años
Pero creo que este es un gran momento para volver a mirar los beneficios que GraphQL puede proporcionar a tus APIs en tu ecosistema. Puedes comenzar un nuevo año introduciendo una tecnología que puede proporcionarte a ti y a tu empresa beneficios claros. Así que, echemos un vistazo a ellos.
1.- Estilo más flexible para satisfacer las necesidades de diferentes perfiles de clientes.
Quiero comenzar este punto con un pequeño salto al pasado cuando se introdujo REST. REST no siempre fue el estándar que usamos para crear nuestra API o Servicios Web, como lo llamábamos en ese momento. Un estándar del W3C, SOAP, era el líder de eso, y REST lo reemplaza, enfocándose en varios puntos.
Sin embargo, el peso del protocolo mucho más ligero que SOAP marca la diferencia, especialmente cuando los dispositivos móviles comienzan a ser parte del ecosistema.
Esa es la situación hoy en día, y GraphQL es un paso adicional en ese enfoque y la perspectiva de ser más flexible. GraphQL permite a cada cliente decidir qué parte de los datos les gustaría usar la misma interfaz para diferentes aplicaciones. Cada uno de ellos seguirá teniendo un enfoque optimizado porque pueden decidir qué les gustaría obtener en cada momento.
2.- Enfoque más desacoplado con el proveedor de servicios
Otro tema importante es la dependencia entre el consumidor de la API y el proveedor. Todos sabemos que diferentes paradigmas como los microservicios se centran en ese enfoque. Nuestro objetivo es obtener tanta independencia como sea posible entre nuestros componentes.
REST no proporciona un gran vínculo entre los componentes, eso es cierto. Aun así, la interfaz está fija al mismo tiempo, por lo que eso significa que cada vez que modificamos esa interfaz agregando un nuevo campo o cambiando uno, podemos afectar al consumidor incluso si no necesitan ese campo para nada.
GraphQL, por su característica de seleccionar los campos que me gustaría obtener, facilita mucho la evolución de la API en sí misma y al mismo tiempo proporciona mucha más independencia para los componentes porque solo los cambios que tienen un impacto claro en los datos que un cliente necesita pueden generar un efecto en ellos, pero el resto es completamente transparente para ellos.
3.- Especificación más estructurada y definida
Uno de los aspectos que definió el auge de REST como un protocolo ampliamente utilizado es la falta de estándares para estructurar y definir su comportamiento. Tuvimos varios intentos usando RAML o incluso solo «muestras como especificación», swagger, y finalmente una especificación OpenAPI. Pero ese tiempo de situación «no estructurada» genera que la API REST pueda hacerse de maneras muy diferentes.
Cada desarrollador o proveedor de servicios puede generar una API REST con un enfoque y filosofía diferentes que generan ruido y es difícil de estandarizar. GraphQL se basa en un Esquema GraphQL que define el tipo gestionado por la API y las operaciones que puedes hacer con él en dos grupos principales: consultas y mutaciones. Eso permite que todas las APIs de GraphQL, sin importar quién las esté desarrollando, sigan la misma filosofía ya que está incluida en el núcleo de la especificación en sí.
Resumen
Después de leer este artículo, probablemente estés diciendo, entonces eso significa que debería eliminar toda mi API REST y comenzar a construir todo en GraphQL. Y mi respuesta a eso es… ¡NO!
El objetivo de este artículo es que seas consciente de los beneficios que diferentes formas de definir API te están proporcionando para que puedas agregarlos a tu cinturón de herramientas, así que la próxima vez que crees una API pienses en estos temas descritos aquí y llegues a una conclusión que sea: mmm creo que GraphQL es la mejor opción para esta situación específica o al revés, no voy a obtener ningún beneficio en esta API específica, así que prefiero usar REST.
La idea es que ahora sepas aplicar a tu caso específico y elegir en base a eso porque nadie mejor que tú para decidir qué es lo mejor para tu caso de uso.
Sigue estos consejos para seleccionar la publicación adecuada para tu artículo y asegurarte de garantizar el mejor impacto.
Cuando estamos escribiendo un artículo en Medium y nos gustaría compartirlo con nuestra audiencia, todos sabemos que usar una Publicación es la mejor manera de hacerlo. Una Publicación es como un sitio de medios o una revista tradicional que aloja artículos sobre un tema y los comparte con sus suscriptores. Cuanto más grande sea la publicación, más personas serán notificadas de que tu artículo está disponible, y mejor será la oportunidad de que tus artículos se muestren en la página de inicio de los usuarios de Medium. Así que seleccionar la publicación adecuada es crucial en este proceso.
Encuentra los seguidores de cualquier publicación.
Lo primero que necesitamos hacer para conocer el número de seguidores de cada publicación es seleccionar la publicación que nos gustaría verificar. Por ejemplo, voy a usar una de las principales, que es The Innovation. Si vas a su página principal: https://medium.com/the-innovation
No verás el número de seguidores directamente en su barra de menú como se muestra en la imagen a continuación:
Página principal de la publicación The Innovation en Medium
Algunas otras publicaciones pueden mostrar su número de seguidores en el menú de la barra superior, pero esto no sucede para todas las publicaciones. Pero aún tienes la opción de conocer el número de seguidores de cada publicación haciendo este pequeño truco. Si tienes la URL principal de una publicación, si agregas /latest a esa URL, estarás en una página que siempre muestra el mismo diseño para todas las publicaciones, y como parte de ese diseño, encontrarás en la barra lateral derecha el número de seguidores:
La página más reciente de la publicación The Innovation mostrando el número de seguidores
Así que, ahora puedes verificar el número de seguidores de cada publicación disponible en Medium, y también te ayudará a saber cuánto tiempo ha pasado desde que se publicó su última entrada. Si la publicación no está publicando nada nuevo, tu historia nunca llegará a todos los seguidores que tiene, así que también verifica la fecha de la última entrada disponible en la misma página.
Encuentra las publicaciones más grandes de hoy.
Ahora sabemos cómo conocer el número de seguidores de cada publicación, pero eso requiere verificar publicación por publicación para obtener ese número, y esto es tedioso. Pero aún peor, necesitamos conocer la publicación que nos gustaría verificar, y no creo que nadie en el espacio de Medium conozca todas las publicaciones para asegurarse de haber verificado todas las relevantes. Entonces, ¿cómo podemos hacer eso más rápido y mejor? Fácil. Aquí está el truco mágico que estabas esperando.
Simplemente ve a esta URL: https://medium.com/search/publications?q=*. Esta URL va a enviar todas las publicaciones (* actúa como un comodín que dice «todo»), por lo que se mostrarán todas las publicaciones, y se ordenarán según el número de editores, como puedes ver aquí:
Resultados de búsqueda de publicaciones ordenados por Seguidores
Para mostrar el número de seguidores, tomo los primeros 20 y hago el truco del primer paso para obtener la siguiente tabla:
Las 14 principales publicaciones en Medium ordenadas por el número de seguidores que tienen
Encuentra la adecuada para ti
Ahora que tenemos todos los datos en nuestras manos, solo necesitamos seleccionar la adecuada para el artículo que nos gustaría enviar, basado en el tema que estamos cubriendo y la perspectiva y estilo que usamos para generar nuestra historia. Es muy recomendable mirar las pautas del creador que tiene cada publicación para adaptar el contenido a lo que se espera de la audiencia de la publicación. De esa manera, maximizamos nuestro éxito con la audiencia.
CICD Docker significa el enfoque que la mayoría de las empresas están utilizando para introducir contenedores también en la fase de construcción y pre-despliegue para implementar una parte de la canalización CICD. Veamos por qué.
DevSecOps es la nueva norma para despliegues a gran escala en grandes empresas para cumplir con el ritmo requerido en los negocios digitales hoy en día. Estos procesos se orquestan utilizando una herramienta de orquestación CICD que actúa como el cerebro de este proceso. Las herramientas habituales para hacer este trabajo son Jenkins, Bamboo, AzureDevOps, GitLab, GitHub.
En el enfoque tradicional, tenemos diferentes servidores de trabajo realizando etapas del proceso DevOps: Código, Construcción, Prueba, Despliegue, y para cada uno de ellos, necesitamos diferentes tipos de herramientas y utilidades para hacer el trabajo. Por ejemplo, para obtener el código, podemos necesitar un git instalado. Para hacer la construcción, podemos confiar en maven o Gradle, y para probar, podemos usar SonarQube, etc.
Estructura de CICD Docker y la relación entre Orquestador y Trabajadores
Entonces, al final, necesitamos un conjunto de herramientas para desempeñarnos con éxito, y eso también requiere algo de gestión. En los nuevos días, con el auge del desarrollo nativo en la nube y el enfoque de contenedores en la industria, esto también está afectando la forma en que desarrollas tus canalizaciones para introducir contenedores como parte de la etapa.
En la mayoría de los Orquestadores CI, puedes definir una imagen de contenedor para ejecutar como cualquier paso de tu proceso DevSecOps, y déjame decirte que es genial si lo haces porque esto te proporcionará muchos de los beneficios de los que necesitas estar consciente.
1.- Solución mucho más escalable
Uno de los problemas cuando usas un orquestador como el elemento principal en tu empresa, y que está siendo utilizado por muchas tecnologías diferentes que pueden ser de código abierto, propietario, basado en código, desarrollo visual, etc., significa que necesitas gestionar muchas cosas e instalar el software en los trabajadores.
Usualmente, lo que haces es que defines algunos trabajadores para hacer la construcción de algunos artefactos, como la imagen mostrada a continuación:
Distribución de trabajadores basada en sus propias capacidades
Eso es genial porque permite la segmentación del proceso de construcción y no requiere que todo el software esté instalado en todas las máquinas, incluso cuando pueden ser incompatibles.
Pero, ¿qué pasa si necesitamos desplegar muchas aplicaciones de uno de los tipos que tenemos en la imagen a continuación, como aplicaciones de TIBCO BusinessWorks? Que estarás limitado según el número de trabajadores que tengan el software instalado para construirlo y desplegarlo.
Con un enfoque basado en contenedores, tendrás todos los trabajadores disponibles porque no se necesita software, solo necesitas extraer la imagen de docker, y eso es todo, así que solo estás limitado por la infraestructura que usas, y si adoptas una plataforma en la nube como parte del proceso de construcción, estas limitaciones simplemente se eliminan. Tu tiempo de comercialización y ritmo de despliegue mejoran.
2.- Fácil de mantener y extender
Si eliminas la necesidad de instalar y gestionar los trabajadores porque se activan cuando los necesitas y se eliminan cuando no son necesarios y todo lo que necesitas hacer es crear una imagen de contenedor que haga el trabajo, el tiempo y el esfuerzo que los equipos necesitan gastar en mantener y extender la solución disminuirán considerablemente.
También la eliminación de cualquier proceso de actualización para los componentes involucrados en los pasos ya que siguen el proceso habitual de imagen de contenedor.
3.- Evitar el bloqueo del Orquestador
Como confiamos en los contenedores para hacer la mayor parte del trabajo, el trabajo que necesitamos hacer para movernos de una solución DevOps a otra es pequeño, y eso nos da el control para elegir en cualquier momento si la solución que estamos usando es la mejor para nuestro caso de uso y contexto o necesitamos movernos a otra más optimizada sin el problema de justificar grandes inversiones para hacer ese trabajo.
Recuperas el control, y también puedes incluso ir a un enfoque de multi-orquestador si es necesario, como usar la mejor solución para cada caso de uso y obtener todos los beneficios de cada uno de ellos al mismo tiempo sin necesidad de luchar contra cada uno de ellos.
Resumen
Todos los beneficios que todos conocemos de los paradigmas de desarrollo nativo en la nube y los contenedores son relevantes para el desarrollo de aplicaciones y otros procesos que usamos en nuestra organización, siendo uno de esos tu canalización y procesos DevSecOps. Comienza hoy haciendo ese viaje para obtener todas esas ventajas en el proceso de construcción y no esperes hasta que sea demasiado tarde. Disfruta tu día. Disfruta tu vida.
Descubre las diferentes opciones para escalar tu plataforma según la carga de tráfico que recibas
Cuando hablamos de Kubernetes, siempre estamos hablando de las opciones de flexibilidad que proporciona. Normalmente, uno de los temas que surgen en la discusión son las opciones de elasticidad que vienen con la plataforma, especialmente cuando se trabaja con un proveedor de nube pública. Pero, ¿cómo podemos implementarlo realmente?
Antes de comenzar a mostrar cómo escalar nuestra plataforma Kubernetes, necesitamos hacer un breve repaso de las opciones que están disponibles para nosotros:
Cluster Autoscaler: Cuando la carga de toda la infraestructura alcanza su pico, podemos mejorarla creando nuevos nodos de trabajo para alojar más instancias de servicio.
Horizontal Pod Autoscaling: Cuando la carga para un pod específico o conjunto de pods alcanza su pico, desplegamos una nueva instancia para asegurar que podemos tener la disponibilidad global que necesitamos.
Veamos cómo podemos implementar esto usando uno de los servicios gestionados de Kubernetes más populares, los Servicios de Kubernetes Elásticos (EKS) de Amazon.
Configuración
Lo primero que vamos a hacer es crear un clúster con un solo nodo de trabajo para demostrar fácilmente el comportamiento de escalabilidad. Y para hacerlo, vamos a usar la herramienta de línea de comandos eksctl para gestionar fácilmente un clúster EKS.
Para poder crear el clúster, lo haremos con el siguiente comando:
Después de unos minutos, tendremos nuestro propio clúster de Kubernetes con un solo nodo para desplegar aplicaciones sobre él.
Ahora vamos a crear una aplicación de muestra para generar carga. Vamos a usar TIBCO BusinessWorks Application Container Edition para generar una aplicación simple. Será una API REST que ejecutará un bucle de 100,000 iteraciones actuando como un contador y devolverá un resultado.
Aplicación de muestra de BusinessWorks para mostrar las opciones de escalabilidad
Y utilizaremos los recursos disponibles en este repositorio de GitHub:
GitHub – alexandrev/testeks
Contribute to alexandrev/testeks development by creating an account on GitHub.
Construiremos la imagen del contenedor y la subiremos a un registro de contenedores. En mi caso, voy a usar mi instancia de Amazon ECR para hacerlo, y usaré los siguientes comandos:
Con eso, puedo ver y probar la aplicación de muestra usando el navegador, como se muestra a continuación:
Probador de Swagger UI para la aplicación de muestra de Kubernetes
Escalado automático de pods horizontales
Ahora, necesitamos comenzar a definir las reglas de escalado automático, y comenzaremos con la regla de Escalado Automático de Pods Horizontales (HPA). Necesitaremos elegir el recurso que nos gustaría usar para escalar nuestro pod. En esta prueba, usaré la utilización de CPU para hacerlo, y usaré el siguiente comando:
Ese comando escalará el conjunto de réplicas testeks de una (1) instancia a cinco (5) instancias cuando el porcentaje de utilización de CPU sea superior al 80%.
Si ahora verificamos el estado de los componentes, obtendremos algo similar a la imagen a continuación:
Definición de regla HPA para la aplicación usando la utilización de CPU como la métrica clave
Si verificamos la columna TARGETS, veremos este valor: <unknown>/80%. Eso significa que el 80% es el objetivo para activar las nuevas instancias y el uso actual es <unknown>.
No tenemos nada desplegado en el clúster para obtener las métricas de cada uno de los pods. Para resolver eso, necesitamos desplegar el Servidor de Métricas. Para hacerlo, seguiremos la documentación de Amazon AWS:
Installing the Kubernetes Metrics Server – Amazon EKS
The Kubernetes Metrics Server is an aggregator of resource usage data in your cluster, and it is not deployed by default in Amazon EKS clusters. For more information, see Kubernetes Metrics Server on GitHub. The Metrics Server is commonly used by other Kubernetes add ons, such as the
Entonces, ejecutando el siguiente comando, tendremos el Servidor de Métricas instalado.
Y después de hacer eso, si verificamos nuevamente, podemos ver que el uso actual ha reemplazado el <unknown>:
Utilización actual de recursos después de instalar el Servidor de Métricas en el clúster de Kubernetes
Si eso funciona, voy a comenzar a enviar solicitudes usando una Prueba de Carga dentro del clúster. Usaré la aplicación de muestra definida a continuación:
Capacidad de Escalado Automático con HPA – Bootcamp de Kubernetes Definitivo
Con el Escalado Automático de Pods Horizontales, Kubernetes escala automáticamente el número de pods en un controlador de replicación, despliegue o conjunto de réplicas basado en la utilización de CPU observada (o, con soporte alfa, en algunas otras métricas proporcionadas por la aplicación).
Para desplegar, usaremos un archivo YAML con el siguiente contenido:
Después de hacer eso, veremos que la utilización actual está aumentando. Después de unos segundos, comenzará a girar nuevas instancias hasta que alcance el número máximo de pods definido en la regla HPA.
Aumento de pods cuando la carga excede el objetivo definido en pasos anteriores.
Luego, tan pronto como la carga también disminuya, el número de instancias será eliminado.
Los pods se eliminan tan pronto como la carga disminuye.
Escalado automático de clústeres
Ahora, necesitamos ver cómo podemos implementar el Escalador Automático de Clústeres usando EKS. Usaremos la información que proporciona Amazon:
Ediciones de despliegue necesarias para configurar el Escalador Automático de Clústeres
Ahora necesitamos ejecutar el siguiente comando:
kubectl -n kube-system set image deployment.apps/cluster-autoscaler cluster-autoscaler=eu.gcr.io/k8s-artifacts-prod/autoscaling/cluster-autoscaler:v1.17.4
Lo único que queda es definir la política de AutoScaling. Para hacerlo, usaremos el portal de Servicios de AWS:
Ingresa a la página de servicio EC en la región en la que hemos desplegado el clúster.
Selecciona las opciones de Grupo de Auto Scaling.
Selecciona el Grupo de Auto Scaling que se ha creado como parte del proceso de creación del clúster EKS.
Ve a la pestaña de Escalado Automático y haz clic en el botón Agregar Política disponible.
Opción de política de escalado automático en la consola de servicio EC2
Luego deberíamos definir la política. Usaremos la utilización promedio de CPU como la métrica y estableceremos el valor objetivo en 50%:
Diálogo de creación de política de escalado automático
Para validar el comportamiento, generaremos carga usando el probador como lo hicimos en la prueba anterior y validaremos la carga del nodo usando el siguiente comando:
kubectl top nodes
Salida de muestra de kubectl top nodes
Ahora desplegamos el probador nuevamente. Como ya lo tenemos desplegado en este clúster, necesitamos eliminarlo primero para desplegarlo nuevamente:
Tan pronto como comience la carga, se crearán nuevos nodos, como se muestra en la imagen a continuación:
kubectl top nodes mostrando cómo los nodos han sido escalados hacia arriba
Después de que la carga termine, volvemos a la situación anterior:
kubectl top nodes mostrando cómo los nodos han sido escalados hacia abajo
Resumen
En este artículo, hemos mostrado cómo podemos escalar un clúster de Kubernetes de manera dinámica tanto a nivel de nodo de trabajo usando la capacidad de Escalador Automático de Clústeres como a nivel de pod usando el Escalador Automático de Pods Horizontales. Eso nos da todas las opciones necesarias para crear un entorno verdaderamente elástico y flexible capaz de adaptarse a las necesidades de cada momento con el enfoque más eficiente.
Auto Scaling Capacity with HPA – Ultimate Kubernetes Bootcamp
With Horizontal Pod Autoscaling, Kubernetes automatically scales the number of pods in a replication controller, deployment or replica set based on observed CPU utilization (or, with alpha support, on some other, application-provided metrics).
Uno de los mayores anuncios de las últimas sesiones de AWS re:Invent 2020 fue el lanzamiento de EKS-D de Amazon. EKS-D es su Distribución de Kubernetes de código abierto que ahora está disponible para que todos la usen en su proveedor de nube o incluso en sus instalaciones.
Está basado en hallazgos anteriores y en todo el proceso que Amazon ha llevado a cabo en la gestión de su plataforma gestionada de Kubernetes, Amazon EKS.
Estos anuncios han hecho que muchas personas se pregunten: “OK, conozco Kubernetes, pero ¿qué es una distribución de Kubernetes? ¿Y por qué debería importarme?”
Así que intentaré responder eso con el conocimiento que tengo, y siempre trato de usar el mismo enfoque: una comparación del modelo de Kubernetes versus Linux.
Kubernetes es un proyecto de código abierto, como sabes, iniciado por Google y ahora gestionado por la comunidad y la Cloud Native Computing Foundation (CNCF), y puedes encontrar todo el código disponible aquí:
GitHub – kubernetes/kubernetes: Production-Grade Container Scheduling and Management
Production-Grade Container Scheduling and Management – GitHub – kubernetes/kubernetes: Production-Grade Container Scheduling and Management
Pero seamos honestos: No muchos de nosotros estamos descargando ese repositorio e intentando compilarlo para proporcionar un clúster. No es así como solemos trabajar. Si sigues el camino del código — descargándolo, construyéndolo, etc. — esto generalmente se llama vanilla Kubernetes.
Si comenzamos con la comparación con Linux, es la misma situación que tenemos con el kernel de Linux que la mayoría de las distribuciones de Linux envían, pero esto ya está compilado y disponible con un montón de otras herramientas que trabajan juntas a través del enfoque habitual.
Así que eso es lo que es una distribución de Kubernetes. Construyen Kubernetes. Proporcionan otras herramientas y componentes para mejorar o proporcionar más características y para centrarse en aspectos adicionales como un enfoque en la seguridad, un enfoque en DevOps, u otro enfoque. Otro concepto que generalmente se plantea es la pureza de la distribución, y tratamos de hablar sobre una distribución que sea pura.
Llamamos a una distribución pura cuando está construyendo Kubernetes, y eso es todo. Deja todo lo demás a los desarrolladores o usuarios para decidir qué quieren usar encima de ella.
¿Cuáles son los Componentes Principales que se Incluyen en una Distribución de Kubernetes?
Los componentes principales que pueden diferir cuando hablamos de una distribución de Kubernetes son los siguientes:
Tiempo de ejecución de contenedores y registros
Todos sabemos que hay más de un tiempo de ejecución de contenedores, e incluso si no estabas al tanto de eso, probablemente hayas leído todos los artículos sobre la eliminación del soporte de Docker en Kubernetes v1.20, como puedes leer en este increíble artículo de Edgar Rodriguez.
Kubernetes Just Deprecated Docker Support. What Now?
Will this kill Docker?
En este momento, parece que todos los tiempos de ejecución deberían soportar la existente Interfaz de Tiempo de Ejecución de Contenedores, y tiempos de ejecución como CRI-O, Containerd, o Kata parecen ser las opciones predeterminadas ahora.
Redes
Otro tema que a menudo difiere cuando hablamos de distribuciones de Kubernetes es cómo gestionan su red, y este es uno de los aspectos más críticos de toda la plataforma.
Como tenemos con el tiempo de ejecución de contenedores, existe una especificación estándar para cubrir ese tema, y esa es la Interfaz de Red de Contenedores (CNI). Existen varios proyectos sobre este tema, como Flannel, Calico, Canal, y Wave. Además, algunas plataformas proporcionan su propio componente, como el operador Openshift SDN.
Almacenamiento
Cómo manejar el almacenamiento en Kubernetes también es muy importante, especialmente a medida que adoptamos este modelo en implementaciones que requieren modelos con estado. Diferentes plataformas pueden soportar diferentes opciones de almacenamiento, como sistemas de archivos, etc.
¿Quiénes son los Mejores Jugadores?
Lo primero que debemos tener en cuenta es que hay un gran número de distribuciones de Kubernetes por ahí.
Contaremos las que tienen una certificación CNCF, y puedes echar un vistazo a todas ellas aquí. En el momento de escribir este artículo, estamos hablando de 72 distribuciones certificadas.
Imagen a través de la Cloud Native Computing Foundation
Estos son los que me gustaría destacar hoy:
Red Hat OpenShift
La plataforma Red Hat OpenShift podría ser una de las plataformas más utilizadas, especialmente en un entorno de nube privada. Podría incluir la mayoría de los servicios de Red Hat en cuanto a almacenamiento, como GlusterFS y redes con OpenShift DNS. Tiene OKD como el proyecto de código abierto que respalda y contribuye a la plataforma OpenShift. Consulta este artículo para ver cómo configurar Openshift localmente para probarlo
Mirantis
La antigua empresa Docker que ha sido adquirida por Mirantis es otra de las opciones habituales cuando hablamos de plataformas soportadas.
VMware Tanzu
VMware Tanzu, también proveniente de la adquisición de Pivotal por parte de VMware, es una plataforma de Kubernetes.
Canonical
Canonical (código abierto) es una plataforma de la empresa que desarrolla y mantiene Ubuntu. Es otra de las opciones importantes aquí y proporciona una variedad de opciones, centrándose no solo en el modo central común sino también en implementaciones de Kubernetes en el borde con proyectos como MicroK8S y más opciones.
Rancher
Rancher (código abierto) es otro de los grandes jugadores, centrándose en seguir y extender los estándares de CNCF y también ofreciendo un gran impulso para la implementación en el borde con K3S. También ofrece actualizaciones automáticas.
Resumen
Así que, como puedes ver, el número de opciones disponibles es enorme. Todas difieren, por lo que es importante tomarse su tiempo cuando se decide la plataforma objetivo basada en sus criterios para su proyecto o su empresa.
Y eso sin cubrir las plataformas gestionadas disponibles que se están convirtiendo en una de las opciones más preferidas para las empresas para que puedan obtener toda la flexibilidad de Kubernetes sin necesidad de manejar la complejidad de gestionar una plataforma de Kubernetes por sí mismos. Pero ese es un tema para otro artículo — esperemos que pronto.
Este artículo al menos te ha proporcionado más claridad sobre qué es una distribución de Kubernetes, las principales diferencias entre ellas, y un vistazo rápido a algunos de los actores clave en este espectro. Disfruta tu día, y disfruta tu vida.
