De Wikipedia, la enciclopedia libre
Saltar a navegación Saltar a búsqueda
Kubernetes
Logotipo de Kubernetes sin workmark.svg
Autor (es) original (es)Google
Desarrollador (es)Base de computación nativa en la nube
Versión inicial7 de junio de 2014 ; Hace 6 años [1] (2014-06-07)
Lanzamiento estable
1.20 [2] / 8 de diciembre de 2020 ; Hace 3 meses [3] (2020-12-08)
Repositorio
Edita esto en Wikidata
Escrito enVamos
EscribeSoftware de gestión de clústeres
LicenciaLicencia Apache 2.0
Sitio webkubernetes .io

Kubernetes ( / ˌ k ( j ) U b ər n ɛ t ɪ s , - n eɪ t ɪ s , - n eɪ t i z / , comúnmente estilizado como K8S [4] ) es una de código abierto contenedor - sistema de orquestación para automatizar la implementación, el escalado y la administración de aplicaciones informáticas . [5] Fue diseñado originalmente porGoogle y ahora es mantenido por Cloud Native Computing Foundation . Su objetivo es proporcionar una "plataforma para automatizar la implementación, el escalado y las operaciones de contenedores de aplicaciones en grupos de hosts". [6] Funciona con una variedad de herramientas de contenedor y ejecuta contenedores en un clúster, a menudo con imágenes creadas con Docker . Kubernetes originalmente interactuó con el tiempo de ejecución de Docker [7] a través de un "Dockershim"; sin embargo, la corrección ha quedado obsoleta en favor de la interfaz directa con containerd u otro tiempo de ejecución compatible con CRI. [8]

Muchos servicios en la nube ofrecen una plataforma basada en Kubernetes o una infraestructura como servicio ( PaaS o IaaS ) en la que Kubernetes se puede implementar como un servicio de suministro de plataforma. Muchos proveedores también ofrecen sus propias distribuciones de Kubernetes de marca.

Historia [ editar ]

Charla de Google Kubernetes Engine en Google Cloud Summit

Kubernetes ( κυβερνήτης , en griego para " timonel " o "piloto" o "gobernador", y la raíz etimológica de la cibernética ) [6] fue fundada por Joe Beda, Brendan Burns y Craig McLuckie, [9] a quienes rápidamente se unieron otros Ingenieros de Google, incluidos Brian Grant y Tim Hockin, y Google lo anunció por primera vez a mediados de 2014. [10] Su desarrollo y diseño están fuertemente influenciados por el sistema Borg de Google , [11] [12] y muchos de los principales contribuyentes al proyecto trabajaron previamente en Borg. El nombre en clave original de Kubernetes dentro de Google era Proyecto 7, una referencia al ex- Borg de Star Trek.personaje Siete de Nueve . [13] Los siete rayos en la rueda del logotipo de Kubernetes son una referencia a ese nombre en clave. El proyecto Borg original fue escrito completamente en C ++, [11] pero el sistema Kubernetes reescrito está implementado en Go .

Kubernetes v1.0 se lanzó el 21 de julio de 2015. [14] Junto con el lanzamiento de Kubernetes v1.0, Google se asoció con Linux Foundation para formar Cloud Native Computing Foundation (CNCF) [15] y ofreció Kubernetes como tecnología semilla . En febrero de 2016 se lanzó [16] Helm [17] [18] el administrador de paquetes para Kubernetes. El 6 de marzo de 2018, Kubernetes Project alcanzó el noveno lugar en confirmaciones en GitHub y el segundo en autores y problemas, después del kernel de Linux . [19]

Hasta la v1.18, Kubernetes siguió una política de soporte N-2 [20] (lo que significa que las 3 versiones menores más recientes reciben seguridad y correcciones de errores).

A partir de la v1.19, Kubernetes seguirá una política de soporte N-3. [21]

