Por qué Kubernetes en la nube no es tan independiente del proveedor como parece y qué hacer al respecto

F5

Kubernetes es una plataforma de código abierto. Por tanto, podría pensarse que es una plataforma independiente del proveedor, lo que significa que se puede migrar fácilmente de una implementación de Kubernetes a otra.

Pero te equivocarías. La realidad es que muchas soluciones de Kubernetes —en particular, las vinculadas a una nube pública específica— son mucho menos independientes del proveedor de lo que podrías pensar.

Afortunadamente, esto no significa que no puedas aprovechar la nube pública como solución de alojamiento de Kubernetes si quieres evitar la dependencia de un proveedor. Puedes hacerlo, pero debes diseñar tu estrategia de Kubernetes de forma que no quedes vinculado al servicio de Kubernetes de un proveedor de nube concreto y, al mismo tiempo, puedas disfrutar de las ventajas de Kubernetes en la nube.

Opciones de Kubernetes en la nube

Hoy en día, todos los principales proveedores de nube pública ofrecen servicios de Kubernetes alojados mediante una arquitectura SaaS. Amazon cuenta con Elastic Kubernetes Service. Azure ofrece Azure Kubernetes Service. Google ofrece Google Kubernetes Engine. IBM cuenta con IBM Cloud Kubernetes Service.

Dado que estos servicios combinan una infraestructura basada en la nube con software que ayuda a automatizar el despliegue y la gestión de Kubernetes, constituyen una solución atractiva para las organizaciones que desean empezar a utilizar Kubernetes rápidamente.

Riesgos de dependencia de un proveedor en Kubernetes en la nube

El hecho de que estos servicios de Kubernetes en la nube parezcan independientes del proveedor también aumenta su atractivo. A primera vista, puede parecer que sería bastante fácil migrar de una plataforma SaaS de Kubernetes a otra. Todas estas plataformas se basan en la versión estándar y de código abierto de Kubernetes. Proporcionan acceso a las mismas herramientas de Kubernetes (como kubectl) y, por lo general, admiten los mismos tipos de configuraciones de almacenamiento y red. Desde esta perspectiva, parecen bastante independientes del proveedor.

Sin embargo, al profundizar, se observa que las nubes públicas que ofrecen Kubernetes como servicio alojado no son tan flexibles ni genéricas como podrían parecer. Se integran con otros servicios que se ejecutan en las nubes públicas que las alojan y dependen de ellos de diversas formas. Para gestionar los clústeres de Kubernetes, es necesario crear políticas de IAM en la nube que se utilice. Es posible que se acaben utilizando servicios específicos del proveedor para la autenticación, como Azure Active Directory en el caso de Azure Kubernetes Service. Además, en muchos casos, los servicios de Kubernetes recomiendan utilizar herramientas complementarias o alternativas, aunque no sean estrictamente obligatorias. Por ejemplo, Google Kubernetes Engine recomienda usar gke-deploy en lugar de kubectl, mientras que Elastic Kubernetes Service está diseñado para utilizarse con eksctl, la herramienta propietaria de Amazon.

Así pues, aunque el código subyacente de Kubernetes sea el mismo independientemente de la nube que utilice para alojarlo y, técnicamente, pueda limitarse a usar herramientas genéricas si se empeña, lo más probable es que las herramientas y configuraciones que acabe utilizando no sean independientes del proveedor. Serán específicas del servicio de Kubernetes que utilice.

Esto supone un obstáculo importante si, por ejemplo, quieres migrar de Azure Kubernetes Service a Google Kubernetes Engine. Aunque puedas trasladar tus cargas de trabajo de Kubernetes sin modificarlas, no puedes hacer lo mismo con las cadenas de herramientas y los archivos de configuración que las sustentan.

Evita la dependencia de un proveedor de Kubernetes en la nube

Si quiere aprovechar la comodidad y la escalabilidad de la nube pública al desplegar clústeres de Kubernetes, pero quiere evitar la dependencia de un proveedor, existen dos soluciones básicas.

Una opción es configurar manualmente tus propios clústeres mediante máquinas virtuales en la nube y gestionarlos por tu cuenta. Con este enfoque, no dispones de la automatización ni de las integraciones que ofrecen las soluciones SaaS de Kubernetes de los proveedores de servicios en la nube, pero sigues teniendo acceso a la infraestructura. Como no utilizas herramientas especializadas, resulta más fácil migrar tus clústeres de un proveedor de alojamiento en la nube a otro sin tener que reconstruirlo todo. Por supuesto, el inconveniente es que configurar y gestionar los clústeres requiere una cantidad considerable de trabajo manual.

El otro enfoque, más automatizado y escalable, consiste en utilizar una solución como el servicio VoltStack® de Volterra para gestionar sus clústeres, independientemente de las nubes en las que se encuentren. Con esta estrategia, básicamente se sustituyen las herramientas específicas para la nube de la plataforma de cada proveedor por un centro de mando y control centralizado que funciona con cualquier nube pública, lo que facilita la migración o replicación de clústeres entre distintas nubes públicas. Se obtiene la misma capacidad de gestión que ofrecen servicios como Google Kubernetes Engine y Azure Kubernetes Engine, pero sin quedar vinculado a nubes públicas específicas.

Conclusión

No cometa el error de dar por sentado que Kubernetes es igual independientemente de dónde o cómo se ejecute. Existen diferencias importantes entre los distintos servicios de Kubernetes basados en la nube, lo que puede dificultar la portabilidad de los clústeres de Kubernetes de una nube a otra (por no mencionar que complica la gestión de clústeres en distintas nubes, ya que cada una dispone de un conjunto de herramientas diferente).

La buena noticia es que existe una solución: al utilizar una solución de gestión de Kubernetes independiente de la nube, como el servicio VoltStack de Volterra, para gestionar todos sus clústeres, evita depender de un proveedor de nube concreto sin renunciar a la facilidad de uso de Kubernetes en la nube.

Sobre el autor

F5

Más artículos de F5