Kubernetes

De Wikipedia, la enciclopedia libre
Ir a la navegación Ir a la búsqueda
Kubernetes
kubernetes.io
Kubernetes logo.svg
Información general
Desarrollador(es) Google
Lanzamiento inicial 7 de junio de 2014
Género software y Linux Foundation Project
Programado en Go
Sistema operativo multiplataforma
Licencia Apache-2.0

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 ambientes para la ejecución contenedores, incluido Docker.

Historia[editar]

Kubernetes (“timonel” o “piloto” en griego) fue fundado por Joe Beda, Brendan Burns y Craig McLuckie[2]​, a quienes se le 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 más “amigable” Borg[6]​. 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[editar]

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]​.

Capullos (Pods)[editar]

La unidad básica de planificación en Kubernetes se denomina capullo (“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[editar]

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[editar]

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[editar]

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[editar]

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

Creación de un clúster de Kubernetes[editar]

Kubernetes coordina un grupo de computadoras 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[editar]

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[editar]

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[editar]

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[editar]

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[editar]

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[editar]

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[editar]

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[editar]

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[editar]

El planificador es el componente enchufable que selecciona sobre qué nodo un pod sin planificar (la unidad básica de manejo del planificador) deberá correr 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[editar]

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[editar]

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[editar]

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[editar]

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[editar]

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.

Referencias[editar]

  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 v3 Platform Combines Docker, Kubernetes, Atomic and More – OpenShift Blog». OpenShift Blog (en inglés estadounidense). 14 de agosto de 2014. 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. a b c d e f g h i «An Introduction to Kubernetes | DigitalOcean». www.digitalocean.com (en inglés). Consultado el 7 de julio de 2017. 
  14. a b «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. a b «Containerizing Docker on Kubernetes !!» (en inglés). 16 de septiembre de 2015. Consultado el 7 de julio de 2017. 
  17. a b «http://christianposta.com/slides/docker/generated/day2.html#/label-examples». christianposta.com (en inglés). 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. a b «Kubernetes Infrastructure - Infrastructure Components | Architecture | OpenShift Origin Latest». docs.openshift.org. Consultado el 7 de julio de 2017. 
  21. a b «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.