Kubernetes - Kubernetes

Kubernetes
Logotipo de Kubernetes sin workmark.svg
Autor (es) original (es) Google
Desarrollador (es) Base de computación nativa en la nube
Versión inicial 7 de junio de 2014 ; hace 7 años ( 07-06-2014 )
Lanzamiento estable
1.22.2 / 4 de agosto de 2021 ; Hace 2 meses ( 04/08/2021 )
Repositorio
Escrito en Ir
Escribe Software de gestión de clústeres
Licencia Licencia Apache 2.0
Sitio web kubernetes .io

Kubernetes ( / ˌ k ( j ) U b ər n ɛ t ɪ s , - n t ɪ s , - n t i z / , comúnmente estilizado como K8S ) es una de código abierto contenedor - orquestación sistema para Automatizar la implementación, el escalado y la administración de aplicaciones informáticas . Fue diseñado originalmente por Google 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 los sistemas de gestión de bases de datos". 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 a través de un "Dockershim"; sin embargo, el shim ha quedado obsoleto a favor de interactuar directamente con el contenedor a través de containerd , o reemplazar Docker con un tiempo de ejecución que cumpla con la Container Runtime Interface (CRI) introducida por Kubernetes en 2016.

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

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 ) fue fundada por Ville Aikas, Joe Beda, Brendan Burns y Craig McLuckie, a quienes se unieron rápidamente otros ingenieros de Google, incluidos Brian Grant y Tim Hockin, y Google lo anunció por primera vez a mediados de 2014. Su desarrollo y diseño están fuertemente influenciados por el sistema Borg de Google , y muchos de los principales contribuyentes al proyecto trabajaron anteriormente en Borg. El nombre en clave original de Kubernetes dentro de Google era Proyecto 7, una referencia al personaje de Star Trek ex Borg Seven of Nine . Los siete radios en la rueda del logotipo de Kubernetes son una referencia a ese nombre en clave. El proyecto Borg original se escribió completamente en C ++, pero el sistema Kubernetes reescrito se implementa en Go .

Kubernetes v1.0 se lanzó el 21 de julio de 2015. Junto con el lanzamiento de Kubernetes v1.0, Google se asoció con Linux Foundation para formar Cloud Native Computing Foundation (CNCF) y ofreció Kubernetes como tecnología semilla. En febrero de 2016, se lanzó el administrador de paquetes Helm 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 .

