Kubernetes

Kubernetes (referido en inglés comúnmente como “K8s”) es un sistema de código libre para la automatización del despliegue, ajuste de escala y manejo de aplicaciones en contenedores^[1]​ que fue originalmente diseñado por Google y donado a la Cloud Native Computing Foundation (parte de la Linux Foundation). Soporta diferentes entornos para la ejecución de contenedores, incluido Docker.

Kubernetes
Información general
Tipo de programa	Linux Foundation Project
Desarrollador	Google
Lanzamiento inicial	7 de junio de 2014
Licencia	Licencia Apache, versión 2.0
Información técnica
Programado en	Go
Versiones
Última versión en pruebas	([> info])
Asistencia técnica
Enlaces
Sitio web oficial Blog Repositorio de código
[editar datos en Wikidata]

Historia

Kubernetes (κυβερνήτης, “timonel” o “piloto” en griego) fue fundado por Joe Beda, Brendan Burns y Craig McLuckie^[2]​, a quienes se les unieron rápidamente otros ingenieros de Google incluyendo a Brian Grant y Tim Hockin, y fue anunciado por Google a mediados de 2014^[3]​. Su diseño estuvo fuertemente influenciado por el sistema Borg de Google y muchos de los principales contribuyentes al proyecto trabajaron antes en Borg.^[4]​^[5]​ El nombre en clave original para Kubernetes dentro de Google era “Project Seven” (en español “Proyecto Siete”), una referencia a un personaje de Star Trek que es un Borg^[6]​ más “amigable”. Los siete radios en la rueda del logo de Kubernetes es una referencia al nombre en clave.

Kubernetes v1.0 fue liberada el 21 de julio de 2015^[7]​. Junto a esta versión de Kubernetes, Google se asoció con la Linux Foundation para formar la Cloud Native Computing Foundation (CNCF)^[8]​ y ofreció Kubernetes como una tecnología semilla.

Rancher Labs incluye una distribución Kubernetes en su plataforma de mejoramiento de contenedores Rancher^[9]​. También está siendo utilizada por Red Hat para su producto OpenShift^[10]​^[11]​, CoreOS para su producto Tectonic, e IBM para su producto IBM Spectrum Conductor for Containers^[12]​.

Diseño

Kubernetes define un conjunto de bloques de construcción (primitivas) que conjuntamente proveen los mecanismos para el despliegue, mantenimiento y escalado de aplicaciones. Los componentes que forman Kubernetes están diseñados para estar débilmente acoplados pero a la vez ser extensibles para que puedan soportar una gran variedad de flujos de trabajo. La extensibilidad es provista en gran parte por la API de Kubernetes, que es utilizada por componentes internos así como extensiones y contenedores ejecutados sobre Kubernetes.^[13]​

Cápsulas (Pods)

La unidad básica de planificación en Kubernetes se denomina cápsula (“pod” en idioma inglés). Esta agrega un nivel de abstracción más elevado a los componentes en contenedores. Un pod consta de uno o más contenedores en los que se garantiza su ubicación en el mismo equipo anfitrión y pueden compartir recursos.^[13]​ Cada pod en Kubernetes es asignado a una única dirección IP (dentro del clúster) que permite a las aplicaciones utilizar puertos sin riesgos de conflictos.^[14]​ Un pod puede definir un volumen, como puede ser un directorio de disco local o un disco de red, y exponerlo a los contenedores dentro del pod.^[15]​. Los pods pueden ser administrados manualmente a través de la API de Kubernetes, o su administración puede ser delegada a un controlador^[13]​

Etiquetas y selectores

Kubernetes permite a los clientes (usuarios o componentes internos) vincular pares clave-valor llamados etiquetas (en inglés label) a cualquier objeto API en el sistema, como pods o nodos. Correspondientemente, selectores de etiquetas son consultas contra las etiquetas que resuelven a los objetos que las satisfacen^[13]​.

Las etiquetas y los selectores son el mecanismo principal de agrupamiento en Kubernetes, y son utilizados para determinar los componentes sobre los cuales aplica una operación.^[16]​