Historial de versiones
VersiónFecha de lanzamientoFecha de finalización del soporte [22]Notas
Old version, no longer maintained: 1.010 de julio de 2015Lanzamiento original
Old version, no longer maintained: 1.19 de noviembre de 2015https://kubernetes.io/blog/2015/11/kubernetes-1-1-performance-upgrades-improved-tooling-and-a-growing-community
Old version, no longer maintained: 1.216 de marzo de 201623 de octubre de 2016https://kubernetes.io/blog/2016/03/kubernetes-1-2-even-more-performance-upgrades-plus-easier-application-deployment-and-management
Old version, no longer maintained: 1.31 de julio de 20161 de noviembre de 2016https://kubernetes.io/blog/2016/07/kubernetes-1-3-bridging-cloud-native-and-enterprise-workloads
Old version, no longer maintained: 1.426 de septiembre de 201621 de abril de 2017https://kubernetes.io/blog/2016/09/kubernetes-1-4-making-it-easy-to-run-on-kuberentes-anywhere
Old version, no longer maintained: 1,512 de diciembre de 20161 de octubre de 2017https://kubernetes.io/blog/2016/12/kubernetes-1-5-supporting-production-workloads
Old version, no longer maintained: 1,628 de marzo de 201723 de noviembre de 2017https://kubernetes.io/blog/2017/03/kubernetes-1-6-multi-user-multi-workloads-at-scale
Old version, no longer maintained: 1,730 de junio de 20174 de abril de 2018https://kubernetes.io/blog/2017/06/kubernetes-1-7-security-hardening-stateful-application-extensibility-updates
Old version, no longer maintained: 1.828 de agosto de 201712 de julio de 2018https://kubernetes.io/blog/2017/09/kubernetes-18-security-workloads-and
Old version, no longer maintained: 1,915 de diciembre de 201729 de septiembre de 2018https://kubernetes.io/blog/2017/12/kubernetes-19-workloads-expanded-ecosystem
Old version, no longer maintained: 1,1028 de marzo de 201813 de febrero de 2019https://kubernetes.io/blog/2018/03/26/kubernetes-1.10-stabilizing-storage-security-networking
Old version, no longer maintained: 1,113 de julio de 20181 de mayo de 2019https://kubernetes.io/blog/2018/06/27/kubernetes-1.11-release-announcement
Old version, no longer maintained: 1.1227 de septiembre de 20188 de julio de 2019https://kubernetes.io/blog/2018/09/27/kubernetes-1.12-kubelet-tls-bootstrap-and-azure-virtual-machine-scale-sets-vmss-move-to-general-availability
Old version, no longer maintained: 1,133 de diciembre de 201815 de octubre de 2019https://kubernetes.io/blog/2018/12/03/kubernetes-1-13-release-announcement
Old version, no longer maintained: 1,1425 de marzo de 201911 de diciembre de 2019https://kubernetes.io/blog/2019/03/25/kubernetes-1-14-release-announcement
Old version, no longer maintained: 1,1520 de junio de 20196 de mayo de 2020https://kubernetes.io/blog/2019/06/19/kubernetes-1-15-release-announcement
Old version, no longer maintained: 1,1622 de octubre de 20192 de septiembre de 2020https://kubernetes.io/blog/2019/09/18/kubernetes-1-16-release-announcement
Old version, no longer maintained: 1,179 de diciembre de 201930 de enero de 2021https://kubernetes.io/blog/2019/12/09/kubernetes-1-17-release-announcement
Older version, yet still maintained: 1,1825 marzo 202030 de abril de 2021https://kubernetes.io/blog/2020/03/25/kubernetes-1-18-release-announcement
Older version, yet still maintained: 1,1926 de agosto de 2020 [23]30 de septiembre de 2021A partir de la versión 1.19 de Kubernetes, la ventana de soporte se extenderá a un año [21] https://kubernetes.io/blog/2020/08/26/kubernetes-release-1.19-accentuate-the-paw-sitive
Current stable version: 1,208 de diciembre de 202030 de diciembre de 2021https://kubernetes.io/blog/2020/12/08/kubernetes-1-20-release-announcement/
Leyenda:
Versión antigua
Versión anterior, aún mantenida
Ultima versión
Última versión de vista previa
Lanzamiento futuro

Ventanas de soporte [ editar ]

El gráfico a continuación muestra el período durante el cual cada versión es / fue compatible [22]

Conceptos [ editar ]

Diagrama de arquitectura de Kubernetes

Kubernetes define un conjunto de bloques de construcción ("primitivas"), que colectivamente proporcionan mecanismos que implementan, mantienen y escalan aplicaciones basadas en CPU, memoria [24] o métricas personalizadas. [25] Kubernetes está débilmente acoplado y es extensible para cumplir con diferentes cargas de trabajo. Esta extensibilidad la proporciona en gran parte la API de Kubernetes, que utilizan los componentes internos, así como las extensiones y contenedores que se ejecutan en Kubernetes. [26] La plataforma ejerce su control sobre los recursos informáticos y de almacenamiento definiendo los recursos como Objetos, que luego pueden administrarse como tales.

Kubernetes sigue la arquitectura principal / réplica . Los componentes de Kubernetes se pueden dividir en los que gestionan un nodo individual y los que forman parte del plano de control. [26] [27]

