Kubernetes in Azure

Práctica Kubernetes
en Azure
Segunda edicion
Automatice la gestión, el escalado y la implementación de
aplicaciones en contenedores
Nills Franssens, Shivakumar Gopalakrishnan y Gunther Lenz

Práctica de Kubernetes en Azure: segunda edición
Derechos de autor © 2020 Packt Publishing
Reservados todos los derechos. Ninguna parte de este libro puede ser reproducida, almacenada en un
sistema de recuperación o transmitida de cualquier forma o por cualquier medio, sin el permiso previo por
escrito del editor, excepto en el caso de breves citas incluidas en artículos críticos o reseñas.
Se ha hecho todo lo posible en la preparación de este libro para asegurar la exactitud de la

información presentada. Sin embargo, la información contenida en este libro se vende sin
garantía, ya sea expresa o implícita. Ni los autores, ni Packt Publishing, ni sus comerciantes y
distribuidores serán responsables de los daños causados o supuestamente causados directa
o indirectamente por este libro.
Packt Publishing se ha esforzado por proporcionar información de marcas comerciales sobre todas
las empresas y productos mencionados en este libro mediante el uso apropiado de mayúsculas. Sin
embargo, Packt Publishing no puede garantizar la exactitud de esta información.
Autores: Nills Franssens, Shivakumar Gopalakrishnan y Gunther Lenz
Revisores técnicos: Peter De Tender y Suleyman Akbas Editores en jefe:
Afzal Shaikh y Priyanka Sawant
Editor de adquisiciones: Rahul Hande
Editor de producción: Deepak Chavan
Consejo editorial: Ben Renow-Clarke e Ian Hough Primera
publicación: marzo de 2019
Segunda publicación: marzo de 2020
Referencia de producción: 1190320
ISBN: 978-1-80020-967-1
Publicado por Packt Publishing Ltd. Livery
Place, 35 Livery Street Birmingham B3
2PB, Reino Unido

Para mamá y papá. Este libro no hubiera sido posible sin todo lo que hiciste por
yo. Los amo a los dos.
Para Kelly. No sería la persona que soy hoy sin ti.

- Nills Franssens
Le dedico este libro a mis padres. Sin su apoyo en todo, desde conseguir mi primera
computadora hasta animarme en cualquier camino que tome, este libro no
ha pasado.
- Shivakumar Gopalakrishnan
Para Okson y Hugo.
Para todos los que lean esto.
- Gunther Lenz
Empezar Descubra lo que puede hacer con un servicio completamente
administrado para simplificar la implementación, la
Kubernetes
administración y las operaciones de Kubernetes, que incluye:
• Cree aplicaciones de microservicios.
• Implementar un clúster de Kubernetes.
en Azure
• Supervise y gestione Kubernetes fácilmente.
Cree una cuenta gratuita y comience a utilizar

Kubernetes en Azure. Azure Kubernetes Service (AKS)
es uno de los más de 25 productos que siempre son
gratuitos con su cuenta. Empiece gratis>
Empiece gratis>
Luego, pruebe estos laboratorios para dominar las tareas

básicas y avanzadas necesarias para implementar una
aplicación de varios contenedores en Kubernetes en Azure
Kubernetes Service (AKS). T T ry norte
rnorte
oywwo>>
Tabla de contenido
Prefacio I
Sección 1: Conceptos básicos 1
Capítulo 1: Introducción a Docker y Kubernetes 3
La evolución del software que nos trajo aquí ........................................... ......... 5

Microservicios ................................................. .................................................. ............... 5
DevOps ................................................. .................................................. ......................... 8
Fundamentos de los contenedores Docker .............................................. ...................... 9
Imágenes de Docker ................................................ .................................................. ............ 10
Kubernetes como plataforma de orquestación de contenedores ... 14

Pods en Kubernetes ............................................... .................................................. ..... 14
Implementaciones en Kubernetes ............................................... ........................................ dieciséis
Servicios en Kubernetes ............................................... ................................................. dieciséis
Servicio Azure Kubernetes ............................................... ..................................... 17

Resumen ................................................. .................................................. ............. 18
Capítulo 2: Kubernetes en Azure (AKS) 21
Diferentes formas de implementar un clúster de AKS ........................................... ................. 22
Introducción a Azure Portal ............................................ .................... 23

Creando su primer clúster de AKS ............................................. ...................................... 23
Una descripción general rápida de su clúster en Azure Portal ........................................ ...... 30
Accediendo a su clúster usando Azure Cloud Shell ........................................... ............ 32
Implementando su primera aplicación de demostración ............................................. ......................... 35
Resumen ................................................. .................................................. ............. 41

Sección 2: Implementación en AKS 43
Capítulo 3: Implementación de aplicaciones en AKS 45
Implementación de la aplicación de muestra del libro de visitas ............................................. ...... 47
Presentación de la aplicación ............................................... ......................................... 47
Implementación del maestro de Redis .............................................. ......................................... 48
Maestro de Redis con un ConfigMap ............................................. .................................... 54
Implementación completa de la aplicación del libro de visitas de muestra ............... 60
Exponiendo el servicio maestro de Redis ............................................. ............................... 60
Despliegue de los esclavos de Redis .............................................. ........................................... 63
Implementar y exponer el front-end ............................................ .......................... 66
La aplicación del libro de visitas en acción ............................................. ............................ 73
Instalación de aplicaciones complejas de Kubernetes con Helm ................................. 74
Instalando WordPress usando Helm .............................................. ................................. 75
Resumen ................................................. .................................................. ............. 82
Capítulo 4: Creación de aplicaciones escalables 85
Escalando su aplicación ............................................... ........................................ 87

Implementando el escalado de su aplicación ............................................. ................... 87
Escalar el componente frontal del libro de visitas ........................................... ................ 90
Uso de HPA ............................................... .................................................. .............. 91
Escalando su clúster ............................................... ............................................... 95

Escalar manualmente su clúster .............................................. ....................................... 95
Escalar su clúster con el escalador automático del clúster ........................................... ......... 97

Actualizando su aplicación ............................................... ................................ 100
Actualización cambiando archivos YAML ............................................. ............................ 101
Actualizar una aplicación usando kubectl edit ............................................ ............ 105
Actualizar una aplicación usando el parche kubectl ............................................ ......... 107
Actualización de aplicaciones usando Helm .............................................. ......................... 109
Resumen ................................................. .................................................. ........... 111
Capítulo 5: Manejo de fallas comunes en AKS 113
Manejo de fallas de nodos ............................................... ........................................ 114
Resolver fallas por falta de recursos ........................................... ............................. 120
Solucionar problemas de montaje de almacenamiento .............................................. ................................ 124
Iniciando la instalación de WordPress .............................................. ......................... 125
Uso de volúmenes persistentes para evitar la pérdida de datos ........................................... .............. 125
Resumen ................................................. .................................................. ........... 138
Capítulo 6: Protección de su aplicación con HTTPS y

Azure AD 141
Soporte HTTPS ................................................ .................................................. ... 143

Instalación de un controlador Ingress .............................................. ................................. 143
Agregar una regla de Ingress para la aplicación del libro de visitas ......................................... 144
Obtener un certificado de Let's Encrypt ............................................ ..................... 147
Autenticación versus autorización ............................................... ................ 159

Proveedores de autenticación y autenticación común ............................................. ........ 159
Implementación del proxy oauth2_proxy .............................................. .......................... 160
Resumen ................................................. .................................................. ........... 170

Capítulo 7: Supervisión del clúster de AKS y la aplicación 173
Comandos para monitorear aplicaciones .............................................. ............ 174

El comando kubectl get .............................................. ......................................... 174
El comando kubectl describe .............................................. ................................ 177
Aplicaciones de depuración ................................................ ............................................ 181
Registros ................................................. .................................................. .......................... 187
Sondas de preparación y vitalidad .............................................. ........................... 188
Construyendo dos contenedores web .............................................. ..................................... 189
Experimentando con sondas de vivacidad y preparación ............................................ 192
Métricas informadas por Kubernetes .............................................. ......................... 196
Estado y consumo del nodo .............................................. .................................. 196
Consumo de vainas ................................................ .................................................. .... 198
Métricas informadas desde Azure Monitor ............................................. ................ 200
AKS Insights ................................................ .................................................. ............. 200
Resumen ................................................. .................................................. ........... 208
Sección 3: Aprovechamiento de los servicios avanzados de Azure PaaS 211
Capítulo 8: Conexión de una aplicación a una base de datos de Azure 213
Configuración de OSBA ............................................... .................................................. .214
Los beneficios de utilizar un servicio de base de datos administrado .......................................... ... 214
¿Qué es OSBA? .................................................. .................................................. ....... 215
Instalación de OSBA en el clúster ............................................. .................................... 216
Implementación de OSBA ................................................ .................................................. ...... 217
Implementación de WordPress ................................................ ......................................... 220
Asegurar MySQL ................................................ .................................................. ...... 222
Conectando al sitio de WordPress ............................................. ............................. 223

Explorando operaciones avanzadas de bases de datos .............................................. ......... 224
Restaurando desde una copia de seguridad .............................................. ............................................ 224
Opciones de recuperación ante desastres (DR) ............................................ ................................... 234
Revisión de registros de auditoría ............................................... .................................................. 235
Resumen ................................................. .................................................. ........... 238
Capítulo 9: Conexión a Azure Event Hubs 241
Implementar un conjunto de microservicios ............................................. ......................... 242
Implementar la aplicación usando Helm ............................................. ...................... 243
Uso de Azure Event Hubs .............................................. ....................................... 250

Creando el centro de eventos .............................................. .............................................. 250
Modificación de los archivos de Helm .............................................. ............................................ 254
Resumen ................................................. .................................................. ........... 260
Capítulo 10: Protección de su clúster de AKS 263
Control de acceso basado en roles ............................................. .................................... 264
Creación de un nuevo clúster con integración de Azure AD .......................................... ..... 266
Creación de usuarios y grupos en Azure AD ........................................... ...................... 271
Configuración de RBAC en AKS .............................................. ............................................ 275
Verificación de RBAC ................................................ .................................................. ......... 279
Configurar la gestión de secretos .............................................. ......................... 283

Creando tus propios secretos .............................................. ......................................... 283
Creación de la clave de registro de Docker ............................................. ............................... 288
Creando el secreto TLS .............................................. .............................................. 289
Usando tus secretos ............................................... .................................................. ... 290
Secretos como variables de entorno .............................................. ............................ 290
Secretos como archivos ............................................... .................................................. .......... 291
Por qué los secretos como archivos son el mejor método .......................................... ....................... 293
Usar secretos almacenados en Key Vault ............................................ ......................... 295
Creación de un Key Vault .............................................. .................................................. .295
Configuración de Key Vault FlexVolume ............................................. ............................... 299
Uso de Key Vault FlexVolume para montar un secreto en un Pod ..................................... 301
La malla de servicios de Istio a su servicio ........................................... .................. 303
Describiendo la malla de servicios de Istio ............................................. .............................. 304
Instalación de Istio ................................................ .................................................. .......... 305
Inyección de Envoy como sidecar automáticamente ............................................ ................ 306
Aplicación de TLS mutua ............................................... ................................................ 307
Habilitación global de mTLS ............................................... ............................................. 311
Resumen ................................................. .................................................. ........... 315
Capítulo 11: Funciones sin servidor 317
Plataformas de funciones múltiples ............................................... .............................. 319
Configuración de requisitos previos ............................................... ...................................... 320
Registro de contenedores de Azure ............................................... .......................................... 321
Creando una máquina de desarrollo .............................................. ............................ 322
Creación de una función de Azure activada por HTTP ........................................... ......... 326
Creación de una función activada por cola ............................................ .................... 330
Creando una cola ............................................... .................................................. ...... 330
Creación de una función activada por cola ............................................ .......................... 333
Funciones de prueba de básculas ............................................... .............................................. 338
Resumen ................................................. .................................................. ........... 340
Índice 343
Prefacio
>
Acerca de
Esta sección presenta brevemente a los autores, la cobertura de este libro, las habilidades técnicas que
necesitará para comenzar y los requisitos de hardware y software necesarios para completar todas las
actividades y ejercicios incluidos.
ii | Prefacio
Acerca de Hands-On Kubernetes en Azure, segunda edición

Kubernetes es el estándar líder en la orquestación de contenedores, utilizado tanto por empresas emergentes
como por grandes empresas. Microsoft es uno de los mayores contribuyentes al proyecto de código abierto y
ofrece un servicio administrado para ejecutar clústeres de Kubernetes a escala.
Este libro lo guiará a través de lo que se necesita para crear y ejecutar aplicaciones sobre el Servicio
de Azure Kubernetes (AKS). Comienza con una explicación de los fundamentos de Docker y
Kubernetes, después de lo cual creará un clúster y comenzará a implementar múltiples
aplicaciones. Con la ayuda de ejemplos del mundo real, aprenderá a implementar aplicaciones
sobre AKS, implementar autenticación, monitorear sus aplicaciones e integrar AKS con otros
servicios de Azure, como bases de datos, Event Hubs y Functions.
Al final de este libro, se habrá convertido en un experto en ejecutar Kubernetes en Azure y aprovechar
las herramientas necesarias para la implementación.
Sobre los autores

Nills Franssens es un entusiasta de la tecnología y un especialista en múltiples tecnologías de
código abierto. Ha estado trabajando con tecnologías de nube pública desde 2013.
En su puesto actual como arquitecto senior de soluciones de nube en Microsoft, trabaja con los
clientes estratégicos de Microsoft en su adopción de la nube. Ha habilitado a varios clientes en su
migración a Azure. Una de estas migraciones fue la migración y la reestructuración de un
importante sitio web público a Kubernetes.
Fuera de Kubernetes, las áreas de especialización de Nills son las redes y el almacenamiento
en Azure. Tiene una maestría en ingeniería de la Universidad de Amberes, Bélgica.
Cuando no está trabajando, puedes encontrar a Nills jugando juegos de mesa con su esposa Kelly y
amigos, o corriendo por uno de los muchos senderos en San José, California.
Gunther Lenz es director senior de la oficina de tecnología de Varian. Es un líder en I + D de

software innovador, arquitecto, MBA, autor publicado, orador público y visionario de la
tecnología estratégica con más de 20 años de experiencia.
Tiene un historial comprobado de liderar con éxito equipos de desarrollo de software y

DevOps grandes, innovadores y transformacionales de más de 50 personas, con un
enfoque en la mejora continua.
Ha definido y dirigido equipos distribuidos a lo largo de todo el ciclo de vida del producto de software
aprovechando procesos, herramientas y tecnologías innovadores como la nube, DevOps, arquitectura de
microservicios ajustada / ágil, transformación digital, plataformas de software, inteligencia artificial y
aprendizaje automático distribuido. .
Acerca de Hands-On Kubernetes en Azure, segunda edición | iii
Fue galardonado con el premio Microsoft Most Valuable Professional for Software Architecture (2005-
2008).
Gunther ha publicado dos libros,. NET: un ciclo de desarrollo completo y Prácticas fábricas
de software en .NET.
Shivakumar Gopalakrishnan es arquitecto de DevOps en Varian Medical Systems. Ha introducido
Docker, Kubernetes y otras herramientas nativas de la nube en el desarrollo de productos de Varian
para habilitar "Todo como código".
Tiene años de experiencia en desarrollo de software en una amplia variedad de campos, que incluyen redes,
almacenamiento, imágenes médicas y, actualmente, DevOps. Ha trabajado para desarrollar dispositivos de
almacenamiento escalables específicamente adaptados a las necesidades de imágenes médicas y ha ayudado a diseñar
soluciones nativas de la nube para ofrecer aplicaciones modulares de AngularJS respaldadas por microservicios. Ha
hablado en múltiples eventos sobre la incorporación de inteligencia artificial y aprendizaje automático en DevOps para
permitir una cultura de aprendizaje en grandes empresas.
Ha ayudado a equipos de grandes empresas médicas altamente reguladas a adoptar metodologías ágiles /
DevOps modernas, incluido el modelo "Usted lo construye, lo ejecuta". Ha definido y lidera la implementación
de una hoja de ruta de DevOps que transforma a los equipos tradicionales en equipos que adoptan a la
perfección enfoques que priorizan la seguridad y la calidad utilizando herramientas de CI / CD.
Tiene una licenciatura en ingeniería de la Facultad de Ingeniería de Guindy y una

maestría en ciencias de la Universidad de Maryland, College Park.
Objetivos de aprendizaje
Al final de este libro, podrá:
• Comprender los fundamentos de Docker y Kubernetes
• Configurar un clúster de AKS
• Implementar aplicaciones en AKS
• Monitorear aplicaciones en AKS y manejar fallas comunes
• Configurar la autenticación para aplicaciones además de AKS
• Integrar AKS con Azure Database for MySQL
• Aproveche Azure Event Hubs desde una aplicación en AKS
• Asegure su clúster
• Implementar funciones sin servidor en su clúster

iv | Prefacio
Audiencia
Si es un ingeniero en la nube, un proveedor de soluciones en la nube, un administrador de sistemas, un

ingeniero de confiabilidad del sitio o un desarrollador que está interesado en DevOps y busca una guía extensa
para ejecutar Kubernetes en el entorno de Azure, este libro es para usted.
Acercarse
Este libro ofrece una combinación de conocimientos prácticos y teóricos. Cubre atractivos escenarios del
mundo real que demuestran cómo se ejecutan las aplicaciones basadas en Kubernetes en la plataforma
Azure. Cada capítulo está diseñado para permitirle aplicar todo lo que aprenda en un contexto práctico.
Después de los capítulos 1 y 2, cada capítulo es autónomo y se puede ejecutar independientemente de
los capítulos anteriores.
Requisitos de Software
También recomendamos que tenga el siguiente software instalado con anticipación:
• Una computadora con un sistema operativo Linux, Windows 10 o macOS
• Una conexión a Internet y un navegador web para que pueda conectarse a Azure
Todos los ejemplos del libro se han diseñado para funcionar con Azure Cloud Shell. No
tendrá que instalar software adicional en su máquina.
Convenciones
Las palabras de código en el texto, los nombres de las tablas de la base de datos, los nombres de las carpetas, los nombres de los archivos, las
extensiones de los archivos, las rutas, las URL ficticias, la entrada del usuario y los identificadores de Twitter se muestran a continuación:
"El siguiente fragmento de código utilizará la kubectl herramienta de línea de comandos para crear
una aplicación definida en el archivo libro de visitas-todo-en-uno.yaml ".
Aquí hay un bloque de código de muestra:
kubectl create -f guestbook-all-in-one.yaml
Usaremos una barra invertida, \, para indicar que una línea de código abarcará varias líneas en
el libro. Puede copiar la barra invertida y continuar en la siguiente línea o ignorar la barra
invertida y escribir el código completo de varias líneas en una sola línea. Por ejemplo:
az aks nodepool update --disable-cluster-autoscaler \
- g rg-handsonaks --cluster-name handsonaks --name agentpool
En muchas ocasiones, hemos utilizado corchetes en ángulo, <>. Debe reemplazarlos con
el parámetro real y no usar estos corchetes dentro de los comandos.
Acerca de Hands-On Kubernetes en Azure, segunda edición | v
Descargar recursos
El paquete de código para este libro también está alojado en GitHub en https://github.com/
PacktPublishing / Hands-On-Kubernetes-on-Azure --- Segunda edición . Puede encontrar el YAML y otros
archivos utilizados en este libro, a los que se hace referencia en instancias relevantes.
También tenemos otros paquetes de códigos de nuestro amplio catálogo de libros y videos disponibles en
https://github.com/PacktPublishing/ . ¡Échales un vistazo!
Sección 1: Conceptos básicos
En la Sección 1 de este libro, cubriremos los conceptos básicos que necesita comprender
para seguir los ejemplos de este libro.
Comenzaremos esta sección explicando los conceptos básicos de estos conceptos subyacentes, como
como Docker y Kubernetes. Luego, explicaremos cómo crear un clúster de Kubernetes en Azure e
implementar una aplicación de ejemplo.
Cuando termine esta sección, tendrá un conocimiento básico básico de Docker y

Kubernetes y un clúster de Kubernetes en funcionamiento en Azure que le permitirá seguir
los ejemplos de este libro.
Esta sección contiene los siguientes capítulos:
• Capítulo 1, Introducción a Docker y Kubernetes

• Capítulo 2, Kubernetes en Azure (AKS)
Introducción
1
a Docker y
Kubernetes
Kubernetes se ha convertido en el estándar líder en la orquestación de contenedores. Desde su creación en
2014, ha ganado una enorme popularidad. Ha sido adoptado tanto por empresas emergentes como por grandes
empresas, y los principales proveedores de nube pública ofrecen un servicio administrado de Kubernetes.
Kubernetes se basa en el éxito de la revolución de contenedores de Docker. Docker es tanto una empresa como
el nombre de una tecnología. Docker como tecnología es la forma estándar de crear y ejecutar contenedores de
software, a menudo llamados contenedores Docker. Un contenedor en sí mismo es una forma de empaquetar
software que facilita la ejecución de ese software en cualquier plataforma, desde su computadora portátil hasta
un servidor en un centro de datos, hasta un clúster que se ejecuta en la nube pública.
Docker es también el nombre de la empresa detrás de la tecnología Docker. Aunque la tecnología

principal es de código abierto, la empresa Docker se centra en reducir la complejidad para los
desarrolladores a través de una serie de ofertas comerciales.
4 | Introducción a Docker y Kubernetes
Kubernetes lleva los contenedores Docker al siguiente nivel. Kubernetes es un orquestador de

contenedores. Un orquestador de contenedores es una plataforma de software que facilita la ejecución
de miles de contenedores sobre miles de máquinas. Automatiza muchas de las tareas manuales
necesarias para implementar, ejecutar y escalar aplicaciones. El orquestador se encargará de programar
el contenedor correcto para que se ejecute en la máquina correcta, y se encargará de la supervisión del
estado y la conmutación por error, así como de escalar su aplicación implementada.
Docker y Kubernetes son proyectos de software de código abierto. El software de código abierto
permite a los desarrolladores de muchas empresas colaborar en una sola pieza de software. La
propia Kubernetes tiene colaboradores de empresas como Microsoft, Google, Red Hat, VMware y
muchas otras.
Las tres principales plataformas de nube pública: Azure, Amazon Web Services (AWS),
y Google Cloud Platform (GCP) - todos ofrecen un servicio gestionado de Kubernetes. Esto está
atrayendo mucho interés en el mercado, ya que la potencia de cómputo virtualmente ilimitada y la
facilidad de uso de estos servicios administrados facilitan la creación e implementación de aplicaciones
a gran escala.
Servicio de Azure Kubernetes (AKS) es el servicio administrado de Azure para Kubernetes.

Gestiona la complejidad de reunir todos los servicios anteriores para usted. En este libro,
aprenderá a utilizar AKS para ejecutar sus aplicaciones. Cada capítulo presentará nuevos
conceptos, que aplicará a través de los numerosos ejemplos de este libro.
Sin embargo, como ingeniero, sigue siendo muy útil comprender las tecnologías que sustentan
AKS. Exploraremos estos fundamentos en este capítulo. Aprenderá sobre los procesos de Linux y
cómo se relacionan con Docker. Verá cómo varios procesos encajan perfectamente en Docker y
cómo Docker encaja perfectamente en Kubernetes. Aunque Kubernetes es técnicamente una
plataforma independiente del tiempo de ejecución de contenedores, Docker es la tecnología de
contenedores más utilizada y se utiliza en todas partes.
Este capítulo presenta conceptos fundamentales de Docker para que pueda comenzar su viaje por
Kubernetes. Este capítulo también presenta brevemente los conceptos básicos que lo ayudarán a crear
contenedores, implementar clústeres, realizar la orquestación de contenedores y solucionar problemas
de aplicaciones en AKS. Tener un conocimiento superficial de lo que se incluye en este capítulo
desmitificará gran parte del trabajo necesario para crear sus aplicaciones autenticadas, cifradas y
altamente escalables en AKS. En los siguientes capítulos, desarrollará gradualmente aplicaciones
seguras y escalables.
La evolución del software que nos trajo aquí | 5
En este capítulo se tratarán los siguientes temas:
• La evolución del software que nos trajo aquí
• Los fundamentos de Docker
• Los fundamentos de Kubernetes
• Los fundamentos de AKS
El objetivo de este capítulo es presentar lo esencial en lugar de proporcionar una fuente de

información completa que describa Docker y Kubernetes. Para empezar, primero veremos cómo ha
evolucionado el software para llevarnos a donde estamos ahora.
La evolución del software que nos trajo aquí

Hay dos evoluciones importantes en el desarrollo de software que permitieron la popularidad de Docker y
Kubernetes. Uno es la adopción de un estilo arquitectónico de microservicios. Los microservicios permiten
crear una aplicación a partir de una colección de pequeños servicios, cada uno de los cuales tiene una
función específica. La otra evolución que permitió a Docker y Kubernetes es DevOps. DevOps es un
conjunto de prácticas culturales que permite a las personas, los procesos y las herramientas crear y lanzar
software con mayor rapidez, frecuencia y confiabilidad.
Aunque puede usar Docker y Kubernetes sin usar microservicios ni DevOps, las tecnologías
se adoptan más ampliamente para implementar microservicios usando metodologías
DevOps.
En esta sección, discutiremos ambas evoluciones, comenzando con los microservicios.
Microservicios
El desarrollo de software ha evolucionado drásticamente con el tiempo. Inicialmente, el software se

desarrolló y ejecutó en un solo sistema, generalmente un mainframe. Un cliente podría conectarse al
mainframe a través de una terminal, y solo a través de esa terminal. Esto cambió cuando las redes de
computadoras se volvieron comunes cuando surgió el modelo de programación cliente-servidor. Un
cliente podría conectarse de forma remota a un servidor e incluso ejecutar parte de la aplicación en su
propio sistema mientras se conecta al servidor para recuperar parte de los datos que la aplicación
requiere.
El modelo de programación cliente-servidor ha evolucionado hacia sistemas verdaderamente distribuidos.

Los sistemas distribuidos son diferentes del modelo cliente-servidor tradicional ya que tienen múltiples
aplicaciones diferentes que se ejecutan en múltiples sistemas diferentes, todos interconectados.
Hoy en día, una arquitectura de microservicios es común al desarrollar sistemas distribuidos. Una
aplicación basada en microservicios consiste en un grupo de servicios que trabajan juntos para formar
la aplicación, mientras que los servicios individuales en sí mismos se pueden construir, probar,
implementar y escalar de forma independiente entre sí. El estilo tiene muchos beneficios pero también
varios inconvenientes.
Una parte clave de una arquitectura de microservicios es el hecho de que cada servicio individual cumple
una y solo una función principal. Cada servicio cumple una única función comercial limitada. Los diferentes
servicios trabajan juntos para formar la aplicación completa. Esos servicios funcionan juntos a través de la
comunicación de red, comúnmente utilizando HTTP REST API o gRPC.
Este enfoque arquitectónico es comúnmente adoptado por aplicaciones que se ejecutan con Docker y
Kubernetes. Docker se utiliza como formato de empaquetado para los servicios individuales, mientras que
Kubernetes es el orquestador que implementa y administra los diferentes servicios que se ejecutan
juntos.
Antes de profundizar en los detalles de Docker y Kubernetes, primero exploremos los beneficios y
desventajas de adoptar microservicios.
Ventajas de ejecutar microservicios
La ejecución de una aplicación basada en microservicios tiene varias ventajas. El primero es el hecho de que cada
servicio es independiente de los demás. Los servicios están diseñados para ser lo suficientemente pequeños (por
lo tanto, micro) para manejar las necesidades de un dominio empresarial. Como son pequeños, se pueden hacer
autónomos y comprobables de forma independiente, por lo que se pueden liberar de forma independiente.
Esto lleva al hecho de que cada microservicio también es escalable de forma independiente. Si una
determinada parte de la aplicación está recibiendo más demanda, esa parte de la aplicación se puede
escalar independientemente del resto de la aplicación.
El hecho de que los servicios sean escalables de forma independiente también significa que se pueden implementar
de forma independiente. Existen múltiples estrategias de implementación cuando se trata de microservicios. Las más
populares son las actualizaciones continuas y las implementaciones azul / verde.
Con una actualización progresiva, se implementa una nueva versión del servicio solo en una parte de la
comunidad de usuarios finales. Esta nueva versión se supervisa cuidadosamente y obtiene gradualmente más
tráfico si el servicio está en buen estado. Si algo sale mal, la versión anterior todavía se está ejecutando y el
tráfico se puede cortar fácilmente.
La evolución del software que nos trajo aquí | 7
Con una implementación azul / verde, implementaría la nueva versión del servicio de forma aislada.
Una vez implementada y probada la nueva versión del servicio, reduciría más del 100% del tráfico de
producción a la nueva versión. Esto permite una transición limpia entre las versiones de servicio.
Otro beneficio de la arquitectura de microservicios es que cada servicio se puede escribir en un

lenguaje de programación diferente. Esto se describe como polígloto - capaz de comprender y
utilizar varios idiomas. Por ejemplo, el servicio de front-end se puede desarrollar en un marco de
JavaScript popular, el back-end se puede desarrollar en C #, mientras que el algoritmo de
aprendizaje automático se puede desarrollar en Python. Esto le permite seleccionar el idioma
correcto para el servicio correcto y hacer que los desarrolladores utilicen los idiomas con los que
están más familiarizados.
Desventajas de ejecutar microservicios
Cada moneda tiene una otra cara, y lo mismo ocurre con los microservicios. Si bien existen
múltiples ventajas para una arquitectura basada en microservicios, esta arquitectura también tiene
sus desventajas.
Los diseños y arquitecturas de microservicios requieren un alto grado de madurez en el desarrollo de

software para ser implementados correctamente. Los arquitectos que entienden muy bien el dominio
deben asegurarse de que cada servicio esté delimitado y de que los diferentes servicios estén cohesivos.
Dado que los servicios son independientes entre sí y tienen versiones independientes, es importante que
el contrato de software entre estos diferentes servicios sea correcto.
Otro problema común con el diseño de microservicios es la complejidad adicional cuando se trata de
monitorear y solucionar problemas de una aplicación de este tipo. Dado que los diferentes servicios componen
una sola aplicación, y esos diferentes servicios se ejecutan en varios servidores, tanto el registro como el
seguimiento de una aplicación de este tipo es una tarea complicada.
Vinculado a las desventajas mencionadas anteriormente es que, por lo general, en los

microservicios, necesita crear más tolerancia a fallas en su aplicación. Debido a la naturaleza
dinámica de los diferentes servicios en una aplicación, es más probable que ocurran fallas. Para
garantizar la disponibilidad de la aplicación, es importante incorporar tolerancia a fallos en los
diferentes microservicios que componen una aplicación. Implementar patrones como
ya que la lógica de reintento o los disyuntores es fundamental para evitar que una sola falla cause tiempo de inactividad de la
aplicación.
A menudo vinculado a los microservicios, pero una transformación separada, es el movimiento DevOps.
Exploraremos lo que significa DevOps en la siguiente sección.
DevOps
DevOps significa literalmente la combinación de desarrollo y operaciones. Más específicamente,
DevOps es la unión de personas, procesos y herramientas para entregar software de manera más
rápida, más frecuente y confiable. DevOps se trata más de un conjunto de prácticas culturales que de
herramientas o implementaciones específicas. Por lo general, DevOps abarca cuatro áreas de
desarrollo de software: planificación, desarrollo, lanzamiento y operación de software.
Nota
Existen muchas definiciones de DevOps. Los autores han adoptado esta definición,
pero a usted, como lector, se le anima a explorar diferentes definiciones en la literatura
sobre DevOps.
La cultura DevOps comienza con la planificación. En la fase de planificación de un proyecto DevOps, se

describen los objetivos de un proyecto. Estos objetivos se describen a un alto nivel (llamado
Épico) y en un nivel inferior (en Características y Tareas). Los diferentes elementos de trabajo de un proyecto de DevOps se
capturan en el registro de funciones. Por lo general, los equipos de DevOps utilizan una metodología de planificación ágil que
trabaja en sprints de programación. Los tableros Kanban se utilizan a menudo para representar el estado del proyecto y
realizar un seguimiento del trabajo. A medida que una tarea cambia de estado de que hacer para
haciendo para hecho, se mueve de izquierda a derecha en un tablero Kanban.
Cuando se planifica el trabajo, se puede realizar el desarrollo real. El desarrollo en una cultura DevOps no se
trata solo de escribir código, sino también de probar, revisar e integrarse con los miembros del equipo. Se utiliza
un sistema de control de versiones como Git para que diferentes miembros del equipo compartan código entre
sí. Un automatizado integración continua (CI) La herramienta se utiliza para automatizar la mayoría de las
tareas manuales, como las pruebas y la creación de código.
Cuando una función se completa con el código, se prueba y se crea, está lista para ser entregada. La
siguiente fase en un proyecto DevOps puede comenzar: entrega. A entrega continua (CD) La
herramienta se utiliza para automatizar la implementación de software. Normalmente, el software se
implementa en diferentes entornos, como pruebas, control de calidad o producción. Se utiliza una
combinación de puertas automáticas y manuales para garantizar la calidad antes de pasar al siguiente
entorno.
Fundamentos de los contenedores Docker | 9
Finalmente, cuando una pieza de software se está ejecutando en producción, puede comenzar la fase de operaciones.
Esta fase implica el mantenimiento, la supervisión y el soporte de una aplicación en producción. El objetivo final es
operar una aplicación de manera confiable con el menor tiempo de inactividad posible. Cualquier problema debe
identificarse de la manera más proactiva posible. Los errores en el software deben ser rastreados en la lista de trabajos
pendientes.
El proceso de DevOps es un proceso iterativo. Un solo equipo nunca está en una sola fase del
proceso. Todo el equipo está continuamente planificando, desarrollando, entregando y
operando software.
Existen múltiples herramientas para implementar las prácticas de DevOps. Existen soluciones
puntuales para una sola fase, como Jira para planificación o Jenkins para CI y CD, así como plataformas
DevOps completas, como GitLab. Microsoft opera dos soluciones que permiten a los clientes adoptar
prácticas de DevOps: Azure DevOps y GitHub. Azure DevOps es un conjunto de servicios para respaldar
todas las fases del proceso de DevOps. GitHub es una plataforma independiente que permite el
desarrollo de software DevOps. GitHub es conocida como la plataforma líder de desarrollo de software
de código abierto, que aloja más de 40 millones de proyectos de código abierto.
Tanto los microservicios como DevOps se usan comúnmente en combinación con Docker y
Kubernetes. Después de esta introducción a los microservicios y DevOps, continuaremos este
primer capítulo con los fundamentos de Docker y los contenedores y luego los fundamentos de
Kubernetes.
Fundamentos de los contenedores Docker

Una forma de tecnología de contenedores ha existido en el kernel de Linux desde la década de 1970. La
tecnología que impulsa los contenedores actuales, denominada cgroups, fue introducida en el kernel de
Linux en 2006 por Google. La empresa Docker popularizó la tecnología en 2013 al introducir un flujo de
trabajo de desarrollador sencillo. La empresa dio su nombre a la tecnología, por lo que el nombre Docker
puede referirse tanto a la empresa como a la tecnología. Sin embargo, más comúnmente usamos Docker
para referirnos a la tecnología.
Docker como tecnología es tanto un formato de empaquetado como un tiempo de ejecución de contenedor. Nos
referimos al empaquetado como una arquitectura que permite empaquetar una aplicación junto con sus
dependencias, como binarios y tiempo de ejecución. El tiempo de ejecución apunta al proceso real de ejecución
de las imágenes del contenedor.
Puede experimentar con Docker creando una cuenta gratuita de Docker en Docker Hub ( https://hub.docker.c
) y usar ese inicio de sesión para abrir Docker Labs ( https: // laboratorios. play-with-docker.com/ ).
Esto le dará acceso a un entorno con Docker preinstalado que es válido por 4 horas. Usaremos
Docker Labs en esta sección mientras creamos nuestro propio contenedor e imagen.
Nota
Aunque usamos Docker Labs basado en navegador en este capítulo para presentar Docker, también
puede instalar Docker en su escritorio o servidor local. Para las estaciones de trabajo, Docker tiene
un producto llamado Docker Desktop ( https: //www.docker. com / products / docker-desktop ) que
está disponible para Windows y Mac para crear contenedores Docker localmente. En servidores,
tanto Windows como Linux, Docker también está disponible como tiempo de ejecución para
contenedores.
Imágenes de docker
Docker usa una imagen para iniciar un nuevo contenedor. Una imagen contiene todo el software que necesita
para ejecutar dentro de su contenedor. Las imágenes de contenedores se pueden almacenar localmente en su
máquina, así como en un registro de contenedores. Hay registros públicos, como el Docker Hub público ( https://hub.docker.com
), o registros privados, como Registro de contenedores de Azure (ACR). Cuando usted, como usuario, no tiene
una imagen localmente en su PC, extraerá una imagen de un registro utilizando el estirar del acoplador mando.
En el siguiente ejemplo, extraeremos una imagen del repositorio público de Docker Hub y
ejecutaremos el contenedor real. Puede ejecutar este ejemplo en Docker Labs siguiendo estas
instrucciones:
# Primero sacaremos una imagen
docker pull docker / whalesay
# Luego podemos ver qué imágenes tenemos localmente imágenes de la

ventana acoplable
# Luego ejecutaremos nuestro contenedor

docker run docker / whalesay cowsay boo
La salida de estos comandos se verá similar a Figura 1.1:
Figura 1.1: Ejemplo de ejecución de Docker en Docker Labs

Lo que sucedió aquí es que Docker primero extrajo su imagen en varias partes y la almacenó
localmente en la máquina en la que se estaba ejecutando. Cuando ejecutamos la aplicación real,
usó esa imagen local para iniciar un contenedor. Si miramos los comandos en detalle, verá que estirar
del acoplador tomó un solo parámetro, estibador / whalesay. Si no proporciona un registro de
contenedor privado, Docker buscará imágenes en el Docker Hub público, que es de donde Docker
extrajo nuestra imagen. El Docker ejecutar El comando tomó un par de argumentos. El primer
argumento fue estibador / whalesay, que es la referencia a la imagen. Los siguientes dos
argumentos, cowsay boo, son comandos que se pasaron al contenedor en ejecución para su
ejecución.
En el ejemplo anterior, aprendimos que es posible ejecutar un contenedor sin crear primero una
imagen. Sin embargo, es muy común que desee crear sus propias imágenes. Para hacer esto, usa
un Dockerfile. Un Dockerfile contiene los pasos que Docker seguirá para comenzar desde una
imagen base y construir su imagen. Estas instrucciones pueden variar desde agregar archivos
hasta instalar software o configurar una red. Se proporciona un ejemplo de un Dockerfile en el
siguiente fragmento de código, que crearemos en nuestro campo de juego de Docker:
FROM docker / whalesay: último

EJECUTAR apt-get -y -qq update && apt-get install -qq -y fortunes CMD
/ usr / games / fortune -a | vaquero
Hay tres líneas en este Dockerfile. El primero le indicará a Docker qué imagen usar como imagen de
origen para esta nueva imagen. El siguiente paso es un comando que se ejecuta para agregar una
nueva funcionalidad a nuestra imagen. En este caso, actualizando nuestro apto repositorio e instalar
una aplicación llamada fortunas. Finalmente, el CMD El comando le dice a Docker qué comando
ejecutar cuando se ejecuta un contenedor basado en esta imagen.
Normalmente, guarda un Dockerfile en un archivo llamado Dockerfile, sin extensión. Para

construir nuestra imagen, debe ejecutar el compilación de Docker y apúntelo al Dockerfile que
creó. Al construir la imagen de Docker, el proceso leerá el Dockerfile y ejecutará los diferentes
pasos en el Dockerfile. Este comando también generará los pasos necesarios para ejecutar un
contenedor y crear su imagen. Veamos una demostración de cómo construir nuestra propia
imagen.
Para crear este Dockerfile, abra un editor de texto a través del vi Dockerfile mando. vi es
un editor de texto avanzado en la línea de comandos de Linux. Si no está familiarizado con
él, veamos cómo ingresaría el texto allí:
1. Una vez que haya abierto vi, presione el I para ingresar al modo de inserción.
2. Luego, copie y pegue o escriba las tres líneas de código.
3. Luego, presione el Esc clave y escriba: wq! para escribir (w) su archivo y salir (q) el texto
editor.
El el siguiente paso es ejecutar compilación de Docker para construir nuestra imagen. Agregaremos un bit final al comando, es
que decir, agregaremos una etiqueta a nuestra imagen para que podamos llamarla por un nombre útil. Para
construya su imagen, utilizará el docker build -t smartwhale. comando (no olvide agregar
el punto final aquí).
Ahora verá que Docker ejecuta una serie de pasos, tres en nuestro caso, para construir nuestra
imagen. Una vez creada la imagen, puede ejecutar su aplicación. Para ejecutar su contenedor,
debe ejecutar Docker ejecutar smartwhale, y debería ver una salida similar a Figura 1.2. Sin
embargo, probablemente verá una cotización inteligente diferente. Esto se debe a la fortunas aplicación
generando diferentes cotizaciones. Si ejecuta el contenedor varias veces, verá aparecer diferentes
comillas, como se muestra en Figura 1.2:
Figura 1.2: Ejemplo de ejecución de un contenedor personalizado

Con esto concluye nuestra descripción general y demostración de Docker. En esta sección, comenzó con
una imagen de contenedor existente y la lanzó en Docker Labs. Después, dio un paso más allá y construyó
su propia imagen de contenedor y comenzó a usar contenedores con su propia imagen. Ahora ha
aprendido lo que se necesita para construir y ejecutar un contenedor. En la siguiente sección, cubriremos
Kubernetes. Kubernetes le permite ejecutar varios contenedores a escala.
Kubernetes como plataforma de organización de contenedores
Construir y ejecutar un solo contenedor parece bastante fácil. Sin embargo, las cosas pueden complicarse
cuando necesita ejecutar varios contenedores en varios servidores. Aquí es donde un orquestador de
contenedores puede ayudar. Un orquestador de contenedores se encarga de programar los contenedores
para que se ejecuten en los servidores, reiniciar los contenedores cuando fallan, mover contenedores a un
nuevo host cuando ese host no funciona y mucho más.
La plataforma de orquestación líder actual es Kubernetes ( https://kubernetes.io/ ).

Kubernetes se inspiró en el proyecto Borg en Google, que, por sí solo, estaba ejecutando
millones de contenedores en producción.
Kubernetes adopta un enfoque declarativo de la orquestación; es decir, usted especifica lo que

necesita y Kubernetes se encarga de implementar la carga de trabajo que especificó. Ya no
necesita iniciar estos contenedores manualmente, ya que Kubernetes lanzará los
contenedores Docker que especificó.
Nota
Aunque Kubernetes admite varios tiempos de ejecución de contenedores, Docker es el tiempo de
ejecución más popular.
A lo largo del libro, crearemos varios ejemplos que ejecutan contenedores en Kubernetes y
aprenderá más sobre los diferentes objetos en Kubernetes. En este capítulo introductorio,
presentaremos tres objetos elementales en Kubernetes que probablemente verá en todas las
aplicaciones: un Pod, una Implementación y un Servicio.
Pods en Kubernetes
Un pod en Kubernetes es el bloque de programación esencial. Un Pod es un grupo de uno o más

contenedores. Esto significa que un Pod contiene un solo contenedor o varios contenedores. Al
crear un Pod con un solo contenedor, puede usar los términos contenedor y Pod indistintamente.
Sin embargo, todavía se prefiere el término Pod.
Kubernetes como plataforma de orquestación de contenedores | 15
Cuando un Pod contiene varios contenedores, estos contenedores comparten el mismo sistema de archivos y
el mismo espacio de nombres de red. Esto significa que cuando un contenedor que forma parte de un Pod
escribe un archivo, otros contenedores en ese mismo Pod pueden leer ese archivo. Esto también significa
que todos los contenedores de un Pod pueden comunicarse entre sí mediante localhost
redes.
En términos de diseño, solo debe colocar contenedores que deben integrarse estrechamente
en el mismo pod. Imagine la siguiente situación: tiene una aplicación web antigua que no es
compatible con HTTPS. Desea actualizar esa aplicación para que admita HTTPS. Puede crear
un Pod que contenga su aplicación web anterior e incluya otro contenedor que haría la
descarga SSL para esa aplicación como se describe en Figura 1.3.
Sus usuarios se conectarían a su aplicación usando HTTPS, mientras que el contenedor en el
medio convierte el tráfico HTTPS a HTTP:
Figura 1.3: Ejemplo de un pod de varios contenedores que descarga HTTPS
Nota
Este principio de diseño se conoce como sidecar. Microsoft tiene un libro electrónico gratuito
disponible que describe varios diseños de pod de contenedores múltiples y el diseño de sistemas
distribuidos ( https://azure.microsoft.com/resources/designing-distributed-systems/ ).
Un pod, ya sea de un solo contenedor o de varios contenedores, es un recurso efímero. Esto

significa que un Pod puede terminarse en cualquier momento y reiniciarse en otro nodo. Cuando
esto suceda, se perderá el estado que estaba almacenado en ese Pod. Si necesita almacenar el
estado en su aplicación, debe almacenarlo en un StatefulSet, que tocaremos en Capítulo 3,
Implementación de aplicaciones en AKS, o almacenar el estado fuera de Kubernetes en una base de
datos externa.
Implementaciones en Kubernetes
Una implementación en Kubernetes proporciona una capa de funcionalidad alrededor de los pods. Le permite
crear múltiples pods a partir de la misma definición y realizar actualizaciones fácilmente en sus pods
implementados. Una implementación también ayuda a escalar su aplicación y, potencialmente, incluso a escalar
automáticamente su aplicación.
Bajo las sábanas, una implementación crea una ReplicaSet, que a su vez creará el
Pod que solicitó. A ReplicaSet es otro objeto en Kubernetes. El propósito de un
ReplicaSet es mantener un conjunto estable de pods en ejecución en un momento dado. Si realiza
actualizaciones en su implementación, Kubernetes creará una nueva ReplicaSet que contendrá los pods
actualizados. De forma predeterminada, Kubernetes realizará una actualización progresiva a la nueva versión.
Esto significa que iniciará algunos pods nuevos. Si se están ejecutando correctamente, terminará algunos Pods
antiguos y continuará este ciclo hasta que solo se estén ejecutando nuevos Pods.
Figura 1.4: Relación entre implementación, ReplicaSet y pods
Servicios en Kubernetes
Un servicio en Kubernetes es una abstracción a nivel de red. Esto le permite exponer los
múltiples Pods que tiene en su Implementación bajo una sola dirección IP y un solo nombre
DNS.
Cada pod en Kubernetes tiene su propia dirección IP privada. En teoría, podría conectar sus
aplicaciones utilizando esta dirección IP privada. Sin embargo, como se mencionó anteriormente,
los pods de Kubernetes son efímeros, lo que significa que se pueden terminar y mover, lo que
afectaría su dirección IP. Al utilizar un Servicio, puede conectar sus aplicaciones entre sí utilizando
una única dirección IP. Cuando un Pod se mueve de un nodo a otro, el Servicio se asegurará de que
el tráfico se enrute al punto final correcto.
En esta sección, presentamos Kubernetes y tres objetos esenciales con

Kubernetes. En la siguiente sección, presentaremos AKS.
Servicio Azure Kubernetes | 17
Servicio Azure Kubernetes

Servicio de Azure Kubernetes (AKS) facilita la creación y administración de clústeres de Kubernetes.
Un clúster de Kubernetes típico consta de varios nodos maestros y varios nodos trabajadores. Un nodo
dentro de Kubernetes es equivalente a un máquina virtual (VM). Los nodos maestros contienen la API de
Kubernetes y una base de datos que contiene el estado del clúster. Los nodos de trabajo son las máquinas
virtuales que ejecutan su carga de trabajo real.
AKS facilita la creación de un clúster. Cuando crea un clúster de AKS, AKS configura el
maestro de Kubernetes de forma gratuita. Luego, AKS creará máquinas virtuales en su
suscripción y las convertirá en nodos trabajadores de su clúster de Kubernetes en su red.
Solo paga por esas máquinas virtuales; no pagas por el amo.
Dentro de AKS, los servicios de Kubernetes están integrados con Azure Load Balancer y los ingresos de
Kubernetes están integrados con la puerta de enlace de aplicaciones. Azure Load Balancer es un servicio
de equilibrador de carga de red de capa 4; la puerta de enlace de la aplicación es un equilibrador de carga
basado en HTTP de capa 7. La integración entre Kubernetes y ambos Servicios significa que cuando crea
un Servicio o Ingress en Kubernetes, Kubernetes creará una regla en un balanceador de carga de Azure o
una puerta de enlace de aplicaciones, respectivamente. Luego, Azure Load Balancer o Application
Gateway enrutarán el tráfico al nodo correcto en su clúster que hospeda su pod.
Además, AKS agrega una serie de funcionalidades que facilitan la administración de un clúster. AKS
contiene lógica para actualizar clústeres a versiones más recientes de Kubernetes. También tiene la
capacidad de escalar fácilmente sus clústeres, haciéndolos más grandes o más pequeños.
El servicio también viene con integraciones que facilitan las operaciones. Los clústeres de AKS vienen
preconfigurados con integración con Azure Active Directory (Azure AD) para hacer la gestión de
identidades y control de acceso basado en roles (RBAC) simple. RBAC es el proceso de
configuración que define qué usuarios obtienen acceso a los recursos y qué acciones pueden tomar
contra esos recursos. AKS también está integrado en Azure Monitor para contenedores, lo que
simplifica la supervisión y la solución de problemas de sus implementaciones.
Resumen
En este capítulo, presentamos los conceptos de Docker y Kubernetes. Ejecutamos varios contenedores,
comenzando con una imagen existente y luego usando una imagen que construimos nosotros mismos.
Después de esa demostración, exploramos tres objetos esenciales de Kubernetes: el Pod, la
Implementación y el Servicio.
Esto proporciona el contexto común para los capítulos restantes, donde implementará
aplicaciones Dockerized en Microsoft AKS. Verá cómo el AKS Plataforma como servicio
(PaaS) La oferta de Microsoft optimiza la implementación al manejar muchas de las tareas
operativas y de administración que tendría que hacer usted mismo si administrara y operara
su propia infraestructura de Kubernetes.
En el próximo capítulo, presentaremos el portal de Azure y sus componentes en el contexto

de la creación de su primer clúster de AKS.
Kubernetes en Azure
2
(AKS)
Instalar y mantener los clústeres de Kubernetes de forma correcta y segura es difícil.
Afortunadamente, todos los principales proveedores de nube, como Azure, AWS y
Google Cloud Platform (GCP), facilitan la instalación y el mantenimiento de clústeres. En
este capítulo, navegará por Azure Portal, lanzará su propio clúster y ejecutará una
aplicación de muestra. Todo esto se logrará desde su navegador.
• Creación de una nueva cuenta gratuita de Azure
• Navegando por el portal de Azure
• Lanzamiento de su primer clúster
• Comenzando su primera aplicación
Comencemos observando las diferentes formas de crear un clúster de AKS y luego ejecutemos nuestra
aplicación de muestra.
22 | Kubernetes en Azure (AKS)
Diferentes formas de implementar un clúster de AKS
Este capítulo presentará la forma gráfica de implementar su clúster de AKS. Sin embargo,
existen varias formas de crear su clúster de AKS:
• Usando el portal: El portal le brinda una forma gráfica de implementar su clúster a través de un
asistente. Esta es una excelente manera de implementar su primer clúster. Para implementaciones
múltiples o implementaciones automatizadas, se recomienda uno de los siguientes métodos.
• Usando la CLI de Azure: El azur interfaz de línea de comandos (CLI) es una CLI multiplataforma
para administrar recursos de Azure. Esto le permite crear un script para la implementación de su
clúster, que puede integrarse en otros scripts.
• Usuario Azure PowerShell: Azure PowerShell es un conjunto de comandos de PowerShell para

administrar recursos de Azure directamente desde PowerShell. También se puede utilizar para crear
clústeres de Kubernetes.
• Uso de plantillas ARM: Azure Resource Manager (ARM) las plantillas son un nativo de
Azure infraestructura como código (IaC) idioma. Le permiten implementar su clúster de
forma declarativa. Esto le permite crear una plantilla que puede ser reutilizada por varios
equipos.
• Usando Terraform para Azure: Terraform es una herramienta IaC de código abierto desarrollada
por HashiCorp. La herramienta es muy popular en la comunidad de código abierto para implementar
recursos en la nube, incluido AKS. Al igual que las plantillas ARM, Terraform también usa plantillas
declarativas para su clúster.
En este capítulo, crearemos nuestro clúster utilizando Azure Portal. Si está interesado en
implementar un clúster mediante CLI, ARM o Terraform, la documentación de Azure
contiene pasos sobre cómo usar estas herramientas para crear sus clústeres en
https://docs.microsoft.com/azure/aks .
Introducción a Azure Portal | 23
Introducción a Azure Portal

Comenzaremos nuestra implementación de clúster inicial utilizando Azure Portal. Azure Portal es una consola
de administración basada en web. Le permite crear, administrar y supervisar todas sus implementaciones de
Azure en todo el mundo a través de una única consola.
Nota
Para seguir los ejemplos de este libro, necesita una cuenta de Azure. Si no tiene una cuenta
de Azure, puede crear una cuenta gratuita siguiendo los pasos en azure.microsoft.com/free .
Si planea ejecutar esto en una suscripción existente, necesitará derechos de propietario
para la suscripción y la capacidad de crear un servicio.
directores en Azure Active Directory (Azure AD).
Todos los ejemplos de este libro se han verificado con una cuenta de prueba gratuita.
Vamos a saltar directamente creando nuestro Servicio de Azure Kubernetes (AKS)

grupo. Al hacerlo, también nos familiarizaremos con Azure Portal.
Creando su primer clúster de AKS
Introducir el aks palabra clave en la barra de búsqueda en la parte superior de Azure Portal. Haga clic en
Servicios de Kubernetes bajo la Servicios categoría en los resultados:
Figura 2.1: Búsqueda de AKS con la barra de búsqueda

Esto lo llevará a la hoja AKS en el portal. Como era de esperar, todavía no tiene ningún
clúster. Continúe y cree un nuevo clúster presionando + Agregar botón:
Figura 2.2: Hacer clic en el botón "+ Agregar" para iniciar el proceso de creación del clúster
Nota
Hay muchas opciones para configurar al crear su clúster de AKS. Para su primer clúster,
recomendamos ceñirse a los valores predeterminados del portal y seguir nuestras pautas de
nomenclatura durante este ejemplo. Probamos las siguientes configuraciones para que funcionen
de manera confiable con una cuenta gratuita.
Esto lo llevará a través del asistente de creación para crear su primer clúster de AKS. El primer
paso aquí es crear un nuevo grupo de recursos. Golpea el Crear nuevo , dale un nombre a tu
recurso y presiona está bien. Si desea seguir los ejemplos de este libro, asigne al grupo de
recursos el nombre rg-handsonaks:
Figura 2.3: Creación de un nuevo grupo de recursos
A continuación, proporcionaremos los detalles de nuestro clúster. Asigne un nombre a su clúster; si

desea seguir los ejemplos del libro, llámelo handsonaks. La región que usaremos en el libro es ( EE. UU.)
Oeste de EE. UU. 2, pero puede utilizar cualquier otra región de su elección cercana a su ubicación.
Usaremos la versión de Kubernetes 1.15.7, pero no se preocupe si esa versión no está disponible para
usted. Kubernetes y AKS evolucionan muy rápidamente y, a menudo, se introducen nuevas versiones. A
continuación, deberá proporcionar un prefijo de nombre DNS. Esto no tiene que ser único, ya que Azure
lo agregará con caracteres aleatorios:
Figura 2.4: Proporcionar los detalles del clúster
A continuación, necesitaremos cambiar el tamaño del nodo y el recuento de nodos. Para optimizar nuestro presupuesto
gratuito para nuestro clúster de muestra, usaremos un máquina virtual (VM) con un núcleo sin almacenamiento
premium e implementar un clúster de dos nodos. Si no está utilizando la versión de prueba gratuita, puede elegir un
tamaño de máquina virtual más potente, aunque esto no es necesario para los laboratorios de este libro.
Golpea el Cambiar tamaño botón debajo del tamaño de la máquina:
Figura 2.5: Hacer clic en la opción 'Cambiar tamaño' para seleccionar una máquina más pequeña
Retire el filtro que busca almacenamiento premium y busque D1_v2. Luego cambie el control deslizante por Recuento
de nodos para 2:
Figura 2.6: Selección de D1_v2 como tamaño de máquina
Esto debería hacer que el tamaño de su clúster se vea similar al que se muestra en Figura 2.7:
Figura 2.7: Tamaño de nodo actualizado y recuento de nodos
Nota
Su cuenta gratuita tiene un límite de cuatro núcleos que se violará si seguimos los valores
predeterminados.
La vista final de la primera hoja debería verse como Figura 2.8. Hay otras opciones de configuración
que no cambiaremos para nuestro clúster de demostración. Ya que estamos listos, presione el Revisar
+ crear botón ahora para hacer una revisión final y crear su clúster:
Figura 2.8: Establecer la configuración del clúster

En la vista final, Azure validará la configuración que se aplicó a su primer clúster. Si la

validación pasó, haga clic en Crear:
Figura 2.9: La validación final de la configuración de su clúster

La implementación de su clúster debería tomar aproximadamente 15 minutos. Una vez que se completa la
implementación, puede verificar los detalles de la implementación como se muestra en Figura 2.10:
Figura 2.10: Detalles de la implementación una vez que el clúster se haya implementado correctamente
Si obtiene un error de limitación de cuota, como se muestra en Figura 2.11, compruebe la configuración y vuelva a
intentarlo. Asegúrese de haber seleccionado el D1_v2 tamaño del nodo y solo dos nodos:
Figura 2.11: Reintento con un tamaño de clúster más pequeño debido a un error de límite de cuota
Para pasar a la siguiente sección, en la que veremos rápidamente nuestro clúster, presione el
Ir al recurso , que lo llevará a la hoja AKS en el portal.
Una descripción general rápida de su clúster en Azure Portal
Si golpeas el Ir al recurso en la sección anterior, ahora debería ver la descripción

general de su clúster en Azure Portal:
Figura 2.12: La hoja AKS en Azure Portal

Esta es una descripción general rápida de su clúster. Proporciona el nombre, la ubicación y la

dirección del servidor API. El menú de navegación de la izquierda ofrece diferentes opciones para
controlar y administrar su clúster. Veamos un par de opciones interesantes que ofrece el portal.
La primera opción interesante es la Grupos de nodos opción. En la vista de grupos de nodos, escala su
grupo de nodos existente (es decir, los nodos o servidores en su clúster) hacia arriba o hacia abajo
agregando o quitando nodos; puede agregar un nuevo grupo de nodos, potencialmente con un tamaño de
servidor diferente, y también puede actualizar sus grupos de nodos individualmente. En
Figura 2.13, puedes ver el Agregar grupo de nodos opción en la parte superior izquierda, y las opciones para
Escala o Potenciar en el menú de la derecha:
Figura 2.13: Agregar, escalar y actualizar grupos de nodos
La segunda hoja interesante es la Potenciar espada. Aquí, puede indicarle a AKS que actualice el plano
de administración a una versión más reciente. Por lo general, en una actualización de Kubernetes,
primero actualiza el plano maestro y luego los grupos de nodos individuales por separado:
Figura 2.14: Actualización de la versión de Kubernetes del servidor de API mediante la hoja de actualización
El último lugar interesante para investigar es Perspectivas. El Perspectivas La opción le proporciona la

supervisión de la infraestructura de su clúster y las cargas de trabajo que se ejecutan en su clúster.
Dado que nuestro clúster es nuevo, no hay muchos datos para investigar. Regresaremos aquí más
tarde en Capítulo 7, Supervisión del clúster de AKS y la aplicación:
Figura 2.15: Visualización de la utilización del clúster mediante la hoja Insights
Con esto concluye nuestra descripción general rápida del clúster y algunas de las opciones de configuración
interesantes en Azure Portal. En la siguiente sección, nos conectaremos a nuestro clúster de AKS mediante Cloud
Shell y luego lanzaremos una aplicación de demostración en la parte superior de nuestro clúster.
Acceder a su clúster mediante Azure Cloud Shell
Una vez que la implementación se complete con éxito, busque el pequeño ícono de Cloud Shell cerca de la barra
de búsqueda, como se resalta en Figura 2.16, y haz clic en él:
Figura 2.16: Hacer clic en el icono de Cloud Shell para abrir Azure Cloud Shell
El portal le pedirá que seleccione PowerShell o Bash como su experiencia de shell predeterminada.
Como trabajaremos principalmente con cargas de trabajo de Linux, seleccione Intento:
Figura 2.17: Seleccionar la opción Bash
Si es la primera vez que lanza Cloud Shell, se le pedirá que cree una cuenta de
almacenamiento; confirmar y crearlo.
Es posible que reciba un mensaje de error que contenga un error de almacenamiento de montaje. Si se
produce ese error, reinicie su Cloud Shell:
Figura 2.18: Pulsando el botón de reinicio al recibir un error de almacenamiento de montaje
Haga clic en el botón de encendido. Debería reiniciarse y debería ver algo similar a
Figura 2.19:
Figura 2.19: Lanzamiento de Cloud Shell con éxito

Puede tirar del divisor / divisor hacia arriba o hacia abajo para ver más o menos del caparazón:
Figura 2.20: Uso del divisor para agrandar o reducir Cloud Shell
La herramienta de línea de comandos que se utiliza para interactuar con los clústeres de Kubernetes se llama
kubectl. El beneficio de usar Azure Cloud Shell es que esta herramienta, junto con muchas otras, viene
preinstalada y se mantiene con regularidad. kubectl utiliza un archivo de configuración almacenado en ~ /. kube
/ config para almacenar credenciales para acceder a su clúster.
Nota
Existe cierta discusión en la comunidad de Kubernetes sobre la pronunciación
correcta de kubectl. La forma común de pronunciarlo es kube-ctl, kube-control o
kube-cuddle.
Para obtener las credenciales necesarias para acceder a su clúster, debe escribir el siguiente
comando:
az aks get-credentials --resource-group rg-handsonaks --name handsonaks
Para verificar que tiene acceso, escriba lo siguiente:

kubectl obtener nodos
Deberías ver algo como Figura 2.21:
Figura 2.21: Salida del comando kubectl get nodes
Este comando ha verificado que podemos conectarnos a nuestro clúster de AKS. En la siguiente sección, seguiremos
adelante y lanzaremos nuestra primera aplicación.
Implementación de su primera aplicación de demostración
Están todos conectados. Ahora vamos a lanzar nuestra primera aplicación. En Cloud Shell, hay dos
opciones para editar el código. Puede hacer esto a través de herramientas de línea de comandos como vi
o nano o puede utilizar un editor de código gráfico escribiendo el código mando. Usaremos el editor
gráfico en nuestros ejemplos, pero siéntase libre de usar la herramienta con la que se sienta más
cómodo.
Para el propósito de este libro, todos los ejemplos de código están alojados en un repositorio de GitHub.
Puede clonar este repositorio en su Cloud Shell y trabajar con los ejemplos de código directamente. Para
clonar el repositorio de GitHub en su Cloud Shell, use el siguiente comando:
clon de git https://github.com/PacktPublishing/Hands-On-Kubernetes-on-Azure--Second-Edition.git

Hands-On-Kubernetes-on-Azure
Para acceder a los ejemplos de código de este capítulo, navegue hasta el directorio de ejemplos
de código y vaya al Capítulo 02 directorio:
cd Hands-On-Kubernetes-on-Azure / Chapter02 /
Usaremos el código directamente allí por ahora. En este punto del libro, no nos centraremos en lo
que está en el YAML archivos todavía. El objetivo de este capítulo es lanzar un clúster e
implementar una aplicación sobre él. En los siguientes capítulos, profundizaremos en cómo se
construyen y cómo podría crear los suyos propios.
Crearemos una aplicación basada en la definición en el azure-vote.yaml expediente. Para abrir

ese archivo en Cloud Shell, puede escribir el siguiente comando:
código azure-vote.yaml
Aquí está el ejemplo de código para su conveniencia:

apiVersion: aplicaciones / v1
tipo: Despliegue
metadatos:
nombre: azure-vote-back
Especificaciones:
réplicas: 1
selector:
matchLabels:
aplicación: azure-vote-back
modelo:
metadatos:
etiquetas:
Especificaciones:
contenedores:
- nombre: azure-vote-back
imagen: redis
recursos:
peticiones:
CPU: 100 m
memoria: 128Mi
límites:
CPU: 250 m
memoria: 256Mi
puertos:
- containerPort: 6379
nombre: redis
---
apiVersion: v1
tipo: Servicio
metadatos:
nombre: azure-vote-back
Especificaciones:
puertos:
- puerto: 6379
selector:
---
apiVersion: aplicaciones / v1
tipo: Despliegue
metadatos:
nombre: azure-vote-front
Especificaciones:
réplicas: 1
selector:
matchLabels:
aplicación: azure-vote-front
modelo:
metadatos:
etiquetas:
Especificaciones:
contenedores:
- nombre: azure-vote-front
imagen: microsoft / azure-vote-front: v1
recursos:
peticiones:
CPU: 100 m
memoria: 128Mi
límites:
CPU: 250 m
memoria: 256Mi
puertos:
- containerPort: 80
env:
- nombre: REDIS
valor: "azure-vote-back"
---
apiVersion: v1
tipo: Servicio
metadatos:
nombre: azure-vote-front
Especificaciones:
tipo: LoadBalancer
puertos:
- puerto: 80
selector:
Puede realizar cambios en los archivos en el editor de código de Cloud Shell. Si ha realizado cambios,
puede guardarlos haciendo clic en el icono ... en la esquina derecha y luego Ahorrar para guardar el
archivo:
Figura 2.22: Pulsando [...] para guardar el archivo
El archivo debe guardarse. Puede verificar esto con el siguiente comando:

gato azure-vote.yaml
Nota:
Golpeando el Pestaña El botón expande el nombre del archivo en Linux. En el escenario anterior, si aciertas Pestaña
después de escribir Arizona, debería expandirse a azure-vote.yaml.
Ahora, iniciemos la aplicación:

kubectl create -f azure-vote.yaml
Debería ver rápidamente el resultado que se muestra en Figura 2.23 que le dice qué recursos
se han creado:
Figura 2.23: Salida del comando kubectl create
Puede verificar el progreso escribiendo lo siguiente:

kubectl obtener vainas
Si escribió esto rápidamente, es posible que haya visto que cierto pod todavía estaba en el
ContenedorCreando proceso:
Figura 2.24: Salida del comando kubectl get pods
Nota
Mecanografía kubectl puede volverse tedioso. Puedes usar el alias comando para hacer su
vida más fácil. Puedes usar k en vez de kubectl como el alias con el siguiente comando: alias
k = kubectl. Después de ejecutar el comando anterior, puede usar k conseguir vainas. Para
propósitos de instrucción en este libro, continuaremos usando el kubectl mando.
Presione la tecla de flecha hacia arriba y presione Ingresar hasta que el estado de todos los pods sea Corriendo. La
configuración de todos los pods lleva algo de tiempo y puede seguir su estado con el siguiente comando:
kubectl get pods - reloj
Para dejar de seguir el estado de los pods (cuando todos están en estado de ejecución), puede
presionar Ctrl + C (comando + C en Mac).
Para acceder a nuestra aplicación públicamente, debemos esperar una cosa más. Ahora queremos
conocer la IP pública del balanceador de carga para poder acceder a ella. Si te acuerdas de Capítulo 1,
Introducción a Docker y Kubernetes, un servicio en Kubernetes creará un equilibrador de carga de
Azure. Este equilibrador de carga obtendrá una IP pública en nuestra aplicación para que podamos
acceder a ella públicamente.
Escriba el siguiente comando para obtener la IP pública del balanceador de carga:
kubectl get service azure-vote-front --watch
Al principio, la IP externa puede mostrar pendiente. Espere a que aparezca la IP pública y luego
presione Ctrl + C (comando + C en Mac) para salir:
Figura 2.25: Cambio en la IP del servicio de pendiente a la dirección IP real
Anote la dirección IP externa y escríbala en un navegador. Debería ver la salida que se muestra en Figura
2.26:
Figura 2.26: La aplicación real que acaba de iniciar
Haga clic en Gatos o Perros y mira cómo sube el conteo.
Ahora ha lanzado su propio clúster y su primera aplicación de Kubernetes. Tenga en cuenta

que Kubernetes se encargó de tareas como conectar el front-end y el back-end, y exponerlo al
mundo exterior, además de proporcionar almacenamiento para los servicios.
Resumen | 41
Antes de pasar al siguiente capítulo, limpiaremos nuestra implementación. Dado que creamos
todo a partir de un archivo, también podemos eliminar todo apuntando a Kubernetes a ese
archivo. Tipo kubectl eliminar -f azure-vote.yaml y observe cómo se eliminan todos sus
objetos:
Figura 2.27: Limpieza de la implementación
En esta sección, nos hemos conectado a nuestro clúster de AKS mediante Cloud Shell, lo hemos
lanzado y conectado con éxito a una aplicación de demostración y, finalmente, hemos limpiado los
recursos que se crearon.
Resumen
Una vez completado este capítulo, podrá acceder y navegar por Azure Portal para realizar todas las
funciones necesarias para implementar un clúster de AKS. Usó la versión de prueba gratuita en
Azure para su ventaja para conocer los entresijos de AKS y otros servicios de Azure. Lanzó su propio
clúster de AKS con la capacidad de personalizar configuraciones si fuera necesario mediante Azure
Portal.
También usó Azure Cloud Shell sin instalar nada en su computadora. Esto es importante
para todas las próximas secciones, donde hará más que lanzar aplicaciones simples.
Finalmente, lanzó un servicio de acceso público. El esqueleto de esta aplicación es el mismo
que el de las aplicaciones complejas que lanzará en capítulos posteriores.
En el próximo capítulo, analizaremos en profundidad las diferentes opciones de implementación para

implementar aplicaciones en AKS.
Sección 2: Implementación
en AKS
En este punto del libro, hemos cubierto los conceptos básicos de Docker y Kubernetes y hemos
configurado un clúster de Kubernetes en Azure. En esta sección, cubriremos cómo implementar
aplicaciones sobre ese clúster de Kubernetes.
A lo largo de esta sección, crearemos e implementaremos progresivamente diferentes

aplicaciones sobre AKS. Comenzaremos por implementar una aplicación simple y luego
presentaremos conceptos como escalado, monitoreo y autenticación. Al final de la sección,
debería sentirse cómodo implementando aplicaciones en AKS.
• Capítulo 3, Implementación de aplicaciones en AKS

• Capítulo 4, Creación de aplicaciones escalables
• Capítulo 5, Manejo de fallas comunes en AKS
• Capítulo 6, Protección de su aplicación con HTTPS y Azure AD
• Capítulo 7, Supervisión del clúster de AKS y la aplicación
Solicitud
3
implementación en AKS
En este capítulo, implementaremos dos aplicaciones en Servicio de Azure Kubernetes (AKS).

Una aplicación consta de varias partes, y usted construirá las aplicaciones paso a paso
mientras se explica el modelo conceptual detrás de ellas. Podrá adaptar fácilmente los pasos
de este capítulo para implementar cualquier otra aplicación en AKS.
Para implementar las aplicaciones y realizar cambios en ellas, utilizará archivos YAML. YAML es
el acrónimo de YAML no es lenguaje de marcado. YAML es un lenguaje que se usa para crear
archivos de configuración para implementar en Kubernetes. Aunque puede usar archivos JSON
o YAML para implementar aplicaciones en Kubernetes, YAML es el lenguaje más utilizado para
hacerlo. YAML se hizo popular porque es más fácil de leer para un humano en comparación
con JSON o XML. Verá varios ejemplos de archivos YAML a lo largo de este capítulo y en todo el
libro.
46 | Implementación de aplicaciones en AKS
Durante la implementación de la aplicación de libro de visitas de muestra, verá los conceptos de

Kubernetes en acción. Verás como un despliegue está vinculado a un ReplicaSet, y cómo eso está
relacionado con el Vainas que se despliegan. Una implementación es un objeto en Kubernetes
que se usa para definir el estado deseado de una aplicación. Una implementación creará un
ReplicaSet. Un ReplicaSet es un objeto en Kubernetes que garantiza que una cierta cantidad de
pods siempre estará disponible. Por lo tanto, un ReplicaSet creará uno o más Pods. Un pod es un
objeto en Kubernetes que es un grupo de uno o más contenedores. Repasemos la relación entre
Implementación, ReplicaSet y Pods:
Figura 3.1: Relación entre una implementación, un ReplicaSet y pods
Mientras implementa las aplicaciones de muestra, utilizará la objeto de servicio para conectarse a la
aplicación. Un servicio en Kubernetes es un objeto que se utiliza para proporcionar una dirección IP
estática y un nombre DNS a una aplicación. Dado que un pod se puede eliminar y mover a diferentes
nodos en el clúster, un servicio garantiza que pueda conectarse a un punto final estático para su
aplicación.
También editará las aplicaciones de muestra para proporcionar detalles de configuración mediante un
ConfigMap. Un ConfigMap es un objeto que se usa para proporcionar detalles de configuración a
los pods. Le permite mantener los ajustes de configuración fuera del contenedor real. Luego,
puede proporcionar estos detalles de configuración a su aplicación conectando ConfigMap a su
implementación.
Finalmente, se le presentará a Helm. Helm es un administrador de paquetes para Kubernetes que ayuda a
agilizar el proceso de implementación. Implementará un sitio de WordPress utilizando Helm y
comprenderá el valor que Helm aporta a Kubernetes. La instalación de WordPress hace uso del
almacenamiento persistente en Kubernetes. Aprenderá cómo se configura el almacenamiento persistente
en AKS.
Implementación de la aplicación de libro de visitas de muestra | 47
• Implementar la aplicación de libro de visitas de muestra
• Implementación completa de la aplicación de libro de visitas de muestra
• Usar Helm para instalar aplicaciones complejas de Kubernetes
Comenzaremos con la aplicación de libro de visitas de muestra.
Implementar la aplicación de libro de visitas de muestra
En este capítulo, implementará la aplicación de Kubernetes de muestra del libro de visitas

clásico. En su mayoría, seguirás los pasos de https://Kubernetes.io/docs/tutorials/
stateless-application / guestbook / con algunas modificaciones. Empleará estas modificaciones
para mostrar conceptos adicionales, como ConfigMaps, que no están presentes en la muestra
original.
La aplicación de ejemplo de libro de visitas es una aplicación web simple de varios niveles. Los diferentes
niveles de esta aplicación tendrán varias instancias. Esto es beneficioso tanto para la alta disponibilidad
como para la escala. La interfaz del libro de visitas es una aplicación sin estado porque la interfaz no
almacena ningún estado. El clúster de Redis en el back-end tiene estado, ya que almacena todas las
entradas del libro de visitas.
Utilizará esta aplicación como base para probar el escalado del back-end y el front-end, de
forma independiente, en el siguiente capítulo.
Antes de comenzar, consideremos la aplicación que implementaremos.
Presentando la aplicación
La aplicación almacena y muestra las entradas del libro de visitas. Puedes utilizarlo para registrar la
opinión de todas las personas que visitan tu hotel o restaurante, por ejemplo. A lo largo del camino,
explicaremos conceptos de Kubernetes como implementaciones y ReplicaSets.
La aplicación utiliza PHP como interfaz. La interfaz se implementará utilizando varias réplicas. La
aplicación usa Redis para su almacenamiento de datos. Redis es una base de datos de clave-valor
en memoria. Redis se usa con mayor frecuencia como caché. Es una de las imágenes de
contenedores más populares según https://www.datadoghq.com/docker-adoption/ .
Figura 3.2: Descripción general de alto nivel de la aplicación del libro de visitas
Comenzaremos a implementar esta aplicación implementando el maestro de Redis.
Implementar el maestro de Redis
En esta sección, implementará el maestro de Redis. Aprenderá sobre la sintaxis YAML que se
requiere para esta implementación. En la siguiente sección, realizará cambios en este YAML.
Antes de realizar cambios, comencemos por implementar el maestro de Redis.
Realice los siguientes pasos para completar la tarea:
1. Abra su amigable Cloud Shell, como se destaca en Figura 3.3:
Figura 3.3: Apertura de Cloud Shell
2. Si no ha clonado el repositorio de github para este libro, hágalo ahora usando el

siguiente comando:
clon de git https://github.com/PacktPublishing/Hands-On-Kubernetes-on-Azure-

- - Segunda edición Hands-On-Kubernetes-on-Azure
cd Hands-On-Kubernetes-on-Azure / Chapter03 /
3. Ingrese el siguiente comando para implementar el maestro:
kubectl apply -f redis-master-deployment.yaml
La aplicación tardará algún tiempo en descargarse y empezar a ejecutarse. Mientras espera,

entendamos el comando que acaba de escribir y ejecutar. Comencemos explorando el
contenido del archivo YAML que se usó:
1 apiVersion: apps / v1 # para versiones anteriores a 1.9.0 use apps / v1beta2 2
kind: Deployment
3 metadatos:
4 nombre: redis-master
5 etiquetas:
6 aplicación: redis
7 especificaciones:
8 selector:
9 matchLabels:
11 papel: maestro
12 nivel: backend
13 réplicas: 1
14 modelo:
15 metadatos:
dieciséis etiquetas:
18 papel: maestro
19 nivel: backend
20 Especificaciones:
21 contenedores:
22 - nombre: maestro
23 imagen: k8s.gcr.io/redis:e2e # o simplemente imagen: recursos
24 de redis:
25 peticiones:
26 CPU: 100 m
27 memoria: 100Mi
28 puertos:
29 - containerPort: 6379
Vamos profundice en el código para comprender los parámetros proporcionados:
• Línea 2: Esto indica que estamos creando un Despliegue. Como se explica en Capítulo 1,
Introducción a Docker y Kubernetes, una implementación es un envoltorio de los pods que
facilita la actualización y el escalado de los pods.
• Líneas 4-6: Aquí el Despliegue se le da un nombre, que es redis-master.

• Líneas 7-12: Estas líneas nos permiten especificar los contenedores que este Despliegue manejaré. En
este ejemplo, el Despliegue seleccionará y gestionará todos los contenedores cuyas etiquetas coincidan
( aplicación: redis, rol: maestro, y tier: backend). La etiqueta anterior coincide exactamente con las
etiquetas proporcionadas en las líneas 14-19.
• Línea 13: Le dice a Kubernetes que necesitamos exactamente una copia del maestro de Redis en
ejecución. Este es un aspecto clave de la naturaleza declarativa de Kubernetes. Proporcionas una
descripción de los contenedores que necesitan ejecutar tus aplicaciones (en este caso, solo una
réplica del maestro de Redis) y Kubernetes se encarga de ello.
• Línea 14-19: Agrega etiquetas a la instancia en ejecución para que pueda agruparse y
conectarse a otros contenedores. Los discutiremos más adelante para ver cómo se usan.
• Línea 22: Da a este contenedor un nombre, que es Maestro. En el caso de un Pod de

contenedores múltiples, cada contenedor de un Pod requiere un nombre único.
• Línea 23: Esta línea indica la imagen de Docker que se ejecutará. En este caso, es el
redis imagen etiquetada con e2e la última imagen de Redis que pasó con éxito su
[ e2e] pruebas).
• Líneas 28-29: Estas dos líneas indican que el contenedor va a escuchar en el puerto.
6379.
• Líneas 24-27: Establece el cpu / memoria recursos solicitados para el contenedor. En este
caso, la solicitud es 0.1 CPU, que es igual a 100m y también se conoce como 100 milicores. La
memoria solicitada es 100Mi, o 104857600 bytes, lo que equivale a ~ 105 MB ( https://Kubernetes.io/d
). También puede establecer límites de CPU y memoria de manera similar. Los límites son
límites sobre lo que puede usar un recipiente. Si su Pod alcanza el límite de la CPU, se
acelerará, mientras que si alcanza los límites de memoria, se reiniciará. Establecer solicitudes
y límites es una práctica recomendada en Kubernetes.
Nota
La definición de YAML de Kubernetes es similar a los argumentos dados a Docker para ejecutar una
imagen de contenedor en particular. Si tuviera que ejecutar esto manualmente, definiría este ejemplo
de la siguiente manera:
# Ejecute un contenedor llamado master, escuchando en el puerto 6379, con 100M

de memoria y 100m de CPU usando la imagen redis: e2e.
Docker ejecutar --nombre maestro -p 6379: 6379 -m 100M -c 100m -d k8s.gcr.io/

redis: e2e
En esta sección, implementó el maestro de Redis y aprendió sobre la sintaxis del archivo
YAML que se usó para crear esta implementación. En la siguiente sección, examinará la
implementación y conocerá los diferentes elementos que se crearon.
Examinando la implementación
El redis-master la implementación debería estar completa ahora. Continúe en Azure

Cloud Shell que abrió en la sección anterior y escriba lo siguiente:
kubectl obtener todo
Debería obtener la salida mostrada en Figura 3.4:
Figura 3.4: Salida que muestra los objetos que fueron creados por su implementación
Puedes ver que tenemos una implementación llamada redis-master. Controla un ReplicaSet de
redis-master- <id aleatorio>. En un examen más detenido, también encontrará que ReplicaSet está
controlando un Pod, redis- master- <ID aleatorio del conjunto de réplicas> - <ID aleatorio>. Figura 3.1 tiene
una representación gráfica de esta relación.
Se pueden obtener más detalles ejecutando el kubectl describe <objeto> <nombre de instancia> comando,
de la siguiente manera:
kubectl describe la implementación / redis-master

Esto generará una salida de la siguiente manera:
Figura 3.5: Resultado de la descripción de la implementación
Ahora ha lanzado un maestro de Redis con la configuración predeterminada.

Normalmente, lanzaría una aplicación con una configuración específica del entorno.
En la siguiente sección, presentaremos un nuevo concepto llamado ConfigMaps y luego

recrearemos el maestro de Redis. Entonces, antes de continuar, necesitamos limpiar la
versión actual, y podemos hacerlo ejecutando el siguiente comando:
kubectl eliminar implementación / redis-master
La ejecución de este comando producirá el siguiente resultado:

deployment.extensions "redis-master" eliminado
En esta sección, examinó la implementación principal de Redis que creó. Viste cómo una
implementación se relaciona con un ReplicaSet y cómo un ReplicaSet se relaciona con Pods. En la
siguiente sección, volverá a crear este maestro de Redis con una configuración específica del entorno
proporcionada a través de un ConfigMap.
Maestro de Redis con un ConfigMap
No hubo nada de malo con la implementación anterior. En casos prácticos de uso, sería
raro que inicie una aplicación sin algunos ajustes de configuración. En este caso, vamos a
establecer los ajustes de configuración para redis-master utilizando un ConfigMap.
Un ConfigMap es una forma portátil de configurar contenedores sin tener imágenes especializadas para
cada configuración. Tiene un par clave-valor para los datos que deben configurarse en un contenedor. Un
ConfigMap se utiliza para configuraciones no secretas. Kubernetes tiene un objeto separado llamado Secreto.
Un secreto se utiliza para configuraciones que contienen datos críticos como contraseñas. Esto se
explorará en detalle en Capítulo 10, Protección de su clúster de AKS de este libro.
En este ejemplo, vamos a crear un ConfigMap. En este ConfigMap,

configuraremos redis-config como clave y el valor será:
maxmemory 2mb
maxmemory-policy allkeys-lru
Ahora, creemos este ConfigMap. Hay dos formas de crear un ConfigMap:
• Crear un ConfigMap a partir de un archivo
• Crear un ConfigMap a partir de un archivo YAML
Exploraremos cada uno en detalle.

Crear un ConfigMap a partir de un archivo
Los siguientes pasos nos ayudarán a crear un ConfigMap a partir de un archivo:
1. Abra el editor de código de Azure Cloud Shell escribiendo código redis-config en el

Terminal. Copie y pegue las siguientes dos líneas y guárdelas como redis-config:
maxmemory 2mb
2. Ahora puede crear el ConfigMap usando el siguiente código:

kubectl crear mapa de configuración example-redis-config --from-file = redis-config
3. Debería obtener un resultado de la siguiente manera:
configmap / example-redis-config creado
4. Puede usar el mismo comando para describir este ConfigMap:

kubectl describe configmap / example-redis-config
5. La salida será como se muestra en Figura 3.6:
Figura 3.6: Resultado de la descripción de ConfigMap
En este ejemplo, creó ConfigMap haciendo referencia a un archivo en el disco. Una forma diferente de
implementar ConfigMaps es crearlos a partir de un archivo YAML. Echemos un vistazo a cómo se puede
hacer esto en la siguiente sección.
Creando un ConfigMap a partir de un archivo YAML
En esta sección, volverá a crear el ConfigMap de la sección anterior utilizando un archivo YAML:
1. Para comenzar, elimine el ConfigMap creado anteriormente:
kubectl eliminar configmap / example-redis-config
2. Copie y pegue las siguientes líneas en un archivo llamado ejemplo-redis-config.yaml,

y luego guarde el archivo:
apiVersion: v1
datos:
redis-config: | -
maxmemory 2mb
tipo: ConfigMap
metadatos:
nombre: ejemplo-redis-config
espacio de nombres: predeterminado
3. Ahora puede volver a crear su ConfigMap mediante el siguiente comando:

kubectl create -f example-redis-config.yaml
4. Debería obtener un resultado de la siguiente manera:
configmap / example-redis-config creado
5. A continuación, ejecute el siguiente comando:
kubectl describe configmap / example-redis-config
6. Este comando devuelve el mismo resultado que el anterior:

Nombre: ejemplo-redis-config
Espacio de nombres: defecto
Etiquetas: <ninguno>
Anotaciones: <ninguno>
Datos
====
redis-config:
----
maxmemory 2mb
Eventos: <ninguno>
Como puede ver, utilizando un archivo YAML, pudo crear el mismo ConfigMap.
Nota:
kubectl obtener tiene la opción útil - o, que se puede usar para obtener la salida de un
objeto en YAML o JSON. Esto es muy útil en los casos en los que ha realizado cambios
manuales en un sistema y desea ver el objeto resultante en formato YAML. Puede obtener
el ConfigMap actual en YAML usando el siguiente comando:
kubectl get -o yaml configmap / example-redis-config
Ahora que tiene el ConfigMap definido, usémoslo.
Usar un ConfigMap para leer datos de configuración
En esta sección, reconfigurará el redis-master despliegue para leer la configuración de

ConfgMap:
1. Para comenzar, modifique redis-master-deployment.yaml para utilizar ConfigMap de la siguiente manera.

Los cambios que debe realizar se explicarán después del código fuente:
Nota
Si descargó el código fuente que acompaña a este libro, hay un archivo en
Capítulo 3, Implementación de aplicaciones en AKS, llamado redis-master-deployment_
Modified.yaml, que tiene los cambios necesarios aplicados.

kind: Deployment
3 metadatos:
5 etiquetas:
7 especificaciones:
8 selector:
9 matchLabels:
11 papel: maestro
12 nivel: backend
13 réplicas: 1
14 modelo:
15 metadatos:
18 papel: maestro
19 nivel: backend
21 contenedores:
22 - nombre: maestro
23 imagen: k8s.gcr.io/redis:e2e
24 mando:
25 - servidor redis
26 - "/redis-master/redis.conf"
27 env:
28 - nombre: MASTER
29 valor: "verdadero"
30 volumeMounts:
31 - mountPath: / redis-master
32 nombre: config
33 recursos:
34 peticiones:
35 CPU: 100 m
36 memoria: 100Mi
37 puertos:
39 volúmenes:
40 - nombre: config
41 configMap:
42 nombre: ejemplo-redis-config
43 artículos:
44 - clave: redis-config
45 ruta: redis.conf
Profundicemos en el código para comprender las diferentes secciones:
• Líneas 24-26: Estas líneas introducen un comando que se ejecutará cuando se inicie su
Pod. En este caso, esto iniciará el servidor redis apuntando a un archivo de configuración
específico.
• Líneas 27-29: Muestra cómo pasar datos de configuración a su contenedor en ejecución. Este
método usa variables de entorno. En forma de Docker, esto sería equivalente a Docker run -e
"MASTER = true". --nombre maestro -p 6379: 6379 -m 100M -c 100m
- d Kubernetes / redis: v1. Esto establece la variable de entorno MAESTRO para verdadero. Su
aplicación puede leer la configuración de las variables de entorno para su configuración.
• Líneas 30-32: Estas líneas montan el volumen llamado config ( este volumen se define en
las líneas 39-45) en el / redis-master ruta en el contenedor en ejecución. Ocultará todo lo
que exista en / redis-master en el envase original.
En términos de Docker, sería equivalente a docker ejecute -v config: / redis-master.

- e "MAESTRO = VERDADERO" --nombre maestro -p 6379: 6379 -m 100M -c 100m -d Kubernetes /
redis: v1.
• Línea 40: Le da al volumen el nombre config. Este nombre se utilizará en el

contexto de este pod.
• Líneas 41-42: Declare que este volumen debe cargarse desde el ejemplo-redis-
config ConfigMap. Este ConfigMap ya debería existir en el sistema. Ya lo has
definido, así que estás bien.
• Líneas 43-45: Aquí, está cargando el valor del redis-config clave (las dos líneas
maxmemory ajustes) como redis.conf expediente.
2. Creemos esta implementación actualizada:

kubectl create -f redis-master-deployment_Modified.yml
3. Esto debería generar lo siguiente:

deployment.apps / redis-master creado
4. Asegurémonos ahora de que la configuración se haya aplicado correctamente. Primero, obtenga el

nombre del Pod:
5. Luego ejecutivo en el Pod y verifique que se hayan aplicado las configuraciones:
kubectl exec -it redis-master- <pod-id> redis-cli

127.0.0.1:6379> CONFIG OBTENER maxmemory
1) "maxmemory" 2) "2097152"
127.0.0.1:6379> CONFIG GET maxmemory-policy
"maxmemory-policy"
"allkeys-lru" 127.0.0.1:6379>exit
En resumen, acaba de realizar una parte importante y complicada de la configuración de aplicaciones nativas de
la nube. También habrá notado que las aplicaciones deben configurarse para leer la configuración de forma
dinámica. Después de configurar su aplicación con la configuración, accedió a un contenedor en ejecución para
verificar la configuración en ejecución.
Nota
La conexión a un contenedor en ejecución es útil para solucionar problemas y realizar diagnósticos.
Debido a la naturaleza efímera de los contenedores, nunca debe conectarse a un contenedor para
realizar una configuración o instalación adicional. Esto debería ser parte de la imagen de su
contenedor o la configuración que proporcione a través de Kubernetes (como acabamos de hacer).
En esta sección, configuró Redis Master para cargar datos de configuración desde un ConfigMap.
En la siguiente sección, implementaremos la aplicación de un extremo a otro.
Implementación completa de la aplicación de libro de visitas de muestra
Habiendo tomado un desvío para comprender la configuración dinámica de las aplicaciones que
utilizan un ConfigMap, ahora volveremos a la implementación del resto de la aplicación del libro de
visitas. Una vez más, se encontrará con los conceptos de implementación, ReplicaSets y Pods para el
back-end y el front-end. Aparte de esto, también se le presentará otro concepto clave, llamado
servicio.
Para iniciar la implementación completa, crearemos un servicio para exponer el servicio

maestro de Redis.
Exponiendo el servicio maestro de Redis
Al exponer un puerto en Docker simple, el puerto expuesto está restringido al host en el

que se está ejecutando. Con las redes de Kubernetes, existe conectividad de red entre
diferentes pods en el clúster. Sin embargo, los pods en sí mismos son de naturaleza
efímera, lo que significa que se pueden apagar, reiniciar o incluso mover a otros hosts sin
mantener su dirección IP. Si se conectara a la IP de un Pod directamente, podría perder la
conectividad si ese Pod se moviera a un nuevo host.
Kubernetes proporciona Servicio objeto, que maneja este problema exacto. Al usar selectores de
coincidencia de etiquetas, envía el tráfico a los pods correctos y realiza el equilibrio de carga. En este
caso, el maestro solo tiene un Pod, por lo que solo garantiza que el tráfico se dirija al Pod
independientemente del nodo en el que se ejecuta el Pod. Para crear el servicio, ejecute el siguiente
comando:
kubectl apply -f redis-master-service.yaml

Implementación completa de la aplicación de libro de visitas de muestra | 61
El servicio maestro de Redis tiene el siguiente contenido:

1 apiVersion: v1
2 tipo: Servicio
3 metadatos:
5 etiquetas:
7 papel: maestro
8 nivel: backend
9 Especificaciones:
10 puertos:
11 - puerto: 6379
12 targetPort: 6379
13 selector:
15 papel: maestro
dieciséis nivel: backend

Veamos ahora lo que ha creado utilizando el código anterior:
• Líneas 1-8: Estas líneas le dicen a Kubernetes que queremos un servicio llamado redis-master,
que tiene las mismas etiquetas que nuestro redis-master Pod de servidor.
• Líneas 10-12: Estas líneas indican que el servicio debe atender el tráfico que llega al puerto. 6379
y reenviarlo al puerto 6379 de los Pods que coinciden con el selector definido entre las líneas
13 y 16.
• Líneas 13-16: Estas líneas se utilizan para encontrar los pods a los que se debe transferir el tráfico
entrante. Entonces, cualquier pod con etiquetas que coincidan ( aplicación: redis, rol: maestro
y nivel: backend) se espera que maneje el puerto 6379 tráfico. Si mira hacia atrás en el ejemplo
anterior, esas son las etiquetas exactas que aplicamos a esa implementación.
Podemos comprobar las propiedades del servicio ejecutando el siguiente comando:

kubectl obtener servicio
Esto le dará una salida como se muestra en Figura 3.7:
Figura 3.7: Salida del servicio que se creó
Ves que un nuevo servicio, llamado redis-master, Ha sido creado. Tiene una IP de todo el clúster de 10.0.227.250
( en su caso, es probable que la IP sea diferente). Tenga en cuenta que esta IP funcionará solo dentro del
clúster (de ahí el ClusterIP tipo).
Un servicio también introduce un Servidor de nombres de dominio (DNS) nombre para ese servicio. El
nombre DNS tiene el formato < nombre-servicio>. <espacio de nombres> .svc.cluster.local; en nuestro
caso, eso sería redis-master.default.svc.cluster.local. Para ver esto en acción, haremos una resolución
de nombre en nuestro redis-master VM. La imagen predeterminada no tiene nslookup instalado, así que
lo omitiremos ejecutando un silbido mando. No se preocupe si ese tráfico no regresa; esto es porque no
expusiste silbido en su servicio, solo el redis Puerto. Echemos un vistazo:
# anote el nombre de su redis-master pod

kubectl exec -it redis-master- <pod-id> bash
ping redis-master
Esto debería generar la resolución de nombre resultante, mostrándole el Nombre de dominio
completo (FQDN) de su servicio y la dirección IP que apareció anteriormente. Puede salir del Pod
a través del Salida comando, como se muestra en Figura 3.8:
Figura 3.8: Uso de un comando ping para ver el FQDN de su servicio
En esta sección, expuso el maestro de Redis mediante un servicio. En la siguiente sección,

desplegará los esclavos de Redis.
Despliegue de los esclavos de Redis
No se recomienda ejecutar un solo backend en la nube. Puede configurar Redis en una configuración
maestro-esclavo. Esto significa que puede tener un maestro que sirva el tráfico de escritura y varios
esclavos que puedan manejar el tráfico de lectura. Es útil para manejar un mayor tráfico de lectura y
alta disponibilidad.
Vamos a configurar esto:
1. Cree la implementación ejecutando el siguiente comando:
kubectl apply -f redis-slave-deployment.yaml
2. Revisemos todos los recursos que se han creado ahora:

La salida sería como se muestra en Figura 3.9:
Figura 3.9: La implementación de los esclavos de Redis crea una serie de nuevos objetos
3. Según el resultado anterior, puede ver que creó dos réplicas del redis-esclavo Vainas.
Esto puede confirmarse examinando el redis-slave- deployment.yaml expediente:

tipo: Despliegue
3 metadatos:
4 nombre: redis-esclavo
5 etiquetas:
7 Especificaciones:
8 selector:
9 matchLabels:
11 papel: esclavo
12 nivel: backend
13 réplicas: 2
14 modelo:
15 metadatos:
18 papel: esclavo
19 nivel: backend
21 contenedores:
22 - nombre: esclavo
23 imagen: gcr.io/google_samples/gb-redisslave:v1
24 recursos:
25 peticiones:
26 CPU: 100 m
27 memoria: 100Mi
28 env:
29 - nombre: GET_HOSTS_FROM
30 valor: dns
31 # El uso de 'GET_HOSTS_FROM = dns' requiere que su clúster
32 # proporcionar un servicio de dns. A partir de Kubernetes 1.3, DNS es un
incorporado
33 # servicio iniciado automáticamente. Sin embargo, si el clúster

están usando
Implementación completa de la aplicación de libro de visitas de muestra | sesenta y cinco
34 # no tiene un servicio DNS integrado, en su lugar puede

35 # acceder a una variable de entorno para encontrar el maestro
36 # anfitrión del servicio. Para hacerlo, comente la línea 'value: dns'
arriba, y
37 # descomente la línea a continuación:
38 # valor: env
39 puertos:
Todo es igual excepto por lo siguiente:
• Línea 13: El número de réplicas es 2.

• Línea 23: Ahora está utilizando una imagen esclava específica.
• Líneas 29-30: Configuración GET_HOSTS_FROM para dns. Como vio en el ejemplo anterior, DNS
se resuelve en el clúster.
4. Al igual que el servicio maestro, debe exponer el servicio esclavo ejecutando lo

siguiente:
kubectl apply -f redis-slave-service.yaml
La única diferencia entre este servicio y el redis-master servicio es que este servicio envía el
tráfico a los pods que tienen el papel: esclavo etiqueta.
5. Comprobar el redis-esclavo service ejecutando el siguiente comando:

Esto debería darle el resultado que se muestra en Figura 3.10:
Figura 3.10: Salida que muestra un servicio redis-master y redis-slave
Ahora tiene un clúster de Redis en funcionamiento, con un solo maestro y dos réplicas. En la
siguiente sección, implementará y expondrá la interfaz.
Implementar y exponer el front-end

Hasta ahora, se ha centrado en el back-end de Redis. Ahora está listo para implementar
la interfaz. Esto agregará una página web gráfica a su aplicación con la que podrá
interactuar.
Puede crear la interfaz con el siguiente comando:

kubectl apply -f frontend-deployment.yaml
Para verificar la implementación, ejecute este código:
Esto mostrará la salida que se muestra en Figura 3.11:
Figura 3.11: Salida que muestra los Pods adicionales que ejecutan el front-end
Notarás que esta implementación especifica 3 réplicas. El despliegue tiene los aspectos habituales
con cambios menores, como se muestra en el siguiente código:
1 apiVersion: apps / v1 # para versiones anteriores a 1.9.0 use apps / v1beta2 kind:
Deployment
2 metadatos:
3 nombre: frontend
4 etiquetas:
5 aplicación: libro de visitas
6 Especificaciones:
7 selector:
8 matchLabels:
10 tier: frontend
11 réplicas: 3
12 modelo:
13 metadatos:
14 etiquetas:
dieciséis tier: frontend

18 contenedores:
19 - nombre: php-redis
20 imagen: gcr.io/google-samples/gb-frontend:v4
21 recursos:
22 peticiones:
23 CPU: 100 m
24 memoria: 100Mi
25 env:
26 - nombre: GET_HOSTS_FROM
27 valor: dns
28 # El uso de GET_HOSTS_FROM = dns requiere que su clúster
29 # proporcionar un servicio de dns. A partir de Kubernetes 1.3, DNS es un
en
30 # servicio iniciado automáticamente. Sin embargo, si el clúster
están usando
31 # no tiene un servicio DNS integrado, en su lugar puede

32 # acceder a una variable de entorno para encontrar el maestro
33 # anfitrión del servicio. Para hacerlo, comente la línea 'value: dns'

arriba, y
34 # descomente la línea a continuación:
35 # valor: env
36 puertos:
Veamos estos cambios:
• Línea 11: El recuento de réplicas se establece en 3.
• Línea 8-10 y 14-16: Las etiquetas están configuradas para aplicación: libro de visitas y tier: frontend.
• Línea 20: interfaz de gb: v4 se utiliza como imagen.
Ahora ha creado la implementación de front-end. Ahora necesita exponerlo como un

servicio.
Exponiendo el servicio front-end
Hay varias formas de definir un servicio de Kubernetes. Los dos servicios de Redis que creamos
eran del tipo ClusterIP. Esto significa que están expuestos en una IP a la que solo se puede acceder
desde el clúster, como se muestra en Figura 3.12:
Figura 3.12: Servicio de Kubernetes de tipo ClusterIP

Otro tipo de servicio es el tipo NodePort. Este servicio estaría expuesto en un puerto estático en
cada nodo como se muestra en Figura 3.13:
Figura 3.13: Servicio de Kubernetes de tipo NodePort

Un último tipo, que usaremos en nuestro ejemplo, es el LoadBalancer tipo. Esto creará un Equilibrador de
carga de Azure que obtendrá una IP pública que podemos usar para conectarnos, como se muestra en Figura
3.14:
Figura 3.14: Servicio de Kubernetes de tipo LoadBalancer
El siguiente código nos ayudará a comprender cómo se expone un servicio front-end:

1 apiVersion: v1
2 tipo: Servicio
3 metadatos:
4 nombre: frontend
5 etiquetas:
7 tier: frontend
8 Especificaciones:
9 # comente o elimine la siguiente línea si desea usar un

LoadBalancer
10 # tipo: NodePort # línea comentada

11 # si su clúster lo admite, descomente lo siguiente para

crear automáticamente
12 # una IP externa con equilibrio de carga para el servicio frontend.
13 tipo: LoadBalancer # línea sin comentar 14
puertos:
15 - puerto: 80
dieciséis selector:
18 tier: frontend
• Ahora que ha visto cómo se expone un servicio de front-end, hagamos que la aplicación
del libro de visitas esté lista para su uso con los siguientes pasos:
1. Para crear el servicio, ejecute el siguiente comando:

kubectl create -f frontend-service.yaml
Este paso tarda algún tiempo en ejecutarse cuando lo ejecuta por primera vez. En segundo plano, Azure
debe realizar un par de acciones para que funcione sin problemas. Tiene que crear un equilibrador de
carga de Azure y una IP pública y establecer las reglas de reenvío de puertos para reenviar el tráfico en el
puerto. 80 a los puertos internos del clúster.
2. Ejecute lo siguiente hasta que haya un valor en el IP EXTERNA columna:

Esto debería mostrar la salida que se muestra en Figura 3.15:
Figura 3.15: Salida que muestra un valor para IP externa después de un tiempo
3. En Azure Portal, si hace clic en Todos los recursos y filtrar en Balanceador de carga, tú
verá un Balanceador de carga de kubernetes. Al hacer clic en él, se muestra algo similar a
Figura 3.16. Las secciones resaltadas le muestran que hay una regla de equilibrio de carga que
acepta tráfico en el puerto. 80 y tienes 2 direcciones IP públicas:
Figura 3.16: Visualización del equilibrador de carga de Kubernetes en Azure Portal
Si hace clic en las dos direcciones IP públicas, verá ambas direcciones IP vinculadas
a su clúster. Uno de ellos será la dirección IP de su servicio real; el otro es utilizado
por AKS para realizar conexiones salientes.
Nota
Azure tiene dos tipos de balanceadores de carga: básico y estándar.
Las máquinas virtuales detrás de un equilibrador de carga básico pueden realizar conexiones salientes sin
ninguna configuración específica. Las máquinas virtuales detrás de un equilibrador de carga estándar (que
ahora es el predeterminado para AKS) necesitan una configuración específica para realizar conexiones
salientes. Es por eso que ve una segunda dirección IP configurada.
¡Finalmente estamos listos para poner en acción nuestra aplicación de libro de visitas!
La aplicación del libro de visitas en acción
Escriba la IP pública del servicio en su navegador favorito. Debería obtener el resultado que se
muestra en Figura 3.17:
Figura 3.17: La aplicación del libro de visitas en acción
Continúe y grabe sus mensajes. Serán salvados. Abra otro navegador y escriba la
misma IP; verá todos los mensajes que escribió.
Felicitaciones: ha completado su primera aplicación de Kubernetes nativa de la nube, de varios niveles y

completamente implementada.
Para conservar recursos en sus máquinas virtuales de prueba gratuita, es mejor eliminar las
implementaciones creadas para ejecutar la siguiente ronda de implementaciones mediante los
siguientes comandos:
kubectl eliminar interfaz de implementación redis-master redis-slave

kubectl eliminar interfaz de servicio redis-master redis-slave
En el transcurso de las secciones anteriores, implementó un clúster de Redis y una
aplicación web de acceso público. Ha aprendido cómo se vinculan las
implementaciones, ReplicaSets y Pods, y cómo Kubernetes usa el
Servicio Objeto para enrutar el tráfico de la red. En la siguiente sección de este capítulo, utilizará Helm
para implementar una aplicación más compleja sobre Kubernetes.
Instalación de aplicaciones complejas de Kubernetes con Helm

En la sección anterior, usamos archivos YAML estáticos para implementar nuestra aplicación.
Al implementar aplicaciones más complicadas, en múltiples entornos (como dev / test / prod),
puede resultar engorroso editar manualmente archivos YAML para cada entorno. Aquí es
donde entra en juego la herramienta Helm.
Helm es el administrador de paquetes de Kubernetes. Helm lo ayuda a implementar, actualizar

y administrar aplicaciones de Kubernetes a escala. Para ello, escribe algo llamado Helm Charts.
Puede pensar en Helm Charts como archivos YAML de Kubernetes parametrizados. Si piensa
en los archivos YAML de Kubernetes que escribimos en la sección anterior, esos archivos eran
estáticos. Debería acceder a los archivos y editarlos para realizar cambios.
Los gráficos de Helm le permiten escribir archivos YAML con ciertos parámetros en ellos, que puede establecer
dinámicamente. Esta configuración de los parámetros se puede realizar a través de un archivo de valores o como una
variable de línea de comandos cuando implementa el gráfico.
Finalmente, con Helm, no es necesario que usted mismo escriba los gráficos de Helm; también
puede utilizar una rica biblioteca de gráficos de Helm preescritos e instalar software popular en su
clúster a través de un comando simple como helm install --name my-release stable / mysql.
Esto es exactamente lo que va a hacer en la siguiente sección. Instalará WordPress en su clúster

emitiendo solo dos comandos. En los siguientes capítulos, también se sumergirá en los gráficos de
timón personalizados que editará.
Nota
El 13 de noviembre de 2019 se lanzó la primera versión estable de Helm v3. Usaremos Helm v3 en los
siguientes ejemplos. La mayor diferencia entre Helm v2 y Helm v3 es que Helm v3 es una herramienta
totalmente del lado del cliente que ya no requiere la herramienta del lado del servidor llamada caña
del timón.
Si desea una introducción más completa a la redacción de sus propios gráficos de Helm, puede
consultar la siguiente publicación de blog de uno de los autores de este libro: https: // blog.
nillsf.com/index.php/2019/11/23/writing-a-helm-v3-chart/ .
Comencemos instalando WordPress en su clúster usando Helm. En esta sección, también aprenderá sobre
el almacenamiento persistente en Kubernetes.
Instalación de aplicaciones complejas de Kubernetes con Helm | 75
Instalación de WordPress usando Helm
Como se mencionó en la introducción, Helm tiene una rica biblioteca de gráficos de Helm escritos previamente. Para
acceder a esta biblioteca, deberá agregar un repositorio a su cliente Helm:
1. Agregue el repositorio que contiene los gráficos de Helm estables con el siguiente comando:
helm repo agregar estable https://kubernetes-charts.storage.googleapis.com/
2. Para instalar WordPress, ejecutaremos el siguiente comando:

helm instalar handsonakswp estable / wordpress
Esta ejecución hará que Helm instale el gráfico detallado en https://github.com/ helm /
charts / tree / master / stable / wordpress .
Helm tarda algún tiempo en instalarse y en aparecer el sitio. Veamos un concepto

clave, PersistentVolumeClaims, mientras se carga el sitio. Después de cubrir esto,
volveremos y veremos nuestro sitio que se creó.
PersistentVolumeClaims
Un proceso requiere computación, memoria, red y almacenamiento. En el ejemplo del libro de visitas, vimos
cómo Kubernetes nos ayuda a abstraer la computación, la memoria y la red. Los mismos archivos YAML
funcionan en todos los proveedores de la nube, incluida una configuración específica de la nube de
equilibradores de carga de cara al público. El ejemplo de WordPress muestra cómo la última pieza, a saber, el
almacenamiento, se extrae del proveedor de nube subyacente.
En este caso, el gráfico de timón de WordPress depende del gráfico de timón de MariaDB ( https: //
github.com/helm/charts/tree/master/stable/mariadb ) para la instalación de su base de datos.
A diferencia de las aplicaciones sin estado, como nuestras interfaces, MariaDB requiere un manejo cuidadoso
del almacenamiento. Para que Kubernetes maneje cargas de trabajo con estado, tiene un objeto específico
llamado StatefulSet. Un StatefulSet ( https://kubernetes.io/docs/concepts/workloads/ controllers / statefulset / )
es como una implementación con la capacidad adicional de realizar pedidos y la singularidad de los Pods. Esto
significa que Kubernetes se asegurará de que el Pod y su almacenamiento se mantengan juntos. Otra forma en
que StatefulSets ayuda es con la asignación de nombres coherentes a los pods en un StatefulSet. Los Pods se
nombran < nombre-pod> - #, donde # comienza desde 0 para el primer Pod, y 1 para el segundo Pod.
Al ejecutar el siguiente comando, puede ver que MariaDB tiene un número predecible
adjunto, mientras que la implementación de WordPress tiene un número aleatorio adjunto al
final:
Esto generará la salida que se muestra en Figura 3.18:
Figura 3.18: Salida que muestra un número predecible para MariaDB Pod, mientras que un nombre aleatorio para
el Pod de WordPress
La numeración refuerza la naturaleza efímera de los pods de implementación frente a los pods
de StatefulSet.
Otra diferencia es cómo se maneja la eliminación de pod. Cuando se elimina un pod de implementación,
Kubernetes lo lanzará de nuevo en cualquier lugar que pueda, mientras que cuando se elimina un pod
StatefulSet, Kubernetes lo relanzará solo en el nodo en el que se estaba ejecutando. Reubicará el pod
solo si el nodo se elimina del clúster de Kubernetes.
A menudo, querrá adjuntar almacenamiento a un StatefulSet. Para lograr esto, un StatefulSet

requiere un volumen persistente. Este volumen puede estar respaldado por muchos
mecanismos (incluidos bloques, como Azure Blob, EBS e iSCSI, y sistemas de archivos de red,
como AFS, NFS y GlusterFS). Por favor refiérase a https://Kubernetes.io/docs/concepts/ storage /
volume / # persistentvolumeclaim para más información.
StatefulSets requiere un volumen aprovisionado previamente o un volumen aprovisionado

dinámicamente manejado por un PersistentVolumeClaim (PVC). En nuestro ejemplo, estamos usando
un PVC. Un PVC proporciona una abstracción sobre el mecanismo de almacenamiento subyacente.
Veamos lo que MariaDB Helm Chart hizo por nosotros ejecutando lo siguiente:
kubectl obtener conjuntos de estado
Esto nos mostrará algo similar a Figura 3.19:
Figura 3.19: Salida que muestra el StatefulSet que creó los pods MariaDB
Echemos un vistazo más en profundidad exportando la definición YAML de nuestro StatefulSet:
kubectl get statefulset -o yaml> código

mariadbss.yaml mariadbss.yaml
Veamos las partes más relevantes de ese archivo YAML. El código se ha truncado para
mostrar solo las partes más relevantes:
1 apiVersion: v1
2 artículos:
3 - apiVersion: aplicaciones / v1
4 tipo: StatefulSet
...
106 volumeMounts:
107 - mountPath: / bitnami / mariadb

108 nombre: datos
...
128 volumeClaimTemplates:
129 - metadatos:
130 creationTimestamp: nulo

131 etiquetas:
132 aplicación: mariadb
133 componente: maestro
134 herencia: Helm

135 lanzamiento: handsonakswp
136 nombre: datos
138 accessModes:
139 - ReadWriteOnce
140 recursos:
141 peticiones:
142 almacenamiento: 8Gi
143 volumeMode: Sistema de archivos
...
La mayoría de los elementos del código anterior se han cubierto anteriormente en la

implementación. En el siguiente bloque, destacaremos las diferencias clave, para echar un vistazo
solo al PVC:
Nota
El PVC puede ser utilizado por cualquier Pod, no solo por los Pods StatefulSet.
Analicemos los diferentes elementos del código anterior en detalle:
• Línea 4: Esta línea indica el StatefulSet declaración.

• Líneas 106-108: Monte el volumen definido como datos y móntelo debajo del /
bitnami / mariadb sendero.
• Líneas 128-143: Declare el PVC. Tenga en cuenta específicamente:
• Línea 136: Esta línea le da el nombre datos, que se reutiliza en la línea 108.
• Línea 139: Da el modo de acceso ReadWriteOnce, que creará almacenamiento en bloque, que
en Azure es un disco.
• Línea 142: Define el tamaño del disco.
Según la información anterior, Kubernetes solicita y vincula dinámicamente un volumen 8Gi a este
pod. En este caso, se usa el aprovisionador de almacenamiento dinámico predeterminado
respaldado por el disco de Azure. Azure configuró el aprovisionador dinámico cuando creamos el
clúster. Para ver las clases de almacenamiento disponibles en su clúster, puede ejecutar el siguiente
comando:
kubectl obtener clase de almacenamiento
Esto le mostrará una salida similar a Figura 3.20:
Figura 3.20: Salida que muestra las diferentes clases de almacenamiento en su clúster
Podemos obtener más detalles sobre el PVC ejecutando lo siguiente:

kubectl obtener pvc
La salida generada se muestra en Figura 3.21:
Figura 3.21: Diferentes PVC en el clúster
Cuando solicitamos almacenamiento en la descripción de StatefulSet (líneas 128-143), Kubernetes realizó

operaciones específicas del disco de Azure para obtener el disco de Azure con 8 GiB de almacenamiento.
Si copia el nombre del PVC y lo pega en la barra de búsqueda de Azure, debería encontrar
el disco que se creó:
Figura 3.22: Vincular el disco a un PVC
El concepto de PVC abstrae las especificaciones de almacenamiento del proveedor en la nube. Esto permite que
la misma plantilla de Helm funcione en Azure, AWS o GCP. En AWS, estará respaldado por Tienda de bloques
elásticos (EBS), y en GCP estará respaldado por Persistent Disk.
Además, tenga en cuenta que los PVC se pueden implementar sin usar Helm.
Comprobando la implementación de WordPress
Después de nuestro análisis de los PVC, volvamos a verificar nuestra implementación de Helm. Podemos
verificar el estado de la implementación usando:
timón ls
Esto debería devolver la salida que se muestra en Figura 3.23:
Figura 3.23: Helm muestra que nuestra aplicación de WordPress se ha implementado
Podemos obtener más información de nuestra implementación en Helm usando el siguiente comando:
estado del timón handsonakswp
Esto devolverá la salida que se muestra en Figura 3.24:
Figura 3.24: Obtener más detalles sobre la aplicación
Esto nos muestra que nuestro gráfico se implementó con éxito. También muestra más información sobre
cómo podemos conectarnos a nuestro sitio. No usaremos estos pasos por ahora; revisaremos estos pasos
en Capítulo 5, Manejo de fallas comunes en AKS, en la sección donde cubrimos la solución de problemas
de montaje de almacenamiento. Por ahora, veremos todo lo que Helm creó para nosotros:

Esto generará una salida similar a Figura 3.25:
Figura 3.25: Salida que muestra todos los objetos creados por Helm
Si aún no tiene una IP externa, espere un par de minutos y vuelva a intentar el

comando.
Luego puede continuar y conectarse a su IP externa y acceder a su sitio de WordPress. La

siguiente captura de pantalla es la salida resultante:
Figura 3.26: Sitio de WordPress que se muestra al conectarse con la IP externa

Para asegurarnos de no tener problemas en los siguientes capítulos, eliminemos el sitio de

WordPress. Esto se puede hacer de la siguiente manera:
helm eliminar handsonakswp
Por diseño, nuestros PVC no se eliminarán. Esto asegura que se mantengan los datos persistentes. Como no
tenemos datos persistentes, también podemos eliminarlos de forma segura:
kubectl eliminar pvc --todos
Nota
Tenga mucho cuidado al ejecutar kubectl eliminar <objeto> --todos ya que eliminará todos los
objetos en un espacio de nombres. Esto no se recomienda en un clúster de producción.
En esta sección, ha implementado un sitio completo de WordPress utilizando Helm. También aprendió
cómo Kubernetes maneja el almacenamiento persistente mediante PVC.
Resumen
En este capítulo, implementamos dos aplicaciones. Comenzamos el capítulo implementando la
aplicación del libro de visitas. Durante esa implementación, analizamos los detalles de los pods, los
ReplicaSets y las implementaciones. También usamos configuración dinámica usando ConfigMaps.
Finalmente, analizamos cómo se utilizan los servicios para enrutar el tráfico a las aplicaciones
implementadas.
La segunda aplicación que implementamos fue una aplicación de WordPress. Lo implementamos a

través del administrador de paquetes Helm. Como parte de esta implementación, se utilizaron PVC y
exploramos cómo se utilizaron en el sistema.
En el próximo capítulo, analizaremos el escalado de aplicaciones y el clúster en sí.

Primero veremos el escalado manual y automático de la aplicación, y luego veremos el
escalado manual y automático del clúster en sí. Finalmente, explicaremos diferentes
formas en las que se pueden actualizar las aplicaciones en Kubernetes.
Construyendo escalable
4
aplicaciones
Al ejecutar una aplicación, la capacidad de escalar y actualizar su aplicación es fundamental. Escalada
es necesario para manejar cargas adicionales con su aplicación, mientras que se requiere una
actualización para mantener su aplicación actualizada y poder introducir nuevas funciones.
El escalado bajo demanda es uno de los beneficios clave del uso de aplicaciones nativas de la nube.
También ayuda a optimizar los recursos para su aplicación. Si el componente de front-end encuentra
cargas pesadas, puede escalar el front-end solo, mientras mantiene la misma cantidad de instancias de
backend. Puede aumentar o reducir el número / tamaño de Máquinas virtuales (VM)
requerido dependiendo de su carga de trabajo y horas pico de demanda. Este capítulo cubrirá en detalle
ambas dimensiones de la escala.
86 | Construyendo aplicaciones escalables
En este capítulo, le mostraremos cómo escalar la aplicación de libro de visitas de muestra que
presentamos en Capítulo 3, Implementación de aplicaciones en AKS. Primero escalaremos esta
aplicación usando comandos manuales, y luego la escalaremos automáticamente usando el
Escalador automático de pod horizontal (HPA). El objetivo es hacer que se sienta cómodo con kubectl,
que es una herramienta importante para administrar aplicaciones que se ejecutan en la parte superior del
Servicio de Azure Kubernetes (AKS). Después de escalar la aplicación en sí, también escalaremos el
clúster. Primero escalaremos el clúster manualmente y luego usaremos el escalador automático del
clúster para escalar automáticamente el clúster. Además, en este capítulo, obtendrá una breve
introducción sobre cómo puede actualizar las aplicaciones que se ejecutan sobre AKS.
En este capítulo, cubriremos los siguientes temas:
• Escalar su aplicación
• Escalar su clúster
• Actualización de su aplicación
Comenzaremos este capítulo discutiendo las diferentes dimensiones cuando se trata de

escalar aplicaciones sobre AKS.
Nota
En el capítulo anterior, clonamos los archivos de ejemplo en Cloud Shell. Si no hizo esto en ese
entonces, le recomendamos que lo haga ahora:
clon de git https://github.com/PacktPublishing/Hands-On-Kubernetes-on-Azure--Second-Edition/tree/Seco
Para este capítulo, navegue hasta el Capítulo 04 directorio:
cd capítulo 04
Escalando su aplicación | 87
Escalando su aplicación
Hay dos dimensiones de escala para aplicaciones que se ejecutan sobre AKS. La primera dimensión de
escala es la cantidad de pods que tiene una implementación, mientras que la segunda dimensión de escala
en AKS es la cantidad de nodos en el clúster.
Al agregar pods adicionales a una implementación, también conocido como escalado horizontal, agrega
potencia de procesamiento adicional a la aplicación implementada. Puede escalar sus aplicaciones
manualmente o hacer que Kubernetes se encargue de esto automáticamente a través de HPA. La HPA
observará métricas como la CPU para determinar si es necesario agregar Pods a su implementación.
La segunda dimensión de escala en AKS es la cantidad de nodos en el clúster. La cantidad de nodos en un

clúster define cuánta CPU y memoria están disponibles para todas las aplicaciones que se ejecutan en ese
clúster. Puede escalar su clúster manualmente cambiando la cantidad de nodos, o puede usar el escalador
automático del clúster para escalar automáticamente su clúster. El escalador automático del clúster
observará el clúster en busca de pods que no se puedan programar debido a limitaciones de recursos. Si
los pods no se pueden programar, agregará nodos al clúster para garantizar que sus aplicaciones puedan
ejecutarse.
Ambas dimensiones de la escala se cubrirán en este capítulo. En esta sección, aprenderá

cómo escalar su aplicación. Primero, escalará su aplicación manualmente y luego, escalará
su aplicación automáticamente.
Implementando el escalado de su aplicación
Para demostrar el escalado manual, usemos el ejemplo del libro de visitas que usamos en el
capítulo anterior. Siga estos pasos para aprender a implementar el escalado manual:
1. Instale el libro de visitas ejecutando el kubectl crear comando en el Azure

línea de comando:
2. Después de haber ingresado el comando anterior, debería ver algo similar, como se muestra
en Figura 4.1, en la salida de la línea de comandos:
Figura 4.1: Inicio de la aplicación del libro de visitas

3. En este momento, ninguno de los servicios es de acceso público. Podemos verificar esto
ejecutando el siguiente comando:
kubectl obtener svc
4. Figura 4.2 muestra que ninguno de los servicios tiene una IP externa:
Figura 4.2: Salida que no muestra ninguno de los servicios que tienen una IP pública
5. Para probar nuestra aplicación, la expondremos públicamente. Para ello, presentaremos un

nuevo comando que le permitirá editar el servicio en Kubernetes sin tener que cambiar el
archivo en su sistema de archivos. Para iniciar la edición, ejecute el siguiente comando:
Interfaz de servicio de edición de kubectl
6. Esto abrirá un vi medio ambiente. Navega hasta la línea que ahora dice tipo: ClusterIP
(línea 27) y cámbielo a tipo: LoadBalancer, como se muestra en Figura 4.3. Para hacer ese cambio,
presione el I botón, escriba sus cambios, presione el Esc botón, escriba: wq !, y luego golpea Ingresar para
guardar los cambios:
Figura 4.3: Cambiar esta línea para escribir: LoadBalancer

7. Una vez que se guardan los cambios, puede ver el objeto de servicio hasta que la IP pública esté
disponible. Para hacer esto, escriba lo siguiente:
kubectl get svc -w
8. Tardará un par de minutos en mostrarte la IP actualizada. Una vez que vea la IP pública
correcta, puede salir del reloj comando golpeando Ctrl + C (comando + C en Mac):
Figura 4.4: Salida que muestra el servicio de front-end obteniendo una IP pública
9. Escriba la dirección IP del resultado anterior en la barra de navegación de su navegador de la siguiente

manera: http: // <IP-EXTERNO> /. El resultado de esto se muestra en Figura 4.5:
Figura 4.5: Navegue hasta la aplicación del libro de visitas
La muestra familiar del libro de visitas debe estar visible. Esto muestra que ha
accedido públicamente al libro de visitas con éxito.
Ahora que ha implementado la aplicación del libro de visitas, puede comenzar a escalar los
diferentes componentes de la aplicación.
Escalar el componente frontal del libro de visitas
Kubernetes nos brinda la capacidad de escalar cada componente de una aplicación de forma
dinámica. En esta sección, le mostraremos cómo escalar el front-end de la aplicación del libro de
visitas. Esto hará que Kubernetes agregue pods adicionales a la implementación:
implementación de escala kubectl / frontend --replicas = 6
Puede establecer la cantidad de réplicas que desee y Kubernetes se encarga del resto. Incluso
puede reducirlo a cero (uno de los trucos que se utilizan para recargar la configuración cuando
la aplicación no admite la recarga dinámica de la configuración). Para verificar que la escala
general funcionó correctamente, puede usar el siguiente comando:
Esto debería darle una salida como se muestra en Figura 4.6:
Figura 4.6: Diferentes pods que se ejecutan en la aplicación del libro de visitas después de escalar horizontalmente
Como puede ver, el servicio de front-end se escaló a seis Pods. Kubernetes también distribuye
estos pods en varios nodos del clúster. Puede ver los nodos en los que se está ejecutando con
el siguiente comando:
kubectl get pods -o wide
Figura 4.7: Muestra en qué nodos se ejecutan los pods

En esta sección, ha visto lo fácil que es escalar pods con Kubernetes. Esta capacidad proporciona una
herramienta muy poderosa para que no solo ajuste dinámicamente los componentes de su
aplicación, sino que también brinde aplicaciones resistentes con capacidades de conmutación por
error habilitadas al ejecutar varias instancias de componentes al mismo tiempo. Sin embargo, no
siempre querrá escalar manualmente su aplicación. En la siguiente sección, aprenderá cómo escalar
automáticamente su aplicación.
Usando el HPA
Escalar manualmente es útil cuando está trabajando en su clúster. En la mayoría de los casos, sin embargo,
querrá que ocurra algún tipo de autoescalado en su aplicación. En Kubernetes, puede configurar el ajuste de
escala automático de su implementación mediante un objeto llamado Escalador automático de pod horizontal
(HPA).
La HPA monitorea las métricas de Kubernetes a intervalos regulares y, según las reglas que usted defina,
escala automáticamente su implementación. Por ejemplo, puede configurar HPA para agregar pods
adicionales a su implementación una vez que la utilización de la CPU de su aplicación sea superior al 50%.
En esta sección, configurará HPA para escalar el front-end de la aplicación

automáticamente:
1. Para iniciar la configuración, primero reduzcamos manualmente nuestra implementación a 1

instancia:
implementación de escala kubectl / frontend --replicas = 1
2. A continuación, crearemos un HPA. Abra el editor de código en Cloud Shell escribiendo

código hpa.yaml e ingrese el siguiente código:
1 apiVersion: ajuste de escala automático / v2beta1

2 tipos: HorizontalPodAutoscaler
3 metadatos:
4 nombre: escalador de frontend
5 especificaciones:
6 scaleTargetRef:
7 apiVersion: extensions / v1beta1
8 tipo: Despliegue
9 nombre: frontend
10 minRéplicas: 1
11 maxReplicas: 10
12 métrica:
13 - tipo: Recurso
14 recurso:
15 nombre: cpu
dieciséis targetAverageUtilization: 25
Investiguemos qué está configurado en este archivo:
• Línea 2: Aquí, definimos que necesitamos HorizontalPodAutoscaler.

• Líneas 6-9: Estas líneas definen la implementación que queremos autoescalar.
• Líneas 10-11: Aquí, configuramos los pods mínimos y máximos en nuestra
implementación.
• Líneas 12-16: Aquí, definimos la métrica que Kubernetes supervisará para

realizar el escalado.
3. Guarde este archivo y cree el HPA con el siguiente comando:

kubectl create -f hpa.yaml
Esto creará nuestro escalador automático. Puedes ver tu escalador automático con el siguiente
comando:
kubectl obtener hpa
Esto inicialmente generará algo como se muestra en Figura 4.8:
Figura 4.8: El objetivo desconocido muestra que la HPA aún no está lista
La HPA tarda unos segundos en leer las métricas. Espere a que el retorno de la
HPA se vea algo similar al resultado que se muestra en Figura 4.9:
Figura 4.9: Una vez que el objetivo muestra un porcentaje, el HPA está listo
4. Ahora seguiremos adelante y haremos dos cosas: primero, observaremos nuestros Pods para ver si se
crean nuevos Pods. Luego, crearemos un nuevo shell y crearemos algo de carga para nuestro
sistema. Comencemos con la primera tarea: ver nuestros pods:
kubectl get pods -w
Esto monitoreará continuamente los Pods que se crean o terminan.

Creemos ahora algo de carga en un nuevo shell. En Cloud Shell, presione el botón para abrir un nuevo
shell:
Figura 4.10: Use este botón para abrir un nuevo Cloud Shell
Esto abrirá una nueva pestaña en su navegador con una nueva sesión en Cloud Shell. Generaremos
algo de carga para nuestra aplicación desde esta pestaña.
5. A continuación, usaremos un programa llamado Oye para generar esta carga. Oye es un pequeño
programa que envía cargas a una aplicación web. Podemos instalar y ejecutar Oye usando los
exportar GOPATH = ~ / go
export PATH = $ GOPATH / bin: $ PATH
ve a buscar -u github.com/rakyll/hey
hey -z 20m http: // <external-ip>
El Oye El programa ahora intentará crear hasta 20 millones de conexiones a nuestro

front-end. Esto generará cargas de CPU en nuestro sistema, lo que hará que HPA comience a
escalar nuestra implementación. Tomará un par de minutos para que esto active una acción
de escala, pero en cierto punto, debería ver que se crean múltiples pods para manejar la
carga adicional como se muestra en Figura 4.11:
Figura 4.11: HPA inicia los nuevos pods

En este punto, puede continuar y matar al Oye programa pulsando Ctrl + C

( comando + C en Mac).
6. Echemos un vistazo más de cerca a lo que hizo nuestro HPA ejecutando el siguiente comando:
kubectl describe hpa
Podemos ver algunos puntos interesantes en el describir operación, como se muestra en

Figura 4.12:
Figura 4.12: Vista detallada de la HPA
Las anotaciones en Figura 4.12 se explican de la siguiente manera:
1: Esto le muestra la utilización actual de la CPU (132%) frente a la deseada (25%). El

Es probable que la utilización actual de la CPU sea diferente en su situación.
2: Esto le muestra que el recuento de réplicas deseado actual es mayor que el máximo real
que habíamos configurado. Esto garantiza que una única implementación no consuma
todos los recursos del clúster.
3: Esto le muestra las acciones de escalado que realizó la HPA. Primero escaló a 4, luego a
8 y luego a 10 pods en la implementación.
7. Si espera un par de minutos, el HPA debería comenzar a reducirse. Puede realizar un seguimiento
de esta operación de reducción mediante el siguiente comando:
kubectl obtener hpa -w

Escalando su clúster | 95
Esto hará un seguimiento de la HPA y le mostrará la reducción gradual de la implementación, como

se muestra en Figura 4.13:
Figura 4.13: Observación de la reducción de escala de HPA
8. Antes de pasar a la siguiente sección, limpiemos los recursos que creamos en esta
sección:
kubectl eliminar -f hpa.yaml

kubectl eliminar -f guestbook-all-in-one.yaml
En esta sección, primero escalamos manualmente y luego automáticamente nuestra aplicación. Sin
embargo, los recursos del clúster eran estáticos; ejecutamos esto en un clúster de dos nodos. En muchos
casos, también puede quedarse sin recursos en el clúster. En la siguiente sección, trataremos ese
problema y explicaremos cómo puede escalar su clúster de AKS usted mismo.
Escalando su clúster
En la sección anterior, tratamos de escalar la aplicación que se ejecuta en la parte superior de un clúster. En
esta sección, explicaremos cómo puede escalar el clúster real que está ejecutando. Primero discutiremos cómo
puede escalar manualmente su clúster. Comenzaremos reduciendo la escala de nuestro clúster a un nodo.
Luego, configuraremos el escalador automático del clúster. El escalador automático del clúster supervisará
nuestro clúster y escalará horizontalmente cuando haya pods que no se puedan programar en nuestro clúster.
Escalar manualmente su clúster
Puede escalar manualmente su clúster de AKS configurando un número estático de nodos para el
clúster. El escalado de su clúster se puede realizar a través del portal de Azure o mediante la línea de
comandos.
En esta sección, le mostraremos cómo puede escalar manualmente su clúster reduciendo el

clúster a un nodo. Esto hará que Azure elimine uno de los nodos de su clúster. Primero, la carga
de trabajo en el nodo que está a punto de eliminarse se reprogramará en el otro nodo. Una vez
que la carga de trabajo se reprograma de forma segura, el nodo se eliminará de su clúster y
luego la máquina virtual se eliminará de Azure.
Para escalar su clúster, siga estos pasos:
1. Abra Azure Portal y vaya a su clúster. Una vez allí, ve a Grupos de nodos y
haga clic en el número de abajo Recuento de nodos, como se muestra en Figura 4.14:
Figura 4.14: Escalado manual del clúster
2. Esto abrirá una ventana emergente que le dará la opción de escalar su clúster. Para nuestro
ejemplo, reduciremos nuestro clúster a un nodo, como se muestra en Figura 4.15:
Figura 4.15: Ventana emergente que confirma el nuevo tamaño del clúster
3. Pulsa el Aplicar en la parte inferior de la pantalla para guardar estos ajustes. Esta voluntad
hacer que Azure elimine un nodo de su clúster. Este proceso tardará unos 5 minutos en
completarse. Puede seguir el progreso haciendo clic en el icono de notificación en la parte
superior de Azure Portal de la siguiente manera:
Figura 4.16: Se puede seguir el escalado del clúster mediante las notificaciones en Azure Portal
Una vez que se haya completado esta operación de reducción, relanzaremos nuestra aplicación de
libro de visitas en este pequeño clúster:
En la siguiente sección, escalaremos horizontalmente el libro de visitas para que ya no se pueda ejecutar en nuestro pequeño
clúster. Luego, configuraremos el escalador automático del clúster para escalar horizontalmente nuestro clúster.
Escala tu clúster con el escalador automático de clústeres
En esta sección, exploraremos el escalador automático del clúster. El escalador automático del clúster
supervisará las implementaciones en su clúster y escalará su clúster para cumplir con los requisitos de su
aplicación. El escalador automático del clúster observa la cantidad de pods en tu clúster que no se pueden
programar debido a recursos insuficientes. Primero forzaremos nuestra implementación para que tenga
pods que no se pueden programar, y luego configuraremos el escalador automático del clúster para escalar
automáticamente nuestro clúster.
Para forzar a nuestro clúster a quedarse sin recursos, escalaremos, manualmente, redis-esclavo
despliegue. Para hacer esto, use el siguiente comando:
implementación de escala kubectl redis-slave - réplicas 5
Puede verificar que este comando fue exitoso al observar los pods en nuestro clúster:
Esto debería mostrarle algo similar a una salida generada en Figura 4.17:
Figura 4.17: Cuatro de los cinco pods están pendientes, lo que significa que no se pueden programar
Como puede ver, ahora tenemos cuatro Pods en un Pendiente Expresar. El Pendiente El estado en
Kubernetes significa que ese Pod no se puede programar en un nodo. En nuestro caso, esto se debe a
que el clúster se quedó sin recursos.
Ahora configuraremos el escalador automático del clúster para escalar automáticamente nuestro clúster.
Como en el escalado manual de la sección anterior, hay dos formas de configurar el escalador automático
del clúster. Puede configurarlo a través del portal de Azure, de forma similar a como hicimos el escalado
manual, o puede configurarlo usando el interfaz de línea de comandos (CLI).
En este ejemplo, usaremos la CLI para habilitar el escalador automático del clúster. El siguiente comando
configurará el escalador automático del clúster para nuestro clúster:
az aks nodepool update --enable-cluster-autoscaler \

- g rg-handsonaks --cluster-name handsonaks \
- - nombre agentpool --min-count 1 --max-count 3
Este comando configura el escalador automático del clúster en el grupo de nodos que tenemos en
nuestro clúster. Lo configura para tener un mínimo de un nodo y un máximo de tres nodos. Esto tardará
un par de minutos en configurarse.
Una vez que el escalador automático del clúster está configurado, puedes verlo en acción mediante el siguiente
comando para observar la cantidad de nodos en tu clúster:
kubectl obtener nodos -w

El nuevo nodo tardará unos 5 minutos en aparecer y convertirse Listo en el clúster. Una vez que
el nuevo nodo está Listo, puedes dejar de mirar los nodos pulsando Ctrl + C
( comando + C en Mac). Debería ver una salida similar a la de Figura 4.18:
Figura 4.18: El nuevo nodo se une al clúster
El nuevo nodo debe garantizar que nuestro clúster tenga recursos suficientes para programar la
ampliación redis-esclavo despliegue. Para verificar esto, ejecute el siguiente comando para verificar el
estado de los pods:
Esto debería mostrarle todos los Pods en un Corriendo indicar lo siguiente:
Figura 4.19: Todos los pods están ahora en estado de ejecución

Ahora limpiaremos los recursos que creamos, deshabilitaremos el escalador automático del clúster y nos
aseguraremos de que nuestro clúster tenga dos nodos para los siguientes ejemplos. Para hacer esto, use los

az aks nodepool update --disable-cluster-autoscaler \
- g rg-handsonaks - cluster-name handsonaks --name agentpool
az aks nodepool scale --node-count 2 -g rg-handsonaks \
- - handsonaks de nombre de clúster --name agentpool
Nota
El último comando del ejemplo anterior le mostrará un error si el clúster ya tiene dos
nodos. Puede ignorar este error con seguridad.
En esta sección, primero reducimos manualmente nuestro clúster y luego usamos el escalador automático del
clúster para escalar horizontalmente nuestro clúster. Primero usamos Azure Portal para escalar horizontalmente el
clúster de forma manual y luego también usamos la CLI de Azure para configurar el escalador automático del
clúster. En la siguiente sección, veremos cómo podemos actualizar las aplicaciones que se ejecutan en AKS.
Actualización de su aplicación
El uso de implementaciones en Kubernetes hace que la actualización de una aplicación sea una operación
sencilla. Al igual que con cualquier actualización, debe tener buenas fallas en caso de que algo salga mal. La
mayoría de los problemas con los que se encontrará se producirán durante las actualizaciones. Se supone que
las aplicaciones nativas de la nube hacen que lidiar con esto sea relativamente fácil, lo cual es posible si tiene
un equipo de desarrollo muy sólido que adopte los principios de DevOps.
El informe State of DevOps ( https://services.google.com/fh/files/misc/state-ofdevops-2019.pdf ) ha

informado durante varios años que las empresas que tienen altas tasas de frecuencia de
implementación de software también tienen una mayor disponibilidad y estabilidad en sus aplicaciones.
Esto puede parecer contradictorio, ya que realizar implementaciones de software aumenta el riesgo de
problemas. Sin embargo, si se implementa con más frecuencia y se implementa mediante prácticas de
DevOps automatizadas, puede limitar el impacto de la implementación del software.
Actualización de su aplicación | 101
Hay varias formas de realizar actualizaciones en un clúster de Kubernetes. En esta sección,

exploraremos las siguientes formas de actualizar los recursos de Kubernetes:
• Actualización cambiando archivos YAML
• Actualización usando kubectl editar
• Actualización usando parche de kubectl
• Actualización usando Helm
Los métodos que describiremos en la siguiente sección funcionan muy bien si tiene aplicaciones sin estado. Si
tiene un estado almacenado en algún lugar, asegúrese de hacer una copia de seguridad de ese estado antes
de intentar algo.
Comencemos esta sección haciendo el primer tipo de actualización: cambiar archivos YAML.
Actualización cambiando archivos YAML
Para actualizar un servicio o implementación de Kubernetes, podemos actualizar el archivo de definición

de YAML real y aplicarlo a la aplicación implementada actualmente. Normalmente usamos kubectl crear para
crear recursos. Del mismo modo, podemos usar kubectl aplicar para realizar cambios en los recursos.
La implementación detecta los cambios (si los hay) y coincide con el Corriendo estado al
estado deseado. Veamos cómo se hace esto:
1. Comenzamos con nuestra aplicación de libro de visitas para demostrar este ejemplo:
2. Después de unos minutos, todos los Pods deberían estar funcionando. Realicemos nuestra primera
actualización cambiando el servicio de ClusterIP para LoadBalancer, como hicimos anteriormente en el
capítulo. Sin embargo, ahora editaremos nuestro archivo YAML en lugar de usar kubectl edit. Edite el
archivo YAML usando esto:
código libro de visitas-todo-en-uno.yaml

Descomente la línea 108 en este archivo para establecer el tipo como LoadBalancer y guarde el archivo. como se
Figura 4.20: Cambio de esta línea en el archivo YAML todo en uno del libro de visitas
3. Aplique el cambio como se muestra en el siguiente código:
kubectl apply -f libro de visitas-todo-en-uno.yaml
4. Ahora puede obtener la IP pública del servicio usando el siguiente comando:
kubectl obtener svc
Dale unos minutos y se te debería mostrar la IP como se muestra en Figura 4.21:
Figura 4.21: Salida que muestra una IP pública
5. Ahora haremos otro cambio. Reduciremos la línea de la imagen frontal en la línea

133 de imagen: gcr.io/google-samples/gb-frontend:v4 a lo siguiente:
imagen: gcr.io/google-samples/gb-frontend:v3
Este cambio se puede realizar abriendo la aplicación del libro de visitas en el editor
usando este comando familiar:
código libro de visitas-todo-en-uno.yaml
6. Ejecute el siguiente comando para realizar la actualización y observe cómo cambian los pods:
kubectl apply -f guestbook-all-in-one.yaml && kubectl get pods -w
7. Esto generará el siguiente resultado:
Figura 4.22: Se crean los pods de un nuevo ReplicaSet
Lo que puede ver aquí es que la versión anterior de los Pods (basada en el
ReplicaSet anterior) se cancela, mientras que se crea la nueva versión.
8. Corriendo eventos de kubectl get | grep ReplicaSet mostrará la actualización continua

estrategia que utiliza la implementación para actualizar las imágenes del front-end de la siguiente manera:
Figura 4.23: Supervisión de eventos de Kubernetes y filtrado para ver solo los eventos relacionados con ReplicaSet
Nota
En el ejemplo anterior, usamos una tubería, que se muestra con el | signo — y el grep mando.
Una tubería en Linux se usa para enviar la salida de un comando a la entrada de otro comando.
En nuestro caso, estamos enviando la salida de kubectl obtener eventos hacia grep mando.
grep es un comando en Linux que se usa para filtrar texto. En nuestro caso, estamos usando el grep
comando para mostrarnos solo las líneas que contienen la palabra ReplicaSet.
Aquí puede ver que el nuevo ReplicaSet se amplía, mientras que el antiguo se
reduce. También verá dos ReplicaSets para la interfaz, el nuevo reemplazando al
otro Pod a la vez:
kubectl obtener conjunto de réplicas
Esto mostrará una salida como se muestra en Figura 4.24:
Figura 4.24: Dos ReplicaSets diferentes
9. Kubernetes también mantendrá un historial de su implementación. Puede ver el historial de

implementación con este comando:
Interfaz de implementación del historial de implementación de kubectl
Esto generará una salida como se muestra en Figura 4.25:
Figura 4.25: Historial de implementación de la aplicación
10. Dado que Kubernetes mantiene un historial de nuestra implementación, esto también permite la reversión. Hagamos una
reversión de nuestra implementación:
implementación de kubectl deshacer la interfaz de implementación
Esto desencadenará una reversión. Esto significa que el nuevo ReplicaSet se reducirá
a cero instancias y el antiguo se volverá a escalar a tres instancias. Podemos verificar
esto usando el siguiente comando:
kubectl obtener conjunto de réplicas

La salida resultante es como se muestra en Figura 4.26:
Figura 4.26: El antiguo ReplicaSet ahora tiene tres Pods, y el nuevo se reduce a cero
Esto nos muestra, como se esperaba, que el ReplicaSet antiguo se reduce a

tres instancias y el nuevo se reduce a cero instancias.
11. Por último, limpiemos de nuevo ejecutando el kubectl eliminar mando:
¡Felicidades! Ha completado la actualización de una aplicación y una reversión a una

versión anterior.
En este ejemplo, ha utilizado kubectl aplicar para realizar cambios en su aplicación. De manera similar,
también puede usar kubectl editar para realizar cambios, que se explorarán en la siguiente sección.
Actualizar una aplicación con kubectl edit

Podemos realizar cambios en nuestra aplicación que se ejecuta en Kubernetes usando kubectl
edit. Usó esto anteriormente en este capítulo. Al correr kubectl editar, la vi Se abrirá el editor
para usted, lo que le permitirá realizar cambios directamente en el objeto en Kubernetes.
Reimplementemos nuestra aplicación de libro de visitas sin un balanceador de carga público y usemos kubectl
para crear el balanceador de carga:
1. Comenzará por implementar la aplicación del libro de visitas:
2. Para iniciar la edición, ejecute el siguiente comando:

3. Esto abrirá un vi medio ambiente. Navega hasta la línea que ahora dice tipo: ClusterIP
(línea 27) y cámbielo a tipo: LoadBalancer, como se muestra en Figura 4.27. Para hacer ese cambio,
presione el I botón, escriba sus cambios, presione el Esc botón, escriba: wq !, y luego golpea Ingresar para
guardar los cambios:
Figura 4.27: Cambiar esta línea para escribir: LoadBalancer
4. Una vez que se guardan los cambios, puede ver el objeto de servicio hasta que la IP pública esté
disponible. Para hacer esto, escriba lo siguiente:
kubectl get svc -w
5. Tardará un par de minutos en mostrarte la IP actualizada. Una vez que vea la IP pública
correcta, puede salir del reloj comando golpeando Ctrl + C (comando + C en Mac)
Esta es un ejemplo de uso kubectl editar para realizar cambios en un objeto de Kubernetes. Esta
El comando abrirá un editor de texto para realizar cambios de forma interactiva. Esto significa que debe
interactuar con el editor de texto para realizar los cambios. Esto no funcionará en un entorno
automatizado. Para realizar cambios automáticos, puede utilizar el parche de kubectl
mando.
Actualizar una aplicación con el parche kubectl
En el ejemplo anterior, usó un editor de texto para realizar los cambios en Kubernetes. En este
ejemplo, utilizará el parche de kubectl comando para realizar cambios en los recursos en
Kubernetes. El parche El comando es particularmente útil en sistemas automatizados, como en
un script o en un sistema de integración / implementación continua.
Hay dos formas principales de utilizar parche de kubectl, ya sea creando un archivo que contenga sus
cambios (llamado archivo de parche) o proporcionando los cambios en línea. Exploraremos ambos
enfoques. Primero, en este ejemplo, cambiaremos la imagen de la interfaz de v4 para v3 usando un
archivo de parche:
1. Inicie este ejemplo creando un archivo llamado frontend-image-patch.yaml:
código frontend-image-patch.yaml
2. Utilice el siguiente texto como parche en ese archivo:
Especificaciones:
modelo:
Especificaciones:
contenedores:
- nombre: php-redis
imagen: gcr.io/google-samples/gb-frontend:v3
Este archivo de parche usa el mismo diseño YAML que los archivos YAML típicos. Lo principal
de un archivo de parche es que solo tiene que contener los cambios y no tiene que ser capaz
de implementar todo el recurso.
3. Para aplicar el parche, use el siguiente comando:

frontend de implementación del parche kubectl --patch "$ (cat frontend-image-patch.
yaml)"
Este comando hace dos cosas: primero, lee el frontend-image-patch.yaml archivo,

y luego lo pasa al parche comando para ejecutar el cambio.
4. Puede verificar los cambios describiendo la implementación del front-end y buscando

el Imagen sección:
kubectl describe la interfaz de implementación

Esto mostrará una salida de la siguiente manera:
Figura 4.28: Después del parche, estamos ejecutando la imagen anterior.
Este fue un ejemplo del uso de la parche comando usando un archivo de parche. También puede
aplicar un parche directamente en la línea de comando sin crear un archivo YAML. En este caso,
describiría el cambio en JSON en lugar de en YAML.
Repasemos un ejemplo en el que revertiremos el cambio de imagen a v4:
1. Ejecute el siguiente comando para volver a parchear la imagen v4:
kubectl patch deployment frontend --patch = '{"spec": {"template": {"spec":

{"containers": [{"name": "php-redis", "image": "gcr.io/ google-samples /
gb-frontend: v4 "}]}}}} '
2. Puede verificar este cambio describiendo la implementación y buscando el Imagen

sección:
kubectl describe la interfaz de implementación
Esto mostrará una salida como se muestra en Figura 4.29:
Figura 4.29: Después de otro parche, volvemos a ejecutar la nueva versión.

Antes de pasar al siguiente ejemplo, eliminemos la aplicación del libro de visitas de nuestro
clúster:
Hasta ahora, ha explorado tres formas de actualizar las aplicaciones de Kubernetes. Primero, realizó
cambios en el archivo YAML real y los aplicó usando aplicar kubectl. Después, usaste kubectl editar
y parche de kubectl para hacer más cambios. En la sección final de este capítulo, usaremos Helm
para actualizar nuestra aplicación.
Actualización de aplicaciones con Helm
Esta sección explica cómo realizar actualizaciones utilizando operadores de Helm:
1. Ejecute el siguiente comando:
helm instalar wp estable / wordpress
Forzaremos una actualización de la imagen del WordPress envase. Primero verifiquemos la

versión de la imagen actual:
kubectl describe statefulset wp-mariadb | Imagen grep
En nuestro caso, la versión de la imagen es 10.3.21-debian-10-r0 como sigue:
Figura 4.30: Obtención de la imagen actual de StatefulSet
Veamos las etiquetas de https://hub.docker.com/r/bitnami/mariadb/tags

y seleccione otra etiqueta. En nuestro caso, seleccionaremos el 10.3.22-debian-10-r9 etiqueta para
actualizar nuestro StatefulSet.
Sin embargo, para actualizar la imagen del contenedor MariaDB, necesitamos obtener la
contraseña de root para el servidor y la contraseña para la base de datos. Podemos obtener estas
contraseñas de la siguiente manera:
kubectl obtener secreto wp-mariadb -o yaml

Figura 4.31: Los secretos cifrados que usa MariaDB
Para obtener la contraseña decodificada, use el siguiente comando:
echo "<contraseña>" | base64 -d
Esto nos mostrará la contraseña de root decodificada y la contraseña de la base de datos decodificada.
2. Podemos actualizar la etiqueta de la imagen con Helm y luego ver cómo cambian los Pods usando el
siguiente comando:
helm upgrade wp stable / wordpress --set mariadb.image.tag = 10.3.21debian-10-r1,

mariadb.rootUser.password = <contraseña decodificada>, mariadb. db.password =
<contraseña de base de datos decodificada> && kubectl get pods -w
Esto actualizará la imagen de nuestra MariaDB y hará que se inicie un nuevo Pod. Corriendo
describir en el nuevo Pod y buscando Imagen nos mostrará la nueva versión de la
imagen:
kubectl describe pod wp-mariadb-0 | Imagen grep
Figura 4.32: Mostrando la nueva imagen

Resumen | 111
3. Finalmente, limpie ejecutando el siguiente comando:
timón eliminar wp
kubectl eliminar pv --todos
Por lo tanto, hemos actualizado nuestra aplicación utilizando Helm. Como ha visto en este ejemplo,
la actualización con Helm se puede realizar mediante el uso de: colocar operador. Esto hace que la
realización de actualizaciones y múltiples implementaciones con Helm sea tan eficiente.
Resumen
Este fue un capítulo con toneladas de información. Nuestro objetivo era mostrarle cómo escalar
implementaciones con Kubernetes. Hicimos esto mostrándole cómo crear múltiples instancias
de su aplicación.
Comenzamos el capítulo analizando cómo definir el uso de un equilibrador de carga y aprovechar

la función de escala de implementación en Kubernetes para lograr escalabilidad. Con
En este tipo de escalabilidad, también logramos la conmutación por error mediante el uso de un equilibrador de
carga y varias instancias del software para aplicaciones sin estado. También analizamos el uso de HPA para escalar
automáticamente nuestra implementación en función de la carga.
Después de eso, también analizamos cómo podemos escalar el clúster en sí. Primero, escalamos manualmente nuestro
clúster y luego usamos un escalador automático de clúster para escalar nuestro clúster en función de la demanda de la
aplicación.
Terminamos el capítulo buscando diferentes formas de actualizar una aplicación implementada.

Primero, exploramos la actualización manual de archivos YAML. Luego, profundizamos en dos kubectl comandos
editar y parche) que se puede utilizar para realizar cambios. Finalmente, mostramos cómo se puede
usar Helm para realizar estas actualizaciones.
En el próximo capítulo, veremos fallas comunes que puede ver al implementar

aplicaciones en AKS y cómo solucionarlas.
Manejo común
5
fallas en AKS
Kubernetes es un sistema distribuido con muchas partes funcionales. AKS resume la mayor parte de
para usted, pero sigue siendo su responsabilidad saber dónde buscar y cómo responder cuando
suceden cosas malas. Gran parte del manejo de fallas lo realiza Kubernetes automáticamente; sin
embargo, se encontrará con situaciones en las que se requiera una intervención manual.
Hay dos áreas en las que las cosas pueden salir mal en una aplicación que se implementa sobre AKS. O el
clúster en sí tiene problemas o la aplicación implementada en la parte superior del clúster tiene
problemas. Este capítulo se centra específicamente en los problemas de los clústeres. Hay varias cosas
que pueden fallar en un clúster.
Lo primero que puede salir mal es que un nodo del clúster puede dejar de estar disponible. Esto puede
suceder debido a una interrupción de la infraestructura de Azure o debido a un problema con la
máquina virtual en sí, como un bloqueo del sistema operativo. De cualquier manera, Kubernetes
monitorea el clúster en busca de fallas en los nodos y se recuperará automáticamente. Verá este
proceso en acción en este capítulo.
114 | Manejo de fallas comunes en AKS
Un segundo problema común en un clúster de Kubernetes son las fallas por falta de recursos. Esto
significa que la carga de trabajo que está intentando implementar requiere más recursos de los que
están disponibles en su clúster. Aprenderá a monitorear estas señales y cómo resolverlas.
Otro problema común son los problemas con el montaje del almacenamiento, que ocurre cuando un nodo
deja de estar disponible. Cuando un nodo en Kubernetes deja de estar disponible, Kubernetes no
desconectará los discos adjuntos a este nodo fallido. Esto significa que esos discos no pueden ser
utilizados por cargas de trabajo en otros nodos. Verá un ejemplo práctico de esto y aprenderá cómo
recuperarse de esta falla.
Analizaremos los siguientes modos de falla en profundidad en este capítulo:
• Manejo de fallas en los nodos
• Resolver fallas por falta de recursos
• Manejo de problemas de montaje de almacenamiento
En este capítulo, aprenderá acerca de los escenarios de fallas comunes, así como las soluciones a esos
escenarios. Para comenzar, presentaremos fallas en los nodos.
Nota:
Referirse a Kubernetes por el camino difícil ( https://github.com/kelseyhightower/kubernetesthe-hard-way

), un excelente tutorial, para tener una idea sobre los bloques en los que se construye
Kubernetes. Para la versión de Azure, consulte Kubernetes por el camino difícil: traducción de
Azure ( https://github.com/ivanfioravanti/kubernetes-the-hard-way-on-azure ).
Manejo de fallas de nodos

Intencionalmente (para ahorrar costos) o involuntariamente, los nodos pueden caer. Cuando eso
suceda, no querrá recibir la proverbial llamada de las 3 am de que su sistema no funciona.
Kubernetes puede manejar cargas de trabajo en movimiento en nodos fallidos automáticamente
por usted. En este ejercicio, vamos a implementar la aplicación del libro de visitas y vamos a cerrar
un nodo en nuestro clúster y ver qué hace Kubernetes en respuesta:
1. Asegúrese de que su clúster tenga al menos dos nodos:

Manejo de fallas en los nodos | 115
Esto debería generar una salida como se muestra en Figura 5.1:
Figura 5.1: Asegúrese de tener dos nodos ejecutándose en su clúster
Si no tiene dos nodos en su clúster, busque su clúster en Azure Portal, navegue hasta Grupos
de nodos, y haga clic en Recuento de nodos. Puedes escalar esto a 2
nodos como se muestra en Figura 5.2:
Figura 5.2: Escalado del clúster
2. Como aplicación de ejemplo en este capítulo, trabajaremos con la aplicación del libro de visitas. El
archivo YAML para implementar esto se ha proporcionado en el código fuente de este capítulo ( libro
de visitas-todo-en-uno.yaml). Para implementar la aplicación del libro de visitas, use el siguiente
comando:
3. Volveremos a darle al servicio una IP pública, como hicimos en los capítulos anteriores.
Para iniciar la edición, ejecute el siguiente comando:
4. Esto abrirá un vi medio ambiente. Navega hasta la línea que ahora dice tipo: ClusterIP ( línea 27) y
cámbielo a tipo: LoadBalancer. Para hacer ese cambio, presione el I para ingresar al modo de
inserción, escriba sus cambios, luego presione el Esc botón, escriba: wq !, y golpea Ingresar para
guardar los cambios.
5. Una vez que se guardan los cambios, puede ver el Servicio objeto hasta la IP pública
se vuelve disponible. Para hacer esto, escriba lo siguiente:
kubectl get svc -w
6. Esto tomará un par de minutos para mostrarle la IP actualizada. Figura 5.3

representa la IP pública del servicio. Una vez que vea la IP pública correcta, puede salir del
comando de vigilancia presionando Ctrl + C (comando + C en Mac):
Figura 5.3: Obtener la IP pública del servicio
7. Ir a http: // <IP-EXTERNO> como se muestra en Figura 5.4:
Figura 5.4: Asegúrese de que la aplicación se esté ejecutando
8. Veamos dónde se están ejecutando actualmente los pods con el siguiente código:

Figura 5.5: Nuestros pods se distribuyen entre el nodo 0 y el nodo 1
Esto nos muestra que tenemos la carga de trabajo distribuida entre el nodo 0 y el nodo 1.
9. En este ejemplo, queremos demostrar cómo Kubernetes maneja una falla de nodo.
Para demostrar esto, cerraremos un nodo en el clúster. En este caso, vamos a hacer
el máximo daño, así que apaguemos el nodo 1 (puede elegir el nodo que desee, con
fines ilustrativos, realmente no importa):
Para cerrar este nodo, busque Conjuntos de escalado de máquinas virtuales en nuestro clúster en la barra de
búsqueda de Azure, como se muestra en Figura 5.6:
Figura 5.6: Buscando el VMSS que aloja su clúster

Después de navegar a la hoja para el conjunto de escala, vaya al Instancias vista, seleccione la
instancia que desea cerrar y luego presione el Desasignar botón, como se muestra en
Figura 5.7:
Figura 5.7: Apagar el nodo 1
Esto cerrará nuestro nodo. Para ver cómo reaccionará Kubernetes con sus pods,
puede ver los pods en su clúster a través del siguiente comando:
kubectl get pods -o wide -w
10. Para verificar si su aplicación puede continuar ejecutándose, opcionalmente puede ejecutar el
siguiente comando para acceder al front-end del libro de visitas cada 5 segundos y obtener el
HTML. Se recomienda abrir esto en una nueva ventana de Cloud Shell:
mientras sea cierto; do curl -m 1 http: // <EXTERNAl-IP> /; dormir 5; hecho
Nota
El comando anterior seguirá llamando a su aplicación hasta que presione Ctrl + C (comando
+ C en Mac). Puede haber momentos intermitentes en los que no obtenga una respuesta, lo
cual es de esperar ya que Kubernetes tarda un par de minutos en reequilibrar el sistema.
Agregue algunas entradas del libro de visitas para ver qué les sucede cuando hace que el
nodo se apague. Esto mostrará una salida como se muestra en Figura 5.8:
Figura 5.8: Escribir un par de mensajes en el libro de visitas
¡Lo que puede ver es que todos sus valiosos mensajes se han ido! Esto muestra la
importancia de tener PersistentVolumeClaims (PVC) para cualquier dato que desee que
sobreviva en el caso de una falla del nodo, que no es el caso en nuestra aplicación aquí.
Verá un ejemplo de esto en la última sección de este capítulo.
11. Después de un tiempo, el resultado de ver los Pods debería haber mostrado un resultado adicional,
mostrándole que los Pods se reprogramaron en el host saludable, como se muestra en Figura 5.9:
Figura 5.9: Los pods del nodo fallido se vuelven a crear

Lo que ves aquí es lo siguiente:
• Uno de los pods de front-end que se ejecutan en el host 1 se canceló porque el host no funcionaba
correctamente.
• Se creó un nuevo pod de front-end, en el host 0. Esto pasó por las etapas Pendiente,
ContainerCreating, y luego Corriendo.
Nota
Kubernetes detectó que el host no estaba en buen estado antes de reprogramar los Pods. Si tuvieras que
hacer kubectl obtiene nodos, verías el nodo 1 en un No está listo Expresar. Hay una configuración en
Kubernetes llamada vaina-desalojo-tiempo de espera que define cuánto tiempo esperará el sistema para
reprogramar Pods en un host en buen estado. El valor predeterminado es de 5 minutos.
En esta sección, aprendió cómo Kubernetes maneja automáticamente las fallas de los nodos al recrear
pods en nodos en buen estado. En la siguiente sección, aprenderá cómo diagnosticar y resolver
problemas relacionados con la falta de recursos.
Resolver fallas por falta de recursos

Otro problema común que puede surgir con los clústeres de Kubernetes es que el clúster se está
quedando sin recursos. Cuando el clúster no tiene suficiente potencia de CPU o memoria para programar
pods adicionales, los pods se atascan en un Pendiente Expresar.
Usos de Kubernetes peticiones para calcular cuánta potencia de CPU o memoria requiere un determinado Pod.
Nuestra aplicación de libro de visitas tiene solicitudes definidas para todas las implementaciones. Si abre el libro
de visitas-todo-en-uno.yaml archivo, verá lo siguiente para el redis-esclavo
despliegue:
...
63 tipo: Despliegue
64 metadatos:
nombre:
sesenta y cinco redis-esclavo
...
83 recursos:
84 peticiones:
85 CPU: 100 m
86 memoria: 100Mi
...
Resolver fallas por falta de recursos | 121
En esta sección se explica que todos los Pod para el redis-esclavo la implementación requiere 100m de
un núcleo de CPU (100 mili o 10%) y 100MiB (Mebibyte) de memoria. En nuestro clúster de 1 CPU (con
el nodo 1 apagado), escalar esto a 10 pods provocará problemas con los recursos disponibles. Veamos
esto:
Nota
En Kubernetes, puede usar la notación de prefijo binario o la notación de base 10 para
especificar la memoria y el almacenamiento. La notación de prefijo binario significa usar KiB
(kibibyte) para representar 1024 bytes, MiB (mebibyte) para representar 1024 KiB y Gib
(gibibyte) para representar 1024 MiB. La notación de base 10 significa usar kB (kilobyte) para
representar 1,000 bytes, MB (megabyte) para representar 1,000 kB y GB (gigabyte) representa
1,000 MB.
1. Empecemos por escalar el redis-esclavo implementación en 10 pods:

implementación de escala kubectl / redis-slave --replicas = 10
2. Esto hará que se creen un par de pods nuevos. Podemos verificar nuestros Pods usando lo
siguiente:
Figura 5.10: Si el clúster se queda sin recursos, los pods pasarán al estado Pendiente
Destacado aquí es uno de los Pods que están en el Pendiente Expresar.
3. Podemos obtener más información sobre estos Pods pendientes usando el siguiente
comando:
kubectl describe pod redis-slave- <pod-id>
Esto le mostrará más detalles. En la parte inferior de la describir comando, debería

ver algo como lo que se muestra en Figura 5.11:
Figura 5.11: Kubernetes no puede programar este pod
Nos explica dos cosas:
• Uno de los nodos no tiene recursos de CPU.
• Uno de los nodos tiene una mancha que el Pod no toleró. Esto significa que el nodo que es No está
listo no puede aceptar vainas.
4. Podemos resolver este problema de capacidad iniciando el nodo 1 como se muestra en Figura 5.12. Esta
se puede hacer de una manera similar al proceso de apagado:
Figura 5.12: Inicie el nodo 1 nuevamente

Resolver fallas por falta de recursos | 123
5. El otro nodo tardará unos minutos en volver a estar disponible en Kubernetes. Si

volvemos a ejecutar el describir comando en el Pod anterior, veremos una salida
como la que se muestra en Figura 5.13:
Figura 5.13: Cuando el nodo está disponible nuevamente, los otros Pods comienzan en el nuevo nodo
Esto muestra que después de que el nodo 1 estuvo disponible, Kubernetes programó nuestro Pod en
ese nodo y luego inició el contenedor.
En esta sección, aprendimos cómo diagnosticar errores por falta de recursos. Pudimos
resolver el error agregando otro nodo al clúster. Antes de pasar al modo de falla final,
limpiaremos la implementación del libro de visitas.
Nota
En Capítulo 4, Escalar su aplicación, discutimos el escalador automático del clúster. El escalador
automático del clúster supervisará los errores de falta de recursos y agregará nuevos nodos al clúster
automáticamente.
Limpiemos ejecutando lo siguiente Eliminar mando:

Hasta ahora, hemos discutido dos modos de falla para los nodos en un clúster de Kubernetes. Primero,
discutimos cómo Kubernetes maneja un nodo que se desconecta y cómo el sistema reprograma los Pods
a un nodo en funcionamiento. Después de eso, vimos cómo Kubernetes usa solicitudes para programar
pods en un nodo y qué sucede cuando un clúster se queda sin recursos. En la siguiente sección,
cubriremos otro modo de falla en Kubernetes, a saber, lo que sucede cuando Kubernetes mueve Pods
con PVC adjuntos.
Solucionar problemas de montaje de almacenamiento
Anteriormente en este capítulo, notó cómo la aplicación del libro de visitas perdía datos cuando el
maestro de Redis se movía a otro nodo. Esto sucedió porque esa aplicación de muestra no usó
ningún almacenamiento persistente. En esta sección, cubriremos un ejemplo de cómo se pueden
usar los PVC para evitar la pérdida de datos cuando Kubernetes mueve un Pod a otro nodo. Le
mostraremos un error común que ocurre cuando Kubernetes mueve Pods con PVC adjuntos, y le
mostraremos cómo solucionarlo.
Para ello, reutilizaremos el ejemplo de WordPress del capítulo anterior. Antes de

comenzar, asegurémonos de que el clúster esté limpio:
Esto nos muestra solo el servicio de Kubernetes, como se muestra en Figura 5.14:
Figura 5.14: Solo debería tener el servicio de Kubernetes ejecutándose por ahora
Asegurémonos también de que ambos nodos se estén ejecutando y Listo:
Esto debería mostrarnos ambos nodos en una Listo estado, como se muestra en Figura 5.15:
Figura 5.15: Debe tener dos nodos disponibles en su clúster
En el ejemplo anterior, bajo el Manejo de fallas de nodos sección, vimos que los mensajes almacenados
en redis-master se perdieron si el Pod se reinicia. La razón de esto es que redis-master almacena todos
los datos en su contenedor, y cada vez que se reinicia, usa la imagen limpia sin los datos. Para sobrevivir
a los reinicios, los datos deben almacenarse en el exterior. Kubernetes usa PVC para abstraer el
proveedor de almacenamiento subyacente para proporcionar este almacenamiento externo.
Para comenzar con este ejemplo, configuraremos la instalación de WordPress.

Solucionar problemas de montaje de almacenamiento | 125
Comenzando la instalación de WordPress
Comencemos instalando WordPress. Demostraremos cómo funciona y luego verificaremos que el

almacenamiento aún esté presente después de un reinicio:
Comience la reinstalación usando el siguiente comando:

helm instalar wp estable / wordpress
Esto tardará un par de minutos en procesarse. Puede seguir el estado de esta

instalación ejecutando el siguiente comando:
kubectl get pods -w
Después de un par de minutos, esto debería mostrarnos Pods con un estado de Corriendo y con un estado
listo de 1/1 para ambos Pods, como se muestra en Figura 5.16:
Figura 5.16: Todos los pods tendrán el estado de En ejecución después de un par de minutos
En esta sección, vimos cómo instalar WordPress. Ahora veremos cómo evitar la pérdida de datos
utilizando los volúmenes persistentes.
Usar volúmenes persistentes para evitar la pérdida de datos
A volumen persistente (PV) es la forma de almacenar datos persistentes en el clúster con

Kubernetes. Explicamos los PV con más detalle en Capítulo 3, Implementación de aplicaciones en AKS. Exploremo
los PV creados para nuestra implementación de WordPress:
1. En nuestro caso, ejecute lo siguiente describir nodos mando:
kubectl describe nodos

Desplácese por la salida hasta que vea una sección similar a Figura 5.17. En nuestro caso,
ambos pods de WordPress se ejecutan en el nodo 0:
Figura 5.17: En nuestro caso, ambos pods de WordPress se ejecutan en el nodo 0
La ubicación de su Pod puede variar.
2. Lo siguiente que podemos comprobar es el estado de nuestros PVC:
kubectl obtener pvc
Figura 5.18: La implementación de WordPress crea dos PVC
El siguiente comando muestra el PV real que está vinculado a los pods:
kubectl describe pv
Esto le mostrará los detalles de ambos volúmenes. Te mostraremos uno de esos en

Figura 5.19:
Figura 5.19: Los detalles de uno de los PVC
Aquí, podemos ver qué Pod ha reclamado este volumen y qué DiskURI está en
Azure.
3. Verifique que su sitio funcione realmente:
Esto nos mostrará la IP pública de nuestro sitio de WordPress, como se muestra en Figura 5.20:
Figura 5.20: Obtener la IP pública del servicio

4. Si recuerdas de Capítulo 3, Implementación de aplicaciones de AKS, Helm nos mostró

los comandos que necesitamos para obtener las credenciales de administrador para nuestro sitio de WordPress.
Tomemos esos comandos y ejecútelos para iniciar sesión en el sitio de la siguiente manera:
estado del timón wp

echo Nombre de usuario: usuario
echo Contraseña: $ (kubectl get secret --namespace default wp-wordpress -o

jsonpath = "{. data.wordpress-password}" | base64 -d)
Esto te mostrará el nombre de usuario y contraseña, como se muestra en Figura 5.21:
Figura 5.21: Obtener el nombre de usuario y la contraseña para la aplicación de WordPress
Nota
Puede notar que los comandos que usamos en el libro son ligeramente diferentes a los
que timón regresó. El comando que timón devuelto para la contraseña no funcionó para
nosotros, y le proporcionamos los comandos de trabajo.
Podemos iniciar sesión en nuestro sitio a través de la siguiente dirección: http: // <ip-external> / admin.
Inicie sesión aquí con las credenciales del paso anterior. Luego, puede continuar y agregar una
publicación a su sitio web. Haga clic en el Escribe tu primera publicación de blog y luego crea una
publicación corta, como se muestra en Figura 5.22:
Figura 5.22: Escribiendo su primera publicación de blog

Escriba un pequeño texto ahora y presione el Publicar botón, como se muestra en Figura 5.23. El texto
en sí no es importante; estamos escribiendo esto para verificar que los datos se conservan en el disco:
Figura 5.23: Publicar una publicación con texto aleatorio
Si ahora dirígete a la página principal de tu sitio web en http: // <ip-external>, Verás tu publicación de
prueba como se muestra en Figura 5.23. Verificaremos si esta publicación sobrevive a un reinicio en la
siguiente sección.
Manejo de fallas del Pod con afectación de PVC
La primera prueba que haremos con nuestro PVC es matar los Pods y verificar si los datos realmente
persistieron. Para hacer esto, hagamos dos cosas:
1. Mira nuestros Pods en nuestra aplicación. Para hacer esto, usaremos nuestro Cloud Shell actual
y ejecuta el siguiente comando:
kubectl get pods -w
2. Mata a los dos Pods que tienen el PVC montado. Para hacer esto, crearemos una nueva ventana de
Cloud Shell haciendo clic en el ícono que se muestra en Figura 5.24:
Figura 24: Apertura de una nueva instancia de Cloud Shell

Una vez que abra un nuevo Cloud Shell, ejecute el siguiente comando:
kubectl delete pod --todos
Si sigue junto con el reloj comando, debería ver una salida como la que se muestra
en Figura 5.25:
Figura 5.25: Después de eliminar los pods, Kubernetes volverá a crear ambos pods automáticamente
Como puede ver, Kubernetes comenzó rápidamente a crear nuevos Pods para recuperarse de la
interrupción del Pod. Los Pods pasaron por un ciclo de vida similar al de los originales, pasando de Pendiente
para ContenedorCreando para Corriendo.
3. Si se dirige a su sitio web, debería ver que su publicación de demostración se ha

conservado. Así es como los PVC pueden ayudarlo a evitar la pérdida de datos, ya que
conservan datos que no se habrían conservado en el contenedor.
Figura 5.26 muestra que la publicación del blog se mantuvo a pesar de que se volvió a crear
el Pod:
Figura 5.26: Sus datos se conservan y la publicación de su blog todavía está allí
Un último punto de datos interesante para observar aquí es el flujo de eventos de Kubernetes. Si
ejecuta el siguiente comando, puede ver los eventos relacionados con los volúmenes:
eventos de kubectl get | grep -i volumen
Figura 5.27: Kubernetes resolvió un error FailedAttachVolume
Esto le muestra los eventos relacionados con los volúmenes. Hay dos mensajes interesantes para
explicar con más detalle: FailedAttachVolume y SuccessfulAttachVolume.
Esto nos muestra cómo Kubernetes maneja los volúmenes que tienen una configuración de
lectura y escritura única. Dado que la característica es solo leer y escribir desde un solo Pod,
Kubernetes solo montará el volumen en el nuevo Pod cuando se desmonte correctamente del
Pod actual. Por lo tanto, inicialmente, cuando se programó el nuevo Pod, mostró el FailedAttachVolume
mensaje ya que el volumen aún estaba adjunto al Pod que se estaba eliminando.
Posteriormente, el Pod pudo montar con éxito el volumen y mostró esto con el mensaje SuccessfulAttachVo
En esta sección, hemos aprendido cómo los PVC pueden ayudar cuando los pods se vuelven a crear en el
mismo nodo. En la siguiente sección, veremos cómo se utilizan los PVC cuando un nodo tiene una falla.
Manejo de la falla del nodo con afectación de PVC
En el ejemplo anterior, vimos cómo Kubernetes puede manejar las fallas de los pods cuando esos pods
tienen un PV adjunto. En este ejemplo, veremos cómo Kubernetes maneja las fallas de los nodos
cuando se adjunta un volumen:
1. Primero verifiquemos qué nodo aloja nuestra aplicación, usando el siguiente

comando:
Descubrimos que, en nuestro clúster, el nodo 1 alojaba MariaDB y el nodo 0 alojaba el sitio de
WordPress, como se muestra en Figura 5.28:
Figura 5.28: Tenemos dos pods ejecutándose en nuestra implementación: uno en el nodo 1 y otro en el nodo 0
2. Vamos a introducir una falla y detener el nodo que podría causar el mayor daño al cerrar el
nodo 0 en Azure Portal. Haremos esto de la misma manera que en el ejemplo anterior.
Primero, busque el conjunto de escalas que respalda nuestro clúster, como se muestra en Figura
5.29:
Figura 5.29: Encontrar el conjunto de escalas que respalda nuestro clúster

3. Luego apague el nodo como se muestra en Figura 5.30:
Figura 5.30: Apagando el nodo
4. Después de esta acción, volveremos a observar nuestros pods para ver qué está sucediendo en el
clúster:
kubectl get pods -o wide -w
Como en el ejemplo anterior, pasarán 5 minutos antes de que Kubernetes comience a

tomar medidas contra nuestro nodo fallido. Podemos ver que eso sucede en Figura
5.31:
Figura 5.31: Un pod en estado pendiente
5. Estamos viendo un nuevo problema aquí. Nuestro nuevo Pod está atrapado en un Pendiente estado y tiene
no ha sido asignado a un nuevo nodo. Averigüemos qué está pasando aquí. Primero, nosotros describir
nuestro Pod:
kubectl describe pods / wp-wordpress- <pod-id>

Obtendrá una salida como se muestra en Figura 5.32:
Figura 5.32: Salida que muestra el Pod en estado pendiente
6. Esto nos muestra que no tenemos suficientes recursos de CPU en nuestro clúster para alojar el
nuevo Pod. Podemos arreglar esto usando el kubectl editar implementar / ... comando para
corregir errores insuficientes de CPU / memoria. Cambiaremos las solicitudes de CPU de 300 a 3
para que nuestro ejemplo continúe:
kubectl editar implementar wp-wordpress
Esto nos lleva a un vi medio ambiente. Podemos encontrar rápidamente la sección referente a la
CPU escribiendo lo siguiente:
/ cpu <enter>
Una vez allí, mueva el cursor sobre los dos ceros y presione el X dos veces para eliminar los ceros.
Finalmente, escriba: wq! para guardar nuestros cambios para que podamos continuar con nuestro
ejemplo.
7. Esto dará como resultado la creación de un nuevo ReplicaSet con un nuevo Pod. Podemos
obtener el nombre del nuevo Pod ingresando el siguiente comando:
Busque el Pod con el estado ContainerCreating, como sigue:
Figura 5.33: El nuevo pod está bloqueado en un estado de creación de contenedor

8. Echemos un vistazo a los detalles de ese Pod con el describir mando:
kubectl describe pod wp-wordpress- <pod-id>
En el Eventos sección de este describir salida, puede ver un mensaje de error de la siguiente
manera:
Figura 5.34: El nuevo Pod tiene un nuevo mensaje de error que describe problemas de montaje de volumen
9. Esto nos dice que el volumen que nuestro nuevo Pod quiere montar todavía está montado en el
Pod que está atascado en un Terminando Expresar. Podemos resolver esto desconectando
manualmente el disco del nodo que cerramos y quitando con fuerza el Pod atascado en el Terminando
Expresar.
Nota
El comportamiento del Pod atascado en el Terminando el estado no es un error. Este es el
comportamiento predeterminado de Kubernetes. La documentación de Kubernetes establece lo
siguiente: "Kubernetes (versión 1.5 o más reciente) no eliminará los pods solo porque un nodo es
inaccesible. Los pods que se ejecutan en un nodo inaccesible ingresan al Terminando
o Desconocido estado después de un tiempo de espera. Los pods también pueden entrar en estos
estados cuando el usuario intenta la eliminación ordenada de un pod en un nodo inalcanzable ".
Puede leer más en https://kubernetes.io/docs/tasks/run-application/force-delete-stateful-setpod/ .
10. Para hacer eso, necesitaremos el nombre del conjunto de básculas y el nombre del grupo de recursos. Para
encontrarlos, busque la escala configurada en el portal como se muestra en Figura 5.35:
Figura 5.35: Busque el conjunto de escalas que respalda su clúster

11. En la vista del conjunto de básculas, copie y pegue el nombre del conjunto de básculas y el grupo de
recursos. Edite el siguiente comando para desconectar el disco de su nodo fallido y luego ejecute este
comando en Cloud Shell:
az vmss disk detach --lun 0 --vmss-name <vmss-name> -g <rgname>

- - id de instancia 0
12. Esto separará el disco del nodo 0. El segundo paso que se requiere aquí es la
eliminación forzosa del Pod del clúster, mientras está atascado en el estado de
terminación:
kubectl eliminar pod wordpress-wp- <pod-id> --grace-period = 0 --force
13. Esto traerá nuestro nuevo Pod a un estado saludable. El sistema tardará un par de
minutos en detectar los cambios y luego montar y programar el nuevo Pod.
Obtengamos los detalles del Pod nuevamente usando el siguiente comando:
kubectl describe pod wp-wordpress- <pod-id>
Figura 5.36: Nuestro nuevo Pod ahora adjunta el volumen y extrae la imagen del contenedor
14. Esto nos muestra que el nuevo Pod logró adjuntar el volumen y que se extrajo la imagen
del contenedor. Verifiquemos que el Pod realmente se esté ejecutando:
Esto mostrará los Pods ejecutándose como se muestra en Figura 5.37:
Figura 5.37: Ambos pods se están ejecutando correctamente
Y esto debería hacer que su sitio web de WordPress esté disponible nuevamente.
Antes de continuar, limpiemos nuestra implementación usando el siguiente comando:

timón eliminar wp

kubectl eliminar pv --todos
También reiniciemos el nodo que se cerró, como se muestra en Figura 5.38:
Figura 5.38: Iniciando el nodo 1 nuevamente
En esta sección, cubrimos cómo puede recuperarse de una falla de nodo cuando los PVC no están
montados en nuevos Pods. Necesitábamos desmontar manualmente el disco y luego eliminar a la
fuerza el Pod que estaba atascado en un Terminando Expresar.
Resumen
En este capítulo, aprendió sobre los modos de falla comunes de Kubernetes y cómo puede
recuperarse de ellos. Comenzamos este capítulo con un ejemplo sobre cómo Kubernetes detecta
automáticamente fallas en los nodos y cómo iniciará nuevos pods para recuperar la carga de
trabajo. Después de eso, escalaste tu carga de trabajo y tu clúster se quedó sin recursos. Se
recuperó de esa situación iniciando el nodo fallido nuevamente para agregar nuevos recursos al
clúster.
A continuación, vio cómo los PV son útiles para almacenar datos fuera de un Pod. Cerró todos
los pods en el clúster y vio cómo el PV aseguraba que no se perdieran datos en su aplicación.
En el ejemplo final de este capítulo, vio cómo puede recuperarse de una falla de nodo cuando
los PV están conectados. Pudiste recuperar la carga de trabajo desmontando el disco del nodo
y eliminando a la fuerza el Pod de terminación. Esto devolvió su carga de trabajo a un estado
saludable.
Este capítulo ha explicado los modos de falla comunes en Kubernetes. En el siguiente capítulo,
presentaremos la compatibilidad con HTTPS en nuestros servicios e introduciremos la autenticación con
Azure Active Directory.
Asegurando su
6
aplicación con
HTTPS y Azure AD
HTTPS se ha convertido en una necesidad para cualquier sitio web de cara al público. No solo mejora la
seguridad de su sitio web, sino que también se está convirtiendo en un requisito para las nuevas
funcionalidades del navegador. HTTPS es una versión segura del protocolo HTTP. HTTPS hace uso de
Seguridad de la capa de transporte (TLS) certificados para cifrar el tráfico entre un usuario final y
un servidor, o entre dos servidores. TLS es el sucesor del Capa de enchufes seguros
( SSL). Los términos TLS y SSL a menudo se usan indistintamente.
En el pasado, necesitaba comprar certificados de un autoridad certificadora (CA), luego

configúrelos en su servidor web y luego renuévelos periódicamente. Si bien eso todavía es
posible hoy, el Vamos a cifrar el servicio y los ayudantes de Kubernetes lo hacen muy fácil
para configurar certificados TLS verificados en su clúster. Let's Encrypt es una organización sin fines de
lucro dirigida por Internet Security Research Group y respaldada por varias empresas. Es un servicio
gratuito que ofrece certificados TLS verificados de forma automatizada. La automatización es un beneficio
clave del servicio Let's Encrypt.
142 | Asegurar su aplicación con HTTPS y Azure AD
En términos de ayudantes de Kubernetes, presentaremos un nuevo objeto llamado Ingreso, y usaremos

un complemento de Kubernetes llamado cert-manager. Un Ingress es un objeto dentro de Kubernetes
que administra el acceso externo a los servicios. Los ingresos se utilizan comúnmente para servicios
HTTP. Un Ingress agrega funcionalidad adicional sobre el objeto de servicio que explicamos en Capítulo 3,
Implementación de aplicaciones en AKS. Se puede configurar un Ingress
para manejar el tráfico HTTPS. También se puede configurar para enrutar el tráfico a diferentes servicios de
back-end en función del nombre de host, que es asignado por el Sistema de nombres de dominio (DNS)
que se utiliza para conectarse.
cert-manager es un complemento de Kubernetes que ayuda a automatizar la creación de

certificados TLS. También ayuda en la rotación de certificados cuando están a punto de caducar.
cert-manager puede interactuar con Let's Encrypt para solicitar certificados automáticamente.
En este capítulo, veremos cómo configurar el Ingress y cert-manager para interactuar con
Let's Encrypt.
También en este capítulo, exploraremos diferentes enfoques de autenticación para la aplicación de libro
de visitas. Miraremos el oauth2_proxy proxy inverso para agregar autenticación a la aplicación de invitado
de muestra mediante Azure Active Directory (AD). El oauth2_proxy es un proxy inverso que reenviará las
solicitudes de autenticación a una plataforma de autenticación de configuración. Aprenderá a proteger
fácilmente aplicaciones que no tienen autenticación incorporada. El esquema de autenticación se puede
extender para usar GitHub, Google, GitLab, LinkedIn o Facebook.
• Configurar un Ingress frente a un servicio
• Agregar compatibilidad con TLS a un Ingress
• Autenticación y proveedores de autenticación comunes
• Autenticación versus autorización
• Implementar el oauth2_proxy sidecar
Comencemos con la configuración de Ingress.

Soporte HTTPS | 143
Soporte HTTPS
La obtención de certificados TLS ha sido tradicionalmente un negocio costoso y manual. Si
quisiera hacerlo de forma económica, podría autofirmar sus certificados, pero los navegadores se
quejarían al abrir su sitio y lo identificarían como no confiable. El servicio Let's Encrypt cambia
todo eso. Let's Encrypt es una CA gratuita, automatizada y abierta que se ejecuta en beneficio del
público. Brinda a las personas los certificados digitales que necesitan para habilitar HTTPS (SSL /
TLS) para sitios web, de forma gratuita, de la manera más fácil de usar.
Nota
Aunque esta sección se centra en el uso de un servicio automatizado como Let's Encrypt,
aún puede seguir el camino tradicional de comprar un certificado de una CA existente e
importarlo a Kubernetes.
Instalación de un controlador Ingress
Con el objeto Ingress, Kubernetes proporciona una forma limpia de exponer sus servicios de forma segura.
Proporciona un punto final SSL y enrutamiento basado en nombres, lo que significa que se pueden enrutar
diferentes nombres DNS a diferentes servicios de back-end.
Si desea crear un objeto Ingress en su clúster, primero debe configurar un

Controlador de ingreso. El controlador de Ingress administrará el estado de los Ingresses que ha
implementado en su clúster. Hay varias opciones al seleccionar un controlador Ingress. Para obtener
una lista completa de opciones, consulte https://kubernetes.io/docs/ conceptos /
servicios-networking / ingress-controllers / . Cuando se ejecuta AKS, las dos opciones más comunes
son usar un controlador Ingress basado en NGINX o un controlador Ingress basado en la puerta de
enlace de aplicaciones de Azure. Para nuestro ejemplo, usaremos la versión NGINX.
Sigamos e instalemos la versión NGINX del controlador Ingress realizando los siguientes
pasos:
1. Para seguir, ejecute esta muestra en la versión Bash de Cloud Shell.
2. Escriba el siguiente comando para comenzar la instalación:
helm repo agregar estable https://kubernetes-charts.storage.googleapis.com/

helm install ingress stable / nginx-ingress
Esto configurará el controlador Ingress para nuestro clúster. Esto creará adicionalmente una
IP pública que usaremos para acceder al controlador Ingress.
3. Vamos a conectarnos al controlador Ingress. Para obtener la IP expuesta del ingreso-

controlador service, ingrese este comando:
Debería ver una entrada para el controlador Ingress como se muestra en Figura 6.1:
Figura 6.1: Obtención de la IP del controlador Ingress
Puede navegar a la página web ingresando http: // <IP-EXTERNO> en el navegador:
Figura 6.2: Un Ingress que muestra su back-end predeterminado
Esto te muestra dos cosas:
4. No hay una aplicación de back-end, solo una aplicación predeterminada.
5. El sitio web se sirve a través de HTTP, no HTTPS (de ahí el No es seguro advertencia).
En las siguientes dos secciones, resolveremos ambos problemas. Primero crearemos una regla de Ingress para
nuestra aplicación de libro de visitas y luego agregaremos soporte HTTPS a través de Let's Encrypt.
Agregar una regla de Ingress para la aplicación del libro de visitas
Comencemos reiniciando nuestra aplicación de libro de visitas. Para iniciar la aplicación del
libro de visitas, escriba el siguiente comando:

Soporte HTTPS | 145
Esto creará nuestra aplicación de libro de visitas de confianza. Debería ver los objetos que se están creando
como se muestra en Figura 6.3:
Figura 6.3: Creación de la aplicación del libro de visitas
Luego, podemos usar el siguiente archivo YAML para exponer el servicio de front-end a través de Ingress.
Esto se proporciona como simple-frontend-ingress.yaml en el código fuente de este capítulo:

2 tipo: Ingress
3 metadatos:
4 nombre: ingreso-frontend-simple
5 Especificaciones:
6 normas:
7 - http:
8 rutas:
9 - sendero: /
10 backend:
11 serviceName: frontend
12 servicePort: 80
Echemos un vistazo a lo que definimos en este archivo YAML:
• Línea 2: Aquí, definimos el hecho de que estamos creando un objeto Ingress.

• Líneas 5-12: Estas líneas definen la configuración del Ingress. Preste especial
atención a:
• Línea 9: Aquí, definimos la ruta en la que está escuchando este Ingress. En nuestro caso, esta es la ruta
de nivel superior. En casos más avanzados, puede tener diferentes rutas que apunten a diferentes
servicios.
• Líneas 10-12: Estas líneas definen el servicio real al que se debe apuntar este tráfico.
Podemos usar el siguiente comando para crear este Ingress:

kubectl apply -f simple-frontend-ingress.yaml
Si ahora vas a https: // <IP-EXTERNO> /, debería obtener una salida como se muestra en
Figura 6.4:
Figura 6.4: Acceso a la aplicación del libro de visitas a través de Ingress
Preste atención a lo siguiente: no tuvimos que exponer públicamente el servicio front-end

como lo hemos hecho en los capítulos anteriores. Hemos agregado Ingress como el servicio
expuesto, y el servicio de front-end sigue siendo privado para el clúster:
Figura 6.5: Diagrama de flujo que muestra Ingress de acceso público

Soporte HTTPS | 147
Puede verificar esto ejecutando el siguiente comando:

kubectl obtener svc
Esto solo debería mostrarle un servicio público:
Figura 6.6: Salida que muestra solo el Ingress que tiene una IP pública
En esta sección, ha iniciado una instancia de la aplicación del libro de visitas. Lo expuso
públicamente al crear un Ingress. Solo el Ingress era de acceso público. En la siguiente
sección, veremos cómo obtener una certificación de Let's Encrypt.
Obtener un certificado de Let's Encrypt

En esta sección, agregaremos soporte HTTPS a nuestra aplicación. Para hacer esto,
necesitamos un certificado TLS. Estaremos usando el cert-manager Complemento de
Kubernetes para solicitar un certificado de Let's Encrypt. Hay un par de pasos involucrados. El
proceso de agregar HTTPS a nuestra aplicación implica los siguientes pasos:
1. Instalar cert-manager, que interactúa con la API Let's Encrypt para solicitar una
certificado para el nombre de dominio que especifique.
2. Mapear el Nombre de dominio completo de Azure (FQDN) a la IP pública de NGINX Ingress.

Un FQDN es el nombre DNS completo de un servicio, a veces denominado registro DNS, como www.g
Se emite un certificado TLS para un FQDN, por lo que necesitamos mapear un FQDN para
nuestro Ingress.
3. Instale el emisor del certificado, que obtendrá el certificado de Let's Encrypt. Cree un
4. certificado SSL para un FQDN determinado.
5. Asegure la sección de servicio de front-end creando un Ingress al servicio con el
certificado creado en paso 4. En nuestro ejemplo, no ejecutaremos este paso. Sin
embargo, reconfiguraremos nuestro Ingress para recoger automáticamente el certificado
creado en paso 4.
Empecemos por el primer paso; instalando cert-manager en nuestro clúster.

Instalación de cert-manager
El primer paso para obtener un certificado TLS es instalar cert-manager en su clúster. cert-
manager https://github.com/jetstack/cert-manager ) automatiza la gestión y emisión de
certificados TLS de diversas fuentes emisoras. Es una solución de código abierto gestionada
por la empresa. Jetstack. Renovar los certificados y asegurarse de que se actualizan
periódicamente es gestionado por cert-manager, que es un complemento de Kubernetes.
Los siguientes comandos se instalan cert-manager en tu clúster:

kubectl crear ns cert-manager
helm repo agregar jetstack https://charts.jetstack.io
helm install cert-manager --namespace cert-manager jetstack / cert-manager
Estos comandos hacen un par de cosas en su clúster:
1. Cree una nueva espacio de nombres. Los espacios de nombres se utilizan dentro de Kubernetes para aislar
cargas de trabajo entre sí.
2. Agregue un nuevo repositorio a Helm para obtener gráficos.
3. Instala el cert-manager Gráfico de timón.
Ahora que has instalado cert-manager, podemos pasar al siguiente paso: mapear un
FQDN al Ingress.
Asignación del FQDN de Azure a la IP pública de NGINX Ingress
El siguiente paso en el proceso de obtener un certificado TLS es agregar un FQDN a su dirección IP. Let's
Encrypt requiere una entrada de DNS disponible públicamente para verificar la propiedad de la entrada
de DNS antes de emite un certificado. Esto asegura que no pueda secuestrar el sitio de otra persona.
Tenemos que asignar el nombre de dominio público que nos dio Azure a la IP externa que obtenemos de
Azure Load Balancer para demostrar la propiedad.
Los siguientes pasos nos ayudarán a vincular una entrada de DNS a nuestra IP pública:
1. Sigamos adelante y vinculemos un nombre DNS a nuestra dirección IP pública. Primero, asegúrese
de obtener su dirección IP de su servicio Ingress:

Soporte HTTPS | 149
Anote la IP del servicio Ingress. En la barra de búsqueda de Azure, busque ahora

ip pública:
Figura 6.7: Búsqueda de IP pública en la barra de búsqueda de Azure
2. Una vez allí, debería ver una serie de direcciones IP públicas. Para encontrar nuestra dirección IP
pública, puede mostrar una columna adicional aquí que le mostrará la dirección IP real. Golpea el Editar
columnas botón para agregar la columna adicional:
Figura 6.8: Hacer clic en Editar columnas para agregar una columna adicional
3. En el selector de columnas, elija dirección IP y presione la flecha que apunta a la derecha, como se muestra
en Figura 6.9:
Figura 6.9: Agregar la dirección IP a las columnas seleccionadas

Soporte HTTPS | 151
4. Hit Aplicar para mostrar las direcciones IP reales. Cuando vea el suyo, haga clic en él. En el
Blade para su dirección IP, ingrese el Configuración vista. Luego, ingrese un único Nombre DNS y
presione Ahorrar:
Figura 6.10: Agregar una etiqueta de nombre DNS única y guardar la configuración
Ahora tiene un registro DNS vinculado a su dirección IP pública. A continuación, instalará el

emisor del certificado en su clúster.
Instalación del emisor del certificado
En esta sección, instalaremos el emisor del certificado de ensayo Let's Encrypt. Varios emisores pueden
emitir un certificado. vamos a cifrar la puesta en escena, por ejemplo, es para propósitos de prueba.
Mientras construimos las pruebas, usaremos el servidor de ensayo. El código del emisor del certificado
se ha proporcionado en el código fuente de este capítulo en la
emisor-certificado.yaml expediente. Como de costumbre, use kubectl create -f certificate-issuer.yaml,
que tiene el siguiente contenido:
1 apiVersion: cert-manager.io/v1alpha2
2 tipo: Emisor
3 metadatos:
4 nombre: letsencrypt-staging
5 Especificaciones:
6 cumbre:
7 servidor: https://acme-staging-v02.api.letsencrypt.org/directory correo electrónico:
8 <su dirección de correo electrónico>
9 privateKeySecretRef:
11 solucionadores:
12 - http01:
13 ingreso:
14 clase: nginx
Ahora, veamos lo que hemos definido aquí:
• Líneas 1-2: Aquí, hemos utilizado el CustomResourceDefinition (CRD) que instalamos anteriormente.
Un CRD es una forma de ampliar el servidor API de Kubernetes para crear recursos personalizados,
como un emisor de certificados. En este caso específicamente, apuntamos a la
cert-manager API CRD que inyectamos en la API de Kubernetes y creamos un Editor
objeto.
• Líneas 6-10: Hemos proporcionado la configuración para Let's Encrypt en estas líneas y
apuntamos al servidor de ensayo.
• Líneas 11-14: Esta es una configuración adicional para que el cliente ACME certifique la propiedad del
dominio.
Con el emisor del certificado instalado, ahora podemos pasar al siguiente paso: crear el
certificado TLS.
Soporte HTTPS | 153
Creando el certificado TLS y asegurando nuestro servicio
En esta sección, crearemos un certificado TLS. Hay dos formas de configurar

cert-manager para crear certificados. Puede crear manualmente un certificado y vincularlo al
controlador Ingress, o puede configurar su controlador Ingress para cert-manager
crea automáticamente el certificado. En este ejemplo, le mostraremos la segunda forma, editando
nuestro Ingress para que se vea como el siguiente código YAML. Este archivo está presente en el
código fuente de GitHub como ingreso-con-tls.yaml:

2 tipo: Ingress
3 metadatos:
5 anotaciones:
6 cert-manager.io/issuer: "letsencrypt-staging"
7 Especificaciones:
8 tls:
9 - Hospedadores:
10 - <su prefijo DNS>. <su región azul> .cloudapp.azure.com 11

nombresecreto: frontend-tls
12 normas:
13 - host: <su prefijo DNS>. <su ubicación de Azure> .cloudapp.azure.com 14

http:
15 rutas:
dieciséis - sendero: /
17 backend:
19 servicePort: 80
Hemos realizado los siguientes cambios en el Ingress original:
• Línea 6: Hemos agregado una anotación a nuestro Ingress que apunta a un emisor de
certificado.
• Líneas 10 y 13: El nombre de dominio para nuestro Ingress se ha agregado aquí. Esto es
necesario porque Let's Encrypt solo emite certificados para dominios.
• Línea 11: Este es el nombre del secreto que se creará para almacenar nuestro certificado.
Puede actualizar el Ingress que creamos anteriormente con el siguiente comando:

kubectl aplica -f ingress-with-tls.yaml
Se necesita cert-manager alrededor de un minuto para solicitar un certificado y configurar nuestro

Ingress para usar ese certificado. Mientras esperamos eso, echemos un vistazo a los recursos
intermedios que cert-manager creado en nuestro nombre.
Antes que nada, cert-manager creo un certificado objeto para nosotros. Podemos ver el estado de ese
objeto usando:
kubectl obtener certificado
Este comando generará una salida como se muestra en Figura 6.11:
Figura 6.11: Salida que muestra el estado del certificado
Como puede ver, nuestro certificado aún no está listo. Hay otro objeto que cert-manager
creado para obtener el certificado. Este objeto es solicitud de certificado. Podemos obtener su
estado usando el siguiente comando:
kubectl obtener solicitud de certificado
Figura 6.12: Salida que muestra el estado del objeto de solicitud de certificado como Falso
Soporte HTTPS | 155
También podemos obtener más detalles sobre la solicitud emitiendo un describir mando contra el solicitud
de certificado objeto:
kubectl describe la solicitud de certificado
Mientras esperamos que se emita nuestro certificado, el estado será similar a

Figura 6.13:
Figura 6.13: Salida que proporciona más detalles sobre el objeto de solicitud de certificado
Si le damos a esto un par de segundos adicionales, el describir El comando debe devolver un mensaje
de creación de certificado exitoso, como se muestra en Figura 6.14:
Figura 6.14: Salida que muestra el certificado emitido

Esto debería permitir que nuestro Ingress de front-end se sirva a través de HTTPS. Probemos esto
en un navegador navegando hasta el nombre DNS que creó en la sección que asigna un FQDN. Esto
indicará un error en el navegador, mostrándole que el certificado no es válido como se muestra en Figura
6.15. Esto es de esperar ya que estamos utilizando el servicio de preparación de Let's Encrypt:
Figura 6.15: Al utilizar el servidor de ensayo Let's Encrypt, nuestro certificado no es de confianza de forma predeterminada
Puede buscar su aplicación haciendo clic en Avanzado y seleccionando Continuar.
Como pudimos completar nuestra prueba con el certificado de ensayo, ahora podemos pasar
a la producción.
Pasar de la puesta en escena a la producción
En esta sección, cambiaremos de un certificado provisional a un certificado de nivel de producción. Para

hacer esto, puede rehacer el ejercicio anterior creando un nuevo emisor en su clúster, como el siguiente
(proporcionado en certificado-emisor-prod.yaml). No olvide cambiar su dirección de correo electrónico
en el archivo:
1 apiVersion: cert-manager.io/v1alpha2
2 tipo: Emisor
3 metadatos:
4 nombre: letsencrypt-prod
5 Especificaciones:
Soporte HTTPS | 157
6 cumbre:
7 servidor: https://acme-v02.api.letsencrypt.org/directory
8 correo electrónico: <su correo electrónico>
9 privateKeySecretRef:
11 solucionadores:
12 - http01:
13 ingreso:
14 clase: nginx
Y luego reemplace la referencia al emisor en el ingreso-con-tls.yaml archivo a

letsencrypt-prod, como este (provisto en el ingreso-con-tls-prod.yaml expediente):

2 tipo: Ingress
3 metadatos:
5 anotaciones:
6 cert-manager.io/issuer: "letsencrypt-prod"
7 Especificaciones:
8 tls:
9 - Hospedadores:
10 - <su prefijo dns>. <su región azul> .cloudapp.azure.com 11

nombresecreto: frontend-tls
12 normas:
13 - host: <su prefijo dns>. <su región azul> .cloudapp.azure.com 14

http:
15 rutas:
dieciséis - sendero: /
17 backend:
19 servicePort: 80
Para aplicar estos cambios, ejecute los siguientes comandos:

kubectl create -f certificate-issuer-prod.yaml
kubectl apply -f ingress-with-tls-prod.yaml
De nuevo, el certificado tardará aproximadamente un minuto en activarse. Una vez que se
emite el nuevo certificado, puede volver a buscar su nombre DNS y no debería ver más
advertencias sobre certificados no válidos. Si hace clic en el elemento del candado en el
navegador, debería ver que su conexión es segura y utiliza un certificado válido:
Figura 6.16: La página web que muestra un certificado válido
En esta sección, hemos introducido dos conceptos nuevos: primero, agregamos un Ingress a nuestra
aplicación de libro de visitas. Hicimos esto configurando primero un controlador Ingress en nuestro
clúster y luego configurando el Ingress para nuestra aplicación de libro de visitas. Un Ingress permite el
enrutamiento avanzado y la descarga HTTPS para aplicaciones en la parte superior de Kubernetes.
Después de eso, agregamos HTTPS a nuestra aplicación de libro de visitas. No tuvimos que cambiar el
código fuente de la aplicación en sí; pudimos agregar soporte HTTPS configurando nuestro Ingress.
Autenticación versus autorización | 159
En la siguiente sección, agregaremos otra capa de seguridad. Agregaremos autenticación a

nuestra aplicación. Antes de sumergirnos en esto, primero analicemos un malentendido
común sobre autenticación y autorización.
Autenticación versus autorización

Autenticación (AuthN) muy a menudo se mezcla con autorización (AuthZ).
La autenticación se ocupa de la identidad (¿quién es usted?) Y, en general, requiere un proveedor de
identidad de confianza. Existen múltiples proveedores, como Azure AD, Okta o GitHub, e incluso las
plataformas de redes sociales como Facebook, Google o Twitter se pueden utilizar como proveedor. La
autorización se ocupa de los permisos (¿qué está tratando de hacer?) Y es muy específica de la
implementación en términos de qué recursos de la aplicación deben protegerse.
Por lo general, se necesitan varios intentos para comprender la diferencia y, aun así, es posible que
se confundan entre los dos. La fuente de confusión es que, en algunos casos, el proveedor de
autenticación y el proveedor de autorización son los mismos. Por ejemplo, en nuestro ejemplo de
WordPress, WordPress proporciona la autenticación (tiene el nombre de usuario y la contraseña) y la
autorización (almacena a los usuarios bajo roles de administrador o usuario, por ejemplo).
Sin embargo, en la mayoría de los casos, el sistema de autenticación y el sistema de autorización son
diferentes. Usaremos un ejemplo práctico de esto en Capítulo 10, Protección de su clúster de AKS. En
ese capítulo, usaremos Azure AD como fuente de autenticación, mientras usamos Kubernetes RBAC
como fuente de autorización.
Proveedores de autenticación y autenticación común
Nuestra aplicación de libro de visitas está abierta a todos y permite que cualquier persona con una IP
pública acceda al servicio. La imagen por sí sola no tiene autenticación. Un problema común es querer
aplicar funcionalidad adicional por separado de la implementación de la aplicación. Esto se puede hacer
introduciendo un proxy que servirá al tráfico de autenticación, en lugar de introducir la lógica de
autenticación en la aplicación principal.
Con los ataques recientes, se ha demostrado que es difícil configurar y mantener un sistema de autenticación
seguro por su cuenta. Para ayudar a sus clientes a crear aplicaciones seguras, muchas empresas le permiten
utilizar su servicio de autenticación para verificar la identidad de un usuario. La autenticación es proporcionada
como un servicio por aquellos proveedores con soporte para OAuth. Éstos son algunos de los proveedores más
conocidos:
• Azure ( https://github.com/pusher/oauth2_proxy#azure-auth-provider )
• Facebook ( https://github.com/pusher/oauth2_proxy#facebook-auth-provider )
• GitHub ( https://github.com/pusher/oauth2_proxy#github-auth-provider )
• GitLab ( https://github.com/pusher/oauth2_proxy#gitlab-auth-provider )
• Google ( https://github.com/pusher/oauth2_proxy#google-auth-provider )
• LinkedIn ( https://github.com/pusher/oauth2_proxy#linkedin-auth-provider )
En las siguientes secciones, usaremos una implementación de proxy, oauth2_proxy, para

implementar la autenticación para nuestro ejemplo de libro de visitas.
Implementación del proxy oauth2_proxy
Comencemos limpiando el Ingress implementado anteriormente. Mantendremos el emisor del

certificado implementado en el clúster. Podemos limpiar el Ingress usando:
kubectl delete -f ingress-with-tls-prod.yaml
Vamos a implementar oauth2_proxy de Pusher https://github.com/pusher/ oauth2_proxy ).

Implemente los siguientes pasos para configurar oauth2_proxy utilizar Azure AD como
sistema de autenticación.
Primero, registre una aplicación con Azure AD. Abra la hoja de Azure AD en el portal
buscando directorio activo azul en la barra de búsqueda:
Figura 6.17: Búsqueda de Azure Active Directory en la barra de búsqueda de Azure

Luego ve a Registros de aplicaciones y haga clic en Nuevo registro:
Figura 6.18: Creación de un nuevo registro de aplicación
Luego, proporcione un nombre para la aplicación y presione Crear:
Figura 6.19: Proporcionar un nombre para la aplicación

A continuación, cree un secreto de ID de cliente realizando los siguientes pasos:
1. Seleccione Certificados y secretos E ir a Nuevo secreto de cliente. Dale al secreto un

descripción y golpe Agregar:
Figura 6.20: Creación de un nuevo secreto de cliente
2. Haga clic en el icono de copia y guarde el secreto en un lugar seguro:
Figura 6.21: Copia del secreto del cliente

3. A continuación, necesitaremos configurar una URL de redireccionamiento. Esta es la URL a la que Azure AD
devolverá la llamada una vez que se haya autenticado al usuario. Para configurar esto, dirígete a
Autenticación en la hoja de Azure AD, haga clic en Agrega una plataforma, y seleccione Web, como se
Figura 6.22: Proporcionar una URL de redireccionamiento
Una vez allí, puede ingresar la siguiente URL:
https: // <su prefijo dns>. <su región azul> .cloudapp.azure.com / oauth2 /

callback y golpea Configure.
4. Luego, regrese al Visión de conjunto hoja y salvar el Solicitud y el Directorio

IDENTIFICACIÓN:
Figura 6.23: Copia de la ID de la aplicación y la ID del directorio
Después de crear el secreto de ID de cliente, configurar la URL de redireccionamiento y copiar las ID de la

aplicación y el directorio, necesitamos crear los siguientes tres objetos en Kubernetes para obtener
oauth2_proxy trabajando en nuestro clúster y realizar un paso final para vincular OAuth a nuestro
Ingress existente:
1. Primero, necesitamos crear una implementación para oauth2_proxy.
2. Entonces, necesitamos exponer esto como un servicio.
3. Después de eso, crearemos un nuevo Ingress para oauth2.
4. Y finalmente, reconfiguraremos nuestro Ingress actual para enviar solicitudes no

autenticadas a oauth2_proxy.
Ejecutaremos los tres pasos mientras mostramos los archivos YAML de la siguiente manera:
1. Comencemos con el primer elemento: crear la implementación. La implementación se puede encontrar

en la fuente como oauth2_deployment.yaml expediente:

2 tipo: Despliegue
3 metadatos:
4 nombre: oauth2-proxy
5 Especificaciones:
6 réplicas: 1
7 selector:
8 matchLabels:
9 aplicación: oauth2-proxy
10 modelo:
11 metadatos:
12 etiquetas:
15 contenedores:
dieciséis - env:
17 - nombre: OAUTH2_PROXY_PROVIDER
18 valor: azul
19 - nombre: OAUTH2_PROXY_AZURE_TENANT
20 valor: <pegar en ID de directorio>
21 - nombre: OAUTH2_PROXY_CLIENT_ID
22 valor: <pegar en el ID de la aplicación>
23 - nombre: OAUTH2_PROXY_CLIENT_SECRET
24 valor: <pegar en secreto de cliente>
25 - nombre: OAUTH2_PROXY_COOKIE_SECRET
26 valor: algo muy aleatorio
27 - nombre: OAUTH2_PROXY_HTTP_ADDRESS
28 valor: "0.0.0.0:4180"
29 - nombre: OAUTH2_PROXY_UPSTREAM
30 valor: "https: // <su prefijo DNS>. <su región azul>.
cloudapp.azure.com/ "
31 - nombre: OAUTH2_PROXY_EMAIL_DOMAINS
32 valor: '*'
33 imagen: quay.io/pusher/oauth2_proxy:latest
34 imagePullPolicy: IfNotPresent
36 puertos:
38 protocolo: TCP
Este despliegue tiene un par de líneas interesantes para discutir. Discutimos las otras líneas en
ejemplos anteriores en Capítulo 3, Implementación de aplicaciones en AKS. Nos centraremos en las
siguientes líneas aquí:
Líneas 17-18: Estas líneas le dicen al oauth2 proxy para redirigir a Azure AD.
Líneas 19-32: Este es el oauth2 configuración.
Línea 33: Esta línea apunta a la imagen de contenedor correcta. Esta es la primera vez que
usamos una imagen que no está alojada en Docker Hub. Muelle es un repositorio de
contenedores alternativo, alojado por RedHat.
Cree la implementación con el siguiente comando:
kubectl create -f oauth2_deployment.yaml
2. A continuación, oauth2 debe exponerse como un servicio para que Ingress pueda hablar con él
creando el siguiente servicio ( oauth2_service.yaml):
1 apiVersion: v1
2 tipo: Servicio
3 metadatos:
5 espacio de nombres: predeterminado
6 Especificaciones:
7 puertos:
8 - nombre: http
9 puerto: 4180
10 protocolo: TCP
11 targetPort: 4180
12 selector:
Crea este servicio usando:
kubectl crea oauth2_service.yaml

3. A continuación, crearemos un Ingress para que cualquier URL que vaya a handsonaks-ingreso-
<tu nombre>. <tu región azul> .cloudapp.azure.com / oauth será redirigido a la oauth2-proxy
Servicio. Aquí se utiliza el mismo emisor de certificado Let's Encrypt (el oauth2_ingress.yaml
archivo en el código fuente de este capítulo):

2 tipo: Ingress
3 metadatos:
4 nombre: oauth2-proxy-ingress
5 anotaciones:
6 kubernetes.io/ingress.class: nginx
7 cert-manager.io/issuer: "letsencrypt-prod"
8 Especificaciones:
9 tls:
10 - Hospedadores:
11 - <su prefijo DNS>. <su región azul> .cloudapp.azure.com

12 secretName: tls-secreto
13 normas:
14 - host: <su prefijo DNS>. <su región azul> .cloudapp.azure.com 15
http:
dieciséis rutas:
17 - ruta: / oauth2
18 backend:
19 serviceName: oauth2-proxy
20 servicePort: 4180
Hay una línea interesante para señalar en este Ingress. Línea 17 introdujo un nuevo camino a
nuestro Ingress. Como se mencionó anteriormente en este capítulo, el mismo Ingress puede tener
múltiples rutas dirigidas a diferentes servicios de back-end. Esto es lo que estamos configurando
aquí.
Cree este Ingress con el siguiente comando:
kubectl create -f oauth2_ingress.yaml

4. Finalmente, enlazaremos el oauth2 proxy al servicio de front-end mediante la creación de un

Ingreso que configura nginx para que la autenticación se verifique utilizando las rutas
en auth-url y auth-signin. Si la solicitud no está autenticada, el tráfico se envía al oauth2_proxy.
Si se autentica con éxito, el tráfico se redirige al servicio de back-end (en nuestro caso, es
el servicio de front-end).
El siguiente código realiza la redirección una vez que la autenticación es exitosa ( frontend-oauth2-ingr
en el repositorio de GitHub):
1 apiVersion: extensiones / v1beta1

2 tipo: Ingress
3 metadatos:
4 nombre: frontend-oauth2-ingress
5 anotaciones:
6 kubernetes.io/ingress.class: nginx
7 nginx.ingress.kubernetes.io/auth-url: "http: //oauth2-proxy.default.
svc.cluster.local: 4180 / oauth2 / auth"
8 nginx.ingress.kubernetes.io/auth-signin: "http: // <su prefijo DNS>.
<su región azul> .cloudapp.azure.com / oauth2 / start" 9 especificaciones:
10 normas:
11 - host: <su prefijo DNS>. <su región azul> .cloudapp.azure.com 12
http:
13 rutas:
14 - sendero: /
15 backend:
dieciséis serviceName: frontend
17 servicePort: 80
Hay un par de cosas interesantes que señalar en esta configuración de Ingress. Las otras
líneas son comunes con los otros Ingresses que hemos creado a lo largo de este capítulo:
Línea 5: Como se mencionó anteriormente, el objeto Ingress puede estar respaldado por
múltiples tecnologías (como NGINX o Application Gateway). El objeto Ingress tiene una sintaxis
para configurar tareas básicas, como Hospedadores y rutas, pero no tiene una configuración
para redirecciones de autenticación, por ejemplo. Varios proveedores de Ingress utilizan las
anotaciones para pasar datos de configuración detallados al proveedor de Ingress en el
back-end.
Líneas 7-8: Esto configura nuestro Ingress para enviar solicitudes no autenticadas a
estas URL.
Crea este Ingress usando el siguiente comando:
kubectl create -f frontend-oauth2-ingress.yaml
Ahora hemos terminado con la configuración. Ahora puede iniciar sesión con su cuenta de Microsoft
existente en el servicio en https: // handsonaks-ingress- <yourname>. <your blue region>.
cloudapp.azure.net/. Para asegurarse de obtener la redirección de autenticación, asegúrese de utilizar
una nueva ventana del navegador o una ventana privada. Debería ser redirigido automáticamente a la
página de inicio de sesión de Azure AD.
Nota
oauth2-proxy admite varios proveedores de autenticación, como GitHub y Google. Solo
el oauth2-proxy El YAML de la implementación debe cambiarse con el servicio adecuado
para cambiar el proveedor de autenticación. Consulte los detalles relevantes en https://github.com/push
provider-configuration .
Ahora que todo se ha implementado, limpiemos los recursos que creamos en nuestro
clúster:
kubectl eliminar -f frontend-oauth2-ingress.yaml
kubectl eliminar -f oauth2_ingress.yaml kubectl
eliminar -f oauth2_deployment.yaml kubectl
eliminar -f oauth2_service- delete ns kubectl
certificar gerente
timón eliminar ingreso
En esta sección, hemos agregado la autenticación de Azure AD a su aplicación. Hicimos esto

agregando el oauth2_proxy a nuestro clúster, y luego reconfiguramos el Ingress existente para
redirigir las solicitudes no autenticadas a oauth2_proxy.
Resumen
En este capítulo, agregamos seguridad HTTPS y control de identidad a nuestra aplicación de libro de
visitas sin cambiar realmente el código fuente. Comenzamos por configurar los objetos de Kubernetes
Ingress en nuestro clúster. Luego, instalamos un administrador de certificados que interactúa con la API
Let's Encrypt para solicitar un certificado para el nombre de dominio que especificamos posteriormente.
Aprovechamos un emisor de certificado para obtener el certificado de Let's Encrypt. Luego,
reconfiguramos nuestro Ingress para solicitar un certificado de este emisor en el clúster.
Luego, pasamos a la autenticación y la autorización y le mostramos cómo aprovechar

Azure AD como proveedor de autenticación para la aplicación del libro de visitas. Aprendió
a proteger sus aplicaciones a escala empresarial. Al integrarse con Azure AD, puede
permitir que cualquier aplicación se vincule al AD de una organización.
En el próximo capítulo, aprenderá cómo monitorear sus implementaciones y configurar alertas.

También aprenderá a identificar rápidamente las causas raíz cuando ocurren errores y aprenderá a
depurar aplicaciones que se ejecutan en AKS. Al mismo tiempo, aprenderá a realizar las
correcciones correctas una vez que haya identificado las causas fundamentales.
Supervisión de AKS
7
clúster y el
solicitud
Ahora que sabe cómo implementar aplicaciones en un clúster de AKS, centrémonos en cómo puede
garantizar que su clúster y sus aplicaciones permanezcan disponibles. En este capítulo, aprenderá a
monitorear su clúster y las aplicaciones que se ejecutan en él. Explorará cómo Kubernetes se asegura de
que sus aplicaciones se ejecuten de manera confiable mediante sondas de preparación y vitalidad.
También aprenderá cómo Monitor de Azure se usa y cómo se integra en Azure Portal, así
como cómo configurar alertas para eventos críticos en su clúster de AKS. Verá cómo puede
usar Azure Monitor para monitorear el estado del clúster en sí, los Pods en el clúster y
obtener acceso a los registros de los Pods a escala.
En resumen, en este capítulo se tratarán los siguientes temas:
• Supervisión y depuración de aplicaciones mediante kubectl
• Revisar las métricas informadas por Kubernetes
• Revisión de métricas de Azure Monitor

174 | Supervisión del clúster de AKS y la aplicación
Comencemos el capítulo revisando algunos de los comandos en kubectl que puede utilizar para
supervisar sus aplicaciones.
Comandos para monitorear aplicaciones

Monitorear el estado de las aplicaciones implementadas en Kubernetes, así como la propia
infraestructura de Kubernetes, es esencial para brindar un servicio confiable a sus clientes. Hay dos
casos de uso principales para el monitoreo:
• Monitoreo continuo para recibir alertas si algo no se comporta como se esperaba
• Solución de problemas y depuración de errores de aplicaciones
Al monitorear una aplicación que se ejecuta en la parte superior de un clúster de Kubernetes,

deberá examinar varias cosas en paralelo, incluidos contenedores, pods, servicios y los nodos del
clúster. Para el monitoreo continuo, necesitará un sistema de monitoreo como Azure Monitor o
Prometheus. Para solucionar problemas, deberá interactuar con el clúster en vivo. Los comandos
más comunes que se utilizan para solucionar problemas son los siguientes:
kubectl get <tipo de recurso> <nombre de recurso> kubectl
describe <tipo de recurso> <nombre de recurso> registros de
kubectl <nombre de pod>
Describiremos cada uno de estos comandos en detalle en este capítulo.
Antes de comenzar, vamos a tener un comienzo limpio con nuestro ejemplo de libro de
visitas. Vuelva a crear el ejemplo del libro de visitas con el siguiente comando:
Mientras que la crear se está ejecutando el comando, veremos su progreso en las siguientes
secciones.
El comando kubectl get

Para ver el panorama general de las aplicaciones implementadas, kubectl proporciona el obtener mando.
El obtener comando enumera los recursos que usted especifica. Los recursos pueden ser Pods,
ReplicaSets, Ingresses, nodos, Implementaciones, Secretos, etc. Ya hemos ejecutado este comando en
los capítulos anteriores para verificar que nuestra aplicación estaba lista para ser utilizada. Realice los
siguientes pasos:
1. Ejecute lo siguiente obtener comando, que nos proporcionará los recursos y su

estados:

Comandos para aplicaciones de monitorización | 175
Esto le mostrará todas las Implementaciones, ReplicaSets, Pods y Servicios en su espacio de

nombres:
Figura 7.1: Todos los recursos que se ejecutan en el espacio de nombres predeterminado
2. Centremos nuestra atención en los pods de nuestra implementación. Podemos obtener el estado de
los Pods con el siguiente comando:
Verá que, ahora, solo se muestran los Pods, como se ve en Figura 7.2. Investiguemos
esto en detalle:
Figura 7.2: Todos los pods en su espacio de nombres

La primera columna indica el nombre del Pod, por ejemplo, frontend-57d8c9fb45-c6qtm.

La segunda columna indica cuántos contenedores en el Pod están listos en comparación con la cantidad
total de contenedores en el Pod. La preparación se define mediante una sonda de preparación en
Kubernetes. Tenemos una sección dedicada llamada Sondas de preparación y vitalidad más adelante en este
capítulo.
La tercera columna indica el estado, por ejemplo, Pendiente, o ContainerCreating, o

Corriendo, y así. La cuarta columna indica el número de reinicios, mientras que la quinta
columna indica la edad en la que se solicitó la creación del Pod.
Si necesita más información sobre su pod, puede agregar columnas adicionales a la salida de un obtener
comando agregando - o ancho al comando como este:
Esto le mostrará información adicional como se muestra en Figura 7.3:
Figura 7.3: Agregar -o de ancho muestra más detalles sobre los Pods
Las columnas adicionales incluyen la dirección IP del Pod, el nodo en el que se está ejecutando, el nodo
designado y las puertas de preparación. Un nodo nominado solo se establece cuando un pod de mayor
prioridad reemplaza a un pod de menor prioridad. El nodo designado es el nodo en el que se iniciará ese pod
de mayor prioridad una vez que los pods de menor prioridad terminen correctamente. Una puerta de
preparación es una forma de introducir componentes externos del sistema como preparación para un Pod.
Ejecutando un conseguir vainas El comando solo muestra el estado del Pod actual. Para ver los
eventos de todos los recursos del sistema, ejecute el siguiente comando:
kubectl obtener eventos
Nota
Kubernetes mantiene eventos durante solo 1 hora de forma predeterminada. Todos los comandos
funcionan solo si el evento se disparó dentro de la última hora.
Si todo va bien, debería tener una salida similar a Figura 7.4:
Figura 7.4: Obtener los eventos muestra todos los eventos de la última hora
Como puede ver en la salida, los estados generales de un Pod son Programado | Tirando | Tirado
| Creado | Comenzó. Como veremos a continuación, las cosas pueden fallar en cualquiera de los estados, y necesitamos
usar la kubectl describe comando para cavar más profundo.
El comando kubectl describe

El kubectl obtener eventos El comando enumera todos los eventos de todo el espacio de nombres. Si
está interesado solo en Pods, puede usar el siguiente comando:
kubectl describe las vainas
El comando anterior enumera toda la información perteneciente a todos los pods. Esta suele ser
demasiada información para contenerla en un shell típico.
Si desea información sobre un Pod en particular, puede escribir lo siguiente:

kubectl describe pod / <pod-name>
Nota
Puede utilizar un barra oblicua o un espacio entre vaina y podname. Los siguientes
dos comandos tendrán la misma salida:
kubectl describe pod / <pod-name>
kubectl describe pod <pod-name>

Obtendrá una salida similar a Figura 7.5, que se explicará en detalle más adelante:
Figura 7.5: La descripción de un objeto muestra la salida detallada de ese objeto.

A partir de la descripción, puede obtener el nodo en el que se está ejecutando el Pod, cuánto tiempo
ha estado funcionando, su dirección IP interna, el nombre de la imagen de Docker, los puertos
expuestos, el env variables y los eventos (de la última hora).
En el ejemplo anterior, el nombre del Pod es frontend-57d8c9fb45-c6qtm. Como se menciona en

Capítulo 1, Introducción a Docker y Kubernetes, tiene el < Nombre de ReplicaSet> - <5 caracteres aleatorios> formato.
El réplica el nombre en sí se genera aleatoriamente desde la interfaz del nombre de la implementación: < nombre de
implementación> - <5 caracteres aleatorios>.
Figura 7.6 muestra la relación entre una implementación, un ReplicaSet y pods:
Figura 7.6: Relación entre una implementación, un ReplicaSet y pods
El espacio de nombres bajo el cual se ejecuta el Pod es defecto. Hasta ahora, solo hemos estado usando
defecto espacio de nombres, apropiadamente nombrado defecto. En los próximos capítulos, veremos cómo los
espacios de nombres nos ayudan a aislar Pods.
Otra sección que es importante de la salida anterior es la sección de nodo:

Nodo: aks-agentpool-39838025-vmss000005 / 10.240.0.7
La sección de nodos nos permite saber en qué nodo físico / VM se está ejecutando el Pod. Si el Pod se
reinicia repetidamente o tiene problemas de ejecución y todo lo demás parece correcto, es posible que
haya un problema con el nodo. Tener esta información es fundamental para realizar una depuración
avanzada.
La siguiente es la hora en que se programó inicialmente el Pod:
Hora de inicio: miércoles, 04 de marzo de 2020 02:53:55 +0000
Esto no significa que el Pod se haya estado ejecutando desde ese momento, por lo que el tiempo
puede ser engañoso en ese sentido. Si ocurre un evento de salud (por ejemplo, un contenedor falla), se
reiniciará un Pod.
Las conexiones entre recursos se realizan utilizando Etiquetas, como se muestra aquí:
Etiquetas: aplicación = libro de visitas
pod-template-hash = 57d8c9fb45
tier = frontend
Así es como conexiones como Servicio Despliegue | ReplicaSet | Vaina son hechos. Si ve que
el tráfico no se enruta a un Pod desde un Servicio, esto es lo primero que debe verificar. Si las
etiquetas no coinciden, los recursos no se adjuntarán.
A continuación, se muestra la IP interna del Pod y su estado:

Estado: en ejecución
IP: 10.244.5.52
Como se mencionó en capítulos anteriores, al construir su aplicación, los Pods se pueden mover a
diferentes nodos y obtener una IP diferente. Sin embargo, al depurar problemas de aplicaciones, tener
una IP directa para un Pod puede ayudar en la resolución de problemas. En lugar de conectarse a su
aplicación a través de un objeto de servicio, puede conectarse directamente de un Pod a otro para probar
la conectividad.
Los contenedores que se ejecutan en el Pod y los puertos que están expuestos se enumeran en el
siguiente bloque:
Contenedores: php-redis:
...
Imagen: gcr.io/google-samples/gb-frontend: v4
...
Puerto: 80 / TCP
Puerto de host: 0 / TCP
Medio ambiente:
GET_HOSTS_FROM: dns
En este caso, estamos obteniendo el gb-frontend contenedor con el v4 etiqueta de la gcr.io

registro de contenedor, y el nombre del repositorio es google-samples.
Puerto 80 está expuesta al tráfico exterior. Dado que cada pod tiene su propia IP, el mismo puerto
puede exponerse para varias instancias del mismo pod incluso cuando se ejecuta en el mismo host.
Por ejemplo, si tuviera dos Pods ejecutando un servidor web en el mismo nodo, ambos podrían usar
el puerto 80, ya que cada Pod tiene su propia dirección IP. Esta es una gran ventaja de gestión, ya que
no tiene que preocuparse por las colisiones de puertos. El puerto que debe configurarse también es
fijo para que los scripts se puedan escribir simplemente sin la lógica de averiguar qué puerto
realmente se asignó para el Pod.
Todos los eventos que ocurrieron en la hora anterior se muestran aquí:
Eventos:
Usando kubectl describe es muy útil para obtener más contexto sobre los recursos que está
ejecutando. En la siguiente sección, nos centraremos en depurar aplicaciones.
Aplicaciones de depuración
Ahora que tenemos un conocimiento básico de cómo monitorear las implementaciones, podemos comenzar a ver
cómo podemos depurar problemas con las implementaciones.
En esta sección, presentaremos errores comunes y determinaremos cómo depurarlos y

corregirlos.
Si aún no ha implementado la aplicación del libro de visitas, ejecute el siguiente

comando:
Después de un período de tiempo, los Servicios deberían estar en funcionamiento.
Errores de extracción de imágenes
En esta sección, vamos a introducir errores de extracción de imágenes estableciendo el valor de la etiqueta de la
imagen en uno inexistente. Se produce un error de extracción de imagen cuando Kubernetes no puede
descargar la imagen del contenedor que necesita para ejecutarse.
Ejecute el siguiente comando en Azure Cloud Shell:

kubectl editar implementación / interfaz
A continuación, cambie la etiqueta de la imagen de v4 para v_non_existent ejecutando los siguientes pasos:
1. Escriba / gb-frontend y golpea el Ingresar para que el cursor se lleve al

definición de imagen.
2. Golpea el I para entrar en el modo de inserción. Borrar v4 y escriba v_non_existent.
3. Ahora, cierre el editor presionando primero el Esc clave, luego escriba: wq! y golpea Ingresar.
La ejecución del siguiente comando enumera todos los pods en el espacio de nombres actual:
El comando anterior debe indicar errores, como se muestra en Figura 7.7:
Figura 7.7: Uno de los Pods tiene el estado de ImagePullBackOff

Ejecute el siguiente comando para obtener los detalles completos del error:
kubectl describe pods / <nombre de pod fallido>
Un ejemplo de salida de error se muestra en Figura 7.8. La línea de error clave está resaltada en rojo:
Figura 7.8: El uso de describe muestra más detalles sobre el error
Entonces, los eventos muestran claramente que la imagen no existe. Los errores como pasar credenciales
no válidas a repositorios Docker privados también aparecerán aquí.
Solucionemos el error volviendo a establecer la etiqueta de la imagen en v4:
1. Primero, escriba el siguiente comando en Cloud Shell para editar la implementación:
kubectl editar implementación / interfaz
2. Tipo / gb-frontend y presiona < entrar> para que el cursor se lleve a la definición de la
imagen.
3. Golpea el I para entrar en el modo de inserción. Borrar v_non_existent, y escriba v4.

4. Ahora, cierre el editor presionando primero el Esc clave, luego escriba: wq! y golpea Ingresar.
El La implementación debería arreglarse automáticamente. Puedes verificarlo obteniendo los eventos.

para los Pods de nuevo.
Nota
Debido a que Kubernetes realizó una actualización continua, la interfaz estuvo disponible
continuamente sin tiempo de inactividad. Kubernetes reconoció un problema con la nueva
especificación y dejó de implementar cambios adicionales automáticamente.
Pueden ocurrir errores de extracción de imágenes cuando las imágenes no están disponibles. En la siguiente sección,
exploraremos un error dentro de la propia aplicación.
Errores de aplicación
Ahora veremos cómo depurar un error de aplicación. Los errores de esta sección serán
autoinducidos, de forma similar a los de la última sección. El método para depurar el problema es
el mismo que usamos para depurar errores en aplicaciones en ejecución.
Para probar nuestro fracaso, tendremos que hacer el Interfaz Servicio de acceso público:
1. Para empezar, editaremos el Interfaz Servicio:
2. Tipo / ClusterIP y golpea Ingresar para llevar el cursor al campo de tipo (línea 27).
3. Golpea el I para entrar en el modo de inserción. Eliminar el ClusterIP y escriba
LoadBalancer.
4. Ahora, cierre el editor presionando primero el Esc clave, luego escriba: wq! y golpea Ingresar. Esto creará
una IP pública para nuestro servicio frontend.
5. Podemos obtener esta IP usando el siguiente comando:

6. Vamos a conectarnos al Servicio, pegando su IP pública en un navegador. Crea un par de

entradas:
Figura 7.9: Realice un par de entradas en la aplicación del libro de visitas
Nota
La mayoría de los errores provienen de una mala configuración, donde se pueden corregir editando la
especificación. Los errores en el código de la aplicación requieren la creación y el uso de una nueva
imagen.
Ahora tiene una instancia de la aplicación del libro de visitas en ejecución. Para mejorar la
experiencia con el ejemplo, reduciremos la interfaz para que solo se ejecute una única
réplica.
Reducir la escala de la interfaz
En Capítulo 3, Implementación de aplicaciones en AKS, aprendiste cómo la implementación de la

interfaz tiene una configuración de réplicas = 3. Esto significa que las solicitudes que recibe la
aplicación pueden ser manejadas por cualquiera de los Pods. Para introducir el error de la aplicación
y anotar los errores, tendríamos que realizar cambios en los tres.
Para facilitar este ejemplo, escale el réplicas para 1 para que tenga que realizar cambios en
un solo Pod:
kubectl scale --replicas = 1 implementación / frontend
Tener solo una réplica en ejecución facilitará la introducción del error. Introduzcamos
ahora este error.
Introduciendo un error de aplicación
En este caso, vamos a hacer el Entregar el botón no funciona. Necesitamos modificar el código
de la aplicación para esto.
Nota
No se recomienda realizar cambios de producción en su aplicación utilizando ejecutivo de
kubectl para ejecutar comandos en sus Pods. Si necesita realizar cambios en su aplicación, la
forma preferible es crear una nueva imagen de contenedor y actualizar su implementación.
Usaremos el ejecutivo de kubectl mando. Este comando le permite ejecutar comandos en la

línea de comandos de ese Pod. Con el - eso opción, adjunta un terminal interactivo al Pod y nos
da un shell en el que podemos ejecutar nuestros comandos. El siguiente comando lanza una
terminal Bash en el Pod:
kubectl exec -it <frontend-pod-name> bash
Una vez que esté en el shell del contenedor, ejecute el siguiente comando:
actualización apta
apt install -y vim

El código anterior instala el editor vim para que podamos editar el archivo para introducir un error. Ahora
usa empuje para abrir el guestbook.php expediente:
vim guestbook.php
Agregue la siguiente línea después de la línea 18. Recuerde, para insertar una línea en vim, presione el I clave. Una
vez que haya terminado de editar, puede salir presionando Esc, y luego escriba: wq! y luego presione Ingresar:
$ host = 'localhost';
if (! defined ('STDOUT')) define ('STDOUT', fopen ('php: // stdout', 'w'));
fwrite (STDOUT, "nombre de host al comienzo del comando 'set'"); fwrite (STDOUT, $
host);
fwrite (STDOUT, "\ n");
El archivo se verá así Figura 7.10:
Figura 7.10: El código actualizado que introdujo un error y registro adicional
Estamos introduciendo un error en el que la lectura de mensajes funcionaría, pero no la escritura.

Hacemos esto pidiendo a la interfaz que se conecte al maestro de Redis en el servidor localhost que no
existe. Las escrituras deberían fallar. Al mismo tiempo, para hacer esta demostración más visual,
agregamos algunos registros adicionales a esta sección del código.
Abra la aplicación de su libro de visitas navegando a su IP pública, y debería ver las

entradas de antes:
Figura 7.11: Las entradas de antes todavía están presentes

Ahora, cree un nuevo mensaje escribiendo un mensaje y presionando el Entregar botón:
Figura 7.12: Se creó un mensaje nuevo
Enviar un mensaje nuevo lo hace aparecer en nuestra aplicación. Si no lo supiéramos mejor,

habríamos pensado que la entrada estaba escrita de forma segura. Sin embargo, si actualiza
su navegador, verá que el mensaje ya no está allí.
Si tiene las herramientas de depuración de red activadas en su navegador, puede detectar la

respuesta de error del servidor.
Para verificar que el mensaje no se haya escrito en la base de datos, presione el botón Actualizar botón
en su navegador; verá solo las entradas iniciales y la nueva entrada ha desaparecido:
Figura 7.13: El nuevo mensaje ha desaparecido

Como desarrollador u operador de aplicaciones, probablemente obtendrá un ticket como este: Después de la nueva
implementación, las nuevas entradas no se conservan. Arreglalo.
Registros
El primer paso es obtener los registros. Salgamos de nuestro pod de front-end por ahora y obtengamos los registros
para este pod:
Salida
kubectl logs <frontend-pod-name>

Verá entradas como las que se ven en Figura 7.14:
Figura 7.14: El nuevo mensaje aparece como parte de los registros de la aplicación.
Por lo tanto, sabe que el error está en algún lugar al escribir en la base de datos en el colocar
sección del código.
Verás esta entrada:

nombre de host al comienzo del comando 'set' localhost
Entonces sabemos que el error está entre esta línea y el inicio del cliente, por lo que la configuración de $ host
= 'localhost' debe ser el error ofensivo. Este error no es tan infrecuente como podría pensar y, como acabamos
de ver, podría haber pasado fácilmente por el control de calidad a menos que hubiera habido una instrucción
específica para actualizar el navegador. Podría haber funcionado perfectamente bien para el desarrollador, ya
que podrían tener un servidor Redis en ejecución en la máquina local.
Hay dos opciones para corregir este error que presentamos ahora: podemos navegar hacia el Pod y hacer
los cambios de código, o podemos pedirle a Kubernetes que nos dé un nuevo Pod saludable. No se
recomienda realizar cambios manuales en los pods, por lo que usaremos el segundo enfoque.
Arreglemos este error eliminando nuestro Pod defectuoso:
kubectl eliminar pod <podname>
Como tenemos un ReplicaSet que controla nuestros Pods, deberíamos obtener inmediatamente un nuevo Pod que
haya comenzado a partir de la imagen correcta. Intente conectarse al libro de visitas nuevamente y verifique que los
mensajes persistan en las actualizaciones del navegador nuevamente.
Los siguientes puntos resumen algunos de los errores y métodos comunes para corregir estos
errores:
• Los errores pueden presentarse de muchas formas y formas.
• La mayoría de los errores encontrados por el equipo de implementación son problemas de configuración.
• Los registros son tus amigos.
• Usando ejecutivo de kubectl en un contenedor es una herramienta de depuración útil.
• Tenga en cuenta que permitir ampliamente ejecutivo de kubectl es un riesgo de seguridad grave, ya que
prácticamente permite que el operador de Kubernetes haga lo que quiera en los Pods a los que tiene acceso.
• Cualquier cosa impresa en stdout y stderr aparece en los registros (independientemente de la

aplicación / idioma / marco de registro).
Introdujimos un error de aplicación en la aplicación del libro de visitas y pudimos aprovechar los
registros de Kubernetes para identificar el problema en el código. En la siguiente sección, veremos
un poderoso mecanismo en Kubernetes llamado Sondas de preparación y vitalidad.
Sondas de preparación y vitalidad

Tocamos brevemente las sondas de preparación en la sección anterior. En esta sección, los
exploraremos con más profundidad.
Kubernetes utiliza sondas de disponibilidad y vitalidad para monitorear la disponibilidad de sus

aplicaciones. Cada sonda tiene un propósito diferente:
• A sonda de vivacidad supervisa la disponibilidad de una aplicación mientras se está ejecutando. Si falla una
sonda de vitalidad, Kubernetes reiniciará su Pod. Esto podría ser útil para detectar puntos muertos,
bucles infinitos o simplemente una aplicación "atascada".
• A sonda de preparación supervisa cuando su aplicación está disponible. Si falla una

sonda de preparación, Kubernetes no enviará tráfico a los pods que no estén listos. Esto
es útil si su aplicación tiene que pasar por alguna configuración antes de que esté
disponible, o si su aplicación podría sobrecargarse pero recuperarse de la carga
adicional.
No es necesario que las sondas de disponibilidad y vitalidad se proporcionen desde el mismo punto final
en su aplicación. Si tiene una aplicación inteligente, esa aplicación podría quedar fuera de rotación (lo que
significa que no se envía más tráfico a la aplicación) sin dejar de estar en buen estado. Para lograr esto, la
sonda de preparación fallaría, pero la sonda de actividad permanecería activa.
Construyamos esto en un ejemplo. Crearemos dos implementaciones de nginx, cada una con una
página de índice y una página de salud. La página de índice servirá como prueba de vida.
Sondas de preparación y vitalidad | 189
Construyendo dos contenedores web
Para este ejemplo, usaremos un par de páginas web que usaremos para conectarnos a nuestras
sondas de preparación y vitalidad. Primero creemos index1.html:
<! DOCTYPE html>
<html>
<cabeza>
<title> Servidor 1 </title>

</head>
<cuerpo>
Servidor 1
</body>
</html>
Después de eso, crea index2.html:
<! DOCTYPE html>
<html>
<cabeza>
<title> Servidor 2 </title>

</head>
<cuerpo>
Servidor 2
</body>
</html>
Creemos también una página de salud, healthy.html:
<! DOCTYPE html>
<html>
<cabeza>
<title> Todo está bien aquí </title>

</head>
<cuerpo>
OK
</body>
</html>
En el siguiente paso, montaremos estos archivos en nuestras implementaciones de Kubernetes. Convertiremos cada
uno de estos en un configmap que conectamos a nuestros Pods. Utilice los siguientes comandos para crear el mapa de
configuración:
kubectl crear configmap server1 --from-file = index1.html kubectl

crear configmap server2 --from-file = index2.html kubectl crear
configmap saludable --from-file = saludable.html
Con eso fuera del camino, podemos seguir adelante y crear nuestras dos implementaciones web. Ambos
serán muy similares, con solo el configmap cambiando. El primer archivo de implementación ( webdeploy1.yaml)
Se ve como esto:
1 apiVersion: aplicaciones / v1
2 tipo: Despliegue
...
18 contenedores:
19 - nombre: nginx-1
20 imagen: nginx
21 puertos:
23 livenessProbe:
24 httpGet:
25 ruta: /healthy.html
26 puerto: 80
27 initialDelaySeconds: 3
28 período Segundos: 3
29 readinessProbe:
30 httpGet:
31 ruta: /index.html
32 puerto: 80
33 initialDelaySeconds: 3
34 período Segundos: 3
35 volumeMounts:
36 - nombre: html
37 mountPath: / usr / share / nginx / html

38 - nombre: índice
39 mountPath: /tmp/index1.html
40 subPath: index1.html
41 - nombre: saludable
42 mountPath: /tmp/healthy.html
43 subPath: healthy.html
44 comando: ["/ bin / sh", "-c"]
45 argumentos: ["cp /tmp/index1.html /usr/share/nginx/html/index.html;
cp /tmp/healthy.html /usr/share/nginx/html/healthy.html; nginx; dormir inf "]
46 volúmenes:
47 - nombre: índice
48 configMap:
49 nombre: servidor1
50 - nombre: saludable
51 configMap:
52 nombre: saludable
53 - nombre: html
54 emptyDir: {}
Hay algunas cosas que destacar en esta implementación:
• Líneas 23-28: Esta es la prueba de la vitalidad. La sonda de vida apunta a la página

de salud. Recuerde, si la página de salud falla, el contenedor se reiniciará.
• Líneas 29-32: Esta es la prueba de preparación. La sonda de preparación en nuestro caso apunta a
la página de índice. Si esta página falla, no se enviará tráfico al Pod temporalmente, pero seguirá
funcionando.
• Líneas 44-45: Estas dos líneas contienen un par de comandos que se ejecutan cuando se inicia nuestro
contenedor. En lugar de simplemente ejecutar el servidor nginx, copiamos el índice y los archivos listos en
la ubicación correcta, luego iniciamos nginx y luego usamos un comando de suspensión (para que
nuestro contenedor siga funcionando).
Puede crear esta implementación con el siguiente comando. También puede implementar la
segunda versión para el servidor 2, que es similar al servidor 1:
kubectl create -f webdeploy1.yaml
kubectl create -f webdeploy2.yaml
Finalmente, también crearemos un Servicio que enruta el tráfico a ambas Implementaciones ( webservice.yaml):
1 apiVersion: v1
2 tipo: Servicio
3 metadatos:
4 nombre: web
5 Especificaciones:
6 selector:
7 aplicación: servidor web
8 puertos:
9 - protocolo: TCP
10 puerto: 80
11 targetPort: 80
12 tipo: LoadBalancer
Podemos crear ese Servicio usando lo siguiente:

kubectl create -f webservice.yaml
Ahora tenemos nuestra aplicación en funcionamiento. En la siguiente sección, presentaremos algunas fallas
para verificar el comportamiento de las sondas de disponibilidad y vitalidad.
Experimentar con sondas de vivacidad y preparación
En la sección anterior, explicamos la funcionalidad de las sondas de actividad y preparación y

creamos una aplicación de muestra. En esta sección, introduciremos errores en nuestra
aplicación y verificaremos el comportamiento de las sondas de actividad y preparación.
Veremos cómo una falla en la sonda de preparación hará que el Pod siga funcionando pero ya
no acepte tráfico. Después de eso, veremos cómo una falla en la sonda de vida hará que se
reinicie el Pod.
Comencemos por fallar la prueba de preparación.
Si no se realiza la prueba de preparación, el tráfico se detiene temporalmente
Ahora que tenemos una aplicación sencilla en funcionamiento, podemos experimentar con el comportamiento de las
sondas de actividad y preparación. Para comenzar, obtengamos la IP externa de nuestro Servicio para conectarse a
nuestro servidor web usando el navegador:

Si presiona la IP externa en el navegador, debería ver una sola línea que dice
Servidor 1 o Servidor 2:
Figura 7.15: Nuestra aplicación devuelve tráfico del servidor 2
Durante nuestras pruebas, usaremos un pequeño script llamado testWeb.sh para conectarnos a nuestra página web 50
veces, para que podamos monitorear una buena distribución de resultados entre el servidor 1 y 2. Primero necesitaremos
hacer que ese script sea ejecutable, y luego podemos ejecutar ese script mientras nuestra Implementación está
completamente en buen estado:
chmod + x testWeb.sh
. /testWeb.sh <ip-external>
Durante las operaciones en buen estado, podemos ver que el servidor 1 y el servidor 2 se ven afectados casi por igual, con 24
hits para el servidor 1, y 26 para el servidor 2:
Figura 7.16: Si bien la aplicación está en buen estado, el tráfico tiene un equilibrio de carga entre el servidor 1 y el servidor 2
Ahora sigamos adelante y falle la prueba de preparación en el servidor 1. Para hacer esto, ejecutivo
en el contenedor y mueva el archivo de índice a una ubicación diferente:
kubectl get pods #note server1 nombre del pod
kubectl exec <nombre del pod del servidor1> mv /usr/share/nginx/html/index.html / usr /

share / nginx / html / index1.html
Una vez que esto se ejecuta, podemos ver el cambio en el estado del Pod con el siguiente
comando:
kubectl get pods -w
Debería ver que el estado de preparación del servidor 1 Pod cambia a 0/1, como se muestra en
Figura 7.17:
Figura 7.17: Las sondas de preparación fallidas hacen que el servidor 1 no tenga contenedores READY
Esto no debería dirigir más tráfico al servidor 1 Pod. Verifiquemos:

En nuestro caso, el tráfico se redirige al servidor 2:
Figura 7.18: Todo el tráfico ahora es servido por el servidor 2
Ahora podemos restaurar el estado del servidor 1 moviendo el archivo de regreso al lugar que le corresponde:
kubectl exec <nombre del pod del servidor1> mv /usr/share/nginx/html/index1.html / usr / share
/ nginx / html / index.html
Esto devolverá nuestro Pod a un estado saludable y nuevamente debería dividir el tráfico en partes iguales:
Esto mostrará una salida similar a Figura 7.19:
Figura 7.19: La restauración de la sonda de preparación hace que el tráfico vuelva a equilibrarse la carga
Un sondeo de preparación fallido hará que Kubernetes ya no envíe tráfico al Pod fallido. Hemos
verificado esto haciendo que falle una sonda de preparación en nuestra aplicación de ejemplo. En la
siguiente sección, exploraremos el impacto de una sonda de vitalidad fallida.
Una sonda de vida que falla provoca el reinicio del contenedor
Podemos repetir el proceso anterior también con la sonda de vida. Cuando falla la prueba de
vida, esperamos que Kubernetes continúe y reinicie nuestro Pod. Intentemos esto eliminando
el archivo de salud:
kubectl exec <server1 pod name> rm /usr/share/nginx/html/healthy.html
Veamos qué hace esto con nuestro Pod:

kubectl get pods -w
Deberíamos ver que el Pod se reinicia en un par de segundos:
Figura 7.20: Una sonda de actividad que falla hará que el Pod se reinicie
Como puedes ver en Figura 7.20, el Pod se reinició correctamente, con un impacto limitado. Podemos
inspeccionar lo que estaba sucediendo en el Pod ejecutando un describir mando:
kubectl describe pod <server1 pod name>
El comando anterior le dará una salida similar a Figura 7.21:
Figura 7.21: Más detalles sobre el Pod que muestra cómo falló la sonda de actividad
En el describir comando, podemos ver claramente que el Pod falló la sonda de actividad.
Después de cuatro fallas, el contenedor se mató y se reinició.
Con esto concluye nuestro experimento con sondas de vivacidad y preparación. Recuerde que ambos
son útiles para su aplicación: se puede usar una sonda de preparación para detener temporalmente el
tráfico hacia su Pod, por lo que tiene que sufrir menos carga. Se utiliza una sonda de actividad para
reiniciar su Pod si hay una falla real en su Pod.
También asegurémonos de limpiar las implementaciones que acabamos de crear:
kubectl eliminar implementación servidor1 servidor2
kubectl eliminar servicio web
Las sondas de actividad y preparación son útiles para garantizar que solo los pods en buen estado
reciban tráfico en su clúster. En la siguiente sección, exploraremos diferentes métricas informadas por
Kubernetes que puede usar para verificar el estado de su aplicación.
Métricas informadas por Kubernetes

Kubernetes informa múltiples métricas. En esta sección, primero usaremos varios comandos de kubectl para
obtener estas métricas. Posteriormente, analizaremos Azure Monitor en busca de contenedores para ver cómo
Azure ayuda con la supervisión de contenedores.
Estado y consumo de nodo

Los nodos de su Kubernetes son los servidores que ejecutan su aplicación. Kubernetes programará
pods en diferentes nodos del clúster. Debe monitorear el estado de sus nodos para asegurarse de
que los nodos en sí estén en buen estado y que los nodos tengan suficientes recursos para ejecutar
nuevas aplicaciones.
Ejecute el siguiente comando para obtener información sobre los nodos del clúster:
El comando anterior enumera su nombre, estado y edad:
Figura 7.22: Hay dos nodos en este clúster

Métricas informadas por Kubernetes | 197
Puede obtener más información pasando el - o amplia opción:

kubectl get -o nodos anchos
La salida enumera el subyacente SO-IMAGEN y INTERNA-IP, y otra información útil, que

se puede ver en Figura 7.23:
Figura 7.23: El uso de -o wide agrega más detalles sobre nuestros nodos
Puede averiguar qué nodos consumen más recursos mediante el siguiente comando:
nodos superiores de kubectl
Muestra el uso de CPU y memoria de los nodos:
Figura 7.24: Uso de CPU y memoria de los nodos
Tenga en cuenta que este es el consumo real en ese momento, no el número de solicitudes que
tiene un determinado nodo. Para obtener las solicitudes, puede ejecutar:
kubectl describe el nodo <nombre del nodo>
Esto le mostrará las solicitudes y los límites por pod, así como la cantidad acumulada para
todo el nodo:
Figura 7.25: La descripción de los nodos muestra detalles sobre solicitudes y límites
Ahora sabe dónde puede encontrar información sobre la utilización de sus nodos. En la
siguiente sección, veremos cómo puede obtener las mismas métricas para pods individuales.
Consumo de vainas
Los pods consumen recursos de CPU y memoria de un clúster de AKS. Las solicitudes y los límites se utilizan
para configurar la cantidad de CPU y memoria que puede consumir un Pod. Las solicitudes se utilizan para
reservar una cantidad mínima de CPU y memoria, mientras que los límites se utilizan para establecer una
cantidad máxima de CPU y memoria por Pod.
En esta sección, exploraremos cómo podemos usar kubectl para obtener información sobre la utilización
de la CPU y la memoria de los pods.
Comencemos por explorar cómo podemos ver las solicitudes y los límites de un Pod que tenemos
actualmente en ejecución:
1. Para este ejemplo, usaremos los pods que se ejecutan en el sistema kube espacio de nombres. Obtener
todos los pods en este espacio de nombres:
kubectl get pods -n kube-system
Esto debería mostrar algo similar a Figura 7.26:
Figura 7.26: Los pods que se ejecutan en el espacio de nombres del sistema kube
Métricas informadas por Kubernetes | 199
2. Obtengamos las solicitudes y los límites para uno de los coredns Vainas. Esto puede hacerse
utilizando el describir mando:
kubectl describe pod coredns- <pod id> -n kube-system
En el describir comando, debería haber una sección similar a Figura 7.27:
Figura 7.27: Límites y solicitudes para CoreDNS Pod
Esto nos muestra que este Pod tiene un límite de memoria de 170 Mi, sin límite de CPU, y tiene una
solicitud de 100 m de CPU (lo que significa 0.1 CPU) y 70Mi de memoria.
Las solicitudes y los límites se utilizan para realizar la gestión de la capacidad en un clúster.
También podemos obtener el consumo real de CPU y memoria de un Pod ejecutando el
siguiente comando:
Cápsulas superiores kubectl -n sistema-kube
Esto debería mostrarle la salida similar a Figura 7.28:
Figura 7.28: Ver el consumo de CPU y memoria de los Pods

Utilizando el top kubectl El comando muestra el consumo de CPU y memoria en el momento en

que se ejecutó el comando. En este caso, podemos ver que el coredns Las vainas están usando 2m y 3m
CPU y están usando 21Mi y 17Mi de memoria.
En esta sección, hemos estado usando el kubectl comando para obtener información sobre la
utilización de recursos de los nodos y pods en nuestro clúster. Esta es información útil, pero está
limitada a ese momento específico. En la siguiente sección, usaremos Azure Monitor para obtener
información más detallada sobre el clúster y las aplicaciones en la parte superior del clúster.
Métricas informadas desde Azure Monitor

Azure Portal muestra muchas de las métricas que le gustaría ver combinadas con la
autorización, ya que solo el personal con acceso al portal puede ver estas métricas.
AKS Insights
El Perspectivas La sección de la hoja AKS proporciona la mayoría de las métricas que necesita saber sobre su
clúster. También tiene la capacidad de profundizar hasta el nivel del contenedor. También puede ver los
registros del contenedor.
Kubernetes hace que las métricas estén disponibles pero no las almacena. Azure Monitor se puede usar para
almacenar estas métricas y hacer que estén disponibles para consultas a lo largo del tiempo. Para recopilar las
métricas y los registros relevantes en Insights, Azure se conecta a la API de Kubernetes para recopilar las
métricas y luego las almacena en Azure Monitor.
Nota
Los registros de un contenedor pueden contener información confidencial. Por lo tanto, los derechos
para revisar los registros deben controlarse y auditarse.
Exploremos el Perspectivas pestaña de la hoja AKS. Comenzaremos con las métricas del clúster.
Métricas informadas desde Azure Monitor | 201
Métricas de clúster
Perspectivas muestra las métricas del clúster. Figura 7.29 muestra la utilización de la CPU y la
utilización de la memoria de todos los nodos del clúster:
Figura 7.29: La pestaña Clúster muestra el uso de CPU y memoria para el clúster
Las métricas del clúster también muestran el recuento de nodos y la cantidad de pods activos. El recuento de
nodos es muy importante, ya que puede realizar un seguimiento de si tiene nodos que estén en un No está
listo Expresar:
Figura 7.30: La pestaña Clúster muestra el recuento de nodos y la cantidad de pods activos
El Grupo La pestaña se puede usar para monitorear el estado de los nodos en el clúster. A continuación,
exploraremos el Salud pestaña.
Usando la pestaña Salud
El Salud La pestaña estaba en vista previa al momento de escribir este libro. Esta pestaña le muestra
una vista del estado de su clúster. Para mostrarle este estado, Azure supervisa y verifica los
componentes de infraestructura necesarios, así como el estado del nodo:
Figura 7.31: La pestaña Estado muestra el estado general del clúster
El Salud La pestaña es útil para realizar un seguimiento del estado general de su clúster. La siguiente pestaña que
exploraremos es la Nodos pestaña..
Nodos
El Nodos La vista le muestra métricas detalladas para sus nodos. También le muestra qué pods se
están ejecutando en cada nodo, como podemos ver en Figura 7.32:
Figura 7.32: Métricas detalladas de los nodos en el panel de vista de nodos
Si desea aún más detalles, puede hacer clic y obtener registros de eventos de Kubernetes
de sus nodos también:
Figura 7.33: Haga clic en Ver registros de eventos de Kubernetes para obtener los registros de un clúster
Esto abrirá Azure Log Analytics y habrá creado previamente una consulta para usted que muestra
los registros de su nodo. En nuestro caso, podemos ver que nuestros nodos se han reiniciado un par
de veces:
Figura 7.34: Log Analytics que muestra los registros de los nodos
Controladores
El Controladores La vista muestra detalles sobre todos los controladores (es decir, ReplicaSet,
DaemonSet, etc.) en su clúster y los Pods que se ejecutan en ellos. Esto le muestra una vista centrada en
el controlador de los contenedores en ejecución. Por ejemplo, puede encontrar el ReplicaSet frontend y
ver todos los pods y contenedores que se ejecutan en él, como se muestra en Figura 7.35:
Figura 7.35: La pestaña Controlador nos muestra todos los contenedores que se ejecutan en un ReplicaSet
La siguiente pestaña es la Contenedores pestaña, que nos mostrará las métricas, los registros y
las variables de entorno de un contenedor.
Métricas de contenedor, registros y variables de entorno
Al hacer clic en el Contenedores La pestaña enumera las métricas del contenedor, las variables de entorno y el
acceso a sus registros, como se muestra en Figura 7.36:
Figura 7.36: La pestaña Contenedores nos muestra todos los contenedores individuales
Nota
Es posible que observe un par de contenedores con un Desconocido Expresar. Esto es de
esperar en nuestra situación. Nuestro intervalo de tiempo en Azure Monitor está establecido
en las últimas 6 horas y, en las últimas 6 horas, hemos creado y eliminado varios pods. Ya no
existen, pero Azure Monitor sabe de su existencia e incluso mantuvo registros para ellos.
Podemos acceder a los registros de nuestro contenedor desde esta vista:
Figura 7.37: Acceda a los registros del contenedor
Esto nos muestra todos los registros que Kubernetes registró desde nuestra aplicación. Accedimos a estos
registros manualmente anteriormente en este capítulo. El uso de este enfoque puede ser mucho más
productivo, ya que podemos editar las consultas de registro y correlacionar registros de diferentes Pods y
aplicaciones en una sola vista:
Figura 7.38: Los registros se recopilan y se pueden consultar

Además de los registros, esta vista también muestra las variables de entorno que se establecen para el
contenedor. Para ver las variables de entorno, desplácese hacia abajo en la celda derecha de esta vista:
Figura 7.39: Las variables de entorno establecidas para el contenedor
Y eso concluye esta sección. Asegurémonos de limpiar nuestras Implementaciones para que podamos
continuar con un libro de visitas limpio en el próximo capítulo:
En esta sección, exploramos las aplicaciones de monitoreo que se ejecutan sobre Kubernetes. Usamos el AKS Perspectivas
pestaña en el portal de Azure para obtener una vista detallada de nuestro clúster y los contenedores que se
ejecutan en nuestro clúster.
Resumen
Comenzamos el capítulo mostrando cómo usar diferentes kubectl comandos para monitorear una
aplicación. Luego, mostramos cómo los registros que crea Kubernetes se pueden usar para depurar esa
aplicación. Los registros contienen toda la información que se escribe en stdout
y stderr. Por último, explicamos el uso de Azure Monitor para mostrar las métricas de AKS y las variables de
entorno, así como los registros con filtrado de registros. También mostramos cómo depurar problemas de
aplicaciones y clústeres mediante el uso de kubectl y monitoreo de Azure Monitor.
En el siguiente capítulo, aprenderemos cómo conectar un clúster de AKS a los servicios de Azure PaaS. Nos
centraremos específicamente en cómo puede conectar un clúster de AKS a una base de datos MySQL
administrada por Azure.
Sección 3: Aprovechamiento
Azure avanzado
Servicios PaaS
Hasta este punto del libro, hemos ejecutado varias aplicaciones sobre AKS. Las aplicaciones siempre
fueron autónomas, lo que significa que la aplicación completa se pudo ejecutar en su totalidad sobre
AKS. Existen ciertas ventajas al ejecutar una aplicación completa sobre AKS. Obtiene portabilidad de
la aplicación, ya que puede mover esa aplicación a cualquier otro clúster de Kubernetes con poca
fricción. También tiene el control total de la aplicación de un extremo a otro.
Un gran control conlleva una gran responsabilidad. Hay ciertas ventajas en descargar partes de su
aplicación a uno de los servicios PaaS que ofrece Azure. Por ejemplo, al descargar su base de datos
a un servicio PaaS administrado, ya no necesita ocuparse de actualizar el servicio de la base de
datos, las copias de seguridad se realizan automáticamente por usted y una gran cantidad de
registro y monitoreo se realiza de inmediato.
En los próximos capítulos, presentaremos múltiples integraciones avanzadas y las ventajas

que conllevan. Después de leer esta sección, debería poder acceder de forma segura a
otros servicios de Azure, como la base de datos SQL de Azure, Event Hubs y Azure
Functions.
• Capítulo 8, Conexión de una aplicación a una base de datos de Azure
• Capítulo 9, Conexión a Azure Event Hubs

• Capítulo 10, Protección de su clúster de AKS
• Capítulo 11, Funciones sin servidor
Comenzaremos esta sección con Capítulo 8, Conexión de una aplicación a una base de datos de Azure, en
el que conectaremos una aplicación a una base de datos administrada de Azure.
Conectando una aplicación a
8
una base de datos de Azure
En capítulos anteriores, almacenamos el estado de nuestra aplicación en nuestro clúster, ya sea en un

clúster de Redis o en MariaDB. Quizás recuerde que ambos tuvieron algunos problemas en lo que
respecta a la alta disponibilidad. Este capítulo lo guiará por el proceso de conexión a una base de datos
MySQL administrada por Azure.
Discutiremos los beneficios de usar una base de datos alojada versus ejecutar StatefulSets
en el propio Kubernetes. Para crear esta base de datos alojada y administrada, haremos uso de
Open Service Broker para Azure (OSBA). OSBA es una forma de crear recursos de Azure,
como una base de datos MySQL administrada, desde un clúster de Kubernetes. En este
capítulo, explicaremos más detalles sobre el proyecto OSBA y configuraremos OSBA en nuestro
clúster.
Luego usaremos OSBA para crear una base de datos MySQL en Azure. Usaremos esta base de datos
administrada como parte de una aplicación de WordPress. Esto le mostrará cómo puede conectar una
aplicación a una base de datos administrada.
214 | Conexión de una aplicación a una base de datos de Azure
Además, te mostraremos aspectos de seguridad, respaldo, recuperación ante desastres (DR),

autorización y registro de auditoría. También se explorará el escalado independiente de la
base de datos y el clúster. Desglosaremos la discusión de este capítulo en los siguientes
temas:
• Configuración de OSBA
• Ampliación de nuestra aplicación para conectarse a una base de datos de Azure
• Exploración de operaciones avanzadas de bases de datos
• Revisión de registros de auditoría
Comencemos configurando OSBA en nuestro clúster.
Configuración de OSBA
En esta sección, configuraremos OSBA en nuestro clúster. OSBA nos permitirá crear una base
de datos MySQL sin salir del clúster de Kubernetes. Comenzaremos esta sección explicando los
beneficios de usar una base de datos alojada frente a ejecutar StatefulSets en Kubernetes.
Los beneficios de utilizar un servicio de base de datos administrado
Todos los ejemplos que hemos analizado hasta ahora han sido autónomos, es decir, todo se ejecutó dentro del
clúster de Kubernetes. Casi cualquier aplicación de producción tiene estado, que generalmente se almacena en
una base de datos. Si bien es una gran ventaja ser mayoritariamente independiente de la nube, esto tiene una
gran desventaja cuando se trata de administrar una carga de trabajo con estado, como una base de datos.
Cuando ejecuta su propia base de datos sobre un clúster de Kubernetes, debe ocuparse de la escalabilidad, la
seguridad, la alta disponibilidad, la recuperación ante desastres y la copia de seguridad. Los servicios de base de
datos administrada que ofrecen los proveedores de la nube pueden liberarlo a usted oa su equipo de tener que
ejecutar estas tareas. Por ejemplo, Azure Database for MySQL viene con seguridad y cumplimiento de nivel
empresarial, alta disponibilidad incorporada y copias de seguridad automatizadas. El servicio se escala en
segundos y, opcionalmente, se puede configurar muy fácilmente para la recuperación ante desastres.
Es mucho más sencillo consumir una base de datos de nivel de producción de Azure que configurar y
administrar la suya propia en Kubernetes. En la siguiente sección, exploraremos una forma en que se
puede usar Kubernetes para crear estas bases de datos en Azure.
Configuración de OSBA | 215
¿Qué es OSBA?
En esta sección, exploraremos qué es OSBA.
Como ocurre con la mayoría de las aplicaciones en estos días, gran parte del trabajo duro ya lo ha hecho
la comunidad de código abierto (incluidos los que trabajan para Microsoft). Microsoft se ha dado cuenta
de que a muchos usuarios les gustaría utilizar sus servicios gestionados de Kubernetes y que necesitan
una forma más sencilla de utilizar las mismas metodologías que se utilizan para la implementación de
Kubernetes. Para ayudar en este esfuerzo, han publicado gráficos de Helm que utilizan estos servicios
administrados como backend ( https://github.com/Azure/helm-charts ).
Una parte clave de la arquitectura que le permite crear recursos de Azure desde
Kubernetes es OSBA ( https://osba.sh/ ). OSBA es un Agente de servicio abierto (OSB)
implementación para Azure. La API OSB es una especificación que define un lenguaje común para los proveedores
de plataformas que las aplicaciones nativas de la nube pueden usar para administrar servicios en la nube sin
bloqueo.
La API de OSB en sí no es específica de Azure o Kubernetes. Es un esfuerzo de la industria para

simplificar el aprovisionamiento de recursos a través de una API estandarizada. Le permite conectarse a
servicios de terceros de forma estandarizada.
Cuando se usa la API OSB con Kubernetes, una extensión llamada Catálogo de servicios se ejecuta
en el clúster. El catálogo de servicios escuchará las solicitudes de la API de Kubernetes y las
traducirá a la API de OSB para interactuar con el proveedor de la plataforma. Esto significa que
cuando realiza una solicitud de una base de datos, la API de Kubernetes enviará esa solicitud al
Catálogo de servicios, que a su vez utilizará la API OSB para interactuar con la plataforma. Figura 8.1
ilustra este flujo lógico:
Figura 8.1: Flujo lógico de solicitar una base de datos mediante OSB en un clúster de Kubernetes
OSBA es una implementación de OSB para múltiples servicios de Azure. Permite a un usuario utilizar la
API de OSB para crear cualquiera de los 14 servicios de Azure compatibles. Uno de esos servicios es Azure
Database for MySQL. Esto significa que puede definir una base de datos MySQL en Azure a través de OSBA
sin tener que usar Azure Portal.
En la siguiente sección, nos centraremos en cómo instalar OSBA en nuestro clúster.

Instalación de OSBA en el clúster
Instalaremos OSBA en nuestro clúster. Hay dos elementos en esta instalación. Primero, instalaremos
la extensión Service Catalog en nuestro clúster. Después de eso, podemos instalar OSBA en el
clúster.
Como instalaremos varios componentes en nuestro clúster, nuestro clúster de dos nodos no será suficiente para
este ejemplo. Escalemos de forma proactiva nuestro clúster de AKS a tres nodos para que no tengamos ningún
problema durante este ejemplo:
az aks scale -n <nombre de clúster> -g <grupo de recursos de clúster> -c 3
Esta escala tardará un par de minutos. Cuando el clúster se escala a tres nodos, podemos comenzar
con la implementación del catálogo de servicios en el clúster.
Implementar el catálogo de servicios en el clúster
El catálogo de servicios proporciona los servidores de catálogo necesarios para el OSB. Para
implementar el catálogo de servicios en el clúster, siga estos pasos:
1. Implementemos el catálogo de servicios ejecutando los siguientes comandos:
kubectl crea un catálogo de espacios de nombres
helm repo agregar svc-cat https://svc-catalog-charts.storage.googleapis.com

helm install catalog svc-cat / catalog --namespace catalog
2. Espere hasta que se implemente el catálogo de servicios. Puede verificar esto ejecutando el
siguiente comando:
kubectl obtener todo -n catálogo
3. Verifique que ambos pods en la implementación estén Corriendo y completamente listo:
Figura 8.2: Implementación exitosa del catálogo de servicios

4. Para interactuar con el agente de servicios, necesitamos instalar otra herramienta CLI, a saber
svcat. Podemos hacer eso con el siguiente comando:
curl -sLO https://download.svcat.sh/cli/latest/linux/amd64/svcat chmod

+ x ./svcat
. / svcat versión --client
Ahora tenemos un catálogo de servicios configurado en la parte superior de nuestro clúster. Ahora,
podemos continuar e instalar OSBA en el clúster.
Implementación de OSBA
En esta sección, implementaremos el OSBA real en nuestro clúster. Para esta configuración, necesitamos
para obtener el ID de suscripción, el ID de inquilino, el ID de cliente y los secretos para que OSBA lance servicios de
Azure en nuestro nombre:
1. Ejecute el siguiente comando para obtener las listas necesarias:
lista de cuentas az
La salida será como se muestra en Figura 8.3:
Figura 8.3: Salida que muestra la lista requerida: ID de suscripción e ID de inquilino
2. Copie su ID de suscripción junto con ID de inquilino y guárdalo en un entorno

variable:
exportar AZURE_SUBSCRIPTION_ID = "<SubscriptionId>"

exportar AZURE_TENANT_ID = "<Inquilino>"
3. Cree una entidad de servicio con RBAC habilitado para que pueda iniciar los servicios de
Azure. Si comparte su suscripción con otra persona, asegúrese de que el nombre de la
entidad de servicio sea único en su directorio:
az ad sp create-for-rbac --name osba-quickstart -o tabla
Figura 8.4: Salida que muestra las credenciales de la entidad de servicio
Nota
Para que el paso anterior se complete correctamente, debe tener el rol de propietario en su
suscripción de Azure.
4. Guarde los valores de la salida del comando en la variable de entorno:
exportar AZURE_CLIENT_ID = "<AppId>"

exportar AZURE_CLIENT_SECRET = "<Password>"
5. Ahora, podemos implementar OSBA de la siguiente manera:
kubectl crear espacio de nombres osba

helm repo agregar azure https://kubernetescharts.blob.core.windows.net/azure
helm install osba azure / open-service-broker-azure \
- - espacio de nombres osba \
- - establecer azure.subscriptionId = $ AZURE_SUBSCRIPTION_ID \

- - establecer azure.tenantId = $ AZURE_TENANT_ID \
- - establecer azure.clientId = $ AZURE_CLIENT_ID \
- - establecer azure.clientSecret = $ AZURE_CLIENT_SECRET
Para verificar que todo se implementó correctamente, puede ejecutar el siguiente

comando:
kubectl obtener todo -n osba

Espere hasta que ambos Pods estén en el Corriendo Expresar. Si uno de los Pods está en el Error
estado, no tiene que preocuparse. Los Pods OSBA se reiniciarán automáticamente y deberían
alcanzar un estado saludable. En nuestro caso, uno de los pods se reinició tres veces, como se
Figura 8.5: Salida que muestra los pods OSBA en el estado En ejecución
6. Para verificar que nuestra implementación fue completamente exitosa, podemos usar el svcat
utilidad que descargamos en la sección anterior:
. / svcat obtener corredores
Esto debería mostrarle su agente de Azure:
Figura 8.6: Salida que muestra el agente de Azure que se ejecuta en el clúster
7. Además, también puede verificar todos los servicios que puede implementar a través del controlador OSBA:
. / svcat obtener clases

Esto le mostrará una lista de servicios que se pueden crear usando OSBA, como se muestra en
Figura 8.7:
Figura 8.7: Una lista (recortada) de los servicios que se pueden crear usando OSBA
En esta sección, configuramos el catálogo de servicios y OSBA en nuestro clúster. Esto significa que ahora
podemos crear servicios administrados por Azure desde nuestro clúster. Usaremos esta capacidad en la
siguiente sección, cuando implementemos WordPress usando una base de datos administrada por Azure.
Implementación de WordPress
Los siguientes son los pasos para implementar WordPress:
1. Ejecute el siguiente comando para instalar WordPress:
kubectl crea ns wordpress

helm install wp azure / wordpress - espacio de nombres wordpress --set replicaCount = 1
- - establecer externalDatabase.azure.location = <su región de Azure>
2. Para verificar el estado del Pod de WordPress, ejecute el siguiente comando:

kubectl obtener pods -n wordpress
Esto debería mostrar el estado de un solo Pod de WordPress como se muestra en Figura 8.8.
En nuestros ejemplos anteriores de WordPress, siempre teníamos dos Pods en ejecución, pero
pudimos descargar la funcionalidad de la base de datos a Azure aquí:
Figura 8.8: Salida que muestra solo un Pod de WordPress y ninguna base de datos en nuestro clúster
Implementación de WordPress | 221
3. Mientras se crea el Pod de WordPress, también podemos verificar el estado de la base de datos.
Podemos usar dos herramientas para obtener este estado, ya sea svcat o kubectl:
. / svcat obtener instancias -n wordpress
Figura 8.9: Salida que muestra el uso de svcat para obtener nuestra instancia de MySQL
Podemos obtener un resultado similar usando kubectl:
kubectl obtener instancias de servicio -n wordpress
Figura 8.10: Salida que muestra el uso de kubectl para obtener nuestra instancia de MySQL
Como puede ver, los resultados de cada método son similares.
4. Espere unos minutos a que se complete la implementación. Primero, la base de datos debe estar
completamente aprovisionada y, luego, el Pod de WordPress debe ingresar al Corriendo
Expresar. Para verificar que todo esté funcionando correctamente, verifique el estado del Pod de WordPress y
asegúrese de que esté Corriendo:
kubectl obtener pods -n wordpress
Figura 8.11: Salida que muestra el estado de WordPress Pod
Ahora hemos implementado WordPress utilizando una base de datos administrada por Azure. Sin embargo, la
conectividad a nuestra base de datos, por defecto, está abierta a Internet. Cambiaremos esto en la siguiente
sección.
Asegurar MySQL
Aunque muchos pasos están automatizados para nosotros, esto no significa que nuestra base de datos MySQL esté
lista para producción. Por ejemplo, la configuración de red para MySQL Server tiene una regla predeterminada que
permite el tráfico desde cualquier lugar. Cambiaremos esto a una regla de punto final de servicio más segura,
también llamada Reglas de red virtual.
Un punto de conexión de servicio en Azure es una conexión de seguridad entre la red

(también denominada VNet) que usa para su implementación y el servicio al que se conecta.
En el caso de AKS y MySQL, esto haría una conexión segura entre la VNet en la que se
implementa AKS y el servicio MySQL.
Configuraremos nuestra base de datos MySQL para usar un punto final de servicio en esta sección:
1. Para realizar este cambio, busque mysql en la barra de búsqueda de Azure:
Figura 8.12: Búsqueda de MySQL en la barra de búsqueda de Azure
2. En la hoja MySQL, vaya a Seguridad de la conexión en la navegación de la izquierda:
Figura 8.13: Hacer clic en Seguridad de conexión

Implementación de WordPress | 223
3. Existe una regla predeterminada que permite una conexión a la base de datos desde cualquier dirección IP.
Puede agregar AKS VNet al Reglas de red virtual sección y eliminar el
AllowAll 0.0.0.0 regla, como se muestra en Figura 8.14:
Figura 8.14: Agregar su AKS VNet a la sección de reglas de VNet y eliminar la regla AllowAll
Hemos reducido enormemente la superficie de ataque al realizar este simple cambio. Ahora podemos
conectarnos a nuestro sitio de WordPress.
Conectarse al sitio de WordPress

Puede verificar que el sitio de su blog esté disponible y en ejecución utilizando EXTERNAL_IP, que se
obtiene ejecutando el siguiente comando:
kubectl obtener servicio -n wordpress
Esto generará una salida como se muestra Figura 8.15:
Figura 8.15: Salida mostrando la IP externa del servicio

Luego, abra un navegador web y vaya a http: // <IP_EXTERNAL> /. Debería ver su nuevo
blog:
Figura 8.16: El aspecto final del blog de WordPress
En esta sección, hemos lanzado un sitio de WordPress que está respaldado por una base de datos
administrada por Azure. También lo hemos asegurado modificando el cortafuegos. En la siguiente
sección, analizaremos las ventajas de permitir que Azure administre su base de datos.
Explorando operaciones avanzadas de bases de datos
Ejecutar su base de datos como un servicio administrado sobre Azure tiene muchas ventajas. En esta sección,
exploraremos esos beneficios. Exploraremos la restauración desde una copia de seguridad, cómo puede configurar la
recuperación ante desastres y cómo puede acceder a los registros de auditoría para verificar quién realizó cambios en
su base de datos.
Comenzaremos restaurando nuestra base de datos desde una copia de seguridad.
Restaurar desde una copia de seguridad
Cuando ejecuta una base de datos dentro de su clúster de Kubernetes, alta disponibilidad (HA),
las copias de seguridad y la recuperación ante desastres son sus responsabilidades. Dediquemos un
tiempo a explicar las diferencias entre esos tres conceptos:
Explorando operaciones avanzadas de bases de datos | 225
• DECIR AH: HA se refiere a la redundancia local en un servicio para garantizar que el servicio
permanezca disponible en caso de que falle un solo componente. Esto significa configurar múltiples
réplicas de un servicio y coordinar el estado entre ellas. En el contexto de una base de datos, esto
significa configurar un clúster de base de datos.
El servicio Azure Database for MySQL viene con HA integrado. Ofrece, en el momento de redactar
este documento, un SLA de disponibilidad del 99,99% por mes.
• Copias de seguridad: Las copias de seguridad se refieren a la realización de copias históricas de sus datos.
Las copias de seguridad son útiles cuando sucede algo imprevisto con sus datos, como la eliminación
accidental de datos o la sobrescritura de datos. Si ejecuta su propia base de datos, debe configurar cron trabajos
para realizar copias de seguridad y almacenarlos por separado.
Azure Database for MySQL maneja las copias de seguridad automáticamente, sin configuración
adicional. El servicio realiza una copia de seguridad cada 5 minutos y le permite restaurarlo en cualquier
momento. Las copias de seguridad se conservan de forma predeterminada durante 7 días, con una
configuración opcional que permite conservar las copias de seguridad hasta por 25 días.
• DR: DR se refiere a la capacidad de un sistema para recuperarse de un desastre. Por lo general, esto
se refiere a la capacidad de recuperarse de una interrupción regional completa. Si ejecuta su propia
base de datos, esto implicaría configurar una base de datos secundaria en una segunda región y
replicar los datos en esa base de datos.
En el caso de Azure Database for MySQL, es fácil configurar la recuperación ante desastres. El
servicio permite configurar una base de datos administrada secundaria y replicar datos de su
región principal a la región secundaria.
Nota
Puede referirse a https://docs.microsoft.com/azure/mysql/concepts-backup para encontrar información
actualizada sobre la frecuencia de la copia de seguridad, la replicación y las opciones de restauración.
Los términos HA, backup y DR a menudo se confunden entre sí. Es importante utilizar la terminología
correcta y que comprenda la diferencia entre los tres conceptos. En esta sección, nos centraremos en las
copias de seguridad y realizaremos una restauración desde nuestra base de datos de WordPress. Para
demostrar que la operación de restauración restaurará los datos del usuario, primero crearemos una
publicación de blog.
Crear una publicación de blog en WordPress
Crearemos una publicación de blog para demostrar que la operación de restauración capturará nuevos datos que
generemos en la base de datos. Para poder realizar esta publicación, necesitamos las credenciales de administrador de
nuestro sitio. Primero obtendremos esas credenciales y luego haremos una nueva publicación:
1. Para obtener las credenciales de administrador, use el siguiente comando:
echo Contraseña: $ (kubectl get secret --namespace wordpress \

wp-wordpress -o jsonpath = "{. data.wordpress-password}" | \
base64 --decode)
Esto le mostrará la contraseña para conectarse a su sitio web de administración:
Figura 8.17: Obtener las credenciales de administrador
2. Ahora busque http: // <IP EXTERNA> / admin para abrir la página de administración para
Sitio de WordPress. Usa el nombre de usuario usuario y la contraseña del paso anterior para iniciar
sesión.
3. Una vez conectado, seleccione el Escribe tu primera publicación de blog Enlace:
Figura 8.18: Hacer clic en el enlace para escribir una publicación

4. Cree una publicación de blog. El contenido no es importante. Una vez que esté satisfecho con la publicación
de su blog, seleccione el Publicar botón para guardar y publicar la publicación del blog:
Figura 8.19: Crear una publicación de blog de muestra y hacer clic en el botón Publicar para guardarla
5. Ahora puede conectarse a http: // <IP EXTERNA> para ver la publicación de tu blog:
Figura 8.20: Nota que muestra el estado correcto de la publicación del blog
Ahora que tenemos una publicación de blog guardada, espere al menos 5 minutos. Azure realiza una copia de
seguridad de la base de datos MySQL cada 5 minutos y queremos asegurarnos de que se haya realizado una copia de
seguridad de nuestros nuevos datos. Una vez que hayan pasado esos 5 minutos, podemos continuar con el siguiente
paso y realizar la restauración real.
Realizar una restauración
Ahora tenemos contenido real en nuestro blog y en la base de datos. Supongamos que durante una actualización, la
base de datos se corrompió y, por lo tanto, queremos hacer una restauración en un momento determinado:
1. Para iniciar la operación de restauración, haga clic en Restaurar en la hoja MySQL en Azure
portal:
Figura 8.21: Hacer clic en el botón Restaurar para iniciar el proceso de restauración
2. Luego, debe elegir el momento desde el que desea realizar la restauración. Este momento
puede ser la hora actual. Asigne un nombre a la base de datos restaurada, que debe ser
único, como se muestra en Figura 8.22. Finalmente, haga clic en está bien. Después de
aproximadamente 5 a 10 minutos, el servicio MySQL debería restaurarse:
Figura 8.22: Seleccionar el momento para restaurar y hacer clic en el botón Aceptar
En esta sección, restauramos nuestra base de datos MySQL. Cuando se completa la operación de
restauración, queda un paso, que es conectar WordPress a la base de datos restaurada.
Conectando WordPress a la base de datos restaurada
La operación de restauración creó una nueva instancia de la base de datos. Para que nuestra instalación de
WordPress se conecte a la base de datos restaurada, necesitamos modificar los archivos de implementación de
Kubernetes. Idealmente, modificará el archivo de valores de Helm y realizará una actualización de Helm; sin
embargo, eso está más allá del alcance de este libro. Los siguientes pasos lo ayudarán a conectar WordPress a
la base de datos restaurada:
1. Desde Azure Portal, anote el Nombre del servidor, como se muestra en Figura 8..23:
Figura 8.23: Visualización del nombre completo de la base de datos restaurada

2. Además, modifique Seguridad de la conexión, como hicimos antes, para permitir que el clúster hable
a la base de datos restaurada. Quite la regla Permitir todo y agregue una regla de VNet a
la red de su clúster de AKS. El resultado se muestra en Figura 8.24:
Figura 8.24: Editando la seguridad de la conexión para la base de datos restaurada
3. A continuación, debemos conectar nuestro Pod de WordPress a la nueva base de datos. Señalemos cómo
sucede eso. Para obtener esa información, ejecute el siguiente comando:
kubectl describe implementar wp -n wordpress
Puede ver que los valores para conectarse a la base de datos se obtienen de un secreto, como se
Figura 8.25: Visualización de las variables de entorno para el Pod de WordPress

Durante la configuración de WordPress, el instalador guardará esta configuración en un archivo: /

nombre de bit / wordpress / wp-config.php. En los siguientes pasos, primero editaremos el secreto y luego
reconfiguraremos wp-config.php.
4. Para establecer secretos, necesitamos base64 valor. Obtener el base64 valor del nombre del
servidor ejecutando el siguiente comando:
echo <nombre del servidor de base de datos restaurado> | base64
Nota la base64 valor.
5. Ahora, seguiremos adelante y editaremos el nombre de host en el secreto. Para hacer esto, usaremos el
editar mando:
kubectl editar secreto wp-wordpress-mysql-secret -n wordpress
Esto abrirá un vi editor. Navegue hasta la línea que contiene anfitrión y presione el I
botón. Elimine el valor actual para el host y pegue el nuevo base64 valor codificado. Entonces
golpea Esc, tipo : wq !, y golpea Ingresar. Tu secreto debe verse como se muestra en
Figura 8.26:
Figura 8.26: Edición de la línea de host para que contenga el valor codificado en base64 del nuevo nombre del servidor
6. A continuación, necesitaremos cambiar esto en el wp-config.php archivo también. Para hacer esto, vamos
ejecutivo en el contenedor de WordPress actual y cambie ese valor:
kubectl exec -it <nombre de pod de wordpress> -n wordpress sh

apt update
apto instalar vim -y
vim /bitnami/wordpress/wp-config.php
Esto abrirá de nuevo un vi editor. Navegue a la línea 32, que contiene el DB_HOST
línea de configuración. Pegar I para ingresar al modo de inserción, y eliminar el valor actual y reemplazarlo con
el nombre de la base de datos restaurada como se muestra en Figura 8.27. Entonces golpea Esc, tipo : wq !, y
golpea Ingresar. Asegúrese de pegar el valor real, no el base64 codificado uno:
Figura 8.27: Cambiar el nombre de la base de datos a la base de datos restaurada
Luego, sal del Pod con el siguiente comando:
Salida
Aunque ahora hemos restablecido el valor secreto y el archivo de configuración, esto no significa que nuestro
servidor recogerá automáticamente el nuevo valor. Tendremos que reiniciar nuestro Pod ahora para
asegurarnos de que la configuración se lea nuevamente.
7. Hay muchas formas de hacer esto y vamos a eliminar el Pod existente. Una vez que se elimina
este Pod, nuestro ReplicaSet El controlador se dará cuenta de esto y creará un nuevo Pod.
Para eliminar el Pod, use el siguiente comando:
kubectl eliminar pod <nombre de pod de wordpress> -n wordpress

8. Después de un par de segundos, debería ver que se está creando un nuevo Pod. El nuevo
Pod tardará entre 5 y 10 minutos en conectarse. Una vez que esté en línea, puede ver los
registros del contenedor desde ese Pod y verificar que esté realmente conectado a la
nueva base de datos:
kubectl logs <nuevo pod de wordpress> -n wordpress
Esto debe contener una línea como se muestra en Figura 8.28:
Figura 8.28: Registros que muestran el Pod de WordPress conectado a la base de datos restaurada
Esto nos muestra que ahora estamos conectados a nuestra base de datos restaurada.
Podemos confirmar que se restauró el contenido real. Puede conectarse al sitio de
WordPress navegando a http: // <IP EXTERNA>:
Figura 8.29: Nota que muestra la restauración exitosa de la publicación del blog
En esta sección, exploramos las capacidades de copia de seguridad y restauración de Azure Database for
MySQL. Publicamos una publicación de blog y restauramos la base de datos donde se almacenaba esta
publicación. Conectamos nuestra instancia de WordPress a la base de datos restaurada y pudimos verificar
que la publicación del blog se restauró correctamente.
Realizar copias de seguridad es solo una de las capacidades de Azure Database for MySQL. En la
siguiente sección, exploraremos las capacidades de DR del servicio.
Opciones de recuperación ante desastres (DR)
Según los requisitos de la aplicación y las necesidades de recuperación ante desastres, puede agregar réplicas
a su servidor MySQL. Las réplicas se pueden crear en la misma región para mejorar el rendimiento de lectura
o en una región secundaria.
Si se está preparando para un escenario de recuperación ante desastres, deberá configurar una réplica en
una región secundaria. Esto lo protegerá de las interrupciones regionales de Azure. Cuando configure
esto, Azure replicará de forma asincrónica los datos del servidor maestro al servidor de réplica que
configuró. Mientras la replicación está en curso, el servidor de réplica se puede usar para leer, pero no
para escribir. Si ocurre un desastre, lo que significa que una región de Azure tiene una interrupción
regional, deberá detener la replicación para convertir el servidor de réplica en un servidor capaz de
atender solicitudes de lectura y escritura.
Es muy sencillo crear una réplica en una nueva región. Aunque configurar y probar la
replicación está fuera del alcance de este libro, mostraremos cómo se puede configurar. Para
configurar la replicación, debe abrir el Replicación pestaña en la hoja MySQL, como se muestra
en Figura 8.30:
Figura 8.30: Creación de una réplica a través de Azure Portal
Nota
Una lista completa de opciones de copia de seguridad, restauración y replicación se documenta
en https: // docs.microsoft.com/azure/mysql/concepts-backup y https://docs.microsoft. com /
azure / mysql / conceptos-lectura-réplicas .
En esta sección, describimos la capacidad de Azure Database for MySQL para replicarse en una región secundaria. Esta
réplica se puede utilizar para crear una estrategia de recuperación ante desastres para su base de datos. En la
siguiente sección, cubriremos cómo se puede usar el registro de actividad para auditar quién ha realizado cambios en
su servidor.
Revisión de registros de auditoría
Una base de datos contiene datos críticos para la empresa. Querrá tener un sistema de registro
que pueda mostrarle quién ha realizado cambios en su base de datos.
Cuando ejecuta la base de datos en el clúster de Kubernetes, es difícil obtener registros de auditoría
Si algo va mal. Necesita una forma sólida de establecer dinámicamente el nivel de auditoría
según el escenario. También debe asegurarse de que los registros se envíen fuera del
clúster.
El servicio Azure Database for MySQL resuelve los problemas anteriores al proporcionar un
mecanismo de auditoría sólido a través de Azure Portal. El servicio tiene dos vistas diferentes de los
registros:
• Registros de actividad: Los registros de actividad le muestran todos los cambios que ocurrieron en el
objeto de Azure de su base de datos. Azure registra todas las transacciones creadas, actualizadas y
eliminadas en los recursos de Azure y conserva esos registros durante 90 días. En el caso de MySQL, esto
significa todos los cambios en el tamaño, en la configuración de copia de seguridad y replicación, etc.
Estos registros son útiles para determinar quién realizó cambios en su base de datos.
• Registros del servidor: Los registros del servidor incluyen registros de los datos reales en su base de datos.
MySQL tiene varios registros disponibles que se pueden configurar. Por lo general, se recomienda activar el
registro de auditoría para verificar quién ha accedido a su base de datos y activar la supervisión de consultas
lentas para realizar un seguimiento de las consultas que se ejecutan lentamente.
Echemos un vistazo a ambos registros:
1. Para acceder a los registros de actividad, abra la hoja de la base de datos MySQL en Azure Portal. En la
navegación de la izquierda, busque Registro de actividades. Esto abrirá la vista del registro de actividad, como
en Figura 8.31:
Figura 8.31: Registros de actividad de Azure que muestran las acciones tomadas contra la base de datos de Azure
El registro de actividad proporciona información muy valiosa para rastrear las actividades que se han
realizado. Debe encontrar eventos en el registro de actividades que apunten a los cambios que realizó
anteriormente en la configuración de seguridad de la conexión.
2. Los registros del servidor se pueden obtener buscando Registros del servidor en la navegación de la izquierda.
Los registros del servidor no están activados de forma predeterminada, como se puede ver en Figura 8.32:
Figura 8.32: Navegación que no muestra registros de servidor de forma predeterminada

3. Activemos los registros del servidor. Habilitaremos el registro de auditoría y el monitoreo de

problemas de desempeño habilitando el log_slow ... declaraciones y slow_query_log, como se
Figura 8.33: Habilitación del registro de auditoría y registro lento de consultas
Una vez que haya activado estos registros, los registros reales tardarán un par de minutos en aparecer.
Después de un par de minutos, debería ver los registros en el Registros del servidor pestaña en el portal de
Azure como se muestra en Figura 8.34:
Figura 8.34: Visualización de los registros del servidor en Azure Portal

Asegurémonos de limpiar nuevamente después de nuestra implementación y escalar nuestro clúster

nuevamente a dos nodos. Si se reduce a dos nodos, se asegurará de ahorrar costos en su suscripción de
Azure:
helm eliminar wp -n wordpress

helm eliminar osba -n osba
helm eliminar catálogo -n catálogo
kubectl eliminar ns wordpress osba catalog
az aks scale -n <nombre de clúster> -g <grupo de recursos de clúster> -c 2
En esta sección, cubrimos los dos tipos de registros que genera Azure para una base de datos MySQL.
Examinamos el registro de actividad para ver qué acciones se tomaron contra la base de datos de Azure
y activamos los registros del servidor para obtener información sobre lo que sucedió dentro de la base
de datos.
Resumen
Este capítulo se centró en trabajar con una solución de muestra de WordPress que aprovecha una base de
datos MySQL como almacén de datos. Comenzamos mostrándole cómo configurar el clúster para conectar la
base de datos MySQL mediante la instalación de Open Service Broker para Azure. Luego le mostramos cómo
configurar una base de datos MySQL y minimizar drásticamente la superficie de ataque cambiando la
configuración predeterminada para no permitir el acceso público a la base de datos. Luego, discutimos cómo
restaurar la base de datos desde una copia de seguridad y cómo aprovechar la solución para DR. Finalmente,
discutimos cómo configurar los registros de auditoría para la resolución de problemas.
En el próximo capítulo, aprenderá cómo implementar microservicios en AKS, incluso mediante el uso de
Event Hubs para una integración débilmente acoplada entre aplicaciones.
Conectando a Azure
9
Centros de eventos
La integración basada en eventos es un patrón clave para implementar microservicios. La idea de una
arquitectura de microservicios es descomponer una aplicación monolítica en un conjunto más pequeño de
servicios. Los eventos se utilizan comúnmente para coordinar entre estos diferentes servicios. Cuando
piensas en un evento, puede ser una de muchas cosas. Las transacciones financieras pueden ser un
evento, así como datos de sensores de IoT, clics y vistas de páginas web, y mucho más.
Un software que se usa comúnmente para manejar este tipo de eventos es Apache Kafka (Kafka para
abreviar). Kafka fue desarrollado originalmente por LinkedIn y luego donado a la Apache Software
Foundation. Es una popular plataforma de transmisión de código abierto. Una plataforma de transmisión
es una plataforma que tiene tres capacidades principales: publicar y suscribir una transmisión de mensajes
(similar a una cola), almacenar estas transmisiones de manera duradera y procesar estas transmisiones a
medida que ocurren.
242 | Conexión a Azure Event Hubs
Azure tiene una oferta similar a Apache Kafka, llamada Azure Event Hubs. Centros de eventos es un
servicio administrado que ofrece ingesta de datos en tiempo real. Es fácil de configurar y usar, y puede
escalar dinámicamente. Event Hub también está integrado con otros servicios de Azure, como análisis de
transmisión, funciones y databricks. Estas integraciones predefinidas le facilitan la creación de
aplicaciones que consumen eventos de los centros de eventos.
Los centros de eventos también proporcionan un punto final de Kafka. Esto significa que puede
configurar sus aplicaciones existentes basadas en Kafka y apuntarlas a Event Hubs en su lugar. El
beneficio de usar Event Hubs para sus aplicaciones de Kafka es que ya no tiene que administrar su clúster
de Kafka porque lo consume como un servicio administrado.
En este capítulo, aprenderá cómo implementar microservicios en AKS y usar Event Hubs para
una integración débilmente acoplada entre aplicaciones. Implementará una aplicación que usa
Kafka para enviar eventos y reemplazará su propio clúster de Kafka con Azure Event Hubs.
Como aprenderá en este capítulo, la integración basada en eventos es uno de los
diferenciadores clave entre aplicaciones monolíticas y basadas en microservicios.
• Implementar un conjunto de microservicios
• Uso de Azure Event Hubs
Comenzaremos este capítulo implementando un conjunto de microservicios que construyen una red
social.
Implementar un conjunto de microservicios
En esta sección, implementaremos un conjunto de microservicios desde una aplicación de

demostración llamada red social. La aplicación se compone de dos microservicios principales: usuarios
y amigos. El servicio de usuarios almacena a todos los usuarios en su propio almacén de datos. Un usuario
está representado por un ID y su nombre y apellido. El servicio de amigos almacena los amigos del usuario.
Una relación de amistad vincula las ID de usuario de ambos amigos y también tiene su propia ID.
Los eventos de agregar un usuario / agregar un amigo se envían a una cola de mensajes. Esta aplicación
utiliza Kafka como cola de mensajes para almacenar eventos relacionados con usuarios, amigos y
recomendaciones.
Esta cola es consumida por un servicio de recomendación. Este servicio está respaldado por un
Neo4j base de datos que luego se puede utilizar para consultar las relaciones entre los usuarios. Neo4j es una
popular plataforma de base de datos de gráficos. Una base de datos de gráficos es diferente de una base de
datos relacional típica como MySQL. Una base de datos de gráficos es una base de datos que se centra en
almacenar la relación entre diferentes elementos. Puede consultar una base de datos de gráficos con
preguntas, como dame los amigos comunes del usuario X y del usuario Y.
Implementación de un conjunto de microservicios | 243
En términos de flujo de datos, puede crear usuarios y relaciones de amistad. La creación de un usuario o
una relación de amistad generará un mensaje en la cola de mensajes, lo que dará como resultado que los
datos se completen en la base de datos de Neo4j. La aplicación no tiene interfaz web. Trabajará
principalmente con la aplicación utilizando la línea de comando, aunque podemos conectarnos a la base
de datos de Neo4j para verificar que los datos se hayan completado en la base de datos.
En la siguiente sección, aprenderá a hacer lo siguiente:
• Utilice Helm para implementar una aplicación de muestra basada en microservicios.
• Pruebe el servicio enviando eventos y observe cómo se crean y actualizan los objetos.
Comencemos por implementar la aplicación.
Implementar la aplicación con Helm

En esta sección, implementaremos la aplicación de demostración usando Helm. Esto implementará la
aplicación completa usando una instancia local de Kafka. Una vez desplegada la aplicación,
generaremos una pequeña red social y verificaremos que fuimos capaces de crear la red social.
1. Este ejemplo tiene muchos requisitos de recursos. Para cumplir con ellos, escale su clúster a
cuatro nodos:
az aks nodepool scale --node-count 4 -g rg-handsonaks \

2. El código de este ejemplo se ha incluido en el repositorio de GitHub para este libro. Puede
encontrar el código en el red social carpeta debajo Capítulo 09. Navega a esta carpeta:
cd Chapter09 / red social
3. Para ejecutar Kafka, también necesitamos ejecutar ZooKeeper. ZooKeeper es otro proyecto de
software de código abierto de la fundación Apache. Proporciona nombres, gestión de la
configuración, sincronización y la capacidad de agrupar servicios. Usaremos los gráficos de Kafka
y ZooKeeper Helm de bitnami, así que agreguemos el repositorio de Helm requerido:
helm repo agregar bitnami https://charts.bitnami.com

helm repo agregar incubadora https://kubernetes-charts-incubator.storage.
googleapis.com
Figura 9.1: Agregar los repositorios de Helm
4. Actualicemos las dependencias para que los gráficos dependientes estén disponibles:
implementación de actualización de helm dep / helm / red social

implementación de actualización de helm dep / helm / friend-service
implementación de actualización de helm dep / helm / user-service
implementación de actualización de helm dep / helm / servicio de recomendación
Esto le mostrará algo similar a Figura 9.2 cuatro veces:
Figura 9.2: Actualización de dependencias
Nota
Durante este ejemplo, es posible que vea una advertencia similar a la siguiente: walk.go: 74: enlace
simbólico encontrado en la ruta :. Ésta es una advertencia que puede ignorarse con seguridad.
5. A continuación, cree un nuevo espacio de nombres para esta aplicación:
kubectl crear red social de espacio de nombres

Figura 9.3: Creación de un nuevo espacio de nombres
6. Ahora, continúe e implemente la aplicación:
helm install social-network --namespace social-network \

- - establecer fullNameOverride = red-social \
- - establecer edge-service.service.type = LoadBalancer \
despliegue / timón / red social
7. Verifique el estado de los pods en la implementación con el siguiente comando:
kubectl get pods -w -n red social
Como puedes ver en Figura 9.4, Tarda unos 5 minutos hasta que todos los Pods estén en
funcionamiento:
Figura 9.4: Salida que muestra todos los Pods con un estado En ejecución
8. Cuando la aplicación se haya implementado correctamente, puede conectarse al servicio

perimetral. Para obtener su IP, use el siguiente comando:
kubectl get service -n social-network
Este comando generará una salida de la siguiente manera:
Figura 9.5: Obtención de la IP externa del servicio perimetral
9. Puede hacer dos pruebas para verificar que la aplicación esté funcionando correctamente. La prueba 1 es
conectar el servicio de borde en el puerto 9000 en un navegador. Figura 9.6 muestra la página de error de
etiqueta blanca, que muestra que la aplicación se está ejecutando:
Figura 9.6: La página de error de etiqueta blanca, que muestra que la aplicación se está ejecutando
10. La segunda prueba para verificar que la aplicación se está ejecutando, es generar realmente una
pequeña red social. Esto verificará que todos los servicios estén funcionando correctamente.
Puede crear esta red usando el siguiente comando:
bash ./deployment/sbin/generate-serial.sh <ip-external>: 9000

Este comando generará una gran cantidad de resultados. La salida comenzará con los
elementos que se muestran en Figura 9.7:
Figura 9.7: Resultado inicial al crear una nueva red social
11. Se necesitará aproximadamente un minuto para generar una red de 15 personas. Para verificar
que la red se haya creado correctamente, busque http: // <ip-external>: 9000 / user / v1 / users
/ 1 en su navegador web. Esto debería mostrarle un pequeño objeto JSON que representa a un
usuario en la red social, como se muestra en Figura 9.8:
Figura 9.8: Creación exitosa del usuario en el servicio de usuario
12. Como validación final, puede conectarse a la base de datos de Neo4j y visualizar la red
social que creó. Para poder conectarse a Neo4j, primero debe exponerlo como un servicio.
Utilizar el neo4j-service.yaml archivo en la carpeta de la red social para exponerlo:
kubectl create -f neo4j-service.yaml -n social-network
Luego, obtenga la dirección IP pública del servicio. Esto puede tardar aproximadamente un minuto en estar
disponible:
kubectl obtener servicio neo4j-service -n social-network

El comando anterior generará la salida de la siguiente manera:
Figura 9.9: Salida que muestra la dirección IP externa del servicio Neo4j
Nota
Tenga en cuenta que la IP externa del servicio Neo4j puede diferir de la IP externa del
servicio perimetral.
13. Utilice su navegador para conectarse a http: // <ip-external>: 7474. Esto abrirá un inicio de sesión
pantalla. Utilice la siguiente información para iniciar sesión:
• Conectar URL: perno: // <ip-external>: 7678

• Nombre de usuario: neo4j
• Contraseña: neo4j
La información de su conexión debe ser similar a Figura 9.10 .:
Figura 9.10: Iniciar sesión en el navegador Neo4j

14. Una vez que esté conectado al navegador Neo4j, podrá ver la red social real. Clickea en el Informació
de la base de datos icono, y luego haga clic en Usuario. Esta
generará una consulta que mostrará la red social que acaba de crear. Esto se verá
similar a Figura 9.11:
Figura 9.11: Vista de la red social que acaba de crear
En el ejemplo actual, hemos configurado la aplicación de un extremo a otro, utilizando Kafka ejecutándose
en nuestro clúster de Kubernetes como una cola de mensajes. Eliminemos ese ejemplo antes de pasar a la
siguiente sección. Para eliminar la implementación local, use los siguientes comandos:
helm delete social-network -n social-network

kubectl delete pvc -n social-network --all kubectl
delete pv --all
En la siguiente sección, dejaremos de almacenar eventos en el clúster y los almacenaremos en

Azure Event Hubs. Al aprovechar la compatibilidad nativa de Kafka en Azure Event Hubs y
cambiar a una tienda de eventos más preparada para la producción, veremos que el proceso es
sencillo.
Uso de Azure Event Hubs

Es posible ejecutar Kafka usted mismo en un clúster, pero puede ser difícil de ejecutar para uso de
producción. En esta sección, transferiremos la responsabilidad de mantener un clúster de Kafka a Azure
Event Hubs. Event Hubs es un servicio de ingesta de datos en tiempo real totalmente administrado. Tiene
soporte nativo para el protocolo Kafka, por lo que, con modificaciones menores, podemos actualizar
nuestra aplicación desde una instancia local de Kafka a la instancia escalable de Azure Event Hubs.
En las siguientes secciones, haremos lo siguiente:
• Cree el centro de eventos a través del portal y recopile los detalles necesarios para conectar nuestra
aplicación basada en microservicios.
• Modifique el gráfico de Helm para utilizar el centro de eventos recién creado.

Comencemos por crear el centro de eventos.
Creando el centro de eventos
En esta sección, crearemos el centro de eventos de Azure. Usaremos este centro de eventos más adelante
para transmitir los nuevos mensajes a. Realice los siguientes pasos para crear el centro de eventos:
1. Para crear el centro de eventos en Azure Portal, busque centro de eventos, como se muestra en
Figura 9.12:
Figura 9.12: Buscando Event Hubs en la barra de búsqueda
2. Haga clic en Event Hubs.

Uso de Azure Event Hubs | 251
3. En el Centros de eventos pestaña, haga clic en Agregar, como se muestra en Figura 9.13:
Figura 9.13: Agregar un nuevo centro de eventos
4. Complete los siguientes datos:

• Nombre: Este nombre debe ser único a nivel mundial. Considere agregar sus iniciales al
nombre.
• Nivel de precios: Seleccione el nivel de precios estándar. El nivel de precios básico no es

compatible con Kafka.
• Hace que esta zona de espacio de nombres sea redundante: Desactivado.
• Suscripción de Azure: Seleccione la misma suscripción que la que aloja su

clúster de Kubernetes.
• Grupo de recursos: Seleccione el grupo de recursos que creamos para el clúster,

rg-handsonaks en nuestro caso.
• Ubicación: Seleccione la misma ubicación que su clúster. En nuestro caso, esto es Oeste de EE. UU. 2.
• Unidad de rendimiento: 1 unidad será suficiente para esta prueba.
• Autoinflar: Desactivado.
Esto debería darle una vista de creación similar a Figura 9.14:
Figura 9.14: La creación de su centro de eventos debería verse así

5. Pulsa el Crear en la parte inferior del asistente para crear su centro de eventos.
6. Una vez creado el centro de eventos, selecciónelo, como se muestra en Figura 9.15:
Figura 9.15: Hacer clic en el nombre del centro de eventos una vez creado
7. Haga clic en Políticas de acceso compartido, Seleccione RootManageSharedAccessKey, y copia

la Cadena de conexión-clave primaria, como se muestra en Figura 9.16:
Figura 9.16: Copia de la cadena de conexión primaria

Usando el portal de Azure, hemos creado un centro de eventos que puede almacenar y procesar nuestros
eventos a medida que se generan. Necesitábamos reunir las cadenas de conexión para poder conectar
nuestra aplicación basada en microservicios. En la siguiente sección, volveremos a implementar nuestra
red social y la configuraremos para conectarse a Event Hubs. Para poder desplegar nuestra red social,
tendremos que realizar un par de cambios en los gráficos de Helm, con el fin de apuntar nuestra
aplicación a Event Hubs en lugar de a Kafka.
Modificar los archivos de Helm
Vamos a cambiar la implementación de microservicios de usar la instancia local de Kafka a usar la

instancia de Event Hubs compatible con Kafka alojada en Azure. Para realizar este cambio,
modificaremos los gráficos de Helm para usar Event Hubs en lugar de Kafka:
1. Modifique el values.yaml archivo para el despliegue de la red social para deshabilitar Kafka en
el clúster e incluya los detalles de la conexión a su centro de eventos:
implementación de código / helm / social-network / values.yaml
Asegúrese de cambiar los siguientes valores:
Líneas 5, 18, 26 y 34: Cambia esto a habilitado: falso.
Líneas 20, 28 y 36: Cambie esto por el nombre de su centro de eventos.
Líneas 21, 29 y 37: Cambie esto a la cadena de conexión de su centro de eventos:
1 nameOverride: red social

2 fullNameOverride: red social
3
4 kafka:
5 habilitado: verdadero
6 nameOverride: kafka
7 fullnameOverride: kafka
8 persistencia:
9 habilitado: falso
10 recursos:
11 peticiones:
12 memoria: 325Mi
13
14
15 amigo-servicio:
fullnameOverride: servicio-amigo
dieciséis
17 kafka:
19 eventhub:
20 nombre: <nombre del centro de eventos>
21 conexión: "<cadena de conexión del centro de eventos>"

22
23 servicio de recomendación:
24 fullnameOverride: servicio de recomendación
25 kafka:
27 eventhub:

30
31 servicio-usuario:
32 fullnameOverride: servicio de usuario
33 kafka:
35 eventhub:
Nota
Para nuestra demostración, estamos almacenando la cadena de conexión en un archivo de valores de Helm. Ésta
no es una práctica recomendada. Para un caso de uso de producción, debe almacenar esos valores como un
secreto y hacer referencia a ellos en su implementación. Exploraremos esto en Capítulo 10, Protección de su clúster
de AKS.
2. Ejecute la implementación de la siguiente manera:
helm install social-network deployment / helm / social-network / -n

socialnetwork --set edge-service.service.type = LoadBalancer
3. Espere a que todos los Pods estén activos. Puede verificar que todos los pods estén en funcionamiento con
kubectl get pods -n social-network
Esto generará la siguiente salida:
Figura 9.17: Salida que muestra el estado de ejecución de todos los pods
4. Para verificar que está conectado a Event Hubs, y no a Kafka local, puede consultar los centros
de eventos en el portal y consultar los diferentes temas. Debería ver un tema de amigo y
usuario, como se muestra en Figura 9.18:
Figura 9.18: Mostrando los dos temas creados en su centro de eventos

5. Sigue mirando los Pods. Cuando todos los pods estén en funcionamiento, obtenga la IP
externa del servicio perimetral. Puede obtener esa IP usando el siguiente comando:
kubectl get svc -n social-network
6. Luego, ejecute el siguiente comando para verificar la creación de la red social

real:
bash ./deployment/sbin/generate-serial.sh <ip-external>: 9000
Esto volverá a crear una red social con 15 usuarios, pero ahora usará Event Hubs para enviar
todos los eventos relacionados con usuarios, amigos y recomendaciones.
7. Puede ver esa actividad en Azure Portal. Azure Portal crea gráficos de supervisión detallados para
Event Hubs. Para acceder a ellos, haga clic en el amigo centro de eventos, como se muestra en Figura
9.19:
Figura 9.19: Hacer clic en el tema del amigo para obtener más métricas
En Figura 9.20, Puede ver que hay tres gráficos que Azure Portal le
proporciona de inmediato: el número de solicitudes, el número de mensajes y
el rendimiento total:
Figura 9.20: Visualización de los gráficos de alto nivel por defecto por tema
Puede profundizar más en los gráficos individuales. Por ejemplo, haga clic en el
gráfico de mensajes. Esto lo llevará a un editor de gráficos interactivo en el
monitor de Azure. Puede ver minuto a minuto cuántos mensajes entraban y
salían de su centro de eventos, como se muestra en Figura 9.21:
Figura 9.21: Hacer clic en el gráfico para obtener más detalles

Asegurémonos de limpiar la implementación que acabamos de crear y volver a escalar nuestro

clúster:
helm delete social-network -n social-network
kubectl delete pvc -n social-network --all kubectl
delete pv --all
kubectl delete service neo4j-service -n social-network az aks
nodepool scale --node-count 2 -g rg-handsonaks \
También puede eliminar el centro de eventos en Azure Portal. Para eliminar el Event Hub, vaya a la Visión de
conjunto página del centro de eventos y seleccione el Borrar botón, como se muestra en Figura
9.22. Se le pedirá que repita el nombre del centro de eventos para asegurarse de no eliminarlo
accidentalmente:
Figura 9.22: Hacer clic en el botón eliminar para eliminar su centro de eventos
Con esto concluye nuestro ejemplo de uso de Event Hubs con Azure Kubernetes Service. En este
ejemplo, reconfiguramos una aplicación de Kafka para usar Azure Event Hubs en su lugar.
Resumen
En este capítulo, implementamos una aplicación basada en microservicios que se conecta a Kafka.
Usamos Helm para implementar esta aplicación de muestra. Pudimos probar la aplicación enviando
eventos a un clúster de Kafka creado localmente y observando cómo se creaban y actualizaban los
objetos.
Finalmente, cubrimos el almacenamiento de eventos en Azure Event Hubs mediante el soporte de Kafka y
pudimos recopilar los detalles necesarios para conectar nuestra aplicación basada en microservicios y modificar
el gráfico de Helm.
El próximo capítulo cubrirá la seguridad del clúster. Cubriremos la seguridad de RBAC, la

administración de secretos y la seguridad de la red usando Istio.
Asegurar su AKS
10
grupo
Labios flojos hunden barcos es una frase que describe lo fácil que puede ser poner en peligro la
seguridad de un clúster administrado por Kubernetes ( Kubernetes, por cierto, es griego para
timonel, como en el timonel de un Embarcacion). Si su clúster se deja abierto con los puertos o servicios
incorrectos expuestos, o si se usa texto sin formato para secretos en las definiciones de aplicaciones, los
malos actores pueden aprovechar esta seguridad negligente y hacer prácticamente lo que quieran en su
clúster.
En este capítulo, exploraremos la seguridad de Kubernetes con más profundidad. Se le presentará el

concepto de control de acceso basado en roles (RBAC) en Kubernetes. Después de eso, aprenderá
acerca de los secretos y cómo usarlos. Primero creará secretos en Kubernetes y, luego, creará un Key
Vault para almacenar secretos de forma más segura. Terminará este capítulo con una breve
introducción a los conceptos de la malla de servicios y se le dará un ejemplo práctico a seguir.
264 | Asegurar su clúster de AKS
Los siguientes temas se tratarán brevemente en este capítulo:
• Control de acceso basado en roles
• Configurar la gestión de secretos
• Usar secretos almacenados en Key Vault
• La malla de servicios de Istio a su servicio
Nota
Para completar el ejemplo sobre RBAC, necesita acceso a una instancia de Azure AD, con
permisos de administrador global.
Comencemos este capítulo con RBAC.
Control de acceso basado en roles
En los sistemas de producción, debe permitir a diferentes usuarios diferentes niveles de acceso a ciertos
recursos; esto se conoce como control de acceso basado en roles (RBAC). Esta sección lo guiará a través
de cómo configurar RBAC en AKS y cómo asignar diferentes roles con diferentes derechos. Los beneficios
de establecer RBAC son que no solo actúa como una barrera contra la eliminación accidental de recursos
críticos, sino que también es una característica de seguridad importante que limita el acceso completo al
clúster a los roles que realmente lo necesitan. En un clúster habilitado para RBAC, los usuarios podrán
observar que pueden modificar solo aquellos recursos a los que tienen acceso.
Hasta ahora, con Cloud Shell, actuamos como raíz, lo que nos permitió hacer cualquier cosa en el
clúster. Para los casos de uso de producción, el acceso a la raíz es peligroso y debe restringirse
tanto como sea posible. Es una buena práctica generalmente aceptada utilizar el principio de
privilegio mínimo (PoLP) para iniciar sesión en cualquier sistema informático. Esto evita tanto el
acceso a datos seguros como el tiempo de inactividad involuntario mediante la eliminación de
recursos clave. En cualquier lugar entre 22% y 29% ( https: //blog.storagecraft. com /
data-loss-statistics-infographic / ) de la pérdida de datos se atribuye a un error humano. No quieres
ser parte de esa estadística.
Control de acceso basado en roles | 265
Los desarrolladores de Kubernetes se dieron cuenta de que esto era un problema y agregaron RBAC junto con el
concepto de roles de servicio para controlar el acceso a los clústeres. Kubernetes RBAC tiene tres conceptos
importantes:
• Papel: Un rol contiene un conjunto de permisos. Un rol tiene un valor predeterminado de no permisos,
y todos los permisos deben solicitarse específicamente. Ejemplos de permisos incluyen conseguir,
mirar, y lista. El rol también contiene los recursos a los que se otorgan estos permisos. Los
recursos pueden ser todos los pods, implementaciones, etc., o pueden ser un objeto
específico (como vaina / mypod).
• Tema: El sujeto es una persona o una cuenta de servicio a la que se le asigna un rol. En AKS,
estos sujetos pueden ser usuarios o grupos de Azure AD.
• Vinculación de roles: Un RoleBinding vincula un sujeto con un rol en un determinado espacio de

nombres o, en el caso de un ClusterRoleBinding, todo el clúster.
Una noción importante que hay que comprender es que, al interactuar con AKS, hay dos capas de
RBAC: Azure RBAC y Kubernetes RBAC. Azure RBAC se ocupa de los roles asignados a las personas
para realizar cambios en Azure, como crear, modificar y eliminar clústeres. Kubernetes RBAC se
ocupa de los derechos de acceso a los recursos de un clúster. Ambos son planos de control
independientes, pero pueden usar los mismos usuarios y grupos que se originan en Azure AD.
Figura 10.1: Dos planos RBAC diferentes, Azure y Kubernetes

RBAC en Kubernetes es una función opcional. El valor predeterminado en AKS es crear clústeres que tengan
habilitado RBAC. Sin embargo, de forma predeterminada, el clúster no está integrado con Azure AD. Esto
significa que, de forma predeterminada, no puede otorgar permisos de Kubernetes a los usuarios de Azure AD.
En este ejemplo, crearemos un nuevo clúster integrado con Azure AD. Comencemos nuestra exploración de
RBAC creando un nuevo usuario y un nuevo grupo en Azure AD.
Creación de un nuevo clúster con integración de Azure AD
En esta sección, crearemos un nuevo clúster que se integra con Azure AD. Esto es necesario para que
podamos hacer referencia a los usuarios en Azure AD en los siguientes pasos. Todos estos pasos se
ejecutarán en Cloud Shell. También hemos proporcionado los pasos en un archivo llamado cluster-aad.
sh. Si prefiere ejecutar el script, cambie las variables en las primeras cuatro líneas para reflejar sus
preferencias. Sigamos adelante y realicemos los pasos:
1. Comenzaremos reduciendo nuestro clúster actual a un nodo:
az aks nodepool scale - handsonaks de nombre de clúster \

- g rg-handsonaks --nombre agentpool - recuento de nodos 1
2. Luego, estableceremos algunas variables que usaremos en el script:

EXISTINGAKSNAME = "handsonaks"
NEWAKSNAME = "handsonaks-aad"
RGNAME = "rg-handsonaks"
UBICACIÓN = "westus2"
TENANTID = $ (az account show --query tenantId -o tsv)
3. Ahora obtendremos la entidad de servicio existente de nuestro clúster de AKS. Reutilizaremos esta
entidad de servicio para otorgar permisos al nuevo clúster para acceder a nuestra suscripción de
Azure:
# Obtenga SP del clúster existente y cree una nueva contraseña

RBACSP = $ (azaks show -n $ EXISTINGAKSNAME -g $ RGNAME \
-RBACSPPASSWD
- consulta servicePrincipalProfile.clientId
= $ (openssl rand -base64-o32)
tsv)
az ad sp credential reset --name $ RBACSP \

- - contraseña $ RBACSPPASSWD --append
4. A continuación, crearemos una nueva aplicación de Azure AD. Esta aplicación de Azure AD se usará para
obtener las membresías de grupo de Azure AD de un usuario:
serverApplicationId = $ (az ad app create \

- - nombre para mostrar "$ {NEWAKSNAME} Servidor" \
- - identificador-uris "https: // $ {NEWAKSNAME} Servidor" \
- - consulta appId -o tsv)
5. En el siguiente paso, actualizaremos la aplicación, crearemos una entidad de servicio y obtendremos

el secreto de la entidad de servicio:
az ad app update --id $ serverApplicationId --set groupMembershipClaims = Todos
az ad sp create --id $ serverApplicationId
serverApplicationSecret = $ (az ad sp credential reset \

- - nombre $ serverApplicationId \
- - descripción-credencial "AKSPassword" \
- - contraseña de consulta -o tsv)
6. Luego, le daremos permiso a esta entidad de servicio para acceder a los datos del directorio en Azure
AD:
permiso de la aplicación de anuncios az add \
- - id $ serverApplicationId \
- - api 00000003-0000-0000-c000-000000000000 \
- 06da0dbc-49e2-44d2-8312-53f166ab848a
- api-permissions e1fe6dd8-ba31-4d61-89e7-88639da4683d
= Alcance \ = Alcance \
7ab1d382-f21e-4acd-a863-ba3e13f7da61 = Rol
concesión de permiso de aplicación de anuncios az --id $ serverApplicationId \
- - api 00000003-0000-0000-c000-000000000000
7. Aquí hay un paso manual que nos lleva a Azure Portal. Necesitamos otorgar el consentimiento
del administrador a la aplicación. Para lograr esto, busque Azure Active Directory
en la barra de búsqueda de Azure:
Figura 10.2: Buscando Azure Active Directory en la barra de búsqueda
8. Luego, seleccione Registros de aplicaciones en el menú de la izquierda:
Figura 10.3: Selección de registros de aplicaciones

9. En el Registros de aplicaciones hoja, ve a Todas las aplicaciones, buscar

<nombre de clúster> Servidor, y seleccione esa aplicación:
Figura 10.4: Buscando el registro de la aplicación que creamos usando el script anteriormente
10. En la vista de esa aplicación, haga clic en Permisos de API, y haga clic en Administrador de subvenciones
consentimiento para el directorio predeterminado ( este nombre puede depender de su nombre de Azure AD):
Figura 10.5: Otorgar el consentimiento del administrador
En el siguiente mensaje, seleccione sí para otorgar esos permisos.
Nota
Puede tomar alrededor de un minuto Otorgar consentimiento de administrador para activarse. Si
aún no está activo, espere un minuto y vuelva a intentarlo. Necesitará derechos de administrador en Azure
AD para poder otorgar este consentimiento.
11. A continuación, crearemos otra entidad de servicio y también le concederemos permisos.

Esta entidad de servicio tomará la solicitud de autenticación del usuario y verificará sus
credenciales y permisos:
clientApplicationId = $ (az ad app create \

- - nombre para mostrar "$ {NEWAKSNAME} Cliente" \
- - aplicación nativa \
- - URL de respuesta "https: // $ {NEWAKSNAME} Cliente" \
az ad sp create --id $ clientApplicationId

oAuthPermissionId = $ (az ad app show --id $ serverApplicationId \
- - consulta "oauth2Permissions [0] .id" -o tsv)
permiso de aplicación de anuncios az agregar --id $ clientApplicationId \
- - api $ serverApplicationId --api-permissions \
$ oAuthPermissionId = Alcance
concesión de permiso de aplicación de anuncios az --id $ clientApplicationId \
- - api $ serverApplicationId
12. Luego, como paso final, podemos crear el nuevo clúster:
azaks crean \
- - grupo de recursos $ RGNAME \
- - nombre $ NEWAKSNAME \
- - ubicación $ LOCATION
- - recuento de nodos 2 \
- - node-vm-size Standard_D1_v2 \
- - generar-claves-ssh \
- - id-aplicación-servidor-aad $ serverApplicationId \
- - aad-server-app-secret $ serverApplicationSecret \
- - id-aplicación-cliente-aad $ clientApplicationId \
- - aad-tenant-id $ TENANTID \
- - principal de servicio $ RBACSP \
- - secreto de cliente $ RBACSPPASSWD
En esta sección, hemos creado un nuevo clúster de AKS que está integrado con Azure AD para
RBAC. Se necesitan entre 5 y 10 minutos para crear un nuevo clúster. Mientras se crea el nuevo
clúster, puede continuar con la siguiente sección y crear un nuevo usuario y grupo en Azure AD.
Crear usuarios y grupos en Azure AD

En esta sección, crearemos un nuevo usuario y un nuevo grupo en Azure AD. Los usaremos
más adelante en el capítulo para asignarles permisos a nuestro clúster de AKS.
Nota
Necesita el rol de administrador de usuarios en Azure AD para poder crear usuarios y
grupos.
1. Para empezar, busque directorio activo azul en la barra de búsqueda de Azure:
Figura 10.6: Buscando Azure Active Directory en la barra de búsqueda
2. Haga clic en Usuarios en el lado izquierdo. Luego seleccione Nuevo Usuario para crear un nuevo usuario:
Figura 10.7: Hacer clic en Nuevo usuario para crear un nuevo usuario
3. Proporcione la información sobre el usuario, incluido el nombre de usuario. Asegúrese de

anotar la contraseña, ya que será necesaria para iniciar sesión:
Figura 10.8: Proporcionar los detalles del usuario (asegúrese de anotar la contraseña)
4. Una vez creado el usuario, vuelva a la hoja de Azure AD y seleccione Grupos. Luego
haga clic en el Nuevo grupo botón para crear un nuevo grupo:
Figura 10.9: Hacer clic en Nuevo grupo para crear un nuevo grupo
5. Cree un nuevo grupo de seguridad. Llamar al grupo administradores de kubernetes, y añadir Tim como un
miembro del grupo. Entonces golpea el Crear botón en la parte inferior:
Figura 10.10: Agregar el tipo de grupo, el nombre del grupo y la descripción del grupo
6. Ahora hemos creado un nuevo usuario y un nuevo grupo. Como paso final, convertiremos a ese usuario
en propietario de un clúster en AKS para que pueda usar la CLI de Azure para obtener acceso al clúster.
Para hacer eso, busque su clúster en la barra de búsqueda de Azure:
Figura 10.11: Buscando su clúster en la barra de búsqueda de Azure

7. En la hoja del clúster, haga clic en Control de acceso (IAM) y luego haga clic en el Agregar
para agregar una nueva asignación de funciones. Selecciona el Rol de usuario del clúster de
servicios de Azure Kubernetes y asígnelo al nuevo usuario que acaba de crear:
Figura 10.12: Asignación de la función de usuario del clúster al nuevo usuario que creó
8. Como también usaremos Cloud Shell para nuestro nuevo usuario, les daremos acceso de colaborador a la cuenta
de almacenamiento de Cloud Shell. Primero, busque almacenamiento en la barra de búsqueda de Azure:
Figura 10.13: Buscando cuentas de almacenamiento en la barra de búsqueda de Azure
9. Seleccione el grupo de recursos en el que Cloud Shell creó esta cuenta de almacenamiento:
Figura 10.14: Selección del grupo de recursos

10. Ir a Control de acceso (IAM) y haga clic en el Agregar botón. Dar el Cuenta de almacenamiento
Contribuyente rol para su usuario recién creado:
Figura 10.15: Otorgar acceso al colaborador de la cuenta de almacenamiento del usuario recién creado
Esto ha concluido la creación de un nuevo usuario y grupo y le ha dado acceso a ese usuario a AKS.
En la siguiente sección, configuraremos RBAC para ese usuario y grupo.
Configuración de RBAC en AKS
Para demostrar RBAC en AKS, crearemos dos espacios de nombres e implementaremos la aplicación Azure Vote
en cada espacio de nombres. Le daremos a nuestro grupo acceso de solo lectura en todo el clúster a los pods, y
le daremos al usuario la capacidad de eliminar los pods en un solo espacio de nombres. Prácticamente,
necesitaremos crear los siguientes objetos en Kubernetes:
• ClusterRole para dar acceso de solo lectura
• ClusterRoleBinding para otorgarle a nuestro grupo el acceso a este rol
• Papel para dar permisos de borrado en el eliminar acceso espacio de nombres
• RoleBinding para otorgar a nuestro usuario acceso a este rol
Figura 10.16: El grupo obtiene acceso de solo lectura a todo el clúster y el usuario obtiene la eliminación
permisos para el espacio de nombres de eliminación de acceso
Configuremos los diferentes roles en nuestro clúster:
1. Para comenzar nuestro ejemplo, necesitaremos recuperar el ID del grupo. Los siguientes
comandos recuperarán la identificación del grupo:
az grupo de anuncios show -g 'kubernetes-admins' --query objectId -o tsv
Esto mostrará su ID de grupo. Anote esto porque lo necesitaremos en los siguientes

pasos:
Figura 10.17: Obtención del ID de grupo
2. A medida que creamos un nuevo clúster para este ejemplo, obtendremos las credenciales para iniciar sesión en este
clúster. Usaremos las credenciales de administrador para realizar la configuración inicial:
az aks get-credentials -n handsonaksad -g rg-handsonaks --admin
3. En Kubernetes, crearemos dos espacios de nombres para este ejemplo:
kubectl crea ns sin acceso kubectl

crea ns elimina acceso
4. Implementaremos el voto azul aplicación en ambos espacios de nombres:
kubectl create -f azure-vote.yaml -n sin acceso kubectl

create -f azure-vote.yaml -n delete-access
5. A continuación, crearemos el ClusterRole expediente. Esto se proporciona en el clusterRole.yaml

expediente:
1 apiVersion: rbac.authorization.k8s.io/v1
2 tipo: ClusterRole
3 metadatos:
4 nombre: readOnly
5 normas:
6 - apiGroups: [""]
7 recursos: ["pods"]
8 verbos: ["get", "watch", "list"]
Echemos un vistazo más de cerca a este archivo:
Línea 2: Define la creación de un ClusterRole
Línea 4: Le da un nombre a nuestro ClusterRole
Línea 6: Da acceso a todos los grupos de API
Línea 7: Da acceso a todos los pods

Línea 8: Da acceso a las acciones - conseguir, mirar, y lista
Crearemos esto ClusterRole usando el siguiente comando:
kubectl create -f clusterRole.yaml
6. El siguiente paso es crear un ClusterRoleBinding. El enlace vincula el rol a un usuario. Esto

se proporciona en el clusterRoleBinding.yaml expediente:
2 tipo: ClusterRoleBinding
3 metadatos:
4 nombre: readOnlyBinding
5 roleRef:
6 tipo: ClusterRole
7 nombre: readOnly
8 apiGroup: rbac.authorization.k8s.io
9 asignaturas:
10 - tipo: Grupo 11
apiGroup: rbac.authorization.k8s.io
12 nombre: "<group-id>"
Línea 2: Define que estamos creando un ClusterRoleBinding
Línea 4: Le da un nombre a nuestro ClusterRoleBinding
Líneas 5-8: Referirse a ClusterRole que creamos en el paso anterior
Líneas 9-12: Consulte nuestro grupo en Azure AD Podemos crear este ClusterRoleBinding
usando el siguiente comando:
kubectl create -f clusterRoleBinding.yaml
7. A continuación, crearemos el Papel que se limita a la eliminar acceso espacio de nombres. Esto se
proporciona en el role.yaml expediente:
2 tipo: Rol
3 metadatos:
4 nombre: deleteRole
5 espacio de nombres: eliminar acceso
6 normas:
7 - apiGroups: [""]
8 recursos: ["pods"]
9 verbos: ["eliminar"]
Este archivo es similar al ClusterRole archivo de antes. Hay dos diferencias

significativas:
Línea 2: Define que estamos creando un Papel, y no un ClusterRole
Línea 5: Define en qué espacio de nombres esta Papel se crea
Podemos crear esto Papel usando el siguiente comando:
kubectl create -f role.yaml
8. Finalmente, crearemos el RoleBinding que vincula a nuestro usuario con el rol de espacio de nombres.
Esto se proporciona en el roleBinding.yaml expediente:
2 tipo: RoleBinding
3 metadatos:
4 nombre: deleteBinding
5 espacio de nombres: eliminar acceso
6 roleRef:
7 tipo: Rol
8 nombre: deleteRole
10 materias:
11 - tipo: Usuario
13 nombre: "<dirección de correo electrónico del usuario>"
Este archivo es similar al archivo ClusterRoleBinding anterior. Hay un par de

diferencias significativas:
Línea 2: Define la creación de un RoleBinding y no un ClusterRoleBinding
Línea 5: Define en qué espacio de nombres esta RoleBinding es creado
Línea 7: Se refiere a un regular Papel y nota un ClusterRole
Líneas 11-13: Definir nuestro usuario en lugar de un grupo Podemos crear
esto RoleBinding usando el siguiente comando:
kubectl create -f roleBinding.yaml
Esto ha concluido los requisitos para RBAC. Creamos dos roles y configuramos dos
RoleBindings. En la siguiente sección, exploraremos el impacto de RBAC iniciando sesión en el
clúster como nuestro usuario.
Verificación de RBAC
Para verificar que RBAC funciona como se esperaba, iniciaremos sesión en Azure Portal con el usuario
recién creado. Ir https://portal.azure.com en un nuevo navegador o en una ventana de InPrivate e inicie
sesión con el usuario recién creado. Se le pedirá inmediatamente que cambie su contraseña. Esta es
una característica de seguridad en Azure AD para garantizar que solo ese usuario conozca su
contraseña:
Figura 10.18: Se le pedirá que cambie su contraseña

Una vez que hayamos cambiado su contraseña, podemos comenzar a probar los diferentes roles de RBAC:
1. Comenzaremos nuestro experimento configurando Cloud Shell para el nuevo usuario. Inicie Cloud
Shell y seleccione Bash:
Figura 10.19: Seleccionar Bash como Cloud Shell
2. En la siguiente vista, seleccione Mostrar configuración avanzada:
Figura 10.20: Seleccionar Mostrar configuración avanzada

3. Luego, dirija Cloud Shell a la cuenta de almacenamiento existente y cree un nuevo recurso compartido de archivos:
Figura 10.21: apunte a la cuenta de almacenamiento existente y cree un nuevo recurso compartido de archivos
4. Una vez que Cloud Shell esté disponible, obtengamos las credenciales para conectarnos a nuestro clúster de
AKS:
az aks get-credentials -n handsonaksaad -g rg-handsonaks
5. Luego, probaremos un comando en kubectl. Intentemos obtener los nodos en el clúster:

Dado que este es el primer comando que se ejecuta en un clúster habilitado para RBAC, se le pedirá que
inicie sesión nuevamente. Navegar a https://microsoft.com/devicelogin y proporcione el código que le
mostró Cloud Shell. Asegúrese de iniciar sesión aquí con las credenciales de su nuevo usuario:
Figura 10.22: Copie y pegue el código que Cloud Shell le mostró en el mensaje
Una vez que haya iniciado sesión, debería obtener un Prohibido mensaje de error de kubectl,
informándole que no tiene permiso para ver los nodos en el clúster. Esto se esperaba ya que el
usuario está configurado solo para tener acceso a los pods:
Figura 10.23: El mensaje que le pide que inicie sesión y el mensaje Prohibido
6. Ahora podemos verificar que nuestro usuario tiene acceso para ver Pods en todos los espacios de nombres y que
el usuario tiene los permisos para eliminar Pods en el eliminar acceso espacio de nombres:
kubectl get pods -n sin acceso

kubectl get pods -n delete-access
Esto debería funcionar para ambos espacios de nombres. Esto se debe a la ClusterRole
configurado para el grupo de usuarios:
Figura 10.24: Nuestro usuario tiene acceso para ver los pods en ambos espacios de nombres
7. También verifiquemos el Eliminar permisos:

kubectl eliminar pod --todos -n sin acceso
kubectl eliminar pod --todos -n eliminar-acceso
Como era de esperar, esto se niega en el sin acceso espacio de nombres y permitido en el eliminar- acceso espacio
de nombres, como se puede ver en Figura 10.25:
Figura 10.25: Las eliminaciones se niegan en el espacio de nombres sin acceso y se permiten en el acceso de eliminación
espacio de nombres
Configurar la gestión de secretos | 283
En esta sección, hemos configurado un nuevo clúster integrado con Azure AD y verificado la
configuración correcta de RBAC con las identidades de Azure AD. Limpiemos los recursos que hemos
creado en esta sección, obtengamos las credenciales para nuestro clúster existente y escalemos
nuestro clúster regular a dos nodos:
az aks eliminar -n handsonaksaad -g rg-handsonaks
az aks get-credentials -n handsonaks -g rg-handsonaks az
aks nodepool scale --cluster-name handsonaks \
- g rg-handsonaks --name agentpool --node-count 2
En la siguiente sección, continuaremos por el camino de la seguridad de Kubernetes, esta vez

investigando los secretos de Kubernetes.
Configurar la gestión de secretos

Todas las aplicaciones de producción requieren cierta información secreta para funcionar. Kubernetes tiene
un back-end de Secrets conectable para administrar estos secretos. Kubernetes también proporciona varias
formas de usar los secretos en su implementación. La capacidad de administrar secretos y utilizar
correctamente el back-end de Secrets hará que sus servicios sean resistentes a los ataques.
Hemos utilizado secretos en algunas de nuestras implementaciones en capítulos anteriores. En su mayoría,

pasamos los secretos como una cadena en algún tipo de variable, o Helm se encargó de crear los secretos por
nosotros. En Kubernetes, los secretos son un recurso, al igual que Pods y ReplicaSets. Los secretos siempre
están vinculados a un espacio de nombres específico. Los secretos deben crearse en todos los espacios de
nombres donde desee utilizarlos. En esta sección, aprenderemos a crear, decodificar y usar nuestros propios
secretos. Comenzaremos usando los secretos integrados de Kubernetes y terminaremos aprovechando Azure
Key Vault para almacenar secretos.
Creando tus propios secretos
Kubernetes proporciona tres formas de crear secretos, de la siguiente manera:
• Creando secretos a partir de archivos
• Creación de secretos a partir de definiciones YAML o JSON
• Creando secretos desde la línea de comando
Con cualquiera de los métodos anteriores, puede crear tres tipos de secretos:
• Secretos genéricos: Estos se pueden crear utilizando valores literales.
• Credenciales de registro de Docker: Se utilizan para extraer imágenes de un registro

privado.
• Certificados TLS: Se utilizan para almacenar certificados SSL.

Comenzaremos usando el método de archivo para crear secretos.
Creando secretos a partir de archivos
Digamos que necesita almacenar una URL y un token secreto para acceder a una API.
Para lograr esto, deberá seguir estos pasos:
1. Almacene la URL en apiurl.txt, como sigue:
echo https://my-secret-url-location.topsecret.com \
> secreturl.txt
2. Almacene el token en otro archivo, de la siguiente manera:
echo 'superSecretToken'> secrettoken.txt
3. Deje que Kubernetes cree los secretos a partir de los archivos, de la siguiente manera:
kubectl crea token-url-myapi genérico secreto \

- - desde-archivo =. / secreturl.txt - desde-archivo =. / secrettoken.txt
En este comando, especificamos el tipo de secreto como genérico.
El comando debería devolver el siguiente resultado:
secreto / myapi-url-token creado
4. Podemos verificar si los secretos se crearon de la misma manera que cualquier otro
recurso de Kubernetes usando el obtener mando:
kubectl obtener secretos
Este comando devolverá una salida similar a Figura 10.26:
Figura 10.26: La salida de kubectl get secrets
Aquí, verá el secreto que acabamos de crear y cualquier otro secreto que todavía esté
presente en el defecto espacio de nombres. Nuestro secreto es el Opaco type, lo que
significa que, desde la perspectiva de Kubernetes, se desconoce el esquema de los
contenidos. Es un par clave-valor arbitrario sin restricciones, a diferencia del registro Docker
o los secretos TLS, que tienen un esquema que se verificará con los detalles requeridos.
5. Para obtener más detalles sobre los secretos, también puede ejecutar el describir mando:
kubectl describe secretos / myapi-url-token
Obtendrá una salida similar a Figura 10.27:
Figura 10.27: Resultado de describir el secreto
Como puede ver, ninguno de los comandos anteriores mostró los valores secretos
reales.
6. Para obtener los secretos, ejecute el siguiente comando:
kubectl get -o yaml secrets / myapi-url-token
Obtendrá una salida similar a Figura 10.28:
Figura 10.28: El uso del modificador -o yaml en kubectl get secret nos da el valor codificado del secreto
Los datos se almacenan como pares clave-valor, con el nombre del archivo como clave y el contenido
codificado en base64 del archivo como valor.
7. Los valores anteriores están codificados en base64. La codificación Base64 no es segura. Codifica el
secreto para que un operador no lo pueda leer fácilmente, pero cualquier actor malo puede
decodificar fácilmente un secreto codificado en base64. Para obtener los valores reales, ejecute el
siguiente comando:
echo 'c3VwZXJTZWNyZXRUb2tlbgo =' | base64 -d
Obtendrá el valor que se ingresó originalmente:
Figura 10.29: Los secretos codificados en Base64 se pueden decodificar fácilmente
8. Del mismo modo, para url valor, puede ejecutar el siguiente comando:
echo 'aHR0cHM6Ly9teS1zZWNyZXQtdXJsLWxvY2F0aW9uLnRvcHNlY3JldC5jb20K' |
base64 -d
Obtendrá el ingresado originalmente url valor, como se muestra en Figura 10.30:
Figura 10.30: La URL codificada también se puede decodificar fácilmente
En esta sección, pudimos codificar la URL con un token secreto y recuperar los valores secretos
reales usando archivos. Continuemos y exploremos el segundo método: crear secretos a partir
de definiciones YAML o JSON.
Creando secretos manualmente usando archivos YAML
Crearemos los mismos secretos usando archivos YAML siguiendo estos pasos:
1. Primero, debemos codificar los secretos para base64, como sigue:
echo 'superSecretToken' | base64
Obtendrá el siguiente valor:
c3VwZXJTZWNyZXRUb2tlbgo =
Puede notar que este es el mismo valor que estaba presente cuando obtuvimos el
yaml definición del secreto en el apartado anterior.
2. Del mismo modo, para el url value, podemos obtener el valor codificado en base64, como se muestra en el
siguiente bloque de código:
echo 'https://my-secret-url-location.topsecret.com' | base64

Esto te dará la base64 URL codificada:
aHR0cHM6Ly9teS1zZWNyZXQtdXJsLWxvY2F0aW9uLnRvcHNlY3JldC5jb20K
3. Ahora podemos crear la definición secreta manualmente; luego, guarde el archivo. Este archivo se ha
proporcionado en el paquete de código como myfirstsecret.yaml:
1 apiVersion: v1
2 tipo: Secreto
3 metadatos:
4 nombre: myapiurltoken-yaml
5 tipo: opaco
6 datos:
7 url: aHR0cHM6Ly9teS1zZWNyZXQtdXJsLWxvY2F0aW9uLnRvcHNlY3JldC5jb20K 8
token: c3VwZXJTZWNyZXRUb2tlbgo =
Investiguemos este archivo:
Línea 2: Esto especifica que estamos creando un secreto.
Línea 5: Esto especifica que estamos creando un Opaco secreto, lo que significa que, desde la
perspectiva de Kubernetes, los valores son pares clave-valor sin restricciones.
Líneas 7-8: Estos son los valores codificados en base64 de nuestro secreto.
4. Ahora podemos crear los secretos de la misma manera que cualquier otro recurso de
Kubernetes usando el crear mando:
kubectl create -f myfirstsecret.yaml
5. Podemos verificar si nuestro secreto se creó con éxito usando esto:
Esto nos mostrará una salida similar a Figura 10.31:
Figura 10.31: Nuestro secreto se creó con éxito a partir de un archivo YAML
6. Puede verificar que los secretos sean los mismos usando kubectl get -o yaml
secretos / myapiurltoken-yaml de la misma forma que describimos en el apartado
anterior.
Creando secretos genéricos usando literales
El tercer método para crear secretos es mediante el uso de literal método, lo que significa que
pasa el valor en la línea de comando. Para hacer esto, ejecute el siguiente comando:
kubectl crea secreto genérico myapiurltoken-literal \
- - de-literal = token = 'superSecretToken' \
- - from-literal = url = https: //my-secret-url-location.topsecret.com
Podemos verificar que el secreto fue creado ejecutando el siguiente comando:

Esto nos dará una salida similar a Figura 10.32:
Figura 10.32: Nuestro secreto se creó con éxito desde la CLI
Por lo tanto, hemos creado secretos utilizando valores literales además de los dos métodos
anteriores.
Crear la clave de registro de Docker
La conexión a un registro Docker privado es una necesidad en los entornos de producción. Dado que
este caso de uso es tan común, Kubernetes ha proporcionado mecanismos para crear una conexión:
kubectl crea registro de Docker secreto <nombre-secreto> \

- - docker-server = <su-servidor-de-registro> \
- - docker-username = <tu-nombre> \
- - docker-password = <tu-pword> --docker-email = <your-email>
El primer parámetro es el tipo secreto, que es Docker-registro. Entonces, le das un nombre al

secreto; por ejemplo, regcred. Los otros parámetros son el servidor Docker ( https://index.docker.io/v1/
para Docker Hub), su nombre de usuario, su contraseña y su correo electrónico.
Puede recuperar el secreto de la misma manera que otros secretos utilizando kubectl para acceder a secretos.
En Azure, Registro de contenedores de Azure (ACR) se utiliza con más frecuencia para almacenar
imágenes de contenedores. Hay dos formas en las que el clúster puede conectarse a ACR. La primera
forma es usar un secreto en el clúster como acabamos de describir. La segunda forma, que es la
recomendada, es utilizar una entidad de servicio. Cubriremos la integración de AKS y ACR en Capítulo
11, Funciones sin servidor.
El último tipo de secreto en Kubernetes es el secreto TLS.
Creando el secreto de TLS
Un secreto TLS se utiliza para almacenar certificados TLS. Para crear un secreto TLS que se pueda usar en
las definiciones de Ingress, usamos el siguiente comando:
kubectl crea tls secreto <nombre-secreto> --key <ssl.key> --cert <ssl.crt>
El primer parámetro es tls para establecer el tipo de secreto, y luego el clave valor y el valor real del
certificado. Por lo general, estos archivos se obtienen de su registrador de certificados.
Nota
Creamos secretos TLS en Capítulo 6, Gestión de su AKS, cluster, donde usamos
cert-manager para crear los secretos en nuestro nombre.
Si desea generar su propio secreto, puede ejecutar el siguiente comando para

generar un certificado SSL autofirmado:
openssl req -x509 -nodes -days 365 -newkey rsa: 2048 - keyout / tmp / ssl. key
-out /tmp/ssl.crt -subj "/CN=foo.bar.com"
En esta sección, cubrimos los diferentes tipos de secretos en Kubernetes y vimos cómo se
pueden crear secretos. En la siguiente sección, usaremos los secretos en nuestra aplicación.
Usando tus secretos
Una vez que se han creado los secretos, es necesario vincularlos a la aplicación. Esto significa que
Kubernetes necesita pasar el valor del secreto al contenedor en ejecución de alguna manera.
Kubernetes ofrece dos formas de vincular sus secretos a su aplicación:
• Usar secretos como variables de entorno
• Montaje de secretos como archivos
Montar secretos como archivos es la mejor manera de consumir secretos en su aplicación. En esta
sección, explicaremos ambos métodos y también mostraremos por qué es mejor usar el segundo
método.
Secretos como variables de entorno
Se hace referencia a los secretos en la definición de Pod bajo el contenedores y env secciones.
Usaremos los secretos que definimos previamente en un Pod y aprenderemos a usarlos en una
aplicación:
1. Podemos configurar un Pod con secretos de variables de entorno como la definición

proporcionada en pod-con-env-secrets.yaml:
1 apiVersion: v1
2 tipo: Pod
3 metadatos:
4 nombre: secreto-usando-env
5 Especificaciones:
6 contenedores:
7 - nombre: nginx
8 imagen: nginx
9 env:
10 - nombre: SECRET_URL
11 valueFrom:
12 secretKeyRef:
13 nombre: myapi-url-token
14 clave: secreturl.txt
15 - nombre: SECRET_TOKEN
dieciséis valueFrom:
17 secretKeyRef:
18 nombre: myapi-url-token
19 clave: secrettoken.txt
20 reiniciarPolítica: Nunca
Inspeccionemos este archivo:
Línea 9: Aquí, estamos configurando las variables de entorno.
Líneas 11-14: Aquí, nos referimos a la secreturl.txt archivo en el myapi-url-token secreto.
Líneas 16-19: Aquí, nos referimos a la secrettoken.txt archivo en el myapi-url-token

secreto.
2. Ahora creemos el Pod y veamos si realmente funcionó:
kubectl create -f pod-with-env-secrets.yaml
3. Compruebe si las variables de entorno están configuradas correctamente:
kubectl exec -it secreto-usando-env sh

echo $ SECRET_URL
echo $ SECRET_TOKEN
Esto debería mostrarle un resultado similar a Figura 10.33:
Figura 10.33: Podemos obtener los secretos dentro del Pod
Cualquier aplicación puede utilizar los valores secretos haciendo referencia a los env variables.
Tenga en cuenta que tanto la aplicación como la definición de Pod no tienen secretos codificados.
Secretos como archivos
Echemos un vistazo a cómo montar los mismos secretos como archivos. Usaremos el siguiente Pod
definición para demostrar cómo se puede hacer esto. Se proporciona en el pod-with-env-

secrets.yaml expediente:
1 apiVersion: v1
2 tipo: Pod
3 metadatos:
4 nombre: volumen-usando-secreto
5 Especificaciones:
6 contenedores:
7 - nombre: nginx
8 imagen: nginx
9 volumeMounts:
10 - nombre: volumen secreto
11 mountPath: "/ etc / secrets"

12 readOnly: verdadero
13 volúmenes:
14 - nombre: volumen secreto
15 secreto:
dieciséis nombresecreto: myapi-url-token
• Líneas 9-12: Aquí, proporcionamos los detalles del montaje. Montamos en el / etc / secretos
directorio como de solo lectura.
• Líneas 13-16: Aquí nos referimos al secreto. Tenga en cuenta que ambos valores del secreto
se montarán en el contenedor.
Tenga en cuenta que esto es más sucinto que el env definición, ya que no es necesario definir un nombre
para todos y cada uno de los secretos. Sin embargo, las aplicaciones deben tener un código especial para
leer el contenido del archivo para poder cargarlo correctamente.
Veamos si los secretos lo lograron:
1. Cree el pod con el siguiente comando:
kubectl create -f pod-with-vol-secret.yaml
2. Haga eco del contenido de los archivos en el volumen montado:
kubectl exec -it secret-using-volume bash cd /

etc / secrets /
gato secreturl.txt
gato /etc/secrets/secrettoken.txt
Como puedes ver en Figura 10.34, nuestros secretos están presentes en nuestro Pod:
Figura 10.34: Los secretos están disponibles como archivos en nuestro Pod
Ahora hemos discutido dos formas en las que los secretos se pueden pasar a un contenedor en
ejecución. En la siguiente sección, explicaremos por qué es una buena práctica utilizar el método de
archivo.
¿Por qué los secretos como archivos son el mejor método?
Aunque es una práctica común utilizar secretos como variables de entorno, es más seguro montar secretos
como archivos. Kubernetes trata los secretos como variables de entorno de forma segura, pero el tiempo de
ejecución de Docker no los trata de forma segura. Para verificar esto, puede ejecutar los siguientes comandos
para ver el secreto en texto sin formato en el tiempo de ejecución de Docker:
1. Comience por obtener la instancia en la que se ejecuta el pod secreto con el siguiente
comando:
kubectl describe pod secret-using-env | nodo grep
Esto debería mostrarle el ID de la instancia, como se ve en Figura 10.35:
Figura 10.35: Obtener el ID de la instancia
2. A continuación, obtenga el ID de Docker del pod en ejecución:
kubectl describe pod secret-using-env | grep 'docker: //'
Esto debería darle la ID de Docker:
Figura 10.36: Obtenga el ID de Docker

3. Finalmente, ejecutaremos un comando en el nodo que ejecuta nuestro contenedor para mostrar el
secreto que hemos pasado como variable de entorno:
INSTANCE = <proporcione el número de instancia>

DOCKERID = <proporcionar ID de Docker>
VMSS = $ (az vmss list --query '[] .name' -o tsv) RGNAME = $ (az
vmss list --query '[] .resourceGroup' -o tsv)
az vmss ejecutar-comando invoke -g $ RGNAME -n $ VMSS
--command-id \ RunShellScript --instance-id $ INSTANCE --scripts \
"docker inspect -f '{{.Config.Env}}' $ DOCKERID" \
- o yaml | grep SECRETO
Esto le mostrará ambos secretos en texto sin formato:
Figura 10.37: Los secretos se decodifican en el tiempo de ejecución de Docker
Como puede ver, los secretos se decodifican en el tiempo de ejecución de Docker. Esto significa que cualquier
operador con acceso a la máquina tendrá acceso a los secretos. Esto también significa que la mayoría de los
sistemas de registro registrarán secretos confidenciales.
Nota
RBAC también es muy importante para controlar secretos. Una persona que tiene acceso al clúster y
tiene el rol correcto tiene acceso a los secretos que se almacenan. Como los secretos solo están
codificados en base64, cualquier persona con permisos RBAC sobre los secretos puede decodificarlos.
Se recomienda tratar el acceso a los secretos con cuidado y tener mucho cuidado al dar acceso a las
personas para usar el ejecutivo de kubectl comando para llevar un shell a los contenedores.
Uso de secretos almacenados en Key Vault | 295
Asegurémonos de limpiar los recursos que creamos en este ejemplo:

kubectl delete pod --todos
kubectl eliminar secreto myapi-url-token \
myapiurltoken-literal myapiurltoken-yaml
Ahora que hemos explorado los secretos en Kubernetes utilizando el mecanismo de secretos predeterminado,
sigamos adelante y usemos una opción más segura, a saber, Key Vault.
Usar secretos almacenados en Key Vault
En la sección anterior, exploramos secretos que se almacenaron de forma nativa en Kubernetes. Esto
significa que se almacenaron codificados en base64 en el servidor API de Kubernetes (en segundo
plano, se almacenarán en una base de datos etcd, pero eso es parte del servicio administrado
proporcionado por Microsoft). Vimos en la sección anterior que los secretos codificados en base64 no
son seguros en absoluto. Para entornos altamente seguros, querrá usar una mejor tienda secreta.
Azure ofrece una solución de almacenamiento de secretos compatible con la industria denominada Azure
Key Vault. Es un servicio administrado que facilita la creación, el almacenamiento y la recuperación de
secretos y ofrece una buena supervisión del acceso a sus secretos. Microsoft mantiene un proyecto de
código abierto que le permite montar secretos en Key Vault en su aplicación. Esta solución se llama Key
Vault FlexVolume y está disponible aquí: https://github.com/Azure/kuberneteskeyvault-flexvol .
En esta sección, crearemos un Key Vault e instalaremos Key Vault FlexVolume para montar un secreto
almacenado en Key Vault en un Pod.
Creación de un Key Vault
Usaremos el portal de Azure para crear un Key Vault:
1. Para iniciar el proceso de creación, busque bóveda de llaves en la barra de búsqueda de Azure:
Figura 10.38: Buscando el almacén de claves en la barra de búsqueda de Azure

2. Haga clic en el Agregar botón para iniciar el proceso de creación:
Figura 10.39: Haga clic en el botón Agregar para comenzar a crear un Key Vault
3. Proporcione los detalles para crear el Key Vault. El nombre de Key Vault debe ser único a
nivel mundial, así que considere agregar sus iniciales al nombre. Se recomienda crear Key
Vault en la misma región que su clúster:
Figura 10.40: Proporcionar los detalles para crear Key Vault

4. Una vez que haya proporcionado los detalles, presione el Revisar + crear botón para revisar y
crea tu Key Vault. Golpea el Crear para finalizar el proceso de creación.
5. Le llevará un par de segundos crear su Key Vault. Una vez que se crea la bóveda, ábrala,
vaya a secretos y presione el Generar / Importar botón para crear un nuevo secreto:
Figura 10.41: Creando un nuevo secreto

6. En el asistente de creación de secretos, proporcione los detalles sobre su secreto. Para que
esta demostración sea más fácil de seguir, se recomienda utilizar el nombre k8s-secret-
demo. Golpea el Crear en la parte inferior de la pantalla para crear el secreto:
Figura 10.42: Proporcionar los detalles de su nuevo secreto
Ahora que tenemos un secreto en Key Vault, podemos seguir adelante y configurar Key Vault
FlexVolume para acceder a este secreto en Kubernetes.
Configuración de Key Vault FlexVolume
En esta sección, configuraremos Key Vault FlexVolume en nuestro clúster. Esto nos permitirá
recuperar secretos de Key Vault:
1. Cree Key Vault FlexVolume con el siguiente comando. El kv-flexvol-

installer.yaml El archivo se ha proporcionado en el código fuente de este capítulo:
kubectl create -f kv-flexvol-installer.yaml
Nota
Hemos proporcionado el kv-flexvol-installer.yaml archivo para garantizar la coherencia con
los ejemplos de este libro. Para casos de uso de producción, recomendamos instalar la última
versión, disponible en https://github.com/Azure/kubernetes-keyvault-flexvol .
2. FlexVolume requiere credenciales para conectarse a Key Vault. En este paso, crearemos
una nueva entidad de servicio:
APPID = $ (az ad app create \

- - nombre para mostrar "flex" \
- - identificador-uris "https: // flex" \
az ad sp create --id $ APPID
APPPASSWD = $ (az ad sp credential reset \

- - nombre $ APPID \
- - descripción-credencial "KeyVault" \
- - contraseña de consulta -o tsv)
3. Ahora crearemos dos secretos en Kubernetes para almacenar la conexión de la entidad de

servicio:
kubectl crea kvcreds genéricos secretos \

- - de-literal = clientid = $ APPID \
- - de-literal = clientsecret = $ APPPASSWD --type = azure / kv
4. Ahora le daremos a este principal de servicio acceso a los secretos de nuestro Key Vault:
KVNAME = handsonaks-kv
az keyvault set-policy -n $ KVNAME --key-permissions \ get
--spn $ APPID
az keyvault set-policy -n $ KVNAME --secret-permissions \ get
--spn $ APPID
az keyvault set-policy -n $ KVNAME --certificate-permissions \ get
--spn $ APPID
Puede verificar que estos permisos se hayan establecido correctamente en el portal. En su

Key Vault, en el Políticas de acceso sección, debería ver que la aplicación flexible tiene Obtener
permisos para claves, secretos y certificados:
Figura 10.43: La aplicación flexible tiene permisos para obtener claves, secretos y certificados.
Nota
Key Vault FlexVolume admite varias opciones de autenticación. Ahora estamos usando una
entidad de servicio creada previamente. FlexVolume también admite el uso de identidades
administradas, ya sea usando una identidad Pod o usando la identidad del Conjunto de
escala de máquina virtual (VMSS) que aloja el clúster. Estas otras opciones de
autenticación no se explorarán en este libro, pero le recomendamos que lea más en
https://github.com/Azure/kubernetes-keyvault-flexvol .
Eso concluye la configuración de Key Vault FlexVolume. En la siguiente sección, usaremos

FlexVolume para obtener acceso a un secreto y montarlo en un Pod.
Uso de Key Vault FlexVolume para montar un secreto en un Pod
En esta sección, montaremos un secreto de Key Vault en un nuevo Pod.
1. Hemos proporcionado un archivo llamado pod_secret_flex.yaml que ayudará a crear un Pod

que monta un secreto de Key Vault. Deberá realizar dos cambios en este archivo:
1 apiVersion: v1
2 tipo: Pod
3 metadatos:
4 nombre: nginx-secret-flex
5 Especificaciones:
6 contenedores:
7 - nombre: nginx
8 imagen: nginx
9 volumeMounts:
10 - nombre: prueba
11 mountPath: / etc / secret /

12 readOnly: verdadero
13 volúmenes:
14 - nombre: prueba
15 flexVolume:
dieciséis controlador: "azure / kv"
17 secretRef:
18 nombre: kvcreds
19 opciones:
20 keyvaultname: <nombre de keyvault>
21 keyvaultobjectnames: k8s-secret-demo
22 keyvaultobjecttypes: secreto
23 tenantid: "<ID de inquilino>"
Investiguemos este archivo:
Líneas 9-12: Al igual que en el ejemplo de montar un secreto como un archivo, también proporcionamos un volumeMount
para montar nuestro secreto como un archivo.
Líneas 13-23: Esta es la configuración de volumen que apunta a FlexVolume.
Líneas 17-18: Aquí, nos referimos a las credenciales de la entidad de servicio que creamos en el
ejemplo anterior.
Líneas 20-23: Debe realizar cambios en estos valores para representar su

entorno.
2. Podemos crear este Pod usando el siguiente comando:
kubectl create -f pod_secret_flex.yaml
3. Una vez que el Pod se crea y se ejecuta, podemos ejecutarlo en el Pod y verificar que el
secreto esté presente:
kubectl exec -it nginx-secret-flex bash cd /

etc / secret
cat k8s-secreto-demo
Esto debería generar el secreto que creamos en Key Vault, como se ve en la Figura 10.43:
Figura 10.44: El secreto que configuramos en Key Vault está montado en el Pod como un archivo
Hemos utilizado con éxito Key Vault para almacenar secretos. El secreto ya no se almacena mal
codificado usando base64 en nuestro clúster, pero ahora se almacena de forma segura fuera
del clúster en Key Vault. Todavía podemos acceder al secreto en el clúster usando Key Vault
FlexVolume.
Asegurémonos de limpiar nuestra implementación:
kubectl eliminar -f pod_secret_flex.yaml kubectl

eliminar -f kv-flexvol-installer.yaml kubectl
eliminar secreto kvcreds
En esta sección, hemos visto varias formas de crear y montar secretos. Hemos explorado la creación de
secretos utilizando archivos, archivos YAML y directamente desde la línea de comandos. También hemos
explorado cómo se pueden consumir los secretos, ya sea como una variable de entorno o como un
archivo montado. Luego, buscamos una forma más segura de consumir secretos, es decir, a través de
Azure Key Vault.
En la siguiente sección, exploraremos el uso de la malla de servicios de Istio para configurar seguridad de
red adicional en nuestro clúster.
La malla de servicios de Istio a su servicio | 303
La malla de servicios de Istio a su servicio

Hemos encontrado varias formas de proteger nuestros Pods, pero nuestras conexiones de red aún están
abiertas. Cualquier pod del clúster puede comunicarse con cualquier otro pod del mismo clúster. Como
ingeniero de confiabilidad del sitio, querrá hacer cumplir las reglas de entrada y salida. Además, también
desea introducir la supervisión del tráfico y le gustaría tener un mejor control del tráfico. Como
desarrollador, no desea que le molesten todos esos requisitos, ya que no sabrá dónde se implementará
su aplicación, o qué está y qué no está permitido. La mejor solución sería una herramienta para que
podamos ejecutar las aplicaciones tal cual, sin dejar de especificar políticas de red, monitoreo avanzado y
control de tráfico.
Ingrese a la malla de servicios. Se define como la capa que controla la comunicación de servicio a servicio.
Una malla de servicios es una red entre microservicios. Una malla de servicios se implementa como una
pieza de software que controla y monitorea el tráfico entre esos diferentes microservicios. Normalmente,
una malla de servicios utiliza un sidecar para implementar la funcionalidad de forma transparente. Si
recuerda, un Pod en Kubernetes puede constar de uno o más contenedores. Un sidecar es un contenedor
que se agrega a un Pod existente para implementar funcionalidades adicionales; en el caso de una malla
de servicios, esta funcionalidad es la funcionalidad de la malla de servicios.
Nota
Una malla de servicios controla mucho más que la simple seguridad de la red. Si todo lo
que necesita es seguridad de red en su clúster, considere adoptar políticas de red.
Al igual que con los microservicios, la implementación de una malla de servicios no es un almuerzo
gratis. Si no tiene cientos de microservicios en ejecución, probablemente no necesite una malla de
servicios. Si decide que realmente necesita uno, primero deberá elegir uno. Hay cuatro opciones
populares, cada una con sus propias ventajas:
• Linkerd ( https://linkerd.io/ ), incluido Conduit ( https://conduit.io/ )
• Istio ( https://istio.io/ )
• Cónsul ( https://www.consul.io/mesh.html )
Debe elegir una malla de servicio según sus necesidades y sentirse cómodo sabiendo
que cualquiera de estas soluciones funcionará para usted. En esta sección,
introducirse en la malla de servicios de Istio. Elegimos la malla de servicios de Istio por su
popularidad. Usamos estrellas y confirmaciones en GitHub como medida de popularidad.
Descripción de la malla de servicios de Istio
Istio es una malla de servicios creada por IBM, Google y Lyft. El proyecto se anunció en mayo de 2017 y
alcanzó una v1 estable en julio de 2018. Istio es la parte del plano de control de la malla de servicio. Istio
por defecto hace uso de la Enviado sidecar. En esta sección, intentaremos explicar qué es una malla de
servicios y cuáles son las funcionalidades centrales de la malla de servicios de Istio.
Nota
En este libro solo nos referimos a las mallas de servicio, y específicamente a Istio, muy brevemente.
Istio es una herramienta muy poderosa no solo para proteger sino también para administrar el tráfico
de su aplicación nativa de la nube. Hay muchos detalles y funcionalidades que no cubrimos en este
libro.
En términos de funcionalidad, una malla de servicios (e Istio específicamente) tiene una serie de
capacidades básicas. La primera de estas capacidades es la gestión del tráfico. El término gestión del
tráfico en este contexto significa el control del enrutamiento del tráfico. Al implementar una malla de
servicios, puede controlar el tráfico para implementar pruebas A / B o implementaciones de canary. Sin
una malla de servicios, necesitaría implementar esa lógica en el código central de su aplicación, mientras
que con una malla de servicios, esa lógica se implementa fuera de la aplicación.
Con la gestión del tráfico también viene la seguridad adicional que ofrece Istio. Istio puede
gestionar la autenticación, la autorización y el cifrado de la comunicación de servicio a
servicio. Esto asegura que solo los servicios autorizados se comuniquen entre sí. En
términos de cifrado, Istio puede implementar TLS mutuo (mTLS) para cifrar la
comunicación de servicio a servicio.
Istio también tiene la capacidad de implementar políticas. Las políticas se pueden utilizar para
limite la tasa de tráfico determinado (por ejemplo, solo permita x transacciones por minuto), maneje la lista
blanca y la lista negra del acceso a los servicios, o implemente reescrituras y redireccionamientos de
encabezados.
Finalmente, Istio agrega una tremenda visibilidad del tráfico entre los diferentes servicios en su
aplicación. Fuera de la caja, Istio puede realizar el seguimiento del tráfico, el monitoreo y el
registro del tráfico entre sus servicios. Puede utilizar esta información para crear paneles para
demostrar el rendimiento de la aplicación y utilizar esta información para depurar fallos de la
aplicación de forma más eficaz.
En la siguiente sección, instalaremos Istio y configuraremos el cifrado mTLS del tráfico

entre Pods. Esta es solo una de las muchas capacidades de la plataforma. Le animamos a
que se aventure fuera del libro y aprenda más sobre Istio.
Instalación de Istio
Instalar Istio es sencillo; para hacerlo, siga estos pasos:
1. Vaya a su directorio de inicio y descargue el istio paquete, como sigue:
cd ~
curl -L https://istio.io/downloadIstio | sh -
2. Añade el istio binarios a su camino. Primero, obtenga el número de versión de Istio que está
ejecutando:
ls | grep istio
Esto debería mostrarte una salida similar a Figura 10.45:
Figura 10.45: Obtención de su número de versión de Istio
Anote la versión de Istio y utilícela de la siguiente manera para agregar los binarios a su ruta:
export PATH = "$ PATH: ~ / istio- <número de lanzamiento> / bin"
3. Verifique si su clúster se puede usar para ejecutar Istio usando el siguiente comando:
istioctl verificar-instalar
4. Instalar istio con el perfil de demostración:
Se aplica el manifiesto istioctl --set profile = demo
Nota
El perfil de demostración es ideal para una demostración de Istio, pero no se recomienda para
instalaciones de producción.
5.Asegúrese de que todo esté en funcionamiento, de la siguiente manera:
kubectl get svc -n istio-system
Debería ver una serie de servicios en el istio-sistema espacio de nombres:
Figura 10.46: Todos los servicios de Istio están en funcionamiento
Ahora tiene Istio en funcionamiento.
Inyectar Envoy como sidecar automáticamente
Como se mencionó en la introducción de esta sección, una malla de servicios usa un sidecar para implementar la
funcionalidad. Istio tiene la capacidad de instalar el Enviado sidecar que utiliza automáticamente mediante el uso de
etiquetas en el espacio de nombres. Podemos hacer que funcione de esta manera siguiendo los siguientes pasos:
1. Etiquetemos el espacio de nombres predeterminado con la etiqueta adecuada, a saber istio-

inyección = habilitado:
kubectl etiqueta espacio de nombres predeterminado istio-injection = habilitado
2. Iniciemos una aplicación para ver si el sidecar se implementa

automáticamente (el bookinfo.yaml se proporciona en el código fuente de
este capítulo):
kubectl create -f bookinfo.yaml

Haz que los pods se ejecuten en el espacio de nombres predeterminado. Es posible que los Pods demoren un par
de segundos en aparecer, y tomará un par de minutos para que todos los Pods se conviertan en Corriendo:
3. Ejecute el describir comando en cualquiera de los Pods:
kubectl describe pods / productpage-v1- <pod-ID>
Puede ver que efectivamente se ha aplicado el sidecar:
Figura 10.47: Istio inyectó automáticamente el proxy sidecar
Tenga en cuenta que, sin realizar ninguna modificación en la aplicación subyacente, pudimos
implementar la malla de servicios de Istio y adjuntarla a los contenedores.
Aplicación de TLS mutua
Para cifrar todo el tráfico de servicio a servicio, habilitaremos mTLS. De forma predeterminada, no
se aplica TLS mutua. En esta sección, aplicaremos la autenticación mTLS paso a paso.
Nota
Si desea obtener más información sobre el marco de seguridad de un extremo a otro
dentro de Istio, lea https://istio.io/docs/concepts/security/ # autenticación-políticas . Para
obtener más detalles sobre TLS mutuo, lea https://istio.io/docs/concepts/ security / #
mutual-tls-authentication .
Implementar servicios de muestra
En este ejemplo, implementará dos servicios, httpbin y dormir, bajo diferentes espacios de
nombres. Dos de estos espacios de nombres, foo y bar, será parte de la malla de servicios. Esto
significa que tendrán la istio proxy de sidecar. Aprenderá una forma diferente en la que se puede
inyectar un sidecar aquí. El tercer espacio de nombres, legado, ejecutará los mismos servicios sin
el proxy sidecar:
Figura 10.48: Dos de los tres espacios de nombres están en la malla de servicios
Veremos los servicios de los espacios de nombres utilizando los siguientes comandos:
1. Primero, creamos espacios de nombres ( foo, bar, y legado) y crea el httpbin y dormir
servicios en esos espacios de nombres:
kubectl crea ns foo

kubectl apply -f <(istioctl kube-inject \
- f httpbin.yaml) -n foo
- f sleep.yaml) -n foo
kubectl crea barra ns

- f httpbin.yaml) -n bar
- f sleep.yaml) -n bar
kubectl crea ns legacy
kubectl apply -f httpbin.yaml -n legacy

kubectl apply -f sleep.yaml -n legacy
Como puede ver, ahora estamos usando el istioctl herramienta para inyectar el sidecar. Lee
nuestros archivos YAML e inyecta el sidecar en la implementación. Ahora tenemos un servicio en
el foo y bar espacios de nombres con el sidecar inyectado. Sin embargo, no se inyectan en el legado
espacio de nombres.
2. Comprobemos si todo se implementó correctamente. Para comprobar esto, hemos proporcionado

un script que establece una conexión desde cada espacio de nombres a todos los demás
espacios de nombres. El script generará el código de estado HTTP para cada conexión.
Figura 10.49: El script probará todas las conexiones.
3. Ejecute el script con el siguiente comando:
bash test_mtls.sh
El comando anterior recorre todas las combinaciones accesibles. Debería ver algo
similar al siguiente resultado. Un código de estado HTTP de 200 significa éxito:
Figura 10.50: Sin ninguna política, podemos conectarnos con éxito de cada espacio de nombres al otro
espacios de nombres
Esto nos muestra que en la configuración actual, todos los Pods pueden comunicarse con todos los
demás Pods.
4. Asegúrese de que no haya políticas existentes excepto la predeterminada, como se indica a continuación:
kubectl get policies.authentication.istio.io \

- -nombres
todos los espacios de
kubectl obtiene meshpolicies.authentication.istio.io
Esto debería mostrarte:
Figura 10.51: Solo debe haber dos políticas presentes
5. Además, asegúrese de que no se apliquen reglas de destino:
kubectl obtiene destinationrules.networking.istio.io \

- - todos los espacios de nombres -o yaml | grep "host:"
En los resultados, no debe haber hosts con foo, bar, legado, o un comodín (indicado
como *).
Figura 10.52: No debe haber hosts con foo, bar, legacy o un comodín *
Hemos implementado con éxito los servicios de muestra y pudimos confirmar que, en el
escenario predeterminado, todos los servicios pudieron comunicarse entre sí.
Habilitación global de mTLS
Con una política de mTLS, puede indicar que todos los servicios deben utilizar mTLS cuando se
comunican con otros servicios. Si no usa mTLS, un mal actor que tiene acceso a un clúster, incluso
si no tiene acceso al espacio de nombres, puede comunicarse con cualquier Pod. Si se les otorgan
suficientes derechos, también pueden operar como intermediarios entre los servicios. La
implementación de mTLS entre servicios reduce las posibilidades de ataques de intermediario
entre servicios:
1. Para habilitar TLS mutuo a nivel mundial, crearemos lo siguiente MeshPolicy ( proporcionada en
mtls_policy.yaml):
1 apiVersion: authentication.istio.io/v1alpha1
2 tipo: MeshPolicy
3 metadatos:
4 nombre: predeterminado
5 Especificaciones:
6 compañeros:
7 - mtls: {}
Desde esto MallaPolítica no tiene selectores, se aplicará a todas las cargas de trabajo. Todas las cargas
de trabajo de la malla solo aceptarán solicitudes cifradas mediante TLS. Esto significa el
MallaPolítica maneja la parte entrante de la conexión:
Figura 10.53: MeshPolicy se aplica a la conexión entrante

Puede crear el MallaPolítica usando este comando:
kubectl apply -f mtls_policy.yaml
Nota
Estamos aplicando el mTLS de manera muy aproximada y agresiva. Normalmente, en un sistema de
producción, introducirá mTLS más lentamente. Istio tiene un modo de aplicación de mTLS especial
llamado permisivo para ayudar a lograr esto. Con mTLS en el permisivo modo, Istio intentará
implementar mTLS siempre que sea posible y registrará una advertencia donde no sea posible. Sin
embargo, el tráfico seguirá fluyendo.
2. Ahora ejecute el script nuevamente para probar la conectividad de red:
bash test_mtls.sh
3. Aquellos sistemas con sidecars fallarán al ejecutar este comando y recibirán un 503 código de
estado, ya que el cliente todavía usa texto sin formato. Puede que tarden unos segundos en MallaPolítica
para tomar efecto. Figura 10.54 muestra la salida:
Figura 10.54: El tráfico a los pods con un sidecar falla con un código de estado 503
Si ves un 200 código de estado con más frecuencia en la salida anterior, considere
esperar un par de segundos y luego volver a ejecutar la prueba.
4. Ahora permitiremos cierto tráfico configurando la regla de destino para usar un comodín *
similar a la política de autenticación de toda la malla. Esto es necesario para configurar el lado
del cliente:
1 apiVersion: networking.istio.io/v1alpha3
2 kind: DestinationRule
3 metadatos:
4 nombre: predeterminado
5 espacio de nombres: istio-system

6 Especificaciones:
7 anfitrión: "* .local"
8 TrafficPolicy:
9 tls:
10 modo: ISTIO_MUTUAL
Echemos un vistazo a este archivo:
• Línea 2: Aquí, estamos creando un DestinationRule que define las políticas que se aplican al tráfico
destinado a un servicio después de que se ha producido el enrutamiento.
• Línea 7: Tráfico destinado a cualquier host en. local que en nuestro caso es todo el tráfico del
clúster) debería utilizar esta política.
• Líneas 8-10: Aquí, definimos que se requiere mTLS para todo el tráfico.
El DestinationRule se aplica a la parte saliente de la conexión, como se muestra en
Figura 10.55:
Figura 10.55: DestinationRule se aplica al tráfico saliente

Podemos crear esto usando lo siguiente:

kubectl create -f destinationRule.yaml
Podemos verificar el impacto de esto ejecutando el mismo comando nuevamente:
bash test_mtls.sh
Esta vez, los códigos devueltos serán como se muestra en Figura 10.56:
Figura 10.56: Foo y bar ahora pueden conectarse entre sí, pero ya no pueden conectarse al legado
Consideremos por un minuto lo que implementamos en este caso. Implementamos: Una política
para todo el clúster que requiere que el tráfico TLS ingrese a los pods.
Una DestinationRule para todo el clúster que requería mTLS en el tráfico saliente.
El impacto de esto es que los servicios dentro de la malla (también conocidos como tener el sidecar)
ahora pueden comunicarse entre sí usando mTLS, y los servicios que están completamente fuera de la
malla (también conocidos como no tener el sidecar) también pueden comunicarse con cada uno. otro,
solo sin mTLS. Debido a nuestra configuración actual, la comunicación de servicio a servicio se
interrumpe cuando solo una parte del flujo está en la malla.
Resumen | 315
Asegurémonos de limpiar todos los recursos que implementamos:
istioctl manifest generate --set profile = demo | kubectl delete -f para NS

en "foo" "bar" "legacy"
hacer
kubectl delete -f sleep.yaml -n $ NS

kubectl delete -f httpbin.yaml -n $ NS
done
kubectl eliminar -f bookinfo.yaml
Con esto concluye esta demostración de Istio.
Resumen
En este capítulo, nos centramos en la seguridad en Kubernetes. Comenzamos con una mirada al clúster RBAC
usando identidades en Azure AD. Después de eso, continuamos almacenando secretos en Kubernetes.
Entramos en detalles sobre la creación, decodificación y uso de secretos. Finalmente, instalamos e inyectamos
Istio, logrando el objetivo de poder establecer políticas para todo el sistema sin necesidad de la intervención o
supervisión del desarrollador. Dado que a los piratas informáticos les gusta elegir sistemas fáciles, las
habilidades que ha aprendido en este capítulo ayudarán a que su configuración sea menos propensa a ser
atacada.
En el siguiente y último capítulo, aprenderá cómo implementar funciones sin servidor en Servicio de
Azure Kubernetes (AKS).
Funciones sin servidor
11
Las funciones sin servidor y sin servidor han ganado un gran impulso en los últimos años. Los
servicios en la nube como Azure Functions, AWS Lambda y GCP Cloud Run han facilitado mucho a
los desarrolladores la ejecución de su código como funciones sin servidor.
La palabra sin servidor se refiere a cualquier solución en la que no necesite administrar servidores. Las
funciones sin servidor se refieren a un subconjunto de la informática sin servidor, donde puede ejecutar su
código como una función bajo demanda. Esto significa que su código en la función solo se ejecutará y se
ejecutará cuando haya un demanda. Este estilo arquitectónico se llama arquitectura impulsada por eventos. En
una arquitectura impulsada por eventos, los consumidores de eventos se activan cuando hay un evento. En el
caso de las funciones sin servidor, los consumidores de eventos serán estas funciones sin servidor. Un evento
puede ser cualquier cosa, desde un mensaje en una cola hasta un nuevo objeto cargado en el almacenamiento,
o incluso una llamada HTTP.
318 | Funciones sin servidor
Las funciones sin servidor se utilizan con frecuencia para el procesamiento de backend. Un ejemplo
común de funciones sin servidor es la creación de miniaturas de una imagen que se carga en el
almacenamiento. Dado que no puede predecir cuántas imágenes se cargarán y cuándo se
cargarán, es difícil planificar la infraestructura tradicional y cuántos servidores debería tener
disponibles para este proceso. Si implementa la creación de esa miniatura como una función sin
servidor, esta función se llamará en cada imagen que se cargue. No es necesario planificar el
número de funciones, ya que cada nueva imagen activará la ejecución de una nueva función.
Este escalado automático es solo uno de los beneficios de utilizar funciones sin servidor. Como vio en el
ejemplo anterior, las funciones se escalarán automáticamente para satisfacer la demanda aumentada o
disminuida. Además, cada función puede escalar independientemente de otras funciones. Otro beneficio
de las funciones sin servidor es la facilidad de uso para los desarrolladores. Las funciones sin servidor
permiten implementar código sin preocuparse por administrar servidores y middleware. Finalmente, en
las funciones sin servidor de la nube pública, usted paga por la ejecución de la función. Esto significa que
paga cada vez que se ejecutan sus funciones y no se le cobra nada por el tiempo de inactividad cuando su
función no se ejecuta.
La popularidad de las plataformas de funciones sin servidor en la nube pública ha provocado la creación
de múltiples marcos de código abierto para permitir a los usuarios crear funciones sin servidor sobre
Kubernetes. En este capítulo, aprenderá a implementar funciones sin servidor en Servicios de Azure
Kubernetes (AKS) directamente con la versión de código abierto de Azure Functions. Comenzará
ejecutando una función simple que se activa en función de un mensaje HTTP. Luego, instalará la función
de escalador automático de una función en su clúster. También integrará las aplicaciones
implementadas por AKS con las colas de almacenamiento de Azure. Cubriremos los siguientes temas:
• Descripción general de las diferentes plataformas de funciones
• Implementar una función activada por HTTP
• Implementar una función activada por cola
Comencemos este capítulo explorando las múltiples plataformas de funciones que están disponibles
para Kubernetes.
Plataformas de funciones múltiples | 319
Plataformas de funciones múltiples
Las plataformas de funciones, como Azure Functions, AWS Lambda y Google Cloud Functions, han
ganado enormemente popularidad. La capacidad de ejecutar código sin pensar en servidores y
tener una escala prácticamente ilimitada es muy popular. La desventaja de utilizar la
implementación de funciones de un proveedor en la nube es que está atrapado en su
infraestructura y su modelo de programación. Además, solo puede ejecutar sus funciones en la
nube pública y no en su propio centro de datos.
Se han lanzado varios marcos de funciones de código abierto para resolver estos
inconvenientes. Hay varios marcos populares:
• Sin servidor ( https://serverless.com/ ): Un marco de aplicación sin servidor basado en Node.js que
puede implementar y administrar funciones en múltiples proveedores de nube, incluido Azure. El
soporte de Kubernetes se proporciona a través de Kubeless.
• OpenFaaS ( https://www.openfaas.com/ ): OpenFaaS es un marco sin servidor nativo de

Kubernetes. Puede ejecutarse en entornos de Kubernetes administrados, como AKS, o en un
clúster autohospedado. OpenFaaS también está disponible como un servicio en la nube
administrado mediante OpenFaaSCloud. La plataforma está escrita en el idioma Go.
• Fission.io ( https://fission.io/ ): Fission está escrito en el idioma Go y es nativo de

Kubernetes. Es un marco sin servidor respaldado por la empresa Platform9.
• Apache OpenWhisk ( https://openwhisk.apache.org/ ): OpenWhisk es una plataforma sin

servidor distribuida de código abierto mantenida por la organización Apache. Se puede
ejecutar en Kubernetes, Mesos y Docker Compose. Está escrito principalmente en el lenguaje
Scala.
• Knative https://cloud.google.com/knative/ ): Knative es una plataforma de funciones sin

servidor escrita en el lenguaje Go y desarrollada por Google. Puede ejecutar funciones de
Knative completamente administradas en Google Cloud o en su propio clúster de Kubernetes.
Microsoft ha tomado una estrategia interesante con su plataforma de funciones. Microsoft opera Azure
Functions como un servicio administrado en Azure y ha abierto la solución completa y la ha puesto a
disposición para ejecutarse en cualquier sistema ( https://github.com/ Azure / azure-functions-host ). Esto
también hace que el modelo de programación de Azure Functions esté disponible además de Kubernetes.
Microsoft también ha lanzado un proyecto adicional de código abierto en asociación con Red Hat llamado Ajuste
de escala automático impulsado por eventos de Kubernetes (KEDA) para facilitar las funciones de escalado
sobre Kubernetes. KEDA es un escalador automático personalizado que puede permitir que las
implementaciones escalen desde y hacia 0 pods. Es importante escalar de 0 a 1 pod para que su aplicación
pueda comenzar a procesar eventos. Reducir la escala a 0 instancias es útil para preservar los recursos en su
clúster. No es posible escalar hacia y desde 0 pods utilizando el valor predeterminado
Escalador automático de pod horizontal (HPA) en Kubernetes.
KEDA también pone a disposición de Kubernetes HPA métricas adicionales para tomar decisiones
de escalado basadas en métricas externas al clúster (por ejemplo, la cantidad de mensajes en
una cola).
Nota
Presentamos y explicamos la HPA en Capítulo 4, Escalar su aplicación.
En este capítulo, implementaremos Azure Functions en Kubernetes en dos ejemplos:
• Una función activada por HTTP
• Una función activada por cola
Antes de comenzar, debemos configurar un Registro de contenedores de Azure (ACR) y una máquina de
desarrollo. El ACR se utilizará para almacenar imágenes personalizadas de Docker que contienen las funciones
que desarrollaremos. Usaremos una máquina de desarrollo para construir las funciones y crear imágenes de
Docker.
Configuración de requisitos previos
En esta sección, configuraremos los requisitos previos que necesitamos para construir y ejecutar
funciones. Necesitamos un registro de contenedores y una máquina de desarrollo.
Introdujimos imágenes de contenedores y un registro de contenedores en Capítulo 1, Introducción a Docker y

Kubernetes, en la sección sobre Imágenes de Docker. Una imagen de contenedor contiene todo el software
necesario para iniciar un contenedor en ejecución real. En este capítulo, crearemos imágenes personalizadas
de Docker que contienen nuestras funciones. Necesitamos un lugar para almacenar estas imágenes para que
Kubernetes pueda extraer estas imágenes y ejecutar los contenedores a escala. Usaremos Azure Container
Registry para esto. Azure Container Registry es un registro de contenedores privado totalmente administrado
por Azure.
Hasta ahora en este libro, hemos ejecutado todos los ejemplos en Azure Cloud Shell. Para el ejemplo
de este capítulo, necesitamos una máquina de desarrollo independiente porque Azure Cloud Shell no
le permite crear imágenes de Docker. Crearemos una nueva máquina de desarrollo en Azure para
realizar estas tareas.
Configuración de requisitos previos | 321
Comencemos por crear un ACR.
Registro de contenedores de Azure
Azure Functions en Kubernetes necesita un registro de imágenes para almacenar sus imágenes de
contenedor. En esta sección, crearemos un ACR y configuraremos nuestro clúster de Kubernetes para tener
acceso a este clúster:
1. En la barra de búsqueda de Azure, busque registro de contenedores y haga clic en Envase

registros:
Figura 11.1: Buscando registros de contenedores en la barra de búsqueda
2. Haga clic en el Agregar en la parte superior para crear un nuevo registro. Proporcione los detalles a
crear el registro. El nombre del registro debe ser único a nivel mundial, así que considere
agregar sus iniciales al nombre del registro. Se recomienda crear el registro en la misma
ubicación que su clúster. Selecciona el Crear botón para crear el registro:
Figura 11.2: Proporcionar los detalles para crear el registro

3. Cuando se crea su registro, abra Cloud Shell para que podamos configurar nuestro clúster de AKS
para obtener acceso a nuestro registro de contenedores. Utilice el siguiente comando para otorgar
permisos a AKS en su registro:
az aks update -n handsonaks -g rg-handsonaks --attach-acr <acrName>
Ahora tenemos un ACR que está integrado con AKS. En la siguiente sección, crearemos una
máquina de desarrollo que se utilizará para construir las funciones de Azure.
Creando una máquina de desarrollo
En esta sección, crearemos una máquina de desarrollo e instalaremos las herramientas necesarias para
ejecutar las funciones de Azure en esta máquina:
• Tiempo
Docker de ejecución de
• CLI de Azure
• Funciones de Azure
• Kubectl
Nota
Para asegurar una experiencia consistente, crearemos un máquina virtual (VM) en Azure que
se utilizará para el desarrollo. Si prefiere ejecutar la muestra en su máquina local, puede
instalar todas las herramientas necesarias localmente.
Comencemos con la creación de la máquina:
1. Para comenzar, generaremos un conjunto de claves ssh que se utilizarán para conectarse a la VM:
ssh-keygen
Se le pedirá una ubicación y una frase de contraseña. Mantenga la ubicación predeterminada e

ingrese una frase de contraseña vacía.
Nota
Si siguió el ejemplo en Capítulo 10, Protección de su clúster de AKS, donde creamos un
clúster integrado de Azure AD, puede omitir el paso 1 ya que ya tendrá un conjunto de
claves SSH.
Si prefiere reutilizar las claves SSH que ya tiene, también puede hacerlo.
2. Ahora crearemos nuestra máquina de desarrollo. Crearemos una VM Ubuntu usando

az vm create -g rg-handsonaks -n devMachine \

- - imagen UbuntuLTS --ssh-key-value ~ / .ssh / id_rsa.pub \
- - admin-username handsonaks - tamaño Standard_D1_v2
3. Esto tardará un par de minutos en completarse. Una vez que se crea la VM, Cloud Shell
debería mostrarle su IP pública, como se muestra en Figura 11.3:
Figura 11.3: Conexión a la IP pública de la máquina
Conéctese a la máquina virtual con el siguiente comando:
ssh handsonaks @ <IP pública>
Se le preguntará si confía en la identidad de la máquina. Tipo sí para

confirmar.
4. Ahora está conectado a una nueva máquina en Azure. En esta máquina, comenzaremos
instalando Docker:
sudo apt-get update

sudo apt-get install docker.io -y sudo
systemctl enable docker sudo
systemctl start docker
5. Para verificar que Docker esté instalado y en ejecución, puede ejecutar el siguiente comando:
sudo docker ejecutar hello-world
Esto debería mostrarte el Hola Mundo mensaje de Docker:
Figura 11.4: Ejecución de hello-world con Docker
6. Para que la operación sea más fluida, agregaremos nuestro usuario al grupo Docker, que
ya no requerirá sudo delante de los comandos de Docker:
sudo usermod -aG docker handsonaks

newgrp docker
Ahora debería poder ejecutar el Hola Mundo comando sin sudo:
Docker ejecutar hola-mundo
7. A continuación, instalaremos la CLI de Azure en esta máquina de desarrollo. Puede

instalar la CLI con el siguiente comando:
curl -sL https://aka.ms/InstallAzureCLIDeb | sudo bash
8. Verifique que la CLI se haya instalado correctamente iniciando sesión:
az login
Esto mostrará un código de inicio de sesión que debe ingresar en https://microsoft.com/

devicelogin :
Figura 11.5: Inicio de sesión en az CLI
Vaya a ese sitio web y pegue el código de inicio de sesión que se le proporcionó para que
pueda iniciar sesión en Cloud Shell. Asegúrese de hacer esto en un navegador en el que haya
iniciado sesión con el usuario que tiene acceso a su suscripción de Azure.
Ahora podemos usar la CLI para autenticar nuestra máquina en ACR. Esto se puede hacer
usando el siguiente comando:
az acr login -n <nombre de registro>
Esto le mostrará una advertencia de que la contraseña se almacenará sin cifrar.

Puede ignorar eso a los efectos de esta demostración.
Las credenciales de ACR caducan después de cierto tiempo. Si se encuentra con el siguiente error
durante esta demostración, puede iniciar sesión en ACR nuevamente usando el comando
anterior:
Figura 11.6: Si se encuentra este error, puede resolverlo iniciando sesión en ACR nuevamente
9. A continuación, instalaremos kubectl en nuestra máquina. El Arizona CLI tiene un acceso directo para instalar el
CLI, que usaremos:
sudo az aks install-cli
Vamos a verificar eso kubectl puede conectarse a nuestro clúster. Para esto, primero obtendremos las
credenciales y luego ejecutaremos un kubectl mando:
az aks get-credentials -n handsonaks -g rg-handsonaks

kubectl get nodos
10. Ahora, podemos instalar las herramientas de Azure Functions en esta máquina. Para hacer esto, ejecute los
wget -q
https://packages.microsoft.com/config/ubuntu/18.04/packagesmicrosoft-prod.deb
sudo dpkg -i paquetes-microsoft-prod.deb
sudo apt-get update
sudo apt-get install azure-functions-core-tools -y
Nota
Si está ejecutando una versión más reciente de Ubuntu que la 18.04, asegúrese de
descargar la dpkg paquete cambiando la URL en el primer paso para reflejar su
versión de Ubuntu.
Ahora tenemos los requisitos previos para comenzar nuestro trabajo con funciones en Kubernetes. Creamos
un ACR para almacenar nuestras imágenes personalizadas de Docker y tenemos una máquina de desarrollo
que usaremos para crear y construir funciones de Azure. En la siguiente sección, crearemos una primera
función que se activa mediante HTTP.
Creación de una función de Azure activada por HTTP
En este primer ejemplo, crearemos una función de Azure activada por HTTP. Esto significa que
puede navegar hasta la página que aloja la función real:
1. Para comenzar, crearemos un nuevo directorio y navegaremos hasta ese directorio:
mkdir http
cd http
2. Ahora, inicializaremos una función usando el siguiente comando. El -- estibador

El parámetro especifica que construiremos nuestra función como un contenedor Docker. Esta
resultará en la creación de un Dockerfile para nosotros. Seleccionaremos el lenguaje Python,
opción 3 en la siguiente captura de pantalla:
func init --docker

Creación de una función de Azure activada por HTTP | 327
Esto creará los archivos necesarios para que funcione nuestra función:
Figura 11.7: Creando una función Python
3. A continuación, crearemos la función real. Ingrese el siguiente código y seleccione la quinta

opción, Disparador HTTP, y nombrar la función python-http:
func nuevo
Esto debería resultar en una salida como Figura 11.8:
Figura 11.8: Creación de una función activada por HTTP

4. El código de la función se almacena en el directorio llamado python-http. No vamos

a realizar cambios en el código de la función. Si desea consultar el código fuente de
la función, puede ejecutar el siguiente comando:
gato python-http / __ init__.py
5. Necesitaremos hacer un cambio en el archivo de configuración de una función. De forma

predeterminada, las funciones requieren una solicitud autenticada. Cambiaremos esto a anónimo
para nuestra demostración. Haremos el cambio en vi ejecutando el siguiente comando:
vi python-http / function.json
Reemplazaremos el authLevel en la línea 5 con anónimo. Para realizar ese cambio,

ejecute los siguientes pasos:
prensa I para entrar en el modo de inserción. Eliminar función
y reemplazarlo con anónimo:
Figura 11.9: Cambiar la función a anónima
• Pegar Esc, tipo : wq !, y luego Ingresar para ahorrar y salir vi.
Nota
Cambiamos el requisito de autenticación para nuestra función a anónimo.
Esto hará que nuestra demostración sea más fácil de ejecutar. Si planea lanzar funciones a
producción, debe considerar cuidadosamente esta configuración, ya que controla quién tiene
acceso a su función.
Creación de una función de Azure activada por HTTP | 329
6. Ahora estamos listos para implementar nuestra función en AKS. Podemos implementar la función usando
func kubernetes deploy --name python-http \

- - registro <nombre de registro> .azurecr.io
Esto hará que el tiempo de ejecución de la función realice un par de pasos. Primero, creará una
imagen de contenedor, luego enviará esa imagen a nuestro registro y, finalmente,
implementará la función en Kubernetes:
Figura 11.10: Implementación de la función en AKS
7. Esto creará un Pod regular sobre Kubernetes. Para verificar los pods, puede
ejecutar el siguiente comando:
8. Una vez que el Pod está en estado de ejecución, puede obtener la IP pública del Servicio que se
implementó y conectarse a él:
Abra un navegador web y busque http: // <ip-external> / api / python- http? name =
handsonaks. Debería ver una página web que le muestre ¡Hola handsonaks !,
que es lo que se supone que muestra nuestra función:
Figura 11.11: Nuestra función está funcionando correctamente
Ahora hemos creado una función con un disparador HTTP. Limpiemos esta implementación antes
de pasar a la siguiente sección:
Kubectl eliminar implementar python-http-http
kubectl eliminar servicio python-http-http
kubectl eliminar secreto python-http
En esta sección, creamos una función de muestra usando un disparador HTTP. Vayamos un paso más allá e
integremos una nueva función con las colas de almacenamiento y configuremos un escalador automático.
Crear una función activada por cola

En la sección anterior, creamos una función HTTP de muestra. En un caso de uso del mundo real, las
colas se utilizan a menudo para pasar mensajes entre diferentes componentes de una aplicación. Se
puede activar una función en función de los mensajes en una cola para luego realizar un procesamiento
adicional en estos mensajes.
En esta sección, crearemos una función que se integra con las colas de almacenamiento para consumir eventos.
También configuraremos KEDA para permitir el escalado hacia / desde 0 Pods en caso de poco tráfico.
Todavía comenzamos creando una cola en Azure.
Creando una cola

En esta sección, crearemos una nueva cuenta de almacenamiento y una nueva cola en esa cuenta de
almacenamiento. Conectaremos funciones a esa cola en la siguiente sección.
1. Para comenzar, crearemos una cuenta de almacenamiento. Buscar almacenamiento en la búsqueda de Azure
barra y seleccione Cuentas de almacenamiento:
Figura 11.12: Buscando almacenamiento en la barra de búsqueda de Azure
2. Haga clic en el Agregar en la parte superior para crear una nueva cuenta. Proporcione los detalles
para crear la cuenta de almacenamiento. El nombre de la cuenta de almacenamiento debe ser único a
nivel mundial, así que considere agregar sus iniciales. Se recomienda crear la cuenta de almacenamiento
en la misma región que su clúster de AKS. Finalmente, para ahorrar costos, se recomienda degradar la
configuración de replicación a Almacenamiento con redundancia local (LRS):
Creación de una función activada por cola | 331
Figura 11.13: Proporcionar los detalles para crear la cuenta de almacenamiento
Si está listo, haga clic en el Revisar y crear botón en la parte inferior. En la pantalla de revisión,
seleccione Crear para iniciar el proceso de creación.
3. La creación de la cuenta de almacenamiento tardará aproximadamente un minuto. Una vez creada,

abra la cuenta haciendo clic en el ir al recurso botón. En la hoja de la cuenta de almacenamiento,
vaya a Claves de acceso, y copie la cadena de conexión principal. Anote esta cadena por ahora:
Figura 11.14: Copia de la cadena de conexión primaria
Nota
Para casos de uso de producción, no se recomienda conectarse al almacenamiento de Azure mediante la
clave de acceso. Cualquier usuario con esa clave de acceso tiene acceso completo a la cuenta de
almacenamiento y puede leer y eliminar todos los archivos que contiene. Se recomienda generar un
firmas de acceso compartido (SAS) token para conectarse al almacenamiento o para usar la seguridad
integrada en Azure AD. Para obtener más información sobre la autenticación de token SAS en el
almacenamiento, consulte https://docs.microsoft.com/rest/api/storageservices/delegate-accesswith-shared-access-signature
. Para obtener más información sobre la autenticación de Azure AD en el almacenamiento de Azure, consulte https://docs.microsoft.com
authorize-with-azure-active-directory .
4. El último paso es crear nuestra cola en la cuenta de almacenamiento. Buscar cola en el

navegación de la izquierda, haga clic en + Cola para agregar una cola y proporcionarle un
nombre. Para seguir con esta demostración, llame a la cola función:
Figura 11.15: Creando una nueva cola
Ahora hemos creado una cuenta de almacenamiento en Azure y tenemos su cadena de conexión.
Creamos una cola en esta cuenta de almacenamiento. En la siguiente sección, crearemos una
función que consumirá mensajes de la cola.
Crear una función activada por cola

En la sección anterior, creamos una cola en Azure. En esta sección, crearemos una
nueva función que vigilará esta cola. Necesitaremos configurar esta función con la
cadena de conexión a esta cola:
1. Comenzaremos creando un nuevo directorio y navegando hasta él:
mkdir ~ / js-queue
cd ~ / js-queue
2. Ahora podemos crear la función. Empezaremos con la inicialización:

func init --docker
<seleccionar nodo, opción 2>
<seleccione javascript, opción 1>
Esto debería resultar en la salida que se muestra en Figura 11.16:
Figura 11.16: Inicialización de una nueva función
Después de la inicialización, podemos crear la función real:
func nuevo
<seleccione el desencadenador de almacenamiento en cola de Azure,
opción 10> <proporcione un nombre, nombre sugerido: js-queue>
Esto debería resultar en la salida que se muestra en Figura 11.17:
Figura 11.17: Creando una nueva función

3. Ahora necesitaremos hacer un par de cambios de configuración. Necesitamos proporcionar funciones

con la cadena de conexión al almacenamiento de Azure y proporcionar el nombre de la cola. Primero,
abra el local.settings.json archivo para configurar las cadenas de conexión para el almacenamiento:
vi local.settings.json
Para realizar los cambios, siga estas instrucciones: Pulse I para
• entrar en el modo de inserción.
• En la linea de AzureWebJobsStorage ( línea 6), reemplace el valor con la cadena de conexión

que copió anteriormente. Agrega una coma al final de esta línea.
• Agregue una nueva línea y luego agregue el siguiente texto en esa línea:
"QueueConnString": "<su cadena de conexión>"
Figura 11.18: Editando el archivo local.settings.json
• Guarde y cierre el archivo presionando el Esc clave, escriba: wq !, y luego presione Ingresar.
4. El siguiente archivo que necesitamos editar es la configuración de la función en sí. Aquí, nos
referiremos a la cadena de conexión anterior y proporcionaremos el nombre de la cola. Para hacer
eso, use el siguiente comando:
vi js-queue / function.json
Para realizar los cambios, siga estas instrucciones: Pulse I para
• entrar en el modo de inserción.
• En la línea 7, cambie el nombre de la cola por el nombre de la cola que creamos ( función).
• En la línea 8, agregue QueueConnString al campo de conexión:
Figura 11.19: Editando el archivo js-queue / function.json
• Guarde y cierre el archivo presionando el Esc clave, escriba: wq !, y luego presione Ingresar.
5. Ahora estamos listos para publicar nuestra función en Kubernetes. Comenzaremos la

publicación configurando KEDA en nuestro clúster de Kubernetes:
kubectl crea ns keda

func kubernetes install --keda - espacio de nombres keda
Esto configurará KEDA en nuestro clúster. La instalación no tarda mucho. Para verificar que la
instalación se haya realizado correctamente, asegúrese de que KEDA Pod se esté ejecutando:
kubectl get pod -n keda

6. Ahora podemos implementar nuestra función en Kubernetes. Configuraremos KEDA para ver el
número de mensajes en cola cada 5 segundos ( intervalo de sondeo = 5) tener un máximo de 15
réplicas ( max-réplicas = 15), y esperar 15 segundos antes de quitar los Pods ( período de
enfriamiento = 15). Para implementar y configurar KEDA, use el siguiente comando:
func kubernetes deploy --name js-queue \

- - registro <nombre de registro> .azurecr.io \
- - polling-interval = 5 --max-replicas = 15 --cooldown-period = 15
Para verificar la implementación, puede ejecutar el siguiente comando:
Esto le mostrará todos los recursos que se implementaron. Como puedes ver en Figura
11.20, esta implementación crea una implementación, un ReplicaSet y un HPA. En la
HPA, debería ver que no hay réplicas actualmente en ejecución:
Figura 11.20: La implementación creó tres objetos y ahora no tenemos ninguna réplica ejecutándose
7. Crearemos un mensaje en la cola ahora para activar la implementación y crear un pod.

Para ver el evento de escala, ejecute el siguiente comando:

8. Para crear un mensaje en la cola, vamos a abrir una nueva sesión de Cloud Shell. Para abrir una
nueva sesión, seleccione el Abrir nueva sesión botón en el caparazón de la nube:
Figura 11.21: Apertura de una nueva instancia de Cloud Shell
9. En este nuevo shell, ejecute el siguiente comando para crear un mensaje en la cola.
az storage message put --queue-name function --connection-string <su

cadena de conexión> --content "test"
Después de crear este mensaje, vuelva al shell anterior. Puede llevar un par de
segundos, pero pronto, su HPA debería escalar a 1 réplica. Posteriormente, también
debería reducirse a 0 réplicas:
Figura 11.22: Con un mensaje en la cola, KEDA escala de 0 a 1 y de nuevo a 0 réplicas
Ahora hemos creado una función que se activa en función del número de mensajes en una
cola. Pudimos verificar que KEDA escaló nuestros pods de 0 a 1 cuando creamos un mensaje
en la cola, y regresó a 0 cuando no quedaban mensajes. En la siguiente sección,
ejecutaremos una prueba de escala, crearemos múltiples mensajes en la cola y veremos
cómo reaccionan las funciones.
Funciones de prueba de escala
En la sección anterior, vimos cómo reaccionaban las funciones cuando había un solo mensaje
en la cola. En este ejemplo, enviaremos 1,000 mensajes a la cola y veremos cómo KEDA escalará
primero nuestra función, luego escalará hacia adentro y eventualmente escalará nuevamente a
cero:
1. En el shell de nube actual, observe la HPA con el siguiente comando:
2. Para comenzar a enviar los mensajes, vamos a abrir una nueva sesión de shell en la nube. Para abrir una
nueva sesión, seleccione el Abrir nueva sesión botón en el caparazón de la nube:
Figura 11.23: Apertura de una nueva instancia de Cloud Shell

3. Para enviar los 1,000 mensajes a la cola, proporcionamos un script de Python llamado sendMessages
en el paquete de código. Cloud Shell ya tiene Python y pip (el administrador de paquetes de
Python) instalados. Para poder ejecutar este script, primero deberá instalar dos dependencias:
pip3 instalar azure

pip3 instalar azure-storage-blob == 12.0.0
Cuando estén instalados, abra el sendMessages.py expediente:
código sendMessages.py
Edite la cadena de conexión de almacenamiento en la línea 4 a su cadena de conexión:
Figura 11.24: Pegar su cadena de conexión para su cuenta de almacenamiento en la línea 4
4. Una vez que haya pegado su cadena de conexión, puede ejecutar el script de
Python y enviar 1,000 mensajes a su cola:
python3 sendMessages.py
Mientras se envían los mensajes, vuelva a la instancia anterior de Cloud Shell y observe
la escala de KEDA de 0 a 1, y luego observe la escala de HPA hasta el máximo de 15
réplicas. La HPA utiliza métricas proporcionadas por KEDA para tomar
las decisiones de escala. Kubernetes, de forma predeterminada, no conoce la cantidad de
mensajes en una cola de almacenamiento de Azure que KEDA proporciona a la HPA.
Una vez que la cola esté vacía, KEDA se reducirá a 0 réplicas:
Figura 11.25: KEDA escalará de 0 a 1 y HPA escalará a 15 Pods

Esto concluye nuestros ejemplos de ejecución de funciones sin servidor sobre Kubernetes.
Asegurémonos de limpiar nuestras implementaciones. Ejecute el siguiente comando desde la
máquina de desarrollo que creamos (el paso final eliminará esta VM. Si desea conservar la VM,
no ejecute el paso final):
kubectl eliminar secreto js-queue kubectl
eliminar objeto escalado js-queue kubectl
eliminar implementación js-queue
func kubernetes eliminar --namespace keda
az vm delete -g rg-handsonaks -n devMachine
Nota
La eliminación de KEDA mostrará un par de errores. Esto se debe a que solo instalamos un subconjunto de
KEDA en la parte superior de nuestro clúster y el proceso de eliminación intenta eliminar todos los
componentes.
En esta sección, ejecutamos una función que fue activada por mensajes en una cola de almacenamiento en la
parte superior de Kubernetes. Usamos un componente llamado KEDA para lograr el escalado en nuestro
clúster. Vimos cómo KEDA puede escalar de 0 a 1 y volver a bajar a 0. También vimos cómo la HPA puede usar
las métricas proporcionadas por KEDA para escalar una implementación.
Resumen
En este capítulo, implementamos funciones sin servidor en la parte superior de nuestro clúster de Kubernetes.
Para lograr esto, primero creamos una máquina de desarrollo y un Azure Container Registry.
Comenzamos nuestras implementaciones de funciones implementando una función que usaba un disparador HTTP.
Las herramientas principales de Azure Functions se utilizaron para crear esa función e implementarla en Kubernetes.
Luego, instalamos un componente adicional en nuestro clúster de Kubernetes llamado KEDA. KEDA
permite el escalado sin servidor en Kubernetes: permite implementaciones desde y hacia 0 pods, y
también proporciona métricas adicionales a la Escalador automático de pod horizontal (HPA).
Usamos una función que se activó en mensajes en una cola de almacenamiento de Azure.
Resumen | 341
Este capítulo también concluye el libro. A lo largo de este libro, presentamos AKS a través de
varios ejemplos prácticos. La primera parte del libro se centró en la puesta en marcha de
aplicaciones. Creamos un clúster de AKS, implementamos múltiples aplicaciones y aprendimos
cómo escalar esas aplicaciones.
La segunda parte del libro se centró en los aspectos operativos de ejecutar AKS.
Analizamos los errores comunes y cómo resolverlos, integramos las aplicaciones con
Azure AD y analizamos la supervisión del clúster.
En la parte final del libro, analizamos la integración avanzada de AKS con otros servicios de Azure.
Integramos nuestro clúster de AKS con bases de datos de Azure y Azure Event Hubs, aseguramos
nuestro clúster y, finalmente, desarrollamos Azure Functions sobre nuestro clúster de AKS.
Como resultado de terminar este libro, ahora debería estar listo para construir y ejecutar
sus aplicaciones a escala sobre AKS.
Regístrate
>
Índice
Acerca de
Todas las palabras clave principales utilizadas en este libro se capturan alfabéticamente en esta sección. Cada uno
va acompañado del número de página de donde aparecen.

A auditoría: 235
registro de auditoría: 212, 222,
incorporado: 64-65, 67,
142, 214, 283
acceso: 10, 17, 34-35, 39, 233, 235, 236 bypass: 62
41, 65, 67, 75, 78, 81, autenticación: 41, 158,
142-143, 159, 173, 188,
200, 206-207, 211,
161, 163, 165, 166,
167, 168, 268, 298,
C
224, 236, 238, 253, 302, 305, 311, 330 calcular: 120
257, 263-267, 273-277, nivel de autorización: 328 devolución de llamada: 163
282, 289, 294-295, autoridad: 141 cert-manager: 140, 146

298-300, 302, 304, 311, autorización: 140, 157, 168 cgrupos: 9
321-322, 324, 328, 332 auth-url: 168 gráficos: 74-75, 148, 215,
accesibles: 41, 73, escalador automático: 86-87, 91-92, 243-244, 254
88, 146-147, 183 95, 97-98, 100, 111, 123, ID de cliente: 218, 266, 299
acme-v: 157 318, 320, 329, 340 clonado: 49, 86
acrname: 322 escalas automáticas: 91 Cloudapp: 153, 157,
complemento: 142, 147-148 azurecr: 329, 337 163, 165, 167-169
dirección: 16, 31, 40, 46, 60, funciones azules: 207, grupo: 3, 17-18, 21-32,
62, 72, 89, 129, 148-151, 315, 316, 317, 318, 34-35, 40-41, 43,
156, 165, 176, 179-180, 319, 320, 324 46-47, 54, 60, 62,
223, 247-248, 278 monitor azul: 15, 171, 194, 64-65, 67-68, 71-74,
grupo de agentes: 98, 100, 198, 199, 201, 204, 206 76, 78-79, 82, 86-87, 90-91,
243, 259, 283 voto azul: 35, 38, 41, 276 94-101, 109, 111, 113-115,
aks insights: 198, 206 117-118, 120-121,
alertas: 170, 173-174
algoritmo: 7
B 123-125, 133-138, 141,
143, 146-148, 151, 156,
anónimo: 328 backend: 50, 57-58, 158-160, 164, 168-170,
apache: 241-243, 319 61, 64, 145, 153, 157, 173-174, 196, 198-205,
un grupo: 277-278 167-168, 215, 318 208, 211, 213-217,
apiurl: 284 copia de seguridad: 214, 224-225, 219-220, 224-225, 230,
una variante: 35-37, 49, 227, 233-235, 238 235, 238, 242-243,
56-57, 61, 64, 66, 70, equilibrador: 17, 39-40, 249-251, 254-255,
77, 91, 145, 151, 153, 70-72, 105, 111, 148 259-260, 263-266,
156-157, 165-168, 190, bitnami: 77-78, 270-271, 273-276, 278,
192, 276-278, 287, 109, 232, 243 281-283, 289, 294, 296,
290-291, 301, 311, 313 información del libro: 306, 315 299-300, 302-303, 305,
aparecen: 13, 40, 186 interruptores: 7 311, 313, 315, 318-322,
anexos: 25 navegador: 21, 40, 73, 89, 325, 330, 336, 340-341
apppasswd: 299 93, 141, 144, 156, 158, clusterip: 62, 68, 88,
enfoque: 6, 14, 187, 207 169, 183, 186-187, 101, 106, 115, 183
arquitectos: 7 192-193, 224, 246-249, cumplimiento: 214
ataque: 223, 238 279, 324, 329 conducto: 303
confgmap: 57
consola: 23 describir: 52, 55-56, 94, eventos: 56, 103, 132, 136,
cónsul: 303 101, 107-110, 122-123, 173, 176-177, 179-180,
contenedor: 3-4, 9-10, 125-126, 134, 136-137, 182, 236, 241-243, 249,
12-15, 46, 48, 51, 54, 59-60, 155, 174, 177, 180, 254, 257, 260, 320, 330
109, 123-124, 131, 182, 195-197, 199, extensiones: 54, 91, 145,
137, 166, 179-181, 184, 230, 285, 293, 307 153, 157, 165, 167-168
188, 191, 193, 195-196, diseño: 7, 15, 82
200, 206-208, 232-233,
289-290, 292-294, 303,
devops: 5, 7-9, 100
diagnóstico: 120, 123
F
320-322, 326, 329, 340 directorio: 17, 23, 35, facebook: 142, 159-160
controlador: 143-144, 86, 138, 142, 152, 157, facilitar: 21
153, 158, 205, 232 160, 164-165, 218, fallos: 100
vaquero: 10, 12 267-269, 271, 292, conmutación por error: 4, 91, 111
choques: 179 305, 326, 328, 333 fracaso: 113-114, 117, 119,
credencial: 266-267, 299 recuperación de desastres: 123, 130, 132-133,
crítico: 7, 54, 85, 173, 264 212, 222, 232 138, 183, 192, 196
diskuri: 127 filtro: 26, 72, 103
D estibador: 3-6, 9-14, 18,

39, 43, 50-51, 59-60,
filtrado: 103, 208
cortafuegos: 224
conjunto de demonios: 205 109, 166, 179, 182, 284, volumen flexible: 295, 298-302
peligroso: 264 288-289, 293-294, diagrama de flujo: 146
tableros: 304 319-320, 322-324, 326 prohibido: 282

base de datos: 15, 17, 48, 75, dockerfile: 12-13, 326 marco: 7, 188, 307, 319
109-110, 186-187, 208, dockerid: 294 amigo: 242, 256-257
211, 213-215, 220-230, acoplado: 18 frontal: 68, 70-71, 85,
232-233, 235-236, 238, rebajar: 102, 330 89-90, 102-103, 107,
242-243, 247, 249, 295 145-147, 156, 168, 187
databricks: 242
centro de datos: 319
mi funciones: 41, 211, 242, 289,
315, 317-322, 326, 328,
datadoghq: 48 cifrar: 141-144, 147-148, 330, 335, 338, 340-341
interbloqueos: 188 151-152, 154, 156, fqdn: 60, 145, 146, 154
decodificar: 283, 286, 294 167, 170, 304, 307
deleterole: 277-278 hacer cumplir: 307
GRAMO
demanda: 6, 85, 111, 317-318 errores: 123, 135, 170, 174,
despliegue: 4, 7, 18, 22, 25, 35, 181-184, 188, 192, 340 puerta de enlace: 17, 143,
41, 43, 45-49, 55, 60, 62, eventhub: 255 168 gibibyte: 121
65-66, 73-74, 114-115, centros de eventos: 209, 236, gigabyte: 121
135, 173, 191, 216-220, 239, 240, 247, 248, 249,
230, 242-243, 245, 252, 254, 255, 257, 258
254, 260, 275-276, 315,
318-320, 329, 337, 340
github: 9, 35, 49, 75,
86, 93, 114, 142,
I kubectl: 34, 38-41, 49,
52-53, 55-57, 59-63,
148, 153, 159-160, imágenes: 9-10, 12, 48, 65-66, 71, 73, 75-76,
168-169, 215, 243, 295, 54, 103, 182, 283, 78-80, 82, 86-92,
299-300, 303, 319 289, 320-321, 326 94-95, 97-111, 114-116,
gitlab: 9, 142, 160 importación: 297 118, 120-128, 130-138,
google: 4, 9, 14, 21, 64, incubadora: 243 144, 146-148, 151,
100, 142, 147, 159-160, ingreso: 17, 142-149, 154-155, 158, 160,
169, 304, 319 152-154, 156-158, 160, 166-167, 169, 173-177,
googleapis: 75, 164, 166-170, 289, 303 180-184, 187-188,
143, 216, 243 inyectar: 309 190-200, 208, 216,
gopath: 93 inyectado: 152, 307-309, 315 218, 220-221, 223,
gráficos: 257-258 invocación: 294 226, 230-233, 238,
grepping: 110 emisor: 147, 151-154, 244-247, 249, 256-257,
libro de visitas: 46-48, 60, 156-157, 160, 167, 170 259, 276-278, 281-282,
66-68, 70-73, 75, istio: 258, 262, 300, 301, 284-285, 287-289,
82, 86-87, 89-90, 302, 303, 304, 305, 291-295, 299, 302,
97, 101-102, 105, 109, 306, 310, 311, 313 306-308, 310, 312,
114-115, 118-120, 123-124, istioctl: 305, 308-309, 315 314-315, 322, 325,
142, 144-147, 158-160, 329, 336-338, 340
170, 174, 179, 181,
183-185, 187-188, 208
J kubeless: 319
javascript: 7, 333
L
H Jenkins: 9
poner en peligro: 263 linkedin: 142, 160, 241
hackers: 315 jetstack: 148 localhost: 15, 185, 187
handsonaks: 25, 34, 98,
100, 243, 259, 266,
283, 322-325, 329
K METRO
hashicorp: 22 Kanban: 8 manualmente: 14, 51, 74, 86-87,
timonel: 263 keda: 318, 328, 334, 91, 95-97, 100, 111, 136,
alta disponibilidad: 45, 61, 335, 336, 337, 338 138, 153, 207, 286-287
211, 212, 222, 223 kafka: 239, 240, 247, 248, mapeo: 148, 156
hpa: 84, 89, 90, 91, 92, 93, 249, 252, 254, 257, 258 mariadb: 75-78,
109, 318, 336, 337, 338 bóveda de claves: 299, 301 109-110, 133, 213
basado en http: 17 palabra clave: 23 maestro: 17, 31, 48-51,
httpbin: 308, 315 53-54, 57-63, 65, 67,
httpget: 190 75, 77, 124, 185, 234
maxmemory: 54-56, 59
meshpolicy: 311-312
PAG en tiempo real: 242, 250
mundo real: 330
middleware: 318 paquete: 46, 74, 82, redespliegue: 105, 254
monolítico: 241-242 305, 326, 339 sombrero rojo: 166
ruta de montaje: 58, 77, candado: 158 redundancia: 225

190-191, 292, 301 permiso: 265, registro: 10, 12, 180,
varios niveles: 47, 73 267, 270, 282 283-284, 288-289,
volumen persistente: 123 320-322, 329, 337, 340
php-redis: 67, 107-108, 180 réplicas: 50, 52, 68, 94,
norte
pod-id: 59, 62, 122, 184, 234-235, 338
espacio de nombres: 15, 56, 62, 134, 136-137, 307 repositorio: 10, 12, 35, 49,
82, 148, 166, 175, 177, política: 309, 311-314 148, 166, 168, 180, 243
179, 181, 198, 216, 218, políglota: 7 reprogramar: 120
244-245, 251, 265, Powershell: 22, 32 investigación: 141
275, 277-278, 282-284, sondas: 173, 176, 188-189, recurso: 15, 22, 24-25,
306-309, 311, 313 192, 194, 196 30, 87, 91, 107,
navegar: 21, 35, 41, apoderados: 60, 65 136-137, 174, 200, 216,
86, 88, 106, 115, 187, público: 3-4, 10, 12, 39-40, 238, 243, 251, 274,
231-232, 243, 326 70-73, 88-89, 102, 283-284, 287, 332
red: 6, 15, 17, 60, 73, 105-106, 115-116, 127, recursos: 15, 17, 22,
75-76, 186, 222, 230, 143, 147-149, 151, 159, 36-37, 39, 41, 50-51,
242-243, 246-247, 183, 185, 238, 247, 58, 63-64, 67, 72-73,
249, 254, 257, 260, 318-319, 323, 329 77, 85, 94-95, 97-101,
302-303, 312 empujador: 160, 165, 169 107, 114, 120-123, 135,
neo4j: 240, 241, pvc: 74, 76, 77, 128, 131 138, 152, 154, 159,
245, 246, 247 pitón: 7, 326-327, 339 169, 174-176, 179-180,
nginx-: 190 196-198, 213, 215, 235,
grupo de nodos: 98, 100,
243, 259, 266, 283
Q 254, 264-265, 276-277,
283, 295, 315, 320, 337
puerto de nodo: 69-70 consultas: 207, 235 reiniciar: 33, 138, 188,
nslookup: 62 195-196, 219, 232
R restaurar: 194, 225-229,
O rbac: 15, 157, 216, 258,

233-234, 238
volver: 32, 60, 62, 80,
oauth-: 169 261, 262, 263, 264, 92, 155, 194, 284
openssl: 266, 289 268, 276, 277, 278, tiempo de ejecución: 9-10, 14,
orquestación: 1, 2, 12 279, 281, 292, 313 293-294, 322, 329

rakyll: 93
solo lectura: 276-277,
292, 301
S sprints: 8
ssh-keygen: 322
Y
sas: 330 estático: 46, 69, 74, 95 tu-nombre: 288
escalable: 4, 6, 43, 85, interruptor: 156, 254, su-contraseña: 288
250 escalado: 99 285, 338-339
reducción de escala: 94, 97
Z
escala: 4, 16, 31, 43, 47,
82, 85-87, 89-98, 115,
T cuidador del zoológico: 243
121, 123, 184, 214, 216, plantilla: 22, 36-37,

238, 266, 318, 320, 50, 57, 64, 67, 79,
330, 337, 339-340 107-108, 165
guión: 22, 107, 193, 266, inquilino: 165, 217-218, 301
269, 309, 312, 339 inquilino: 218, 266,
secreto: 54, 109, 128, 154, 270, 301
162, 164-165, 218, terraform: 22
226, 230-232, 255, rendimiento: 251, 258
260, 267, 283-295, miniatura: 318
297-302, 329, 340 caña del timón: 74
servidor: 3, 5, 10, 31, 61-62, tiempo de espera: 136
109, 141, 151-152,

156-157, 180, 185-187,
189-196, 222, 229,
U
231-232, 234-238, ubuntu: 323, 326
267, 269, 289, 295 corriente arriba: 165
sin servidor: 211, 289, utilidad: 219

315, 317-319, 340
funciones sin servidor:
315, 316, 338
V
registro del servidor: 233, validar: 28
234, 235, 236 valioso: 236
malla de servicio: 261, 262, vmware: 4
300, 301, 302, 304, 306 reglas de vnet: 220, 221
set-policy: 299
cierre: 118, 122
sidecar: 15, 142, 303-304,
W
306-309, 312, 314 advertencia: 144, 244, 312, 325
esclavos: 62-63 whalesay: 10, 12
fuente: 3, 5, 12, 57, comodín: 310, 313
115, 145, 151, 153, trabajado: 90, 187, 291
158-159, 164, 167, wp-config: 231-232
170, 299, 306, 328 wp-mariadb: 109
envoltorio: 50

Kubernetes in Azure

Cargado por

Información del documento

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Kubernetes in Azure

Cargado por

Copyright:

Formatos disponibles

Práctica Kubernetes

Nills Franssens, Shivakumar Gopalakrishnan y Gunther Lenz

Derechos de autor © 2020 Packt Publishing

Se ha hecho todo lo posible en la preparación de este libro para asegurar la exactitud de la

Autores: Nills Franssens, Shivakumar Gopalakrishnan y Gunther Lenz

Revisores técnicos: Peter De Tender y Suleyman Akbas Editores en jefe:

Afzal Shaikh y Priyanka Sawant

Editor de adquisiciones: Rahul Hande

Editor de producción: Deepak Chavan

Consejo editorial: Ben Renow-Clarke e Ian Hough Primera

publicación: marzo de 2019

Segunda publicación: marzo de 2020

Referencia de producción: 1190320

Publicado por Packt Publishing Ltd. Livery

Place, 35 Livery Street Birmingham B3

2PB, Reino Unido

Para Kelly. No sería la persona que soy hoy sin ti.

Para Okson y Hugo.

Para todos los que lean esto.

Cree una cuenta gratuita y comience a utilizar

Luego, pruebe estos laboratorios para dominar las tareas

Sección 1: Conceptos básicos 1

Capítulo 1: Introducción a Docker y Kubernetes 3

La evolución del software que nos trajo aquí ........................................... ......... 5

DevOps ................................................. .................................................. ......................... 8

Fundamentos de los contenedores Docker .............................................. ...................... 9

Imágenes de Docker ................................................ .................................................. ............ 10

Kubernetes como plataforma de orquestación de contenedores ... 14

Implementaciones en Kubernetes ............................................... ........................................ dieciséis

Servicios en Kubernetes ............................................... ................................................. dieciséis

Servicio Azure Kubernetes ............................................... ..................................... 17

Capítulo 2: Kubernetes en Azure (AKS) 21

Diferentes formas de implementar un clúster de AKS ........................................... ................. 22

Introducción a Azure Portal ............................................ .................... 23

Una descripción general rápida de su clúster en Azure Portal ........................................ ...... 30

Accediendo a su clúster usando Azure Cloud Shell ........................................... ............ 32

Implementando su primera aplicación de demostración ............................................. ......................... 35

Resumen ................................................. .................................................. ............. 41

Capítulo 3: Implementación de aplicaciones en AKS 45

Implementación de la aplicación de muestra del libro de visitas ............................................. ...... 47

Presentación de la aplicación ............................................... ......................................... 47

Implementación del maestro de Redis .............................................. ......................................... 48

Maestro de Redis con un ConfigMap ............................................. .................................... 54

Implementación completa de la aplicación del libro de visitas de muestra ............... 60

Exponiendo el servicio maestro de Redis ............................................. ............................... 60

Despliegue de los esclavos de Redis .............................................. ........................................... 63

Implementar y exponer el front-end ............................................ .......................... 66

La aplicación del libro de visitas en acción ............................................. ............................ 73

Instalación de aplicaciones complejas de Kubernetes con Helm ................................. 74

Instalando WordPress usando Helm .............................................. ................................. 75

Resumen ................................................. .................................................. ............. 82

Capítulo 4: Creación de aplicaciones escalables 85

Escalando su aplicación ............................................... ........................................ 87

Escalar el componente frontal del libro de visitas ........................................... ................ 90

Uso de HPA ............................................... .................................................. .............. 91

Escalando su clúster ............................................... ............................................... 95

Escalar su clúster con el escalador automático del clúster ........................................... ......... 97

Actualizar una aplicación usando kubectl edit ............................................ ............ 105

Actualizar una aplicación usando el parche kubectl ............................................ ......... 107

Actualización de aplicaciones usando Helm .............................................. ......................... 109

Resumen ................................................. .................................................. ........... 111

Capítulo 5: Manejo de fallas comunes en AKS 113

Manejo de fallas de nodos ............................................... ........................................ 114

Resolver fallas por falta de recursos ........................................... ............................. 120