Por qué Cloud Kubernetes no es tan independiente del proveedor como parece y qué hacer al respecto
Kubernetes es una plataforma de código abierto. Se podría pensar, entonces, que se trata de una plataforma independiente del proveedor, lo que significa que se puede migrar fácilmente de una implementación de Kubernetes a otra.
Pero estarías equivocado. La realidad es que muchas soluciones de Kubernetes (en particular, aquellas que están vinculadas a una nube pública específica) son mucho menos independientes del proveedor de lo que se podría pensar.
Afortunadamente, esto no significa que no puedas aprovechar la nube pública como una solución de alojamiento de Kubernetes si quieres evitar el bloqueo. Puede hacerlo, pero debe diseñar su estrategia de Kubernetes de manera tal que no quede limitado al servicio de Kubernetes de un proveedor de nube en particular y al mismo tiempo le permita disfrutar de las ventajas de Kubernetes basado en la nube.
Opciones de Kubernetes basadas en la nube
Hoy en día, todas las principales nubes públicas ofrecen servicios de Kubernetes alojados a través de una arquitectura SaaS. Amazon tiene el servicio Elastic Kubernetes. Azure proporciona el servicio Azure Kubernetes. Google ofrece Google Kubernetes Engine. IBM tiene IBM Cloud Kubernetes Service.
Debido a que estos servicios combinan una infraestructura basada en la nube con un software que ayuda a automatizar la implementación y la gestión de Kubernetes, son una solución atractiva para las organizaciones que buscan comenzar a trabajar rápidamente con Kubernetes.
Riesgos de bloqueo de Kubernetes en la nube
El hecho de que estos servicios de Kubernetes en la nube parezcan agnósticos también aumenta su atractivo. A primera vista, podría parecer que sería bastante fácil pasar de una plataforma SaaS de Kubernetes a otra. Todas estas plataformas se basan en Kubernetes estándar de código abierto. Proporcionan acceso a las mismas herramientas de Kubernetes (como kubectl) y generalmente admiten los mismos tipos de configuraciones de almacenamiento y red. Desde esta perspectiva, parecen bastante independientes del proveedor.
Sin embargo, cuando profundizas más, te das cuenta de que las nubes públicas que ofrecen Kubernetes como servicio alojado no son tan flexibles ni genéricas como pueden parecer. Se integran y dependen de diversas maneras de otros servicios que se ejecutan en las nubes públicas que los alojan. Debes crear políticas de IAM en cualquier nube que uses para administrar tus clústeres de Kubernetes. Es posible que termines usando servicios específicos del proveedor, como Azure Active Directory en el caso de Azure Kubernetes Service, para la autenticación. Y en muchos casos, existen herramientas complementarias o de reemplazo que los servicios de Kubernetes prefieren que utilices, incluso si no las requieren estrictamente. Google Kubernetes Engine quiere que uses gke-deploy en lugar de kubectl, por ejemplo, mientras que Elastic Kubernetes Service está diseñado para usarse con eksctl, la herramienta propietaria de Amazon.
Por lo tanto, si bien el código subyacente de Kubernetes puede ser el mismo sin importar qué nube use para alojar Kubernetes, y si bien técnicamente podría quedarse con herramientas genéricas si realmente lo intentara, las herramientas y configuraciones que probablemente terminará usando no son independientes del proveedor. Son específicos del servicio de Kubernetes que utilice.
Eso crea una barrera importante si desea migrar, por ejemplo, de Azure Kubernetes Service a Google Kubernetes Engine. Incluso si puede levantar y cambiar sus cargas de trabajo de Kubernetes, no puede hacer lo mismo con las cadenas de herramientas y los archivos de configuración que las respaldan.
Evite el bloqueo de Kubernetes en la nube
Si desea aprovechar la conveniencia y escalabilidad de la nube pública al implementar clústeres de Kubernetes pero no desea quedar atrapado, existen dos soluciones básicas.
Una de ellas es configurar manualmente sus propios clústeres utilizando máquinas virtuales basadas en la nube y luego administrarlos usted mismo. Con este enfoque, no se obtiene la automatización ni las integraciones que vienen con las ofertas SaaS Kubernetes de los proveedores de la nube, pero aún se obtiene la infraestructura. Como no utiliza herramientas especializadas, es más fácil migrar sus clústeres de un host en la nube a otro sin tener que reconstruir todo. Por supuesto, la desventaja aquí es que se requiere una cantidad significativa de esfuerzo manual para configurar y administrar los clústeres.
El otro enfoque, más automatizado y escalable, es utilizar una solución como el servicio VoltStack® de Volterra para administrar sus clústeres, sin importar en qué nubes residan. Con esta estrategia, básicamente reemplaza las herramientas específicas de la nube de la plataforma de cada proveedor con un centro de comando y control centralizado que funciona con cualquier nube pública, lo que facilita la migración o replicación de clústeres entre diferentes nubes públicas. Obtendrá la misma capacidad de administración que obtendría de servicios como Google Kubernetes Engine y Azure Kubernetes Engine sin el bloqueo de nubes públicas específicas.
CONCLUSIÓN
No cometa el error de asumir que Kubernetes es Kubernetes sin importar dónde o cómo lo ejecute. Existen diferencias importantes entre los distintos servicios de Kubernetes basados en la nube, que pueden dificultar la portabilidad de los clústeres de Kubernetes de una nube a otra (sin mencionar que dificultan la administración de clústeres en diferentes nubes, porque cada una tiene un conjunto diferente de herramientas).
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 administrar todos sus clústeres, se libera de la dependencia de un proveedor de nube en particular y, al mismo tiempo, aprovecha la facilidad de uso de Kubernetes basado en la nube.