Durante el evento KubeCon EU, que se celebra esta semana en Barcelona del día 20 al 23 de mayo, Microsoft ha anunciado novedades relacionadas con el estándar Kubernetes de Google (aunque se trata de una tecnología de código abierto), entre las que destaca la versión 3 de Helm, la integración de Kubernetes con Visual Studio Code (VS Code), la versión 1.0 del proyecto Virtual Kubelet, el Service Mesh Interface (SMI) y el nuevo proyecto de la comunidad para la colaboración en torno a la infraestructura Service Mesh.

Helm 3

Posiblemente, el hito más importante para la comunidad de Kubernetes es la primera versión Alpha de Helm 3, que presenta una re-factorización casi completa del gestor de paquetes de Helm para convertirse en un moderno gestor de paquetes de aplicaciones. El proyecto Helm es prácticamente tan antiguo como el propio Kubernetes y su diseño original fue anterior a muchos de los avances propios de Kubernetes, entre ellos CustomResourceDefinitions e incluso el Control de Acceso Basado en Roles (Kubernetes RBAC). Debido a esto, la arquitectura de Helm 2 se vio obligada a implementar una serie de características por su cuenta, lo que la hizo menos integrada con Kubernetes, y significó que la gestión de cosas como el RBAC de Charts y Resources era complicada y estaba desconectada de la de la propia Kubernetes. Según Microsoft, Helm 3 permite un salto cualitativo en este sentido.

Al reemplazar las APIs personalizadas para charts y despliegues con CustomResourceDefinitions, funcionalidades como RBAC se aplican directamente a Helm, de forma que todo el sistema da un salto cualitativo en términos de integración y es nativo de Kubernetes. Gracias a ello, ahora se puede utilizar por línea de comando ‘kubectl’ para interactuar con charts de Helm, y el Control de Acceso Basado en Roles nativo de Kubernetes para limitar el acceso y los recursos que los usuarios pueden crear.

Helm se ha convertido en el estándar de facto para empaquetar y desplegar las aplicaciones de Kubernetes, centrándose en el usuario final y facilitando que estos tengan éxito. Los avances y mejoras que incluye Helm 3 siguen esta tendencia y lo hacen aún más útil, tanto para los que ya lo utilizan, como para otros usuarios que han probado otras soluciones.

Extensión de Kubernetes para el editor de código de Visual Studio

Microsoft asegura que ha trabajado estrechamente con el equipo responsable de la extensión de código abierto Kubernetes para Visual Studio Code. Esta extensión lleva la integración nativa de Kubernetes al código de Visual Studio, de forma que se puede ver fácilmente el contenido de un clúster, comprobar el estado de los Pods de un vistazo, hacer clic con el botón derecho del ratón para obtener un terminal en un Pod o configurar una redirección de puertos de red, y filtrar fácilmente los registros para identificar problemas, todo ello dentro del mismo entorno en el que está alojado el código.

Además, la extensión es de código abierto en GitHub y funciona con Kubernetes en cualquier lugar. No importa dónde se esté ejecutando Kubernetes, la integración con Visual Studio Code hace que sea más fácil trabajar con las aplicaciones y clusters con menos ventanas y cambios de contexto.

Microsoft ha anunciado en Kubecon que su integración de VS Code ha alcanzado la versión 1.0 y está totalmente soportada para gestionar la producción de clústeres de Kubernetes. Además, también se ha incorporado una API de extensibilidad completa que hace posible que terceras partes, como Red Hat OpenShift, creen sus propias experiencias de integración sobre la base proporcionada por Microsoft. Al igual que los Custom Resources, añadir extensibilidad permite la colaboración en el núcleo, al mismo tiempo que permite que otros construyan experiencias enriquecidas dirigidas a entornos específicos. Es un ejemplo del valor de un enfoque abierto y extensible de las herramientas.

Virtual Kubelet 1.0

Otro de los anuncios del desarrollador es la versión 1.0 de Virtual Kubelet, que representa una integración única de Kubernetes y tecnologías de contenedores serverless, como Azure Container Instances. Permitir a los profesionales liberarse del trabajo de administrar un sistema operativo, mientras que todavía utilizan Kubernetes para la configuración, es una poderosa propuesta de valor tanto para las startups como para las grandes empresas.

A la pujante comunidad de usuarios y al destacado papel de Azure se suman a los anuncios realizados a principios de este mes en Build, la conferencia anual de desarrolladores de Microsoft, entre los que destaca el lanzamiento de los nodos virtuales AKS, impulsados por el Proyecto Virtual Kubelet. Todo ello pone de manifiesto el valor del Código abierto, incluso cuando se trabaja con funcionalidades estrechamente integradas para Azure.

Service Mesh Interface (SMI)

Por último, Microsoft ha destacado la creciente comunidad que se está desarrollando en torno a la especificación Service Mesh Interface. Durante un tiempo, la compañía ha tenido constancia de que los usuarios y clientes estaban satisfechos con la propuesta de Service Mesh, ya que les proporcionaba los avances necesarios para el desarrollo de aplicaciones nativas de la nube. Sin embargo, también ha comprobado que la integración monolítica de la interfaz y la implementación que existía anteriormente para Service Mesh ha limitado su adopción.

Los entornos Service Mesh o malla de servicios están evolucionando muy rápido y a los usuarios les preocupa que, al apostar por una implementación en particular, puedan quedar “atrapados”. Al ofrecer una interfaz de API genérica, que posteriormente puede implementarse por varios proveedores de Service Mesh, como Istio, Linkerd y Consul Connect, la interfaz libera a los usuarios para utilizar sus capacidades sin estar sujetos a ninguna implementación concreta.

Esto significa que son libres de experimentar e incluso cambiar implantaciones sin tener que cambiar sus aplicaciones. Una cuestión que favorece que Service Mesh esté a la par con otras partes de Kubernetes, como Ingress, Container Runtime (CRI) y Networking (CNI), que tienen interfaces genéricas con implementaciones modulares. Microsoft asegura que ha trabajado con partners en el desarrollo de SMI y espera construir una comunidad aún mayor a medida que avance y reitere en su especificación. SMI es un proyecto abierto iniciado con la colaboración de Microsoft, Linkerd, HashiCorp, Solo, Kinvolk y Weaveworks, que también ha contado con el apoyo de Aspen Mesh, Canonical, Docker, Pivotal, Rancher, Red Hat y VMware.

About Author

Periodista especializado con más de 18 años de experiencia en tecnología. He sido director de publicaciones como Macworld (dedicada al mundo Apple) o TechStyle (dedicada a electrónica de consumo) y después he trabajado con TICbeat.com como responsable de desarrollo de producto, como Chief Content Officer en GlobbTV y es editor de Tech4Fun (http://tech4fun.es).

Leave A Reply