{"id":15141,"date":"2023-04-26T07:26:15","date_gmt":"2023-04-26T07:26:15","guid":{"rendered":"https:\/\/bluetab.net\/?p=15141"},"modified":"2023-04-26T07:26:15","modified_gmt":"2023-04-26T07:26:15","slug":"kubecon-2023-una-mirada-hacia-el-futuro-de-kubernetes","status":"publish","type":"post","link":"https:\/\/bluetab.net\/en\/2023\/04\/kubecon-2023-una-mirada-hacia-el-futuro-de-kubernetes\/","title":{"rendered":"KubeCon 2023: Una mirada hacia el futuro de Kubernetes"},"content":{"rendered":"
\"\"<\/a><\/figure>\n

Lucas Calvo<\/a><\/h4>\n

Cloud Engineer<\/p>\n

\"\"<\/a><\/figure>\n

Javier P\u00e9rez<\/a><\/h4>\n

Practice Lead for MLOps<\/p>\n

\"\"<\/a><\/figure>\n

\u00c1ngel Maroco<\/a><\/h4>\n

Enterprise Architect<\/p>\n

Como es costumbre en Bluetab,<\/b> desde hace ya varios a\u00f1os asistimos a la KubeCon + CloudNative Europa 2023 <\/b>celebrada en Amsterdam<\/b>, el evento tecnol\u00f3gico l\u00edder a nivel mundial en referencia a Kubernetes, Cloud Native y tendencias DevOps<\/b>.<\/p>\n

Durante esta conferencia, que re\u00fane a miles de desarrolladores, ingenieros y expertos en tecnolog\u00eda de todo el mundo, hemos tenido la oportunidad de adquirir ideas innovadoras para nuestro trabajo.\u00a0<\/p>\n

Adem\u00e1s, pudimos presenciar casos de uso reales de las principales empresas a nivel mundial, lo que nos permiti\u00f3 adentrarnos en los desaf\u00edos complejos que enfrentan las grandes organizaciones en la actualidad.<\/p>\n

En este art\u00edculo, nos proponemos explorar algunas de las tendencias y temas clave<\/b> que captaron nuestra atenci\u00f3n durante este destacado evento.\u00a0<\/p>\n

El a\u00f1o pasado nos despedimos de la KubeCon 2022 de Valencia descubriendo las capacidades que convert\u00edan al Gateway API como un API oficial<\/b>, graduado de incubaci\u00f3n a beta, simplificando el modelo de service networking en Kubernetes, incluyendo nuevos objetos como GatewayClass, Gateway, HTTPRoute, TCPRoute, etc.\u00a0<\/p>\n

El Gateway API es un proyecto mantenido por el SIG de Networking, en continua evoluci\u00f3n, y este a\u00f1o empezamos la KubeCon 2023, esta vez en Amsterdam, justo donde lo dejamos el a\u00f1o pasado, con las novedades que nos trae este grupo de trabajo sobre la evoluci\u00f3n del Gateway API, graduado de Beta a GA, incluyendo las capacidades de Multi-Cluster Services<\/i>.\u00a0\u00a0<\/p>\n

Sin lugar a dudas, uno de los temas principales en los \u00faltimos d\u00edas ha sido c\u00f3mo se pueden desplegar aplicaciones en<\/b> plataformas Multi-Cluster<\/b>, mejorando la disponibilidad y reduciendo la latencia. Hace un tiempo, la sincronizaci\u00f3n de clusters era una tarea complicada, que podr\u00eda llegar a requerir cierto trabajo manual dependiendo del entorno en que trabajemos.<\/p>\n

Afortunadamente, mediante la evoluci\u00f3n de las APIs de Kubernetes, podemos simplificar este problema con el Gateway API haciendo uso de los servicios de Multi-Cluster, habilitando la gesti\u00f3n avanzada del routing<\/i> entre diferentes clusters.\u00a0<\/p>\n

Este caso de uso nos permite abordar situaciones donde tenemos una falla catastr\u00f3fica, como la p\u00e9rdida de una regi\u00f3n o zona de computaci\u00f3n, en la cual est\u00e1n localizadas las m\u00e1quinas que ejecutan nuestras aplicaciones, ofreciendo una conmutaci\u00f3n instant\u00e1nea del tr\u00e1fico de un cluster a otro.\u00a0<\/p>\n

Si, por ejemplo, tenemos una sistema ejecutando para USA y Europa a la vez, podemos elegir a d\u00f3nde redirigir la carga de trabajo: de forma local a los or\u00edgenes de tr\u00e1fico, minimizando la latencia, y usar la otra regi\u00f3n del mundo para ser resilientes.<\/p>\n

La uni\u00f3n de varias APIs de Kubernetes no abre nuevas oportunidades para lograr nuestros objetivos, aunque todav\u00eda estamos en los primeros pasos de estos proyectos, os animamos a que os pong\u00e1is al d\u00eda con alguna de sus implementaciones[1]<\/a>.<\/p>\n

En la edici\u00f3n del a\u00f1o pasado vimos como uno de los principales temas de inter\u00e9s fue la orquestaci\u00f3n de cargas de trabajo mediante t\u00e9cnica de <\/b>Advanced Scheduling<\/i><\/b>. Trabajar en el \u00e1mbito big data es siempre un reto, pero si a\u00f1adimos kubernetes, se abre la oportunidad de emplear otros paradigmas que coordinan pods para realizar trabajos individuales.<\/p>\n

Si tradicionalmente nos encontramos ante falta de recursos como principal fuente de problemas, en kubernetes tambi\u00e9n se pueden generar problemas de inanici\u00f3n debido al scheduler original, sin olvidar c\u00f3mo gestionar el sistema de shuffle de datos entre los ejecutores de las aplicaciones.\u00a0<\/p>\n

Uno de los puntos m\u00e1s relevantes y cr\u00edticos es la parte de monitorizaci\u00f3n y observabilidad.<\/b> Buena parte de las ponencias giran en torno a estos dos \u00e1mbitos debido a la necesidad de las organizaciones de conocer en tiempo real el estado del cluster, servicios y despliegues.<\/p>\n

Tambi\u00e9n este a\u00f1o, con la explosi\u00f3n de las plataformas multi-cluster<\/b> llega un nuevo reto, monitorizar y centralizar todas las m\u00e9tricas de tus distintos clusters<\/b> para mantener la integridad de tu arquitectura. Para esto vienen viejos conocidos como Prometheus, Grafana, Thanos, Cortex, etc. para resolver esta problem\u00e1tica.\u00a0<\/p>\n

Adem\u00e1s, cada vez se hace m\u00e1s \u00e9nfasis en la monitorizaci\u00f3n y alertado defensivo<\/b>, es decir, como usar tus herramientas para saber cu\u00e1ndo, c\u00f3mo y d\u00f3nde est\u00e1s recibiendo alg\u00fan ataque en tu plataforma, ya sea un ataque DDoS, ataques por inyecci\u00f3n de SQL o hasta analizar el consumo de tus propios pods por si hubiera alg\u00fan consumo elevado que pudiera ser por un posible crypto-mining.<\/p>\n

Para esto cada vez la monitorizaci\u00f3n va m\u00e1s de la mano de la anal\u00edtica de datos y anal\u00edtica avanzada para buscar patrones en las m\u00e9tricas de tu plataforma y poder evitar cualquier tipo de fallo o incidencia.<\/p>\n

La uni\u00f3n de Monitorizaci\u00f3n y Seguridad<\/b> no solo se percibe en la evoluci\u00f3n de los proyectos del CNCF, sino tambi\u00e9n en c\u00f3mo afecta a las organizaciones. Este a\u00f1o destaca c\u00f3mo las organizaciones comienzan a adoptar un modelo de gesti\u00f3n donde un equipo dedicado\u00a0 acumula cada vez m\u00e1s tareas, como revisar el control de acceso de los usuarios<\/b>,\u00a0 gestionar la asignaci\u00f3n de las pol\u00edticas de seguridad<\/b>, revisar el rendimiento de la infraestructura<\/b> de datos u otras tareas seg\u00fan la organizaci\u00f3n.<\/p>\n

No quer\u00edamos terminar la experiencia sin hablar de la nueva tecnolog\u00eda que est\u00e1 oculta actualmente en varios proyectos de la CNCF: \u201c<\/b>extended Berkeley Packet Filter<\/i><\/b>\u201d (eBPF)<\/b>[2<\/a>].<\/p>\n

El origen de esta tecnolog\u00eda recae en el grupo de trabajo de tcpdump, donde se desarroll\u00f3 para analizar el tr\u00e1fico de red sin impactar en el rendimiento de las aplicaciones. Sin embargo, se ha visto claramente extendido su uso en t\u00e9rminos de seguridad y monitorizaci\u00f3n.\u00a0<\/p>\n

A modo resumen, eBPF permite ejecutar un c\u00f3digo de usuario a nivel de <\/b>kernel-space<\/i><\/b>, teniendo acceso a las estructuras de memoria sin restricciones<\/b>. Esto se realiza mediante unos hook que tiene programados el propio kernel de linux para habilitar el punto de entrada de la funci\u00f3n.<\/p>\n

eBPF requiere un kernel moderno, puesto que es una tecnolog\u00eda en incubaci\u00f3n, siendo incluso posible que un mismo programa no llegue a funcionar entre diferentes sistemas operativos debido a las modificaciones que est\u00e1 realizando del propio kernel, a\u00fan con ello os animamos a explorar su utilidad.\u00a0<\/p>\n

Conclusiones<\/h2>\n