Módulo 2
Introducción a Contenedores y Kubernetes
2-2 Importancia
Antes de usar las características y capacidades de vSphere with Tanzu, es importante comprender las
construcciones de contenedores y Kubernetes.
2-3 lecciones del módulo
1. Introducción a los Contenedores
2. Introducción a Kubernetes
2-4 Lección 1: Introducción a los contenedores
2-5 objetivos de aprendizaje
Después de completar esta lección, debería poder cumplir con los siguientes objetivos:
• Diferenciar entre contenedores y máquinas virtuales
• Identificar las partes de un sistema de contenedores
• Reconocer los pasos en un flujo de trabajo básico de Docker
2-6 máquinas virtuales y contenedores (1)
Cada máquina virtual proporciona hardware virtual que el sistema operativo invitado utiliza para
ejecutar aplicaciones. Múltiples aplicaciones se ejecutan en un solo servidor físico sin dejar de estar
lógicamente separadas y aisladas.
Con los contenedores, los desarrolladores toman un sistema de archivos del sistema operativo base
simplificado y se superponen solo en los archivos binarios y bibliotecas necesarios de los que depende
la aplicación.
Con la virtualización, varias máquinas físicas se pueden consolidar en una sola máquina física que
ejecuta varias máquinas virtuales. Cada máquina virtual proporciona hardware virtual que el sistema
operativo invitado utiliza para ejecutar aplicaciones. Múltiples aplicaciones se ejecutan en un solo
servicio físico sin dejar de estar lógicamente separadas y aisladas.
Una preocupación sobre las máquinas virtuales es que, por lo general, tienen un tamaño de cientos de
megabytes a gigabytes y contienen muchos archivos binarios y bibliotecas que no son relevantes para
la aplicación principal que se ejecuta en ellas.
Con los contenedores, los desarrolladores toman un sistema de archivos del sistema operativo base
simplificado y se superponen solo en los archivos binarios y bibliotecas necesarios de los que depende
la aplicación. Cuando un contenedor se ejecuta como un proceso en el sistema operativo host del
contenedor, el contenedor puede ver sus dependencias y paquetes de sistema operativo base.
Además, el contenedor está aislado de todos los demás procesos en el sistema operativo del host del
contenedor. Los procesos contenedores son los únicos procesos que se ejecutan en un sistema mínimo.
Desde la perspectiva del sistema operativo del host del contenedor, el contenedor es solo otro proceso
que se está ejecutando, pero con una vista restringida del sistema de archivos y CPU y memoria
potencialmente restringidas.
2-7 Máquinas Virtuales y Contenedores (2)
Compara las características de las máquinas virtuales y los contenedores.
Los contenedores son la tecnología ideal para los microservicios porque los objetivos de los
contenedores (ligeros, empaquetados fácilmente, pueden ejecutarse en cualquier lugar) se alinean con
los objetivos y beneficios de la arquitectura de microservicios.
Los operadores obtienen componentes de aplicaciones modulares que son pequeños y pueden adaptarse
a los recursos existentes.
Los desarrolladores pueden concentrarse en la lógica de los componentes de aplicaciones modulares,
sabiendo que la infraestructura es confiable y admite la escalabilidad de los módulos.
2-8 Acerca de los hosts de contenedores
Los hosts de contenedores pueden ser de los siguientes tipos:
• Sistema operativo estándar con un motor de contenedor instalado:
— Ubuntu con Docker
• SO desarrollado específicamente con contenedores en mente:
— Photon
— CoreOS
• Máquina virtual o máquina física:
— El uso de máquinas virtuales tiene muchos beneficios, como una fácil administración y
escalabilidad.
Operations proporciona hosts de contenedores como la estructura base que los desarrolladores usan
para ejecutar sus contenedores. Un sistema de microservicios robusto incluye más entregables, muchos
de los cuales se construyen usando contenedores.
Para que los desarrolladores se centren en brindar servicios a los clientes, las operaciones deben
proporcionar una infraestructura de host de contenedores confiable. Por ejemplo, en vSphere, las
operaciones proporcionan vApps inmutables. La confiabilidad de las operaciones aumenta con
herramientas de orquestación automatizadas.
Actualmente, los contenedores de Microsoft Windows no son compatibles con los clústeres de vSphere
with Tanzu y Tanzu Kubernetes.
2-9 Ejemplo de flujo de trabajo de contenedores
Un flujo de trabajo de contenedor sigue estos pasos:
1. Cree una imagen a partir del código fuente y las dependencias.
2. Envíe la imagen al registro de imágenes.
3. Tome la imagen del registro de imágenes.
4. Ejecute la imagen como contenedor.
En el flujo de trabajo de ejemplo, se crea una imagen a partir de archivos de código fuente y otras
dependencias. Un contenedor se puede almacenar en un registro y la imagen se puede enviar a un host
de contenedor donde se usa para generar contenedores.
Con este tipo de flujo de trabajo, los desarrolladores escriben el código una vez. El código funciona en
muchos entornos diferentes.
En Dockerfile, una especificación clave es el nombre de la imagen base del sistema operativo que se
requiere para el contenedor. Un contenedor se puede implementar solo en hosts que ejecutan el sistema
operativo que coincide con el especificado en el Dockerfile.
2-10 Acerca de los motores de contenedores
Un motor de contenedor es un plano de control que se instala en cada host de contenedor. El plano de
control administra los contenedores en ese host. Los motores de contenedores realizan las siguientes
funciones:
• Cree imágenes de contenedores a partir del código fuente (por ejemplo, Dockerfile).
Alternativamente, cargue imágenes de contenedores desde un repositorio.
• Cree contenedores en ejecución basados en una imagen de contenedor.
• Asignar un contenedor en ejecución a una imagen.
• Guardar una imagen y enviarla a un repositorio.
• Detenga y retire los contenedores.
• Suspender y reiniciar contenedores.
• Informar sobre el estado del contenedor. Docker es el motor de contenedores más utilizado.
El motor del contenedor se ejecuta como un proceso daemon en el sistema operativo del host del
contenedor. Cuando un usuario solicita que se ejecute un contenedor, el motor del contenedor obtiene la
imagen del contenedor de un registro de imágenes (o localmente si ya se ha descargado) y ejecuta el
contenedor como un proceso.
2-11 Acerca de Dockerfile
Dockerfile es un archivo de texto sin formato que declara cómo crear una imagen.
Dockerfile es similar al código fuente de una imagen.
Puede usar el comando BUILD para crear una imagen desde Dockerfile Sample Dockerfile:
2-12 imágenes de contenedores
Las imágenes de contenedores son comparables a una plantilla de máquina virtual. Tienen las
siguientes características:
• Las imágenes de contenedores contienen el código de la aplicación y las dependencias de la
aplicación.
• Las imágenes de contenedor se construyen utilizando un sistema de archivos en capas y pueden
constar de una o más capas.
• Las imágenes de Docker se construyen usando un Dockerfile, y cada línea en un Dockerfile
representa una capa en una imagen de contenedor.
Docker utiliza un sistema de archivos de unión para combinar múltiples capas de una imagen en una
sola imagen. Estas capas (también denominadas imágenes intermedias) se generan cuando los
comandos del Dockerfile se ejecutan durante la compilación de la imagen de Docker.
Las imágenes intermedias se superponen para formar un nuevo directorio de archivos único y coherente
que constituye la imagen en el host del contenedor.
Para analizar una imagen de Docker, ejecute estos comandos:
• inspección de imagen acoplable
• historial de imágenes de la ventana acoplable
DIVE es una herramienta de terceros para explorar una imagen Docker y su contenido de capa y para
encontrar formas de reducir el tamaño de su imagen Docker u OCI.
2-13 Registro de imágenes
Las imágenes de contenedores se almacenan en un registro de imágenes central:
• El registro de imágenes mantiene múltiples versiones de imágenes de contenedores.
• Los motores de contenedores pueden tomar imágenes de un registro de imágenes para ejecutarlas.
• Docker Hub es el registro público más utilizado.
Harbour es un registro que se puede instalar en las instalaciones. Proporciona las siguientes
características:
• Firma de imágenes
• Escaneo de vulnerabilidades
Operations admite Harbor, un registro de imágenes, para garantizar la seguridad de los contenedores en
nubes públicas y privadas.
Para obtener más información sobre la biblioteca Docker Hub para imágenes de contenedores, consulte
[Link]
[Link] obtener más información sobre el proyecto del servidor de registro Harbor,
consulte [Link]
La versión integrada de Harbour integrada con vSphere with Tanzu no es compatible con todas las
funciones de Harbour independiente.
2-14 laboratorios
Laboratorio: Verificación de Docker en la estación de trabajo del desarrollador
Laboratorio: ejecución de una imagen de contenedor
Laboratorio: creación de una imagen de contenedor personalizada
2-15 Laboratorio 1: Verificación de Docker en la estación de trabajo del desarrollador
Conéctese a la estación de trabajo del desarrollador y verifique que Docker se esté ejecutando:
1. Conéctese a la máquina virtual de la estación de trabajo del desarrollador
2. Inicie la ventana acoplable
3. Inspeccione el entorno de vSphere
4. Inspeccione el entorno del centro de datos de NSX-T
2-16 Laboratorio 2: Ejecución de una imagen de contenedor
Extraiga, ejecute y detenga una imagen de contenedor:
1. Conéctese a la máquina virtual de la estación de trabajo del desarrollador
2. Tire de una imagen de contenedor
3. Ejecute una imagen de contenedor
4. Detener un contenedor en ejecución
2-17 Laboratorio 3: Creación de una imagen de contenedor personalizada
Use un Dockerfile para crear una imagen de contenedor personalizada:
1. Conéctese a la máquina virtual de la estación de trabajo del desarrollador
2. Inspeccione el Dockerfile
3. Usa el Dockerfile para construir una imagen
4. Use la imagen recién creada para ejecutar un contenedor
2-18 Revisión de los objetivos del alumno
Después de completar esta lección, debería poder cumplir con los siguientes objetivos:
• Diferenciar entre contenedores y máquinas virtuales
•Identificar las partes de un sistema de contenedores
• Reconocer los pasos en un flujo de trabajo básico de Docker
2-19 Lección 2: Introducción a Kubernetes
2-20 objetivos de aprendizaje
Después de completar esta lección, debería poder cumplir con los siguientes objetivos:
• Explicar la importancia de Kubernetes
• Reconocer la arquitectura básica de Kubernetes
• Describir un flujo de trabajo básico de Kubernetes
2-21 Problemas resueltos por Kubernetes
Con Docker, los contenedores se administran en un solo host de contenedor. La gestión de varios
contenedores en varios hosts de contenedores crea muchos problemas:
• Gestión de grandes cantidades de contenedores
• Reinicio de contenedores fallidos
• Contenedores a escala para cumplir con la capacidad
• Redes y equilibrio de carga
Kubernetes proporciona una capa de orquestación para resolver estos problemas.
Anteriormente, las operaciones proporcionaban conjuntos de máquinas virtuales para admitir
aplicaciones. Ahora, Operations proporciona un conjunto dinámico de hosts de contenedores que
admiten una gran arquitectura de servicios en contenedores.
Proporcionar un conjunto de hosts de contenedores agrega complejidad al soporte operativo, lo que
requiere soluciones que automaticen la entrega de los requisitos operativos. Cada aplicación es ahora
un conjunto de contenedores.
2-22 Arquitectura de Kubernetes
La arquitectura de Kubernetes tiene varios componentes.
La arquitectura de Kubernetes incluye los siguientes componentes:
• kubectl: la interfaz de línea de comandos (CLI) para la API de Kubernetes
• Máquina virtual del plano de control de Kubernetes:
— Servidor API: El punto de entrada a la plataforma Kubernetes
— etcd: El almacén de datos clave/valor utilizado para almacenar la configuración y el estado actual
del sistema
— Administrador de controladores: Ejecuta varios controladores que observan la API en busca de
cambios y toma las medidas apropiadas
— Programador: Equilibra los pods en los nodos
• Máquina virtual del nodo de Kubernetes:
— kubelet: Observa la API para el trabajo asignado a ella
— kube-proxy: Configura las reglas de red para enrutar el tráfico a los contenedores
— Docker: Ejecuta pods cuando lo solicita kubelet
El valor de Kubernetes es que automatiza muchas responsabilidades operativas clave, proporcionando
al desarrollador un entorno confiable.
Cada componente arquitectónico se enfoca en una tarea, aumentando el uso de recursos, la
confiabilidad y la consistencia.
Docker no es el único motor de ejecución de contenedores. CRI-O y containerd son otros tiempos de
ejecución.
2-23 Acerca de los manifiestos
En Kubernetes, los archivos de manifiesto declaran el estado deseado de los objetos. Los manifiestos
tienen las siguientes propiedades:
• Formato YAML
• Configuración declarativa
• Primitivos de API deseados
Kubernetes gestiona la creación de las primitivas solicitadas.
Los archivos de manifiesto son el nuevo lenguaje compartido entre el desarrollador y el operador.
Actúan como la única fuente de verdad para la configuración de un conjunto de componentes de
aplicación (contenedores).
Para obtener más información sobre YAML, consulte Otro lenguaje de marcado más en
[Link]
2-24 Acerca de los Pods (1)
Un pod es un conjunto de uno o más contenedores estrechamente acoplados. Es la unidad de trabajo
más pequeña de Kubernetes.
Los contenedores en un pod comienzan y terminan juntos.
Ejemplo: ejecutar un pod.
• El nombre del pod es nginx-demo.
• Al pod se le asigna una etiqueta.
•Ejecuta image nginx con la versión 1.7.9.
•Debería escuchar en el puerto 80.
Para obtener más información sobre los pods de Kubernetes, consulte
[Link]
La arquitectura de Kubernetes tiene muchos objetos y otras primitivas conceptuales. Este tema es una
descripción general de algunos objetos y primitivos fundamentales.
2-25 Acerca de los Pods (2)
Los pods se ejecutan dentro de los nodos de trabajo de Kubernetes y pueden ejecutar uno o más
procesos de contenedor.
2-26 Acerca de los conjuntos de réplicas (1)
Un ReplicaSet declara cómo la funcionalidad de un pod se vuelve escalable y resistente a través de la
redundancia.
El ReplicaSet garantiza que se mantenga en ejecución una cantidad específica de pods.
Ejemplo: implementar un ReplicaSet.
• El nombre de ReplicaSet es nginx-replica-demo.
• Se espera que se estén ejecutando dos réplicas.
• El ReplicaSet se aplica a los pods con la etiqueta nginx.
Para obtener más información sobre los conjuntos de réplicas de Kubernetes, consulte
[Link]
2-27 Acerca de los conjuntos de réplicas (2)
Los ReplicaSets crean y mantienen copias de un pod. Los pods de réplica se pueden ejecutar en el
mismo nodo de Kubernetes o en varios nodos.
2-28 Acerca de las implementaciones (1)
Una implementación es la primitiva más utilizada:
• Declara si los pods se pueden actualizar y si se pueden parchear sin interrumpir los servicios.
• Proporciona actualizaciones continuas mediante la creación de conjuntos de réplicas y la destrucción
de conjuntos de réplicas antiguos.
• Permite implementar una nueva versión de una imagen sin tiempo de inactividad
Ejemplo: implementar una implementación.
• El nombre de la implementación es nginx.
• Se espera que se ejecuten tres réplicas.
• La implementación ejecuta image nginx con la versión 1.7.9.
For more information about Kubernetes deployments, see
[Link]
2-29 Acerca de las implementaciones (2)
Las implementaciones se usan comúnmente para combinar declaraciones de pod y ReplicaSet en un
solo manifiesto.
2-30 Acerca de los servicios (1)
Un servicio describe cómo los pods descubren y se comunican entre sí y con redes externas.
Un servicio expone los pods como una única dirección IP.
Ejemplo: implementar un servicio.
• El nombre del servicio es nginx-service.
• Es un servicio de LoadBalancer.
• Debería escuchar en el puerto 80.
Una dirección IP de servicio se expone a través de uno de estos ServiceTypes:
• ClusterIP: expone el servicio en una dirección IP interna del clúster • NodePort: expone el servicio
externamente como un puerto estático
• LoadBalancer: Expone el servicio externamente usando el balanceador de carga de un proveedor de
nube
• ExternalName: asigna el servicio a un registro CNAME
Para obtener más información sobre los servicios de Kubernetes, consulte
[Link]
2-31 Acerca de los servicios (2)
Los servicios, como los servicios de balanceador de carga, pueden exponer pods con una dirección IP
externa estática.
2-32 Acerca de las políticas de red
Una política de red es una especificación de cómo se permite que los grupos de pods se comuniquen
entre sí y con otros puntos finales de la red.
Las políticas de red declaran reglas para el tráfico de entrada y salida.
Ejemplo: implementar una política de red.
• El nombre de la política es política de red.
• La política permite todo el tráfico de entrada desde [Link]/24.
• Permite todo el tráfico de salida a [Link]/8.
• Se aplica a los pods con la etiqueta de aplicación nginx
2-33 Acerca de los espacios de nombres
Los espacios de nombres proporcionan un límite de recursos y autorización para los objetos de
Kubernetes. Los espacios de nombres pueden abarcar los nodos de Kubernetes.
2-34 Ejemplo de flujo de trabajo de Kubernetes
Pasos de flujo de trabajo de ejemplo:
1. Cree una imagen a partir del código fuente y las dependencias.
2. Envíe la imagen al registro de imágenes.
3. Dígale a Kubernetes que use la imagen para ejecutar un pod.
4. El programador asigna el pod a un nodo.
5. Kubelet acepta el pod.
6. Docker toma la imagen del registro de imágenes.
7. Docker inicia el proceso del contenedor dentro de un pod.
El flujo de trabajo de ejemplo muestra cómo un desarrollador puede usar Docker para crear una imagen
localmente, almacenar la imagen en un registro y usar Kubernetes para administrar la ejecución del
contenedor.
La intención operativa es proteger los contenedores, mantener la comunicación entre los pods y
garantizar que se ejecute todo el código de las imágenes.
El contenedor es administrado por los requisitos específicos de Kubernetes en el manifiesto para
mantener una aplicación robusta, resistente y escalable por parte del kubelet del trabajador. El
contenedor también se gestiona según los requisitos del manifiesto en maestro, etc. Con estos detalles,
los equipos de desarrolladores y operadores pueden trabajar juntos para declarar lo que se necesita y, en
el proceso, satisfacer las necesidades de los clientes.
Kubernetes admite un proceso rápido, dinámico y continuo para satisfacer las necesidades de los
clientes.
2-35 Revisión de los objetivos del alumno
Después de completar esta lección, debería poder cumplir con los siguientes objetivos:
• Explicar la importancia de Kubernetes
• Reconocer la arquitectura básica de Kubernetes
• Describir un flujo de trabajo básico de Kubernetes
2-36 puntos clave
• Un contenedor es la encapsulación de una aplicación y archivos binarios o bibliotecas dependientes.
• Una imagen de contenedor es ejecutada por un sistema operativo de host de contenedor mediante un
motor de contenedor como Docker.
• Kubernetes es una capa de orquestación y gestión para contenedores.
¿Preguntas?
Módulo 3
Introducción a vSphere con Tanzu
3-2 Importancia
Desarrollar una comprensión de los conceptos y la arquitectura de vSphere with Tanzu y
las redes de NSX-T Data Center puede ayudarlo a proporcionar funcionalidad de red a
vSphere with Tanzu.
3-3 lecciones del módulo
1. Introducción a vSphere with Tanzu 2. Introducción a NSX-T Data Center for vSphere
with Tanzu 3. Interfaz de línea de comandos de Kubernetes kubectl
3-4 Lección 1: Descripción general de vSphere with Tanzu
3-5 objetivos de aprendizaje
Después de completar esta lección, debería poder cumplir con los siguientes objetivos:
• Describir el propósito de vSphere with Tanzu y cómo encaja en la cartera de VMware
Tanzu
• Identificar las capacidades de vSphere with Tanzu
• Reconocer los beneficios clave de vSphere with Tanzu
• Describir el clúster supervisor de vSphere with Tanzu
• Identificar los componentes que componen vSphere with Tanzu Supervisor Cluster
• Describir el servicio Grid de Tanzu Kubernetes
3-6 Acerca de Cloud Native Computing Foundation (1)
La Cloud Native Computing Foundation (CNCF) es parte de la Linux Foundation. Puede encontrar más
información sobre CNCF en [Link]
Cloud Native Computing Foundation (CNCF) aloja componentes críticos de la infraestructura
tecnológica global. CNCF reúne a los principales desarrolladores, usuarios finales y proveedores del
mundo y organiza las conferencias de desarrolladores de código abierto más grandes.
3-7 Acerca de Cloud Native Computing Foundation (2)
VMware es miembro de Cloud Native Computing Foundation (CNCF) y contribuye a varios proyectos
en todo el panorama de CNCF.
3-8 Acerca de vSphere con Tanzu
vSphere with Tanzu transforma vSphere en una plataforma nativa de Kubernetes
Un clúster habilitado con vSphere with Tanzu se denomina clúster supervisor.
En una implementación de VMware Cloud Foundation, el clúster supervisor se ejecuta sobre una capa
de SDDC que incluye los siguientes elementos:
• ESXi para cómputo
• Centro de datos NSX-T para redes
• vSAN u otra solución de almacenamiento compartido como almacenamiento compartido para pods de
vSphere, clústeres de Tanzu Kubernetes y máquinas virtuales que se ejecutan dentro del clúster
supervisor
Después de crear un Clúster supervisor, puede crear espacios de nombres en el Clúster supervisor que
se denominan Espacios de nombres de supervisor.
Los ingenieros de DevOps pueden ejecutar cargas de trabajo que consisten en contenedores que se
ejecutan dentro de vSphere Pods. También pueden crear clústeres de Kubernetes ascendentes mediante
el servicio Tanzu Kubernetes Grid.
3-9 vSphere con Tanzu y VMware Tanzu (1)
3-10 vSphere con Tanzu y VMware Tanzu (2)
vSphere with Tanzu integra e incorpora Kubernetes directamente en vSphere y es la base de la cartera
de VMware Tanzu para ejecutar Kubernetes:
• Une vSphere y Kubernetes
• Amplía vSphere para todas las aplicaciones modernas
• Admite la colaboración entre el desarrollo y las operaciones de TI (DevOps)
Construir
• Bitnami: sistema de gestión de paquetes para aplicaciones web, pilas de soluciones y máquinas
virtuales
• Pivotal: desarrollo de aplicaciones nativas en la nube
Correr
• vSphere with Tanzu: ejecuta cargas de trabajo de Kubernetes de forma nativa en vSphere. Habilita el
autoaprovisionamiento de clústeres de Tanzu Kubernetes que se ejecutan en vSphere with Tanzu.
• Tanzu Kubernetes Grid: oferta independiente que se puede aprovisionar en vSphere 6.7 U3 y
versiones posteriores y en Amazon Web Services.
• Tanzu Kubernetes Integrated Edition: solución de contenedor basada en Kubernetes con redes
avanzadas, un registro de contenedor privado y administración del ciclo de vida (anteriormente
conocido como VMware Enterprise PKS).
Administrar
• Tanzu Mission Control: administra múltiples clústeres de Tanzu Kubernetes desde una sola vista, sin
importar dónde se estén ejecutando los clústeres de Tanzu Kubernetes Grid (vSphere, AWS y más).
3-11 VMware Cloud Foundation con Tanzu
VMware Cloud Foundation con Tanzu es la mejor manera de ejecutar cargas de trabajo de Kubernetes a
escala.
Los servicios de infraestructura híbrida son los siguientes:
• vSphere Pod Service: los desarrolladores pueden ejecutar contenedores de forma nativa y segura en
vSphere sin administrar VM o clústeres de Kubernetes.
• Servicio de red: los desarrolladores pueden definir enrutadores virtuales, balanceadores de carga y
reglas de firewall para usar con su aplicación.
• Servicio de registro: los desarrolladores pueden almacenar y administrar imágenes Docker y OCI
mediante Harbor. Harbor es un registro de imágenes de contenedor de código abierto que protege las
imágenes con control de acceso basado en funciones.
• Servicio de almacenamiento: las políticas y los dispositivos de almacenamiento de vCenter Server
pueden consumirse como clases de almacenamiento de Kubernetes y usarse como discos persistentes
con contenedores, clústeres de Kubernetes y máquinas virtuales.
Los servicios de tiempo de ejecución de VMware Tanzu incluyen Tanzu Kubernetes Grid Service. Con
este servicio, los desarrolladores pueden administrar clústeres de Kubernetes consistentes, compatibles
y conformes, que son clústeres de Tanzu Kubernetes.
3-12 vSphere 7 con Tanzu
vSphere 7 with Tanzu es la forma más rápida de comenzar con las cargas de trabajo de Kubernetes.
Los servicios de infraestructura son los siguientes:
• Servicio de red: puede usar balanceadores de carga de terceros para crear servidores virtuales para
cargas de trabajo.
• Servicio de almacenamiento: se admite cualquier almacenamiento compatible con vSphere.
Los servicios de tiempo de ejecución de VMware Tanzu incluyen Tanzu Kubernetes Grid Service. Con
este servicio, los desarrolladores pueden administrar clústeres de Kubernetes consistentes, compatibles
y conformes, que son clústeres de Tanzu Kubernetes.
3-13 Comparación de configuraciones de implementación de vSphere con Tanzu
A partir de vSphere 7 Update 1, vSphere with Tanzu se puede implementar mediante NSX-T Data
Center o mediante vSphere Distributed Switches.
vSphere con Tanzu en NSX-T Data Center:
• Redes y seguridad del centro de datos NSX-T
• Servicio de red Tanzu Kubernetes
• Servicio de pods de vSphere
• Servicio de red
• Servicio de Almacenamiento
• Servicio de Registro
vSphere con Tanzu en vSphere Distributed Switch:
• Conmutador distribuido de vSphere
• Servicio de red Tanzu Kubernetes
• Servicio de red (compatibilidad con balanceador de carga externo)
• Servicio de Almacenamiento
La funcionalidad de vSphere with Tanzu depende de la infraestructura de red virtual que se utilice.
vSphere with Tanzu en vSphere Distributed Switch no es compatible con los pods de vSphere ni con el
registro Harbor integrado. Se pueden utilizar registros independientes de puertos u otros registros de
contenedores.
3-14 Acerca de las máquinas virtuales del plano de control (1)
Las máquinas virtuales del plano de control son equivalentes a los nodos del plano de control de
Kubernetes. Estas máquinas virtuales del plano de control se crean y ejecutan en los hosts que forman
parte del clúster supervisor:
• ESX Agent Manager (EAM) administra la implementación de las máquinas virtuales del plano de
control.
• DRS determina la ubicación de estas máquinas virtuales y las migra cuando es necesario.
• Las reglas de antiafinidad de VM se crean automáticamente para las VM del plano de control.
Las máquinas virtuales del plano de control proporcionan la interfaz de desarrollo y administración
para el clúster supervisor:
• Un punto final de API
• Servicios de infraestructura y pods para el Supervisor Cluster
• Gestión del ciclo de vida de las máquinas virtuales del plano de control
La antiafinidad de las máquinas virtuales del plano de control se realiza mediante un nuevo método
similar a las políticas informáticas en VMware Cloud on AWS. Este método no está disponible en
vSphere Client. La antiafinidad del plano de control no aparece en los ajustes de configuración de
vSphere DRS.
3-15 Acerca de las máquinas virtuales del plano de control (2)
Las máquinas virtuales del plano de control ejecutan servicios de infraestructura y pods para el clúster
supervisor, de forma similar a los nodos del plano de control de Kubernetes.
3-16 Redes del plano de control
Las máquinas virtuales del plano de control usan redes de administración, corporativas y de clúster:
• Se accede a la administración de vSphere Client desde la red de administración mediante una IP
flotante.
• La comunicación etcd entre cada VM del plano de control utiliza la red de gestión.
• Los desarrolladores acceden a la infraestructura mediante una IP virtual.
• El plano de control se comunica con los pods mediante una red de clúster.
La IP flotante sigue al líder etcd, lo que garantiza que, en la partición, el tráfico se enruta a la parte
funcional del clúster.
La IP flotante no siempre se asigna. Durante la elección de un líder, o durante la pérdida del quórum de
etcd, ningún plano de control posee la IP flotante, y vCenter Server Appliance y Spherelets (ESX) no
pueden conectarse al servidor ap.
Todos los componentes vuelven a intentar sus conexiones indefinidamente y reanudan la función
normal cuando el clúster etcd recupera el quórum.
3-17 Acerca de los clústeres supervisores (1)
El clúster supervisor incluye un conjunto de máquinas virtuales de plano de control que brindan acceso
API al clúster supervisor.
La máquina virtual del plano de control sirve como punto final para que los usuarios de Kubernetes
administren sus espacios de nombres mediante la conocida interfaz de línea de comandos de kubectl.
3-18 Acerca de los clústeres supervisores (2)
En vSphere with Tanzu, un clúster supervisor es un clúster especial de Kubernetes que usa ESXi como
nodos trabajadores en lugar de Linux.
En un clúster supervisor, cada host ESXi ejecuta una instancia de Spherelet, que es una implementación
especial de kubelet, directamente en ESXi y no como una VM.
3-19 Acerca de Spherelet
Spherelet es un kubelet que se adapta de forma nativa a ESXi. Permite que el host ESXi se convierta en
parte de un clúster de Kubernetes. Spherelet realiza las siguientes funciones:
• Se comunica con las máquinas virtuales del plano de control
• Administra la configuración de nodos
• Inicia los pods de vSphere • Supervisa los pods de vSphere
3-20 Acerca de CRX
Container Runtime Executive (CRX) está integrado en ESXi. Tiene las siguientes propiedades:
• Núcleo de Linux Photon paravirtualizado
• Misma virtualización de hardware, límites y aislamiento que las máquinas virtuales
Container Runtime Executive (CRX) es similar a una VM desde la perspectiva de hostd y vCenter
Server. CRX incluye un kernel de Linux altamente paravirtualizado que funciona con el hipervisor.
CRX utiliza las mismas técnicas de virtualización de hardware que las máquinas virtuales y tiene un
límite de máquina virtual a su alrededor.
CRX utiliza una técnica de arranque directo, que permite que el invitado Linux de CRX inicie el
proceso de inicio principal sin pasar por la inicialización del kernel.
CRX proporciona una interfaz binaria de aplicaciones (ABI) de Linux, con la que puede ejecutar un
contenedor como si se ejecutara directamente en el VMkernel.
VMX: tiempo de ejecución de la máquina virtual
VMM: monitor de máquina virtual
3-21 Acerca de los pods de vSphere
Un pod de vSphere es una máquina virtual con un tamaño reducido que ejecuta uno o más
contenedores de Linux.
Con vSphere Pods, las cargas de trabajo tienen las siguientes capacidades:
• Fuerte aislamiento de un kernel de Linux basado en Photon OS
• Gestión de recursos mediante DRS
• Mismo nivel de aislamiento de recursos que las máquinas virtuales
• Compatible con la Iniciativa de contenedor abierto (OCI)
• Equivalente a un host de contenedor de Kubernetes
Los pods de vSphere no son compatibles con vSphere vMotion. Cuando un host ESXi se coloca en
modo de mantenimiento, los pods de vSphere en ejecución se agotan y se vuelven a implementar en
otro host ESXi, pero solo si el pod de vSphere es parte de un ReplicaSet.
3-22 Red y almacenamiento de módulos de vSphere
Los pods de vSphere utilizan diferentes tipos de almacenamiento según los objetos que se almacenan.
Los tipos de almacenamiento son discos de máquina virtual efímeros (VMDK), VMDK de volumen
persistente y VMDK de imagen de contenedores:
• Las políticas de almacenamiento para la imagen del contenedor y los discos efímeros se definen a
nivel de clúster.
• Las políticas de almacenamiento para volúmenes persistentes se definen a nivel de espacio de
nombres.
• Networking for vSphere Pods usa la topología proporcionada por NSX.
3-23 Comparación de pods de vSphere con Kubernetes
La arquitectura de vSphere with Tanzu difiere ligeramente de la arquitectura de Kubernetes. La
principal diferencia es que ESXi se convierte en un nodo de Kubernetes.
En Kubernetes tradicional, los pods se ejecutan dentro de los nodos de trabajo de Kubernetes
(máquinas virtuales Linux). En vSphere with Tanzu, los pods de vSphere se ejecutan en ESXi, de forma
similar a una VM.
3-24 Acerca de los espacios de nombres
Un espacio de nombres es una construcción de Kubernetes que se usa para dividir los recursos del
clúster:
• Los espacios de nombres admiten el acceso multiusuario.
• Los recursos se controlan mediante cuotas de recursos.
• El administrador de vSphere puede controlar las cuotas y el acceso desde vSphere Client.
Un espacio de nombres establece los límites de los recursos donde se pueden ejecutar los clústeres de
vSphere Pods y Kubernetes, creados mediante el servicio de Kubernetes. Cuando se crea inicialmente,
el espacio de nombres tiene recursos ilimitados en el clúster supervisor. Puede establecer límites para la
CPU, la memoria, el almacenamiento y la cantidad de objetos de Kubernetes que se pueden ejecutar en
el espacio de nombres. Se crea un grupo de recursos por cada espacio de nombres en vSphere. Las
limitaciones de almacenamiento se representan como cuotas de almacenamiento en Kubernetes.
Para proporcionar a los ingenieros de DevOps acceso a los espacios de nombres, asigne permisos a los
usuarios o grupos de usuarios disponibles en una fuente de identidad asociada con vCenter Single Sign-
On.
Después de crear y configurar un espacio de nombres con límites de recursos y objetos, permisos y
políticas de almacenamiento, los ingenieros de DevOps pueden acceder al espacio de nombres para
ejecutar cargas de trabajo de Kubernetes y crear clústeres de Kubernetes mediante el servicio de
Kubernetes.
3-25 Registro de Contenedores
Los contenedores necesitan un repositorio para almacenar sus imágenes.
vSphere with Tanzu integra el registro de imágenes de Harbour en vSphere.
A cada espacio de nombres en el clúster supervisor se le asigna su propio proyecto en el registro de
Harbour.
Cuando está habilitado, Harbour se implementa como una serie de pods de vSphere en el clúster
supervisor en su propio espacio de nombres dedicado y administrado por el sistema.
3-26 Servicio de cuadrícula Tanzu Kubernetes
Tanzu Kubernetes Grid Service habilita un clúster de Tanzu Kubernetes que se ejecuta dentro de
máquinas virtuales en un espacio de nombres en el clúster supervisor. Con este servicio, los
desarrolladores pueden controlar su propio clúster de Kubernetes aislado.
La ejecución de un clúster de Tanzu Kubernetes Grid se puede comparar con la ejecución de clústeres
de Kubernetes tradicionales mediante máquinas virtuales y un sistema operativo de host de contenedor.
Tanzu Kubernetes Grid Service automatiza la implementación de dicho clúster. Un objeto de clúster de
Tanzu Kubernetes solo puede constar de su plano de control y máquinas virtuales de trabajo. Los pods
de vSphere no se pueden implementar en un objeto de clúster de Tanzu Kubernetes Grid.
3-27 Objetos de vSphere with Tanzu en vSphere Client
Los objetos de vSphere with Tanzu están visibles en vSphere Client.
Los objetos visibles en la vista Hosts y clústeres incluyen:
1. Espacio de nombres
2. Módulos de vSphere
3. Clúster Tanzu Kubernetes
4. Registro portuario
5. Máquinas virtuales del plano de control
3-28 Licencias de vSphere con Tanzu
Cada host ESXi tiene una licencia de vSphere Enterprise Plus y el clúster tiene una licencia adicional
de Kubernetes.
En vSphere 7 Update 3 y versiones posteriores, al vencimiento de las claves de licencia de Tanzu, no se
aplicarán medidas estrictas automáticamente, lo que permite a los administradores una mayor
flexibilidad para adquirir y asignar una nueva clave de licencia sin afectar las operaciones normales.
En vSphere 7 Update 1 y versiones posteriores, cada host ESXi tiene una licencia de vSphere
Enterprise Plus y el clúster tiene una licencia adicional de Kubernetes.
3-29 Laboratorio 4: Habilitación de vSphere con Tanzu
Utilice vSphere Client para habilitar vSphere with Tanzu:
1. Inicie sesión en el cliente de vSphere
2. Crear una biblioteca de contenido
3. Verifique que vSphere HA y vSphere DRS estén habilitados
4. Habilite vSphere con Tanzu
5. Licencia del clúster
3-30 Revisión de los objetivos del alumno
Después de completar esta lección, debería poder cumplir con los siguientes objetivos:
• Describir el propósito de vSphere with Tanzu y cómo encaja en la cartera de VMware Tanzu
• Identificar las capacidades de vSphere with Tanzu
• Reconocer los beneficios clave de vSphere with Tanzu
• Describir el clúster supervisor de vSphere with Tanzu
• Identificar los componentes que componen vSphere with Tanzu Supervisor Cluster
• Describir el servicio Grid de Tanzu Kubernetes
3-31 Lección 2: NSX-T Data Center para vSphere con Tanzu
3-32 Objetivos de aprendizaje
Después de completar esta lección, debería poder cumplir con los siguientes objetivos:
• Identificar los componentes de NSX-T Data Center que usa vSphere with Tanzu
• Describir las puertas de enlace de nivel 1 y nivel 0 de NSX-T Data Center
• Describir clústeres informáticos y perimetrales compartidos
• Reconocer los requisitos de NSX-T Data Center para vSphere with Tanzu
3-33 Acerca de los segmentos del centro de datos de NSX-T
Un segmento de NSX-T Data Center proporciona funcionalidad de conmutación en un entorno virtual,
desacoplado del hardware subyacente. Un segmento de NSX-T Data Center también se denomina
conmutador lógico.
Un segmento brinda a los administradores el equivalente lógico de un conmutador físico de capa 2:
• Proporciona conmutación de capa 2 para interfaces de puerta de enlace y VM
• Se extiende a través de la infraestructura física
3-34 Acerca de las puertas de enlace de nivel 1 del centro de datos de NSX-T
Una puerta de enlace de nivel 1 de NSX-T Data Center realiza las funciones de un enrutador lógico.
Las puertas de enlace de nivel 1 pueden interconectar diferentes segmentos:
• Proporcionar conexiones de enlace descendente a los segmentos
• Actuar como puerta de enlace para los segmentos
• Proporcionar una conexión de enlace ascendente a la puerta de enlace de nivel 0
3-35 Acerca de las puertas de enlace de nivel 0 del centro de datos de NSX-T
Las puertas de enlace de nivel 0 se conectan a la red física y a los enrutadores físicos.
Las puertas de enlace de nivel 0 brindan conectividad a todas las puertas de enlace de nivel 1
conectadas.
Puede proporcionar enrutamiento estático o dinámico.
El enrutamiento dinámico es proporcionado por el Protocolo de puerta de enlace fronteriza (BGP)
3-36 Acerca de Shared Edge y clústeres informáticos
Un clúster informático y perimetral compartido es un clúster ESXi que ejecuta cargas de trabajo y
máquinas virtuales perimetrales de NSX-T Data Center:
• NSX Manager prepara un clúster ESXi como un clúster informático y perimetral compartido para
vSphere with Tanzu.
• Las máquinas virtuales perimetrales se implementan en el mismo clúster que ejecuta las máquinas
virtuales del plano de control de vSphere con Tanzu y las cargas de trabajo de Kubernetes.
• El dispositivo NSX Manager debe residir en un clúster de administración independiente con vCenter
Server.
For more on shared edge and compute cluster topology, see VMware Validated Design documentation
at [Link]
3-37 Acerca de los clústeres informáticos y perimetrales independientes
Puede configurar clústeres informáticos y perimetrales independientes para admitir vSphere with
Tanzu:
• El clúster perimetral se ejecuta en un clúster.
• Las cargas de trabajo se ejecutan en un clúster separado.
3-38 Acerca de los cortafuegos distribuidos
Un firewall distribuido se ejecuta en el kernel como un paquete VIB en todos los clústeres de host
ESXi que están preparados para NSX.
El firewall distribuido de NSX-T Data Center es un firewall con estado. Supervisa el estado de las
conexiones activas y utiliza esta información para determinar qué paquetes de red permitir a través del
cortafuegos:
• El VIB de firewall distribuido que está instalado en el host ESXi inspecciona el tráfico.
• El tráfico rechazado se bloquea antes de que abandone el host ESXi.
