Kubernetes ( / ˌ k ( j ) uː b ər ˈ n ɛ t ɪ s , - ˈ n eɪ t ɪ s , - ˈ n eɪ t iː z , - ˈ n ɛ t iː z / , K8s ) [3] es un sistema de orquestación de contenedores de código abierto para automatizar la implementación , escalado y gestión de software . [4] [5] Originalmente diseñado por Google , el proyecto ahora es mantenido por una comunidad mundial de colaboradores, y la marca registrada pertenece a la Cloud Native Computing Foundation .
El nombre Kubernetes proviene del griego κυβερνήτης (kubernḗtēs), que significa gobernador, ' timonel ' o 'piloto'. Kubernetes suele abreviarse como K8s , contando las ocho letras entre la K y la s (un numerónimo ). [6]
Kubernetes ensambla una o más computadoras, ya sean máquinas virtuales o hardware , en un clúster que puede ejecutar cargas de trabajo en contenedores. Funciona con varios entornos de ejecución de contenedores, como ContainerD y CRI-O . [7] Su idoneidad para ejecutar y administrar cargas de trabajo de todos los tamaños y estilos ha llevado a su adopción generalizada en nubes y centros de datos. Existen múltiples distribuciones de esta plataforma, de proveedores de software independientes (ISV), así como ofertas alojadas en la nube de todos los principales proveedores de nube pública. [8]
Kubernetes es uno de los sistemas de software más implementados en el mundo [9] y lo utilizan empresas como Google , Microsoft , Amazon , Apple , Meta , Nvidia , Reddit y Pinterest .
Kubernetes ( griego antiguo : κυβερνήτης , romanizado : kubernḗtēs , ' timonel, navegante ' o ' guía ' , y la raíz etimológica de cibernética ) [5] fue anunciado por Google el 6 de junio de 2014. [10] El proyecto fue concebido y creado por los empleados de Google Joe Beda, Brendan Burns y Craig McLuckie. Otros en Google pronto se unieron para ayudar a construir el proyecto, incluidos Ville Aikas, Dawn Chen, Brian Grant, Tim Hockin y Daniel Smith. [11] [12] Otras empresas como Red Hat y CoreOS se unieron al esfuerzo poco después, con contribuyentes notables como Clayton Coleman y Kelsey Hightower . [10]
El diseño y desarrollo de Kubernetes se inspiró en el administrador de clústeres Borg de Google y se basó en la teoría de promesas . [13] [14] Muchos de sus principales contribuyentes habían trabajado previamente en Borg; [15] [16] bautizaron a Kubernetes como " Proyecto 7 " en honor al personaje ex Borg de Star Trek Siete de Nueve [17] y le dieron a su logotipo un timón de barco de siete radios (diseñado por Tim Hockin). A diferencia de Borg, que fue escrito en C++ , [15] Kubernetes está escrito en el lenguaje Go .
Kubernetes se anunció en junio de 2014 y la versión 1.0 se lanzó el 21 de julio de 2015. [18] Google trabajó con la Linux Foundation para formar la Cloud Native Computing Foundation (CNCF) [19] y ofreció Kubernetes como tecnología semilla.
Google ya ofrecía un servicio de Kubernetes administrado, GKE , y Red Hat respaldaba a Kubernetes como parte de OpenShift desde el inicio del proyecto Kubernetes en 2014. [20] En 2017, los principales competidores se unieron en torno a Kubernetes y anunciaron que agregarían soporte nativo para él:
El 6 de marzo de 2018, el Proyecto Kubernetes alcanzó el noveno lugar en la lista de proyectos de GitHub por número de confirmaciones y el segundo lugar en autores y problemas, después del kernel de Linux . [26]
Hasta la versión 1.18, Kubernetes seguía una política de soporte N-2, lo que significa que las tres versiones menores más recientes reciben actualizaciones de seguridad y correcciones de errores. [27] A partir de la versión 1.19, Kubernetes sigue una política de soporte N-3. [28]
Kubernetes define un conjunto de bloques de construcción ("primitivos") que colectivamente proporcionan mecanismos que implementan, mantienen y escalan aplicaciones basadas en CPU , memoria [29] o métricas personalizadas. [30] Kubernetes está acoplado de forma flexible y es extensible para satisfacer las necesidades de diferentes cargas de trabajo. Los componentes internos, así como las extensiones y los contenedores que se ejecutan en Kubernetes, dependen de la API de Kubernetes. [31] La plataforma ejerce su control sobre los recursos de cómputo y almacenamiento al definir los recursos como objetos, que luego se pueden administrar como tales.
Kubernetes sigue la arquitectura principal/réplica . Los componentes de Kubernetes se pueden dividir en aquellos que administran un nodo individual y aquellos que forman parte del plano de control. [31] [32]
El nodo maestro de Kubernetes maneja el plano de control de Kubernetes del clúster, administrando su carga de trabajo y dirigiendo la comunicación a través del sistema. El plano de control de Kubernetes consta de varios componentes, como el cifrado TLS , RBAC y un método de autenticación fuerte , separación de red, cada uno con su propio proceso, que puede ejecutarse tanto en un solo nodo maestro como en varios maestros que admiten clústeres de alta disponibilidad . [32] Los diversos componentes del plano de control de Kubernetes son los siguientes. [33]
Etcd [34] es un almacén de datos de clave-valor distribuido, ligero y persistente(desarrollado originalmente para Container Linux ). Almacena de forma fiable los datos de configuración del clúster, lo que representa el estado general del clúster en un momento determinado. etcd prioriza la coherencia sobre la disponibilidad en caso de una partición de la red (consulte el teorema CAP ). La coherencia es crucial para programar y operar los servicios correctamente.
El servidor API sirve a la API de Kubernetes usando JSON sobre HTTP , que proporciona tanto la interfaz interna como la externa a Kubernetes. [31] [35] El servidor API procesa, valida solicitudes REST y actualiza el estado de los objetos API en etcd, lo que permite a los clientes configurar cargas de trabajo y contenedores en los nodos de trabajo. [36] El servidor API usa la API de vigilancia de etcd para monitorear el clúster, implementar cambios de configuración críticos o restaurar cualquier divergencia del estado del clúster al estado deseado según lo declarado en etcd.
Por ejemplo, un operador humano puede especificar que se deben ejecutar tres instancias de un "pod" en particular (ver a continuación), y etcd almacena este hecho. Si el controlador de implementación descubre que solo se están ejecutando dos instancias (lo que entra en conflicto con la declaración de etcd), [37] programa la creación de una instancia adicional de ese pod. [32]
El planificador es un componente extensible que selecciona el nodo en el que se ejecuta un pod no programado (la unidad básica de cargas de trabajo que se programarán), en función de la disponibilidad de recursos y otras restricciones. El planificador realiza un seguimiento de la asignación de recursos en cada nodo para garantizar que la carga de trabajo no se programe en exceso de los recursos disponibles. Para este propósito, el planificador debe conocer los requisitos de recursos, la disponibilidad de recursos y otras restricciones o directivas de políticas proporcionadas por el usuario, como la calidad del servicio, los requisitos de afinidad/antiafinidad y la localidad de los datos. La función del planificador es hacer coincidir la "oferta" de recursos con la "demanda" de la carga de trabajo. [38]
Kubernetes permite ejecutar varios programadores dentro de un solo clúster. Por lo tanto, los complementos del programador se pueden desarrollar e instalar como extensiones en proceso del programador original nativo al ejecutarlo como un programador independiente, siempre que se ajusten al marco de programación de Kubernetes. [39] Esto permite a los administradores de clústeres extender o modificar el comportamiento del programador predeterminado de Kubernetes según sus necesidades.
Un controlador es un bucle de reconciliación que impulsa el estado actual del clúster hacia el estado deseado, comunicándose con el servidor API para crear, actualizar y eliminar los recursos que administra (por ejemplo, pods o puntos finales de servicio). [40] [35]
Un controlador de ejemplo es un controlador ReplicaSet, que maneja la replicación y el escalamiento ejecutando una cantidad específica de copias de un pod en todo el clúster. El controlador también maneja la creación de pods de reemplazo si el nodo subyacente falla. [40] Otros controladores que forman parte del sistema central de Kubernetes incluyen un controlador DaemonSet para ejecutar exactamente un pod en cada máquina (o algún subconjunto de máquinas) y un controlador de trabajos para ejecutar pods que se ejecutan hasta su finalización (por ejemplo, como parte de un trabajo por lotes). [41] Los selectores de etiquetas a menudo forman parte de la definición del controlador que especifica el conjunto de pods que administra un controlador. [42]
El administrador del controlador es un proceso único que administra varios controladores centrales de Kubernetes (incluidos los ejemplos descritos anteriormente), se distribuye como parte de la instalación estándar de Kubernetes y responde a la pérdida de nodos. [33]
También se pueden instalar controladores personalizados en el clúster, lo que permite ampliar aún más el comportamiento y la API de Kubernetes cuando se utilizan junto con recursos personalizados (consulte recursos, controladores y operadores personalizados a continuación).
Un nodo, también conocido como trabajador o minion, es una máquina en la que se implementan contenedores (cargas de trabajo). Cada nodo del clúster debe ejecutar un entorno de ejecución de contenedores , así como los componentes mencionados a continuación, para comunicarse con la configuración de red principal de estos contenedores.
kubelet es responsable del estado de ejecución de cada nodo, garantizando que todos los contenedores en el nodo estén en buen estado. Se encarga de iniciar, detener y mantener los contenedores de aplicaciones organizados en pods según lo indicado por el plano de control. [31] [43] kubelet monitorea el estado de un pod y, si no está en el estado deseado, el pod se vuelve a implementar en el mismo nodo. El estado del nodo se transmite cada pocos segundos a través de mensajes de latido al servidor API. Una vez que el plano de control detecta una falla en el nodo, se espera que un controlador de nivel superior observe este cambio de estado y lance pods en otro nodo en buen estado. [44]
Un entorno de ejecución de contenedores es responsable del ciclo de vida de los contenedores, incluido el lanzamiento, la conciliación y la eliminación de los contenedores. kubelet interactúa con los entornos de ejecución de contenedores a través de la Interfaz de entorno de ejecución de contenedores (CRI), [45] [46] que desacopla el mantenimiento del núcleo de Kubernetes de la implementación real de la CRI.
Originalmente, kubelet interactuaba exclusivamente con el entorno de ejecución de Docker [47] a través de un "dockershim". Sin embargo, desde noviembre de 2020 [48] hasta abril de 2022, Kubernetes ha dejado de usar el shim en favor de interactuar directamente con el contenedor a través de Containerd, o reemplazar Docker con un entorno de ejecución que sea compatible con la Interfaz de entorno de ejecución de contenedores (CRI). [49] [45] [50] Con el lanzamiento de la versión 1.24 en mayo de 2022, el "dockershim" se ha eliminado por completo. [51]
Algunos ejemplos de entornos de ejecución de contenedores populares que son compatibles con kubelet incluyen contenedord (inicialmente compatible a través de Docker), rkt [52] y CRI-O .
kube-proxy es una implementación de un proxy de red y un balanceador de carga , y admite la abstracción de servicios junto con otras operaciones de red. [31] Es responsable de enrutar el tráfico al contenedor apropiado según la IP y el número de puerto de la solicitud entrante.
En Kubernetes, los espacios de nombres se utilizan para segregar los recursos que maneja en colecciones distintas y que no se cruzan. [53] Están pensados para usarse en entornos con muchos usuarios distribuidos en varios equipos o proyectos, o incluso en entornos separados como desarrollo, prueba y producción.
La unidad de programación básica en Kubernetes es un pod , [54] que consta de uno o más contenedores que se garantiza que estarán ubicados en el mismo nodo. [31] A cada pod en Kubernetes se le asigna una dirección IP única dentro del clúster, lo que permite que las aplicaciones usen puertos sin riesgo de conflicto. [55] Dentro del pod, todos los contenedores pueden hacer referencia entre sí.
Un contenedor reside dentro de un pod. El contenedor es el nivel más bajo de un microservicio, que contiene la aplicación en ejecución, las bibliotecas y sus dependencias.
Kubernetes admite varias abstracciones de cargas de trabajo que se encuentran en un nivel superior a los pods simples. Esto permite a los usuarios definir y administrar de manera declarativa estas abstracciones de alto nivel, en lugar de tener que administrar pods individuales por sí mismos. A continuación, se describen varias de estas abstracciones, compatibles con una instalación estándar de Kubernetes.
El propósito de un ReplicaSet es mantener un conjunto estable de pods de réplica ejecutándose en un momento dado. Como tal, a menudo se utiliza para garantizar la disponibilidad de una cantidad específica de pods idénticos. [56] También se puede decir que el ReplicaSet es un mecanismo de agrupación que permite a Kubernetes mantener la cantidad de instancias que se han declarado para un pod determinado. La definición de un ReplicaSet utiliza un selector, cuya evaluación dará como resultado la identificación de todos los pods que están asociados con él.
Un ReplicationController , similar a un ReplicaSet, cumple la misma función y se comporta de manera similar a un ReplicaSet, que es garantizar que siempre habrá una cantidad específica de réplicas de pod según lo deseado. La carga de trabajo ReplicationController fue la predecesora de un ReplicaSet, pero finalmente se dejó de usar en favor de ReplicaSet para hacer uso de selectores de etiquetas basados en conjuntos. [56]
Las implementaciones son un mecanismo de gestión de nivel superior para los ReplicaSets. Mientras que el controlador del ReplicaSet gestiona la escala del ReplicaSet, el controlador de la implementación gestiona lo que sucede con el ReplicaSet (si se debe implementar una actualización, revertirla, etc.). Cuando las implementaciones se escalan hacia arriba o hacia abajo, esto da como resultado un cambio en la declaración del ReplicaSet, y este cambio en el estado declarado es gestionado por el controlador del ReplicaSet. [37]
Los StatefulSets son controladores que imponen las propiedades de unicidad y ordenamiento entre instancias de un pod, y se pueden usar para ejecutar aplicaciones con estado . [57] Si bien escalar aplicaciones sin estado es solo una cuestión de agregar más pods en ejecución, hacerlo para cargas de trabajo con estado es más difícil, porque el estado debe conservarse si se reinicia un pod. Si la aplicación se escala hacia arriba o hacia abajo, es posible que sea necesario redistribuir el estado.
Las bases de datos son un ejemplo de cargas de trabajo con estado. Cuando se ejecutan en modo de alta disponibilidad, muchas bases de datos incluyen la noción de una instancia principal y de instancias secundarias. En este caso, la noción de ordenación de las instancias es importante. Otras aplicaciones, como Apache Kafka, distribuyen los datos entre sus intermediarios; por lo tanto, un intermediario no es igual a otro. En este caso, la noción de unicidad de instancia es importante.
Los DaemonSets son responsables de garantizar que se cree un pod en cada nodo individual del clúster. [58] Generalmente, la mayoría de las cargas de trabajo se escalan en respuesta a un recuento de réplicas deseado, según los requisitos de disponibilidad y rendimiento que necesite la aplicación. Sin embargo, en otros escenarios puede ser necesario implementar un pod en cada nodo individual del clúster, aumentando la cantidad total de pods a medida que se agregan nodos y recogiéndolos como basura a medida que se eliminan. Esto es particularmente útil para los casos de uso en los que la carga de trabajo tiene cierta dependencia del nodo real o la máquina host, como la recopilación de registros, los controladores de ingreso y los servicios de almacenamiento.
Un servicio de Kubernetes es un conjunto de pods que funcionan juntos, como un nivel de una aplicación de varios niveles . El conjunto de pods que constituyen un servicio se define mediante un selector de etiquetas. [31] Kubernetes proporciona dos modos de descubrimiento de servicios , utilizando variables de entorno o utilizando DNS de Kubernetes. [59] El descubrimiento de servicios asigna una dirección IP estable y un nombre DNS al servicio, y equilibra la carga del tráfico de manera rotatoria para las conexiones de red de esa dirección IP entre los pods que coinciden con el selector (incluso cuando las fallas hacen que los pods se muevan de una máquina a otra). [55] De manera predeterminada, un servicio se expone dentro de un clúster (por ejemplo, los pods del back-end pueden agruparse en un servicio, con solicitudes de los pods del front-end equilibradas entre ellos), pero un servicio también puede exponerse fuera de un clúster (por ejemplo, para que los clientes lleguen a los pods del front-end). [60]
Los sistemas de archivos en el contenedor de Kubernetes proporcionan almacenamiento efímero de forma predeterminada. Esto significa que un reinicio del pod borrará todos los datos de dichos contenedores y, por lo tanto, esta forma de almacenamiento es bastante limitante en cualquier aplicación que no sea trivial. Un volumen de Kubernetes [61] proporciona almacenamiento persistente que existe durante la vida útil del propio pod. Este almacenamiento también se puede utilizar como espacio de disco compartido para contenedores dentro del pod. Los volúmenes se montan en puntos de montaje específicos dentro del contenedor, que están definidos por la configuración del pod, y no se pueden montar en otros volúmenes ni vincularse a otros volúmenes. El mismo volumen se puede montar en diferentes puntos del árbol del sistema de archivos por diferentes contenedores.
Un desafío común de las aplicaciones es decidir dónde almacenar y administrar la información de configuración, parte de la cual puede contener datos confidenciales. Los datos de configuración pueden ser cualquier cosa, desde información de granularidad fina como propiedades individuales hasta información de granularidad gruesa como archivos de configuración completos, como documentos JSON o XML . Kubernetes proporciona dos mecanismos estrechamente relacionados para abordar esta necesidad, conocidos como ConfigMaps y Secrets , que permiten realizar cambios de configuración sin necesidad de reconstruir la aplicación.
Los datos de los ConfigMaps y los Secrets estarán disponibles para cada una de las instancias de la aplicación a las que se han vinculado estos objetos mediante la implementación. Un Secret o un ConfigMap se envía a un nodo solo si un pod en ese nodo lo requiere, y este solo se almacenará en la memoria del nodo. Una vez que se elimina el pod que depende del Secret o del ConfigMap, también se elimina la copia en memoria de todos los Secrets y ConfigMaps vinculados.
Los datos de un ConfigMap o Secret son accesibles para el pod a través de una de las siguientes maneras: [62]
La mayor diferencia entre un secreto y un ConfigMap es que los secretos están diseñados específicamente para contener datos seguros y confidenciales, aunque no están cifrados en reposo de forma predeterminada y requieren una configuración adicional para asegurar completamente el uso de secretos dentro del clúster. [63] Los secretos se utilizan a menudo para almacenar datos confidenciales o sensibles como certificados, credenciales para trabajar con registros de imágenes, contraseñas y claves ssh .
Kubernetes permite a los clientes (usuarios o componentes internos) adjuntar claves llamadas etiquetas a cualquier objeto API en el sistema, como pods y nodos. En consecuencia, los selectores de etiquetas son consultas contra etiquetas que se resuelven en objetos coincidentes. [31] Cuando se define un servicio, se pueden definir los selectores de etiquetas que utilizará el enrutador de servicio/balanceador de carga para seleccionar las instancias de pod a las que se enrutará el tráfico. Por lo tanto, simplemente cambiar las etiquetas de los pods o cambiar los selectores de etiquetas en el servicio se puede utilizar para controlar qué pods reciben tráfico y cuáles no, lo que se puede utilizar para admitir varios patrones de implementación como implementaciones azul-verde o pruebas A/B . Esta capacidad de controlar dinámicamente cómo los servicios utilizan los recursos de implementación proporciona un acoplamiento flexible dentro de la infraestructura.
Por ejemplo, si los pods de una aplicación tienen etiquetas para un sistema tier(con valores como frontend, backend, por ejemplo) y un release_track(con valores como canary, production, por ejemplo), entonces una operación en todos los nodos backendy canarypuede usar un selector de etiquetas, como: [42]
tier=backend AND release_track=canary
Al igual que las etiquetas, los selectores de campo también permiten seleccionar recursos de Kubernetes. A diferencia de las etiquetas, la selección se basa en los valores de los atributos inherentes al recurso que se selecciona, en lugar de en la categorización definida por el usuario. metadata.namey metadata.namespaceson selectores de campo que estarán presentes en todos los objetos de Kubernetes. Otros selectores que se pueden utilizar dependen del tipo de objeto o recurso.
Los complementos son funciones adicionales del clúster de Kubernetes que se implementan como aplicaciones que se ejecutan en él. Los pods pueden administrarse mediante implementaciones, controladores de replicación, etc. Hay muchos complementos. Algunos de los más importantes son:
Los contenedores surgieron como una forma de hacer que el software sea portátil. El contenedor contiene todos los paquetes necesarios para ejecutar un servicio. El sistema de archivos proporcionado hace que los contenedores sean extremadamente portátiles y fáciles de usar en el desarrollo. Un contenedor se puede trasladar del desarrollo al de prueba o producción sin cambios de configuración o con relativamente pocos.
Históricamente, Kubernetes solo era adecuado para servicios sin estado. Sin embargo, muchas aplicaciones tienen una base de datos que requiere persistencia, lo que lleva a la creación de almacenamiento persistente para Kubernetes. Implementar almacenamiento persistente para contenedores es uno de los principales desafíos de los administradores de Kubernetes, DevOps e ingenieros de la nube. Los contenedores pueden ser efímeros, pero cada vez más de sus datos no lo son, por lo que es necesario garantizar la supervivencia de los datos en caso de que el contenedor se interrumpa o falle el hardware. Al implementar contenedores con Kubernetes o aplicaciones en contenedores, las organizaciones a menudo se dan cuenta de que necesitan almacenamiento persistente. Necesitan proporcionar almacenamiento rápido y confiable para bases de datos, imágenes raíz y otros datos utilizados por los contenedores.
Además del panorama, la Cloud Native Computing Foundation (CNCF) ha publicado otra información sobre el almacenamiento persistente de Kubernetes, incluido un blog que ayuda a definir el patrón de almacenamiento adjunto a contenedores. Este patrón puede considerarse como uno que utiliza el propio Kubernetes como un componente del sistema o servicio de almacenamiento. [64]
También se puede encontrar más información sobre la popularidad relativa de estos y otros enfoques en la encuesta de panorama de CNCF, que mostró que OpenEBS, una plataforma de almacenamiento persistente con estado de Datacore Software, [65] y Rook, un proyecto de orquestación de almacenamiento, eran los dos proyectos con más probabilidades de estar en evaluación a partir del otoño de 2019. [66]
El almacenamiento conectado a contenedores es un tipo de almacenamiento de datos que surgió a medida que Kubernetes ganaba importancia. El enfoque o patrón de almacenamiento conectado a contenedores se basa en el propio Kubernetes para determinadas capacidades, al tiempo que ofrece principalmente bloques, archivos, objetos e interfaces a las cargas de trabajo que se ejecutan en Kubernetes. [67]
Los atributos comunes del almacenamiento conectado a contenedores incluyen el uso de extensiones para Kubernetes, como definiciones de recursos personalizadas, y el uso del propio Kubernetes para funciones que, de otro modo, se desarrollarían e implementarían por separado para el almacenamiento o la gestión de datos. Entre los ejemplos de funcionalidades proporcionadas por definiciones de recursos personalizadas o por el propio Kubernetes se incluyen la lógica de reintento, proporcionada por el propio Kubernetes, y la creación y el mantenimiento de un inventario de medios y volúmenes de almacenamiento disponibles, que normalmente se entregan a través de una definición de recursos personalizada. [68] [69]
En la versión 1.9 de Kubernetes, se introdujo la versión Alpha inicial de Container Storage Interface (CSI). [70] Anteriormente, los complementos de volumen de almacenamiento se incluían en la distribución de Kubernetes. Al crear una CSI estandarizada, el código necesario para interactuar con sistemas de almacenamiento externo se separó de la base de código principal de Kubernetes. Solo un año después, la función CSI se puso a disposición del público en general (GA) en Kubernetes. [71]
Un componente clave del plano de control de Kubernetes es el servidor API, que expone una API HTTP que puede ser invocada por otras partes del clúster, así como por usuarios finales y componentes externos. Esta API es una API REST y es declarativa por naturaleza, y es la misma API expuesta al plano de control. [72] El servidor API está respaldado por etcd para almacenar todos los registros de forma persistente. [73]
En Kubernetes, todos los objetos sirven como " registro de intención " del estado del clúster y pueden definir el estado deseado en el que el escritor del objeto desea que se encuentre el clúster. [74] Como tal, la mayoría de los objetos de Kubernetes tienen el mismo conjunto de campos anidados, como se muestra a continuación:
spec:Describe el estado deseado del recurso, que puede ser controlado por los usuarios finales u otros controladores de nivel superior;status:Describe el estado actual del recurso, que se actualiza activamente por el controlador del recurso.Todos los objetos de Kubernetes están sujetos a las mismas convenciones de API. Algunas de ellas son:
metadata: [75]namespace:una etiqueta en la que se subdividen los objetos;name:una cadena que identifica de forma única el objeto dentro del espacio de nombres definido;uid:una cadena única que puede distinguir entre objetos con el mismo nombre en el espacio y el tiempo (incluso entre eliminaciones y recreaciones con el mismo nombre).metadata.ownerReferencescampo: [76]controllercampo.La API de Kubernetes se puede ampliar mediante recursos personalizados , que representan objetos que no forman parte de la instalación estándar de Kubernetes. Estos recursos personalizados se declaran mediante definiciones de recursos personalizados (CRD), que es un tipo de recurso que se puede registrar y anular de forma dinámica sin apagar ni reiniciar un clúster que se esté ejecutando actualmente. [78]
Los controladores personalizados son otro mecanismo de extensión que interactúa con la API de Kubernetes, de forma similar a los controladores predeterminados en el administrador de controladores de Kubernetes estándar preinstalado. Estos controladores pueden interactuar con recursos personalizados para permitir una API declarativa: los usuarios pueden declarar el estado deseado del sistema a través de los recursos personalizados, y es responsabilidad del controlador personalizado observar el cambio y conciliarlo.
La combinación de recursos y controladores personalizados suele denominarse operador de Kubernetes . El caso de uso clave para los operadores es captar el objetivo de un operador humano que administra un servicio o un conjunto de servicios e implementarlos mediante la automatización, y con una API declarativa que respalde esta automatización. Los operadores humanos que se encargan de aplicaciones y servicios específicos tienen un conocimiento profundo de cómo debe comportarse el sistema, cómo implementarlo y cómo reaccionar si hay problemas.
Algunos ejemplos de problemas que resuelven los operadores incluyen la realización y restauración de copias de seguridad del estado de esa aplicación y el manejo de actualizaciones del código de la aplicación junto con cambios relacionados, como esquemas de bases de datos o configuraciones adicionales. Varios proyectos notables bajo el programa de incubación de la Cloud Native Computing Foundation siguen el patrón del operador para extender Kubernetes, incluidos Argo, Open Policy Agent e Istio. [79]
Kubernetes define las siguientes estrategias para controlar el acceso a su API. [80]
El servidor API de Kubernetes escucha en un puerto TCP que sirve tráfico HTTPS , para aplicar la seguridad de la capa de transporte (TLS) mediante certificados CA. [ 33]
En versiones anteriores de Kubernetes, el servidor API admitía la escucha en puertos HTTP y HTTPS (el número de puerto HTTP no tenía ningún tipo de seguridad de transporte). Esto quedó obsoleto en la v1.10 y finalmente dejó de ser compatible en la v1.20 de Kubernetes. [81]
Se espera que todas las solicitudes realizadas al servidor API de Kubernetes estén autenticadas y admite varias estrategias de autenticación, algunas de las cuales se enumeran a continuación: [82]
Por lo general, se espera que los usuarios indiquen y definan los detalles de la URL del clúster junto con las credenciales necesarias en un archivo kubeconfig , que son compatibles de forma nativa con otras herramientas de Kubernetes como kubectl y las bibliotecas de cliente oficiales de Kubernetes. [83]
La API de Kubernetes admite los siguientes modos de autorización: [84]
Kubernetes admite varios clientes API oficiales:
Los mismos principios de diseño de API se han utilizado para definir una API para aprovechar un programa con el fin de crear, configurar y administrar clústeres de Kubernetes. Esto se llama API de clúster. [87] Un concepto clave incorporado en la API es el uso de la infraestructura como software , o la noción de que la infraestructura del clúster de Kubernetes es en sí misma un recurso/objeto que se puede administrar como cualquier otro recurso de Kubernetes. De manera similar, las máquinas que componen el clúster también se tratan como un recurso de Kubernetes. La API tiene dos partes: la API principal y una implementación del proveedor. La implementación del proveedor consta de funciones específicas del proveedor de la nube que permiten a Kubernetes proporcionar la API del clúster de una manera que está bien integrada con los servicios y recursos del proveedor de la nube. [33]
Kubernetes se utiliza comúnmente como una forma de alojar una implementación basada en microservicios , porque éste y su ecosistema asociado de herramientas proporcionan todas las capacidades necesarias para abordar las preocupaciones clave de cualquier arquitectura de microservicios .
Varios proveedores ofrecen plataformas basadas en Kubernetes o infraestructura como servicio (IaaS) que implementan Kubernetes. [88] [89]
Por lo general, se clasifican según su código abierto, comercial o administrado. A continuación, se enumeran varias distribuciones notables: [90]
El gráfico a continuación visualiza el período durante el cual se apoyó/apoyó cada versión [91]
{{cite web}}: Enlace externo en |title=En comparación con los 1,5 millones de proyectos en GitHub, Kubernetes ocupa el puesto n.° 9 en cuanto a confirmaciones y el n.° 2 en cuanto a autores/problemas, solo superado por Linux.
Uno de los servicios primarios más importantes es un servidor API. Este es el principal punto de administración 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 asegurarse de que el almacén etcd y los detalles del servicio de los contenedores implementados estén de acuerdo. Actúa como puente entre varios componentes para mantener la salud del clúster y difundir información y comandos.