Hasta la v1.18, Kubernetes siguió una política de soporte N-2 (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.

Historial de versiones
Versión Fecha de lanzamiento Fecha de fin de soporte Notas
Versión antigua, ya no se mantiene: 1.0 10 de julio de 2015 Lanzamiento original
Versión antigua, ya no se mantiene: 1.1 9 de noviembre de 2015 https://kubernetes.io/blog/2015/11/kubernetes-1-1-performance-upgrades-improved-tooling-and-a-growing-community
Versión antigua, ya no se mantiene: 1.2 16 de marzo de 2016 23 de octubre de 2016 https://kubernetes.io/blog/2016/03/kubernetes-1-2-even-more-performance-upgrades-plus-easier-application-deployment-and-management
Versión antigua, ya no se mantiene: 1.3 1 de julio de 2016 1 de noviembre de 2016 https://kubernetes.io/blog/2016/07/kubernetes-1-3-bridging-cloud-native-and-enterprise-workloads
Versión antigua, ya no se mantiene: 1.4 26 de septiembre de 2016 21 de abril de 2017 https://kubernetes.io/blog/2016/09/kubernetes-1-4-making-it-easy-to-run-on-kuberentes-anywhere
Versión antigua, ya no se mantiene: 1,5 12 de diciembre de 2016 1 de octubre de 2017 https://kubernetes.io/blog/2016/12/kubernetes-1-5-supporting-production-workloads
Versión antigua, ya no se mantiene: 1,6 28 de marzo de 2017 23 de noviembre de 2017 https://kubernetes.io/blog/2017/03/kubernetes-1-6-multi-user-multi-workloads-at-scale
Versión antigua, ya no se mantiene: 1,7 30 de junio de 2017 4 de abril de 2018 https://kubernetes.io/blog/2017/06/kubernetes-1-7-security-hardening-stateful-application-extensibility-updates
Versión antigua, ya no se mantiene: 1.8 28 de agosto de 2017 12 de julio de 2018 https://kubernetes.io/blog/2017/09/kubernetes-18-security-workloads-and
Versión antigua, ya no se mantiene: 1,9 15 de diciembre de 2017 29 de septiembre de 2018 https://kubernetes.io/blog/2017/12/kubernetes-19-workloads-expanded-ecosystem
Versión antigua, ya no se mantiene: 1,10 28 de marzo de 2018 13 de febrero de 2019 https://kubernetes.io/blog/2018/03/26/kubernetes-1.10-stabilizing-storage-security-networking
Versión antigua, ya no se mantiene: 1,11 3 de julio de 2018 1 de mayo de 2019 https://kubernetes.io/blog/2018/06/27/kubernetes-1.11-release-announcement
Versión antigua, ya no se mantiene: 1.12 27 de septiembre de 2018 8 de julio de 2019 https://kubernetes.io/blog/2018/09/27/kubernetes-1.12-kubelet-tls-bootstrap-and-azure-virtual-machine-scale-sets-vmss-move-to-general-availability
Versión antigua, ya no se mantiene: 1,13 3 de diciembre de 2018 15 de octubre de 2019 https://kubernetes.io/blog/2018/12/03/kubernetes-1-13-release-announcement
Versión antigua, ya no se mantiene: 1,14 25 de marzo de 2019 11 de diciembre de 2019 https://kubernetes.io/blog/2019/03/25/kubernetes-1-14-release-announcement
Versión antigua, ya no se mantiene: 1,15 20 de junio de 2019 6 de mayo de 2020 https://kubernetes.io/blog/2019/06/19/kubernetes-1-15-release-announcement
Versión antigua, ya no se mantiene: 1,16 22 de octubre de 2019 2 de septiembre de 2020 https://kubernetes.io/blog/2019/09/18/kubernetes-1-16-release-announcement
Versión antigua, ya no se mantiene: 1,17 9 de diciembre de 2019 30 de enero de 2021 https://kubernetes.io/blog/2019/12/09/kubernetes-1-17-release-announcement
Versión antigua, ya no se mantiene: 1,18 25 marzo 2020 30 de abril de 2021 https://kubernetes.io/blog/2020/03/25/kubernetes-1-18-release-announcement
Versión anterior, pero aún se mantiene: 1,19 26 agosto 2020 30 de septiembre de 2021 A partir de la versión 1.19 de Kubernetes, la ventana de soporte se extenderá a un año https://kubernetes.io/blog/2020/08/26/kubernetes-release-1.19-accentuate-the-paw-sitive
Versión anterior, pero aún se mantiene: 1,20 8 de diciembre de 2020 30 de diciembre de 2021 https://kubernetes.io/blog/2020/12/08/kubernetes-1-20-release-announcement/
Versión anterior, pero aún se mantiene: 1,21 8 de abril de 2021 30 de abril de 2022 https://kubernetes.io/blog/2021/04/08/kubernetes-1-21-release-announcement/
Versión estable actual: 1,22 4 de agosto de 2021 4 de agosto de 2022 https://kubernetes.io/blog/2021/08/04/kubernetes-1-22-release-announcement/
Lanzamiento futuro: 1,23 7 de diciembre de 2021 7 de diciembre de 2022 https://www.kubernetes.dev/resources/release/
Leyenda:
Versión antigua
Versión anterior, aún mantenida
Ultima versión
Última versión de vista previa
Lanzamiento futuro

Ventanas de soporte

El cuadro a continuación muestra el período durante el cual cada versión es / fue compatible.

Conceptos

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 o métricas personalizadas. 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. 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.

Objetos de clúster

Plano de control

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 solo nodo maestro como en varios maestros que admiten clústeres de alta disponibilidad . Los diversos componentes del plano de control de Kubernetes son los siguientes:

  • etcd: etcd es un almacén de datos de valor clave persistente, liviano, distribuido desarrollado por CoreOS que almacena de manera confiable los datos de configuración del clúster, que representan el estado general del clúster en cualquier momento dado. Al igual que Apache ZooKeeper , etcd es un sistema que favorece la coherencia sobre la disponibilidad en caso de una partición de red (ver teorema CAP ). Esta consistencia es crucial para programar y operar correctamente los servicios. El servidor de API de Kubernetes utiliza la API de vigilancia de etcd para monitorear el clúster e implementar cambios de configuración críticos o simplemente restaurar cualquier divergencia del estado del clúster a lo declarado por 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.
  • 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. El servidor de API procesa y valida las solicitudes REST y actualiza el estado de los objetos de API en etcd, lo que permite a los clientes configurar cargas de trabajo y contenedores en los nodos de trabajo.
  • 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.
  • 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.). 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 ejecutando 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. 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. El conjunto de pods que administra un controlador está determinado por selectores de etiquetas que forman parte de la definición del controlador.

