Adivinación

Kubernetes ya ha jugado un papel importante en mi trabajo, y en el futuro será aún más importante. Pero 2018 está llegando a su fin, así que olvídate de la modestia y haz una predicción audaz:

El futuro de Kubernetes son las máquinas virtuales, no los contenedores.

Según el horóscopo chino, 2018 fue el año del perro, pero en tecnología fue el año de Kubernetes. Muchos acaban de aprender sobre esta tecnología revolucionaria, y los departamentos de TI de todas partes están tratando de desarrollar una "estrategia de Kubernetes" [1]. Algunas organizaciones ya han transferido grandes cargas de trabajo a Kubernetes.

[1] Si está intentando desarrollar una estrategia de Kubernetes, ya ha fallado, pero este es un tema para otro artículo.

En otras palabras, hay mucha gente en Kubernetes en cada paso del Ciclo Gartner Sensation. Algunos están atrapados en un vacío de decepción o ahogados en un pozo de desesperación.


Jeremykemp, Wikipedia . Creative Commons CC BY-SA 3.0

Soy un gran admirador de los contenedores y no diré que los contenedores están muertos . En 2013, Docker nos dio un shell para Linux Containers: una nueva y sorprendente forma de construir, empaquetar, compartir e implementar aplicaciones. Apareció en el momento adecuado, ya que comenzamos a tomarnos en serio la entrega continua. Su modelo se convirtió en ideal para la cadena de entrega y contribuyó a la aparición de la plataforma PaaS, y luego CaaS.



Los ingenieros de Google vieron que la comunidad de TI finalmente estaba lista para los contenedores. Google ha estado utilizando contenedores durante mucho tiempo y, en cierto sentido, pueden considerarse los inventores de la contenedorización. Comenzaron a desarrollar Kubernetes. Como saben ahora, esta es la reencarnación gratuita de la plataforma Borg de Google.

Pronto, el soporte para Kubernetes fue proporcionado por todas las nubes grandes (GKE, AKS, EKS). Los servicios en las instalaciones también aumentaron rápidamente las plataformas basadas en Kubernetes (Pivotal Container Service, Openshift, etc.).

Soft multi-tenancy

Era necesario resolver un problema molesto, que puede considerarse la falta de contenedores ... esto es la tenencia múltiple.

Los contenedores de Linux no se crearon como cajas de seguridad (como Solaris Zones o FreeBSD Jails). En cambio, se basaron en un modelo de kernel común que utiliza funciones de kernel para proporcionar un aislamiento básico del proceso. Como diría Jesse Frazel , "los contenedores no son reales".


Esto se ve agravado por el hecho de que la mayoría de los componentes de Kubernetes no conocen a los inquilinos. Por supuesto, tiene espacios de nombres Pod y políticas de seguridad , pero no existe tal cosa en la API. Así como en componentes internos como kubelet o kube-proxy . Esto lleva al hecho de que Kubernetes implementa el modelo de "renta suave" (arrendamiento suave).


Arquitectura Kubernetes

Las abstracciones se filtran aún más. Una plataforma en la parte superior de los contenedores hereda muchos aspectos de la renta blanda. Las plataformas en la parte superior de las máquinas virtuales de múltiples inquilinos heredan este arriendo difícil (VMware, Amazon Web Services, OpenStack, etc.).

El modelo de alquiler suave de Kubernetes coloca a los proveedores de servicios y distribuciones en una posición extraña. El grupo de Kubernetes se está convirtiendo en una línea de "renta dura". Incluso dentro de la misma organización, hay muchas razones para exigir una renta dura entre los usuarios (o aplicaciones). Debido a que las nubes públicas proporcionan Kubernetes completamente administrado como un servicio, es fácil para los clientes tomar su propio clúster y usar el límite del clúster como punto de aislamiento.

Algunas distribuciones de Kubernetes, como el Pivotal Container Service (PKS) , son conscientes de este problema de alquiler y utilizan un modelo similar, proporcionando el mismo Kubernetes como un servicio que se puede obtener de una nube pública, pero en su propio centro de datos.

Esto condujo a la aparición del modelo de "muchos grupos", en lugar de "un gran grupo común". A menudo, los clientes de GKE de Google tienen docenas de clústeres de Kubernetes implementados para múltiples equipos. A menudo, cada desarrollador obtiene su propio clúster. Este comportamiento genera una cantidad sorprendente de instancias (Kubesprawl).

Alternativamente, los operadores crean sus propios grupos de Kubernetes en sus propios centros de datos para asumir un trabajo adicional para administrar múltiples grupos, o acuerdan arrendar uno o dos grupos grandes suavemente.

Por lo general, el clúster más pequeño es de cuatro máquinas (o máquinas virtuales). Uno (o tres para HA) para Kubernetes Master, tres para Kubernetes Workers. Se gasta mucho dinero en sistemas que en su mayor parte están inactivos.

