¿Qué es Kubernetes?

Introducción

Kubernetes es un potente sistema de código abierto, desarrollado inicialmente por Google y respaldado por la Cloud Native Computing Foundation (CNCF), para gestionar aplicaciones en contenedores en un entorno de clúster. Su objetivo es proporcionar mejores formas de gestionar componentes y servicios relacionados y distribuidos en infraestructuras variadas. Para obtener más información sobre Kubernetes, explore la guía a continuación. Si está buscando un servicio de alojamiento de Kubernetes gestionado, consulte nuestro sencillo servicio de Kubernetes gestionado diseñado para el crecimiento.

En esta guía, discutiremos qué es Kubernetes, algunos de los conceptos básicos de Kubernetes. Hablaremos sobre la arquitectura del sistema, los problemas que resuelve y el modelo que utiliza para manejar implementaciones y escalado en contenedores.

¿Qué es Kubernetes?

Kubernetes, en su nivel básico, es un sistema para ejecutar y coordinar aplicaciones en contenedores en un clúster de máquinas. Es una plataforma diseñada para gestionar completamente el ciclo de vida de aplicaciones y servicios en contenedores utilizando métodos que proporcionan previsibilidad, escalabilidad y alta disponibilidad.

Como usuario de Kubernetes, puedes definir cómo deben ejecutarse tus aplicaciones y las formas en que deben poder interactuar con otras aplicaciones o con el mundo exterior. Puedes escalar tus servicios hacia arriba o hacia abajo, realizar actualizaciones de manera fluida y cambiar el tráfico entre diferentes versiones de tus aplicaciones para probar características o revertir implementaciones problemáticas. Kubernetes proporciona interfaces y primitivas de plataforma componibles que te permiten definir y gestionar tus aplicaciones con altos niveles de flexibilidad, potencia y confiabilidad.

Arquitectura de Kubernetes

Para entender cómo Kubernetes puede proporcionar estas capacidades, es útil tener una idea de cómo está diseñado y organizado a un nivel alto. Kubernetes puede visualizarse como un sistema construido en capas, donde cada capa superior abstrae la complejidad encontrada en los niveles inferiores.

En su base, Kubernetes reúne máquinas físicas o virtuales individuales en un clúster utilizando una red compartida para comunicarse entre cada servidor, ya sea físico o virtual. Este clúster de Kubernetes es la plataforma física donde se configuran todos los componentes, capacidades y cargas de trabajo de Kubernetes.

Las máquinas en el clúster de Kubernetes reciben cada una un rol dentro del ecosistema de Kubernetes. Un servidor (o un pequeño grupo en implementaciones altamente disponibles) funciona como el servidor maestro. Este servidor actúa como una puerta de enlace y cerebro para el clúster al exponer una API de Kubernetes para usuarios y clientes, verificar la salud de otros servidores, decidir cómo dividir y asignar el trabajo de la mejor manera (conocido como “programación”), y orquestar la comunicación entre otros componentes (a veces referido como orquestación de contenedores). El servidor maestro actúa como el punto de contacto principal con el clúster y es responsable de la mayor parte de la lógica centralizada que Kubernetes proporciona.

Las otras máquinas en el clúster están designadas como nodos: servidores responsables de aceptar y ejecutar cargas de trabajo utilizando recursos locales y externos. Para ayudar con el aislamiento, la gestión y la flexibilidad, Kubernetes ejecuta aplicaciones y servicios en contenedores, por lo que cada nodo debe estar equipado con un tiempo de ejecución de contenedores (como Docker o rkt). El nodo recibe instrucciones de trabajo del servidor maestro y crea o destruye contenedores en consecuencia, ajustando las reglas de red para enrutar y reenviar el tráfico adecuadamente.

Como se mencionó anteriormente, las aplicaciones y servicios en sí se ejecutan en el clúster dentro de contenedores. Los componentes subyacentes se aseguran de que el estado deseado de las aplicaciones coincida con el estado real del clúster. Los usuarios interactúan con el clúster comunicándose con el servidor principal de la API de Kubernetes directamente o con clientes y bibliotecas. Para iniciar una aplicación o servicio, se presenta un plan declarativo en JSON o YAML que define qué crear y cómo debe ser gestionado. Luego, el servidor principal toma el plan y determina cómo ejecutarlo en la infraestructura examinando los requisitos y el estado actual del sistema. Este grupo de aplicaciones definidas por el usuario que se ejecutan según un plan especificado representa la capa final de Kubernetes.

