Los contenedores, Docker y Kubernetes han ganado una enorme cantidad de seguidores en algunos años. De la misma manera que la virtualización de servidores comenzó a cambiar la forma en que los departamentos de TI dirigían sus centros de datos a mediados de la década de 2000, las herramientas de contenedores modernas y los orquestadores ahora están sacudiendo la forma en que desarrollamos y ejecutamos aplicaciones. No hay nada que conecte inherentemente el crecimiento de los contenedores con la informática en la nube, pero cuando se combinan, proporcionan una gran manera de desarrollar aplicaciones con un enfoque nativo de nube. Se han escrito libros enteros en Docker y Kubernetes, pero continuemos con una introducción relámpago para ver cómo se pueden ejecutar con rapidez los contenedores en Azure. Hay un conjunto poderoso de servicios Azure dedicados a los contenedores que se alinea más con el enfoque PaaS. Puede centrarse en la forma de crear y ejecutar las aplicaciones, en lugar de cómo administrar la infraestructura de contenedores, la orquestación y los componentes de clúster.
En este capítulo, examinamos qué son los contenedores, cómo se involucró Docker y qué puede hacer Kubernetes por usted. Para ver cómo ejecutar rápidamente una instancia de contenedor único o varias instancias de contenedor en un clúster, exploramos Azure Container Instances (ACI) y Azure Kubernetes Service (AKS).

¿Qué son los contenedores?
En los últimos años, ha habido una gran ola de interés y adopción en torno a los contenedores y me impresionaría si usted no ha oído hablar de una empresa que ha liderado esta carga: Docker. Pero, ¿qué es exactamente un contenedor, y qué tiene que ver Docker con este?.
En primer lugar, analicemos un host de virtualización tradicional que ejecuta VM. La figura es como el diagrama que miramos antes en el capítulo 1, donde cada máquina virtual tiene su propio hardware virtual y sistema operativo invitado.

Un contenedor elimina el hardware virtual y el sistema operativo invitado. Todo lo que se incluye en un contenedor son las principales aplicaciones y bibliotecas necesarias para ejecutar la aplicación, como se muestra en la figura.

Muchas VM pueden ejecutarse en un solo hipervisor, cada máquina virtual con su propio sistema operativo virtual invitado, hardware virtual y pila de aplicaciones. El hipervisor administra las solicitudes del hardware virtual de cada máquina virtual, programa la asignación y el uso compartido de esos recursos de hardware físico, y aplica la seguridad y el aislamiento de cada máquina virtual. El trabajo del hipervisor se muestra en la figura.

También se pueden ejecutar varios contenedores en un único host. El host de contenedor recibe las distintas llamadas de sistema de cada contenedor y programa la asignación y la distribución de esas solicitudes en un kernel de base compartida, sistema operativo y recursos de hardware. Los contenedores proporcionan un aislamiento lógico de los procesos de aplicación. El trabajo del tiempo de ejecución del contenedor se muestra en la figura.

Los contenedores suelen ser mucho más livianos que las máquinas virtuales. Los contenedores pueden iniciarse más rápido que las máquinas virtuales, a menudo en cuestión de segundos en lugar de minutos. El tamaño de una imagen de contenedor típicamente es de solo decenas o cientos de MB, en comparación con las muchas decenas de GB para VM. Todavía hay límites de seguridad y controles vigentes, pero es importante recordar que cada contenedor comparte técnicamente el kernel que otros contenedores en el mismo host.

