Amigos de Encora TV, os queremos presentar un nuevo capítulo de Encora Webinars. En este Encora webinar sobre Azure Kubernetes Service (AKS), realizado en abril de 2021 para nuestros clientes, explicamos de la mano de David Marquina, CTO de Encora y Nacho Bellido, TAM & Presales Manager, todo lo que necesitamos saber acerca de los Kubernetes en Azure.
Serie de Encora Webinars sobre contenedores
En el anterior webinar de Introducción a las tecnologías de contenedores, David, nos explicó lo que son las tecnologías de contenedores.
En las tecnologías de contenedores, existe un elemento básico y que nos aporta un pilar adicional a estas tecnologías, los orquestadores.
Estos orquestadores, son lo que nos permite dotar a estos contenedores de una inteligencia y hacer un auto escalado, dotándoles características Enterprise.
En el webinar referenciado hablamos de dos tipos de orquestadores:
1. Openshift de RedHat (ahora IBM) y
2. Kubernetes que es OpenSource.
Retos en la adopción sobre contenedores
Existe una forma de desplegar esta tecnología de Kubernetes con un servicio dentro de un cloud público (la mayoría lo tienen). En el caso de Azure, se llama AKS (Azure Kubernetes Service) viene a ser un poco una forma de simplificar.
La KubeCon es la conferencia anual de usuarios de Kubernetes.
En la KubeCon del 2020, se hizo una encuesta a CIOs que habían ido o que asistían como invitados. En esa encuesta, se les preguntaba, como usuarios de Kubernetes, cuáles eran los retos que se habían encontrado, como empresa, como compañía, como CIO, en cuanto a adoptar Kubernetes como una tecnología sobre la que puedas ejecutar tus aplicaciones.
Los resultados obtenidos fueron bastante reseñables pero la verdad es que también bastante esperables.
La mayoría se encontró que tenía una complejidad operacional bastante alta.
De todos modos, es importantísimo reseñar la segunda, el acceso al talento especializado en la tecnología de Kubernetes. Se refiere a cuando no encuentro a gente que sepa de Kubernetes. Es decir, mis principales problemas son, aparte de migrar las aplicaciones, que ya es normalmente un problema interno, la complejidad operacional y que no tengo a nadie que lo sepa operar.
Azure Kubernetes Service – AKS
La respuesta de los cloud públicos para este problema es, bien, perfecto, nosotros te damos la capa de gestión, la capa de administración, todo el entorno, de una forma automatizada para que tú no tengas que saber de Kubernetes. Tú sólo tienes que ponerlos el contenedor, conectar los nodos de cómputo y nosotros nos encargamos de todo. Así funciona EKS (Amazon), así funciona AKS (Azure) y así funciona GKE (Google).
Básicamente los tres, vienen a ser una capa común y los tres son muy parecidos.
Hay un valor fundamental que hay que resaltar: cuando yo estoy corriendo con un Azure Kubernetes Service, como son estos tres servicios y especialmente AKS, pierdo muchas funcionalidades que tengo en un clúster de Kubernetes on premise, no tanto funciones tecnológicas sino cosas como poder hacer backup, poder parametrizar determinadas cosas, poder personalizar, etc.
Day 2 – Operations
Lo que nos viene a simplificar especialmente una tecnología as a Service, es lo que se llaman las operaciones de día dos. Es decir, tenemos las tecnologías de día cero y de día uno, que consisten en hacer unos requerimientos, hacer toda la arquitectura y lo voy a desplegar. Todo ello, lo tengo que hacer tanto en on premise como en un servicio en Cloud.
En un servicio en Cloud será más sencillo porque no tengo que depender del hardware, pero sigo teniendo que hacer un setup y una instalación. En todo lo que es el día 2, las operaciones, los costes OPEX rutinarios de mantenimiento, de la administración, de preocuparme, etc. esto es lo que nos viene a reducir las operaciones de día 2 y esto es muy importante que lo sepamos.
Todo ello no quiere decir que, con Azure Kubernetes Service pulsemos un botón y se despliegue solo. Ayuda mucho y simplifica mucho, pero es más en el día a día donde nos ayuda.
Arquitectura AKS
Es importante tener clara la arquitectura de Azure Kubernetes Service y cómo se estructura. Qué parte se gestiona por Azure y qué parte administra el cliente final o su partner si existen servicios gestionados en Azure.
Azure nos provee la capa de control plane, que es la capa de administrador y dónde puedo gestionarlo todo.
Lo que tengo que proveer yo son los nodos. Los nodos, en este caso, son instancias virtuales donde ejecutar mis contenedores.
Es cierto que yo a través de un panel de Azure, puedo inyectar en estas instancias el sistema operativo Linux con los demonios y con todo lo que necesitan, pero yo estos nodos los voy contratando aparte.
De hecho, la parte de control plane, es totalmente gratuita, sólo pago por los nodos. Hay unos mínimos que siempre están cubiertos por Microsoft, por Azure.
Tenemos toda una parte de Azure Kubernetes Service lo que nos viene a ofrecer la capa de control plane y luego desplegamos nodos virtuales en modelo Pods sobre los nodos virtuales de Kubernetes que son gestionados por este control plane de Azure Kubernetes Service.
Disponibilidad de AKS
Las ventajas de Azure Kubernetes Service son la disponibilidad y la seguridad del servicio, es decir, este control plane que ofrece Azure en su modelo Azure Kubernetes Service, está gestionado dentro del acuerdo de la Agreement Global de servicios del 99.5% que me ofrece Azure.
Todos los servicios que corren en Azure tienen una pauta general sobre cumplimiento. Da lo mismo que hablemos del sistema de correo, una base de datos en SQL, etc., todos cumplen esos mínimos del Agreement Global de Azure y luego a partir de ahí se pueden mejorar esos porcentajes, contratando un servicio más avanzado.
Según el tipo de servicio o coste que queramos asumir, podemos seleccionar la disponibilidad de ese cómputo. Hay incluso instancias de cómputo que no tienen ningún tipo de SLA, que son muy baratas, pero se apagan en función de la demanda de Azure.
Cuando seleccionar el nodo que vas a utilizar te indica si quieres utilizar un nodo más orientado hacia el cómputo, más orientado hacia el rendimiento, más potenciado en memoria, etc. y en función de eso lógicamente va asociada una familia de instancias, que realmente no tienen grandes requerimientos y, por tanto, en función de la carga del Datacenter, pueden ser trasladadas, no tienen ese SLA, etc.
Es muchísimo más barato y para servicios que no sean críticos, son muy útiles y recomendables. De hecho, Microsoft, las fomenta mucho porque tiene esos picos que no utiliza y que los ofrece a este tipo de servicios que pueden ser muy cómodos.
Anteriormente, hablábamos de que la disponibilidad en una estructura de Kubernetes no consiste en dar muchísima disponibilidad a cada nodo y teniendo pocos nodos, sino teniendo una infraestructura de muchos nodos y muy distribuida. Todo ello nos permite dar la disponibilidad con el volumen y con balanceos de carga.
Por ejemplo podemos tener 20 nodos pequeñitos y sobre esos ejecutar varios Pods con varias aplicaciones. Es preferible esto para la disponibilidad que tener un único.
El concepto Lift and Shift de Azure Kubernetes Service, que consiste en que tu mismo traes el contenedor y Azure ya te da las posibilidades. Inyectas tu contenedor a través de GitHub en el registro, y mientras, yo ya estoy dispuesto para que tú despliegues estos contenedores dentro del Pod en Azure Kubernetes Service y que luego interactúes con el resto.
Algo muy importante e interesante, es la capa de Azure Active Directory. Es todo lo que nos aporta en cuanto a roles.
Existe una parte DevOps en la que puedes conectar el PowerShell directamente con un recurso de GitHub, por tanto, tienes disponibilidad de todos los scripts que estarán subidos, por la línea de comandos para implementarlo en tu entorno. Es súper sencillo de gestionar y de implementar el Lift and Shift.
Implementar el Lift and Shift consiste en coger lo que tienes, paquetizarlo y depositarlo en un sitio que ya está empaquetado.
En cuanto al acceso, más sencillo no puede ser, tenemos Azure Active Directory. Utilizaremos los recursos que ya tenemos, por ejemplo, tenemos Microsoft 365, con eso ya tenemos un Azure Active Directory por detrás, lo conectamos y ya tenemos habilitada la validación de directorio activo para todos nuestros usuarios, es decir, si se van a conectar con las mismas credenciales de Microsoft 365, ya están accediendo a nuestros recursos. No requieren nada más.
No solamente desplegamos Kubernetes, sino que también tengo toda esta arquitectura alrededor donde puedo desplegar servicios.
Licenciamiento de Azure
¿Cómo licenciar? ¿Cómo pagar?
El procedimiento es tan sencillo como:
- Indicar vCPU y vRAM.
- ¿Cuántas máquinas voy a levantar? En este punto, no es tan importante tener una máquina mucho tiempo levantada si no, muchas máquinas las que tienen que estar que forman parte de un mismo cluster.
- ¿Voy a tener datos listos que quiero anexar a las máquinas? Si o no. En principio, lógicamente, habrá que ponerles algún disco para que intercambien información.
- ¿Número de clusters que queremos montar? Uno, dos, tres…
- ¿Qué ventajas tenemos? Las mismas que con cualquier entorno. Podemos usar distancias reservadas, es decir, si vamos a tener ejecutando durante uno o tres años, marcamos la opción. Durante un año, existe una diferencia de precio de un 36% y si lo llevamos a tres años pues alrededor del 56%.
Con esos datos, ya podremos ir arrancando.
Obviamente luego tenemos que configurar si queremos o no acceso de Azure Active Directory. Si lo queremos, marcamos la casilla.
Todo lo que hemos comentado anteriormente, lleva herramientas de gestión.
Hibridación en Azure
En este apartado se enumerarán las herramientas de gestión que se utilizan en cualquier infraestructura de Azure.
Microsoft hace mucho hincapié en su uso. Podemos hibridar los entornos: podemos tener un entorno local on premise, de toda la vida, con nuestro Kubernetes y podemos tener paralelamente el Azure Kubernetes Service. Lo conectamos con un S2S VPN. Con eso ya tenemos tráfico.
Con el Azure Monitor podemos gestionar los flujos de datos (hacia dónde van, de dónde vienen y hacia dónde se dirigen)
El Azure Policy es una parte del acceso de la seguridad, es decir, fijamos políticas de consumo, en función de nuestros usuarios. Le añadimos Azure Policy para controlar dónde está todo y quién accede a qué, si podemos o no podemos generar recursos nuevos o no, etc.
Sobre esto, le añadimos el Azure Security Center (arriba, a la derecha de la diapositiva). Este Azure Security Center, debería ir en prácticamente todos los proyectos de Azure. ¿Por qué?
Security approach en Azure
El Azure Security Center es una herramienta que va a estar escaneando todo el rato el entorno. En ese análisis señalará, por ejemplo, que el entorno está bien, pero te has dejado esto abierto o está bien, pero las políticas que has generado no dejan entrar a nadie o hay fuga de información por este lado, etc.
Todo esto lo podemos añadir junto con el Azure Defender, que al final es el que nos protege dentro de nuestra infraestructura, y le decimos que tenemos un entorno de Kubernetes, con tantos nodos, tantos clústeres, tantas imágenes en los nodos desplegadas y en función de eso, activamos el Defender.
El Defender nos va a proteger todo ese entorno y va a reportar directamente a Azure Security Center para que, desde dentro de una consola, seamos capaces de saber las vulnerabilidades que tenemos, si hay algo que no estamos haciendo correctamente, si estamos infrautilizando los recursos o hemos sobredimensionado nuestro entorno y no tenemos tanta demanda. También podemos tener los accesos y la gestión de los logs y demás.
Además, también avisa de las vulnerabilidades. Es decir, avisa de si tienes que parchear tus propios nodos o de si tienes servicios internos en contenedores que tengan alguna vulnerabilidad, etc., te avisa de todo.
En kubernetes no, pero en proyectos genéricos de Azure, es capaz de avisarte de si tienes abierto el puerto RDP, si tienes abierto puertos muy comunes contra el exterior en los que puedas recibir ataques, etc. Tiene una opción que te permite remediarlo y que te avisa del tiempo que va a tardar en hacerlo y el impacto que puede haber, etc. En este caso tu mismo ya eliges si no lo quieres hacer, si quieres que lo haga de manera proactiva al Security Center o lo quieres implementar tú a mano.
Si decides implementarlo a mano, te da recomendaciones, te da el flujograma de cómo se ataca y te lo deja todo hecho.
Son herramientas muy potentes que tenemos que usarlas siempre en cualquier implementación.
Esta herramienta, además de desplegar Azure Kubernetes Service, se integra con todas las herramientas de la arquitectura de seguridad de despliegue de Policy que tiene Azure. No sólo tenemos un Azure Kubernetes Service, sino que tenemos un Kubernetes enterprise que cuenta con compliance, con seguridad, con gobernanza, etc.
BBDD on K8s
En esta diapositiva nos encontramos con un workflow que resume lo que podemos o no hacer con Kubernetes.
Resuelve dudas como:
- ¿Puedo poner mi base de datos en Kubernetes?
- ¿Puedo poner un Microsoft SQL dentro de contenedores?
- ¿Puedo poner mi base de datos Oracle dentro de contenedores?
Basándonos en lo que contesta la diapositiva, ¿puede mi BD tener características que sean amigables con Kubernetes? Sí o no, si no lo tiene, directamente vete a una máquina virtual o vete a una base de datos, a lo que sería un PaaS (SQL as a Service o un Oracle as a Service, et.).
Si realmente tu base de datos es amigable y se entiende bien con Kubernetes, perfecto.
Esta diapositiva os servirá para llegar a la pregunta importante de ¿lo quiero poner en Kubernetes o no? Porque tendemos a ponerlo todo en contenedores porque parece que es universal y no, espera, hay que aterrizarlo y ver qué evalúa realmente cada carga, si la podemos poner en contenedores o no.
Por ejemplo, con el SQL, ¿tengo que montar siempre una máquina y encima de la máquina virtual montar un SQL y administrar la máquina y el SQL por separado? en todos los casos no será necesario.
En algunos casos será necesario pero también podemos usar una BD completamente gestionada o incluso utilizar IAAS.
Más información sobre Azure (Wikipedia)
Kubernetes (κυβερνήτης, “timonel” o “piloto” en griego) fue fundado por Joe Beda, Brendan Burns y Craig McLuckie , a quienes se les unieron rápidamente otros ingenieros de Google incluyendo a Brian Grant y Tim Hockin, y fue anunciado por Google a mediados de 2014. Su diseño estuvo fuertemente influenciado por el sistema Borg de Google y muchos de los principales contribuyentes al proyecto trabajaron antes en Borg. El nombre en clave original para Kubernetes dentro de Google era “Project Seven” (en español “Proyecto Siete”), una referencia a un personaje de Star Trek que es un Borg más “amigable”. Los siete radios en la rueda del logo de Kubernetes es una referencia al nombre en clave.
Kubernetes v1.0 fue liberada el 21 de julio de 2015. Junto a esta versión de Kubernetes, Google se asoció con la Linux Foundation para formar la Cloud Native Computing Foundation (CNCF) y ofreció Kubernetes como una tecnología semilla.
Rancher Labs incluye una distribución Kubernetes en su plataforma de mejoramiento de contenedores Rancher. También está siendo utilizada por Red Hat para su producto OpenShift, CoreOS para su producto Tectonic, e IBM para su producto IBM Spectrum Conductor for Containers.
Esperamos que os haya gustado este webinar.
Recordad que podéis consultar todos los webinars y que os podéis suscribir a la Encora Newsletter para estar al día de todas nuestras novedades.
Gracias por compartirlo en redes sociales. Esperamos vuestros comentarios.
¡Hasta pronto!