Componentes del Servidor Principal

Como se describió anteriormente, el servidor principal actúa como el plano de control principal para los clústeres de Kubernetes. Sirve como el principal punto de contacto para administradores y usuarios, y también proporciona muchos sistemas de clúster amplios para los nodos trabajadores relativamente no sofisticados. En general, los componentes en el servidor principal trabajan juntos para aceptar solicitudes de usuario, determinar las mejores formas de programar contenedores de carga de trabajo, autenticar clientes y nodos, ajustar la red a nivel de clúster y gestionar responsabilidades de escalado y verificación de salud.

Estos componentes pueden instalarse en una sola máquina o distribuirse en varios servidores. Analizaremos cada uno de los componentes individuales asociados con los servidores maestros para los clústeres de Kubernetes en esta sección.

etcd

Uno de los componentes fundamentales que Kubernetes necesita para funcionar es un almacén de configuración disponible globalmente. El proyecto etcd, desarrollado por el equipo de CoreOS (sistema operativo), es un almacén de claves y valores distribuido y ligero que puede configurarse para abarcar varios nodos.

Kubernetes utiliza etcd para almacenar datos de configuración a los que pueden acceder cada uno de los nodos del clúster. Esto se puede utilizar para descubrimiento de servicios y puede ayudar a que los componentes se configuren o reconfiguren según la información actualizada. También ayuda a mantener el estado del clúster con funciones como la elección del líder y el bloqueo distribuido. Al proporcionar una API simple de HTTP/JSON, la interfaz para establecer o recuperar valores es muy directa.

Al igual que la mayoría de los otros componentes en el plano de control, etcd se puede configurar en un solo servidor maestro o, en escenarios de producción, distribuirse entre varios equipos. El único requisito es que sea accesible en red para cada una de las máquinas de Kubernetes.

kube-apiserver

Uno de los servicios principales más importantes es un servidor API. Este es el punto de gestión principal de todo el clúster, ya que permite a un usuario configurar las cargas de trabajo y las unidades organizativas de Kubernetes. También es responsable de garantizar que el almacenamiento etcd y los detalles del servicio de los contenedores implementados estén en acuerdo. Actúa como puente entre varios componentes para mantener la salud del clúster y difundir información y comandos.

El servidor API implementa una interfaz RESTful, lo que significa que muchas herramientas y bibliotecas diferentes pueden comunicarse fácilmente con él. Un cliente llamado kubectl está disponible como método predeterminado para interactuar con el clúster de Kubernetes desde una computadora local.

kube-controller-manager

El administrador de controladores es un servicio general que tiene muchas responsabilidades. Principalmente, gestiona diferentes controladores que regulan el estado del clúster, administran los ciclos de vida de la carga de trabajo y realizan tareas rutinarias. Por ejemplo, un controlador de replicación asegura que el número de réplicas (copias idénticas) definidas para una vaina coincida con el número actualmente implementado en el clúster. Los detalles de estas operaciones se escriben en etcd, donde el administrador de controladores observa los cambios a través del servidor API.

Cuando se detecta un cambio, el controlador lee la nueva información e implementa el procedimiento que cumple con el estado deseado. Esto puede implicar escalar una aplicación hacia arriba o hacia abajo, ajustar puntos finales, etc.

kube-scheduler

El proceso que realmente asigna cargas de trabajo a nodos específicos en el clúster es el programador. Este servicio lee los requisitos operativos de una carga de trabajo, analiza el entorno de infraestructura actual y coloca el trabajo en un nodo o nodos aceptables.

El programador es responsable de rastrear la capacidad disponible en cada host para asegurarse de que las cargas de trabajo no se programen en exceso de los recursos disponibles. El programador debe conocer la capacidad total, así como los recursos ya asignados a las cargas de trabajo existentes en cada servidor.

cloud-controller-manager

Kubernetes puede implementarse en muchos entornos diferentes e interactuar con varios proveedores de infraestructura para comprender y administrar el estado de los recursos en el clúster. Si bien Kubernetes trabaja con representaciones genéricas de recursos como almacenamiento adjunto y equilibradores de carga, necesita una manera de asignar estos recursos a los recursos reales proporcionados por proveedores de nube no homogéneos.