Plano de control [ editar ]

El maestro de Kubernetes es la unidad de control principal del clúster, administra su carga de trabajo y dirige la comunicación a través del sistema. El plano de control de Kubernetes consta de varios componentes, cada uno con su propio proceso, que pueden ejecutarse tanto en un único nodo maestro como en varios maestros que admiten clústeres de alta disponibilidad . [27] Los diversos componentes del plano de control de Kubernetes son los siguientes:

  • etcd: etcd [28] es un almacén de datos de valor clave persistente, ligero, distribuido desarrollado por CoreOS que almacena de forma fiable los datos de configuración del clúster, que representan el estado general del clúster en un momento dado. Al igual que Apache ZooKeeper , etcd es un sistema que favorece la coherencia sobre la disponibilidad en el caso de una partición de red (consulte el teorema CAP). Esta consistencia es crucial para programar y operar correctamente los servicios. El servidor API de Kubernetes utiliza la API de vigilancia de etcd para monitorear el clúster y realizar cambios de configuración críticos o simplemente restaurar cualquier divergencia del estado del clúster a lo que declaró el implementador. Por ejemplo, si el implementador especificó que es necesario ejecutar tres instancias de un pod en particular, este hecho se almacena en etcd. Si se encuentra que solo se están ejecutando dos instancias, este delta se detectará en comparación con los datos de etcd, y Kubernetes lo usará para programar la creación de una instancia adicional de ese pod. [27]
  • Servidor de API: el servidor de API es un componente clave y sirve a la API de Kubernetes mediante JSON sobre HTTP , que proporciona la interfaz interna y externa a Kubernetes. [26] [29] El servidor API procesa y valida las 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. [30]
  • Programador: el programador es el componente conectable que selecciona en qué nodo se ejecuta un pod no programado (la entidad básica administrada por el programador), según la disponibilidad de recursos. El programador rastrea el uso 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 programador debe conocer los requisitos de recursos, la disponibilidad de recursos y otras restricciones y directivas de políticas proporcionadas por el usuario, como la calidad de servicio, los requisitos de afinidad / antiafinidad, la ubicación de los datos, etc. En esencia, la función del planificador es hacer coincidir el "suministro" de recursos con la "demanda" de la carga de trabajo. [31]
  • Administrador de controladores: un controlador es un bucle de reconciliación que impulsa el estado real del clúster hacia el estado del clúster deseado, comunicándose con el servidor API para crear, actualizar y eliminar los recursos que administra (pods, puntos finales de servicio, etc.). [32] [29] El administrador del controlador es un proceso que administra un conjunto de controladores centrales de Kubernetes. Un tipo de controlador es un controlador de replicación, que maneja la replicación y el escalado mediante la ejecución de un número específico de copias de un pod en el clúster. También maneja la creación de pods de reemplazo si falla el nodo subyacente. [32]Otros controladores que forman parte del sistema central de Kubernetes incluyen un DaemonSet Controller para ejecutar exactamente un pod en cada máquina (o algún subconjunto de máquinas) y un Job Controller para ejecutar pods que se ejecutan hasta su finalización, por ejemplo, como parte de un trabajo por lotes. [33] El conjunto de pods que administra un controlador está determinado por selectores de etiquetas que forman parte de la definición del controlador. [34]

Nodos [ editar ]

Un nodo, también conocido como trabajador o esbirro, es una máquina donde se implementan contenedores (cargas de trabajo). Cada nodo del clúster debe ejecutar un tiempo de ejecución de contenedor como Docker , así como los componentes que se mencionan a continuación, para comunicarse con el primario para la configuración de red de estos contenedores.

  • Kubelet: Kubelet es responsable del estado de ejecución de cada nodo, asegurando 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 módulos según las indicaciones del plano de control. [26] [35]
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 primario. Una vez que el primario detecta una falla en el nodo, el controlador de replicación observa este cambio de estado y lanza pods en otros nodos en buen estado. [ cita requerida ]
  • Kube-proxy: el Kube-proxy es una implementación de un proxy de red y un equilibrador de carga , y admite la abstracción del servicio junto con otras operaciones de red. [26] Es responsable de enrutar el tráfico al contenedor apropiado según la IP y el número de puerto de la solicitud entrante.
  • Tiempo de ejecución del contenedor: un contenedor reside dentro de una vaina. El contenedor es el nivel más bajo de un microservicio, que contiene la aplicación en ejecución, las bibliotecas y sus dependencias. Los contenedores se pueden exponer al mundo a través de una dirección IP externa. Kubernetes ha admitido contenedores Docker desde su primera versión, y en julio de 2016 se agregó el motor de contenedores rkt . [36]