Por ejemplo, si un pod de una aplicación tiene la etiqueta para un nivel del sistema (“front-end”, “back-end”, por ejemplo) y un release_track (“canary”, “production”, por ejemplo), entonces una operación sobre todos los nodos “back-end” y “canary” podría utilizar un selector de etiquetas como el siguiente^[17]​:

nivel=back-end AND release_track=canary

Controladores

Un controlador es un bucle de reconciliación que lleva al estado real del clúster hacia el estado deseado.^[18]​ Hace esto mediante la administración de un conjunto de pods. Un tipo de controlador es un "Replication Controller", que se encarga de la replicación y escala mediante la ejecución de un número especificado de copias de un pod a través de un clúster. También se encarga de crear pods de reemplazo si un nodo subyacente falla.^[16]​ Otros controladores que forma parte del sistema central de Kubernetes incluye al "DaemonSet Controller" para la ejecución de exactamente un pod en cada máquina (o algún subconjunto de máquinas), y un "Job Controller" para ejecutar pods que ejecutan hasta su finalización, por ejemplo como parte de un trabajo batch.^[19]​ El conjunto de pods que un controlador administra está determinado por los selectores de etiquetas que forman parte de la definición del controlador.^[17]​

Servicios

Un servicio Kubernetes es un conjunto de pods que trabajan en conjunto, como una capa de una aplicación multicapas. El conjunto de pods que constituyen un servicio está definido por el selector de etiquetas^[13]​. Kubernetes provee de un servicio de descubrimiento y enrutamiento de pedidos mediante la asignación de una dirección IP estable y un nombre DNS al servicio, y balancea la carga de tráfico en un estilo round-robin hacia las conexiones de red de las direcciones IP entre los pods que verifican el selector (incluso cuando fallas causan que los pods se muevan de máquina en máquina).^[14]​ Por defecto un servicio es expuesto dentro de un cluster (por ejemplo, pods de un back end pueden ser agrupados en un servicio, con las peticiones de los pods de front end siendo balanceadas entre ellos), pero un servicio también puede ser expuesto hacia afuera del clúster.

Módulos básicos de Kubernetes

En forma práctica y general se describe a continuación la creación y administración de Cápsulas(Pods).^{[cita requerida]}

Creación de un clúster de Kubernetes

Kubernetes coordina un grupo de computadores de alta disponibilidad que están conectadas para funcionar como una sola unidad. Las abstracciones en Kubernetes le permiten implementar aplicaciones en contenedores en un clúster sin vincularlas específicamente a máquinas individuales. Para hacer uso de este nuevo modelo de implementación, las aplicaciones se deben empaquetar de una manera que las separe de los hosts individuales: deben estar en contenedores.

Despliegue de una aplicación

Se puede crear y administrar una implementación utilizando la interfaz de línea de comandos de Kubernetes, Kubectl. Kubectl utiliza la API de Kubernetes para interactuar con el clúster. Cuando se crea una implementación, se deberá especificar la imagen del contenedor para su aplicación y el número de réplicas que se desean ejecutar. Se puede cambiar esa información más adelante actualizando su Implementación.

Exploración de aplicaciones

Al crear una implementación, Kubernetes crea un Pod para alojar su instancia de aplicación. Un Pod es una abstracción de Kubernetes que representa un grupo de uno o más contenedores de aplicaciones (como Docker o rkt), y algunos recursos compartidos para esos contenedores.

Mantenimiento de Pods

Los pods Kubernetes son mortales. Los pods de hecho tienen un ciclo de vida. Cuando un nodo trabajador "muere", los pods que se ejecutan en el nodo también se pierden. Luego, un controlador de replicación puede hacer que el clúster regrese dinámicamente al estado deseado mediante la creación de nuevos pods para mantener su aplicación en ejecución.

Ampliación de aplicaciones