Los controladores de nube actúan como el pegamento que permite a Kubernetes interactuar con proveedores con diferentes capacidades, características y APIs mientras mantiene construcciones relativamente genéricas internamente. Esto permite a Kubernetes actualizar su información de estado de acuerdo con la información recopilada del proveedor de la nube, ajustar los recursos en la nube según sea necesario en el sistema y crear y utilizar servicios en la nube adicionales para satisfacer los requisitos de trabajo enviados al clúster.

Componentes del Servidor de Nodos

En Kubernetes, los servidores que realizan el trabajo ejecutando contenedores se conocen como nodos. Los servidores de nodos tienen algunos requisitos que son necesarios para comunicarse con los componentes maestros, configurar la red de contenedores y ejecutar las cargas de trabajo asignadas a ellos.

A Container Runtime

El primer componente que cada nodo debe tener es un tiempo de ejecución de contenedores. Típicamente, este requisito se satisface instalando y ejecutando Docker, pero también están disponibles alternativas como rkt y runc.

El tiempo de ejecución de contenedores es responsable de iniciar y gestionar contenedores, aplicaciones encapsuladas en un entorno operativo relativamente aislado pero liviano. Cada unidad de trabajo en el clúster se implementa, en su nivel básico, como uno o más contenedores que deben ser desplegados. El tiempo de ejecución de contenedores en cada nodo es el componente que finalmente ejecuta los contenedores definidos en las cargas de trabajo enviadas al clúster.

kubelet

El punto de contacto principal para cada nodo con el grupo del clúster es un pequeño servicio llamado kubelet. Este servicio es responsable de transmitir información hacia y desde los servicios del plano de control, así como de interactuar con el almacén etcd para leer detalles de configuración o escribir nuevos valores.

El servicio kubelet se comunica con los componentes maestros para autenticarse en el clúster y recibir comandos y trabajos. El trabajo se recibe en forma de un manifiesto que define la carga de trabajo y los parámetros operativos. El proceso kubelet asume entonces la responsabilidad de mantener el estado del trabajo en el servidor del nodo. Controla el tiempo de ejecución de contenedores para iniciar o destruir contenedores según sea necesario.

kube-proxy

Para administrar la subdivisión de subredes de hosts individuales y hacer que los servicios estén disponibles para otros componentes, se ejecuta un pequeño servicio de proxy llamado kube-proxy en cada servidor de nodos. Este proceso reenvía las solicitudes a los contenedores correctos, puede realizar un equilibrio de carga primitivo y generalmente se encarga de garantizar que el entorno de red sea predecible y accesible, pero aislado cuando sea necesario.

Objetos y Cargas de Trabajo de Kubernetes

Mientras que los contenedores son el mecanismo subyacente utilizado para implementar aplicaciones contenerizadas, Kubernetes utiliza capas adicionales de abstracción sobre la interfaz del contenedor para proporcionar características de escalabilidad, resiliencia y gestión del ciclo de vida. En lugar de administrar contenedores directamente, los usuarios definen e interactúan con instancias compuestas de diversos elementos primitivos proporcionados por el modelo de objetos de Kubernetes. A continuación, repasaremos los diferentes tipos de objetos que se pueden utilizar para definir estas cargas de trabajo.

Pods

A pod is the most basic unit that Kubernetes deals with. Containers themselves are not assigned to hosts. Instead, one or more tightly coupled containers are encapsulated in an object called a pod.

A pod generally represents containers that should be controlled as a single application. Pods consist of containers that operate closely together, share a life cycle, and should always be scheduled on the same node. They are managed entirely as a unit and share their environment, volumes, and IP space. In spite of their containerized implementation, you should generally think of pods as a single, monolithic application to best conceptualize how the cluster will manage the pod’s resources and scheduling.

Por lo general, las vainas consisten en un contenedor principal que satisface el propósito general de la carga de trabajo y opcionalmente algunos contenedores auxiliares que facilitan tareas estrechamente relacionadas. Estos son programas que se benefician de ser ejecutados y gestionados en sus propios contenedores, pero están estrechamente ligados a la aplicación principal. Por ejemplo, una vaina puede tener un contenedor ejecutando el servidor de aplicación principal y un contenedor auxiliar descargando archivos al sistema de archivos compartido cuando se detectan cambios en un repositorio externo. Por lo general, no se recomienda la escalabilidad horizontal a nivel de vaina porque hay otros objetos de nivel superior más adecuados para la tarea.