Pods [ editar ]

La unidad de programación básica en Kubernetes es un pod . [37] Una vaina es una agrupación de componentes en contenedores. Un pod consta de uno o más contenedores que se garantiza que se ubicarán en el mismo nodo. [26]

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. [38] Dentro del pod, todos los contenedores pueden hacer referencia entre sí en localhost, pero un contenedor dentro de un pod no tiene forma de dirigirse directamente a otro contenedor dentro de otro pod; para eso, tiene que usar la dirección IP del Pod. Sin embargo, un desarrollador de aplicaciones nunca debe usar la dirección IP del pod para hacer referencia / invocar una capacidad en otro pod, ya que las direcciones IP del pod son efímeras; el pod específico al que hacen referencia puede asignarse a otra dirección IP del pod al reiniciar. En su lugar, deben usar una referencia a un servicio , que contiene una referencia al pod de destino en la dirección IP del pod específico.

Un pod puede definir un volumen, como un directorio de disco local o un disco de red, y exponerlo a los contenedores del pod. [39] Los pods se pueden administrar manualmente a través de la API de Kubernetes , o su administración se puede delegar a un controlador. [26] Dichos volúmenes también son la base de las funciones de Kubernetes de ConfigMaps (para proporcionar acceso a la configuración a través del sistema de archivos visible para el contenedor) y Secrets (para proporcionar acceso a las credenciales necesarias para acceder a recursos remotos de forma segura, proporcionando esas credenciales en el sistema de archivos visible solo para contenedores autorizados).

ReplicaSets [ editar ]

El propósito de un ReplicaSet es mantener un conjunto estable de Pods de réplica ejecutándose en cualquier momento. Como tal, a menudo se usa para garantizar la disponibilidad de un número específico de Pods idénticos. [40]

También se puede decir que ReplicaSets [41] es un mecanismo de agrupación que permite a Kubernetes mantener el número de instancias que se han declarado para un pod determinado. La definición de un conjunto de réplicas utiliza un selector, cuya evaluación dará como resultado la identificación de todos los pods que están asociados con él.

Servicios [ editar ]

Vista simplificada que muestra cómo interactúan los servicios con las redes de pod en un clúster de Kubernetes

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. [26] Kubernetes proporciona dos modos de descubrimiento de servicios , usando variables ambientales o usando DNS de Kubernetes. [42] 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 a 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 máquina a máquina). [38] De forma predeterminada, un servicio está expuesto dentro de un clúster (p. Ej., Back-endLos pods se pueden agrupar en un servicio, con las solicitudes de los pods de front-end con equilibrio de carga entre ellos), pero un servicio también puede exponerse fuera de un clúster (por ejemplo, para que los clientes lleguen a los pods de front-end). [43]

Volúmenes [ editar ]

Los sistemas de archivos del 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 cosa menos en aplicaciones triviales. Un volumen de Kubernetes [44] 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 enlazar con otros volúmenes. El mismo volumen se puede montar en diferentes puntos del árbol del sistema de archivos mediante diferentes contenedores.

Espacios de nombres [ editar ]

Kubernetes proporciona una partición de los recursos que administra en conjuntos no superpuestos llamados espacios de nombres. [45] Están pensados ​​para su uso en entornos con muchos usuarios distribuidos en varios equipos o proyectos, o incluso entornos separados como desarrollo, prueba y producción.

ConfigMaps y secretos [ editar ]

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 tan detallada como propiedades individuales o información detallada como archivos de configuración completos o documentos JSON / XML. Kubernetes proporciona dos mecanismos estrechamente relacionados para hacer frente a esta necesidad: "configmaps" y "secretos", los cuales permiten realizar cambios en la configuración sin necesidad de compilar una aplicación. Los datos de los mapas de configuración y los secretos estarán disponibles para cada instancia de la aplicación a la que se han vinculado estos objetos a través de la implementación. Un secreto y / o un mapa de configuración solo se envía a un nodo si un pod en ese nodo lo requiere. Kubernetes lo mantendrá en memoria en ese nodo.Una vez que se elimina el pod que depende del mapa de configuración o secreto, también se elimina la copia en memoria de todos los mapas de configuración y secretos vinculados. El pod puede acceder a los datos a través de una de estas dos formas: a) como variables de entorno (que serán creadas por Kubernetes cuando se inicie el pod) ob) disponibles en el sistema de archivos del contenedor que es visible solo desde dentro del pod.