Nodos

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.
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.
  • 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. 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 .

Espacios de nombres

Kubernetes proporciona una partición de los recursos que administra en conjuntos no superpuestos llamados espacios de nombres. 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.

DaemonSets

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.

Objetos de carga de trabajo

Vainas

La unidad de programación básica en Kubernetes es un pod . Una vaina es una agrupación de componentes en contenedores. Un pod consta de uno o más contenedores que están garantizados para estar ubicados en el mismo nodo.

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. 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. Los pods se pueden administrar manualmente a través de la API de Kubernetes o su administración se puede delegar a un controlador. 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 Secretos (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 a contenedores autorizados).

ReplicaSets

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.

También se puede decir que ReplicaSets 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 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

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. Kubernetes proporciona dos modos de descubrimiento de servicios , usando variables ambientales o usando DNS de Kubernetes. El descubrimiento de servicios asigna una dirección IP estable y un nombre DNS al servicio, y la carga equilibra el 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 una máquina a otra). ). De forma predeterminada, un servicio está expuesto dentro de un clúster (p. Ej., Los pods de back-end pueden agruparse 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 (p. Ej., para que los clientes lleguen a los pods de front-end).

Volúmenes

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 proporciona almacenamiento persistente que existe durante la vida útil del 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.

ConfigMaps y secretos

Un desafío común de las aplicaciones es decidir dónde almacenar y administrar la información de configuración, algunos de los cuales pueden 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 de 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

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 primaria 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. Los StatefulSets son controladores (consulte Controller Manager , más arriba) proporcionados por Kubernetes que imponen las propiedades de unicidad y orden entre las instancias de un pod y se pueden usar para ejecutar aplicaciones con estado.

Implementaciones y controladores de replicación

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 de ReplicaSet, las implementaciones administrarán lo que sucede con 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.

Etiquetas y selectores

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. 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:

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

Complementos

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

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, 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.

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.

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.

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.

API

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 de naturaleza declarativa. Hay dos tipos de recursos de API. La mayoría de los recursos de la API en la API de Kubernetes son objetos. Estos representan una instancia concreta de un concepto en el clúster, como un pod o un espacio de nombres. Un pequeño número de tipos de recursos de API son "virtuales". Estos representan operaciones en lugar de objetos, como una verificación de permisos, utilizando el recurso "subjectaccessreviews". Los recursos de la API que corresponden a los objetos se representarán en el clúster con identificadores únicos para los objetos. Los recursos virtuales no tienen identificadores únicos.

Operadores

Kubernetes se puede ampliar mediante recursos personalizados. Estos recursos de API representan objetos que no forman parte del producto estándar de Kubernetes. Estos recursos pueden aparecer y desaparecer en un clúster en ejecución mediante el registro dinámico. Los administradores del clúster pueden actualizar los recursos personalizados independientemente del clúster.

Los controladores personalizados son otro mecanismo de extensión. Estos interactúan con los recursos personalizados y permiten una verdadera API declarativa que permite la gestión del ciclo de vida de los recursos personalizados que está alineada con la forma en que Kubernetes está diseñado. La combinación de recursos personalizados y controladores personalizados a menudo se conoce como un operador (de Kubernetes). El caso de uso clave para los operadores es capturar el objetivo de un operador humano que está administrando un servicio o conjunto de servicios e implementarlos mediante la automatización y con una API declarativa que respalde esta automatización. Los operadores humanos que se ocupan 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. Los ejemplos de problemas resueltos por los operadores incluyen realizar y restaurar copias de seguridad del estado de esa aplicación y manejar las actualizaciones del código de la aplicación junto con los cambios relacionados, como los esquemas de la base de datos o los ajustes de configuración adicionales.

API de clúster

Los mismos principios de diseño de API se han utilizado para definir una API para crear, configurar y administrar clústeres de Kubernetes mediante programación. Esto se llama 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

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

Referencias

enlaces externos