Al crear un Despliegue se expone públicamente a través de un Servicio. La implementación creó solo un pod para ejecutar nuestra aplicación. Cuando el tráfico aumenta, se debe escalar (aumentar en recursos y número) la aplicación para satisfacer la demanda de los usuarios. El escalado se realiza cambiando el número de réplicas en una implementación.

Actualización de aplicaciones

Los usuarios esperan que las aplicaciones estén disponibles todo el tiempo y se espera que los desarrolladores implementen nuevas versiones de ellas varias veces al día. En Kubernetes esto se hace con actualizaciones sucesivas. Las actualizaciones continuas permiten que la actualización de Implementaciones tenga lugar sin tiempo de inactividad al actualizar incrementalmente las instancias de pods con otras nuevas. Los nuevos Pods serán programados en Nodos con recursos disponibles.

Arquitectura

Kubernetes sigue una arquitectura maestro-esclavo. Los componentes de Kubernetes pueden ser divididos en aquellos que administran un nodo individual y aquellos que son partes de un panel de control^[20]​^[13]​.

etcd

etcd es un almacén de datos persistente, liviano, distribuido de clave-valor desarrollado por CoreOS que almacena de manera confiable los datos de configuración del clúster, representando el estado general del cluster en un punto del tiempo dado. Otros componentes escuchan por cambios en este almacén para avanzar al estado deseado^[20]​.

Servidor de API

El servidor API es un componente central y sirve a la API de Kubernetes utilizando JSON sobre HTTP, que proveen la interfaz interna y externa de Kubernetes^[13]​^[21]​. El servidor API procesa y valida las peticiones REST y actualiza el estado de los objetos API en etcd, así permitiendo a los clientes configurar flujos de trabajos y contenedores a través de los nodos esclavos.

Planificador

El planificador es el componente enchufable que selecciona sobre qué nodo deberá correr un pod sin planificar (la unidad básica de manejo del planificador) basado en la disponibilidad de recursos. El planificador lleva la cuenta de la utilización de recursos en cada nodo para asegurar que un flujo de trabajo no es planificado en exceso de la disponibilidad de los recursos. Para este propósito, el planificador debe conocer los requerimientos de recursos, la disponibilidad de recursos y una variedad de restricciones y políticas directivas como quality-of-service (QoS), requerimiento de afinidad, localización de datos entre otros. En esencia, el rol del planificador es el de emparejar la oferta de un recurso con la demanda de un flujo de trabajos.^[22]​

Administrador del controlador

El administrador de controlador es el proceso sobre el cual el núcleo de los controladores Kubernetes como DaemonSet y Replication se ejecuta. Los controladores se comunican con el servidor API para crear, actualizar y eliminar recursos que ellos manejan (pods, servicios, etc.)^[21]​.

Nodo Kubernetes

El nodo, también conocido como esclavo o worker, es la máquina física (o virtual) donde los contenedores (flujos de trabajos) son desplegados. Cada nodo en el clúster debe ejecutar la rutina de tiempo de ejecución (como Docker), así como también los componentes mencionados más abajo, para comunicarse con el maestro para la configuración en red de estos contenedores.

Kubelet

Kubelet es responsable por el estado de ejecución de cada nodo (es decir, asegurarse que todos los contenedores en el nodo se encuentran saludables). Se encarga del inicio, la detención y el mantenimiento de los contenedores de aplicaciones (organizados como pods) como es indicado por el panel de control^[13]​^[23]​.

Kubelet monitorea el estado de un pod y, si no se encuentra en el estado deseado, el pod será desplegado nuevamente al mismo nodo. El estado del nodo es comunicado al maestro cada pocos segundos mediante una señal periódica ("heartbeat"). Una vez que el nodo detecta la falla de un nodo, el Replication Controller observa este cambio de estado y lanza pods en otros nodos sanos.

Kube-Proxy

Kube-Proxy es la implementación de un proxy de red y balanceador de carga soportando la abstracción del servicio junto con otras operaciones de red^[13]​. Es responsable del enrutamiento del tráfico hacia el contenedor correcto basado en la dirección IP y el número de puerto indicados en el pedido.

cAdvisor