Los datos en sí se almacenan en el maestro, que es una máquina altamente segura a la que nadie debería tener acceso de inicio de sesión. La mayor diferencia entre un mapa secreto y un mapa de configuración es que el contenido de los datos en un secreto está codificado en base64. Las versiones recientes de Kubernetes también han introducido compatibilidad con el cifrado. Los secretos se utilizan a menudo para almacenar datos como certificados, contraseñas, extraer secretos (credenciales para trabajar con registros de imágenes) y claves ssh.

StatefulSets [ editar ]

Es muy fácil abordar el escalado de aplicaciones sin estado: simplemente se agregan más pods en ejecución, que es algo que Kubernetes hace muy bien. Las cargas de trabajo con estado son mucho más difíciles, porque el estado debe conservarse si se reinicia un pod y si la aplicación se escala hacia arriba o hacia abajo, es posible que el estado deba redistribuirse. 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 vienen con la noción de instancia principal y instancia (s) secundaria (s). En este caso, la noción de ordenamiento de instancias es importante. Otras aplicaciones, como Kafka, distribuyen los datos entre sus agentes, por lo que un agente no es igual a otro. En este caso, la noción de unicidad de instancia es importante. StatefulSets [46] son controladores (consulteController Manager , a continuación) proporcionados por Kubernetes que refuerzan las propiedades de unicidad y orden entre las instancias de un pod y se pueden usar para ejecutar aplicaciones con estado.

DaemonSets [ editar ]

Normalmente, las ubicaciones donde se ejecutan los pods están determinadas por el algoritmo implementado en el programador de Kubernetes. Sin embargo, para algunos casos de uso, podría ser necesario ejecutar un pod en cada uno de los nodos del clúster. Esto es útil para casos de uso como recopilación de registros, controladores de entrada y servicios de almacenamiento. La capacidad de realizar este tipo de programación de pod se implementa mediante la función llamada DaemonSets. [47]

Etiquetas y selectores [ editar ]

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. [26] Cuando se define un servicio, se pueden definir los selectores de etiquetas que utilizará el enrutador de servicio / equilibrador 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 usar para controlar qué pods reciben tráfico y cuáles no, que se pueden usar para admitir varios patrones de implementación como implementaciones azul-verde o pruebas AB.. Esta capacidad para controlar dinámicamente cómo los servicios utilizan los recursos de implementación proporciona un acoplamiento flexible dentro de la infraestructura.

Por ejemplo, si las vainas de una aplicación tienen etiquetas para un sistema tier(con valores tales como front-end, back-end, por ejemplo) y una release_track(con valores tales como canary, production, por ejemplo), a continuación, una operación en todos back-endy canarynodos puede utilizar un selector de etiqueta, tales como: [34]

tier=back-end 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 atributo 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 / recurso.

Controladores de replicación e implementaciones [ editar ]

Un ReplicaSet declara la cantidad de instancias de un pod que se necesitan y un Replication Controller administra el sistema para que la cantidad de pods en buen estado que se estén ejecutando coincida con la cantidad de pods declarados en el ReplicaSet (determinado mediante la evaluación de su selector).

Las implementaciones son un mecanismo de administración de nivel superior para ReplicaSets. Mientras que el controlador de replicación administra la escala del ReplicaSet, las implementaciones administrarán lo que sucede con el ReplicaSet: si una actualización debe implementarse o revertirse, etc. Cuando las implementaciones se escalan hacia arriba o hacia abajo, esto da como resultado la declaración del ReplicaSet cambia, y este cambio en el estado declarado es administrado por el controlador de replicación.

Complementos [ editar ]

