Introducción a Kubernetes – Guía para novatos

Introducción

Kubernetes es un poderoso sistema de código abierto, desarrollado inicialmente por Google, para administrar aplicaciones en contenedores en un entorno agrupado. Su objetivo es proporcionar mejores formas de administrar componentes y servicios relacionados y distribuidos en una infraestructura variada.

En esta guía, discutiremos 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 las implementaciones en contenedores.

¿Qué es Kubernetes?

Kubernetes, en su nivel básico, es un sistema para ejecutar y coordinar aplicaciones en contenedores en un grupo de máquinas.

Es una plataforma diseñada para administrar completamente el ciclo de vida de las 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 continuas y cambiar el tráfico entre diferentes versiones de tus aplicaciones para probar características o revertir implementaciones problemáticas.

Kubernetes proporciona interfaces y plataformas primitivas compositivas que te permiten definir y administrar tus aplicaciones con un alto grado de flexibilidad, potencia y confiabilidad.

Arquitectura 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 alto nivel.

Los kubernetes se pueden visualizar como un sistema integrado en capas, con cada capa superior abstrayendo 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. Este clúster es la plataforma física donde se configuran todos los componentes, capacidades y cargas de trabajo de Kubernetes.

A las máquinas del clúster se les asigna un rol dentro del ecosistema Kubernetes. Un servidor (o un pequeño grupo en implementaciones de alta disponibilidad) funciona como el servidor master/maestro.

Este servidor actúa como una puerta de enlace y un cerebro para el clúster al exponer una API para usuarios y clientes, comprobar el estado de otros servidores, decidir cómo dividir y asignar el trabajo (conocido como “programación”) y organizar la comunicación entre otros componentes.

El servidor maestro actúa como el principal punto de contacto con el clúster y es responsable de la mayor parte de la lógica centralizada que proporciona Kubernetes.

Nodos

Las otras máquinas del clúster se designan como nodos: servidores responsables de aceptar y ejecutar las cargas de trabajo utilizando recursos locales y externos.