Por lo general, los usuarios no deben gestionar las vainas ellos mismos, porque no proporcionan algunas de las características típicamente necesarias en las aplicaciones (como la gestión sofisticada del ciclo de vida y la escalabilidad). En su lugar, se anima a los usuarios a trabajar con objetos de nivel superior que utilizan vainas o plantillas de vainas como componentes base, pero implementan funcionalidades adicionales.

Controladores de Replicación y Conjuntos de Replicación

A menudo, al trabajar con Kubernetes, en lugar de trabajar con vainas individuales, en su lugar se estarán gestionando grupos de vainas replicadas e idénticas. Estas se crean a partir de plantillas de vainas y pueden escalarse horizontalmente mediante controladores conocidos como controladores de replicación y conjuntos de replicación.

A replication controller is an object that defines a pod template and control parameters to scale identical replicas of a pod horizontally by increasing or decreasing the number of running copies. This is an easy way to distribute load and increase availability natively within Kubernetes. The replication controller knows how to create new pods as needed because a template that closely resembles a pod definition is embedded within the replication controller configuration.

El controlador de replicación es responsable de garantizar que el número de pods desplegados en el clúster coincida con el número de pods en su configuración. Si un pod o el host subyacente falla, el controlador iniciará nuevos pods para compensar. Si el número de réplicas en la configuración de un controlador cambia, el controlador iniciará o eliminará contenedores para que coincida con el número deseado. Los controladores de replicación también pueden realizar actualizaciones graduales para cambiar un conjunto de pods a una nueva versión uno por uno, minimizando el impacto en la disponibilidad de la aplicación.

Los conjuntos de replicación son una iteración del diseño del controlador de replicación con mayor flexibilidad en cómo el controlador identifica los pods que debe gestionar. Los conjuntos de replicación están comenzando a reemplazar a los controladores de replicación debido a sus mayores capacidades de selección de réplicas, pero no pueden realizar actualizaciones graduales para cambiar los backends a una nueva versión como pueden hacer los controladores de replicación. En su lugar, los conjuntos de replicación están destinados a ser utilizados dentro de unidades adicionales de nivel superior que proporcionan esa funcionalidad.

Al igual que los pods, tanto los controladores de replicación como los conjuntos de replicación rara vez son las unidades con las que trabajarás directamente. Aunque se basan en el diseño de los pods para agregar escalabilidad horizontal y garantías de fiabilidad, carecen de algunas de las capacidades de gestión del ciclo de vida de granularidad fina que se encuentran en objetos más complejos.

Los despliegues

Los despliegues son una de las cargas de trabajo más comunes para crear y gestionar directamente. Los despliegues utilizan conjuntos de réplicas como un componente básico, añadiendo funcionalidades flexibles de gestión del ciclo de vida a la mezcla.

Si bien los despliegues construidos con conjuntos de réplicas pueden parecer duplicar la funcionalidad ofrecida por los controladores de replicación, los despliegues resuelven muchos de los problemas que existían en la implementación de actualizaciones graduales. Al actualizar aplicaciones con controladores de replicación, los usuarios deben presentar un plan para un nuevo controlador de replicación que reemplace al controlador actual. Al usar controladores de replicación, tareas como el seguimiento del historial, la recuperación de fallos de red durante la actualización y revertir cambios incorrectos son difíciles o quedan como responsabilidad del usuario.

Los despliegues son objetos de alto nivel diseñados para facilitar la gestión del ciclo de vida de los pods replicados. Los despliegues pueden modificarse fácilmente cambiando la configuración y Kubernetes ajustará los conjuntos de réplicas, gestionará las transiciones entre diferentes versiones de la aplicación y opcionalmente mantendrá automáticamente el historial de eventos y las capacidades de deshacer. Debido a estas características, es probable que los despliegues sean el tipo de objeto de Kubernetes con el que trabaje con más frecuencia.

Conjuntos de Estados

Los conjuntos de estado son controladores especializados de pods que ofrecen garantías de orden y unicidad. Principalmente, se utilizan para tener un control más detallado cuando hay requisitos especiales relacionados con el orden de implementación, datos persistentes o redes estables. Por ejemplo, los conjuntos de estado suelen estar asociados con aplicaciones orientadas a datos, como bases de datos, que necesitan acceso a los mismos volúmenes incluso si se reprograman en un nuevo nodo.

