Aprende Kubernetes aquí: https://hackr.io/tutorials/learn …
Introducción
Kubernetes es un sistema poderoso, desarrollado por Google, para administrar aplicaciones en contenedores en un entorno agrupado. Su objetivo es proporcionar mejores formas de administrar componentes 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 y la escala.
¿Qué es Kubernetes?
Kubernetes , en su nivel básico, es un sistema para administrar aplicaciones en contenedores a través de un grupo de nodos. En muchos sentidos, Kubernetes fue diseñado para abordar la desconexión entre la forma en que se diseña la infraestructura moderna y agrupada, y algunas de las suposiciones que la mayoría de las aplicaciones y servicios tienen sobre sus entornos.
La mayoría de las tecnologías de clustering se esfuerzan por proporcionar una plataforma uniforme para el despliegue de aplicaciones. El usuario no debería tener que preocuparse mucho sobre dónde está programado el trabajo. La unidad de trabajo presentada al usuario se encuentra en el nivel de “servicio” y puede ser realizada por cualquiera de los nodos miembros.
Sin embargo, en muchos casos, sí importa cómo se ve la infraestructura subyacente. Al escalar una aplicación, a un administrador le importa que las distintas instancias de un servicio no se asignen todas al mismo host.
En el otro lado de las cosas, muchas aplicaciones distribuidas compuestas con la escala en mente están compuestas de servicios de componentes más pequeños. Estos servicios deben programarse en el mismo host que los componentes relacionados si se van a configurar de forma trivial. Esto se vuelve aún más importante cuando confían en condiciones de red específicas para comunicarse adecuadamente.
Si bien es posible con la mayoría del software de agrupación en clústeres tomar este tipo de decisiones de programación, no es ideal operar a nivel de servicios individuales. En la mayoría de los casos, las aplicaciones que comprenden diferentes servicios deben administrarse como una sola aplicación. Kubernetes proporciona una capa sobre la infraestructura para permitir este tipo de gestión.
Componentes Maestros
Los sistemas a nivel de infraestructura como CoreOS se esfuerzan por crear un entorno uniforme donde cada host sea desechable e intercambiable. Kubernetes, por otro lado, opera con un cierto nivel de especialización de host.
Los servicios de control en un grupo de Kubernetes se denominan componentes maestro o plano de control . Estos funcionan como los principales puntos de contacto de administración para los administradores, y también proporcionan muchos sistemas a nivel de clúster para los nodos de trabajo relativamente tontos. Estos servicios se pueden instalar en una sola máquina o distribuir en varias máquinas.
Los servidores que ejecutan estos componentes tienen una serie de servicios únicos que se utilizan para administrar la carga de trabajo del clúster y las comunicaciones directas a través del sistema. A continuación, cubriremos estos componentes.
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 CoreOS, es un almacén de valor clave distribuido y ligero que se puede distribuir a través de múltiples nodos.
Kubernetes utiliza etcd para almacenar datos de configuración que pueden ser utilizados por cada uno de los nodos en el clúster. Esto se puede usar para el descubrimiento del servicio y representa el estado del clúster al que cada componente puede hacer referencia para configurarse o reconfigurarse. 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 puede configurarse en un único servidor maestro o, en escenarios de producción, distribuirse entre varias máquinas. El único requisito es que la red sea accesible para cada una de las máquinas Kubernetes.
Servidor API
Uno de los servicios maestros más importantes es un servidor API. Este es el punto de administración principal de todo el clúster, ya que le permite a un usuario configurar muchas de las cargas de trabajo y unidades organizativas de Kubernetes. También es responsable de asegurarse de que la tienda etcd y los detalles de servicio de los contenedores implementados 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 REST, lo que significa que muchas herramientas y bibliotecas diferentes pueden comunicarse fácilmente con ella. Un cliente llamado kubecfg está empaquetado junto con las herramientas del lado del servidor y se puede usar desde una computadora local para interactuar con el clúster Kubernetes.
Servicio de administrador de controladores
El servicio del administrador del controlador es un servicio general que tiene muchas responsabilidades. Es responsable de una serie de controladores que regulan el estado del clúster y realizan tareas rutinarias. Por ejemplo, el controlador de replicación garantiza que la cantidad de réplicas definidas para un servicio 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.
Servicio de programador
El proceso que realmente asigna cargas de trabajo a nodos específicos en el clúster es el programador. Esto se utiliza para leer los requisitos operativos de un servicio, analizar el entorno de infraestructura actual y colocar el trabajo en un nodo o nodos aceptables.
El programador es responsable de hacer un seguimiento de la utilización de los recursos 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 los recursos totales disponibles en cada servidor, así como los recursos asignados a las cargas de trabajo existentes asignadas en cada servidor.
Componentes del Servidor Nodo
En Kubernetes, los servidores que realizan trabajo se conocen como nodos . Los servidores de nodo tienen algunos requisitos que son necesarios para comunicarse con los componentes maestros, configurar la red para contenedores y ejecutar las cargas de trabajo reales asignadas a ellos.
Docker ejecutándose en una subred dedicada
El primer requisito de cada servidor de nodo individual es la docker . El servicio de la docker se utiliza para ejecutar contenedores de aplicaciones encapsulados en un entorno operativo relativamente aislado pero liviano. Cada unidad de trabajo se implementa, en su nivel básico, como una serie de contenedores que deben implementarse.
Una suposición clave que hace Kubernetes es que una subred dedicada está disponible para cada servidor de nodo. Este no es el caso con muchas implementaciones agrupadas estándar. Por ejemplo, con CoreOS, se necesita un tejido de red separado llamado flannel para este propósito. Docker debe configurarse para usar esto de modo que pueda exponer los puertos de la manera correcta.
Servicio de Kubelet
El punto de contacto principal para cada nodo con el grupo de clústeres es a través de 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 los detalles de configuración o escribir nuevos valores.
El servicio kubelet comunica con los componentes maestros para recibir comandos y trabajar. El trabajo se recibe en forma de un “manifiesto” que define la carga de trabajo y los parámetros operativos. El proceso de kubelet asume la responsabilidad de mantener el estado del trabajo en el servidor de nodo.
Servicio de proxy
Con el fin de hacer frente a la división en subredes del host individual y para hacer que los servicios estén disponibles para terceros, se ejecuta un pequeño servicio proxy en cada servidor de nodo. Este proceso reenvía las solicitudes a los contenedores correctos, puede hacer un equilibrio de carga primitivo y generalmente es responsable de asegurarse de que el entorno de red sea predecible y accesible, pero aislado.
Unidades de Trabajo Kubernetes
Si bien los contenedores son los que se usan para implementar aplicaciones, las cargas de trabajo que definen cada tipo de trabajo son específicas de Kubernetes. Repasaremos los diferentes tipos de “trabajo” que se pueden asignar a continuación.
Vainas
Una vaina es la unidad básica con la que trata Kubernetes. Los contenedores en sí no están asignados a los hosts. En su lugar, los contenedores estrechamente relacionados se agrupan en una vaina. Un pod generalmente representa uno o más contenedores que deben ser controlados como una sola “aplicación”.
Esta asociación hace que todos los contenedores involucrados se programen en el mismo host. Se gestionan como una unidad y comparten un entorno. Esto significa que pueden compartir volúmenes y espacio de IP, y pueden implementarse y escalarse como una sola aplicación. En general, puede y debe pensar en los pods como una sola computadora virtual para poder conceptualizar mejor cómo deberían funcionar los recursos y la programación.
El diseño general de las cápsulas generalmente consiste en el contenedor principal que satisface el propósito general de la cápsula y, opcionalmente, algunos contenedores de ayuda que facilitan las tareas relacionadas. Estos son programas que se benefician de ser ejecutados y administrados en su propio contenedor, pero están fuertemente vinculados a la aplicación principal.
La escala horizontal generalmente no se recomienda en el nivel de pod porque existen otras unidades más adecuadas para la tarea.
Servicios
Hemos utilizado el término “servicio” a lo largo de esta guía de una manera muy flexible, pero Kubernetes en realidad tiene una definición muy específica para la palabra al describir las unidades de trabajo. Un servicio , cuando se describe de esta manera, es una unidad que actúa como un equilibrador de carga básico y un embajador para otros contenedores. Un servicio agrupa colecciones lógicas de pods que realizan la misma función para presentarlas como una sola entidad.
Esto le permite implementar una unidad de servicio que conoce todos los contenedores de backend para pasar el tráfico. Las aplicaciones externas solo deben preocuparse por un único punto de acceso, pero se benefician de un backend escalable o al menos un backend que puede intercambiarse cuando sea necesario. La dirección IP de un servicio permanece estable, abstrayendo cualquier cambio en las direcciones IP del pod que pueda ocurrir a medida que los nodos mueren o se reprograman los pods.
Los servicios son una interfaz para un grupo de contenedores para que los consumidores no tengan que preocuparse por nada más allá de una única ubicación de acceso. Al implementar un servicio, puede obtener fácilmente la capacidad de descubrimiento y puede simplificar los diseños de sus contenedores.
Controladores de replicación
Una versión más compleja de un pod es un pod replicado . Estos son manejados por un tipo de unidad de trabajo conocida como un controlador de replicación .
Un controlador de replicación es un marco para definir pods que están diseñados para ser escalados horizontalmente. La unidad de trabajo es, en esencia, una unidad anidada. Se proporciona una plantilla, que es básicamente una definición completa de pod. Esto se envuelve con detalles adicionales sobre el trabajo de replicación que se debe hacer.
El controlador de replicación es una responsabilidad delegada sobre el mantenimiento de un número deseado de copias. Esto significa que si un contenedor se cae temporalmente, el controlador de replicación podría iniciar otro contenedor. Si el primer contenedor vuelve a estar en línea, el controlador anulará uno de los contenedores.