Los complementos funcionan como cualquier otra aplicación que se ejecute dentro del clúster: se implementan a través de pods y servicios, y solo se diferencian en que implementan características del clúster de Kubernetes. Los pods pueden ser administrados por Implementaciones, ReplicationControllers, etc. Hay muchos complementos y la lista sigue creciendo. Algunos de los más importantes son:

  • DNS: todos los clústeres de Kubernetes deben tener DNS de clúster; es una característica obligatoria. Cluster DNS es un servidor DNS, además de los otros servidores DNS en su entorno, que proporciona registros DNS para los servicios de Kubernetes. Los contenedores iniciados por Kubernetes incluyen automáticamente este servidor DNS en sus búsquedas de DNS.
  • Interfaz de usuario web: se trata de una interfaz de usuario basada en web de uso general para clústeres de Kubernetes. Permite a los usuarios administrar y solucionar problemas de aplicaciones que se ejecutan en el clúster, así como del clúster en sí.
  • Monitoreo de recursos de contenedores: proporcionar un tiempo de ejecución de aplicaciones confiable y poder escalarlo hacia arriba o hacia abajo en respuesta a las cargas de trabajo, significa poder monitorear de manera continua y efectiva el rendimiento de la carga de trabajo. Container Resource Monitoring proporciona esta capacidad al registrar métricas sobre contenedores en una base de datos central y proporciona una interfaz de usuario para examinar esos datos. El cAdvisor es un componente en un nodo esclavo que proporciona una capacidad limitada de monitoreo de métricas. También hay canalizaciones de métricas completas, como Prometheus, que pueden satisfacer la mayoría de las necesidades de monitoreo.
  • Registro a nivel de clúster: los registros deben tener un almacenamiento y un ciclo de vida separados, independientemente de los nodos, pods o contenedores. De lo contrario, las fallas del nodo o pod pueden causar la pérdida de datos de eventos. La capacidad para hacer esto se denomina registro a nivel de clúster, y dichos mecanismos son responsables de guardar los registros del contenedor en un almacén de registros central con una interfaz de búsqueda / navegación. Kubernetes no proporciona almacenamiento nativo para los datos de registro, pero se pueden integrar muchas soluciones de registro existentes en el clúster de Kubernetes.

Almacenamiento [ editar ]

Los contenedores surgieron como una forma de hacer que el software sea portátil. El contenedor contiene todos los paquetes que necesita para ejecutar un servicio. El sistema de archivos proporcionado hace que los contenedores sean extremadamente portátiles y fáciles de usar en desarrollo. Un contenedor se puede mover de desarrollo a prueba o producción sin cambios de configuración o con relativamente pocos cambios.

Históricamente, Kubernetes solo era adecuado para servicios sin estado. Sin embargo, muchas aplicaciones tienen una base de datos, que requiere persistencia, lo que conduce a la creación de almacenamiento persistente para Kubernetes. La implementación del almacenamiento persistente para contenedores es uno de los principales desafíos de los administradores de Kubernetes, DevOps e ingenieros de nube. Los contenedores pueden ser efímeros, pero cada vez más datos no lo son, por lo que es necesario garantizar la supervivencia de los datos en caso de que el contenedor termine o falle el hardware. Al implementar contenedores con Kubernetes o aplicaciones en contenedores, las empresas a menudo se dan cuenta de que necesitan almacenamiento persistente. Deben proporcionar un 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 Kubernetes Persistent Storage, incluido un blog que ayuda a definir el patrón de almacenamiento adjunto al contenedor. Este patrón se puede considerar como uno que usa Kubernetes en sí mismo como un componente del sistema o servicio de almacenamiento. [48]

También se puede encontrar más información sobre la popularidad relativa de estos y otros enfoques en la encuesta de paisaje de la CNCF, que mostró que OpenEBS de MayaData 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. [49]

El almacenamiento adjunto al contenedor es un tipo de almacenamiento de datos que surgió cuando Kubernetes ganó importancia. El enfoque o patrón de almacenamiento adjunto de contenedor se basa en el propio Kubernetes para ciertas capacidades, al tiempo que ofrece principalmente bloques, archivos, objetos e interfaces para las cargas de trabajo que se ejecutan en Kubernetes. [50]

Los atributos comunes de Container Attached Storage incluyen el uso de extensiones de Kubernetes, como definiciones de recursos personalizadas, y el uso de Kubernetes en sí mismo para funciones que de otra manera se desarrollarían y desplegarían por separado para el almacenamiento o la gestión de datos. Entre los ejemplos de funcionalidad entregada por las definiciones de recursos personalizadas o por el propio Kubernetes se incluyen la lógica de reintento, entregada por el propio Kubernetes, y la creación y mantenimiento de un inventario de medios y volúmenes de almacenamiento disponibles, generalmente entregados a través de una definición de recurso personalizada. [51] [52]

API [ editar ]

Los principios de diseño subyacentes a Kubernetes permiten crear, configurar y administrar clústeres de Kubernetes mediante programación. Esta función se expone a través de una API llamada Cluster API. Un concepto clave incorporado en la API es la noción de que el clúster de Kubernetes es en sí mismo un recurso / objeto que se puede administrar como cualquier otro recurso de Kubernetes. Del mismo modo, 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 de 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.

Usos [ editar ]

Kubernetes se usa comúnmente como una forma de alojar una implementación basada en microservicios, porque él y su ecosistema de herramientas asociado brindan todas las capacidades necesarias para abordar las preocupaciones clave de cualquier arquitectura de microservicio .