cAdvisor es un agente que monitorea y recoge métricas de utilización de recursos y rendimiento como CPU, memoria, uso de archivos y red de los contenedores en cada nodo.

Véase también

• LXC

Referencias

1. kubernetes: Production-Grade Container Scheduling and Management, Kubernetes, 7 de julio de 2017, consultado el 7 de julio de 2017 .
2. «Google Made Its Secret Blueprint Public to Boost Its Cloud». WIRED (en inglés estadounidense). Consultado el 7 de julio de 2017. 
3. «Google Open Sources Its Secret Weapon in Cloud Computing». WIRED (en inglés estadounidense). Consultado el 7 de julio de 2017. 
4. Verma, Abhishek; Pedrosa, Luis; Korupolu, Madhukar R.; Oppenheimer, David; Tune, Eric; Wilkes, John (2015). Large-scale cluster management at Google with Borg (en inglés). Consultado el 7 de julio de 2017. 
5. «Borg, Omega, and Kubernetes - ACM Queue». queue.acm.org. Consultado el 7 de julio de 2017. 
6. «Early Stage Startup Heptio Aims to Make Kubernetes Friendly». eWEEK (en inglés estadounidense). Consultado el 7 de julio de 2017. 
7. Lardinois, Frederic. «As Kubernetes Hits 1.0, Google Donates Technology To Newly Formed Cloud Native Computing Foundation | TechCrunch». Consultado el 7 de julio de 2017. 
8. «Home - Cloud Native Computing Foundation». Cloud Native Computing Foundation (en inglés estadounidense). Consultado el 7 de julio de 2017. 
9. «Enterprise-grade Kubernetes Distribution | Rancher Labs». Rancher Labs (en inglés estadounidense). Consultado el 7 de julio de 2017. 
10. . OpenShift Blog (en inglés estadounidense). 14 de agosto de 2014. Archivado desde el original el 6 de julio de 2015. Consultado el 7 de julio de 2017. 
11. «Why Red Hat Chose Kubernetes for OpenShift – OpenShift Blog». OpenShift Blog (en inglés estadounidense). 7 de noviembre de 2016. Consultado el 7 de julio de 2017. 
12. «Welcome to Wikis». www.ibm.com (en inglés). 20 de octubre de 2009. Consultado el 7 de julio de 2017. 
13. «An Introduction to Kubernetes | DigitalOcean». www.digitalocean.com (en inglés). Consultado el 7 de julio de 2017. 
14. «Kubernetes 101 – Networking». Das Blinken Lichten (en inglés estadounidense). 12 de febrero de 2015. Consultado el 7 de julio de 2017. 
15. Strachan, James (21 de mayo de 2015). «Kubernetes for developers». fabric8 io. Consultado el 7 de julio de 2017. 
16. «Containerizing Docker on Kubernetes !!» (en inglés). 16 de septiembre de 2015. Consultado el 7 de julio de 2017. 
17. . christianposta.com (en inglés). Archivado desde el original el 29 de octubre de 2015. Consultado el 7 de julio de 2017. 
18. «CoreOS». coreos.com (en inglés). Consultado el 7 de julio de 2017. 
19. «LiveWyer | Kubernetes & Cloud Native Computing Experts | Kubernetes: Exciting Experimental Features». www.livewyer.com (en inglés). Consultado el 7 de julio de 2017. 
20. . docs.openshift.org. Archivado desde el original el 6 de julio de 2015. Consultado el 7 de julio de 2017. 
21. «Kubernetes from the ground up: the API server». kamalmarhubi.com. Consultado el 7 de julio de 2017. 
22. «The Three Pillars of Kubernetes Container Orchestration | Rancher Labs». Rancher Labs (en inglés estadounidense). 18 de mayo de 2017. Consultado el 7 de julio de 2017. 
23. «What even is a kubelet?». kamalmarhubi.com. Consultado el 7 de julio de 2017. 

24. HPE Container Platform, una plataforma de contenedores unificada basada en Kubernetes de código abierto

•   Datos: Q22661306
•   Multimedia: Kubernetes