Por lo tanto, debe mover a Kubernetes de alguna manera hacia un multicliente rígido. La comunidad de Kubernetes es muy consciente de esta necesidad. Ya se ha formado un grupo de trabajo de arrendamiento múltiple . Ella está trabajando duro en este tema, y ​​tienen varios modelos y sugerencias sobre cómo trabajar con cada modelo.

Jesse Frazel escribió una publicación de blog sobre este tema, y ​​es genial porque es mucho más inteligente que yo, por lo que puedo referirme a ella y salvarme de diez años de estudio intenso, tratando de alcanzar su nivel. Si no ha leído esa publicación, léala ahora.

Solo máquinas virtuales muy pequeñas optimizadas para la velocidad ...

Kata Containers es un proyecto de código abierto y una comunidad que trabaja para crear una implementación estándar de máquinas virtuales livianas que se vean y funcionen como contenedores pero que brinden aislamiento de la carga de trabajo y beneficios de seguridad de VM.

Jesse sugiere utilizar la tecnología de contenedor VM, como los contenedores Kata . Ofrecen aislamiento a nivel de VM, pero funcionan como contenedores. Esto permite a Kubernetes dar a cada "inquilino" (asumimos el inquilino en el espacio de nombres) su propio conjunto de servicios del sistema Kubernetes que se ejecutan en contenedores de máquinas virtuales anidados (el contenedor de máquinas virtuales dentro de la máquina virtual que proporciona la infraestructura de IaaS).


Imagen de Jesse Frasel: multiusuario duro en Kubernetes

Esta es una elegante solución de alquiler múltiple de Kubernetes. Su propuesta va aún más allá para que Kubernetes use contenedores VM anidados para cargas de trabajo (Pods) que se ejecutan en Kubernetes, lo que proporciona un aumento significativo en la utilización de recursos.

Nos queda al menos una optimización más. Cree el hipervisor adecuado para el proveedor de infraestructura subyacente o el proveedor de la nube. Si el contenedor de VM es una abstracción de primer nivel proporcionada por IaaS, aumentaremos aún más la utilización de recursos. El número mínimo de máquinas virtuales para iniciar un clúster de Kubernetes se reduce a una máquina (o tres para HA) para alojar el sistema de administración de Kubernetes, que está disponible para el "superusuario".

Multi-arrendamiento optimizado de recursos (costo)

Una implementación de Kubernetes con dos espacios de nombres y varias aplicaciones en ejecución se verá así:

Nota: hay otras cargas en la misma infraestructura de IaaS. Como se trata de contenedores de máquinas virtuales, tienen el mismo nivel de aislamiento que las máquinas virtuales en la nube convencionales. Por lo tanto, pueden trabajar en el mismo hipervisor con un riesgo mínimo.

Inicialmente, no se implementa infraestructura en la nube, por lo que para un superusuario los costos son cero.

Un superusuario solicita un clúster de Kubernetes desde la nube. El proveedor de servicios en la nube crea una máquina virtual con un contenedor (o tres para HA) que ejecuta las API centrales de Kubernetes y los servicios del sistema. El superusuario puede implementar módulos en el espacio de nombres del sistema o crear nuevos espacios para delegar el acceso a otros usuarios.

Superuser crea dos espacios de nombres foo y bar . Kubernetes solicita dos contenedores de VM de la nube para cada nivel de gestión de espacio de nombres (API de Kubernetes y servicios del sistema). El superusuario delega el acceso a estos espacios de nombres a algunos usuarios, cada uno de ellos lanza algunas cargas de trabajo (módulos) y los contenedores de VM solicitan estos contenedores para estas cargas de trabajo.

En todas las etapas, el superusuario paga solo por los recursos realmente consumidos. El proveedor de servicios en la nube controla estos recursos y están disponibles para cualquier usuario de la nube.

Realmente no estoy diciendo nada nuevo ...

Los proveedores de servicios en la nube ya están trabajando en esta dirección. Puede verificar esto mirando los eventos de la comunidad (es posible que Amazon ya lo haya hecho en silencio con Fargate).

El primer consejo es Virtual Kubelet , una herramienta de código abierto diseñada para disfrazarse de kubelet. Conecta Kubernetes a otras API, lo que permite a Kubernetes solicitar contenedores VM desde un planificador estándar en la nube.

Otros consejos son una gran cantidad de nuevas tecnologías para la contenedorización de máquinas virtuales , como los contenedores Kata ya mencionados, así como el Firecracker de Amazon y el asesor de Google.

Conclusión

Si implementa correctamente las mejoras en el modelo de una renta dura, encontrará la virtualización del Santo Grial de Kubernetes. Aislamiento completo de las cargas de trabajo y sin costos adicionales.

Si no utiliza la nube pública, aún obtiene los beneficios de una mayor utilización de recursos, lo que vale la pena con menores requisitos de hardware.

Esperemos que VMware y OpenStack presten atención y publiquen hipervisores basados ​​en contenedores ligeros de VM y las implementaciones de Virtual Kubelet correspondientes.