Para ayudar con el aislamiento, la administració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 contenedor (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 de manera adecuada.

Como se mencionó anteriormente, las aplicaciones y los servicios se ejecutan en el clúster dentro de los 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 al comunicarse con el servidor API principal directamente o con clientes y bibliotecas. Para iniciar una aplicación o servicio, se envía un plan declarativo en JSON o YAML que define qué crear y cómo debe administrarse.

El servidor maestro toma el plan y descubre cómo ejecutarlo en la infraestructura mediante el examen de los requisitos y el estado actual del sistema. Este grupo de aplicaciones definidas por el usuario que se ejecutan de acuerdo con un plan específico representa la capa final de Kubernetes.

Componentes del servidor maestro

Como describimos anteriormente, el servidor maestro actúa como el plano de control primario para los clusters de Kubernetes. Sirve como el principal punto de contacto para administradores y usuarios, y también proporciona muchos sistemas a nivel de clúster para los nodos de trabajadores relativamente poco sofisticados.

En general, los componentes en el servidor maestro trabajan juntos para aceptar las solicitudes de los usuarios, determinar las mejores formas de programar contenedores de carga de trabajo, autenticar clientes y nodos, ajustar la red en todo el clúster y administrar las responsabilidades de escalado y control de estado.

Estos componentes pueden instalarse en una sola máquina o distribuirse en varios servidores. En esta sección, veremos cada uno de los componentes individuales asociados con los servidores maestros.

etcd

Uno de los componentes fundamentales que necesita Kubernetes para funcionar es un almacén de configuración disponible a nivel mundial. El proyecto etcd , desarrollado por el equipo de CoreOS, es un almacén de valor clave distribuido y ligero que se puede configurar para abarcar varios nodos.

Kubernetes utiliza etcd para almacenar datos de configuración a los que puede acceder cada uno de los nodos del clúster. Esto se puede usar para el descubrimiento del servicio y puede ayudar a los componentes a configurarse o reconfigurarse según la información actualizada.

También ayuda a mantener el estado del clúster con características como la elección del líder y el bloqueo distribuido. Al proporcionar una API HTTP/JSON simple, la interfaz para establecer o recuperar valores es muy sencilla.

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

kube-apiserver

Uno de los servicios maestros más importantes es un servidor API. Este es el principal punto de administración de todo el clúster, ya que le permite a un usuario configurar las cargas de trabajo y las unidades organizativas de Kubernetes.

También es responsable de asegurarse de que etcd almacene y detalle los servicios de los contenedores implementados para que estén de acuerdo. Actúa como el puente entre varios componentes para mantener la salud del clúster y diseminar 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 un método predeterminado para interactuar con el clúster Kubernetes desde una computadora local.

kube-controller-manager

El administrador del controlador es un servicio general que tiene muchas responsabilidades. Principalmente, administra 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 garantiza que el número de réplicas (copias idénticas) definidas para un pod coincida con el número implementado actualmente en el clúster. Los detalles de estas operaciones se escriben en etcd, donde el administrador del controlador observa los cambios a través del servidor API.

Cuando se ve 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 los 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 estén programadas 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 se puede implementar en muchos entornos diferentes y puede 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 el almacenamiento conectable y los balanceadores de carga, necesita una forma de asignarlos a los recursos reales proporcionados por proveedores de nube no homogéneos.

Los administradores de los controladores en la nube actúan como el pegamento que permite a Kubernetes interactuar con proveedores con diferentes capacidades, características y API mientras mantiene construcciones relativamente genéricas internamente.

Esto permite a Kubernetes actualizar su información de estado de acuerdo con la información recopilada por el proveedor de la nube, ajustar los recursos de la nube a medida que se necesitan cambios en el sistema y crear y utilizar servicios de nube adicionales para satisfacer los requisitos de trabajo enviados al clúster.

Componentes del Servidor Nodo

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

Un tiempo de ejecución de contenedores

El primer componente que debe tener cada nodo es un tiempo de ejecución de contenedor. Por lo general, este requisito se satisface al instalar y ejecutar Docker, pero también existen alternativas como rkt y runc.

El tiempo de ejecución del contenedor es responsable de iniciar y administrar los 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 implementarse. El tiempo de ejecución del contenedor 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 de clústeres 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 almacenamiento etcd para leer los 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 trabajo. El trabajo se recibe en forma de un manifiesto que define la carga de trabajo y los parámetros operativos.

El proceso kubelet luego asume la responsabilidad de mantener el estado del trabajo en el servidor del nodo. Controla el tiempo de ejecución del contenedor para iniciar o destruir contenedores según sea necesario.

kube-proxy

Para administrar la división en subredes del host individual 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 nodo.

Este proceso envía las solicitudes a los contenedores correctos, puede hacer un balanceo de carga primitivo y, en general, es responsable de garantizar que el entorno de red sea predecible y accesible, pero aislado cuando sea apropiado.

Objetos Kubernetes y cargas de trabajo

Si bien los contenedores son el mecanismo subyacente que se usa para implementar aplicaciones, Kubernetes utiliza capas adicionales de abstracción a través de la interfaz del contenedor para proporcionar funciones de administración de escala, resiliencia y ciclo de vida.

En lugar de administrar contenedores directamente, los usuarios definen e interactúan con instancias compuestas por varias primitivas proporcionadas por el modelo de objetos Kubernetes. Revisaremos los diferentes tipos de objetos que se pueden usar para definir estas cargas de trabajo a continuación.

Pods

Un pod es la unidad más básica con la que trata Kubernetes. Los contenedores en sí no están asignados a los hosts. En su lugar, uno o más contenedores estrechamente acoplados están encapsulados en un objeto llamado pod.

Un pod generalmente representa uno o más contenedores que deben controlarse como una sola aplicación. Las cápsulas están formadas por contenedores que operan en estrecha colaboración, comparten un ciclo de vida y siempre deben programarse en el mismo nodo.

Se administran en su totalidad como una unidad y comparten su entorno, volúmenes y espacio IP. A pesar de su implementación en contenedores, generalmente debes pensar en los pods como una aplicación única y monolítica para conceptualizar mejor cómo el cluster administrará los recursos y la programación del pod.

Funcionamiento

Por lo general, un pod consisten en un contenedor principal que satisface el propósito general de la carga de trabajo y, opcionalmente, algunos contenedores de ayuda que facilitan las tareas estrechamente relacionadas.

Estos son programas que se benefician de ser ejecutados y administrados en sus propios contenedores, pero están estrechamente ligados a la aplicación principal.

Por ejemplo, un pod puede tener un contenedor que ejecuta el servidor de aplicaciones primario y un contenedor auxiliar que lleva los archivos al sistema de archivos compartido, cuando se detectan cambios en un repositorio externo.

El escalado horizontal generalmente no se recomienda en el nivel de pod porque existen otros objetos de nivel superior más adecuados para la tarea.

En general, los usuarios no deben administrar los pods por sí mismos, ya que no proporcionan algunas de las funciones que normalmente se necesitan en las aplicaciones (como la administración sofisticada del ciclo de vida y el escalado).

En su lugar, se recomienda a los usuarios que trabajen con objetos de nivel superior que usan pods o plantillas de pods, como componentes básicos pero que implementan funcionalidad adicional.

Controladores de replicación y conjuntos de replicación

A menudo, al trabajar con Kubernetes, en lugar de trabajar con pods individuales, en su lugar estarás administrando grupos de pods idénticos y replicados. Estos se crean a partir de plantillas de pods y pueden ser escalados horizontalmente por controladores conocidos como controladores de réplica y conjuntos de réplica.

Controlador de replicación

Es un objeto que define una plantilla de pod y parámetros de control para escalar réplicas idénticas de un pod horizontalmente al aumentar o disminuir el número de copias en ejecución.

Esta es una manera fácil de distribuir la carga y aumentar la disponibilidad de forma nativa dentro de Kubernetes. El controlador de replicación sabe cómo crear nuevos pods según sea necesario porque una plantilla que se parece mucho a una definición de pod está incrustada dentro de la configuración del controlador de réplica.

El controlador de replicación es responsable de garantizar que el número de pods implementados en el clúster coincida con el número de pods en tu configuración. Si un pod o un 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 se inicia o elimina los contenedores para que coincida con el número deseado.

Los controladores de réplica también pueden realizar actualizaciones continuas para pasar de un conjunto de pods a una nueva versión una por una, minimizando el impacto en la disponibilidad de la aplicación.

Conjuntos de replicación

Son una iteración en el diseño del controlador de replicación con una mayor flexibilidad en la forma en que el controlador identifica los pods que debe administrar.

Los conjuntos de replicación están comenzando a reemplazar los controladores de replicación debido a su mayor capacidad de selección de réplicas, pero no pueden hacer actualizaciones continuas para completar el ciclo hacia una nueva versión como lo pueden hacer los controladores de replicación.

En cambio, los conjuntos de replicación están diseñados para usarse 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.

Si bien se basan en el diseño del módulo para agregar escalas horizontales y garantías de confiabilidad, carecen de algunas de las capacidades de gestión del ciclo de vida fino que se encuentran en objetos más complejos.

Implementaciones

Las implementaciones son una de las cargas de trabajo más comunes para crear y administrar directamente. Las implementaciones utilizan conjuntos de replicación como un bloque de construcción, lo que agrega funcionalidad de administración de ciclo de vida flexible a la mezcla.

Si bien las implementaciones creadas con conjuntos de replicaciones pueden parecer duplicar la funcionalidad ofrecida por los controladores de replicación, las implementaciones resuelven muchos de los puntos problemáticos que existían en la implementación de actualizaciones sucesivas.

Al actualizar las aplicaciones con controladores de replicación, los usuarios deben enviar un plan para un nuevo controlador de replicación que reemplace al controlador actual.

Cuando se usan controladores de replicación, las tareas como el seguimiento del historial, la recuperación de fallas de la red durante la actualización y la eliminación de los cambios incorrectos son difíciles o se dejan como responsabilidad del usuario.

Las implementaciones son un objeto de alto nivel diseñado para facilitar la administración del ciclo de vida de los pods replicados.

Las implementaciones se pueden modificar fácilmente cambiando la configuración y Kubernetes ajustará los conjuntos de réplicas, administrará las transiciones entre diferentes versiones de las aplicaciones y, opcionalmente, mantendrá el historial de eventos y deshará las capacidades automáticamente.

Debido a estas características, las implementaciones probablemente serán el tipo de objeto Kubernetes con el que trabajes con más frecuencia.

Conjuntos de Estado

Los conjuntos con estado son controladores de pods especializados que ofrecen garantías de pedido y exclusividad. Principalmente, estos se usan para tener un control más preciso cuando tienes requisitos especiales relacionados con el orden de implementación, datos persistentes o redes estables.

Por ejemplo, los conjuntos de estado a menudo se asocian 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 moverse a otro nodo.

Del mismo modo, los volúmenes de almacenamiento persistentes se pueden transferir con un pod cuando se necesita reprogramar. Los volúmenes persisten incluso después de que se haya eliminado el pod para evitar la pérdida accidental de datos.

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

Conjuntos de demonios

Los conjuntos de demonios son otra forma especializada de controlador de pod que ejecuta una copia de un pod en cada nodo del clúster (o un subconjunto, si se especifica).

Esto suele ser útil cuando se implementan pods que ayudan a realizar el mantenimiento y proporcionan servicios para los nodos.

Por ejemplo, la recopilació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 los conjuntos de demonios.

Debido a que los daemon sets a menudo proporcionan servicios fundamentales y son necesarios en toda la flota, pueden pasar por alto las restricciones de programación de pod que impiden que otros controladores asignen pods a ciertos hosts.

Como ejemplo, debido a sus responsabilidades únicas, el servidor maestro se configura con frecuencia para que no esté disponible para la programación normal de pod, pero los conjuntos de demonios tienen la capacidad de anular la restricción en cada base para asegurarse de que los servicios esenciales se estén ejecutando.

Jobs y Cron Jobs

Las cargas de trabajo que hemos descrito hasta ahora han asumido un ciclo de vida similar a un servicio de larga duración.

Kubernetes utiliza una carga de trabajo llamada Jobs 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 jobs son útiles si necesitas realizar un procesamiento único o por lotes en lugar de ejecutar un servicio continuo.

La construcción de jobs son conocidos como cron jobs. Al igual que los demonios cron convencionales en Linux y sistemas similares a Unix que ejecutan scripts de forma programada, los cron jobs en Kubernetes proporcionan una interfaz para ejecutar trabajos con un componente de programación.

Los cron jobs se pueden usar para programar un trabajo para que se ejecute en el futuro o de forma regular, recurrente. Los cron jobs de Kubernetes son básicamente una reimplementación del comportamiento del cron clásico, utilizando el clúster como plataforma en lugar de un solo sistema operativo.

Otros Componentes Kubernetes

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

Servicios

Hasta ahora, hemos estado usando el término “servicio” en el sentido convencional de Unix: para denotar procesos de larga ejecución, a menudo conectados a la red, capaces de responder a las 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 presentarlas como una sola entidad.

Esto te permite implementar un servicio que puede realizar un seguimiento y enrutar a todos los contenedores de back-end de un tipo particular.

Los consumidores internos solo necesitan conocer el punto final estable proporcionado por el servicio. Mientras tanto, la abstracción del servicio te permite escalar o reemplazar las unidades de trabajo de back-end 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 la capacidad de descubrimiento y puedes simplificar los diseños de tus contenedores.

Utilización

Siempre que necesites proporcionar acceso a uno o más pods para otra aplicación o para consumidores externos, debes configurar un servicio.

Por ejemplo, si tienes un conjunto de pods que ejecutan servidores web a los que se debe acceder desde Internet, un servicio proporcionará la abstracción necesaria.

Del mismo modo, si tus servidores web necesitan almacenar y recuperar datos, desearías configurar un servicio interno para darles acceso a los pods de tu base de datos.

Aunque los servicios, de forma predeterminada, solo están disponibles mediante una dirección IP enrutable internamente, pueden estar disponibles fuera del clúster al elegir una de varias estrategias.

La configuración de NodePort funciona al abrir 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 mediante un servicio interno de clúster IP.

Alternativamente, el tipo de servicio LoadBalancer crea un balanceador de carga externo para enrutar al servicio utilizando la integración del balanceador de carga Kubernetes de un proveedor de la nube.

El administrador del controlador en la nube creará el recurso apropiado y lo configurará utilizando las direcciones de servicio del servicio interno.

Volúmenes y volúmenes persistentes

El hecho de compartir datos de manera confiable y garantizar su disponibilidad entre reinicios de contenedores es un desafío en muchos entornos de contenedores.

Los tiempos de ejecución de los contenedores a menudo proporcionan algún mecanismo para adjuntar el almacenamiento a un contenedor que persiste más allá de la vida útil del contenedor, pero las implementaciones generalmente carecen de flexibilidad.

Para abordar esto, Kubernetes utiliza su propia abstracción de volúmenes que permite que los datos sean compartidos por todos los contenedores dentro de un pod y permanezcan disponibles hasta que se termine el pod.

Esto significa que los pods estrechamente acoplados pueden compartir archivos fácilmente sin complejos mecanismos externos.

Las fallas en el contenedor dentro del pod no afectarán el acceso a los archivos compartidos. Una vez que se termina el pod, 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 extraer un almacenamiento más robusto que no está ligado al ciclo de vida del pod. En su lugar, permiten a los administradores configurar recursos de almacenamiento para el clúster que los usuarios pueden solicitar y reclamar para los pods que están ejecutando.

Una vez que se hace un pod 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 inmediatamente.

Los datos persistentes se pueden usar para protegerse contra fallas basadas en nodos y para asignar mayores cantidades de almacenamiento que las disponibles localmente.

Etiquetas y anotaciones

Una abstracción organizativa de Kubernetes relacionada, pero fuera de los otros conceptos, es el etiquetado.

Una etiqueta en Kubernetes es una etiqueta semántica que se puede adjuntar a los objetos Kubernetes para marcarlos como parte de un grupo. Estos pueden ser seleccionados para cuando se dirigen a diferentes instancias para administración o enrutamiento.

Por ejemplo, cada uno de los objetos basados ​​en el controlador utiliza etiquetas para identificar los pods en los que deberían operar. Los servicios usan etiquetas para comprender los pods de backend a los que deben enrutar las solicitudes.

Las etiquetas se dan como simples pares clave-valor. Cada unidad puede tener más de una etiqueta, pero cada unidad solo puede tener una entrada para cada clave.

Por lo general, una clave de “nombre” se usa como un identificador de propósito general, pero además puede clasificar los objetos por otros criterios como la 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 valor-clave a un objeto.

Si bien las etiquetas se deben usar para obtener información semántica útil para hacer coincidir un pod con los 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 enriquecidos a un objeto que no es útil para fines de selección.

Conclusión

Kubernetes es un proyecto emocionante que permite a los usuarios ejecutar cargas de trabajo en contenedores escalables y de alta disponibilidad en una plataforma altamente abstracta.

Si bien la arquitectura y el conjunto de componentes internos de Kubernetes pueden parecer desalentadores al principio, su poder, flexibilidad y conjunto de características sólidas no tienen paralelo en el mundo del código abierto.

Al comprender cómo los bloques de construcción básicos se combinan, puedes comenzar a diseñar sistemas que aprovechen completamente las capacidades de la plataforma para ejecutar y administrar tus cargas de trabajo a gran escala.