Los conjuntos de estado proporcionan un identificador de red estable al crear un nombre único basado en números para cada pod que persistirá incluso si el pod necesita ser movido a otro nodo. De igual manera, los volúmenes de almacenamiento persistentes pueden ser transferidos con un pod cuando sea necesario reprogramar. Los volúmenes persisten incluso después de que el pod haya sido eliminado para evitar la pérdida accidental de datos.

Al implementar o ajustar la escala, los conjuntos de estado realizan operaciones de acuerdo con el identificador numerado en su nombre. Esto proporciona una mayor previsibilidad y control sobre el orden de ejecución, lo cual puede ser útil en algunos casos.

Conjuntos de demonios

Los conjuntos de demonios son otra forma especializada de controlador de pods que ejecutan una copia de un pod en cada nodo del clúster (o un subconjunto, si se especifica). Esto es más útil cuando se implementan pods que ayudan a realizar tareas de mantenimiento y proporcionan servicios para los propios nodos de Kubernetes.

Por ejemplo, la recolección y el reenvío de registros, la agregación de métricas y la ejecución de servicios que aumentan las capacidades del propio nodo son candidatos populares para conjuntos de demonios. Debido a que los conjuntos de demonios a menudo proporcionan servicios fundamentales y son necesarios en toda la flota, pueden evadir las restricciones de programación de pods que impiden que otros controladores asignen pods a ciertos hosts. Como ejemplo, debido a sus responsabilidades únicas, el servidor principal frecuentemente se configura para no estar disponible para la programación normal de pods, pero los conjuntos de demonios tienen la capacidad de anular la restricción caso por caso para asegurar que los servicios esenciales estén en funcionamiento.

Trabajos y Trabajos Cron

Las cargas de trabajo que hemos descrito hasta ahora han asumido todas un ciclo de vida similar al de un servicio en ejecución. Kubernetes utiliza una carga de trabajo llamada trabajos para proporcionar un flujo de trabajo más basado en tareas donde se espera que los contenedores en ejecución salgan con éxito después de algún tiempo una vez que hayan completado su trabajo. Los trabajos son útiles si necesita realizar procesamiento único o por lotes en lugar de ejecutar un servicio continuo.

La construcción en trabajos son trabajos cron. Al igual que los demonios cron convencionales en sistemas Linux y similares a Unix que ejecutan scripts según un horario, los trabajos cron en Kubernetes proporcionan una interfaz para ejecutar trabajos con un componente de programación. Los trabajos cron se pueden usar para programar un trabajo para que se ejecute en el futuro o de forma regular y recurrente. Los trabajos cron de Kubernetes son básicamente una reimplementación del comportamiento cron clásico, utilizando el clúster como plataforma en lugar de un único sistema operativo.

Otros Componentes de Kubernetes

Más allá de las cargas de trabajo que puedes ejecutar en un clúster, Kubernetes proporciona varias abstracciones adicionales que te ayudan a administrar tus aplicaciones, controlar la red y habilitar la persistencia. Discutiremos algunos de los ejemplos más comunes aquí.

Servicios de Kubernetes

Hasta ahora, hemos estado utilizando el término “servicio” en el sentido convencional, similar a Unix: para denotar procesos en ejecución prolongada, a menudo conectados en red, capaces de responder a solicitudes. Sin embargo, en Kubernetes, un servicio es un componente que actúa como un balanceador de carga interno básico y embajador para pods. Un servicio agrupa colecciones lógicas de pods que realizan la misma función para presentarlos como una única entidad.

Esto te permite implementar un servicio que pueda realizar un seguimiento y dirigirse a todos los contenedores backend de un tipo particular. Los consumidores internos solo necesitan conocer el punto de conexión estable proporcionado por el servicio. Mientras tanto, la abstracción del servicio te permite escalar o reemplazar las unidades de trabajo backend según sea necesario. La dirección IP de un servicio permanece estable independientemente de los cambios en los pods a los que se dirige. Al implementar un servicio, obtienes fácilmente capacidad de descubrimiento y puedes simplificar tus diseños de contenedores.

