02 Jun 2020

Como sabrán, en noviembre pasado Mirantis adquirió el negocio Docker Enterprise de Docker, Inc., y , como imaginarán desde entonces han estado, bastante ocupados! Los equipos de Mirantis y Docker han estado integrando sus esfuerzos y combinando lo mejor de ambos mundos para resultar en los mejores productos, servicios y soporte que se puede brindar a los clientes.

Seis meses después, Mirantis se enorgullece de anunciar el “General Avalaibility” de Docker Enterprise 3.1, con nuevas características que te permiten mejorar aún más tu juego de Kubernetes. Esta nueva versión incluye muchas características nuevas, entre las cuales:

  • K8s en Windows
  • Soporte de GPU
  • Istio Ingress
  • Nuevo “UCP Installer”
  • Upgrade a K8s 1.17

Hagamos un repaso de que significa todo esto.

(ver el anuncio en: https://www.mirantis.com/blog/announcing-docker-enterprise-3-1-general-availability/ )

Kubernetes on Windows

Desde el principio, Kubernetes ha sido un proyecto extremadamente centrado en Linux, lo cual es comprensible, ya que los contenedores evolucionaron a partir de desarrolladores de la comunidad Linux como cgroups. Pero, ¿en qué difiere esto para los desarrolladores de Windows, siendo que después de todo, Docker se ejecuta en Windows y hace posible ejecutar contenedores de Linux también (aunque usando virtualización).

En las últimas versiones de Kubernetes, la comunidad ha estado trabajando en la capacidad de ejecutar en Windows, y con Docker Enterprise 3.1, ahora se suma la capacidad de unir fácilmente Workers Windows a un clúster de Kubernetes y administrarlos como lo haría con la administración tradicional Nodos de Linux desde la UCP (Universal Control Plane).

La capacidad de orquestar “Containers” basados en Windows permite a las organizaciones aprovechar la amplia disponibilidad de imágenes existentes con formatos Windows (docker hub), tanto para el desarrollo de nuevas aplicaciones como para la modernización de las existentes. Este Proporciona un camino relativamente fácil para “contenerizar” y operar aplicaciones de Windows de misión crítica (incluso heredadas) en un entorno que mejora la disponibilidad y facilita el “scale”, manteniendo la administración de la infraestructura subyacente a través de políticas, herramientas y opciones familiares orientadas a Windows. Por supuesto, también libera a los usuarios para explotar Azure Stack y / u otras plataformas en la nube que ofrecen infraestructura virtual y básica de Windows Server, el entorno Multi Cloud para la aplicación.

Soporte de GPU

Hubo un tiempo en que las “Graphic Processing Units” (GPU) eran solo para juegos, pero ese tiempo ya pasó; ahora son una parte esencial para realizar eficientemente los pesados cálculos que se están convirtiendo cada vez más en parte de la vida empresarial. Incluso antes de que el Machine Learning y la Inteligencia Artificial aparecieran en el radar empresarial, las grandes corporaciones tenían operaciones de “Data Mining” que los habían preparado para la próxima batalla.

Docker Enterprise 3.1 con Kubernetes 1.17 hace fácil el agregar un “Worker Node” con capacidades de GPU de manera estándar a los clústeres de Kubernetes. Con unos pocos pasos y fácilmente automatizados se puede configurar el nodo (Linux), ya sea antes o después de unirlo a Docker Enterprise, y luego, el Servicio Docker Kubernetes reconoce automáticamente al nodo como habilitado para GPU, y los Deploys que lo necesiten o puedan llegar a usar esta capacidad pueden ser “taggeados” y configurados para detectarlo.

Esta capacidad complementa la alta variedad cada vez mayor de placas de GPU NVIDIA para el Datacenter (y escritorio), así como la rápida expansión de las opciones de máquinas virtuales equipadas con hardware de GPU de los proveedores de la nube pública. La disponibilidad de la adquisición de GPU y el soporte sólido para GPU estándar a nivel de Container (por ejemplo, en TensorFlow containerizado) está transformando la explotación de nuevas aplicaciones y modelos comerciales, desde AI hasta bioinformática y juegos. Mientras tanto, Kubernetes y los contenedores están haciendo que sea más fácil compartir una GPU relativamente costosa aún, o configurar e implementar en nodos con GPU de la nube según sea necesario, lo que posiblemente permita ahorros, ya que el costo de los nodos de GPU tiende a ser elevado.

Istio Ingress

Cuando se usa Kubernetes, no se quiere exponer todo el clúster al mundo exterior. Lo más seguro es exponer solo la porción del clúster que sea necesario para manejar el tráfico entrante. Idealmente, se desearía poder configurar esta porción y tener una lógica de manejo adicional basada en rutas, encabezados, etc.

Es posible que haya oído hablar de Istio, la aplicación “service mesh” que le brinda un control extremadamente potente y granular del tráfico dentro de las partes de una aplicación descentralizada. Parte de Istio es Istio Ingress, un reemplazo directo para Kubernetes Ingress, que controla el tráfico que ingresa a su clúster. Docker Enterprise 3.1 incluye Istio Ingress, que se puede controlar y configurar directamente desde UCP 3.3.0. Eso significa que puede habilitar o deshabilitar fácilmente el servicio directamente desde la interfaz de usuario o la CLI.

Ver mas..

16 Mar 2020

Al iniciar en el terreno de Containers lo primero que buscamos es utilizar esta herramienta para ejecutar todo lo referente a Stateless, o en síntesis el/los cliente de la base.

Tuvimos un tiempo donde la base era una gran caja en algún lugar. A medida que confiamos en la virtualización trasladamos algunas bases dentro de VMs. Dependiendo la magnitud de las aplicaciones es probable que siga habiendo una gran caja con una base de datos y varias bases más pequeñas en VMs dentro de mi ambiente. Esto es lo que vemos hoy como normal con la virtualización.

Podemos pensar en que en lugar de una VM, la Base sea un Container. Nada nos impide pensar eso. El Container puede vivir en una VM o en un server físico por igual. Dejando por un rato de lado que pasa con el licenciamiento (digamos, no sea que venga Oracle y nos diga.. ah, un container en un nodo de 4 vCPUs en Azure??.. tenés que pagar por todos los cores que tiene Azure en ese Datacenter) ejecutar base de datos en un Container pasa a ser una ejecución casi nativa, es decir si el servidor es físico funcionará como si hubiera instalado localmente en dicho servidor. (ej: SAP HANA TDI, Oracle DB Enterprise, SQL Server for Linux).

Como fuera, creemos que el mayor beneficio lo encontraremos en soluciones modernas como MongoDB o Cassandra, incluso en “sharding” de MySql con Vitess, MariaDB…o Confluent/Kafka, del cual somos parnters. Desde el punto de vista de arquitectura estas soluciones nos darán la libertad de brindar datos en Microservicios con verdadero Scale Out, pero esto requerirá un cambio mayor en nuestras aplicaciones.

Ahora bien, los datos ubicados dentro de la imagen, los filesystems montados desde ahí durante el inicio del container trabajarán en una modalidad que se llama “copy on write”, donde las modificaciones sobre esos filesystem desaparecen al eliminarse el Container. Para que los datos perduren aún cuando el Container se elimine o se re-instancie en otro nodo por decisión de Kubernetes, necesito crear volúmenes persistentes.

De la misma manera que en un Cluster tradicional de Unix/Linux/Windows en el que dos Servers comparten una LUN, deberíamos trasladar esta problemática al Container (Docker) o al Orquestrator (Kubernetes). Para facilitar esta tarea existen los plugins.

Inicialmente estos plugins residían en la herramienta de container (Docker), pero hoy la tendencia es que residan en el orquestador (Kubernetes). VMware, Nutanix, etc.. tienen plugins, pero si este plugin lo ofrece la solución de almacenamiento, nos independizamos de Hypervisor y podemos pensar en ambientes físicos o virtuales por igual.

Hay un estándar emergente y en desarrollo que se llama CSI (Container Storage Interface (CSI) for Kubernetes). Purestorage tiene un esquema de solución para integrarse con Kubernetes mediante este estándar que se denomina Pure Service Orquestrator o PSO. En un ambiente muy grande, con varios racks, varios Storage y Servers por rack, PSO ofrece la funcionalidad mediante políticas de ubicar los datos y workloads acorde a la ubicación en el datacenter. (Pure Service Orchestrator).

En nuestra búsqueda de productos para entornos de microservicios en containers, vimos a Purestorage como un aliado de valor.