Ver también [ editar ]

  • OpenShift
  • Lista de software de gestión de clústeres
  • Base de computación nativa en la nube
  • Malla de servicio abierta

Referencias [ editar ]

  1. ^ "Primera confirmación de GitHub para Kubernetes" . github.com . 2014-06-07. Archivado desde el original el 1 de marzo de 2017.
  2. ^ "Página de versiones de GitHub" . github.com . Consultado el 31 de octubre de 2020 .
  3. ^ "Kubernetes 1.20: la versión más Raddest" . Kubernetes . Consultado el 14 de diciembre de 2020 .
  4. ^ "Repositorio de Kubernetes GitHub" . GitHub . 22 de enero de 2021.
  5. ^ "kubernetes / kubernetes" . GitHub . Archivado desde el original el 21 de abril de 2017 . Consultado el 28 de marzo de 2017 .
  6. ^ a b "¿Qué es Kubernetes?" . Kubernetes . Consultado el 31 de marzo de 2017 .
  7. ^ "Kubernetes v1.12: Introducción a RuntimeClass" . kubernetes.io .
  8. ^ "Que no cunda el pánico: Kubernetes y Docker" . Blog de Kubernetes . Consultado el 22 de diciembre de 2020 .
  9. ^ "Google hizo público su plan secreto para impulsar su nube" . Archivado desde el original el 1 de julio de 2016 . Consultado el 27 de junio de 2016 .
  10. ^ "Google Open Sources su arma secreta en Cloud Computing" . Cableado . Archivado desde el original el 10 de septiembre de 2015 . Consultado el 24 de septiembre de 2015 .
  11. ^ a b Abhishek Verma; Luis Pedrosa; Madhukar R. Korupolu; David Oppenheimer; Eric Tune; John Wilkes (21 al 24 de abril de 2015). "Gestión de clústeres a gran escala en Google con Borg" . Actas de la Conferencia europea sobre sistemas informáticos (EuroSys) . Archivado desde el original el 27 de julio de 2017.
  12. ^ "Borg, Omega y Kubernetes - Cola ACM" . queue.acm.org . Archivado desde el original el 9 de julio de 2016 . Consultado el 27 de junio de 2016 .
  13. ^ "Heptio de inicio de etapa temprana tiene como objetivo hacer Kubernetes amigable" . Consultado el 6 de diciembre de 2016 .
  14. ^ "Como Kubernetes Hits 1.0, Google dona tecnología a la Fundación de computación nativa en la nube recién formada" . TechCrunch . Archivado desde el original el 23 de septiembre de 2015 . Consultado el 24 de septiembre de 2015 .
  15. ^ "Fundación de computación nativa en la nube" . Archivado desde el original el 3 de julio de 2017.
  16. ^ https://github.com/helm/helm/releases/tag/v1.0
  17. ^ https://www.wikieduonline.com/wiki/Helm_(package_manager)
  18. ^ https://helm.sh/
  19. ^ Conway, Sarah. "Kubernetes es el primer proyecto de CNCF en graduarse" (html) . Base de computación nativa en la nube . Archivado desde el original el 29 de octubre de 2018 . Consultado el 3 de diciembre de 2018 . En comparación con los 1,5 millones de proyectos en GitHub, Kubernetes es el número 9 para confirmaciones y el número 2 para autores / problemas, solo superado por Linux.
  20. ^ "Versión de Kubernetes y política de soporte de sesgo de versión" . Kubernetes . Consultado el 3 de marzo de 2020 .
  21. ^ a b "Anuncio de lanzamiento de Kubernetes 1.19> Aumentar la ventana de soporte de Kubernetes a un año" . Kubernetes . Consultado el 28 de agosto de 2020 .
  22. ^ a b "Lanzamientos de parches de Kubernetes" . 5 de enero de 2021.
  23. ^ "Anuncio de lanzamiento de Kubernetes 1.19" . Kubernetes . Consultado el 28 de agosto de 2020 .
  24. ^ Sharma, Priyanka (13 de abril de 2017). "Ajuste de escala automático basado en CPU / memoria en Kubernetes — Parte II" . Blog de tecnología de Powerupcloud . Medio . Consultado el 27 de diciembre de 2018 .
  25. ^ "Configurar el ajuste de escala automático de Kubernetes con métricas personalizadas" . Bitnami . BitRock. 15 de noviembre de 2018 . Consultado el 27 de diciembre de 2018 .
  26. ^ a b c d e f g h i "Introducción a Kubernetes" . DigitalOcean . Archivado desde el original el 1 de octubre de 2015 . Consultado el 24 de septiembre de 2015 .
  27. ^ a b c "Infraestructura de Kubernetes" . Documentación de la comunidad OpenShift . OpenShift. Archivado desde el original el 6 de julio de 2015 . Consultado el 24 de septiembre de 2015 .
  28. ^ Container Linux por CoreOS: infraestructura de clúster
  29. ↑ a b Marhubi, Kamal (26 de septiembre de 2015). "Kubernetes desde cero: servidor API" . kamalmarhubi.com. Archivado desde el original el 29 de octubre de 2015 . Consultado el 2 de noviembre de 2015 .
  30. ^ Ellingwood, Justin (2 de mayo de 2018). "Introducción a Kubernetes" . DigitalOcean . Archivado desde el original el 5 de julio de 2018 . Consultado el 20 de julio de 2018 . Uno de los servicios primarios más importantes es un servidor API. Este es el punto de administración principal de todo el clúster, ya que permite al usuario configurar las cargas de trabajo y las unidades organizativas de Kubernetes. También es responsable de asegurarse de que la tienda etcd y los detalles del servicio de los contenedores implementados estén de acuerdo. Actúa como puente entre varios componentes para mantener el estado del clúster y difundir información y comandos.
  31. ^ "Los tres pilares de la orquestación de contenedores de Kubernetes - Rancher Labs" . rancher.com . 18 de mayo de 2017. Archivado desde el original el 24 de junio de 2017 . Consultado el 22 de mayo de 2017 .
  32. ^ a b "Descripción general de un controlador de replicación" . Documentación . CoreOS . Archivado desde el original el 22 de septiembre de 2015 . Consultado el 2 de noviembre de 2015 .
  33. ↑ Sanders, Jake (2 de octubre de 2015). "Kubernetes: emocionantes características experimentales" . Livewyer . Archivado desde el original el 20 de octubre de 2015 . Consultado el 2 de noviembre de 2015 .
  34. ^ a b "Introducción: entrenamiento de Docker y Kubernetes - Día 2" . Red Hat . 2015-10-20. Archivado desde el original el 29 de octubre de 2015 . Consultado el 2 de noviembre de 2015 .
  35. ↑ Marhubi, Kamal (27 de agosto de 2015). "¿Qué [..] es un Kubelet?" . kamalmarhubi.com. Archivado desde el original el 13 de noviembre de 2015 . Consultado el 2 de noviembre de 2015 .
  36. ^ "rktnetes trae el motor de contenedor rkt a Kubernetes" . kubernetes.io .
  37. ^ "Vainas" . kubernetes.io .
  38. ↑ a b Langemak, Jon (11 de febrero de 2015). "Kubernetes 101 - Redes" . Das Blinken Lichten . Archivado desde el original el 25 de octubre de 2015 . Consultado el 2 de noviembre de 2015 .
  39. ↑ Strachan, James (21 de mayo de 2015). "Kubernetes para desarrolladores" . Medio (plataforma de publicación) . Archivado desde el original el 7 de septiembre de 2015 . Consultado el 2 de noviembre de 2015 .
  40. ^ "ReplicaSet" . kubernetes.io . Consultado el 3 de marzo de 2020 .
  41. ^ "Implementaciones, ReplicaSets y pods" .
  42. ^ "Servicio" . kubernetes.io .
  43. ↑ Langemak, Jon (15 de febrero de 2015). "Kubernetes 101 - Acceso externo al clúster" . Das Blinken Lichten . Archivado desde el original el 26 de octubre de 2015 . Consultado el 2 de noviembre de 2015 .
  44. ^ "Volúmenes" . kubernetes.io .
  45. ^ "Espacios de nombres" . kubernetes.io .
  46. ^ "StatefulSets" . kubernetes.io .
  47. ^ "DaemonSet" . kubernetes.io .
  48. ^ https://www.cncf.io/blog/2018/04/19/container-attached-storage-a-primer/
  49. ^ https://www.cncf.io/wp-content/uploads/2020/03/CNCF_Survey_Report.pdf
  50. ^ "Almacenamiento adjunto contenedor: una cartilla" . Base de computación nativa en la nube . 2018-04-19 . Consultado el 9 de octubre de 2020 .
  51. ^ "Almacenamiento adjunto contenedor | SNIA" . www.snia.org . Consultado el 9 de octubre de 2020 .
  52. ^ "Lista de verificación de aplicaciones nativas en la nube: almacenamiento nativo en la nube" . www.replex.io . Consultado el 9 de octubre de 2020 .

Enlaces externos [ editar ]

  • Página web oficial
  • Kubernetes en GitHub