Cada vez que necesites proporcionar acceso a uno o más pods a otra aplicación o a consumidores externos, debes configurar un servicio. Por ejemplo, si tienes un conjunto de pods que ejecutan servidores web que deben ser accesibles desde Internet, un servicio proporcionará la abstracción necesaria. Del mismo modo, si tus servidores web necesitan almacenar y recuperar datos, querrás configurar un servicio interno para darles acceso a tus pods de base de datos.

Aunque los servicios, por defecto, solo están disponibles usando una dirección IP enrutada internamente, pueden estar disponibles fuera del clúster eligiendo una de varias estrategias. La configuración NodePort funciona abriendo un puerto estático en la interfaz de red externa de cada nodo. El tráfico al puerto externo se enrutaré automáticamente a los pods apropiados usando un servicio de IP de clúster interno.

Alternativamente, el tipo de servicio LoadBalancer crea un balanceador de carga externo para dirigirse al servicio usando la integración del balanceador de carga de Kubernetes del proveedor de la nube. El administrador del controlador de la nube creará el recurso apropiado y lo configurará usando las direcciones de servicio del servicio interno.

Volúmenes y Volúmenes Persistentes

Compartir datos de manera confiable y garantizar su disponibilidad entre reinicios de contenedores es un desafío en muchos entornos contenerizados. Los motores de contenedores a menudo proporcionan algún mecanismo para adjuntar almacenamiento a un contenedor que persiste más allá de la vida útil del contenedor, pero las implementaciones suelen carecer de flexibilidad.

Para abordar esto, Kubernetes utiliza su propia abstracción de volúmenes que permite compartir datos entre todos los contenedores dentro de una cápsula y mantenerlos disponibles hasta que la cápsula se termina. Esto significa que las cápsulas estrechamente acopladas pueden compartir archivos fácilmente sin mecanismos externos complejos. Los fallos de contenedor dentro de la cápsula no afectarán el acceso a los archivos compartidos. Una vez que la cápsula se termina, el volumen compartido se destruye, por lo que no es una buena solución para datos verdaderamente persistentes.

Los volúmenes persistentes son un mecanismo para abstraer un almacenamiento más robusto que no está vinculado al ciclo de vida de la cápsula. En su lugar, permiten a los administradores configurar recursos de almacenamiento para el clúster que los usuarios pueden solicitar y reclamar para las cápsulas que están ejecutando. Una vez que una cápsula ha terminado con un volumen persistente, la política de reclamación del volumen determina si el volumen se mantiene hasta que se elimine manualmente o se elimine junto con los datos de inmediato. Los datos persistentes se pueden utilizar para protegerse contra fallos basados en nodos y para asignar mayores cantidades de almacenamiento de las disponibles localmente.

Etiquetas y Anotaciones

A Kubernetes organizational abstraction related to, but outside of the other concepts, is labeling. A label in Kubernetes is a semantic tag that can be attached to Kubernetes objects to mark them as a part of a group. These can then be selected for when targeting different instances for management or routing. For instance, each of the controller-based objects use labels to identify the pods that they should operate on. Services use labels to understand the backend pods they should route requests to.

Las etiquetas se presentan como pares de clave-valor simples. Cada unidad puede tener más de una etiqueta, pero solo puede tener una entrada para cada clave. Por lo general, se utiliza una clave “nombre” como identificador de propósito general, pero también puedes clasificar objetos según otros criterios como etapa de desarrollo, accesibilidad pública, versión de la aplicación, etc.

Las anotaciones son un mecanismo similar que te permite adjuntar información arbitraria de clave-valor a un objeto. Mientras que las etiquetas deben usarse para información semántica útil para emparejar un pod con criterios de selección, las anotaciones son más libres y pueden contener datos menos estructurados. En general, las anotaciones son una forma de agregar metadatos ricos a un objeto que no son útiles para fines de selección.

Conclusión

Kubernetes es un proyecto emocionante que permite a los usuarios ejecutar cargas de trabajo contenerizadas escalables y altamente disponibles en una plataforma altamente abstracta. Si bien la arquitectura de Kubernetes y su conjunto de componentes internos pueden parecer intimidantes al principio, su poder, flexibilidad y conjunto de funciones robustas son incomparables en el mundo del código abierto y para el desarrollo nativo de la nube. Al comprender cómo encajan los bloques de construcción básicos, puedes comenzar a diseñar sistemas que aprovechen al máximo las capacidades de la plataforma para ejecutar y administrar tus cargas de trabajo a escala, construyendo aplicaciones nativas de la nube increíbles.