Pruébelo ahora
Se tarda unos minutos en crear un clúster de AKS para su uso en los próximos ejercicios, así que complete los siguientes pasos y continúe leyendo el capítulo:
1 Abra Azure Portal y seleccione el icono de Cloud Shell en el menú superior.
2 Cree un grupo de recursos. Proporcione un nombre, como azuremolchapter19, y una ubicación, como eastus. La disponibilidad de la región de AKS puede variar, así que seleccione una región principal como eastus o westeurope. (Para obtener una lista actualizada de la disponibilidad de la región, consulte https://azure.microsoft.com/regions/services).
az group create –name azuremolchapter19 –location eastus
3 Para crear un clúster Kubernetes, especifique –node-count como 2 y utilice conjuntos de escalado y zonas de disponibilidad (que aprendió en los capítulos anteriores):

az aks create \
–resource-group azuremolchapter19 \
–name azuremol \
–node-count 2 \
–vm-set-type VirtualMachineScaleSets \
–zones 1 2 3 \
–no-wait

El parámetro final –no-wait devuelve el control a Cloud Shell mientras se crea el resto del clúster. Siga leyendo mientras se implementa el clúster.
Docker se unió a la parte contenedora con un conjunto de herramientas y formatos estándar que definían cómo construir y ejecutar un contenedor. Docker se basa en las principales funcionalidades existentes de nivel de kernel de Linux y Windows para proporcionar una experiencia de contenedor sistemática y portátil entre plataformas. Un desarrollador puede crear un contenedor Docker en su equipo portátil que ejecuta macOS, validar y probar su aplicación y, a continuación, ejecutar exactamente el contenedor de Docker, sin modificación, en un clúster Linux o Windows más tradicional de manera local o en Azure. Todos los binarios de aplicación, bibliotecas y archivos de configuración requeridos se empaquetan como parte del contenedor, por lo que el sistema operativo host subyacente no se convierte en un factor de diseño o restricción.
La importancia de Docker no se debe perder aquí. Los términos contenedor y Docker se utilizan a menudo indistintamente, aunque eso no es técnicamente exacto. Docker es un conjunto de herramientas que ayuda a los desarrolladores a compilar y ejecutar contenedores de forma sistemática, confiable y portátil. La facilidad de uso de estas herramientas llevó a la adopción rápida y cambió la forma que tenía la tecnología de contenedor subyacente por más de una década en la corriente principal. Los desarrolladores adoptaron los contenedores y la plataforma Docker, y los departamentos de TI han tenido que jugar a ponerse al día desde entonces.
Docker participa en la Open Container Initiative. El formato y las especificaciones que Docker definió para la forma de empaquetar y ejecutar un contenedor fueron algunos de los principios fundadores de este proyecto. El trabajo de Docker ha continuado y se basa en el trabajo realizado por otros. Los grandes colaboradores en el espacio de contenedores incluyen a IBM y Red Hat, aportando algunos de los diseños principales y el código que impulsa las plataformas de contenedores actuales. Es importante Open Container Initiative y el formato de diseño para el empaquetado de contenedores y tiempos de ejecución porque cada proveedor pone en capas sus propias herramientas en la parte superior de los formatos comunes, lo que les permite mover el contenedor subyacente entre las plataformas y tener la misma experiencia básica.

El enfoque de los microservicios a las aplicaciones
Si los contenedores ofrecen un concepto de aislamiento similar a las máquinas virtuales, ¿puede ejecutar el mismo tipo de cargas de trabajo que realiza en una VM? Bueno, sí y no. Solo porque puede hacer algo no significa necesariamente que debe hacerlo. Los contenedores se pueden utilizar para ejecutar cualquier carga de trabajo con la que se sienta cómodo, y hay ventajas en términos de portabilidad y funciones de orquestación que examinamos más adelante en la sección anterior. Para maximizar los beneficios de los contenedores y prepararse para el éxito, aproveche la oportunidad de adoptar un modelo mental ligeramente diferente cuando comience a trabajar con contenedores. La figura compara el modelo de aplicación tradicional con un enfoque de microservicios.

Una VM estándar incluye una instalación completa del sistema operativo invitado, como Ubuntu o Windows Server. Esta instalación de sistema operativo base incluye cientos de componentes, bibliotecas y herramientas. A continuación, instala más bibliotecas y aplicaciones, como el servidor web NGINX o Microsoft SQL Server. Por último, se implementa el código de la aplicación. Esta VM normalmente ejecuta una parte grande, si no toda, de la aplicación. Es una instancia grande de instalación y ejecución de aplicación. Para mejorar el rendimiento, puede agregar más memoria o CPU a la VM (escala vertical, analizada en capítulos anteriores) o aumentar el número de instancias que ejecutan la aplicación (escala horizontal, como con conjuntos de escala). La creación de varias instancias de aplicación solo funciona si la aplicación es compatible con clústeres y, a menudo, implica algún tipo de almacenamiento de información compartido para permitir un estado uniforme en todas las instancias de la aplicación. Esta forma tradicional de implementación se denomina aplicación monolítica.
Un enfoque diferente de cómo diseñar, desarrollar y ejecutar aplicaciones es dividir las cosas en componentes más pequeños y de tamaño de bite. Se trata de un enfoque de microservicios para el desarrollo y la implementación de aplicaciones. Cada microservicio es responsable de una pequeña parte del entorno de aplicación más amplio. Los microservicios pueden crecer, escalar y actualizarse independientemente del resto del entorno de aplicación.
Aunque este modelo puede ofrecer desafíos al principio mientras que los equipos de desarrollo y TI aprenden a adoptar una manera diferente de construir e implementar aplicaciones, los contenedores son un gran ajuste para el enfoque de microservicios. Los desarrolladores tienen el poder de implementar actualizaciones más pequeñas y más incrementales a un ritmo más rápido que el enfoque monolítico del desarrollo de aplicaciones. Los microservicios y los contenedores también son una excelente opción para los flujos de trabajo de integración continua y entrega continua (CI/CD) que facilitan que desarrolle, pruebe, escale e implemente las actualizaciones. Sus clientes reciben nuevas funcionalidades o correcciones de errores con más rapidez de lo que lo harían e, idealmente, es de esperar que su negocio crezca como resultado.

Microservicios con Azure Service Fabric
Este capítulo se centra principalmente en los contenedores Docker y la orquestación con Kubernetes, pero un servicio Azure similar traslada el desarrollo de aplicaciones hacia un modelo de microservicios. Azure Service Fabric ha existido durante varios años y fue

históricamente un enfoque centrado en Windows para el desarrollo de aplicaciones donde cada componente se desglosa en su propio microservicio. Service Fabric mantiene un registro de dónde se ejecuta cada componente de microservicio en un clúster, permite que los servicios se descubran y se comuniquen entre sí, y que manipulen la redundancia y el escalamiento.
Muchos servicios de Azure grandes utilizan Service Fabric «por debajo», incluido Cosmos DB. Eso debe darle una sensación de la capacidad y poder que puede tener Service Fabric. Service Fabric en sí se ejecuta en la parte superior de los conjuntos de escala de máquinas virtuales. Sabe una o dos cosas sobre los conjuntos de escalas por ahora, ¿verdad?
La plataforma Service Fabric ha madurado, y ahora puede manipular tanto Windows como Linux como el sistema operativo invitado, para que pueda desarrollar su aplicación con cualquier lenguaje de programación con el que se sienta cómodo. Este es otro ejemplo de elección en Azure: tiene la flexibilidad de elegir cómo quiere administrar y orquestar sus aplicaciones de contenedor. Tanto Service Fabric como AKS tienen excelentes beneficios y casos de uso.
Como buen punto de partida, si actualmente desarrolla, o desea desarrollar, los microservicios fuera de los contenedores, Service Fabric es una gran opción. Las aplicaciones diseñadas en torno al modelo de actor también encajan perfectamente, ya que Service Fabric se creó originalmente con este modelo de programación en mente. Service Fabric proporciona un enfoque unificado para manipular aplicaciones de microservicios más tradicionales y aplicaciones basadas en contenedores. Si decide adoptar contenedores para otras cargas de trabajo, puede utilizar las mismas herramientas de administración e interfaz de Service Fabric para administrar todos los entornos de aplicaciones.
Para un enfoque de aplicación más centrado en contenedores desde el primer momento, AKS puede ser una mejor opción, con el crecimiento y la adopción de Kubernetes que proporciona una experiencia de contenedores de primera clase. Puede ejecutar contenedores de Linux y Windows en AKS.

Azure Container Instances
Ahora que entiende un poco más acerca de lo que son los contenedores y cómo se pueden utilizar, profundizaremos y crearemos una instancia básica de la pizzería. Este ejemplo es el mismo usado en capítulos anteriores, donde creó una VM básica que ejecutó su sitio web, o implementó la aplicación para aplicaciones web. En ambos casos, había que crear la VM o la aplicación web, conectarse a ella y, a continuación, implementar una página web básica. ¿Puede el poder de los contenedores hacer que su vida sea mucho más fácil? Desde luego.
Un servicio definido llamado el primer momento (ACI) le permite crear y ejecutar contenedores en cuestión de segundos. No hay recursos de red por adelantado para crear y configurar, y se paga por cada instancia de contenedor por la segunda. Si nunca ha usado contenedores y no quiere instalar nada localmente en el equipo, ACI es una gran manera de probar la tecnología.
Para ver cómo puede ejecutar rápidamente su pizzería, vamos a crear una instancia de contenedor. Solo se necesita un comando para ejecutar una instancia de contenedor, pero la figura muestra cómo reunir muchos componentes para hacer que esto tras bambalinas. Observaremos los componentes de Dockerfile y Docker Hub después de que la instancia de contenedor esté en funcionamiento.

Pruébelo ahora
Para crear una instancia de contenedor de Azure que ejecute un sitio web básico, complete los pasos siguientes.
1 Abra Azure Portal y seleccione el icono de Cloud Shell en el menú superior.
2 Cree una instancia de contenedor y especifique que desea tener una dirección IP pública y abra el puerto 80:
az container create \
–resource-group azuremolchapter19 \
–name azuremol \
–image iainfoulds/azuremol \
–ip-address public \
–ports 80
En este ejercicio se usa una imagen de ejemplo que creé para usted, la que examinaremos un poco más cuando el contenedor esté en funcionamiento.
3 Para ver lo que se creó, observe la salida del comando para crear el
contenedor.
En la sección Eventos, puede ver cómo se extrae la imagen (descarga) desde Docker Hub, se crea un contenedor y luego se inicia el contenedor.
También se asignan algunas reservas de CPU y memoria, que se pueden ajustar si es necesario. Se muestra una dirección IP pública, junto con cierta información sobre el contenedor, como el estado de aprovisionamiento, el tipo de SO y la directiva de reinicio.
4 Para abrir el sitio web básico que se ejecuta en el contenedor, puede consultar solo la dirección IP pública asignada:
az container show \
–resource-group azuremolchapter19 \
–name azuremol \
–query ipAddress.ip \
–output tsv
5 Abra la dirección IP pública de su instancia de contenedor en un navegador web. La pizzería básica debe mostrarse, como se muestra en la figura.

Examinemos la imagen del contenedor. No quiero alejarme demasiado de Docker y cómo desarrollar imágenes de contenedores, pero es importante entender de dónde viene esta imagen y cómo se ejecuta el sitio web sin ninguna configuración adicional.
La imagen se desarrolla a partir de una definición de configuración llamada Dockerfile. En Dockerfile, se define qué es la plataforma base, cualquier configuración que se desee aplicar y cualquier comando que se ejecute o los archivos que se desee copiar. Dockerfiles puede ser, y a menudo es, más complejo que el ejemplo siguiente, que se utilizó para desarrollar el contenedor de ejemplo azuremol:

FROM nginx:1.17.5
EXPOSE 80:80
COPY index.html /usr/share/nginx/html

Cuando se utilizó este Dockerfile para crear una imagen de contenedor de Docker, se utilizó NGINX como imagen de origen y se copió la página web de ejemplo. Luego, este contenedor se llevó a Docker Hub, un repositorio público en línea que Docker proporciona para compartir e implementar contenedores. Para implementar la instancia de contenedor, usted proporcionó iainfoulds/azuremol como la imagen del contenedor que se utilizará. Azure buscó en Docker Hub y encontró un repositorio llamado iainfoulds y, dentro de él, una imagen denominada azuremol.
Examinemos cada línea del Dockerfile:
– FROM nginx:1.17.5: en capítulos anteriores, creó una VM básica, conectada a ella con SSH, y luego instaló manualmente el servidor web nginx. En el ejemplo Dockerfile, todo eso se logra en una línea. Esta línea dice que el contenedor debe basarse en una imagen de contenedor existente preinstalada con NGINX. 1.17.5 es la versión de la imagen de contenedor NGINX pública para utilizar; corresponde a la más reciente en el momento de la redacción de este libro. Es una buena práctica incluir un número de versión específico. Si no incluye un número de versión, siempre se utiliza la última versión. Esto suena bien en teoría, pero las aplicaciones de microservicios pueden escalar a un número bastante grande de contenedores activos, por lo que para asegurarse de tener un entorno coherente, se quiere controlar el número de versión exacto de cada componente en uso.
– EXPOSE 80:80: para permitir el acceso a la VM en capítulos anteriores, creó una regla NSG que permitía el puerto 80. En Dockerfile, esta línea le indica al contenedor que abra el puerto 80 y lo asigna al puerto interno 80. Cuando creó la instancia de contenedor con az container create, también especificó que la plataforma Azure debería permitir el tráfico con –ports 80. Esa es toda la red virtual en la que tiene que pensar.
– COPY index.html /usr/share/nginx/html: la parte final es llevar su aplicación al contenedor. En capítulos anteriores, utilizó Git para obtener la página web de ejemplo de la pizzería y luego llevó eso a su aplicación web. Con Dockerfile, usted COPY (copia) el archivo index. html al directorio local /usr/share/nginx/html del contenedor. ¡Listo!
Para sus propios escenarios, puede definir Dockerfile que utiliza una imagen base diferente, como Node.js o Python. A continuación, instale las bibliotecas o paquetes de soporte adicionales requeridos, extraiga el código de la aplicación del control de código fuente, como GitHub, e implemente la aplicación. Este Dockerfile se utilizaría para crear imágenes de contenedor que luego se almacenan en un registro de contenedor privado, no un repositorio público de Docker Hub como el del ejemplo.

Azure Container Registry
Puede que piense que Docker Hub suena muy bien. ¿Azure tiene algo maravilloso? Así es. Debido a que es necesario crear Dockerfile y desarrollar una imagen de contenedor, lamentablemente no es un ejercicio de dos minutos, y hay mucho que abordar en este capítulo. Puede integrar con facilidad Azure Container Registry (ACR) y AKS, de modo que ambos servicios funcionan bien juntos. Puede crear sus propias imágenes de Dockerfile en Cloud Shell; sin embargo, lo animo a explorar esto si dispone de tiempo. Azure Container Registry (ACR) es la ruta que elegiría para almacenar mis imágenes de contenedor, por un par de razones:
– Se trata de un registro privado para sus imágenes de contenedor, por lo que no es necesario preocuparse por el acceso potencial no deseado a sus archivos de aplicación y configuración. Puede aplicar los mismos mecanismos de RBAC que analizamos en el capítulo 6. RBAC le ayuda a limitar y auditar quién tiene acceso a sus imágenes.
– Almacenar las imágenes de su contenedor en un registro en Azure significa que sus imágenes están allí en los mismos centros de datos que la infraestructura utilizada para ejecutar sus instancias de contenedor o clústeres (que examinamos en la sección 19.4.1). Aunque las imágenes de contenedor deben ser relativamente pequeñas, a menudo solo decenas de MB de tamaño, que pueden sumar si sigue descargando esas imágenes de un registro remoto.
ACR también ofrece opciones de replicación y redundancia integradas que puede utilizar para colocar sus contenedores cerca de dónde se implementen y ejecutarlos para que los usuarios accedan. Esta localidad de región es similar a cómo utilizó la replicación global de Cosmos DB en el capítulo 10 para hacer que esos milisegundos cuenten y proporcionar a sus clientes el tiempo de acceso más rápido posible a sus aplicaciones.
Si todo esto suena emocionante, eche un vistazo a la página de inicio rápido de ACR para ponerse en funcionamiento con su propio repositorio privado en pocos minutos: http://mng.bz/04rj.

Azure Kubernetes Service
Ejecutar una instancia de contenedor única es genial, pero eso no le da mucha redundancia o capacidad de escalar. ¿Recuerda cómo pasamos capítulos completos antes en el libro hablando sobre cómo ejecutar múltiples instancias de su aplicación, equilibrio de carga y escalarlos automáticamente? ¿No sería genial hacer lo mismo con los contenedores? Ahí es donde se necesita un orquestador de contenedor.
Como su nombre lo indica, un orquestador de contenedor administra las instancias de contenedor, monitorea su estado y puede escalar según sea necesario. Los orquestadores pueden, y a menudo lo hacen, manipular mucho más, pero en un nivel alto, un enfoque principal está en manipular todas las partes móviles implicadas en la ejecución de una aplicación altamente disponible, escalable, basada en contenedores. Hay algunos orquestadores de contenedores, como Docker Swarm y el sistema operativo de nube distribuida (DC/OS), pero uno ha subido por encima del resto para convertirse en el orquestador listo de preferencia: Kubernetes.
Kubernetes comenzó como un proyecto de open source liderado por Google y que surgió de la herramienta de orquestación de contenedores internos de la empresa. Ampliamente aceptado por la comunidad de open source, Kubernetes es uno de los proyectos de open source más grandes y de más rápido crecimiento en GitHub. Muchas empresas de tecnología de gran tamaño, incluidas Red Hat, IBM y Microsoft, contribuyen al proyecto Kubernetes básico.
En esta sección, vamos a tomar la misma aplicación web de ejemplo del ejercicio anterior con ACI para ejecutar una implementación redundante y escalable en Kubernetes. Terminará con algunos componentes, como se muestra en la figura.

Creación de un clúster con Azure Kubernetes Services
En el capítulo 9, analizamos cómo los conjuntos de escala de máquinas virtuales reducen la complejidad de la implementación y configuración de la infraestructura subyacente. Usted indica cuántas instancias de VM desea en un conjunto de escala, y el resto de la red, el almacenamiento de información y la configuración se implementan para usted. AKS funciona de manera muy similar para ofrecer un clúster Kubernetes resiliente y escalable, con administración manipulada por la plataforma Azure. Los conjuntos de escalado pueden utilizarse para las máquinas virtuales subyacentes que se ejecutan en el clúster AKS, y esas máquinas virtuales pueden distribuirse por las zonas de disponibilidad. Se utilizan equilibradores de carga de Azure, también redundantes por zona. Básicamente, AKS reúne varios de los componentes de la infraestructura y los procedimientos recomendados que ha aprendido hasta ahora en este libro.

Pruébelo ahora
Para ver la información en el clúster de AKS, complete los pasos siguientes:
1 Abra Azure Portal y seleccione el icono de Cloud Shell en el menú superior.
2 Anteriormente en el capítulo, se creó un clúster Kubernetes. El proceso tardó unos minutos, pero espero que esté listo ahora. Mire el estado del clúster de la siguiente manera:
az aks show \
–resource-group azuremolchapter19 \
–name azuremol

El provisioningState cerca del final debe informar Succeeded.
3 Si el clúster está listo, obtenga un archivo de credenciales que le permita utilizar las herramientas de línea de comandos de Kubernetes para autenticar y administrar recursos:
az aks get-credentials \
–resource-group azuremolchapter19 \
–name azuremol
Eso es todo lo que se necesita para que Kubernetes funcione en Azure. Puede que esté preguntándose, «¿no puedo simplemente construir mi propio clúster con VM o conjuntos de escala, e instalar de forma manual el mismo Docker y componentes Kubernetes?». Claro que puede. El paralelo es el enfoque IaaS y PaaS de VM frente a aplicaciones web. El enfoque de aplicación web ofrece muchos beneficios: solo se preocupa por las opciones de configuración de alto nivel, y luego sube el código de su aplicación. Un clúster administrado de Kubernetes, ofrecido por AKS, reduce el nivel de complejidad y administración: su enfoque se convierte en sus aplicaciones y en la experiencia de sus clientes.
De la misma manera que puede elegir VM sobre aplicaciones web, puede optar por implementar su propio clúster Kubernetes en lugar de utilizar AKS. Está bien, ambos enfoques terminan usando los mismos componentes de servicios Azure. Las máquinas virtuales, los conjuntos de escala, los equilibradores de carga y los NSG son todos los temas que aprendió en capítulos anteriores, y todos están todavía presentes con los grupos AKS, aunque se abstraen. Desde una perspectiva de planificación y solución de problemas, debe tener las habilidades para entender lo que está sucediendo por debajo para hacer que funcione la oferta de Kubernetes administrada. Su nivel de comodidad, y el tiempo que desee para administrar la infraestructura, lo ayudarán a guiar su proceso de toma de decisiones mientras desarrolla una nueva aplicación en torno a los contenedores en Azure.

Ejecución de un sitio web básico en Kubernetes
Creó un clúster Kubernetes en la sección anterior, pero no hay ninguna aplicación ejecutándose. ¡Vamos a cambiar eso! Necesita crear la implementación de Kubernetes que vio con anterioridad en la figura 19.8; vea la figura.

Pruébelo ahora
Para implementar una aplicación en el clúster de Kubernetes, complete los pasos siguientes:
1 Interactúe con un clúster de Kubernetes mediante una utilidad de línea de comandos denominada kubectl. Utilice la misma imagen de contenedor iainfoulds/azuremol del Docker Hub que ejecutó como instancia de contenedor:
kubectl run azuremol \
–image=docker.io/iainfoulds/azuremol:latest \
–port=80
Puede tardar un minuto en descargar la imagen del contenedor de Docker Hub e iniciar la aplicación en Kubernetes. La aplicación se ejecuta en un pod: una construcción lógica en Kubernetes que aloja cada contenedor.
2 Los pods pueden contener componentes adicionales de ayudante, pero por ahora, supervise el estado de su contenedor observando el pod:
kubectl get pods –watch
Incluso cuando el estado del pod se informa como Running, no podrá acceder a la aplicación. La instancia de contenedor que creó con anterioridad podría enrutar el tráfico sobre una dirección IP pública directamente a esa instancia, pero ¿qué cree que se necesita para que un clúster Kubernetes enrute el tráfico a los contenedores? Si pensó en un equilibrador de carga, ¡felicitaciones! En este momento, solo tiene un pod: una instancia de contenedor único. Escalará el número de pods en el laboratorio de fin de capítulo, y para que funcione, se necesita una manera de enrutar el tráfico a varias instancias. Entonces, vamos a decirle a Kubernetes que use un equilibrador de carga.
Aquí es donde la integración entre Kubernetes y Azure se torna fantástica. Cuando le dice a Kubernetes que quiere crear un equilibrador de carga para sus contenedores, por debajo, Kubernetes vuelve a la plataforma Azure y crea un equilibrador de carga de Azure. Este equilibrador de carga de Azure es como el que aprendió en el capítulo 8. Hay grupos de IP frontend y back-end, y reglas de equilibrio de carga, y puede configurar sondeos de estado. A medida que su implementación de Kubernetes aumenta o disminuye, el equilibrador de carga se actualiza automáticamente según sea necesario.

Pruébelo ahora
Para exponer su aplicación a Internet, complete los siguientes pasos:
1 Dígale a Kubernetes que desea utilizar un equilibrador de carga y agregue una regla para distribuir el tráfico en el puerto 80:

kubectl expose deployment/azuremol \
–type=”LoadBalancer” \
–port 80

2 Como antes, observe el estado de su implementación de servicios:
kubectl get service azuremol –watch
Cuando se asigne la dirección IP pública externa, el equilibrador de carga de Azure terminó de implementarse y el clúster y los nodos Kubernetes están conectados.
3 Abra la dirección IP pública de su servicio en un navegador web para ver cómo se ejecuta la aplicación web.
Las implementaciones de aplicaciones en Kubernetes a menudo están mucho más involucradas que este ejemplo básico. Normalmente se define un manifiesto de servicio, similar a una plantilla del administrador de recursos, que define todas las características de la aplicación. Estas propiedades pueden incluir el número de instancias de la aplicación que se ejecutará, cualquier almacenamiento para adjuntar, métodos de equilibrio de carga y puertos de red para utilizar, etc. En el mundo real, ni siquiera se hace esto manualmente; un sistema CI/CD como Azure DevOps o Jenkins automatiza las implementaciones de aplicaciones y los servicios directamente dentro del clúster AKS. Lo bueno de AKS es que no tiene que preocuparse por la instalación y configuración de Kubernetes. Al igual que con otros servicios PaaS, como aplicaciones web y Cosmos DB, usted lleva sus aplicaciones y deja que la plataforma Azure se encargue de la infraestructura subyacente y la redundancia.

Mantenerlo limpio y ordenado
Recuerde limpiar y eliminar sus grupos de recursos para que no acabe consumiendo un montón de sus créditos Azure gratis. A medida que empieza a explorar los contenedores, se vuelve aún más importante prestar atención a qué recursos de Azure deja activados. Una sola aplicación web no cuesta mucho, pero un clúster AKS de cinco nodos y unas pocas instancias de contenedor con imágenes de Azure Container Registry georreplicadas sí pueden.
Las instancias de ACI se cobran por segundo, y el costo se suma rápidamente si se dejan en funcionamiento durante días o semanas. Un clúster AKS ejecuta una VM para cada nodo, así que si escala y ejecuta muchas VM en su clúster, está pagando por una VM para cada nodo.
No hay ningún cargo por el número de contenedores que cada uno de los nodos AKS se ejecuta, pero como con cualquier VM, un nodo AKS se vuelve costoso cuando se deja en funcionamiento. Lo bueno de Kubernetes es que puede exportar sus configuraciones de servicio (la definición de sus pods, los equilibradores de carga, el autoescalado, etc.) para implementarlas en otros lugares. A medida que desarrolla y prueba sus aplicaciones, no necesita dejar un clúster de AKS en ejecución, puede implementar un clúster según sea necesario e implementar su servicio desde una configuración anterior.
Los clusters de AKS pueden escalar hacia arriba y hacia abajo, como verá en el ejercicio de laboratorio del final del capítulo. También puede configurar el escalado automático que hace este escalado por usted en función de la carga. Es el mismo tipo de escalado automático que vimos en el capítulo 9 para conjuntos de escalado y aplicaciones web. ¿Comienza a ver que todo se une en Azure?
Este capítulo también ha sido una introducción a velocidad warp para los contenedores y Kubernetes, así que no se preocupe si se siente un poco abrumado en este momento. Manning tiene varios libros excelentes, como Aprenda Docker en un mes de almuerzos, por Elton Stoneman (https://livebook.manning.com/book/learn-docker-in-a-month-of-lunches) y Kubernetes en acción, de Marko Luksa (https://livebook.manning.com/book/kubernetes-in-action), que pueden ayudarle a profundizar más en Docker, el desarrollo de aplicaciones de microservicios y Kubernetes. Revíselos si este capítulo suena emocionante y quiere explorar más.

Los ejemplos de este capítulo utilizaron VM de Linux para los nodos del cluster de AKS y luego ejecutaron contenedores Linux para NGINX. Los contenedores son un poco complicados, ya que se pueden ejecutar contenedores Linux solo en nodos Linux, por ejemplo. Como aprendiste al principio del capítulo, los contenedores comparten el sistema operativo huésped y el kernel. Por lo tanto, no puede ejecutar contenedores de Windows en un nodo de Linux. En general, tampoco puede ejecutar contenedores de Linux en un nodo de Windows. Hay algunos trucos técnicos interesantes, pero en general, el contenedor y el sistema operativo del nodo subyacente deben coincidir.
Lo bueno de AKS es que puede ejecutar tanto nodos Linux como Windows, por lo que puede ejecutar contenedores Linux y Windows. Es necesario prestar un poco de atención a cómo se programan estos diferentes contenedores en los diferentes sistemas operativos de los nodos, pero este enfoque amplía enormemente las aplicaciones y servicios que se pueden ejecutar en AKS.

Laboratorio: Escalado de sus implementaciones de Kubernetes
El ejemplo básico de este capítulo creó un clúster Kubernetes de dos nodos y un único pod que ejecuta su sitio web. En este laboratorio, explore cómo puede escalar el clúster y el número de instancias de contenedor. Este ejemplo es básico, pero cuantos más nodos tenga, más instancias de contenedor podrá ejecutar, lo que es especialmente útil cuantas más aplicaciones necesite ejecutar en su clúster.
1 Puede ver cuántos nodos hay en su clúster Kubernetes con kubectl get nodes. Escale su clúster a tres nodos:
az aks scale \
–resource-group azuremolchapter19 \
–name azuremol \
–node-count 3
Se tarda un minuto o dos en escalar y agregar el nodo nuevo.
2 Utilice kubectl de nuevo para ver el estado de sus nodos. Cuando se amplía un nodo, Kubernetes no crea instancias de contenedor adicionales para sus aplicaciones de forma automática, por lo que no se obtiene ningún beneficio inmediato de los recursos informáticos adicionales que proporciona el nuevo nodo.
3 Vea su implementación actual con kubectl get deployment azuremol. Solo se creó una instancia antes. Esta aplicación de ejemplo no está aprovechando al máximo el nuevo nodo que agregó al cluster en el paso 1. Escale hasta cinco instancias o réplicas:

kubectl scale deployment azuremol –replicas 5

4 Utilice kubectl de nuevo para examinar la implementación. Mire los pods, las instancias del contenedor en ejecución con kubectl get pods. En cuestión de segundos, todas esas réplicas adicionales se iniciaron y se conectaron al equilibrador de carga.
5 Utilice kubectl get pods -o wide para ver en qué nodos se ejecutan los pods. Observe el último número en el nombre del nodo, que indica qué nodo del conjunto de escalado se utiliza. Los pods deben distribuirse en todos los nodos del clúster. Como otras aplicaciones escalarían el número de contenedores de forma similar, se puede empezar a maximizar el uso de los recursos informáticos en todos los nodos del clúster.

Y hasta aqui la entrada de hoy, gracias a todos!!!