¡Bienvenido a la documentación de Kubernetes en Castellano!
Como podrá comprobar, la mayor parte de la documentación aún está disponible solo en inglés, pero no se preocupe, hay un equipo trabajando en la traducción al castellano.
Si quiere participar, puede entrar al canal de Slack #kubernetes-docs-es y formar parte del equipo detrás de la localización.
También puede pasar por el canal para solicitar la traducción de alguna página en concreto o reportar algún error que se haya podido encontrar. ¡Cualquier aportación será bien recibida!
Este sitio contiene documentación para la versión actual de Kubernetes
y las cuatro versiones anteriores de Kubernetes.
La disponibilidad de la documentación para una versión de Kubernetes es distinta de si
esa versión es compatible actualmente.
Lea Período de soporte para obtener información sobre
qué versiones de Kubernetes son oficialmente compatibles y durante cuánto tiempo.
2 - Setup
En esta sección encontrarás toda la información necesaria para poder identificar
la solución que mejor se adapta a tus necesidades.
Decidir dónde ejecutar Kubernetes depende principalmente de los recursos que
tengas disponibles, de las características del clúster y de cuánta flexibilidad
necesites.
Puedes ejecutar Kubernetes casi en cualquier lugar, desde su ordenador portátil
a máquinas virtuales en la nube o en un rack de servidores físicos on-premises.
Puedes configurar un clúster totalmente gestionado ejecutando un solo comando,
desplegar una solución parcialmente automatizada que te ofrezca un poco más de
control o directamente crear tu propio clúster de forma completamente manual
personalizando y controlando cada componente.
Soluciones para la máquina en local
Una solución para la máquina en local es la forma más sencilla de empezar a
utilizar Kubernetes. Puedes crear y probar clústeres de Kubernetes sin tener
que preocuparte por consumir recursos en el cloud ni disponer de conectividad.
Deberías elegir una solución de este tipo si buscas:
Probar o empezar a aprender sobre Kubernetes.
Desarrollar y testear clústeres localmente.
Soluciones gestionadas
Una solución gestionada es la forma más conveniente de crear y gestionar un
clúster de Kubernetes. El proveedor gestiona y opera los clústeres completamente
por lo que tú no has de preocuparte de nada.
Deberías elegir una solución de este tipo si:
Quieres una solución totalmente gestionada.
Quieres centrarte en desarrollar tus aplicaciones o servicios.
No tienes un equipo dedicado de operaciones pero quieres alta disponibilidad.
No tienes recursos para alojar y monitorizar sus clústeres.
Soluciones sobre IaaS en la nube
Un solución sobre IaaS en la nube permite crear clústeres Kubernetes con solo
unos pocos comandos, se encuentran en desarrollo activo, tienen el apoyo de la
comunidad y algunas de ellas forman parte del proyecto Kubernetes.
Se pueden desplegar en la infraestructura como servicio (IaaS) proporcionada por
los proveedores en la nube y ofrecen más flexibilidad que las soluciones
gestionadas, pero requieren más conocimientos para ponerlos en marcha y más
esfuerzo para operarlos.
Deberías elegir una solución de este tipo si:
Necesitas más control que el permitido en las soluciones gestionadas.
Quieres responsabilizarte de la operativa de los clústeres.
Soluciones sobre virtualización On-Premises
Una solución sobre virtualización sobre on-premises permite crear clústeres y
operarlos de forma segura en tú nube privada con solo unos pocos comandos.
Deberías elegir una solución de este tipo si:
Quieres desplegar clústeres en su nube privada dentro de tú red.
Tienes un equipo de operaciones para desplegar y operar el clúster.
Tienes los recursos necesarios para ejecutar y monitorizar el clúster.
Soluciones personalizadas
Una solución personalizadas proporciona total libertad sobre los clústeres
pero requiere más conocimiento y experiencia.
2.1 - Descargando Kubernetes
2.1.1 - Compilando desde código fuente
Se puede o bien crear una release desde el código fuente o bien descargar una versión pre-built. Si no se pretende hacer un desarrollo de Kubernetes en sí mismo, se sugiere usar una version pre-built de la release actual, que se puede encontrar en Release Notes.
El código fuente de Kubernetes se puede descargar desde el repositorio kubernetes/kubernetes .
Compilar desde código fuente
Si simplemente estas compilando una release desde el código fuente, no es necesario hacer una configuración completa del entorno golang ya que toda la compilación se realiza desde un contenedor Docker.
Compilar es fácil.
git clone https://github.com/kubernetes/kubernetes.git
cd kubernetes
make release
Para más detalles sobre el proceso de compilación de una release, visita la carpeta kubernetes/kubernetes build
2.2 - Desplegando un clúster con kubeadm
2.3 - Soluciones sobre IaaS en la nube
2.4 - Soluciones sobre virtualización On-Premises
2.5 - Soluciones personalizadas
2.6 - Kubernetes sobre Windows
3 - Conceptos
La sección de conceptos te ayudará a conocer los componentes de Kubernetes así como las abstracciones que utiliza para representar tu cluster. Además, te ayudará a obtener un conocimiento más profundo sobre cómo funciona Kubernetes.
Introducción
En Kubernetes se utilizan los objetos de la API de Kubernetes para describir el estado deseado del clúster: qué aplicaciones u otras cargas de trabajo se quieren ejecutar, qué imagenes de contenedores usan, el número de replicas, qué red y qué recursos de almacenamiento quieres que tengan disponibles, etc. Se especifica el estado deseado del clúster mediante la creación de objetos usando la API de Kubernetes, típicamente mediante la interfaz de línea de comandos, kubectl. También se puede usar la API de Kubernetes directamente para interactuar con el clúster y especificar o modificar tu estado deseado.
Una vez que se especifica el estado deseado, el Plano de Control de Kubernetes realizará las acciones necesarias para que el estado actual del clúster coincida con el estado deseado. Para ello, Kubernetes realiza diferentes tareas de forma automática, como pueden ser: parar o arrancar contenedores, escalar el número de réplicas de una aplicación dada, etc. El Plano de Control de Kubernetes consiste en un grupo de daemons que corren en tu clúster:
El Master de Kubernetes es un conjunto de tres daemons que se ejecutan en un único nodo del clúster, que se denomina nodo master. Estos daemons son: kube-apiserver, kube-controller-manager y kube-scheduler.
Los restantes nodos no master contenidos en tu clúster, ejecutan los siguientes dos daemons:
kubelet, el cual se comunica con el Master de Kubernetes.
kube-proxy, un proxy de red que implementa los servicios de red de Kubernetes en cada nodo.
Objetos de Kubernetes
Kubernetes tiene diferentes abstracciones que representan el estado de tu sistema: aplicaciones contenerizadas desplegadas y cargas de trabajo, sus recursos de red y almacenamiento asociados e información adicional acerca de lo que el clúster está haciendo en un momento dado. Estas abstracciones están representadas por objetos de la API de Kubernetes. Puedes revisar [Entendiendo los Objetos de Kubernetes] (/docs/concepts/overview/working-with-objects/kubernetes-objects/) para obtener más detalles.
Además, Kubernetes contiene abstracciónes de nivel superior llamadas Controladores. Los Controladores se basan en los objetos básicos y proporcionan funcionalidades adicionales sobre ellos. Incluyen:
Los distintos componentes del Plano de Control de Kubernetes, tales como el Master de Kubernetes y el proceso kubelet, gobiernan cómo Kubernetes se comunica con el clúster. El Plano de Control mantiene un registro de todos los Objetos de Kubernetes presentes en el sistema y ejecuta continuos bucles de control para gestionar el estado de los mismos. En un momento dado, los bucles del Plano de Control responderán a los cambios que se realicen en el clúster y ejecutarán las acciones necesarias para hacer que el estado actual de todos los objetos del sistema converjan hacia el estado deseado que has proporcionado.
Por ejemplo, cuando usas la API de Kubernetes para crear un Deployment, estás proporcionando un nuevo estado deseado para el sistema. El Plano de Control de Kubernetes registra la creación del objeto y lleva a cabo tus instrucciones ejecutando las aplicaciones requeridas en los nodos del clúster, haciendo de esta manera que el estado actual coincida con el estado deseado.
El Master de Kubernetes
El Master de Kubernetes es el responsable de mantener el estado deseado de tu clúster. Cuando interactuas con Kubernetes, como por ejemplo cuando utilizas la interfaz de línea de comandos kubectl, te estás comunicando con el master de tu clúster de Kubernetes.
Por "master" entendemos la colección de daemons que gestionan el estado del clúster. Típicamente, estos daemons se ejecutan todos en un único nodo del clúster, y este nodo recibe por tanto la denominación de master. El master puede estar replicado por motivos de disponibilidad y redundancia.
Kubernetes Nodes
En un clúster de Kubernetes, los nodos son las máquinas (máquinas virtuales, servidores físicos, etc) que ejecutan tus aplicaciones y flujos de trabajo en la nube. El master de Kubernetes controla cada nodo, por lo que en raras ocasiones interactuarás con los nodos directamente.
Si quieres empezar a contribuir a la documentación de Kubernetes accede a la página Empieza a contribuir.
3.1 - Introducción
3.1.1 - ¿Qué es Kubernetes?
Esta página ofrece una visión general sobre Kubernetes.
Kubernetes es una plataforma portable y extensible de código abierto para
administrar cargas de trabajo y servicios. Kubernetes facilita la automatización
y la configuración declarativa. Tiene un ecosistema grande y en rápido crecimiento.
El soporte, las herramientas y los servicios para Kubernetes están ampliamente disponibles.
¿Por qué necesito Kubernetes y qué puede hacer por mi?
Kubernetes tiene varias características. Puedes pensar en Kubernetes como:
una plataforma de contenedores
una plataforma de microservicios
una plataforma portable de nube
y mucho más.
Kubernetes ofrece un entorno de administración centrado en contenedores. Kubernetes
orquesta la infraestructura de cómputo, redes y almacenamiento para que las cargas de
trabajo de los usuarios no tengan que hacerlo. Esto ofrece la simplicidad de las Plataformas
como Servicio (PaaS) con la flexibilidad de la Infraestructura como Servicio (IaaS) y permite
la portabilidad entre proveedores de infraestructura.
¿Qué hace de Kubernetes una plataforma?
A pesar de que Kubernetes ya ofrece muchas funcionalidades, siempre hay nuevos
escenarios que se benefician de nuevas características. Los flujos de trabajo
de las aplicaciones pueden optimizarse para acelerar el tiempo de desarrollo.
Una solución de orquestación propia puede ser suficiente al principio, pero suele requerir
una automatización robusta cuando necesita escalar. Es por ello que Kubernetes fue diseñada como
una plataforma: para poder construir un ecosistema de componentes y herramientas que hacen
más fácil el desplegar, escalar y administrar aplicaciones.
Las etiquetas, o Labels, le
permiten a los usuarios organizar sus recursos como deseen. Las anotaciones, o Annotations, les permiten asignar información arbitraria a un recurso para
facilitar sus flujos de trabajo y hacer más fácil a las herramientas administrativas inspeccionar el estado.
Este
diseño
ha permitido que otros sistemas sean construidos sobre Kubernetes.
Lo que Kubernetes no es
Kubernetes no es una Plataforma como Servicio (PaaS) convencional. Ya que
Kubernetes opera a nivel del contenedor y no a nivel del hardware, ofrece
algunas características que las PaaS también ofrecen, como deployments,
escalado, balanceo de carga, registros y monitoreo. Dicho esto, Kubernetes
no es monolítico y las soluciones que se ofrecen de forma predeterminada
son opcionales e intercambiables.
Kubernetes ofrece los elementos esenciales para construir una plataforma
para desarrolladores, preservando la elección del usuario y la flexibilidad
en las partes más importantes.
Entonces, podemos decir que Kubernetes:
No limita el tipo de aplicaciones que soporta. Kubernetes busca dar soporte a un número diverso de cargas de trabajo, que incluyen aplicaciones con y sin estado así como aplicaciones que procesan datos. Si la aplicación puede correr en un contenedor, debería correr bien en Kubernetes.
No hace deployment de código fuente ni compila tu aplicación. Los flujos de integración, entrega y deployment continuo (CI/CD) vienen determinados por la cultura y preferencia organizacional y sus requerimientos técnicos.
No provee servicios en capa de aplicación como middleware (por ejemplo, buses de mensaje), frameworks de procesamiento de datos (como Spark), bases de datos (como MySQL), caches o sistemas de almacenamiento (como Ceph). Es posible correr estas aplicaciones en Kubernetes, o acceder a ellos desde una aplicación usando un mecanismo portable como el Open Service Broker.
No dictamina las soluciones de registros, monitoreo o alerta que se deben usar. Hay algunas integraciones que se ofrecen como prueba de concepto, y existen mecanismos para recolectar y exportar métricas.
No provee ni obliga a usar un sistema o lenguaje de configuración (como jsonnet) sino que ofrece una API declarativa que puede ser usada con cualquier forma de especificación declarativa
No provee ni adopta un sistema exhaustivo de mantenimiento, administración o corrección automática de errores
Además, Kubernetes no es un mero sistema de orquestación. De hecho, Kubernetes elimina la necesidad de orquestar. Orquestación se define como la ejecución de un flujo de trabajo definido: haz A, luego B y entonces C. Kubernetes está compuesto de un conjunto de procesos de control independientes y combinables entre si que llevan el estado actual hacia el estado deseado. No debería importar demasiado como llegar de A a C. No se requiere control centralizado y, como resultado, el sistema es más fácil de usar, más poderoso, robusto, resiliente y extensible.
¿Por qué usar contenedores?
¿Te preguntas las razones para usar contenedores?
La Manera Antigua de desplegar aplicaciones era instalarlas en un
servidor usando el administrador de paquetes del sistema operativo.
La desventaja era que los ejecutables, la configuración, las librerías
y el ciclo de vida de todos estos componentes se entretejían unos a
otros. Podíamos construir imágenes de máquina virtual inmutables para
tener rollouts y rollbacks predecibles, pero las máquinas virtuales
son pesadas y poco portables.
La Manera Nueva es desplegar contenedores basados en virtualización
a nivel del sistema operativo, en vez del hardware. Estos contenedores
están aislados entre ellos y con el servidor anfitrión: tienen sus propios
sistemas de archivos, no ven los procesos de los demás y el uso de recursos
puede ser limitado. Son más fáciles de construir que una máquina virtual, y
porque no están acoplados a la infraestructura y sistema de archivos del
anfitrión, pueden llevarse entre nubes y distribuciones de sistema operativo.
Ya que los contenedores son pequeños y rápidos, una aplicación puede ser
empaquetada en una imagen de contenedor. Esta relación uno a uno entre
aplicación e imagen nos abre un abanico de beneficios para usar contenedores.
Con contenedores, podemos crear imágenes inmutables al momento de la compilación
en vez del despliegue ya que las aplicaciones no necesitan componerse junto al
resto del stack ni atarse al entorno de infraestructura de producción. Generar
una imagen de contenedor al momento de la compilación permite tener un entorno
consistente que va desde desarrollo hasta producción. De igual forma, los contenedores
son más transparentes que las máquinas virtuales y eso hace que el monitoreo y la
administración sean más fáciles. Esto se aprecia más cuando los ciclos de vida de
los contenedores son administrados por la infraestructura en vez de un proceso supervisor
escondido en el contenedor. Por último, ya que solo hay una aplicación por contenedor,
administrar el despliegue de la aplicación se reduce a administrar el contenedor.
En resumen, los beneficios de usar contenedores incluyen:
Ágil creación y despliegue de aplicaciones:
Mayor facilidad y eficiencia al crear imágenes de contenedor en vez de máquinas virtuales
Desarrollo, integración y despliegue continuo:
Permite que la imagen de contenedor se construya y despliegue de forma frecuente y confiable,
facilitando los rollbacks pues la imagen es inmutable
Separación de tareas entre Dev y Ops:
Puedes crear imágenes de contenedor al momento de compilar y no al desplegar, desacoplando la
aplicación de la infraestructura
Observabilidad
No solamente se presenta la información y métricas del sistema operativo, sino la salud de la
aplicación y otras señales
Consistencia entre los entornos de desarrollo, pruebas y producción:
La aplicación funciona igual en un laptop y en la nube
Portabilidad entre nubes y distribuciones:
Funciona en Ubuntu, RHEL, CoreOS, tu datacenter físico, Google Kubernetes Engine y todo lo demás
Administración centrada en la aplicación:
Eleva el nivel de abstracción del sistema operativo y el hardware virtualizado a la aplicación que funciona en un sistema con recursos lógicos
Microservicios distribuidos, elásticos, liberados y débilmente acoplados:
Las aplicaciones se separan en piezas pequeñas e independientes que pueden ser desplegadas y administradas de forma dinámica, y no como una aplicación monolítica que opera en una sola máquina de gran capacidad
Aislamiento de recursos:
Hace el rendimiento de la aplicación más predecible
Utilización de recursos:
Permite mayor eficiencia y densidad
¿Qué significa Kubernetes? ¿Qué significa K8S?
El nombre Kubernetes proviene del griego y significa timonel o piloto. Es la raíz de gobernador y de cibernética. K8s
es una abrevación que se obtiene al reemplazar las ocho letras "ubernete" con el número 8.
Este documento describe los distintos componentes que
son necesarios para operar un clúster de Kubernetes.
Componentes del plano de control
Los componentes que forman el plano de control toman decisiones globales sobre
el clúster (por ejemplo, la planificación) y detectan y responden a eventos del clúster, como la creación
de un nuevo pod cuando la propiedad replicas de un controlador de replicación no se cumple.
Estos componentes pueden ejecutarse en cualquier nodo del clúster. Sin embargo para simplificar, los
scripts de instalación típicamente se inician en el mismo nodo de forma exclusiva,
sin que se ejecuten contenedores de los usuarios en esos nodos. El plano de control se ejecuta en varios nodos
para garantizar la alta disponibilidad.
kube-apiserver
El servidor de la API es el componente del plano de control
de Kubernetes que expone la API de Kubernetes. Se trata del frontend de Kubernetes,
recibe las peticiones y actualiza acordemente el estado en etcd.
La principal implementación de un servidor de la API de Kubernetes es
kube-apiserver.
Es una implementación preparada para ejecutarse en alta disponiblidad y que
puede escalar horizontalmente para balancear la carga entre varias instancias.
etcd
Almacén de datos persistente, consistente y distribuido de clave-valor utilizado
para almacenar toda a la información del clúster de Kubernetes.
Si tu clúster utiliza etcd como sistema de almacenamiento, échale un vistazo a la
documentación sobre estrategias de backup.
Componente del plano de control que está pendiente de los
Pods que no tienen ningún
nodo asignado
y seleciona uno donde ejecutarlo.
Para decidir en qué nodo
se ejecutará el pod, se tienen
en cuenta diversos factores: requisitos de recursos, restricciones de hardware/software/políticas,
afinidad y anti-afinidad, localización de datos dependientes, entre otros.
kube-controller-manager
Componente del plano de control que ejecuta los controladores de Kubernetes.
Lógicamente cada controlador
es un proceso independiente, pero para reducir la complejidad, todos se compilan
en un único binario y se ejecuta en un mismo proceso.
Estos controladores incluyen:
Controlador de nodos: es el responsable de detectar y responder cuándo un nodo deja de funcionar
Controlador de replicación: es el responsable de mantener el número correcto de pods para cada controlador
de replicación del sistema
Controlador de endpoints: construye el objeto Endpoints, es decir, hace una unión entre los Services y los Pods
Controladores de tokens y cuentas de servicio: crean cuentas y tokens de acceso a la API por defecto para los nuevos Namespaces.
cloud-controller-manager
cloud-controller-manager ejecuta controladores que
interactúan con proveedores de la nube. El binario cloud-controller-manager es una característica alpha que se introdujo en la versión 1.6 de Kubernetes.
cloud-controller-manager sólo ejecuta ciclos de control específicos para cada proveedor de la nube. Es posible
desactivar estos ciclos en kube-controller-manager pasando la opción --cloud-provider= external cuando se arranque el kube-controller-manager.
cloud-controller-manager permite que el código de Kubernetes y el del proveedor de la nube evolucionen de manera independiente. Anteriormente, el código de Kubernetes dependía de la funcionalidad específica de cada proveedor de la nube. En el futuro, el código que sea específico a una plataforma debería ser mantenido por el proveedor de la nube y enlazado a cloud-controller-manager al correr Kubernetes.
Los siguientes controladores dependen de alguna forma de un proveedor de la nube:
Controlador de nodos: es el responsable de detectar y actuar cuándo un nodo deja de responder
Controlador de rutas: para configurar rutas en la infraestructura de nube subyacente
Controlador de servicios: para crear, actualizar y eliminar balanceadores de carga en la nube
Controlador de volúmenes: para crear, conectar y montar volúmenes e interactuar con el proveedor de la nube para orquestarlos
Componentes de nodo
Los componentes de nodo corren en cada nodo, manteniendo a los pods en funcionamiento y proporcionando el entorno de ejecución de Kubernetes.
kubelet
Agente que se ejecuta en cada nodo de un clúster. Se asegura de que los contenedores estén corriendo en un pod.
El agente kubelet toma un conjunto de especificaciones de Pod, llamados
PodSpecs, que han sido creados por Kubernetes y garantiza que los contenedores descritos en ellos estén funcionando y
en buen estado.
kube-proxy
kube-proxy permite abstraer un servicio en Kubernetes manteniendo las
reglas de red en el anfitrión y haciendo reenvío de conexiones.
Los addons son pods y servicios que implementan funcionalidades del clúster. Estos pueden ser administrados
por Deployments, ReplicationControllers y otros. Los addons asignados a un espacio de nombres se crean en el espacio kube-system.
Más abajo se describen algunos addons. Para una lista más completa de los addons disponibles, por favor visite Addons.
DNS
Si bien los otros addons no son estrictamente necesarios, todos los clústers de Kubernetes deberían tener un DNS interno del clúster ya que la mayoría de los ejemplos lo requieren.
El DNS interno del clúster es un servidor DNS, adicional a los que ya podrías tener en tu red, que sirve registros DNS a los servicios de Kubernetes.
Los contenedores que son iniciados por Kubernetes incluyen automáticamente este servidor en sus búsquedas DNS.
Interfaz Web (Dashboard)
El Dashboard es una interfaz Web de propósito general para clústeres de Kubernetes. Le permite a los usuarios administrar y resolver problemas que puedan presentar tanto las aplicaciones como el clúster.
Monitor de recursos de contenedores
El Monitor de recursos de contenedores almacena
de forma centralizada series de tiempo con métricas sobre los contenedores, y provee una interfaz para navegar estos
datos.
Registros del clúster
El mecanismo de registros del clúster está a cargo de almacenar
los registros de los contenedores de forma centralizada, proporcionando una interfaz de búsqueda y navegación.
La API de Kubernetes sirve como base para el esquema de configuración declarativa del sistema. La herramienta de
línea de comandos kubectl puede ser usada para crear, actualizar, eliminar y consultar objetos a través de la API.
Kubernetes también almacena el estado de los recursos de la API en forma serializada. Actualmente esto se hace en etcd.
Kubernetes está compuesto, en si mismo, por varios componentes que interactúan a través de su API.
Cambios a la API
En nuestra experiencia, cualquier sistema exitoso necesita crecer y evolucionar al cambiar o emerger nuevos casos de uso. Por lo tanto, esperamos que la API de Kubernetes cambie y crezca continuamente. Dicho esto, nuestro objetivo es no romper la compatibilidad con los clientes ya existentes, por un período de tiempo razonable. En general, podemos esperar que se agreguen nuevos recursos y propiedades con cierta frecuencia. Para eliminar un recurso o propiedad, se requiere seguir la política de obsolescencia de la API.
En el documento de cambios a la API describimos como cambiar la API y definimos lo que es considerado como un cambio compatible.
Definiciones OpenAPI y Swagger
Los detalles completos de la API se documentan usando OpenAPI.
A partir de Kubernetes 1.10, el servidor de API de Kubernetes provee una especificación OpenAPI en el endpoint /openapi/v2.
Se puede solicitar un formato en particular utilizando las siguientes cabeceras HTTP:
Cabecera
Valores admitidos
Accept
application/json, application/com.github.proto-openapi.spec.v2@v1.0+protobuf (el content-type predeterminado es application/json si esta cabecera contiene */* o se omite)
Accept-Encoding
gzip (esta cabecera es opcional)
Antes de 1.14, los endpoints separados por formato (/swagger.json, /swagger-2.0.0.json, /swagger-2.0.0.pb-v1, /swagger-2.0.0.pb-v1.gz)
servían la especificación OpenAPI en distintos formatos. Estos endpoints se consideran obsoletos y serán removidos en Kubernetes 1.14.
Kubernetes implementa un formato alternativo de serialización basado en Protocol Buffer (Protobuf) diseñado principalmente para las comunicaciones dentro del clúster. Este formato está documentado en su propuesta de diseño y los archivos IDL de cada esquema se encuentran en los paquetes de Go que definen los objetos de la API.
Antes de 1.14, el apiserver de Kubernetes ofrecía una API para obtener la especificación Swagger v1.2 de la API de Kubernetes en /swaggerapi. Este endpoint se considera obsoleto y será removido en Kubernetes 1.14.
Versionado de la API
Para facilitar la eliminación de propiedades o reestructurar la representación de un recurso, Kubernetes soporta múltiples versiones de la API en distintas rutas como /api/v1 or /apis/extensions/v1beta1.
Se versiona a nivel de la API en vez de a nivel de los recursos o propiedades para asegurarnos de que la API presenta una visión clara y consistente de los recursos y el comportamiento del sistema, y para controlar el acceso a las APIs experimentales o que estén terminando su ciclo de vida. Los esquemas de serialización JSON y Protobuf siguen los mismos lineamientos para los cambios, es decir, estas descripciones cubren ambos formatos.
Se ha de tener en cuenta que hay una relación indirecta entre el versionado de la API y el versionado del resto del software. La propuesta de versionado de la API y releases describe esta relación.
Las distintas versiones de la API implican distintos niveles de estabilidad y soporte. El criterio para cada nivel se describe en detalle en la documentación de Cambios a la API. A continuación se ofrece un resumen:
Nivel "alpha":
El nombre de la versión contiene alpha (p. ej., v1alpha1).
Puede tener muchos errores. Activar esta característica podría exponer errores. Desactivada por defecto.
El soporte para esta característica podría ser eliminado sin previo aviso.
La API podría volverse incompatible en el futuro y sin previo aviso.
Se recomienda su uso solo en clústers efímeros y de prueba ya que hay mayor riesgo de errores y carece de soporte a largo plazo
Nivel "beta":
El nombre de la versión contiene beta (p. ej., v2beta3).
El código ha sido probado. Activar esta característica es seguro. Activada por defecto.
Los detalles de esta característica podrían cambiar, pero se mantendrá el soporte.
El esquema y/o la semántica de un objeto podría volverse incompatible en el futuro. Si esto pasa, se ofrecerán instrucciones para migrar a una nueva versión. Esto podría requerir eliminar, editar o volver a crear objetos. El proceso de edición podría requerir planificación, incluyendo tiempo de inactividad para aplicaciones que usaban esta característica.
No se recomienda para aplicaciones críticas de negocio ya que podría volverse incompatible en futuras versiones. Si tiene múltiples clústeres que pueden actualizarse de forma independiente se podría decidir correr este riesgo.
Por favor, ¡pruebe las características en fase beta y comparta sus comentarios! Una vez que salgan de la fase beta, sería más difícil hacer cambios.
Nivel estable:
El nombre de la versión es vX donde X es un entero.
Las versiones estables de las características aparecerán en los siguientes releases.
Grupos de API
Para que sea más fácil extender la API de Kubernetes, se han creado los grupos de API.
Estos grupos se especifican en una ruta REST y en la propiedad apiVersion de un objeto serializado.
Actualmente hay varios grupos de API en uso:
El grupo core (o group) en la ruta REST /api/v1 y usa apiVersion: v1.
Los grupos con entidad propia están en la ruta REST /apis/$NOMBRE_GRUPO/$VERSION y usan apiVersion: $NOMBRE_GRUPO/$VERSION.
(p. ej., apiVersion: batch/v1). La lista completa de los grupos soportados está disponible en la Referencia de la API.
Los usuarios que necesiten la semántica completa de la API pueden implementar su propio apiserver
usando el agregador para hacerlo
transparente para los clientes.
Activar los grupos de API
Ciertos recursos y grupos de API están activados por defecto. Pueden activarse o desactivarse con la opción --runtime-config en apiserver. --runtime-config acepta valores separados por coma. Por ejemplo, para desactivar batch/v1, use la opción
--runtime-config=batch/v1=false. Para activar batch/v2alpha1, pase la opción --runtime-config=batch/v2alpha1.
Esta opción acepta pares de clave=valor separados por coma que describen la configuración operativa del apiserver.
IMPORTANTE: Activar o desactivar grupos o recursos requiere reiniciar el apiserver y el controller-manager para que estos reconozcan los cambios a --runtime-config.
Activar recursos en los grupos
Los DaemonSets, Deployments, HorizontalPodAutoscalers, Ingresses, Jobs y ReplicaSets están activados por defecto.
Se pueden activar otros recursos con la opción --runtime-config del apiserver. Por ejemplo, como --runtime-config acepta valores separados por coma, puede desactivar los Deployments y los Ingress con la opción
--runtime-config=extensions/v1beta1/deployments=false,extensions/v1beta1/ingresses=false
3.1.4 - Objetos de Kubernetes
3.1.4.1 - Entender los Objetos de Kubernetes
Esta página explica cómo se representan los objetos de Kubernetes en la API de Kubernetes, y cómo puedes definirlos en formato .yaml.
Entender los Objetos de Kubernetes
Los Objetos de Kubernetes son entidades persistentes dentro del sistema de Kubernetes. Kubernetes utiliza estas entidades para representar el estado de tu clúster. Específicamente, pueden describir:
Qué aplicaciones corren en contenedores (y en qué nodos)
Los recursos disponibles para dichas aplicaciones
Las políticas acerca de cómo dichas aplicaciones se comportan, como las políticas de reinicio, actualización, y tolerancia a fallos
Un objeto de Kubernetes es un "registro de intención" -- una vez que has creado el objeto, el sistema de Kubernetes se pondrá en marcha para asegurar que el objeto existe. Al crear un objeto, en realidad le estás diciendo al sistema de Kubernetes cómo quieres que sea la carga de trabajo de tu clúster; esto es, el estado deseado de tu clúster.
Para trabajar con los objetos de Kubernetes -- sea para crearlos, modificarlos, o borrarlos -- necesitarás usar la API de Kubernetes. Cuando utilizas el interfaz de línea de comandos kubectl, por ejemplo, este realiza las llamadas necesarias a la API de Kubernetes en tu lugar. También puedes usar la API de Kubernetes directamente desde tus programas utilizando alguna de las Librerías de Cliente.
Alcance y Estado de un Objeto
Cada objeto de Kubernetes incluye dos campos como objetos anidados que determinan la configuración del objeto: el campo de objeto spec y el campo de objeto status. El campo spec, que es obligatorio, describe el estado deseado del objeto -- las características que quieres que tenga el objeto. El campo status describe el estado actual del objeto, y se suministra y actualiza directamente por el sistema de Kubernetes. En cualquier momento, el Plano de Control de Kubernetes gestiona de forma activa el estado actual del objeto para que coincida con el estado deseado requerido.
Por ejemplo, un Deployment de Kubernetes es un objeto que puede representar una aplicación de tu clúster. Cuando creas el Deployment, puedes especificar en el spec del Deployment que quieres correr tres réplicas de la aplicación. El sistema de Kubernetes lee el spec del Deployment y comienza a instanciar réplicas de tu aplicación -- actualizando el estado para conciliarlo con tu spec. Si cualquiera de las instancias falla (un cambio de estado), el sistema de Kubernetes soluciona la diferencia entre la spec y el estado llevando a cabo una correción -- en este caso, iniciando otra instancia de reemplazo.
Para obtener más información acerca de la spec, el status, y los metadatos de los objetos, echa un vistazo a las Normas de la API de Kubernetes.
Describir un Objeto de Kubernetes
Cuando creas un objeto en Kubernetes, debes especificar la spec del objeto que describe su estado deseado, así como información básica del mismo (como el nombre). Cuando usas la API de Kubernetes para crear el objeto (bien de forma directa o usando kubectl), dicha petición a la API debe incluir toda la información en formato JSON en el cuerpo de la petición. A menudo, le proporcionas la información a kubectl como un archivo .yaml.kubectl convierte esa información a JSON cuando realiza la llamada a la API.
Aquí hay un ejemplo de un archivo .yaml que muestra los campos requeridos y la spec del objeto Deployment de Kubernetes:
apiVersion:apps/v1# Usa apps/v1beta2 para versiones anteriores a 1.9.0kind:Deploymentmetadata:name:nginx-deploymentspec:selector:matchLabels:app:nginxreplicas:2# indica al controlador que ejecute 2 podstemplate:metadata:labels:app:nginxspec:containers:- name:nginximage:nginx:1.7.9ports:- containerPort:80
Una forma de crear un Deployment utilizando un archivo .yaml como el indicado arriba sería ejecutar el comando
kubectl apply
en el interfaz de línea de comandos, pasándole el archivo .yaml como argumento. Aquí tienes un ejemplo de cómo hacerlo:
En el archivo .yaml del objeto de Kubernetes que quieras crear, obligatoriamente tendrás que indicar los valores de los siguientes campos (como mínimo):
apiVersion - Qué versión de la API de Kubernetes estás usando para crear este objeto
kind - Qué clase de objeto quieres crear
metadata - Datos que permiten identificar unívocamente al objeto, incluyendo una cadena de texto para el name, UID, y opcionalmente el namespace
También deberás indicar el campo spec del objeto. El formato del campo spec es diferente según el tipo de objeto de Kubernetes, y contiene campos anidados específicos de cada objeto. La Referencia de la API de Kubernetes puede servirte de ayuda para encontrar el formato de la spec para cada uno de los objetos que puedes crear usando Kubernetes.
Por ejemplo, el formato de la spec para un objeto de tipo Pod lo puedes encontrar
aquí,
y el formato de la spec para un objeto de tipo Deployment lo puedes encontrar
aquí.
Siguientes pasos
Aprender más acerca de los objetos básicos más importantes de Kubernetes, como el Pod.
3.1.4.2 - Nombres
Todos los objetos de la API REST de Kubernetes se identifica de forma inequívoca mediante un Nombre y un UID.
Para aquellos atributos provistos por el usuario que no son únicos, Kubernetes provee de etiquetas y anotaciones.
Una cadena de caracteres proporcionada por el cliente que identifica un objeto en la URL de un recurso, como por ejemplo, /api/v1/pods/nombre-del-objeto.
Los nombres de los objetos son únicos para cada tipo de objeto. Sin embargo, si se elimina el objeto, se puede crear un nuevo objeto con el mismo nombre.
Por regla general, los nombres de los recursos de Kubernetes no deben exceder la longitud máxima de 253 caracteres y deben incluir caracteres alfanuméricos en minúscula, -, y .; aunque algunos recursos tienen restricciones más específicas.
UIDs
Una cadena de caracteres generada por Kubernetes para identificar objetos de forma única.
Cada objeto creado a lo largo de toda la vida de un clúster Kubernetes tiene un UID distinto. Está pensado para distinguir entre ocurrencias históricas de entidades similares.
3.1.4.3 - Espacios de nombres
Kubernetes soporta múltiples clústeres virtuales respaldados por el mismo clúster físico.
Estos clústeres virtuales se denominan espacios de nombres (namespaces).
Cuándo Usar Múltiple Espacios de Nombre
Los espacios de nombres están pensados para utilizarse en entornos con muchos usuarios
distribuidos entre múltiples equipos, o proyectos. Para aquellos clústeres con
unas pocas decenas de usuarios, no deberías necesitar crear o pensar en espacios de
nombres en absoluto. Empieza a usarlos solamente si necesitas las características
que proporcionan.
Los espacios de nombres proporcionan un campo de acción para los nombres. Los nombres de los recursos
tienen que ser únicos dentro de cada espacio de nombres, pero no entre dichos espacios de nombres.
Los espacios de nombres son una forma de dividir los recursos del clúster
entre múltiples usuarios (via cuotas de recursos).
En futuras versiones de Kubernetes, los objetos de un mismo espacio de nombres
tendrán las mismas políticas de control de acceso por defecto.
No es necesario usar múltiples espacios de nombres sólo para separar recursos
ligeramente diferentes, como versiones diferentes de la misma aplicación: para ello
utiliza etiquetas para distinguir tus recursos dentro
del mismo espacio de nombres.
Puedes listar los espacios de nombres actuales dentro de un clúster mediante:
kubectl get namespaces
NAME STATUS AGE
default Active 1d
kube-system Active 1d
kube-public Active 1d
Kubernetes arranca con tres espacios de nombres inicialmente:
default El espacio de nombres por defecto para aquellos objetos que no especifican ningún espacio de nombres
kube-system El espacio de nombres para aquellos objetos creados por el sistema de Kubernetes
kube-public Este espacio de nombres se crea de forma automática y es legible por todos los usuarios (incluyendo aquellos no autenticados).
Este espacio de nombres se reserva principalmente para uso interno del clúster, en caso de que algunos recursos necesiten ser visibles y legibles de forma pública para todo el clúster.
La naturaleza pública de este espacio de nombres es simplemente por convención, no es un requisito.
Establecer el espacio de nombres para una petición
Para indicar de forma temporal el espacio de nombres para una petición, usa la opción --namespace.
Por ejemplo:
kubectl --namespace=<insert-namespace-name-here> run nginx --image=nginx
kubectl --namespace=<insert-namespace-name-here> get pods
Establecer la preferencia de espacio de nombres
Puedes indicar de forma permanente el espacio de nombres para todas las llamadas futuras a comandos kubectl
en dicho contexto.
Cuando creas un Servicio, se crea una entrada DNS correspondiente.
Esta entrada tiene la forma <service-name>.<namespace-name>.svc.cluster.local, que significa
que si un contenedor simplemente usa <service-name>, se resolverá al servicio
que sea local al espacio de nombres. Esto es de utilidad para poder emplear la misma
configuración entre múltiples espacios de nombres como Development, Staging y Production.
Si quieres referenciar recursos entre distintos espacios de nombres, entonces
debes utilizar el nombre cualificado completo de dominio (FQDN).
No Todos los Objetos están en un Espacio de nombres
La mayoría de los recursos de Kubernetes (ej. pods, services, replication controllers, y otros) están
en algunos espacios de nombres. Sin embargo, los recursos que representan a los propios
espacios de nombres no están a su vez en espacios de nombres.
De forma similar, los recursos de bajo nivel, como los nodos y
los volúmenes persistentes, no están en ningún espacio de nombres.
Para comprobar qué recursos de Kubernetes están y no están en un espacio de nombres:
# In a namespacekubectl api-resources --namespaced=true# Not in a namespacekubectl api-resources --namespaced=false
3.1.4.4 - Etiquetas y Selectores
Las etiquetas son pares de clave/valor que se asocian a los objetos, como los pods.
El propósito de las etiquetas es permitir identificar atributos de los objetos que son relevantes y significativos para los usuarios, pero que no tienen significado para el sistema principal.
Se puede usar las etiquetas para organizar y seleccionar subconjuntos de objetos. Las etiquetas se pueden asociar a los objetos a la hora de crearlos y posteriormente modificarlas o añadir nuevas.
Cada objeto puede tener un conjunto de etiquetas clave/valor definidas, donde cada clave debe ser única para un mismo objeto.
Las etiquetas permiten consultar y monitorizar los objetos de forma más eficiente y son ideales para su uso en UIs y CLIs. El resto de información no identificada debe ser registrada usando anotaciones.
Motivación
Las etiquetas permiten que los usuarios mapeen sus estructuras organizacionales en los propios objetos sin acoplamiento, sin forzar a los clientes a almacenar estos mapeos.
Los despliegues de servicios y los procesos en lotes suelen requerir a menudo la gestión de entidades multi-dimensionales (ej., múltiples particiones o despliegues, múltiples entregas, múltiples capas, múltiples microservicios por capa). Tal gestión a menudo requiere de operaciones horizontales que rompen la encapsulación de representaciones estrictamente jerárquicas, especialmente jerarquías rígidas determinadas por la infraestructura en vez de por los usuarios.
Estos son sólo algunos ejemplos de etiquetas de uso común; eres libre de establecer tus propias normas. Ten en cuenta que la clave de cada etiqueta debe ser única dentro de cada objeto.
Sintaxis y conjunto de caracteres
Las etiquetas son pares de clave/valor. Las claves válidas de etiqueta tienen dos partes: un prefijo opcional y un nombre, separados por una barra (/). La parte del nombre es obligatoria y debe ser menor o igual a 63 caracteres, empezando y terminando con un carácter alfanumérico ([a-z0-9A-Z]), con guiones (-), guiones bajos (_), puntos (.), y cualquier carácter alfanumérico en medio. El prefijo es opcional. Si se indica, este debe ser un subdominio DNS: una serie de etiquetas DNS separadas por puntos (.), no mayores de 253 caracteres en total, seguidas de una barra (/).
Si se omite el prefijo, la clave de la etiqueta se entiende que es privada para el usuario. Los componentes automatizados del sistema (ej. kube-scheduler, kube-controller-manager, kube-apiserver, kubectl, u otros de terceras partes) que añaden etiquetas a los objetos de usuario deben especificar obligatoriamente un prefijo.
Los prefijos kubernetes.io/ y k8s.io/ están reservados para el sistema de Kubernetes.
Los valores de etiqueta válidos deben tener como máximo 63 caracteres y empezar y terminar con un carácter alfanumérico ([a-z0-9A-Z]), con guiones (-), guiones bajos (_), puntos (.), y cualquier carácter alfanumérico en medio.
Selectores de etiquetas
Al contrario que los nombres y UIDs, las etiquetas no garantizan la unicidad. En general, se espera que muchos objetos compartan la(s) misma(s) etiqueta(s).
A través del selector de etiqueta, el cliente/usuario puede identificar un conjunto de objetos. El selector de etiqueta es la primitiva principal de agrupación en Kubernetes.
La API actualmente soporta dos tipos de selectores: basados en igualdad y basados en conjunto.
Un selector de etiqueta puede componerse de múltiples requisitos separados por coma. En el caso de múltiples requisitos, todos ellos deben ser satisfechos de forma que las comas actúan como operadores AND (&&) lógicos.
La semántica de selectores vacíos o no espefificados es dependiente del contexto,
y los tipos de la API que utilizan los selectores deberían documentar su propia validación y significado.
Nota:
Para algunos tipos de la API, como los ReplicaSets, los selectores de etiqueta de dos instancias no deben superponerse dentro del mismo espacio de nombres, ya que el controlador puede interpretarlos como un conflicto y no ser capaz de determinar cuántas réplicas debería haber finalmente.
Requisito basado en Igualdad
Los requisitos basados en Igualdad o Desigualdad permiten filtrar por claves y valores de etiqueta. Los objetos coincidentes deben satisfacer todas y cada una de las etiquetas indicadas, aunque puedan tener otras etiquetas adicionalmente.
Se permiten tres clases de operadores =,==,!=. Los dos primeros representan la igualdad (y son simplemente sinónimos), mientras que el último representa la desigualdad. Por ejemplo:
environment = production
tier != frontend
El primero selecciona todos los recursos cuya clave es igual a environment y su valor es igual a production.
El último selecciona todos los recursos cuya clave es igual a tier y su valor distinto de frontend, y todos los recursos que no tengan etiquetas con la clave tier.
Se podría filtrar los recursos de production que excluyan frontend usando comas: environment=production,tier!=frontend
Un escenario de uso de requisitos basados en igualdad es aquel donde los Pods pueden especificar
los criterios de selección de nodo. Por ejemplo, el Pod de abajo selecciona aquellos nodos con
la etiqueta "accelerator=nvidia-tesla-p100".
Los requisitos de etiqueta basados en Conjuntos permiten el filtro de claves en base a un conjunto de valores. Se puede utilizar tres tipos de operadores: in,notin y exists (sólo el identificador clave). Por ejemplo:
environment in (production, qa)
tier notin (frontend, backend)
partition
!partition
El primer ejemplo selecciona todos los recursos cuya clave es igual a environment y su valor es igual a production o qa.
El segundo ejemplo selecciona todos los recursos cuya clave es igual a tier y sus valores son distintos de frontend y backend, y todos los recursos que no tengan etiquetas con la clavetier.
El tercer ejemplo selecciona todos los recursos que incluyan una etiqueta con la clave partition; sin comprobar los valores.
El cuarto ejemplo selecciona todos los recursos que no incluyan una etiqueta con la clave partition; sin comprobar los valores.
De forma similar, el separador de coma actúa como un operador AND . Así, el filtro de recursos con una clave igual a partition (sin importar el valor) y con un environment distinto de qa puede expresarse como partition,environment notin (qa).
El selector basado en conjunto es una forma genérica de igualdad puesto que environment=production es equivalente a environment in (production); y lo mismo aplica para != y notin.
Los requisitos basados en conjunto pueden alternarse con aquellos basados en igualdad. Por ejemplo: partition in (customerA, customerB),environment!=qa.
API
Filtro con LIST y WATCH
Las operaciones LIST y WATCH pueden especificar selectores de etiqueta para filtrar el conjunto de objetos devueltos usando un parámetro de consulta. Ambos requisitos están permitidos (se presentan aquí como aparecerían en la cadena URL de consulta):
requisitios basados en igualdad: ?labelSelector=environment%3Dproduction,tier%3Dfrontend
requisitios basados en conjunto: ?labelSelector=environment+in+%28production%2Cqa%29%2Ctier+in+%28frontend%29
Es posible utilizar ambos estilos de selección de etiquetas para mostrar u observar recursos con un cliente REST. Por ejemplo, para enfocarse en apiserver con kubectl usando el estilo basado en igualdad se puede ejecutar:
kubectl get pods -l environment=production,tier=frontend
o usando requisitos basados en conjunto:
kubectl get pods -l 'environment in (production),tier in (frontend)'
Como ya se ha comentado, los requisitos basados en conjunto son más expresivos. Por ejemplo, se puede implementar el operador OR sobre valores:
kubectl get pods -l 'environment in (production, qa)'
o restringir la coincidencia negativa mediante el operador notin:
kubectl get pods -l 'environment,environment notin (frontend)'
Establecer referencias en los objetos de la API
Algunos objetos de Kubernetes, como los services y los replicationcontrollers, también hacen uso de los selectores de etiqueta para referirse a otros conjuntos de objetos, como los pods.
Service y ReplicationController
El conjunto de pods que un service expone se define con un selector de etiqueta. De forma similar, el conjunto de pods que un replicationcontroller debería gestionar se define con un selector de etiqueta.
Los selectores de etiqueta para ambos objetos se definen en los archivos json o yaml usando mapas, y únicamente se permite los selectores basados en igualad:
"selector": {
"component" : "redis",
}
ó
selector:component:redis
este selector (respectivamente en formato json o yaml) es equivalente a component=redis o component in (redis).
Recursos que soportan requisitos basados en conjunto
Algunos recursos más recientes, como el Job, el Deployment, el Replica Set, y el Daemon Set, sí permiten requisitos basados en conjunto.
matchLabels es un mapa de pares {key,value}. Una única combinación de {key,value} en el mapa matchLabels es equivalente a un elemento en matchExpressions donde el campo key es "key", el operator es "In", y la matriz values contiene únicamente "value". matchExpressions es una lista de requisitos de selección de pod. Los operadores permitidos son In, NotIn, Exists, y DoesNotExist. El conjunto de valores no puede ser vacío en el caso particular de In y NotIn. Todos los requisitos, tanto de matchLabels como de matchExpressions se combinan entre sí con el operador AND -- todos ellos deben ser satisfechos.
Seleccionar conjuntos de objetos
Un caso de uso de selección basada en etiquetas es la posibilidad de limitar los nodos en los que un pod puede desplegarse.
Ver la documentación sobre selección de nodo para más información.
3.1.4.5 - Anotaciones
Puedes usar las anotaciones de Kubernetes para adjuntar metadatos arbitrarios a los objetos, de tal forma que clientes como herramientas y librerías puedan obtener fácilmente dichos metadatos.
Adjuntar metadatos a los objetos
Puedes usar las etiquetas o anotaciones para adjuntar metadatos a los objetos de Kubernetes.
Las etiquetas pueden utilizarse para seleccionar objetos y para encontrar colecciones de objetos que satisfacen ciertas condiciones.
Por el contrario, las anotaciones no se utilizan para identificar y seleccionar objetos.
Los metadatos de una anotación pueden ser pequeños o grandes, estructurados o no estructurados,
y pueden incluir caracteres no permitidos en las etiquetas.
Las anotaciones, al igual que las etiquetas, son mapas de clave/valor:
Aquí se presentan algunos ejemplos de información que podría ser indicada como anotaciones:
Campos gestionados por una capa de configuración declarativa.
Adjuntando dichos campos como anotaciones permitiría diferenciarlos de los
valores por defecto establecidos por clientes o servidores, además de los
campos auto-generados y los campos modificados por sistemas de auto-escalado.
Información acerca de la construcción, entrega, o imagen como marcas de fecha, IDs de entrega, rama de Git,
número de PR, funciones hash de imágenes, y direcciones de registro.
Referencias a los repositorios de trazas, monitorización, analíticas, o auditoría.
Información de librería de cliente o herramienta que puede usarse con fines de depuración de código:
por ejemplo, nombre, versión, e información de construcción.
Información de usuario o procedencia de herramienta/sistema, como las URLs de los
objetos provenientes de otros componentes del ecosistema.
Metadatos para una herramienta ligera de lanzamiento de aplicaciones: por ejemplo, configuración o puntos de control.
Número de teléfono o contacto de las personas a cargo, o entradas de directorio que
especifican dónde puede encontrarse dicha información, como la página web de un equipo de trabajo.
Directivas del usuario final a las implementaciones para modificar el comportamiento
o solicitar funcionalidades no estándar.
En vez de usar anotaciones, podrías almacenar este tipo de información en una
base de datos externa o un directorio, pero eso complicaría enormemente la posibilidad
de crear librerías compartidas de cliente, así como herramientas para el
despliegue, gestión, introspección, y similares.
Sintaxis y conjunto de caracteres
Las Anotaciones son entradas clave/valor. Una clave válida para una anotación tiene dos partes: un prefijo opcional y un nombre, separados por una barra (/). La parte del nombre es obligatoria y debe tener 63 caracteres o menos, empezando y terminando con un carácter alfanumérico ([a-z0-9A-Z]) con guiones (-), guiones bajos (_), puntos (.) en medio. El prefijo es opcional. Si se indica,
el prefijo debe ser un subdominio DNS: una serie de etiquetas DNS separadas por puntos (.), no superior a 253 caracteres en total, seguida de una barra (/).
Si se omite el prefijo, la clave de la anotación se entiende que es privada para el usuario. Los componentes automatizados del sistema (e.g. kube-scheduler, kube-controller-manager, kube-apiserver, kubectl, u otros de terceros) que añaden anotaciones a los objetos de usuario deben, pues, especificar un prefijo.
Los prefijos kubernetes.io/ y k8s.io/ se reservan para el uso exclusivo de los componentes principales de Kubernetes.
Los selectores de campo te permiten seleccionar recursos de Kubernetes basados en el valor de uno o más campos del recurso. Aquí se presentan varios ejemplos de consultas de selectores de campo:
metadata.name=my-service
metadata.namespace!=default
status.phase=Pending
Este comando kubectl selecciona todos los Pods para los cuales el valor del campo status.phase es igual a Running:
kubectl get pods --field-selector status.phase=Running
Nota:
Los selectores de campo son esencialmente filtros de recursos. Por defecto, no se aplica ningún selector/filtro, lo que significa que todos los tipos de recursos son seleccionados. Esto hace que las siguientes consultas con kubectl sean equivalentes:
kubectl get pods
kubectl get pods --field-selector ""
Campos soportados
Los selectores de campos soportados varían según el tipo de recursos de Kubernetes. Todos los tipos de recursos permiten los campos metadata.name y metadata.namespace. El uso de un selector de campo no soportado provoca un error. Por ejemplo:
kubectl get ingress --field-selector foo.bar=baz
Error from server (BadRequest): Unable to find "ingresses" that match label selector "", field selector "foo.bar=baz": "foo.bar" is not a known field selector: only "metadata.name", "metadata.namespace"
Operadores soportados
Puedes usar los operadores =, ==, y != en los selectores de campo (= y == significan lo mismo). Este comando de kubectl, por ejemplo, selecciona todos los servicios de Kubernetes que no están en el espacio de nombres default:
kubectl get services --field-selector metadata.namespace!=default
Selectores anidados
De la misma manera que con una etiqueta y otros selectores, los selectores de campo pueden anidarse como una lista de elementos separados por coma. Este comando de kubectl selecciona todos los Pods para los que el campo status.phase no es igual a Running y el campo spec.restartPolicy es igual a Always:
kubectl get pods --field-selector=status.phase!=Running,spec.restartPolicy=Always
Múltiples tipos de recursos
Puedes usar los selectores de campo entre múltiples tipos de recursos. Este comando de kubectl selecciona todos los Statefulsets y Services que no están en el espacio de nombres default:
kubectl get statefulsets,services --all-namespaces --field-selector metadata.namespace!=default
3.1.4.7 - Finalizadores
Los finalizadores son atributos de un namespace que instruyen a Kubernetes a
esperar a que ciertas condiciones sean satisfechas antes que pueda borrar
definitivamente un objeto que ha sido marcado para eliminarse.
Los finalizadores alertan a los controladores
para borrar recursos que poseian esos objetos eliminados.
Cuando instruyes a Kubernetes a borrar un objeto que tiene finalizadores
especificados, la API de Kubernetes marca ese objeto para eliminacion
configurando el campo metadata.deletionTimestamp, y retorna un codigo de
estado 202 (HTTP "Aceptado").
El objeto a borrar permanece en un estado
de terminacion mientras el plano de contol, u otros componentes, ejecutan
las acciones definidas en los finalizadores.
Luego de que esas acciones son completadas, el controlador borra los
finalizadores relevantes del objeto. Cuando el campo metadata.finalizers
esta vacio, Kubernetes considera el proceso de eliminacion completo y borra
el objeto.
Puedes utilizar finalizadores para controlar garbage collection
de recursos. Por ejemplo, puedes definir un finalizador para borrar recursos
relacionados o infraestructura antes que el controlador elimine el objeto.
Puedes usar finalizadores para controlar garbage collection
de los recursos alertando a los controladores para que ejecuten tareas de limpieza especificas antes de eliminar el recurso.
Los finalizadores usualmente no especifican codigo a ejecutar, sino que son generalmente listas de parametros referidos a
un recurso especifico, similares a las anotaciones. Kubernetes especifica algunos finalizadores automaticamente,
pero podrías especificar tus propios.
Cómo funcionan los finalizadores
Cuando creas un recurso utilizando un archivo de manifiesto, puedes especificar
finalizadores mediante el campo metadata.finalizers. Cuando intentas eliminar el
recurso, el servidor API que maneja el pedido de eliminación ve los valores en el
campo finalizadores y hace lo siguiente:
Modifica el objecto para agregar un campo metadata.deletionTimestamp con
el momento en que comenzaste la eliminación.
Previene que el objeto sea eliminado hasta que su campo metadata.finalizers
este vacío.
Retorna un codigo de estado 202 (HTTP "Aceptado")
El controlador que meneja ese finalizador recibe la actualización del objecto
configurando el campo metadata.deletionTimestamp, indicando que la eliminación
del objeto ha sido solicitada.
El controlador luego intenta satisfacer los requerimientos de los finalizadores
especificados para ese recurso. Cada vez que una condición del finalizador es
satisfecha, el controlador remueve ese parametro del campo finalizadores. Cuando
el campo finalizadores esta vacío, un objeto con un campo deletionTimestamp
configurado es automaticamente borrado. Puedes tambien utilizar finalizadores para
prevenir el borrado de recursos no manejados.
Un ejemplo usual de un finalizador es kubernetes.io/pv-protection, el cual
previene el borrado accidental de objetos PersistentVolume. Cuando un objeto
PersistentVolume está en uso por un Pod, Kubernetes agrega el finalizador
pv-protection. Si intentas elimiar el PersistentVolume, este pasa a un estado
Terminating, pero el controlador no puede eliminarlo ya que existe el finalizador.
Cuando el Pod deja de utilizar el PersistentVolume, Kubernetes borra el finalizador
pv-protection y el controlador borra el volumen.
Referencias de dueño, etiquetas y finalizadores (#owners-labels-finalizers)
Al igual que las etiquetas, las
referencias de dueño
describen las relaciones entre objetos en Kubernetes, pero son utilizadas para un
propósito diferente. Cuando un
controlador maneja objetos como
Pods, utiliza etiquetas para identificar cambios a grupos de objetos relacionados.
Por ejemplo, cuando un Job crea uno
o más Pods, el controlador del Job agrega etiquetas a esos pods para identificar cambios
a cualquier Pod en el cluster con la misma etiqueta.
El controlador del Job tambien agrega referencias de dueño a esos Pods, referidas
al Job que creo a los Pods. Si borras el Job mientras estos Pods estan corriendo,
Kubernetes utiliza las referencias de dueño (no las etiquetas) para determinar
cuáles Pods en el cluster deberían ser borrados.
Kubernetes también procesa finalizadores cuando identifica referencias de dueño en
un recurso que ha sido marcado para eliminación.
En algunas situaciones, los finalizadores pueden bloquear el borrado de objetos
dependientes, causando que el objeto inicial a borrar permanezca más de lo
esperado sin ser completamente eliminado. En esas situaciones, deberías chequear
finalizadores y referencias de dueños en los objetos y sus dependencias para
intentar solucionarlo.
Nota:
En casos donde los objetos queden bloqueados en un estado de eliminación, evita
borrarlos manualmente para que el proceso continue. Los finalizadores usualmente
son agregados a los recursos por una razón, por lo cual eliminarlos forzosamente
puede causar problemas en tu cluster. Borrados manuales sólo deberían ejecutados
cuando el propósito del finalizador es entendido y satisfecho de alguna otra manera (por
ejemplo, borrando manualmente un objeto dependiente).
Puedes visualizar y gestionar los objetos de Kubernetes con herramientas adicionales a kubectl
y el propio tablero de control. Un conjunto común de etiquetas permite a dichas herramientas
trabajar de forma interoperable, describiendo los objetos de una forma común que todas las
herramientas puedan entender.
Además del soporte a herramientas, las etiquetas recomendadas describen las aplicaciones
de forma que puedan ser consultadas.
Los metadatos se organizan en torno al concepto de una aplicación. Kubernetes no es
una plataforma como servicio (PaaS) y ni tiene o restringe la definición formal de una aplicación.
Al contrario, las aplicaciones son informales y se describen mediante el uso de los metadatos.
La definición de lo que contiene una aplicación es imprecisa.
Nota:
Estas son las etiquetas recomendadas. Estas facilitan la gestión de aplicaciones,
pero no son obligatorias para las herramientas en general.
Las etiquetas compartidas y las anotaciones comparten un prefijo común: app.kubernetes.io.
Las etiquetas sin un prefijo son privadas para los usuarios. El prefijo compartido
garantiza que las etiquetas compartidas no entran en conflicto con las etiquetas
personalizadas de usuario.
Etiquetas
Para beneficiarse al máximo del uso de estas etiquetas, estas deberían aplicarse a cada objeto de recurso.
Clave
Descripción
Ejemplo
Tipo
app.kubernetes.io/name
El nombre de la aplicación
mysql
string
app.kubernetes.io/instance
Un nombre único que identifique la instancia de la aplicación
wordpress-abcxzy
string
app.kubernetes.io/version
La versión actual de la aplicación (ej., la versión semántica, cadena hash de revisión, etc.)
5.7.21
string
app.kubernetes.io/component
El componente dentro de la arquitectura
database
string
app.kubernetes.io/part-of
El nombre de una aplicación de nivel superior de la cual es parte esta aplicación
wordpress
string
app.kubernetes.io/managed-by
La herramienta usada para gestionar la operativa de una aplicación
helm
string
Para ilustrar estas etiquetas en acción, consideremos el siguiente objeto StatefulSet:
Una misma aplicación puede desplegarse una o más veces en un clúster de Kubernetes e,
incluso, el mismo espacio de nombres. Por ejemplo, wordpress puede instalarse más de una
vez de forma que sitios web diferentes sean instalaciones diferentes de wordpress.
El nombre de una aplicación y el nombre de la instancia se almacenan de forma separada.
Por ejemplo, WordPress tiene un app.kubernetes.io/name igual a wordpress mientras que
tiene un nombre de instancia, representado como app.kubernetes.io/instance con un valor de
wordpress-abcxzy. Esto permite identificar tanto a la aplicación como a sus instancias.
Cada instancia de una aplicación tiene su propio nombre único.
Ejemplos
Para ilustrar las diferentes formas en que se puede utilizar las etiquetas, los siguientes ejemplos presentan distintas complejidades.
Un Servicio Simple sin Estado
Considera el caso de un servicio simple sin estado desplegado mediante el uso de un objeto Deployment y Service. Los dos siguientes extractos de código representan cómo usar las etiquetas de la forma más sencilla.
El objeto Deployment se utiliza para supervisar los pods que ejecutan la propia aplicación.
Considera una aplicación un poco más complicada: una aplicación web (WordPress)
que utiliza una base de datos (MySQL), instalada utilizando Helm. Los siguientes extractos
de código ilustran la parte inicial de los objetos utilizados para desplegar esta aplicación.
El comienzo del objeto Deployment siguiente se utiliza para WordPress:
Con los objetos StatefulSet y Service de MySQL te darás cuenta que se incluye la información acerca de MySQL y Wordpress, la aplicación global.
3.1.5 - Gestión de objetos usando kubectl
3.2 - Arquitectura de Kubernetes
3.2.1 - Nodos
Un nodo es una máquina de trabajo en Kubernetes, previamente conocida como minion. Un nodo puede ser una máquina virtual o física, dependiendo del tipo de clúster. Cada nodo está gestionado por el componente máster y contiene los servicios necesarios para ejecutar pods. Los servicios en un nodo incluyen el container runtime, kubelet y el kube-proxy. Accede a la sección The Kubernetes Node en el documento de diseño de arquitectura para más detalle.
Estado del Nodo
El estado de un nodo comprende la siguiente información:
El uso de estos campos varía dependiendo del proveedor de servicios en la nube y/o de la configuración en máquinas locales.
HostName: El nombre de la máquina huésped como aparece en el kernel del nodo. Puede ser reconfigurado a través del kubelet usando el parámetro --hostname-override.
ExternalIP: La dirección IP del nodo que es accesible externamente (que está disponible desde fuera del clúster).
InternalIP: La dirección IP del nodo que es accesible únicamente desde dentro del clúster.
Estados
El campo conditions describe el estado de todos los nodos en modo Running.
Estado
Descripción
OutOfDisk
True si no hay espacio suficiente en el nodo para añadir nuevos pods; sino False
Ready
True si el nodo está en buen estado y preparado para aceptar nuevos pods, Falso si no puede aceptar nuevos pods, y Unknown si el controlador aún no tiene constancia del nodo después del último node-monitor-grace-period (por defecto cada 40 segundos)
MemoryPressure
True si hay presión en la memoria del nodo -- es decir, si el consumo de memoria en el nodo es elevado; sino False
PIDPressure
True si el número de PIDs consumidos en el nodo es alto -- es decir, si hay demasiados procesos en el nodo; sino False
DiskPressure
True si hay presión en el tamaño del disco -- esto es, si la capacidad del disco es baja; sino False
NetworkUnavailable
True si la configuración de red del nodo no es correcta; sino False
El estado del nodo se representa como un objeto JSON. Por ejemplo, la siguiente respuesta describe un nodo en buen estado:
Si el status de la condición Ready se mantiene como Unknown o False por más tiempo de lo que dura un pod-eviction-timeout, se pasa un argumento al kube-controller-manager y todos los pods en el nodo se marcan para borrado por el controlador de nodos. El tiempo de desalojo por defecto es de cinco minutos. En algunos casos, cuando el nodo se encuentra inaccesible, el API Server no puede comunicar con el kubelet del nodo. La decisión de borrar pods no se le puede hacer llegar al kubelet hasta que la comunicación con el API Server se ha restablecido. Mientras tanto, los pods marcados para borrado pueden continuar ejecutándose en el nodo aislado.
En versiones de Kubernetes anteriores a 1.5, el controlador de nodos forzaba el borrado de dichos pods inaccesibles desde el API Server. Sin embargo, desde la versión 1.5, el nodo controlador no fuerza el borrado de pods hasta que se confirma que dichos pods han dejado de ejecutarse en el clúster. Pods que podrían estar ejecutándose en un nodo inalcanzable se muestran como Terminating o Unknown. En aquellos casos en los que Kubernetes no puede deducir si un nodo ha abandonado el clúster de forma permanente, puede que sea el administrador el que tenga que borrar el nodo de forma manual. Borrar un objeto Node en un clúster de Kubernetes provoca que los objetos Pod que se ejecutaban en el nodo sean eliminados en el API Server y libera sus nombres.
En la versión 1.12, la funcionalidad TaintNodesByCondition se eleva a beta, de forma que el controlador del ciclo de vida de nodos crea taints de forma automática, que representan estados de nodos.
De forma similar, el planificador de tareas ignora estados cuando evalúa un nodo; en su lugar mira los taints del nodo y las tolerancias de los pods.
En la actualidad, los usuarios pueden elegir entre la versión de planificación antigua y el nuevo, más flexible, modelo de planificación.
Un pod que no tiene definida ninguna tolerancia es planificado utilizando el modelo antiguo, pero si un nodo tiene definidas ciertas tolerancias, sólo puede ser asignado a un nodo que lo permita.
Precaución:
Habilitar esta funcionalidad crea una pequeña demora entre que una condición es evaluada y un taint creado. Esta demora suele ser inferior a un segundo, pero puede incrementar el número de pods que se planifican con éxito pero que luego son rechazados por el kubelet.
Capacidad
Describe los recursos disponibles en el nodo: CPU, memoria, y el número máximo de pods que pueden ser planificados dentro del nodo.
Información
Información general sobre el nodo: versión del kernel, versión de Kubernetes (versiones del kubelet y del kube-proxy), versión de Docker (si se utiliza), nombre del sistema operativo. Toda esta información es recogida por el kubelet en el nodo.
Gestión
A diferencia de pods y services, los nodos no son creados por Kubernetes de forma inherente; o son creados de manera externa por los proveedores de servicios en la nube como Google Compute Engine, o existen en la colección de máquinas virtuales o físicas. De manera que cuando Kubernetes crea un nodo, crea un objeto que representa el nodo. Después de ser creado, Kubernetes comprueba si el nodo es válido o no. Por ejemplo, si intentas crear un nodo con el siguiente detalle:
Kubernetes crea un objeto Node internamente (la representación), y valida el nodo comprobando su salud en el campo metadata.name. Si el nodo es válido -- es decir, si todos los servicios necesarios están ejecutándose -- el nodo es elegible para correr un pod. Sino, es ignorado para cualquier actividad del clúster hasta que se convierte en un nodo válido.
Nota:
Kubernetes conserva el objeto de un nodo inválido y continúa probando por si el nodo, en algún momento, entrase en servicio.
Para romper este ciclo deberás borrar el objeto Node explícitamente.
Actualmente, hay tres componentes que interactúan con la interfaz de nodos de Kubernetes: controlador de nodos, kubelet y kubectl.
Controlador de Nodos
El controlador de nodos es un componente maestro en Kubernetes que gestiona diferentes aspectos de los nodos.
El controlador juega múltiples papeles en la vida de un nodo. El primero es asignar un bloque CIDR (Class Inter-Domain Routing) al nodo cuando este se registra (si la asignación CIDR está activada) que contendrá las IPs disponibles para asignar a los objetos que se ejecutarán en ese nodo.
El segundo es mantener actualizada la lista interna del controlador con la lista de máquinas disponibles a través del proveedor de servicios en la nube. Cuando Kubernetes se ejecuta en la nube, si un nodo deja de responder, el controlador del nodo preguntará al proveedor si la máquina virtual de dicho nodo continúa estando disponible. Si no lo está, el controlador borrará dicho nodo de su lista interna.
El tercero es el de monitorizar la salud de los nodos. El controlador de nodos es el responsable de actualizar la condición NodeReady del campo NodeStatus a ConditionUnknown cuando un nodo deja de estar accesible (por ejemplo, si deja de recibir señales de vida del nodo indicando que está disponible, conocidas como latidos o hearbeats en inglés) y, también es responsable de posteriormente desalojar todos los pods del nodo si este continúa estando inalcanzable. Por defecto, cuando un nodo deja de responder, el controlador sigue reintentando contactar con el nodo durante 40 segundos antes de marcar el nodo con ConditionUnknown y, si el nodo no se recupera de ese estado pasados 5 minutos, empezará a drenar los pods del nodo para desplegarlos en otro nodo que esté disponible. El controlador comprueba el estado de cada nodo cada --node-monitor-period segundos.
En versiones de Kubernetes previas a 1.13, NodeStatus es el heartbeat del nodo. Empezando con 1.13 la funcionalidad de node lease se introduce como alfa (NodeLease,
KEP-0009). Cuando la funcionalidad está habilitada, cada nodo tiene un objeto Lease asociado en el namespace kube-node-lease que se renueva periódicamente y ambos, el NodeStatus y el Lease son considerados como hearbeats del nodo. Node leases se renuevan con frecuencia, mientras que NodeStatus se transmite desde el nodo al máster únicamente si hay cambios o si ha pasado cierto tiempo (por defecto, 1 minuto, que es más que la cuenta atrás por defecto de 40 segundos que marca un nodo como inalcanzable). Al ser los node lease más ligeros que NodeStatus, los hearbeats resultan más económicos desde las perspectivas de escalabilidad y de rendimiento.
En Kubernetes 1.4, se actualizó la lógica del controlador de nodos para gestionar mejor los casos en los que un gran número de nodos tiene problemas alcanzando el nodo máster (Por ejemplo, cuando el nodo máster es el que tiene un problema de red). Desde 1.4, el controlador de nodos observa el estado de todos los nodos en el clúster cuando toma decisiones sobre desalojo de pods.
En la mayoría de los casos, el controlador de nodos limita el ritmo de desalojo --node-eviction-rate (0.1 por defecto) por segundo, lo que significa que no desalojará pods de más de un nodo cada diez segundos.
El comportamiento de desalojo de nodos cambia cuando un nodo en una zona de disponibilidad tiene problemas. El controlador de nodos comprobará qué porcentaje de nodos en la zona no se encuentran en buen estado (es decir, que su condición NodeReady tiene un valor ConditionUnknown o ConditionFalse) al mismo tiempo. Si la fracción de nodos con problemas es de al menos --unhealthy-zone-threshold (0.55 por defecto) entonces se reduce el ratio de desalojos: si el clúster es pequeño (por ejemplo, tiene menos o los mismos nodos que --large-cluster-size-threshold - 50 por defecto) entonces los desalojos se paran. Sino, el ratio se reduce a --secondary-node-eviction-rate (0.01 por defecto) por segundo. La razón por la que estas políticas se implementan por zonas de disponibilidad es debido a que una zona puede quedarse aislada del nodo máster mientras que las demás continúan conectadas. Si un clúster no comprende más de una zona, todo el clúster se considera una única zona.
La razón principal por la que se distribuyen nodos entre varias zonas de disponibilidad es para que el volumen de trabajo se transfiera a aquellas zonas que se encuentren en buen estado cuando una de las zonas se caiga.
Por consiguiente, si todos los nodos de una zona se encuentran en mal estado, el nodo controlador desaloja al ritmo normal --node-eviction-rate. En el caso extremo de que todas las zonas se encuentran en mal estado (es decir, no responda ningún nodo del clúster), el controlador de nodos asume que hay algún tipo de problema con la conectividad del nodo máster y paraliza todos los desalojos hasta que se restablezca la conectividad.
Desde la versión 1.6 de Kubernetes el controlador de nodos también es el responsable de desalojar pods que están ejecutándose en nodos con NoExecute taints, cuando los pods no permiten dichos taints. De forma adicional, como una funcionalidad alfa que permanece deshabilitada por defecto, el NodeController es responsable de añadir taints que se corresponden con problemas en los nodos del tipo nodo inalcanzable o nodo no preparado. En esta sección de la documentación hay más detalles acerca de los taints NoExecute y de la funcionalidad alfa.
Desde la versión 1.8, el controlador de nodos puede ser responsable de la creación de taints que representan condiciones de nodos. Esta es una funcionalidad alfa en 1.8.
Auto-Registro de Nodos
Cuando el atributo del kubelet --register-node está habilitado (el valor por defecto), el kubelet intentará auto-registrarse con el API Server. Este es el patrón de diseño preferido, y utilizado por la mayoría de distribuciones.
Para auto-registro, el kubelet se inicia con las siguientes opciones:
--kubeconfig - La ruta a las credenciales para autentificarse con el API Server.
--cloud-provider - Cómo comunicarse con un proveedor de servicios para leer meta-datos sobre si mismo.
--register-node - Registro automático con el API Server.
--register-with-taints - Registro del nodo con la lista de taints proporcionada (separada por comas <key>=<value>:<effect>). Esta opción se ignora si el atributo--register-node no está habilitado.
--node-ip - La dirección IP del nodo.
--node-labels - Etiquetas para añadir al nodo durante el registro en el clúster (ver las restricciones que impone el NodeRestriction admission plugin en 1.13+).
--node-status-update-frequency - Especifica la frecuencia con la que el nodo envía información de estado al máster.
Los administradores del clúster pueden crear y modificar objetos Node.
Si un administrador desea crear objetos Node de forma manual, debe levantar kubelet con el atributo --register-node=false.
Los administradores del clúster pueden modificar recursos Node (independientemente del valor de --register-node). Dichas modificaciones incluyen crear etiquetas en el nodo y/o marcarlo como no-planificable (de forma que pods no pueden ser planificados para instalación en el nodo).
Etiquetas y selectores de nodos pueden utilizarse de forma conjunta para controlar las tareas de planificación, por ejemplo, para determinar un subconjunto de nodos elegibles para ejecutar un pod.
Marcar un nodo como no-planificable impide que nuevos pods sean planificados en dicho nodo, pero no afecta a ninguno de los pods que existían previamente en el nodo. Esto resulta de utilidad como paso preparatorio antes de reiniciar un nodo, etc. Por ejemplo, para marcar un nodo como no-planificable, se ejecuta el siguiente comando:
kubectl cordon $NODENAME
Nota:
Los pods creados por un controlador DaemonSet ignoran el planificador de Kubernetes y no respetan el atributo no-planificable de un nodo. Se asume que los daemons pertenecen a la máquina huésped y que se ejecutan incluso cuando esta está siendo drenada de aplicaciones en preparación de un reinicio.
Capacidad del Nodo
La capacidad del nodo (número de CPUs y cantidad de memoria) es parte del objeto Node.
Normalmente, nodos se registran a sí mismos y declaran sus capacidades cuando el objeto Node es creado. Si se está haciendo administración manual, las capacidades deben configurarse en el momento de añadir el nodo.
El planificador de Kubernetes asegura la existencia de recursos suficientes para todos los pods que se ejecutan en un nodo. Comprueba que la suma recursos solicitados por los pods no exceda la capacidad del nodo. Incluye todos los pods iniciados por el kubelet, pero no tiene control sobre contenedores iniciados directamente por el runtime de contenedores ni sobre otros procesos que corren fuera de contenedores.
Un nodo es un recurso principal dentro de la REST API de Kubernetes. Más detalles sobre el objeto en la API se puede encontrar en: Object Node API.
3.2.2 - Comunicación entre Nodos y el Plano de Control
Este documento cataloga las diferentes vías de comunicación entre el kube-apiserver y el clúster de Kubernetes.
La intención es permitir a los usuarios personalizar sus instalaciones para proteger sus configuraciones de red de forma que el clúster pueda ejecutarse en una red insegura (o en un proveedor de servicios en la nube con direcciones IP públicas)
Nodo al Plano de Control
La API de Kubernetes usa el patrón de "hub-and-spoke". Todo uso de la API desde los nodos (o los pods que ejecutan) termina en el servidor API. Ninguno de los otros componentes del plano de control está diseñado para exponer servicios remotos. El servidor API está configurado para escuchar conexiones remotas en un puerto seguro HTTPS (normalmente 443) con una o más formas de
autenticación de cliente habilitada.
Una o más formas de autorización deben ser
habilitadas, especialmente si las peticiones anónimas o los tokens de cuenta de servicio están permitidos.
Los nodos deben ser aprovisionados con el certificado raíz público del clúster, de modo que puedan
conectarse de forma segura al servidor API en conjunto con credenciales de cliente válidas. Un buen enfoque es que las credenciales de cliente proporcionadas al kubelet estén en forma de certificado de cliente. Véase el TLS bootstrapping de kubelet para ver cómo aprovisionar certificados de cliente kubelet de forma automática.
Los Pods que deseen conectar con el apiserver pueden hacerlo de forma segura a través de una cuenta de servicio, de esta forma Kubernetes inserta de forma automática el certificado raíz público y un bearer token válido en el pod cuando es instanciado. El servicio kubernetes (en todos los namespaces) se configura con una dirección IP virtual que es redireccionada (via kube-proxy) al punto de acceso HTTPS en el apiserver.
Los componentes del plano de control también se comunican con el apiserver del clúster a través de un puerto seguro.
Como resultado, el modo de operación para las conexiones desde los nodos y pods que se ejecutan en los nodos al plano de control es seguro por defecto y puede ejecutarse en redes públicas y/o inseguras.
Plano de control al nodo
Hay dos vías de comunicación primaria desde el plano de control (apiserver) y los nodos. La primera es desde el apiserver al proceso kubelet que se ejecuta en cada nodo del clúster. La segunda es desde el apiserver a cualquier nodo, pod o servicio a través de la funcionalidad proxy del apiserver.
Apiserver al kubelet
Las conexiones del apiserver al kubelet se utilizan para:
Recoger entradas de registro de pods.
Conectar (a través de kubectl) con pods en ejecución.
Facilitar la funcionalidad port-forwarding del kubelet.
Estas conexiones terminan en el endpoint HTTPS del kubelet. Por defecto, el apiserver no verifica el certificado del kubelet, por lo que la conexión es vulnerable a ataques del tipo "ataque de intermediario" ("man-in-the-middle"), e insegura para conectar a través de redes públicas y/o no fiables.
Para verificar esta conexión, se utiliza el atributo --kubelet-certificate-authority que provee el apiserver con un certificado raíz con el que verificar el certificado del kubelet.
Si esto no es posible, se utiliza un túnel SSH entre el apiserver y el kubelet para conectar a través de redes públicas o de no confianza.
Las conexiones desde el apiserver a un nodo, pod o servicio se realizan por defecto con conexiones HTTP simples y, por consiguiente, no son autenticadas o encriptadas. Pueden ser ejecutadas en una conexión segura HTTPS con el prefijo https: al nodo, pod o nombre de servicio en la URL de la API, pero no validarán el certificado proporcionado por el punto final HTTPS ni proporcionarán las credenciales del cliente. Por tanto, aunque la conexión estará cifrada, no proporcionará ninguna garantía de integridad. Estas conexiones no son actualmente seguras para ejecutarse en redes públicas o no fiables.
Túneles SSH
Kubernetes ofrece soporte para túneles SSH que protegen la comunicación entre el plano de control y los nodos. En este modo de configuración, el apiserver inicia un túnel SSH a cada nodo en el clúster (conectando al servidor SSH en el puerto 22) y transfiere todo el tráfico destinado a un kubelet, nodo, pod o servicio a través del túnel. El túnel garantiza que dicho tráfico no es expuesto fuera de la red en la que se ejecutan los nodos.
Nota:
Los túneles SSH están actualmente obsoletos, por lo que no deberías optar por utilizarlos a menos que sepas lo que
estás haciendo. El Konnectivity service es un sustituto de este canal de comunicación.
Servicio Konnectivity
FEATURE STATE:Kubernetes v1.18 [beta]
En sustitución de los túneles SSH, el servicio Konnectivity proporciona un proxy de nivel TCP para la comunicación entre el plano de control y el clúster. El servicio Konnectivity consta de dos partes: el servidor Konnectivity en la red del plano de control y los agentes Konnectivity en la red de nodos.
Los agentes Konnectivity inician conexiones con el servidor Konnectivity y mantienen las conexiones de red.
Tras habilitar el servicio Konnectivity, todo el tráfico del plano de control a los nodos pasa por estas conexiones.
3.2.3 - Conceptos subyacentes del Cloud Controller Manager
El concepto del Cloud Controller Manager (CCM) (no confundir con el ejecutable) fue creado originalmente para permitir que Kubernetes y el código específico de proveedores de servicios en la nube evolucionen de forma independiente. El Cloud Controller Manager se ejecuta a la par con otros componentes maestros como el Kubernetes Controller Manager, el API Server y el planificador. También puede ejecutarse como un extra, en cuyo caso se ejecuta por encima de Kubernetes.
El diseño del Cloud Controller Manager está basado en un sistema de plugins, lo que permite a nuevos proveedores de servicios integrarse de forma fácil con Kubernetes. Se está trabajando en implementar nuevos proveedores de servicios y para migrar los existentes del antiguo modelo al nuevo CCM.
Este documento describe los conceptos tras el Cloud Controller Manager y detalla sus funciones asociadas.
En la siguiente imagen, se puede visualizar la arquitectura de un cluster de Kubernetes que no utiliza el Cloud Controller Manager:
Diseño
En el diagrama anterior, Kubernetes y el proveedor de servicios en la nube están integrados a través de diferentes componentes:
Kubelet
Kubernetes controller manager
Kubernetes API server
El CCM consolida toda la lógica dependiente de la nube de estos tres componentes para crear un punto de integración único. La nueva arquitectura con CCM se muestra a continuación:
Componentes del CCM
El CCM secciona parte de la funcionalidad del Kubernetes Controller Manager (KCM) y la ejecuta como procesos independientes. Específicamente, aquellos controladores en el KCM que son dependientes de la nube:
Controlador de Nodos
Controlador de Volúmenes
Controlador de Rutas
Controlador de Servicios
En la versión 1.9, el CCM se encarga de la ejecución de los siguientes controladores:
Controlador de Nodos
Controlador de Rutas
Controlador de Servicios
Nota:
El controlador de volúmenes se dejó fuera del CCM de forma explícita. Debido a la complejidad que ello requería y a los esfuerzos existentes para abstraer lógica de volúmenes específica a proveedores de servicios, se decidió que el controlador de volúmenes no fuese movido al CCM.
El plan original para habilitar volúmenes en CCM era utilizar volúmenes Flex con soporte para volúmenes intercambiables. Sin embargo, otro programa conocido como CSI (Container Storage Interface) se está planeando para reemplazar Flex.
Considerando todo lo anterior, se ha decidido esperar hasta que CSI esté listo.
Funciones del CCM
El CCM hereda sus funciones de componentes que son dependientes de un proveedor de servicios en la nube. Esta sección se ha estructurado basado en dichos componentes:
1. Kubernetes Controller Manager
La mayoría de las funciones del CCM derivan del KCM. Como se ha mencionado en la sección anterior, el CCM es responsable de los siguientes circuitos de control:
Controlador de Nodos
Controlador de Rutas
Controlador de Servicios
Controlador de Nodos
El controlador de nodos es responsable de inicializar un nodo obteniendo información del proveedor de servicios sobre los nodos ejecutándose en el clúster. El controlador de nodos lleva a cabo las siguientes funciones:
Inicializa un nodo con etiquetas de región y zona específicas del proveedor.
Inicializa un nodo con detalles de la instancia específicos del proveedor, como por ejemplo, el tipo o el tamaño.
Obtiene las direcciones de red del nodo y su hostname.
En caso de que el nodo deje de responder, comprueba la nube para ver si el nodo ha sido borrado. Si lo ha sido, borra el objeto nodo en Kubernetes.
Controlador de Rutas
El controlador de Rutas es responsable de configurar rutas en la nube para que contenedores en diferentes nodos dentro de un clúster kubernetes se puedan comunicar entre sí.
Controlador de Servicios
El controlador de servicios es responsable de monitorizar eventos de creación, actualización y borrado de servicios. Basándose en el estado actual de los servicios en el clúster Kubernetes, configura balanceadores de carga del proveedor (como Amazon ELB, Google LB, or Oracle Cloud Infrastructure Lb) de forma que estos reflejen los servicios definidos en Kubernetes. Adicionalmente, se asegura de que los sistemas de apoyo de servicios para balanceadores de carga en la nube se encuentren actualizados.
2. Kubelet
El controlador de nodos incluye la funcionalidad del kubelet que es dependiente de la nube. Previa a la introducción de CCM, el kubelet era responsable de inicializar un nodo con detalles específicos al proveedor como direcciones IP, etiquetas de región/zona y tipo de instancia. La introduccion de CCM transfiere esta inicialización del kubelet al CCM.
En este nuevo modelo, el kubelet inicializa un nodo sin información especifica del proveedor de servicios. Sin embargo, añade un taint al nodo recién creado de forma que este no esté disponible para el planificador hasta que el CCM completa el nodo con la información específica del proveedor. Sólo entonces elimina el taint y el nodo se vuelve accesible.
Mecanismo de Plugins (extensiones)
El Cloud Controller Manager utiliza interfaces Go(lang), lo que permite que implementaciones de cualquier proveedor de servicios sean conectadas. Específicamente, utiliza el CloudProvider Interface definido aquí.
La implementación de los cuatro controladores referenciados en este documento, algunas estructuras de inicialización junto con el interface CloudProvider, permanecerán como parte del núcleo de Kubernetes.
Para más información sobre el desarrollo de extensiones/plugins, consultar Desarrollo del CCM.
Autorización
Esta sección divide el nivel de acceso requerido por varios objetos API para que el CCM pueda llevar acabo sus operaciones.
Controlador de Nodos
El controlador de nodos sólo opera con objetos Nodo. Necesita de acceso total para obtener, listar, crear, actualizar, arreglar, monitorizar y borrar objetos Nodo.
v1/Node:
Get
List
Create
Update
Patch
Watch
Delete
Controlador de Rutas
El controlador de rutas permanece a la escucha de eventos de creación de nodos y configura sus rutas. Necesita acceso a los objetos Nodo.
v1/Node:
Get
Controlador de Servicios
El controlador de servicios permanece a la escucha de eventos de creación, actualización y borrado de objetos Servicio, y se encarga de configurar los endpoints para dichos servicios.
Para acceder a los objetos Servicio, necesita permisos para listar y monitorizar. Para el mantenimiento de servicios necesita permisos para parchear y actualizar.
Para configurar endpoints para los servicios necesita permisos para crear, listar, obtener, monitorizar y actualizar.
v1/Service:
List
Get
Watch
Patch
Update
Otros
La implementación del núcleo de CCM requiere acceso para crear eventos, y para asegurar la seguridad de operaciones; necesita acceso para crear ServiceAccounts.
v1/Event:
Create
Patch
Update
v1/ServiceAccount:
Create
El RBAC ClusterRole para CCM se muestra a continuación:
Instrucciones para configurar y ejecutar el CCM pueden encontrarse aquí.
3.2.4 - Leases
Los sistemas distribuidos suelen necesitar leases, que proporcionan un mecanismo para bloquear recursos compartidos
y coordinar la actividad entre los miembros de un conjunto.
En Kubernetes, el concepto de lease (arrendamiento) está representado por objetos Lease
en el grupo API de coordination.k8s.io,
que se utilizan para capacidades críticas del sistema, como los heartbeats del nodo y la elección del líder a nivel de componente.
Heartbeats del nodo
Kubernetes utiliza la API Lease para comunicar los heartbeats de los nodos kubelet al servidor API de Kubernetes.
Para cada Nodo , existe un objeto Lease con un nombre que coincide en el espacio de nombres kube-node-lease.
Analizando a detalle, cada hearbeat es una solicitud update a este objeto Lease, actualizando
el campo spec.renewTime del objeto Lease. El plano de control de Kubernetes utiliza la marca de tiempo de este campo
para determinar la disponibilidad de este «Nodo».
Kubernetes también utiliza Leases para asegurar que sólo una instancia de un componente se está ejecutando en un momento dado.
Esto lo utilizan componentes del plano de control como kube-controller-manager y kube-scheduler en configuraciones de
HA, donde sólo una instancia del componente debe estar ejecutándose activamente mientras las otras
instancias están en espera.
Identidad del servidor API
FEATURE STATE:Kubernetes v1.26 [beta]
A partir de Kubernetes v1.26, cada kube-apiserver utiliza la API Lease para publicar su identidad al resto del sistema.
Aunque no es particularmente útil por sí mismo, esto proporciona un mecanismo para que los clientes
puedan descubrir cuántas instancias de kube-apiserver están operando el plano de control de Kubernetes.
La existencia de los objetos leases de kube-apiserver permite futuras capacidades que pueden requerir la coordinación entre
cada kube-apiserver.
Puedes inspeccionar los leases de cada kube-apiserver buscando objetos leases en el namespace kube-system
con el nombre kube-apiserver-<sha256-hash>. También puedes utilizar el selector de etiquetas apiserver.kubernetes.io/identity=kube-apiserver:
kubectl -n kube-system get lease -l apiserver.kubernetes.io/identity=kube-apiserver
NAME HOLDER AGE
apiserver-07a5ea9b9b072c4a5f3d1c3702 apiserver-07a5ea9b9b072c4a5f3d1c3702_0c8914f7-0f35-440e-8676-7844977d3a05 5m33s
apiserver-7be9e061c59d368b3ddaf1376e apiserver-7be9e061c59d368b3ddaf1376e_84f2a85d-37c1-4b14-b6b9-603e62e4896f 4m23s
apiserver-1dfef752bcb36637d2763d1868 apiserver-1dfef752bcb36637d2763d1868_c5ffa286-8a9a-45d4-91e7-61118ed58d2e 4m43s
El hash SHA256 utilizado en el nombre del lease se basa en el nombre de host del sistema operativo visto por ese servidor API. Cada kube-apiserver debe ser
configurado para utilizar un nombre de host que es único dentro del clúster. Las nuevas instancias de kube-apiserver que utilizan el mismo nombre de host
asumirán los leases existentes utilizando una nueva identidad de titular, en lugar de instanciar nuevos objetos leases. Puedes comprobar el
nombre de host utilizado por kube-apiserver comprobando el valor de la etiqueta kubernetes.io/hostname:
kubectl -n kube-system get lease apiserver-07a5ea9b9b072c4a5f3d1c3702 -o yaml
Los leases caducados de los kube-apiservers que ya no existen son recogidos por los nuevos kube-apiservers después de 1 hora.
Puedes desactivar el lease de identidades del servidor API desactivando la opción APIServerIdentity de los interruptores de funcionalidades.
Cargas de trabajo
Tu propia carga de trabajo puede definir su propio uso de los leases. Por ejemplo, puede ejecutar un
controlador en la que un miembro principal o líder
realiza operaciones que sus compañeros no realizan. Tú defines un Lease para que las réplicas del controlador puedan seleccionar
o elegir un líder, utilizando la API de Kubernetes para la coordinación.
Si utilizas un lease, es una buena práctica definir un nombre para el lease que esté obviamente vinculado a
el producto o componente. Por ejemplo, si tienes un componente denominado Ejemplo Foo, utilice un lease denominado
ejemplo-foo.
Si un operador de clúster u otro usuario final puede desplegar varias instancias de un componente, selecciona un nombre
prefijo y elije un mecanismo (como el hash del nombre del despliegue) para evitar colisiones de nombres
para los leases.
Puedes utilizar otro enfoque siempre que consigas el mismo resultado: los distintos productos de software no entren en conflicto entre sí.
3.2.5 - Container Runtime Interface (CRI)
CRI es una interfaz de plugin que permite que kubelet use una amplia variedad de
container runtimes, sin necesidad de volver a compilar los componentes del clúster.
Necesitas un
container runtime ejecutándose en
cada Nodo en tu clúster, de manera que
kubelet pueda iniciar los
Pods y sus contenedores.
Container Runtime Interface (CRI) es el protocolo principal para la comunicación entre el kubelet y el Container Runtime.
Kubelet actúa como un cliente cuando se conecta al runtime del contenedor a través de gRPC.
El runtime y los endpoints del servicio de imágenes deben estar disponibles en el runtime del contenedor,
que se puede configurar por separado dentro de kubelet usando
--image-service-endpointbanderas de línea de comando.
Para Kubernetes v1.31, kubelet prefiere usar CRI v1.
Si el runtime del contenedor no es compatible con v1 del CRI, kubelet intenta
negociar cualquier versión compatible anterior.
Kubelet v1.31 también puede negociar CRI v1alpha2, pero
esta versión se considera obsoleta.
Si kubelet no puede negociar una versión CRI soportada, kubelet se da por vencido
y no se registra como nodo.
Actualizando
Al actualizar Kubernetes, kubelet intenta seleccionar automáticamente la
última versión de CRI al reiniciar el componente. Si eso falla, entonces la alternativa
se llevará a cabo como se mencionó anteriormente. Si se requirió una rellamada de gRPC porque el
runtime del contenedor se ha actualizado, entonces el runtime del contenedor también debe
soportar la versión seleccionada inicialmente o se espera que la rellamada falle. Esto
requiere un reinicio de kubelet.
Esta página describe el recurso RuntimeClass y el mecanismo de selección del
motor de ejecución.
RuntimeClass es una característica que permite seleccionar la configuración del
motor de ejecución para los contenedores. La configuración del motor de ejecución para
los contenedores se utiliza para ejecutar los contenedores de un Pod.
Motivación
Se puede seleccionar un RuntimeClass diferente entre diferentes Pods para
proporcionar equilibrio entre rendimiento y seguridad. Por ejemplo, si parte de
la carga de trabajo requiere un alto nivel de garantía de seguridad, se podrían
planificar esos Pods para ejecutarse en un motor de ejecución que use
virtualización de hardware. Así se beneficiaría con un mayor aislamiento del motor
de ejecución alternativo, con el coste de alguna sobrecarga adicional.
También se puede utilizar el RuntimeClass para ejecutar distintos Pods con el
mismo motor de ejecución pero con distintos parámetros.
Configuración
Configurar la implementación del CRI en los nodos (depende del motor de
ejecución)
Crear los recursos RuntimeClass correspondientes.
1. Configurar la implementación del CRI en los nodos
La configuración disponible utilizando RuntimeClass dependen de la
implementación de la Interfaz del Motor de ejecución de Containers (CRI). Véase
la sección Configuración del CRI para más
información sobre cómo configurar la implementación del CRI.
Nota:
RuntimeClass por defecto asume una configuración de nodos homogénea para todo el
clúster (lo que significa que todos los nodos están configurados de la misma
forma para el motor de ejecución de los contenedores). Para soportar configuraciones
heterogéneas de nodos, véase Planificación más abajo.
Las configuraciones tienen un nombre de handler (manipulador) correspondiente, referenciado
por la RuntimeClass. El handler debe ser una etiqueta DNS 1123 válida
(alfanumérico + caracter -).
2. Crear los recursos RuntimeClass correspondientes.
Cada configuración establecida en el paso 1 tiene un nombre de handler, que
identifica a dicha configuración. Para cada handler, hay que crear un objeto
RuntimeClass correspondiente.
Actualmente el recurso RuntimeClass sólo tiene dos campos significativos: el
nombre del RuntimeClass (metadata.name) y el handler. La
definición del objeto se parece a ésta:
apiVersion:node.k8s.io/v1 # La RuntimeClass se define en el grupo node.k8s.iokind:RuntimeClassmetadata:name:myclass # Nombre por el que se referenciará la RuntimeClass# no contiene espacio de nombreshandler:myconfiguration # El nombre de la configuración CRI correspondiente
Se recomienda que las operaciones de escritura de la RuntimeClass
(creación/modificación/parcheo/elimiación) se restrinjan al administrador del
clúster. Habitualmente es el valor por defecto. Véase Visión general de la
Autorización para más
detalles.
Uso
Una vez se han configurado las RuntimeClasses para el clúster, el utilizarlas es
muy sencillo. Solo se especifica un runtimeClassName en la especificación del Pod.
Por ejemplo:
Así se informa a Kubelet del nombre de la RuntimeClass a utilizar para
este pod. Si dicha RuntimeClass no existe, o el CRI no puede ejecutar el
handler correspondiente, el pod entrará en la
fase final Failed.
Se puede buscar por el correspondiente
evento
con el mensaje de error.
Si no se especifica ninguna runtimeClassName, se usará el RuntimeHandler por
defecto, lo que equivale al comportamiento cuando la opción RuntimeClass está
deshabilitada.
Configuración del CRI
Para más detalles sobre cómo configurar los motores de ejecución del CRI, véase
instalación del CRI.
dockershim
El CRI dockershim incorporado por Kubernetes no soporta manejadores del motor de
ejecución.
Los handlers del motor de ejecución se configuran mediante la configuración
de containerd en /etc/containerd/config.toml. Los handlers válidos se
configuran en la sección de motores de ejecución:
Los handlers del motor de ejecución se configuran a través de la
configuración del CRI-O en /etc/crio/crio.conf. Los manejadores válidos se
configuran en la tabla
crio.runtime
Especificando el campo scheduling en una RuntimeClass se pueden establecer
restricciones para asegurar que los Pods ejecutándose con dicha RuntimeClass se
planifican en los nodos que la soportan.
Para asegurar que los pods sean asignados en nodos que soportan una RuntimeClass
determinada, ese conjunto de nodos debe tener una etiqueta común que se
selecciona en el campo runtimeclass.scheduling.nodeSelector. El nodeSelector
de la RuntimeClass se combina con el nodeSelector del pod durante la admisión,
haciéndose efectiva la intersección del conjunto de nodos seleccionados por
ambos. Si hay conflicto, el pod se rechazará.
Si los nodos soportados se marcan para evitar que los pods con otra RuntimeClass
se ejecuten en el nodo, se pueden añadir tolerations al RuntimeClass. Igual
que con el nodeSelector, las tolerancias se mezclan con las tolerancias del
pod durante la admisión, haciéndose efectiva la unión del conjunto de nodos
tolerados por ambos.
Para saber más sobre configurar el selector de nodos y las tolerancias, véase
Asignando Pods a Nodos.
Sobrecarga del Pod
FEATURE STATE:Kubernetes v1.18 [beta]
Se pueden especificar recursos de sobrecarga adicional que se asocian a los
Pods que estén ejecutándose. Declarar la sobrecarga permite al clúster (incluido
el planificador) contabilizarlo al tomar decisiones sobre los Pods y los
recursos. Para utilizar la sobrecarga de pods, se debe haber habilitado la
feature gate
PodOverhead (lo está por defecto).
La sobrecarga de pods se define en la RuntimeClass a través del los campos de
overhead. Con estos campos se puede especificar la sobrecarga de los pods en
ejecución que utilizan esta RuntimeClass para asegurar que estas sobrecargas se
cuentan en Kubernetes.
Esta página explica los recursos disponibles para Containers dentro del entorno de un Container.
Entorno del Container
El entorno de los Containers de Kubernetes, añade múltiples recursos importantes a los Containers:
Un sistema de ficheros que es la combinación de una imagen y uno o más volúmenes.
Información sobre el propio Container.
Información sobre otros objetos en el clúster.
Información del Container
El hostname de un Container es el nombre del Pod donde el Container está funcionando.
Está disponible a través del comando hostname o con la función gethostname de la libc.
El nombre del Pod y el namespace están disponibles como variables de entorno a través de la
downward API.
Las variables de entorno definidas por el usuario en la definición del Pod están también disponibles en el Container,
así como cualquier variable de entorno definida de forma estática en la imagen de Docker.
Información del Cluster
Una lista de todos los servicios que se ejecutaban cuando se creó el Container está disponible a través de variables de entorno.
La sintaxis de estas variables de entorno coincide con la de los links de Docker.
Para un servicio llamado foo que mapea un Container llamado bar,
las siguientes variables de entorno estan definidas:
FOO_SERVICE_HOST=<El host donde está funcionando el servicio>
FOO_SERVICE_PORT=<El puerto dónde está funcionando el servicio>
Los servicios tienen direcciones IP dedicadas y están disponibles para el Container a través de DNS,
si el complemento para DNS está habilitado.
Siguientes pasos
Más información sobre cómo ejecutar código en respuesta a los cambios de etapa durante ciclo de vida de un contenedor la puedes encontrar en Container lifecycle hooks.
Esta página describe como los contenedores gestionados por kubelet pueden utilizar el framework Container lifecycle hook (hook del ciclo de vida del contenedor)
para ejecutar código disparado por eventos durante la gestión de su ciclo de vida (lifecycle).
Introducción
De manera análoga a muchos frameworks de lenguajes de programación que tienen componentes hooks de lifecycle, como Angular,
Kubernetes también proporciona esta funcionalidad para los contenedores.
Los hooks permiten a los contenedores conocer los eventos en su gestión de ciclo de vida
y ejecutar el código implementado en un controlador cuando el hook de ciclo de vida correspondiente es ejecutado.
Hooks de contenedores
Hay dos hooks expuestos en los contenedores:
PostStart
Este hook se ejecuta inmediatamente después de crear un contenedor.
Sin embargo, no es posible garantizar que el hook se ejecute antes del ENTRYPOINT del contenedor.
No se le pasa ningún parámetro.
PreStop
Este hook se llama inmediatamente antes de que se finalice un contenedor debido a una solicitud de API o evento de gestión como un fallo liveness, o contención de recursos entre otros. Una llamada al hook de Prestop falla si el contenedor ya está en estado terminated (finalizado) o completed (completado).
Es bloqueante, lo que significa que es sincrónico,
por lo que debe completarse antes de que la llamada para eliminar el contenedor pueda ser enviada.
No se le pasa ningún parámetro.
Puedes encontrar información más detallada sobre el comportamiento de finalización de un contenedor
Finalización de Pods.
Implementación de controladores de hooks
Los contenedores pueden acceder a un hook implementando y registrado en un controlador de este hook.
Hay dos tipos de controladores de hooks que se pueden implementar para los contenedores:
Exec: ejecuta un comando específico, como pre-stop.sh, dentro de cgroups y namespaces del contenedor.
Los recursos consumidos por el comando serán tomados en cuenta para el contenedor.
HTTP: ejecuta una petición HTTP contra un endpoint específico dentro del contenedor.
Ejecución de controladores de hooks
Cuando se llama un hook de gestión de ciclo de vida de un contenedor,
el sistema de gestión de Kubernetes ejecuta el controlador en el contenedor registrado para este hook.
Las llamadas al controlador de hooks son síncronas dentro del contexto del Pod que contiene el contenedor.
Esto significa que para un hook PostStart,
el ENTRYPOINT del contenedor y el hook se disparan de forma asíncrona.
Sin embargo, si el hook tarda demasiado en ejecutarse o se cuelga,
el contenedor no puede alcanzar el estado de running (en ejecución).
El comportamiento es similar para un hook PreStop.
Si el hook se cuelga durante la ejecución,
la fase del Pod permanece en un estado de terminating (finalizando) y se cancela después del terminationGracePeriodSeconds (finalización después del periodo de gracia) del pod en cuestión.
Si un hook PostStart o PreStop falla, se mata el contenedor.
Los usuarios deben hacer que sus controladores de hooks sean lo más livianos posible.
Hay casos, sin embargo, que los comandos de larga ejecución tienen sentido,
como cuando se guarda el estado antes de detener un contenedor.
Garantías de entrega de hooks
La entrega de un hook está destinada a ser enviada al menos una vez,
lo que significa que un hook puede ser llamado varias veces para cualquier evento dado,
tanto para PostStart como para PreStop.
Depende de la implementación del hook manejar esto correctamente.
En general, solo se realizan entregas individuales.
Si, por ejemplo, un receptor hook HTTP está inactivo y no puede recibir tráfico,
no hay ningún reintento.
Sin embargo, en algunos casos puede ocurrir una doble entrega.
Por ejemplo, si un Kubelet se reinicia durante la ejecución de envio de un hook,
el hook puede volver a enviarse después de que el kubelet se levante.
Depurando controladores de hooks
Los logs de un controlador de hooks no son expuestos en los eventos del Pod.
Si un controlador falla por alguna razón, emite un evento.
Para PostStart, es el evento FailedPostStartHook,
y para PreStop, el evento FailedPreStopHook.
Puedes ver que eventos están en ejecución con el comando kubectl describe pod <pod_name>.
El siguiente ejemplo muestra los eventos en ejecución a través del comando anterior:
Events:
FirstSeen LastSeen Count From SubobjectPath Type Reason Message
--------- -------- ----- ---- ------------- -------- ------ -------
1m 1m 1 {default-scheduler } Normal Scheduled Successfully assigned test-1730497541-cq1d2 to gke-test-cluster-default-pool-a07e5d30-siqd
1m 1m 1 {kubelet gke-test-cluster-default-pool-a07e5d30-siqd} spec.containers{main} Normal Pulling pulling image "test:1.0"
1m 1m 1 {kubelet gke-test-cluster-default-pool-a07e5d30-siqd} spec.containers{main} Normal Created Created container with docker id 5c6a256a2567; Security:[seccomp=unconfined]
1m 1m 1 {kubelet gke-test-cluster-default-pool-a07e5d30-siqd} spec.containers{main} Normal Pulled Successfully pulled image "test:1.0"
1m 1m 1 {kubelet gke-test-cluster-default-pool-a07e5d30-siqd} spec.containers{main} Normal Started Started container with docker id 5c6a256a2567
38s 38s 1 {kubelet gke-test-cluster-default-pool-a07e5d30-siqd} spec.containers{main} Normal Killing Killing container with docker id 5c6a256a2567: PostStart handler: Error executing in Docker Container: 1
37s 37s 1 {kubelet gke-test-cluster-default-pool-a07e5d30-siqd} spec.containers{main} Normal Killing Killing container with docker id 8df9fdfd7054: PostStart handler: Error executing in Docker Container: 1
38s 37s 2 {kubelet gke-test-cluster-default-pool-a07e5d30-siqd} Warning FailedSync Error syncing pod, skipping: failed to "StartContainer" for "main" with RunContainerError: "PostStart handler: Error executing in Docker Container: 1"
1m 22s 2 {kubelet gke-test-cluster-default-pool-a07e5d30-siqd} spec.containers{main} Warning FailedPostStartHook
Los Pods son las unidades de computación desplegables más pequeñas que se pueden crear y gestionar en Kubernetes.
¿Qué és un Pod?
Un Pod (como en una vaina de ballenas o vaina de guisantes) es un grupo de uno o más contenedores (como contenedores Docker), con almacenamiento/red compartidos, y unas especificaciones de cómo ejecutar los contenedores. Los contenidos de un Pod son siempre coubicados, coprogramados y ejecutados en un contexto compartido. Un Pod modela un "host lógico" específico de la aplicación: contiene uno o más contenedores de aplicaciones relativamente entrelazados. Antes de la llegada de los contenedores, ejecutarse en la misma máquina física o virtual significaba ser ejecutado en el mismo host lógico.
Mientras que Kubernetes soporta más runtimes de contenedores a parte de Docker, este último es el más conocido y ayuda a describir Pods en términos de Docker.
El contexto compartido de un Pod es un conjunto de namespaces de Linux, cgroups y, potencialmente, otras facetas de aislamiento, las mismas cosas que aíslan un contenedor Docker. Dentro del contexto de un Pod, las aplicaciones individuales pueden tener más subaislamientos aplicados.
Los contenedores dentro de un Pod comparten dirección IP y puerto, y pueden encontrarse a través de localhost. También pueden comunicarse entre sí mediante comunicaciones estándar entre procesos, como semáforos de SystemV o la memoria compartida POSIX. Los contenedores en diferentes Pods tienen direcciones IP distintas y no pueden comunicarse por IPC sin configuración especial.
Estos contenedores normalmente se comunican entre sí a través de las direcciones IP del Pod.
Las aplicaciones dentro de un Pod también tienen acceso a volúmenes compartidos, que se definen como parte de un Pod y están disponibles para ser montados en el sistema de archivos de cada aplicación.
En términos de Docker, un Pod se modela como un grupo de contenedores de Docker con namespaces y volúmenes de sistemas de archivos compartidos.
Al igual que los contenedores de aplicaciones individuales, los Pods se consideran entidades relativamente efímeras (en lugar de duraderas). Como se explica en ciclo de vida del pod, los Pods se crean, se les asigna un identificador único (UID) y se planifican en nodos donde permanecen hasta su finalización (según la política de reinicio) o supresión. Si un nodo muere, los Pods programados para ese nodo se programan para su eliminación después de un período de tiempo de espera. Un Pod dado (definido por su UID) no se "replanifica" a un nuevo nodo; en su lugar, puede reemplazarse por un Pod idéntico, con incluso el mismo nombre si lo desea, pero con un nuevo UID (consulte controlador de replicación para obtener más detalles).
Cuando se dice que algo tiene la misma vida útil que un Pod, como un volumen, significa que existe mientras exista ese Pod (con ese UID). Si ese Pod se elimina por cualquier motivo, incluso si se crea un reemplazo idéntico, el recurso relacionado (por ejemplo, el volumen) también se destruye y se crea de nuevo.
diagrama de Pod
Un Pod de múltiples contenedores que contiene un extractor de archivos y un servidor web que utiliza un volumen persistente para el almacenamiento compartido entre los contenedores.
Motivación para los Pods
Gestión
Los Pods son un modelo del patrón de múltiples procesos de cooperación que forman una unidad de servicio cohesiva. Simplifican la implementación y la administración de las aplicaciones proporcionando una abstracción de mayor nivel que el conjunto de las aplicaciones que lo constituyen. Los Pods sirven como unidad de despliegue, escalado horizontal y replicación. La colocación (coprogramación), el destino compartido (por ejemplo, la finalización), la replicación coordinada, el uso compartido de recursos y la gestión de dependencias se controlan automáticamente para los contenedores en un Pod.
Recursos compartidos y comunicación
Los Pods permiten el intercambio de datos y la comunicación entre los contenedores que lo constituyen.
Todas las aplicaciones en un Pod utilizan el mismo namespace de red (la misma IP y puerto) y, por lo tanto, pueden "encontrarse" entre sí y comunicarse utilizando localhost.
Debido a esto, las aplicaciones en un Pod deben coordinar su uso de puertos. Cada Pod tiene una dirección IP en un espacio de red compartido que tiene comunicación completa con otros servidores físicos y Pods a través de la red.
Los contenedores dentro del Pod ven que el hostname del sistema es el mismo que el nombre configurado para el Pod. Hay más información sobre esto en la sección networking.
Además de definir los contenedores de aplicaciones que se ejecutan en el Pod, el Pod especifica un conjunto de volúmenes de almacenamiento compartido. Los volúmenes permiten que los datos sobrevivan a reinicios de contenedores y se compartan entre las aplicaciones dentro del Pod.
Usos de Pods
Los Pods pueden ser usados para alojar pilas de aplicaciones integradas (por ejemplo, LAMP), pero su objetivo principal es apoyar los programas de ayuda coubicados y coadministrados, como:
sistemas de gestión de contenido, loaders de datos y archivos, gestores de caché locales, etc.
copia de seguridad de registro y punto de control, compresión, rotación, captura de imágenes, etc.
observadores de cambio de datos, adaptadores de registro y monitoreo, publicadores de eventos, etc.
proxies, bridges y adaptadores.
controladores, configuradores y actualizadores.
Los Pods individuales no están diseñados para ejecutar varias instancias de la misma aplicación, en general.
¿Por qué simplemente no ejecutar múltiples programas en un solo contenedor de Docker?
Transparencia. Hacer visibles los contenedores dentro del Pod
a la infraestructura permite que esta brinde servicios, como gestión de procesos
y monitoreo de recursos, a los contenedores, facilitando una
serie de comodidades a los usuarios.
Desacople de dependencias de software. Los contenedores individuales pueden ser
versionados, reconstruidos y redistribuidos independientemente. Kubernetes podría incluso apoyar
actualizaciones en vivo de contenedores individuales en un futuro.
Facilidad de uso. Los usuarios no necesitan ejecutar sus propios administradores de procesos,
para propagación de señales, códigos de salida, etc.
Eficiencia. Debido a que la infraestructura asume más responsabilidad,
los contenedores pueden ser más livianos.
¿Por qué no admitir la planificación conjunta de contenedores por afinidad?
Ese enfoque proporcionaría la ubicación conjunta, pero no la mayor parte de
beneficios de los Pods, como compartir recursos, IPC, compartir el destino garantizado y
gestión simplificada.
Durabilidad de pods (o su ausencia)
Los Pods no están destinados a ser tratados como entidades duraderas. No sobrevivirán a errores de planificación, caídas de nodo u otros desalojos, ya sea por falta de recursos o en el caso de mantenimiento de nodos.
En general, los usuarios no deberían necesitar crear Pods directamente, deberían
usar siempre controladores incluso para Pods individuales, como por ejemplo, los
Deployments.
Los controladores proporcionan autorecuperación con un alcance de clúster, así como replicación
y gestión de despliegue.
Otros controladores como los StatefulSet
pueden tambien proporcionar soporte para Pods que necesiten persistir el estado.
El uso de API colectivas como la principal primitiva de cara al usuario es relativamente común entre los sistemas de planificación de clúster, incluyendo Borg, Marathon, Aurora, y Tupperware.
El Pod se expone como primitiva para facilitar:
planificación y capacidad de conexión del controlador
soporte para operaciones a nivel de Pod sin la necesidad de "proxy" a través de las API del controlador
desacople de la vida útil del Pod de la vida útil del controlador, como para el arranque
desacople de controladores y servicios, el endpoint del controlador solo mira Pods
composición limpia de funcionalidad a nivel de Kubelet con funcionalidad a nivel de clúster, Kubelet es efectivamente el "controlador de Pod"
aplicaciones en alta disponibilidad, que esperan que los Pods sean reemplazados antes de su finalización y ciertamente antes de su eliminación, como en el caso de desalojos planificados o descarga previa de imágenes.
Finalización de Pods
Debido a que los Pods representan procesos en ejecución en los nodos del clúster, es importante permitir que esos procesos finalicen de forma correcta cuando ya no se necesiten (en lugar de ser detenidos bruscamente con una señal de KILL). Los usuarios deben poder solicitar la eliminación y saber cuándo finalizan los procesos, pero también deben poder asegurarse de que las eliminaciones finalmente se completen. Cuando un usuario solicita la eliminación de un Pod, el sistema registra el período de gracia previsto antes de que el Pod pueda ser eliminado de forma forzada, y se envía una señal TERM al proceso principal en cada contenedor. Una vez que el período de gracia ha expirado, la señal KILL se envía a esos procesos y el Pod se elimina del servidor API. Si se reinicia Kubelet o el administrador de contenedores mientras se espera que finalicen los procesos, la terminación se volverá a intentar con el período de gracia completo.
Un ejemplo del ciclo de terminación de un Pod:
El usuario envía un comando para eliminar Pod, con un período de gracia predeterminado (30s)
El Pod en el servidor API se actualiza con el tiempo a partir del cual el Pod se considera "muerto" junto con el período de gracia.
El Pod aparece como "Terminando" cuando aparece en los comandos del cliente
(simultáneo con 3) Cuando el Kubelet ve que un Pod se ha marcado como terminado porque se ha configurado el tiempo en 2, comienza el proceso de apagado del Pod.
Si uno de los contenedores del Pod ha definido un preStop hook, se invoca dentro del contenedor. Si el hook preStop todavía se está ejecutando después de que expire el período de gracia, el paso 2 se invoca con un pequeño período de gracia extendido (2s).
El contenedor recibe la señal TERM. Tenga en cuenta que no todos los contenedores en el Pod recibirán la señal TERM al mismo tiempo y cada uno puede requerir un hook preStop si el orden en el que se cierra es importante.
(simultáneo con 3) Pod se elimina de la lista de endponts del servicio, y ya no se considera parte del conjunto de Pods en ejecución para controladores de replicación. Los Pods que se apagan lentamente no pueden continuar sirviendo el tráfico ya que los balanceadores de carga (como el proxy de servicio) los eliminan de sus rotaciones.
Cuando expira el período de gracia, todos los procesos que todavía se ejecutan en el Pod se eliminan con SIGKILL.
El Kubelet terminará de eliminar el Pod en el servidor API configurando el período de gracia 0 (eliminación inmediata). El Pod desaparece de la API y ya no es visible desde el cliente.
Por defecto, todas las eliminaciones se realizan correctamente en 30 segundos. El comando kubectl delete admite la opción--grace-period = <seconds>que permite al usuario anular el valor predeterminado y especificar su propio valor. El valor 0forzar eliminación del Pod.
Debe especificar un indicador adicional --force junto con --grace-period = 0 para realizar eliminaciones forzadas.
Forzar destrucción de Pods
La eliminación forzada de un Pod se define como la eliminación de un Pod del estado del clúster y etcd inmediatamente. Cuando se realiza una eliminación forzada, el apiserver no espera la confirmación del kubelet de que el Pod ha finalizado en el nodo en el que se estaba ejecutando. Elimina el Pod en la API inmediatamente para que se pueda crear un nuevo Pod con el mismo nombre. En el nodo, los Pods que están configurados para terminar de inmediato recibirán un pequeño período de gracia antes de ser forzadas a matar.
Estas eliminaciones pueden ser potencialmente peligrosas para algunos Pods y deben realizarse con precaución. En el caso de Pods de StatefulSets, consulte la documentación de la tarea para eliminando Pods de un StatefulSet.
Modo privilegiado para Pods
Cualquier contenedor en un Pod puede habilitar el modo privilegiado, utilizando el indicador privilegiado en el contexto de seguridad de la especificación del contenedor. Esto es útil para contenedores que desean usar capacidades de Linux como manipular la pila de red y acceder a dispositivos. Los procesos dentro del contenedor obtienen casi los mismos privilegios que están disponibles para los procesos fuera de un contenedor. Con el modo privilegiado, debería ser más fácil escribir complementos de red y volumen como Pods separados que no necesitan compilarse en el kubelet.
Nota:
El runtime de contenedores debe admitir el concepto de un contenedor privilegiado para que esta configuración sea relevante.
API
Pod es un recurso de nivel superior en la API REST de Kubernetes.
La definición de objeto de API Pod
describe el objeto en detalle.
3.4.1.2 - Ciclo de vida de un Pod
Esta página describe el ciclo de vida de un Pod.
Los Pods siguen un ciclo de vida definido, comenzando en la fase Pending,
y luego pasando a "en ejecución" Running si al menos uno de sus contenedores primarios se
inicia correctamente,
y luego pasando a "exitoso" (Succeeded) o "fallido" (Failed) si uno de los contenedores de un Pod
termina en error.
Al igual que contenedores de aplicaciones, los Pods se consideran entidades relativamente efímeras.
Los Pods se crean y se les asigna un identificador único (UID), y se programan para ejecutarse en nodos donde se mantienen hasta que se terminan (de acuerdo con las políticas de reinicio) o se eliminan.
Si un nodo muere,
los Pods programados para ejecutarse en ese Nodo
se programan para eliminarse.
El plano de control marca los Pods para ser eliminados luego de un periodo de tiempo.
Ciclo de vida de un Pod
Mientras un Pod se está ejecutando, el kubelet puede reiniciar contenedores para manejar algunos tipos de fallos.
Dentro de un Pod, Kubernetes rastrea distintos estados del contenedor y determina qué acción realizar para que el Pod esté sano nuevamente.
En la API de Kubernetes, los Pods tienen una especificación y un estatus actual.
El estatus de un objeto Pod consiste en un conjunto de condiciones del Pod.
También puedes inyectar información de readiness personalizada a los datos de condición de un Pod, si es útil para tu aplicación.
Los Pods solo se programan una vez en su ciclo de vida; asignar un Pod a un nodo específico se llama vincular (binding, en inglés), y el proceso de seleccionar cuál Pod usar se llama programar.
Una vez que un Pod está vinculado a un nodo, Kubernetes intenta ejecutar el Pod en ese nodo.
El Pod se ejecuta en ese nodo hasta que termina, o hasta que es terminado; si Kubernetes no es capaz de iniciar el Pod en el nodo seleccionado (por ejemplo, si el nodo falla antes que el Pod inicie), entonces ese Pod en particular nunca inicia.
Puedes usar readiness de programación del Pod para retrasar la programación de un Pod hasta que todas sus puertas de programación sean removidas.
Por ejemplo, podrías querer definir un conjunto de Pods, pero solo lanzar la programación una vez que todos los Pods hayan sido creados.
Sin embargo, los Pods pueden fallar de una manera que el clúster no puede recuperar, y en ese caso
Kubernetes no intenta más sanar el Pod; en su lugar, Kubernetes elimina el
Pod y confía en otros componentes para proporcionar una curación automática.
Si un Pod está programado para un nodo y ese
nodo luego falla, el Pod se trata como no saludable y Kubernetes eventualmente elimina el Pod.
Un Pod no sobrevivirá a una evacuación debido
a la falta de recursos o al mantenimiento del Nodo.
Kubernetes utiliza una abstracción de nivel superior, llamada
controlador, que maneja el trabajo de
gestionar las instancias de Pods relativamente desechables.
Un Pod dado (como se define por un UID) nunca es "reprogramado" a un nodo diferente; en su lugar,
ese Pod puede ser reemplazado por un nuevo Pod casi idéntico.
Si hace un Pod de reemplazo, incluso puede
tener el mismo nombre (como en .metadata.name) que tenía el Pod antiguo, pero el reemplazo
tendría un .metadata.uid diferente del Pod antiguo.
Kubernetes no garantiza que un reemplazo de un Pod existente sea programado
en el mismo nodo en el que el antiguo Pod estaba siendo reemplazado.
Ciclo de vida asociados
Cuando se dice que algo tiene la misma vida útil que un Pod, como un
volúmen,
eso significa que el objeto existe mientras ese Pod específico (con ese UID exacto)
exista.
Si ese Pod se elimina por cualquier razón, e incluso si se crea un reemplazo idéntico,
el objeto relacionado (un volumen, en este ejemplo) también se destruye y se crea nuevamente.
Figura 1.
Un Pod de varios contenedores que contiene un extractor de archivos sidecar y un servidor web. El Pod utiliza un volumen efímero emptyDir para almacenamiento compartido entre los contenedores.
Fase del Pod
El campo status de un Pod es un objeto
PodStatus
de Kubernetes que tiene un campo phase.
La fase de un Pod es un resumen simple y de alto nivel de dónde se encuentra el
Pod en su ciclo de vida. La fase no pretende ser un resumen completo de
observaciones del estado del contenedor o Pod, ni tampoco pretende ser una
máquina de estado completa.
El número y los significados de los valores de fase de un Pod están
estrechamente guardados.
Aparte de lo que se documenta aquí, no se debe asumir nada acerca de los Pods
que tienen un valor de phase determinado.
Aquí están los posibles valores de phase:
Valor
Descripción
Pending
El clúster de Kubernetes aceptó el Pod, pero uno o más contenedores no se configuraron ni prepararon para ejecutarse. Esto incluye el tiempo que pasa un Pod esperando ser programado, así como el tiempo dedicado a descargar imágenes de contenedores a través de la red.
Running
El Pod se vinculó a un nodo y se crearon todos los contenedores. Al menos un contenedor todavía se está ejecutando o está en proceso de iniciarse o reiniciarse.
Succeeded
Todos los contenedores del Pod finalizaron con éxito y no se reiniciarán.
Failed
Todos los contenedores del Pod han finalizado y al menos un contenedor ha finalizado con error. Es decir, el contenedor salió con un estado distinto de cero o el sistema lo canceló.
Unknown
Por alguna razón no se pudo obtener el estado del Pod. Esta fase generalmente ocurre debido a un error en la comunicación con el nodo donde debería ejecutarse el Pod.
Nota:
Cuando se está borrando un Pod, se muestra como Terminating por algunos
comandos de kubectl.
Este estado Terminating no es una de las fases del Pod.
A un Pod se le garantiza un tiempo para terminar con gracia,
cuyo valor por defecto es 30 segundos.
Puedes utilizar el flag --force
para terminar un Pod por la fuerza.
A partir de la versión 1.27 de Kubernetes, el kubelet aplica una transición de
los Pods borrados, excepto
por Pods estáticos
y Pods borrados por la fuerza sin un finalizador, a
una fase terminal
(Failed o Succeeded dependiendo de los códigos de salida de los contenedores
del Pod) antes de su eliminación del servidor API.
Si un Nodo muere o se desconecta del resto del clúster,
Kubernetes aplica una política para establecer la phase de todos los Pods
en Failed.
Estados del contenedor
Así como la fase del Pod en general, Kubernetes rastrea el estado de cada
contenedor dentro de un Pod.
Puedes
usar hooks del ciclo de vida de un contenedor
para lanzar eventos en ciertos puntos en el ciclo de vida de un
contenedor.
Una vez que el programador
asigna un Pod a un Nodo,
el kubelet inicia creando los contenedores para ese Pod usando un
runtime del contenedor.
Hay 3 estados posibles para un contenedor: Waiting(esperando), Running(en ejecución), y Terminated(terminado).
Para revisar el estado de los contenedores de un Pod,
puedes usar kubectl describe pod <name-of-pod>.
La salida muestra el estado de cada contenedor dentro del Pod.
Cada estado tiene un significado específico:
Waiting
Si un contenedor no está en el estado Running o Terminated, está Waiting.
Un contenedor en el estado Waiting aún está ejecutando las operaciones que
requiere para completar su arranque:
por ejemplo,
descargar la imagen del contenedor de un registro de imágenes de un contenedor,
o aplicando datos secretos.
Running
El estado Running indica que el contenedor se está ejecutando sin problemas.
Si hay un hook postStart configurado, ya se ha ejecutado y finalizado.
Cuando utilizas el comando kubectl para consultar un Pod con un contenedor que
está Running,
también puedes ver información sobre cuando el contenedor entró en
estado Running.
Terminated
Un contenedor en el estado Terminated comenzó su ejecución y luego se terminó
con éxito o falló por alguna razón.
Cuando usas kubectl para consultar un Pod con un contenedor que
está Terminated, puedes ver un motivo, y un código de salida, y la hora de
inicio y de finalización del contenedor.
Si un contenedor tiene un hook preStop configurado, el hook se ejecuta antes
de que el contenedor entre en estado Terminated.
Cómo los Pods manejan los problemas con los contenedores
Kubernetes maneja los fallos de los contenedores dentro de los Pods usando una política de reinicio, restartPolicy en inglés definida en la especificación spec del Pod.
Esta política determina cómo reacciona Kubernetes cuando los contenedores salen debido a errores u otras razones, que sigue la siguiente secuencia:
Fallo inicial: Kubernetes intenta un reinicio inmediato basado en la restartPolicy del Pod.
Fallos repetidos:
Después del fallo inicial, Kubernetes aplica un retraso exponencial para los reinicios subsiguientes, descrito en restartPolicy.
Esto evita que los intentos de reinicio rápidos y repetidos sobrecarguen el sistema.
Estado de CrashLoopBackOff:
Esto indica que el mecanismo de retraso exponencial está actualmente en efecto para un contenedor dado que está en un bucle de fallos, fallando y reiniciando repetidamente.
Reinicio del retraso:
Si un contenedor funciona correctamente durante un cierto período (por ejemplo, 10 minutos), Kubernetes reinicia el retraso, tratando cualquier nuevo fallo como el primero.
En la práctica, un CrashLoopBackOff es una condición o evento que podría verse como salida del comando kubectl, al describir o listar Pods, cuando un contenedor en el Pod no arranca correctamente y luego intenta y falla continuamente en un bucle.
En otras palabras, cuando un contenedor entra en el bucle de fallos, Kubernetes aplica el retraso exponencial mencionado en la Política de reinicio del contenedor.
Este mecanismo evita que un contenedor defectuoso sobrecargue el sistema con intentos de inicio fallidos continuos.
El CrashLoopBackOff puede ser causado por problemas como los siguientes:
Errores de la aplicación que hacen que el contenedor salga.
Errores de configuración, como variables de entorno incorrectas o archivos de configuración faltantes.
Restricciones de recursos, donde el contenedor puede no tener suficiente memoria o CPU para arrancar correctamente.
Fallos en los chequeos de salud si la aplicación no comienza a servir dentro del tiempo esperado.
Las sondas de liveness o de arranque del contenedor devuelven un resultado de Failure como se menciona en la sección de sondas.
Para investigar la causa raíz de un problema de CrashLoopBackOff, un usuario puede:
Revisar los registros: Use kubectl logs <nombre-del-pod> para revisar los registros del contenedor. Esta es a menudo la forma más directa de diagnosticar el problema que causa los fallos.
Inspeccionar eventos: Use kubectl describe pod <nombre-del-pod> para ver eventos para el Pod, lo que puede proporcionar pistas sobre problemas de configuración o recursos.
Revisar la configuración: Asegúrese de que la configuración del Pod, incluidas las variables de entorno y los volúmenes montados, sea correcta y que todos los recursos externos necesarios estén disponibles.
Verificar los límites de recursos: Asegúrese de que el contenedor tenga suficiente CPU y memoria asignada. A veces, aumentar los recursos en la definición del Pod puede resolver el problema.
Depurar la aplicación: Pueden existir errores o configuraciones incorrectas en el código de la aplicación. Ejecutar esta imagen de contenedor localmente o en un entorno de desarrollo puede ayudar a diagnosticar problemas específicos de la aplicación.
Política de reinicio del contenedor
La especificación (spec en inglés) de un Pod tiene un campo restartPolicy con los posibles
valores Always, OnFailure, y Never.
El valor por defecto es Always.
La política de reinicio (restartPolicy en inglés) para un Pod aplica a
contenedores de apps en el Pod
para contenedores de inicialización regulares.
Los contenedores sidecar
ignoran el campo restartPolicy: en Kubernetes, un sidecar se define como una
entrada dentro de initContainers que tiene su restartPolicy a nivel del contenedor
establecido en Always. Para contenedores de inicio que finalizan con un error, el kubelet reinicia el
contenedor de inicio si el nivel del Pod restartPolicy es OnFailure
o Always:
Always: Automáticamente reinicia el contenedor luego de alguna terminación.
OnFailure: Solo reinicia el contenedor si finaliza con un error (estado de salida distinto de cero).
Never: No reinicia el contenedor automáticamente.
Cuando el kubelet está manejando el contenedor, se reinicia de acuerdo con la política de reinicio configurada, que solo se aplica a los reinicios que realizan contenedores de
reemplazo dentro del
mismo Pod y ejecutándose en el mismo nodo.
Después de que los contenedores en un Pod terminan, el kubelet
los reinicia con un retraso de retroceso exponencial (10s, 20s, 40s,...), que
está limitado a
cinco minutos. Una vez que un contenedor se ha ejecutado durante 10 minutos sin
ningún problema, el
kubelet restablece el temporizador de reinicio para ese contenedor.
Ciclo de vida de contenedores Sidecar y el Pod
explica el comportamiento de init containers cuando
especifica una restartPolicy.
Condiciones del Pod
Un Pod tiene un PodStatus, que tiene un listado de
PodConditions
a través de los cuales el Pod ha pasado o no.
El kubelet administra las siguientes condiciones del Pod:
PodScheduled: El Pod está programado para un nodo.
PodReadyToStartContainers: (característica beta; habilitada
por defecto) La zona de pruebas del Pod se creó
correctamente y se configuró la red.
ContainersReady: todos los contenedores en el Pod están listos.
Ready: el Pod es capaz de recibir peticiones y debería ser agregado a los
grupos de equilibrio de carga de todos los Services que coincidan.
Nombre del campo
Descripción
type
Nombre de esta condición del Pod.
status
Indica si la condición es aplicable, con valores posibles "True", "False", ó "Unknown".
lastProbeTime
Marca de tiempo de cuando se probó por última vez la condición del Pod.
lastTransitionTime
Marca de tiempo de cuando el Pod hizo transición de un estado a otro.
reason
Texto legible por máquina que indica el motivo de la última transición de la condición.
message
Mensaje legible por humanos indicando detalles acerca de la última transición de estado.
Preparación del Pod
FEATURE STATE:Kubernetes v1.14 [stable]
Tu aplicación puede inyectar retroalimentación adicional o señales
al PodStatus:
Pod readiness.
Para usar esto, establece readinessGates en la spec del Pod para especificar una
lista de condiciones adicionales que el kubelet evalúa para la preparación del
Pod.
Las condiciones de preparación están determinadas por el estado actual de los
campos status.conditions de un Pod.
Si Kubernetes no puede encontrar una condición en el campo status.conditions
de un Pod, el estado de la condición se establece en "False".
Aquí hay un ejemplo:
kind:Pod...spec:readinessGates:- conditionType:"www.example.com/feature-1"status:conditions:- type:Ready # una PodCondition construidastatus:"False"lastProbeTime:nulllastTransitionTime:2018-01-01T00:00:00Z- type:"www.example.com/feature-1"# una PodCondition extrastatus:"False"lastProbeTime:nulllastTransitionTime:2018-01-01T00:00:00ZcontainerStatuses:- containerID:docker://abcd...ready:true...
Las condiciones del Pod que incluyas deben tener nombres que sean válidos para
los formatos de etiqueta
de Kubernetes.
Estado de preparación del Pod
El comando kubectl patch no admite actualizar el estado del objeto.
Para establecer estas status.conditions para el Pod, las aplicaciones y
los operadores
deberían utilizar la acción Patch.
Puedes utilizar
una librería cliente de Kubernetes
para escribir código que establece condiciones personalizadas de un Pod para su
preparación.
Para los Pods que utilizan condiciones personalizadas, ese Pod es evaluado para
estar listo solamente cuando ambas afirmaciones aplican:
Todos los contenedores del Pod están listos.
Todas las condiciones personalizadas especificadas en readinessGates
están True.
Cuando los contenedores de un Pod están listos, pero al menos una condición
personalizada está ausente o False,
el kubelet establece la condición del Pod
en ContainersReady.
Preparación de la red del Pod
FEATURE STATE:Kubernetes v1.29 [beta]
Nota:
Durante su desarrollo temprano, esta condición se llamó PodHasNetwork.
Después de que un Pod es programado en un nodo, necesita ser admitido por el kubelet y
tener cualquier volumen de almacenamiento requerido montado.
Una vez que estas fases se completan,
el kubelet trabaja con
un runtime de contenedores (usando Container runtime interface (CRI)) para configurar un
sandbox de runtime y configurar la red para el Pod.
Si la puerta de característicasPodReadyToStartContainersCondition
está habilitada
(está habilitada por defecto para Kubernetes 1.31), la
condición PodReadyToStartContainers se agregará al campo status.conditions de un Pod.
La condición PodReadyToStartContainers se establece en False por el kubelet cuando detecta que un
Pod no tiene un sandbox de runtime con red configurada.
Esto ocurre en los siguientes escenarios:
Al principio del ciclo de vida del Pod, cuando el kubelet aún no ha comenzado a configurar un sandbox para
el Pod usando el runtime de contenedores.
Más adelante en el ciclo de vida del Pod, cuando el sandbox del Pod ha sido destruido debido a:
el nodo reiniciándose, sin que el Pod sea desalojado.
para runtimes de contenedores que usan máquinas virtuales para aislamiento, la máquina virtual del sandbox del Pod reiniciándose, lo que luego requiere crear un nuevo sandbox y
una nueva configuración de red para el contenedor.
La condición PodReadyToStartContainers se establece en True por el kubelet después de la
finalización exitosa de la creación del sandbox y la configuración de la red para el Pod
por el plugin de runtime. El kubelet puede comenzar a extraer imágenes de contenedores y crear
contenedores después de que la condición PodReadyToStartContainers se haya establecido en True.
Para un Pod con contenedores de inicialización, el kubelet establece la condición Initialized en
True después de que los contenedores de inicialización se hayan completado exitosamente (lo que ocurre
después de la creación exitosa del sandbox y la configuración de la red por el plugin de runtime).
Para un Pod sin contenedores de inicialización, el kubelet establece la condición Initialized
en True antes de que comience la creación del sandbox y la configuración de la red.
Sondeos del contenedor
Una sonda es un diagnóstico realizado periódicamente por
el kubelet en un
contenedor.
Para ejecutar este diagnóstico, el kubelet ejecuta código dentro del contenedor
o realiza una solicitud de red.
Mecanismos de revisión
Existen cuatro maneras diferentes de revisar un contenedor usando una sonda.
Cada sonda debe definir exactamente una de estas cuatro maneras:
exec: Ejecuta un comando especificado dentro del contenedor.
El diagnóstico se considera exitoso si el comando termina con un código de
estado 0.
grpc
Realiza una llamada de procedimiento remoto usando gRPC.
El destino debe
implementar revisión de estado de gRPC.
El diagnóstico se considera exitoso si el status de la respuesta es SERVING.
httpGet
Realiza una petición HTTP GET contra la dirección IP en la ruta y puerto
especificado.
El diagnóstico se considera exitoso si la respuesta tiene un código de estado
mayor o igual que 200 y menor que 400.
tcpSocket
Realiza una revisión TCP contra la dirección IP del Pod en un puerto
específico.
El diagnóstico se considera exitoso si el puerto está abierto.
Si el sistema remoto (el contenedor) cierra la conexión inmediatamente después
de abrir la conexión, el diagnóstico se considera exitoso.
Precaución:
A diferencia de otros mecanismos, la implementación de la sonda exec involucra
la creación/bifurcación de múltiples procesos cada vez que se ejecuta.
Como resultado, en caso de clústers con mayor densidad de Pods, intérvalos más
bajos de initialDelaySeconds, periodSeconds, configurando un sondeo
con exec puede introducir una sobrecarga en el uso de la CPU del nodo.
En tales escenarios, considere la utilización de los mecanismos alternativos de
sondeo para evitar la sobrecarga.
Resultados de sondeos
Cada sondeo puede tener uno de tres resultados:
Success
El contenedor ha pasado el diagnóstico.
Failure
El contenedor ha fallado el diagnóstico.
Unknown
El diagnóstico ha fallado (no se debe tomar ninguna acción, y el kubelet hará
más revisiones adicionales).
Tipos de sondeo
Opcionalmente,
el kubelet puede ejecutar y reaccionar a tres tipos de sondeos en contenedores
en ejecución:
livenessProbe
Indica si el contenedor se está ejecutando.
Si el sondeo falla, el kubelet mata el contenedor,
y el contenedor está sujeto a su política de reinicio.
Si un contenedor no tiene un sondeo de liveness, el estado por defecto
es Success.
readinessProbe
Indica si un contenedor está preparado para responder a peticiones.
Si el sondeo falla,
el controlador de endpoints elimina las direcciones IP del Pod de los endpoints
de todos los Services que coinciden con el Pod.
El estado por defecto de readiness antes del retraso inicial es Failure.
Si un contenedor no tiene un sondeo de readiness, el estado por defecto
es Success.
startupProbe
Indica si la aplicación dentro del contenedor ha iniciado. El resto de los
sondeos están deshabilitados si un sondeo de inicio se proporciona, hasta que se
complete. Si el sondeo falla, el kubelet mata el contenedor y el contenedor
está sujeto a su política de reinicio. Si un contenedor no
tiene un sondeo de inicio, el estado por defecto es Success.
Si el proceso en tu contenedor es capaz de terminar por sí mismo cuando
encuentra un error o deja de estar sano, no necesitas un sondeo liveness; el
kubelet automáticamente realizará la acción adecuada de acuerdo con la política
de reinicio restartPolicy del Pod.
Si te gustaría que tu contenedor fuese destruido y reiniciado si falla un
sondeo, especifica un sondeo liveness y especifica una restartPolicy
de Always o OnFailure.
¿Cuándo debería utilizar un sondeo readiness?
Se te gustaría enviar tráfico al Pod solo cuando una sonda sea exitosa,
especifica un sondeo readiness.
En este caso,
el sondeo readiness podría ser el mismo que el liveness,
pero la existencia del sondeo readines en la especificación significa que el Pod
iniciará sin recibir ningún tráfico y solo iniciará cuando el sondeo readiness
sea exitoso.
Si quieres que tu contenedor sea capaz de darse de baja por mantenimiento por sí
mismo,
puedes especificar un sondeo de readiness que revisa un endpoint específico de
readiness que es distinto del sondeo liveness.
Si tu aplicación tiene una dependencia estricta con servicios de trasfondo,
puedes implementar ambos sondeos de liveness y readiness.
El sondeo de liveness pasa cuando la aplicación por sí misma está sana, pero el
sondeo de readiness revisa adicionalmente que cada servicio de trasfondo está
disponible.
Esto ayuda a evitar enviar a Pods que solo pueden responder con errores.
Si tu contenedor necesita trabajar cargando grandes datos, ficheros de
configuración, o migraciones durante el inicio, puedes usar
un sondeo de inicio.
Sin embargo, si quieres detectar la diferencia entre una aplicación que ha
fallado y una aplicación que todavía está procesando datos de inicialización,
puedes usar un sondeo de readiness.
Nota:
Si quieres ser capaz de drenar peticiones cuando se elimina el Pod,
no necesitas un sondeo readiness;
cuando se elimina el Pod,
automáticamente se cambia al estado unready sin importar si existe el sondeo
readiness.
El Pod permanece en el estado unready mientras espera que los contenedores en
el Pod se paren.
¿Cuándo debería utilizar un sondeo de inicialización?
Los sondeos de inicialización son útiles para Pods que tienen contenedores que
se toman un largo tiempo para estar en servicio.
En lugar de especificar un intérvalo largo de liveness, puedes crear una
configuración separada para sondear el contenedor en el inicio, permitiendo un
tiempo mayor que el intervalo de liveness.
Si tu contenedor usualmente inicia en más
de initialDelaySeconds + failureThreshold × periodSeconds, deberías
especificar un sondeo de inicialización que revise el mismo endpoint que la
sonda liveness.
El periodo por defecto periodSeconds es de 10 segundos.
Deberías especificar el campo failureThreshold lo suficientemente alto para
permitir al contenedor arrancar, sin cambiar los valores por defecto de la sonda
liveness.
Esto ayuda a proteger contra puntos muertos.
Finalización de Pods
Ya que los Pods representan procesos ejecutándose en nodos de un clúster, es
importante permitir que esos procesos terminen con gracia cuando no se
necesitan (en lugar de detenerse abruptamente con una señal Kill y sin
oportunidad de limpiarse).
El diseño está orientado a permitir que puedas solicitar la eliminación de un
Pod y saber cuándo finalizan los procesos, pero también para asegurar que la
eliminación se completa eventualmente.
Cuando solicitas la eliminación de un Pod, el clúster registra y rastrea el
periodo de gracia antes de que el Pod se elimine por la fuerza.
Con este rastreo de detención forzada en marcha,
el kubelet intenta pararlo con gracia.
Típicamente, con esta finalización con gracia del Pod, el kubelet hace
peticiones al tiempo de ejecución del contenedor para intentar detener los
contenedores en el Pod, primeramente enviando una señal Term (ej. SIGTERM),
con un período de tiempo de gracia, al proceso principal de cada contenedor.
Las peticiones para parar los contenedores se procesan de forma asíncrona en el
tiempo de ejecución del contenedor.
No hay garantía del orden de procesamiento de estas peticiones.
Muchos contenedores respetan el valor STOPSIGNAL definido en la imagen del
contenedor y, si es diferente, envían el valor de STOPSIGNAL en lugar de
TERM.
Una vez que el período de gracia ha acabado,
se envía la señal KILL a cualquier proceso restante, y luego el Pod se elimina
del Servidor API.
Si el kubelet o el tiempo de ejecución del contenedor del servicio que lo
administra se reinicia mientras espera que los procesos terminen, el kubelet
reintenta de nuevo el proceso incluyendo el periodo original de gracia.
Un flujo de finalización de un Pod, ilustrado con un ejemplo:
Utilizas la herramienta kubectl para eliminar manualmente un Pod
específico, con un periodo de gracia por defecto (30 segundos).
El Pod en el servidor API se actualiza con el tiempo más allá del cual el Pod
se considera "muerto"
junto con el periodo de gracia.
Si utilizas kubectl describe para revisar el Pod que estás borrando,
ese Pod se mostrará como Terminating.
En el nodo donde se ejecuta el Pod: tan pronto como el kubelet observa que el
Pod se ha marcado como terminando (se ha definido una duración de parada con
gracia), el kubelet comienza el proceso local de parar el Pod.
Si uno de los contenedores del Pod tiene definido
un hookpreStop y
el terminationGracePeriodSeconds en la especificación del Pod no está
definido en 0, el kubelet ejecuta ese hook dentro del contenedor.
El terminationGracePeriodSeconds por defecto es 30 segundos.
Si el hook preStop todavía se está ejecutando luego de la expiración del
período de gracia, el kubelet solicita una extensión 2 segundos del periodo
de gracia.
Nota:
Si el hook preStop necesita más tiempo para completar que el tiempo
permitido por defecto,
debes modificar el terminationGracePeriodSeconds para adaptarlo.
El kubelet lanza el tiempo de ejecución del contenedor para enviar una
señal TERM al proceso 1 dentro de cada contenedor.
Nota:
Los contenedores en el Pod reciben la señal TERM en tiempos diferentes y en
orden arbitrario.
Si el orden de finalización importa, considera utilizar un hook preStop
para sincronizarlos.
Al mismo tiempo que el kubelet inicia la finalización con gracia del Pod, el
panel de control evalúa si quitar este Pod en finalización de los
objetos EndpointSlice (y Endpoints), donde aquellos objetos representan
un Service con un selector configurado.
Los ReplicaSets y otros
recursos de carga de trabajo ya no consideran al Pod como réplica válida, en
servicio.
Los Pods que finalizan lentamente no servirían tráfico regular y debería
iniciar la finalización de procesamiento de conexiones abiertas.
Algunas aplicaciones necesitan ir más allá de finalizar las conexiones
abiertas y necesitan finalización aún con más gracia, por ejemplo, drenar y
completar una sesión.
Cualquier endpoint que representa los Pods en finalización no son removidos
inmediatamente de EndpointSlices y se expone un estatus indicando
el estado de terminación
de la API de EndpointSlice
(y la API de Endpoint legada).
Los endpoints que están terminando siempre tienen su estatus ready
como false (para compatibilidad con versiones anteriores a 1.26), por lo
que los balanceadores de carga no los usarán para tráfico regular.
Si se necesita drenar el tráfico en un Pod que está terminando,
el readiness se puede revisar con la condición serving.
Puedes encontrar más detalles en cómo implementar drenado de conexiones en el
tutorial Pods y flujo de terminación de Endpoints
Si tus Pods incluyen uno o más contenedores sidecar (contenedores de inicialización con una política de reinicio Always), el kubelet retrasará el envío de la señal TERM a estos contenedores sidecar hasta que el último contenedor principal se haya terminado completamente.
Los contenedores sidecar serán eliminados en orden inverso al que se han definido en la especificación del Pod.
Esto asegura que los contenedores sidecar continúan sirviendo a los otros contenedores en el Pod hasta que ya no se necesiten.
Esto significa que la terminación lenta de un contenedor principal también retrasará la terminación de los contenedores sidecar.
Si el periodo de gracia expira antes que se complete el proceso de terminación, el Pod podría entrar en terminación forzada.
En este caso, todos los contenedores restantes en el Pod serán terminados simultáneamente con un periodo de gracia corto.
De forma similar, si el Pod tiene un hook preStop que excede el periodo de gracia de finalización, puede ocurrir una terminación de emergencia.
En general, si has usado hooks de preStop para controlar el orden de terminación sin contenedores sidecar, puedes quitarlos y permitir que el kubelet maneje la terminación de sidecars automáticamente.
Recolección de elementos no utilizados de los Pods
Cuando los Pods fallan,
los objetos API permanecen en el clúster hasta que un humano o el proceso de
controlador los elimine
explícitamente.
El recolector de elementos no utilizados (PodGC en inglés) es un controlador en
el plano de control que elimina los Pods que se han terminado (con una fase
de Succeeded o Failed), cuando el número de Pods excede el umbral
configurado (determinado por terminated-pod-gc-threshold en el controlador de
kube-controller-manager).
Esto evita la fuga de recursos mientras que los Pods se crean y se eliminan en
el tiempo.
Adicionalmente,
el PodGC limpia cualquier Pod que satisfaga cualquiera de las siguientes
condiciones:
Pods huérfanos - asociados a un Nodo que ya no existe,
Pods que están finalizando y no están programados,
Pods que están finalizando,
asociados a un nodo que no está listo, contaminado
con node.kubernetes.io/out-of-service,
cuando la condición NodeOutOfServiceVolumeDetach está habilitada.
Cuando la condición PodDisruptionCondition está habilitada,
además de limpiar los Pods,
el PodGC también los marcará como fallidos si están en una fase no terminal.
También, el PodGC agrega una condición de disrupción del Pod cuando realiza la limpieza de un Pod huérfano.
Mira condiciones de disrupción del Pod para más detalles.
Para información detallada sobre el estatus del contenedor del Pod en la API,
mira la documentación de referencia de la API que cubre el status del Pod.
3.4.1.3 - Contenedores de Inicialización
Esta página proporciona una descripción general de los contenedores de inicialización (init containers): contenedores especializados que se ejecutan
antes de los contenedores de aplicación en un Pod.
Los contenedores de inicialización pueden contener utilidades o scripts de instalación no presentes en una imagen de aplicación.
Tú puedes especificar contenedores de inicialización en la especificación del Pod junto con el arreglo de containers
(el cual describe los contenedores de aplicación).
Entendiendo los contenedores de inicialización
Un Pod puede tener múltiples contenedores
ejecutando aplicaciones dentro de él, pero también puede tener uno o más contenedores de inicialización
que se ejecutan antes de que se inicien los contenedores de aplicación.
Los contenedores de inicialización son exactamente iguales a los contenedores regulares excepto por:
Los contenedores de inicialización siempre se ejecutan hasta su finalización.
Cada contenedor de inicialiación debe completarse correctamente antes de que comience el siguiente.
Si el contenedor de inicialización de un Pod falla, kubelet reinicia repetidamente ese contenedor de inicialización hasta que tenga éxito.
Sin embargo, si el Pod tiene una restartPolicy de Never y un contenedor de inicialización falla durante el inicio de ese Pod, Kubernetes trata al Pod en general como fallido.
Para especificar un contenedor de inicialización para un Pod, agrega el campo initContainers en
la especificación del Pod,
como un arreglo de elementos container (similar al campo containers de aplicación y su contenido).
Consulta Container en la
referencia de API para más detalles.
El estado de los contenedores de inicialización se devuelve en el campo .status.initContainerStatuses
como un arreglo de los estados del contenedor (similar al campo .status.containerStatuses).
Diferencias con los contenedores regulares
Los contenedores de inicialización admiten todos los campos y características de los contenedores de aplicaciones,
incluidos los límites de recursos, los volúmenes y la configuración de seguridad. Sin embargo, las
solicitudes de recursos y los límites para un contenedor de inicialización se manejan de manera diferente,
como se documenta en Recursos.
Además, los contenedores de inicialización no admiten lifecycle, livenessProbe, readinessProbe o
startupProbe porque deben de ejecutarse hasta su finalización antes de que el Pod pueda estar listo.
Si especificas varios contenedores de inicialización para un Pod, kubelet ejecuta cada contenedor
de inicialización secuencialmente. Cada contenedor de inicialización debe tener éxito antes de que se pueda ejecutar el siguiente.
Cuando todos los contenedores de inicialización se hayan ejecutado hasta su finalización, kubelet inicializa
los contenedores de aplicación para el Pod y los ejecuta como de costumbre.
Usando contenedores de inicialización
Dado que los contenedores de inicialización tienen imágenes separadas de los contenedores de aplicaciones, estos
tienen algunas ventajas sobre el código relacionado de inicio:
Los contenedores de inicialización pueden contener utilidades o código personalizado para la configuración que no están presentes en una
imagen de aplicación. Por ejemplo, no hay necesidad de hacer una imagen FROM de otra imagen solo para usar una herramienta como
sed, awk, python o dig durante la instalación.
Los roles de constructor e implementador de imágenes de aplicación pueden funcionar de forma independiente sin
la necesidad de construir conjuntamente una sola imagen de aplicación.
Los contenedores de inicialización pueden ejecutarse con una vista diferente al sistema de archivos que los contenedores de aplicaciones en
el mismo Pod. En consecuencia, se les puede dar acceso a
Secrets a los que los contenedores de aplicaciones no pueden acceder.
Debido a que los contenedores de inicialización se ejecutan hasta su finalización antes de que se inicien los contenedores de aplicaciones, los contenedores de inicialización ofrecen
un mecanismo para bloquear o retrasar el inicio del contenedor de aplicación hasta que se cumplan una serie de condiciones previas. Una vez
que las condiciones previas se cumplen, todos los contenedores de aplicaciones de un Pod pueden iniciarse en paralelo.
Los contenedores de inicialización pueden ejecutar de forma segura utilidades o código personalizado que de otro modo harían a una imagen de aplicación
de contenedor menos segura. Si mantiene separadas herramientas innecesarias, puede limitar la superficie de ataque
a la imagen del contenedor de aplicación.
Ejemplos
A continuación, se muestran algunas ideas sobre cómo utilizar los contenedores de inicialización:
Esperar a que se cree un Service
usando una sola linea de comando de shell:
for i in {1..100}; do sleep 1; if nslookup myservice; thenexit 0; fi; done; exit1
Registrar este Pod con un servidor remoto desde la downward API con un comando como:
curl -X POST http://$MANAGEMENT_SERVICE_HOST:$MANAGEMENT_SERVICE_PORT/register -d 'instance=$(<POD_NAME>)&ip=$(<POD_IP>)'
Esperar algo de tiempo antes de iniciar el contenedor de aplicación con un comando como:
Colocar valores en un archivo de configuración y ejecutar una herramienta de plantilla para generar
dinámicamente un archivo de configuración para el contenedor de aplicación principal. Por ejemplo,
colocar el valor POD_IP en una configuración y generar el archivo de configuración
de la aplicación principal usando Jinja.
Contenedores de inicialización en uso
Este ejemplo define un simple Pod que tiene dos contenedores de inicialización.
El primero espera por myservice y el segundo espera por mydb. Una vez que ambos
contenedores de inicialización se completen, el Pod ejecuta el contenedor de aplicación desde su sección spec.
apiVersion:v1kind:Podmetadata:name:myapp-podlabels:app.kubernetes.io/name:MyAppspec:containers:- name:myapp-containerimage:busybox:1.28command:['sh','-c','echo ¡La aplicación se está ejecutando! && sleep 3600']initContainers:- name:init-myserviceimage:busybox:1.28command:['sh','-c',"until nslookup myservice.$(cat /var/run/secrets/kubernetes.io/serviceaccount/namespace).svc.cluster.local; do echo esperando a myservice; sleep 2; done"]- name:init-mydbimage:busybox:1.28command:['sh','-c',"until nslookup mydb.$(cat /var/run/secrets/kubernetes.io/serviceaccount/namespace).svc.cluster.local; do echo esperando a mydb; sleep 2; done"]
Puedes iniciar este Pod ejecutando:
kubectl apply -f myapp.yaml
El resultado es similar a esto:
pod/myapp-pod created
Y verificar su estado con:
kubectl get -f myapp.yaml
El resultado es similar a esto:
NAME READY STATUS RESTARTS AGE
myapp-pod 0/1 Init:0/2 0 6m
o para más detalles:
kubectl describe -f myapp.yaml
El resultado es similar a esto:
Name: myapp-pod
Namespace: default
[...]Labels: app.kubernetes.io/name=MyApp
Status: Pending
[...]Init Containers:
init-myservice:
[...] State: Running
[...] init-mydb:
[...] State: Waiting
Reason: PodInitializing
Ready: False
[...]Containers:
myapp-container:
[...] State: Waiting
Reason: PodInitializing
Ready: False
[...]Events:
FirstSeen LastSeen Count From SubObjectPath Type Reason Message
--------- -------- ----- ---- ------------- -------- ------ -------
16s 16s 1{default-scheduler } Normal Scheduled Successfully assigned myapp-pod to 172.17.4.201
16s 16s 1{kubelet 172.17.4.201} spec.initContainers{init-myservice} Normal Pulling pulling image "busybox" 13s 13s 1{kubelet 172.17.4.201} spec.initContainers{init-myservice} Normal Pulled Successfully pulled image "busybox" 13s 13s 1{kubelet 172.17.4.201} spec.initContainers{init-myservice} Normal Created Created container with docker id 5ced34a04634; Security:[seccomp=unconfined] 13s 13s 1{kubelet 172.17.4.201} spec.initContainers{init-myservice} Normal Started Started container with docker id 5ced34a04634
Para ver los logs de los contenedores de inicialización en este Pod ejecuta:
kubectl logs myapp-pod -c init-myservice # Inspecciona el primer contenedor de inicializaciónkubectl logs myapp-pod -c init-mydb # Inspecciona el segundo contenedor de inicialización
En este punto, estos contenedores de inicialización estarán esperando para descubrir los Servicios denominados
mydb y myservice.
Aquí hay una configuración que puedes usar para que aparezcan esos Servicios:
Luego verás que esos contenedores de inicialización se completan y que el Pod myapp-pod
pasa al estado Running:
kubectl get -f myapp.yaml
El resultado es similar a esto:
NAME READY STATUS RESTARTS AGE
myapp-pod 1/1 Running 0 9m
Este sencillo ejemplo debería servirte de inspiración para crear tus propios
contenedores de inicialización. ¿Qué es lo que sigue? contiene un enlace a un ejemplo más detallado.
Comportamiento detallado
Durante el inicio del Pod, kubelet retrasa la ejecución de contenedores de inicialización hasta que la red
y el almacenamiento estén listos. Después, kubelet ejecuta los contenedores de inicialización del Pod en el orden que
aparecen en la especificación del Pod.
Cada contenedor de inicialización debe salir correctamente antes de que
comience el siguiente contenedor. Si un contenedor falla en iniciar debido al tiempo de ejecución o
sale con una falla, se vuelve a intentar de acuerdo con el restartPolicy del Pod. Sin embargo,
si el restartPolicy del Pod se establece en Always, los contenedores de inicialización usan
el restartPolicy como OnFailure.
Un Pod no puede estar Ready sino hasta que todos los contenedores de inicialización hayan tenido éxito. Los puertos en un
contenedor de inicialización no se agregan a un Servicio. Un Pod que se está inicializando,
está en el estado de Pending, pero debe tener una condición Initialized configurada como falsa.
Si el Pod se reinicia o es reiniciado, todos los contenedores de inicialización
deben ejecutarse de nuevo.
Los cambios en la especificación del contenedor de inicialización se limitan al campo de la imagen del contenedor.
Alterar un campo de la imagen del contenedor de inicialización equivale a reiniciar el Pod.
Debido a que los contenedores de inicialización se pueden reiniciar, reintentar o volverse a ejecutar, el código del contenedor de inicialización
debe ser idempotente. En particular, el código que escribe en archivos en EmptyDirs
debe estar preparado para la posibilidad de que ya exista un archivo de salida.
Los contenedores de inicialización tienen todos los campos de un contenedor de aplicaciones. Sin embargo, Kubernetes
prohíbe el uso de readinessProbe porque los contenedores de inicialización no pueden
definir el readiness distinto de la finalización. Esto se aplica durante la validación.
Usa activeDeadlineSeconds en el Pod para prevenir que los contenedores de inicialización fallen por siempre.
La fecha límite incluye contenedores de inicialización.
Sin embargo, se recomienda utilizar activeDeadlineSeconds si el usuario implementa su aplicación
como un Job porque activeDeadlineSeconds tiene un efecto incluso después de que initContainer finaliza.
El Pod que ya se está ejecutando correctamente sería eliminado por activeDeadlineSeconds si lo estableces.
El nombre de cada aplicación y contenedor de inicialización en un Pod debe ser único; un
error de validación es arrojado para cualquier contenedor que comparta un nombre con otro.
Recursos
Dado el orden y la ejecución de los contenedores de inicialización, las siguientes reglas
para el uso de recursos se aplican:
La solicitud más alta de cualquier recurso o límite particular definido en todos los contenedores
de inicialización es la solicitud/límite de inicialización efectiva. Si algún recurso no tiene un
límite de recursos especificado éste se considera como el límite más alto.
La solicitud/límite efectiva para un recurso es la más alta entre:
la suma de todas las solicitudes/límites de los contenedores de aplicación, y
la solicitud/límite de inicialización efectiva para un recurso
La planificación es hecha con base en las solicitudes/límites efectivos, lo que significa
que los contenedores de inicialización pueden reservar recursos para la inicialización que no se utilizan
durante la vida del Pod.
El nivel de QoS (calidad de servicio) del nivel de QoS efectivo del Pod es el
nivel de QoS tanto para los contenedores de inicialización como para los contenedores de aplicación.
La cuota y los límites son aplicados con base en la solicitud y límite efectivos de Pod.
Los grupos de control de nivel de Pod (cgroups) se basan en la solicitud y el límite de Pod efectivos, al igual que el planificador de Kubernetes (kube-scheduler).
Razones de reinicio del Pod
Un Pod puede reiniciarse, provocando la re-ejecución de los contenedores de inicialización por las siguientes razones:
Se reinicia el contenedor de infraestructura del Pod. Esto es poco común y debería hacerlo alguien con acceso de root a los nodos.
Todos los contenedores en un Pod son terminados mientras restartPolicy esté configurado en Always,
forzando un reinicio y el registro de finalización del contenedor de inicialización se ha perdido debido a
la recolección de basura.
El Pod no se reiniciará cuando se cambie la imagen del contenedor de inicialización o cuando
se pierda el registro de finalización del contenedor de inicialización debido a la recolección de basura. Esto
se aplica a Kubernetes v1.20 y posteriores. Si estás utilizando una versión anterior de
Kubernetes, consulta la documentación de la versión que estás utilizando.
Esta guía es para los dueños de aplicaciones que quieren crear
aplicaciones con alta disponibilidad y que necesitan entender
qué tipos de interrupciones pueden suceder en los Pods.
También es para los administradores de clústeres que quieren aplicar acciones
automatizadas en sus clústeres, como actualizar o autoescalar los clústeres.
Interrupciones voluntarias e involuntarias
Los Pods no desaparecen hasta que algo (una persona o un controlador) los destruye
o hay problemas de hardware o software que son inevitables.
Nosotros llamamos a esos casos inevitables interrupciones involuntarias de
una aplicación. Algunos ejemplos:
Una falla en el hardware de la máquina física del nodo.
Un administrador del clúster borra una VM (instancia) por error.
El proveedor de la nube o el hipervisor falla y hace desaparecer la VM.
Un kernel panic.
El nodo desaparece del clúster por un problema de red que lo separa del clúster.
A excepción de la condición sin recursos suficientes, todas estas condiciones
deben ser familiares para la mayoría de los usuarios, no son específicas
de Kubernetes.
Nosotros llamamos a los otros casos interrupciones voluntarias. Estas incluyen
las acciones iniciadas por el dueño de la aplicación y aquellas iniciadas por el Administrador
del Clúster. Las acciones típicas de los dueños de la aplicación incluyen:
borrar el Deployment u otro controlador que maneja el Pod
actualizar el Deployment del Pod que causa un reinicio
borrar un Pod (por ejemplo, por accidente)
Las acciones del administrador del clúster incluyen:
Remover un Pod de un nodo para permitir que otra cosa pueda ingresar a ese nodo.
Estas acciones pueden ser realizadas directamente por el administrador del clúster, por
tareas automatizadas del administrador del clúster o por el proveedor del clúster.
Consulte al administrador de su clúster, a su proveedor de la nube o a la documentación de su distribución
para determinar si alguna de estas interrupciones voluntarias está habilitada en su clúster.
Si ninguna se encuentra habilitada, puede omitir la creación del presupuesto de Interrupción de Pods.
Precaución:
No todas las interrupciones voluntarias son consideradas por el presupuesto de interrupción de Pods. Por ejemplo,
borrar un Deployment o Pods que evitan el uso del presupuesto.
Tratando con las interrupciones
Estas son algunas de las maneras para mitigar las interrupciones involuntarias:
Replique su aplicación si usted necesita alta disponibilidad. (Aprenda sobre correr aplicaciones replicadas
stateless
y stateful
Incluso, para una alta disponibilidad mayor cuando se corren aplicaciones replicadas,
propague las aplicaciones por varios racks (usando
anti-affinity)
o usando zonas (si usa un clúster multi-zona.)
La frecuencia de las interrupciones voluntarias varía. En un clúster basico de Kubernetes, no hay
interrupciones voluntarias automáticas (solo el usuario las genera). Sin embargo, su administrador del clúster o proveedor de alojamiento
puede correr algun servicio adicional que pueda causar estas interrupciones voluntarias. Por ejemplo,
desplegando una actualización de software en los nodos puede causar interrupciones. También, algunas implementaciones
de clústers con autoescalamiento de nodos puede causar interrupciones para defragmentar o compactar los nodos.
Su administrador de clúster o proveedor de alojamiento debe tener documentado cuál es el nivel de interrupciones
voluntarias esperadas, sí es que las hay. Ciertas opciones de configuración, como ser
usar PriorityClasses
en las especificaciones de su Pod pueden también causar interrupciones voluntarias (o involuntarias).
Presupuesto de Interrupción de Pods
FEATURE STATE:Kubernetes v1.21 [stable]
Kubernetes ofrece carácteristicas para ayudar a ejecutar aplicaciones con alta disponibliidad, incluso cuando usted
introduce interrupciones voluntarias frecuentes.
Como dueño de la aplicación, usted puede crear un presupuesto de interrupción de Pods (PDB por sus siglas en inglés) para cada aplicación.
Un PDB limita el numero de Pods de una aplicación replicada, que estan caídos de manera simultánea por
interrupciones voluntarias. Por ejemplo, una aplicación basada en quórum puede
asegurarse que el número de réplicas corriendo nunca es menor al
número necesitado para obtener el quórum. Una web de tipo front end puede querer
asegurarse que el número de réplicas atendiendo al tráfico nunca puede caer bajo un cierto
porcentaje del total.
Los administradores del clúster y proveedores de hosting pueden usar herramientas que
respeten el presupuesto de interrupción de Pods utilizando la API de Desalojo
en vez de directamente borrar Pods o Deployments.
Por ejemplo, el subcomando kubectl drain le permite marcar un nodo a un modo fuera de
servicio. Cuando se ejecuta kubectl drain, la herramienta trata de quitar a todos los Pods en
el nodo que se esta dejando fuera de servicio. La petición de desalojo que kubectl solicita en
su nombre puede ser temporalmente denegado, entonces la herramienta periodicamente reintenta todas las
peticiones fallidas hasta que todos los Pods en el nodo afectado son terminados o hasta que el tiempo de espera,
que puede ser configurado, es alcanzado.
Un PDB especifica el número de réplicas que una aplicación puede tolerar, relativo a cuantas
se pretende tener. Por ejemplo, un Deployment que tiene un .spec.replicas: 5 se
supone que tiene 5 Pods en cualquier momento. Si su PDB permite tener 4 a la vez,
entonces la API de Desalojo va a permitir interrupciones voluntarias de uno (pero no de dos) Pod a la vez.
El grupo de Pods que comprende a la aplicación está especificado usando una etiqueta selectora, la misma
que es usada por el controlador de aplicación (deployment, stateful-set, etc).
El número de Pods "deseado" es calculado a partir de .spec.replicas del recurso de Workload
que es manejado para esos Pods. El plano de control descubre el recurso Workload perteneciente al
examinar las .metadata.ownerReferences del Pod.
Las Interrupciones Involuntarias no pueden ser prevenidas por los PDB; pero si
son contabilizadas a partir de este presupuesto.
Los Pods que son borrados o no están disponibles debido a una actualización continua de una aplicación forman parte del presupuesto de interrupciones, pero los recursos Workload (como los Deployments y StatefulSet)
no están limitados por los PDBs cuando se hacen actualizaciones continuas. En cambio, la administración de fallas
durante la actualización de la aplicación está configurada en la especificación para este recurso Workload específico.
Cuando un Pod es eliminado usando la API de desalojo, este es
terminado correctamente, haciendo honor al
terminationGracePeriodSeconds configurado en su PodSpec.
Ejemplo de Presupuesto de Interrupción de POD
Considere un clúster con 3 nodos, nodo-1 hasta nodo-3.
El clúster está ejecutando varias aplicaciones. Uno de ellos tiene 3 replicas, que llamaremos
pod-a, pod-b, y pod-c. Otro Pod no relacionado y sin PDB, llamado pod-x, también se muestra.
Inicialmente los Pods están distribuidos de esta manera:
nodo-1
nodo-2
nodo-3
pod-a available
pod-b available
pod-c available
pod-x available
Los 3 Pods son parte de un Deployment, ellos colectivamente tienen un PDB que requiere
que por lo menos 2 de los 3 Pods estén disponibles en todo momento.
Por ejemplo, supongamos que el administrador del clúster quiere reiniciar para actualizar el kernel y solucionar un error.
El administrador del clúster primero intenta drenar el nodo-1 usando el comando kubectl drain.
La herramienta intenta drenar los Pods pod-a y pod-x. Esto tiene éxito inmediatamente.
Ambos Pods pasan al estado terminating al mismo tiempo.
Esto pone al clúster en el siguiente estado:
nodo-1 draining
nodo-2
nodo-3
pod-a terminating
pod-b available
pod-c available
pod-x terminating
El Deployment detecta que uno de los Pods está terminando, entonces crea un reemplazo
llamado pod-d. Dado que el nodo-1 está bloqueado, el pod se inicia en otro nodo. Además,
se crea el pod pod-y como reemplazo de pod-x.
(Nota: para un StatefulSet, pod-a, que debería llamarse algo como pod-0, debe terminar completamente antes de su reemplazo, que también se llama pod-0 pero tiene un UID diferente, puede ser creado. De lo contrario, el ejemplo también se aplica a un StatefulSet).
Ahora el clúster está en este estado:
nodo-1 draining
nodo-2
nodo-3
pod-a terminating
pod-b available
pod-c available
pod-x terminating
pod-d starting
pod-y starting
En algún momento, los Pods terminan y el clúster se ve así:
nodo-1 drained
nodo-2
nodo-3
pod-b available
pod-c available
pod-d starting
pod-y starting
En este estado, si un administrador del clúster impaciente intenta drenar el nodo-2 o el
nodo-3, el comando de drenado será bloqueado, porque solo hay 2 Pods disponibles para
el Deployment y el PDB requiere al menos 2. Después de un tiempo, pod-d y pod-y están disponibles.
El estado del clúster ahora se ve así:
nodo-1 drained
nodo-2
nodo-3
pod-b available
pod-c available
pod-d available
pod-y available
Ahora, el administrador del clúster drena el nodo-2.
El comando de drenado intentará drenar los 2 Pods en algún orden, digamos
primero pod-b y luego pod-d. Tendrá éxito en eliminar pod-b.
Pero cuando intente drenar pod-d, será rechazado porque eso dejará
solo un Pod disponible para el Deployment.
El Deployment crea un reemplazo para pod-b llamado pod-e.
Dado que no hay suficientes recursos disponibles en el clúster para programar
pod-e, el drenado será bloqueado nuevamente. El clúster terminará en este
estado:
nodo-1 drained
nodo-2
nodo-3
no node
pod-b terminating
pod-c available
pod-e pending
pod-d available
pod-y available
Ahora, el administrador del clúster necesita
agregar un nuevo nodo en el clúster para continuar con la actualización.
Usted puede ver cómo Kubernetes varía la tasa a la que ocurren las interrupciones,
según:
cuántas réplicas necesita una aplicación
cuánto tiempo lleva apagar una instancia correctamente
cuánto tiempo lleva iniciar una nueva instancia
el tipo de controlador
la capacidad de recursos del clúster
Separación entre el dueño del Clúster y los roles de dueños de la Aplicación
Muchas veces es útil pensar en el Administrador del Clúster
y al dueño de la aplicación como roles separados con conocimiento limitado
el uno del otro. Esta separación de responsabilidades
puede tener sentido en estos escenarios:
Cuando hay muchos equipos con aplicaciones compartiendo un clúster de Kubernetes y
hay una especialización natural de roles
Cuando se usa una herramienta de terceros o un servicio para automatizar el control del clúster
El presupuesto de interrupción de Pods respalda esta separación de roles, proporcionando
una interfaz entre los roles.
Si no hay tal separación de responsabilidades en la organización,
es posible que no sea necesario el Presupuesto de Interrupción de Pods.
Cómo realizar Acciones Disruptivas en el Clúster
Si usted es el Administrador del Clúster y necesitas realizar una acción disruptiva en todos
los nodos del clúster, como una actualización de nodo o de software, estas son algunas de las opciones:
Aceptar el tiempo de inactividad mientras dura la actualización.
Cambiar a otra réplica completa del clúster.
No hay tiempo de inactividad, pero puede ser costoso tener duplicados los nodos
y también se requiere esfuerzo humano para orquestar dicho cambio.
Diseñar la tolerancia a fallas en la aplicación y usar PDBs.
No hay tiempo de inactividad.
Duplicación mínima de recursos.
Permite mucha más automatización en la administración del clúster.
Diseñar aplicaciones para tolerar fallas es complicado, pero el trabajo para tolerar interrupciones
involuntarias a menudo vale la pena en comparación con el trabajo de admitir autoescalado y tolerar
interrupciones involuntarias.
Aprenda sobre actualizar un Deployment
incluyendo los pasos para mantener su disponibilidad durante la actualización.
3.4.1.5 - Containers Efímeros
FEATURE STATE:Kubernetes v1.31 [alpha]
Esta página proporciona una descripción general de los Containers efímeros: un tipo especial de Container
que se ejecuta temporalmente en un Pod ya existente para cumplir las
acciones iniciadas por el usuario, como por ejemplo, la solución de problemas. En vez de ser utilizadas para
crear aplicaciones, los Containers efímeros se utilizan para examinar los servicios.
Advertencia:
Los Containers efímeros se encuentran en una fase alfa inicial y no son aptos para clústers
de producción. Es de esperar que esta característica no funcione en algunas situaciones, por
ejemplo, al seleccionar los Namespaces de un Container. De acuerdo con la Política de
Deprecación de Kubernetes, esta característica
alfa puede variar significativamente en el futuro o ser eliminada por completo.
Entendiendo los Containers efímeros
Pods son el componente fundamental de las
aplicaciones de Kubernetes. Puesto que los Pods están previstos para ser desechables
y reemplazables, no se puede añadir un Container a un Pod una vez creado. Sin embargo, por lo
general se eliminan y se reemplazan los Pods de manera controlada utilizando
Deployments.
En ocasiones es necesario examinar el estado de un Pod existente, como por ejemplo,
para poder solucionar un error difícil de reproducir. Puede ejecutar en estos casos
un Container efímero en un Pod ya existente para examinar su estado y para ejecutar
comandos de manera arbitraria.
Qué es un Container efímero?
Los Containers efímeros se diferencian de otros Containers en que no garantizan ni los
recursos ni la ejecución, y en que nunca se reiniciarán automáticamente, de modo que no
son aptos para la construcción de aplicaciones. Los Containers efímeros se describen
usando la misma ContainerSpec que los Containers regulares, aunque muchos campos son
incompatibles y no están habilitados para los Containers efímeros.
Los Containers efímeros no pueden tener puertos, por lo que campos como ports,
livenessProbe, readinessProbe no están habilitados.
Las asignaciones de recursos del Pod son inmutables, por lo que no esta habilitado
configurar "resources".
Para obtener una lista completa de los campos habilitados, consulte la documentación
de referencia [EphemeralContainer] (/docs/reference/generated/kubernetes-api/v1.31/#ephemeralcontainer-v1-core).
En vez de añadirlos de forma directa al pod.spec, los Containers efímeros se crean usando un
controlador especial de la API, ephemeralcontainers, por lo tanto no es posible añadir un
Container efímero utilizando kubectl edit.
Al igual en el caso de los Containers regulares, no se puede modificar o remover un Container
efímero después de haberlo agregado a un Pod.
Casos de uso para los Containers efímeros
Los Containers efímeros resultan útiles para la solución interactiva de incidencias cuando
kubectl exec es insuficiente tanto porque un container se ha caído, como porque la imagen de un
Container no incluye las utilidades de depuración.
En particular, las imágenes distroless
le permiten desplegar imágenes de Containers mínimos que disminuyen la superficie de ataque
y la exposición a errores y vulnerabilidades. Ya que las imágenes distroless no contienen un
shell ni ninguna utilidad de depuración, resulta difícil solucionar los problemas de las imágenes
distroless usando solamente kubectl exec.
Cuando utilice Containers efímeros, es conveniente habilitar el proceso Namespace de uso
compartido para poder ver los
procesos en otros containers.
Ejemplos
Nota:
Los ejemplos de esta sección requieren que los EphemeralContainersfeature
gate estén habilitados
y que tanto el cliente como el servidor de Kubernetes tengan la version v1.16 o posterior.
En los ejemplos de esta sección muestran la forma en que los Containers efímeros se
presentan en la API. Los usuarios normalmente usarían un plugin kubectl para la solución
de problemas que automatizaría estos pasos.
Los Containers efímeros son creados utilizando el subrecurso ephemeralcontainers del Pod,
que puede ser visto utilizando kubectl --raw. En primer lugar describa el Container
efímero a añadir como una lista de EphemeralContainers:
Se puede conectar al nuevo Container efímero usando kubectl attach:
kubectl attach -it example-pod -c debugger
Si el proceso Namespace de uso compartido está habilitado, se pueden visualizar los procesos de todos los Containers de ese Pod.
Por ejemplo, después de haber conectado, ejecute ps en el debugger del container:
ps auxww
La respuesta es semejante a:
PID USER TIME COMMAND
1 root 0:00 /pause
6 root 0:00 nginx: master process nginx -g daemon off;
11 101 0:00 nginx: worker process
12 101 0:00 nginx: worker process
13 101 0:00 nginx: worker process
14 101 0:00 nginx: worker process
15 101 0:00 nginx: worker process
16 101 0:00 nginx: worker process
17 101 0:00 nginx: worker process
18 101 0:00 nginx: worker process
19 root 0:00 /pause
24 root 0:00 sh
29 root 0:00 ps auxww
3.4.2 - Controladores
3.4.2.1 - ReplicaSet
El objeto de un ReplicaSet es el de mantener un conjunto estable de réplicas de Pods ejecutándose
en todo momento. Así, se usa en numerosas ocasiones para garantizar la disponibilidad de un
número específico de Pods idénticos.
Cómo funciona un ReplicaSet
Un ReplicaSet se define con campos, incluyendo un selector que indica cómo identificar a los Pods que puede adquirir,
un número de réplicas indicando cuántos Pods debería gestionar, y una plantilla pod especificando los datos de los nuevos Pods
que debería crear para conseguir el número de réplicas esperado. Un ReplicaSet alcanza entonces su propósito
mediante la creación y eliminación de los Pods que sea necesario para alcanzar el número esperado.
Cuando un ReplicaSet necesita crear nuevos Pods, utiliza su plantilla Pod.
El enlace que un ReplicaSet tiene hacia sus Pods es a través del campo del Pod denominado metadata.ownerReferences,
el cual indica qué recurso es el propietario del objeto actual. Todos los Pods adquiridos por un ReplicaSet tienen su propia
información de identificación del ReplicaSet en su campo ownerReferences. Y es a través de este enlace
cómo el ReplicaSet conoce el estado de los Pods que está gestionando y actúa en consecuencia.
Un ReplicaSet identifica los nuevos Pods a adquirir usando su selector. Si hay un Pod que no tiene OwnerReference
o donde OwnerReference no es un controlador, pero coincide con el selector del ReplicaSet,
este será inmediatamente adquirido por dicho ReplicaSet.
Cuándo usar un ReplicaSet
Un ReplicaSet garantiza que un número específico de réplicas de un pod se está ejecutando en todo momento.
Sin embargo, un Deployment es un concepto de más alto nivel que gestiona ReplicaSets y
proporciona actualizaciones de forma declarativa de los Pods junto con muchas otras características útiles.
Por lo tanto, se recomienda el uso de Deployments en vez del uso directo de ReplicaSets, a no ser
que se necesite una orquestración personalizada de actualización o no se necesite las actualizaciones en absoluto.
En realidad, esto quiere decir que puede que nunca necesites manipular los objetos ReplicaSet:
en vez de ello, usa un Deployment, y define tu aplicación en la sección spec.
apiVersion:apps/v1kind:ReplicaSetmetadata:name:frontendlabels:app:guestbooktier:frontendspec:# modifica las réplicas según tu caso de usoreplicas:3selector:matchLabels:tier:frontendtemplate:metadata:labels:tier:frontendspec:containers:- name:php-redisimage:gcr.io/google_samples/gb-frontend:v3
Si guardas este manifiesto en un archivo llamado frontend.yaml y lo lanzas en un clúster de Kubernetes,
se creará el ReplicaSet definido y los Pods que maneja.
También puedes comprobar el estado del replicaset:
kubectl describe rs/frontend
Y verás una salida parecida a la siguiente:
Name: frontend
Namespace: default
Selector: tier=frontend,tier in (frontend)Labels: app=guestbook
tier=frontend
Annotations: <none>
Replicas: 3 current / 3 desired
Pods Status: 3 Running / 0 Waiting / 0 Succeeded / 0 Failed
Pod Template:
Labels: app=guestbook
tier=frontend
Containers:
php-redis:
Image: gcr.io/google_samples/gb-frontend:v3
Port: 80/TCP
Requests:
cpu: 100m
memory: 100Mi
Environment:
GET_HOSTS_FROM: dns
Mounts: <none>
Volumes: <none>
Events:
FirstSeen LastSeen Count From SubobjectPath Type Reason Message
--------- -------- ----- ---- ------------- -------- ------ -------
1m 1m 1{replicaset-controller } Normal SuccessfulCreate Created pod: frontend-qhloh
1m 1m 1{replicaset-controller } Normal SuccessfulCreate Created pod: frontend-dnjpy
1m 1m 1{replicaset-controller } Normal SuccessfulCreate Created pod: frontend-9si5l
Y por último, puedes comprobar los Pods que ha arrancado:
kubectl get Pods
Deberías ver la información de cada Pod similar a:
NAME READY STATUS RESTARTS AGE
frontend-9si5l 1/1 Running 0 1m
frontend-dnjpy 1/1 Running 0 1m
frontend-qhloh 1/1 Running 0 1m
También puedes verificar que la referencia de propietario de dichos pods está puesta al ReplicaSet frontend.
Para ello, obtén el yaml de uno de los Pods ejecutándose:
kubectl get pods frontend-9si5l -o yaml
La salida será parecida a esta, donde la información sobre el ReplicaSet aparece en el campo ownerReferences de los metadatos:
Aunque puedes crear Pods simples sin problemas, se recomienda encarecidamente asegurarse de que dichos Pods no tienen
etiquetas que puedan coincidir con el selector de alguno de tus ReplicaSets.
La razón de esta recomendación es que un ReplicaSet no se limita a poseer los Pods
especificados en su plantilla -- sino que puede adquirir otros Pods como se explicó en secciones anteriores.
Toma el ejemplo anterior del ReplicaSet frontend, y los Pods especificados en el siguiente manifiesto:
Como estos Pods no tienen un Controlador (o cualquier otro objeto) como referencia de propietario
y como además su selector coincide con el del ReplicaSet frontend, este último los terminará adquiriendo de forma inmediata.
Supón que creas los Pods después de que el ReplicaSet frontend haya desplegado los suyos
para satisfacer su requisito de cuenta de réplicas:
Verás que el ReplicaSet ha adquirido dichos Pods y simplemente ha creado tantos nuevos
como necesarios para cumplir con su especificación hasta que el número de
sus nuevos Pods y los originales coincidan con la cuenta deseado. Al obtener los Pods:
kubectl get Pods
Veremos su salida:
NAME READY STATUS RESTARTS AGE
frontend-pxj4r 1/1 Running 0 5s
pod1 1/1 Running 0 13s
pod2 1/1 Running 0 13s
De esta forma, un ReplicaSet puede poseer un conjunto no homogéneo de Pods
Escribir un manifiesto de ReplicaSet
Al igual que con el esto de los objeto de la API de Kubernetes, un ReplicaSet necesita los campos
apiVersion, kind, y metadata. Para los ReplicaSets, el tipo es siempre ReplicaSet.
En la versión 1.9 de Kubernetes, la versión apps/v1 de la API en un tipo ReplicaSet es la versión actual y está habilitada por defecto.
La versión apps/v1beta2 de la API se ha desaprobado.
Consulta las primeras líneas del ejemplo frontend.yaml como guía.
El campo .spec.template es una plantilla pod que es
también necesita obligatoriamente tener etiquetas definidas. En nuestro ejemplo frontend.yaml teníamos una etiqueta: tier: frontend.
Lleva cuidado de que no se entremezcle con los selectores de otros controladores, no sea que traten de adquirir este Pod.
Para el campo de regla de reinicio de la plantilla,
.spec.template.spec.restartPolicy, el único valor permitido es Always, que es el valor predeterminado.
Selector de Pod
El campo .spec.selector es un selector de etiqueta.
Como se explicó anteriormente, estas son las etiquetas que se usan para
identificar los Pods potenciales a adquirir. En nuestro ejemplo frontend.yaml, el selector era:
matchLabels:
tier: frontend
El el ReplicaSet, .spec.template.metadata.labels debe coincidir con spec.selector, o será
rechazado por la API.
Nota:
Cuando 2 ReplicaSets especifican el mismo campo .spec.selector, pero los campos
.spec.template.metadata.labels y .spec.template.spec diferentes, cada ReplicaSet
ignora los Pods creados por el otro ReplicaSet.
Réplicas
Puedes configurar cuántos Pods deberían ejecutarse de forma concurrente indicando el campo .spec.replicas.
El ReplicaSet creará/eliminará sus Pods para alcanzar este número.
Si no indicas el valor del campo .spec.replicas, entonces por defecto se inicializa a 1.
Trabajar con ReplicaSets
Eliminar un ReplicaSet y sus Pods
Para eliminar un ReplicaSet y todos sus Pods, utiliza el comando kubectl delete.
El Recolector de basura eliminará automáticamente
todos los Pods subordinados por defecto.
Cuando se usa la API REST o la librería client-go, se debe poner el valor de propagationPolicy a Background o
Foreground en la opción -d.
Por ejemplo:
Se puede eliminar un ReplicaSet sin afectar a ninguno de sus Pods usando el comando kubectl delete con la opción --cascade=false.
Cuando se usa la API REST o la librería client-go, se debe poner propagationPolicy a Orphan.
Por ejemplo:
Una vez que se ha eliminado el original, se puede crear un nuevo ReplicaSet para sustituirlo.
Mientras el viejo y el nuevo .spec.selector sean el mismo, el nuevo adoptará a los viejos Pods.
Sin embargo, no se esforzará en conseguir que los Pods existentes coincidan con una plantilla pod nueva, diferente.
Para actualizar dichos Pods a la nueva especificación de forma controlada,
usa una actualización en línea.
Aislar Pods de un ReplicaSet
Es posible aislar Pods de un ReplicaSet cambiando sus etiquetas. Esta técnica puede usarse
para eliminar Pods de un servicio para poder depurar, recuperar datos, etc. Los Pods
que se eliminar de esta forma serán sustituidos de forma automática (siempre que el
número de réplicas no haya cambiado).
Escalar un ReplicaSet
Se puede aumentar o reducir fácilmente un ReplicaSet simplemente actualizando el campo .spec.replicas.
El controlador del ReplicaSet se asegura de que el número deseado de Pods con un selector
de etiquetas coincidente está disponible y operacional.
ReplicaSet como blanco de un Horizontal Pod Autoscaler
Un ReplicaSet puede también ser el blanco de un
Horizontal Pod Autoscalers (HPA). Esto es,
un ReplicaSet puede auto-escalarse mediante un HPA. Aquí se muestra un ejemplo de HPA dirigido
al ReplicaSet que creamos en el ejemplo anterior.
Si guardas este manifiesto en un archivo hpa-rs.yaml y lo lanzas contra el clúster de Kubernetes,
debería crear el HPA definido que auto-escala el ReplicaSet destino dependiendo del uso
de CPU de los Pods replicados.
Alternativamente, puedes usar el comando kubectl autoscale para conseguir el mismo objetivo
(¡y mucho más fácil!)
kubectl autoscale rs frontend --max=10
Alternativas al ReplicaSet
Deployment (recomendado)
UnDeployment es un objeto que puede poseer ReplicaSets
y actualizar a estos y a sus Pods mediante actualizaciones en línea declarativas en el servidor.
Aunque que los ReplicaSets puede usarse independientemente, hoy en día se usan principalmente a través de los Deployments
como el mecanismo para orquestrar la creación, eliminación y actualización de los Pods.
Cuando usas Deployments no tienes que preocuparte de gestionar los ReplicaSets que crean.
Los Deployments poseen y gestionan sus ReplicaSets.
Por tanto, se recomienda que se use Deployments cuando se quiera ReplicaSets.
Pods simples
A diferencia del caso en que un usuario creaba Pods de forma directa, un ReplicaSet sustituye los Pods que se eliminan
o se terminan por la razón que sea, como en el caso de un fallo de un nodo o
una intervención disruptiva de mantenimiento, como una actualización de kernel.
Por esta razón, se recomienda que se use un ReplicaSet incluso cuando la aplicación
sólo necesita un único Pod. Entiéndelo de forma similar a un proceso supervisor,
donde se supervisa múltiples Pods entre múltiples nodos en vez de procesos individuales
en un único nodo. Un ReplicaSet delega los reinicios del contenedor local a algún agente
del nodo (por ejemplo, Kubelet o Docker).
Job
Usa un Job en vez de un ReplicaSet para
aquellos Pods que se esperan que terminen por ellos mismos (esto es, trabajos por lotes).
DaemonSet
Usa un DaemonSet en vez de un ReplicaSet para aquellos
Pods que proporcionan funcionalidad a nivel de servidor, como monitorización de servidor o
logging de servidor. Estos Pods tienen un ciclo de vida asociado al del servidor mismo:
el Pod necesita ejecutarse en el servidor antes de que los otros Pods comiencen, y es seguro
que terminen cuando el servidor esté listo para ser reiniciado/apagado.
ReplicationController
Los ReplicaSets son los sucesores de los ReplicationControllers.
Los dos sirven al mismo propósito, y se comportan de forma similar, excepto porque un ReplicationController
no soporta los requisitos del selector basado en conjunto, como se describe en la guía de usuario de etiquetas.
Por ello, se prefiere los ReplicaSets a los ReplicationControllers.
3.4.2.2 - ReplicationController
Nota:
hoy en día la forma recomendada de configurar la replicación es con un Deployment que configura un ReplicaSet.
Un ReplicationController garantiza que un número determinado de réplicas se estén ejecutando
en todo momento. En otras palabras, un ReplicationController se asegura que un pod o un conjunto homogéneo de pods
siempre esté arriba y disponible.
Cómo Funciona un ReplicationController
Si hay muchos pods, el ReplicationController termina los pods extra. Si hay muy pocos, el
ReplicationController arranca más pods. A difrencia de los pods creados manualmente, los pods mantenidos por un
ReplicationController se sustituyen de forma automática si fallan, se borran, o se terminan.
Por ejemplo, tus pods se re-crean en un nodo durante una intervención disruptiva de mantenimiento como una actualización del kernel.
Por esta razón, deberías usar un ReplicationController incluso cuando tu aplicación sólo necesita
un único pod. Un ReplicationController es parecido a un supervisor de procesos,
pero en vez de supervisar procesos individuales en un único nodo,
el ReplicationController supervisa múltiples pods entre múltiples nodos.
A menudo nos referimos a un ReplicationController de forma abreviada como "rc" o "rcs", así como
atajo en los comandos de kubectl.
Un caso simple es crear un objeto ReplicationController para ejecutar de manera fiable una instancia
de un Pod indefinidamente. Un caso de uso más complejo es ejecutar varias réplicas idénticas
de un servicio replicado, como los servidores web.
Ejecutar un ejemplo de ReplicationController
Esta configuración de un ReplicationController de ejemplo ejecuta tres copias del servidor web nginx.
Comprueba el estado del ReplicationController con este comando:
kubectl describe replicationcontrollers/nginx
Name: nginx
Namespace: default
Selector: app=nginx
Labels: app=nginx
Annotations: <none>
Replicas: 3 current / 3 desired
Pods Status: 0 Running / 3 Waiting / 0 Succeeded / 0 Failed
Pod Template:
Labels: app=nginx
Containers:
nginx:
Image: nginx
Port: 80/TCP
Environment: <none>
Mounts: <none>
Volumes: <none>
Events:
FirstSeen LastSeen Count From SubobjectPath Type Reason Message
--------- -------- ----- ---- ------------- ---- ------ -------
20s 20s 1 {replication-controller } Normal SuccessfulCreate Created pod: nginx-qrm3m
20s 20s 1 {replication-controller } Normal SuccessfulCreate Created pod: nginx-3ntk0
20s 20s 1 {replication-controller } Normal SuccessfulCreate Created pod: nginx-4ok8v
Como se puede observar, se han creado tres pods, pero ninguno se está ejecutándose todavía,
puede que porque la imagen todavía se está descargando.
Unos momentos después, el mismo comando puede que muestre:
Para listar todos los pods que pertenecen al ReplicationController de forma legible,
puedes usar un comando como el siguiente:
pods=$(kubectl get pods --selector=app=nginx --output=jsonpath={.items..metadata.name})echo$pods
nginx-3ntk0 nginx-4ok8v nginx-qrm3m
Como se puede ver, el selector es el mismo que el selector del ReplicationController (mostrado en la salida de
kubectl describe), y con una forma diferente a lo definido en el archivo replication.yaml.
La opción --output=jsonpath especifica una expresión que simplemente muestra el nombre
de cada pod en la lista devuelta.
Escribir una especificación de ReplicationController
Al igual que con el resto de configuraciones de Kubernetes, un ReplicationController necesita los campos apiVersion, kind, y metadata.
Para información general acerca del trabajo con archivos de configuración, ver la gestión de objetos.
Un ReplicationController también necesita un sección .spec.
Plantilla Pod
El campo .spec.template es el único campo requerido de .spec.
El campo .spec.template es una plantilla pod.
Tiene exactamente el mismo esquema que un pod, excepto por el hecho de que está anidado y no tiene los campos apiVersion ni kind.
Además de los campos obligatorios de un Pod, una plantilla pod de un ReplicationController debe especificar las etiquetas apropiadas
y la regla de reinicio apropiada. En el caso de las etiquetas, asegúrate que no se entremezclan con otros controladores. Ver el selector de pod.
Para los reinicios locales de los contenedores, los ReplicationControllers delegan en los agentes del nodo,
por ejmplo el Kubelet o Docker.
Etiquetas en los ReplicationController
los ReplicationController puede tener sus propias (.metadata.labels). Normalmente, se indicaría dichas etiquetas
con los mismos valores que el campo .spec.template.metadata.labels; si el campo .metadata.labels no se indica,
entonces se predetermina al valor de .spec.template.metadata.labels. Sin embargo, se permite que sean diferentes,
y el valor de .metadata.labels no afecta al comportamiento del ReplicationController.
Selector de Pod
El campo .spec.selector es un selector de etiqueta. Un ReplicationController
gestiona todos los pods con etiquetas que coinciden con el selector. No distingue entre
pods que creó o eliminó, y pods que otra persona o proceso creó o eliminó. Esto permite sustituir al ReplicationController sin impactar a ninguno de sus pods que se esté ejecutando.
Si se indica, el valor de .spec.template.metadata.labels debe ser igual al de .spec.selector, o será rechazado por la API.
Si no se indica el valor de .spec.selector, se tomará como predeterminado el de .spec.template.metadata.labels.
Tampoco deberías crear ningún pod cuyas etiquetas coincidan con las de este selector, ni directamente con
otro ReplicationController, ni con otro controlador como un Job. Si lo haces, el
ReplicationController piensa que el creó también los otros pods. Kubernetes no te impide hacerlo.
Si al final terminas con múltiples controladores que tienen selectores que se entremezclan,
tendrás que gestionar la eliminación tú mismo (ver abajo).
Múltiples Réplicas
Puedes configurar cuántos pods deberían ejecutarse de forma concurrente poniendo el valor de .spec.replicas al número
de pods que te gustaría tener ejecutándose a la vez. El número de ejecuciones en cualquier momento puede que sea superior
o inferior, dependiendo de si las réplicas se han incrementado o decrementado, o si un pod se ha apagado de forma controlada,
y su sustituto arranca más pronto.
Si no se indica el valor de .spec.replicas, entonces se predetermina a 1.
Trabajar con ReplicationControllers
Eliminar un ReplicationController y sus Pods
Para eliminar un ReplicationController y todos sus pods, usa el comando kubectl delete. Kubectl reducirá el ReplicationController a cero y esperará
que elimine cada pod antes de eliminar al ReplicationController mismo. Si este comando kubectl
se interrumpe, puede ser reiniciado.
Cuando uses la API REST o la librería Go, necesitas realizar los pasos de forma explícita (reducir las réplicas a cero,
esperar a que se eliminen los pods, y entonces eliminar el ReplicationController).
Eliminar sólo el ReplicationController
Puedes eliminar un ReplicationController sin impactar a ninguno de sus Pods.
Usando kubectl, indica la opción --cascade=false en el comando kubectl delete.
Cuando uses la API REST o la librería Go, simplemente elimina objeto ReplicationController.
Una vez que el objeto original se ha eliminado, puedes crear un nuevo ReplicationController para sustituirlo.
Mientras el viejo y el nuevo valor del .spec.selector sea el mismo, el nuevo adoptará a los viejos pods.
Sin embargo, no se molestará en hacer que los pods actuales coincidan con una plantilla pod nueva, diferente.
Para actualizar los pods con una nueva especificación de forma controlada, utiliza la actualización en línea.
Aislar pods de un ReplicationController
Se puede aislar Pods del conjunto destino de un ReplicationController cambiando sus etiquetas.
Esta técnica puede usarse para eliminar pods de un servicio para poder depurarlos, recuperar datos, etc.
Los Pods que se eliminan de esta forma serán sustituidos de forma automática (asumiendo que el número de réplicas no ha cambiado tampoco).
Patrones comunes de uso
Reprogramación
Como se comentó arriba, cuando tienes 1 pod que quieres mantener ejecutándose, o 1000, un ReplicationController se asegura de que el número indicado de pods exista,
incluso si falla un nodo o se termina algún pod (por ejemplo, debido a alguna acción de otro agente de control).
Escalado
El ReplicationController facilita el escalado del número de réplicas tanto para su aumento como para su disminución,
bien manualmente o mediante un agente de auto-escalado, simplemente actualizando el campo replicas.
Actualizaciones en línea
El ReplicationController se ha diseñado para facilitar las actualizaciones en línea de un servicio mediante la sustitución de sus pods uno por uno.
Cómo se explicó en #1353, la estrategia recomendada es crear un nuevo ReplicationController con 1 réplica,
escalar el nuevo (+1) y el viejo (-1) controlador uno por uno, y entonces eliminar el viejo controlador una vez que alcanza las 0 réplicas.
Esto actualiza de forma predecible el conjunto de pods independientemente de que se produzcan fallos inesperados.
De forma ideal, el controlador de actualización en línea tendrá en cuenta si la aplicación está lista, y
se asegurará de que un número suficiente de pods está en servicio en todo momento.
Los dos ReplicationControllers necesitarán crear pods con al menos una etiqueta diferenciadora, como la etiqueta de imagen del contenedor primario del pod,
ya que las actualizaciones de imagen son las que normalmente desencadenan las actualizaciones en línea.
Además de llevar a cabo múltiples despliegues de una aplicación cuando una actualización en línea está en progreso,
es común ejecutar varios despliegues durante un período extendido de tiempo, o incluso de forma contínua, usando múltiples operaciones de despliegue. Dichas operaciones se diferenciarían por etiquetas.
Por ejemplo, un servicio puede que exponga todos los pods con etiquetas tier in (frontend), environment in (prod). Ahora digamos que tenemos 10 pods replicados que forman este grupo.
Pero queremos poder desplegar una nueva versión 'canary' de este component. Se podría configurar un ReplicationController con el valor de replicas puesto a 9 para la mayor parte de las réplicas,
con etiquetas tier=frontend, environment=prod, track=stable, y otro ReplicationController con el valor de replicas puesto a 1 para el 'canary',
con las etiquetas tier=frontend, environment=prod, track=canary. Así el servicio cubriría tanto los pods canary como el resto.
Pero también es posible trastear con los ReplicationControllers de forma separada para probar cosas, monitorizar los resultados, etc.
Usar ReplicationControllers con servicios
Un único servicio puede exponer múltiples ReplicationControllers, de forma que, por ejemplo, algo de tráfico
vaya a la versión vieja, y otro tanto vaya a la versión nueva.
Un ReplicationController nunca se terminará por sí mismo, pero tampoco se espera que se ejecute permanentemente como los servicios.
Los servicios puede que estén compuestos de pods controlados por múltiples ReplicationControllers,
y se espera que muchos ReplicationControllers se creen y se destruyan durante el ciclo de vida de un servicio (por ejemplo,
para realizar una actualización de los pods que ejecutan el servicio). Ambos servicios mismos y sus clientes deberían permanecer
ajenos a los ReplicationControllers que mantienen los pods que proporcionan los servicios.
Escribir aplicaciones que se repliquen
Los Pods creados por un ReplicationController están pensados para que sean intercambiables y semánticamente idénticos,
aunque sus configuraciones puede que sean heterogéneas a lo largo del tiempo. Este es un ajuste obvio para los servidores sin estado replicados,
pero los ReplicationControllers también pueden utilizarse para mantener la disponibilidad de aplicaciones que se elijen por un maestro, las particionadas, y las de grupos de trabajadores.
Dichas aplicaciones deberían usar los mecanismos de asignación dinámica de trabajo, como las colas de trabajo RabbitMQ,
en vez de la personalización estática/de una sola vez en la configuración de cada pod,
ya que se considera un anti-patrón. Cualquier personalización de pod que se haga, como el calibrado vertical automático de recursos (por ejemplo, cpu o memoria),
debería realizarse a través de otro proceso de controlador en línea, no con el mismo ReplicationController.
Responsabilidades de un ReplicationController
El ReplicationController simplemente garantiza que el número deseado de pods coincide con su selector de etiqueta y que son operacionales.
Actualmente, sólo los pods que han terminado se excluyen de la cuenta. En el futuro, la disponibilidad y otra información disponible en el sistema
se tendrá en cuenta, se añadirá más controles sobre la regla de sussitución, y se está planificando
emitir eventos que podrían ser aprovechados por clientes externos para implementar reglas complejas de sustitución y escalado de forma arbitraria.
El ReplicationController está siempre condicionado a esta reducida responsabilidad.
Él mismo no llevará a cabo ni pruebas de estar listo ni vivo. En vez de aplicar el auto-escalado,
se pretende que este sea realizado por un auto-escalador externo (como se vio en #492), que sería el encargado de cambiar su campo replicas.
No se añadirá reglas de programación (por ejemplo, propagación) al ReplicationController.
Ni se debería validar que los pods controlados coincidan con la plantilla actual especificada, ya que eso obstruiría el auto-calibrado y otros procesos automáticos.
De forma similar, los vencimientos de término, las dependencias de orden, la extensión de la configuración, y otras características se aplican en otro lado.
Incluso se plantea excluir el mecanismo de creación de pods a granel (#170).
El ReplicationController está pensado para ser una primitiva de bloques is intended to be a composable building-block primitive. We expect higher-level APIs and/or tools to be built on top of it and other complementary primitives for user convenience in the future. The "macro" operations currently supported by kubectl (run, scale, rolling-update) are proof-of-concept examples of this. For instance, we could imagine something like Asgard managing ReplicationControllers, auto-scalers, services, scheduling policies, canaries, etc.
Objeto API
El ReplicationController es un recurso de alto nivel en la API REST de Kubernetes. Más detalles acerca del
objeto API se pueden encontrar aquí:
Objeto API ReplicationController.
Alternativas al ReplicationController
ReplicaSet
El ReplicaSet es el ReplicationController de nueva generación que soporta el nuevo selector de etiqueta basado en conjunto.
Se usa principalmente por el Deployment como un mecanismo para orquestrar la creación de pods, la eliminación y las actualizaciones.
Nótese que se recomienda usar Deployments en vez de directamente usar los ReplicaSets, a menos que necesites una orquestración personalizada de actualizaciones o no quieras actualizaciones en absoluto.
Deployment (Recomendado)
El Deployment es un objeto de alto nivel de la API que actualiza sus ReplicaSets subyacenetes y sus Pods
de forma similar a cómo lo hace el comando kubectl rolling-update. Se recomienda el uso de Deployments si se quiere esta functionalidad de actualización en línea,
porque a diferencia del comando kubectl rolling-update, son declarativos, se ejecutan del lado del servidor, y tienen características adicionales.
Pods simples
A diferencia del caso en que un usuario ha creado directamente pods, un ReplicationController sustituye los pods que han sido eliminador o terminados por cualquier motivo,
como en el caso de un fallo de un nodo o una intervención disruptiva de mantenimiento, como la actualización del kernel.
Por esta razón, se recomienda que se usa un ReplicationController incluso si tu aplicación sólo necesita un único pod.
Piensa que es similar a un supervisor de proceso, sólo que supervisa múltiples pods entre múltiples nodos en vez de
procesos individuales en un único nodo. Un ReplicationController delega los reinicios locales de
los contenedores a algún agente del nodo (por ejemplo, Kubelet o Docker).
Job
Usa un Job en vez de un ReplicationController para aquellos pods que se espera que terminen por sí mismos
(esto es, trabajos por lotes).
DaemonSet
Usa un DaemonSet en vez de un ReplicationController para aquellos pods que proporcionan
una función a nivel de servidor, como la monitorización o el loggin de servidor. Estos pods tienen un ciclo de vida que está asociado
al del servidor: el pod necesita ejecutarse en el servidor antes que los otros pods arranquen, y es seguro
terminarlo cuando el servidor está listo para reiniciarse/apagarse.
Un controlador de Deployment proporciona actualizaciones declarativas para los Pods y los
ReplicaSets.
Cuando describes el estado deseado en un objeto Deployment, el controlador del Deployment se encarga de cambiar el estado actual al estado deseado de forma controlada.
Puedes definir Deployments para crear nuevos ReplicaSets, o eliminar Deployments existentes y adoptar todos sus recursos con nuevos Deployments.
Nota:
No deberías gestionar directamente los ReplicaSets que pertenecen a un Deployment.
Todos los casos de uso deberían cubrirse manipulando el objeto Deployment.
Considera la posibilidad de abrir un incidente en el repositorio principal de Kubernetes si tu caso de uso no está soportado por el motivo que sea.
Casos de uso
A continuación se presentan los casos de uso típicos de los Deployments:
Declarar el nuevo estado de los Pods actualizando el PodTemplateSpec del Deployment. Ello crea un nuevo ReplicaSet y el Deployment gestiona el cambio de los Pods del viejo ReplicaSet al nuevo de forma controlada. Cada nuevo ReplicaSet actualiza la revisión del Deployment.
Se crea un Deployment denominado nginx-deployment, indicado a través del campo .metadata.name.
El Deployment crea tres Pods replicados, indicado a través del campo replicas.
El campo selector define cómo el Deployment identifica los Pods que debe gestionar.
En este caso, simplemente seleccionas una etiqueta que se define en la plantilla Pod (app: nginx).
Sin embargo, es posible definir reglas de selección más sofisticadas,
siempre que la plantilla Pod misma satisfaga la regla.
Nota:
matchLabels es un mapa de entradas {clave,valor}. Una entrada simple {clave,valor} en el mapa matchLabels
es equivalente a un elemento de matchExpressions cuyo campo sea la "clave", el operador sea "In",
y la matriz de valores contenga únicamente un "valor". Todos los requisitos se concatenan con AND.
El campo template contiene los siguientes sub-campos:
Los Pods se etiquetan como app: nginx usando el campo labels.
La especificación de la plantilla Pod, o el campo .template.spec, indica
que los Pods ejecutan un contenedor, nginx, que utiliza la versión 1.7.9 de la imagen de nginx de
Docker Hub.
Crea un contenedor y lo llamar nginx usando el campo name.
Ejecuta la imagen nginx en su versión 1.7.9.
Abre el puerto 80 para que el contenedor pueda enviar y recibir tráfico.
Para crear este Deployment, ejecuta el siguiente comando:
Debes indicar el parámetro --record para registrar el comando ejecutado en la anotación de recurso kubernetes.io/change-cause.
Esto es útil para futuras introspecciones, por ejemplo para comprobar qué comando se ha ejecutado en cada revisión del Deployment.
A continuación, ejecuta el comando kubectl get deployments. La salida debe ser parecida a la siguiente:
NAME READY UP-TO-DATE AVAILABLE AGE
nginx-deployment 3/3 3 3 1s
Cuando inspeccionas los Deployments de tu clúster, se muestran los siguientes campos:
NAME enumera los nombre de los Deployments del clúster.
READY muestra cuántas réplicas de la aplicación están disponibles para sus usuarios. Sigue el patrón número de réplicas listas/deseadas.
UP-TO-DATE muestra el número de réplicas que se ha actualizado para alcanzar el estado deseado.
AVAILABLE muestra cuántas réplicas de la aplicación están disponibles para los usuarios.
AGE muestra la cantidad de tiempo que la aplicación lleva ejecutándose.
Nótese cómo los valores de cada campo corresponden a los valores de la especificación del Deployment:
El número de réplicas deseadas es 3 de acuerdo con el campo .spec.replicas.
El número de réplicas actuales es 0 de acuerdo con el campo .status.replicas.
El número de réplicas actualizadas es 0 de acuerdo con el campo .status.updatedReplicas.
El número de réplicas disponibles es 0 de acuerdo con el campo .status.availableReplicas.
Si deseamos obtener más información del Deployment utilice el parámetro '-o wide', ejecutando el comando 'kubectl get deployments -o wide'. La salida será parecida a la siguiente:
NAME READY UP-TO-DATE AVAILABLE AGE CONTAINERS IMAGES SELECTOR
nginx-deployment 3/3 33 10s nginx nginx:1.7.9 app=nginx
Ejecutando el comando anterior se muestran los siguientes campos adicionales:
CONTAINERS muestra los nombres de los contenedores declarados en .spec.template.spec.containers.[name].
IMAGES muestra los nombres de las imágenes declaradas en .spec.template.spec.containers.[image].
'SELECTOR' muestra el Label selector que se declaró en matchLabels o matchExpressions.
Para ver el estado del Deployment, ejecuta el comando kubectl rollout status deployment.v1.apps/nginx-deployment. Este comando devuelve el siguiente resultado:
Waiting for rollout to finish: 2 out of 3 new replicas have been updated...
deployment "nginx-deployment" successfully rolled out
Ejecuta de nuevo el comando kubectl get deployments unos segundos más tarde:
NAME READY UP-TO-DATE AVAILABLE AGE
nginx-deployment 3/3 3 3 18s
Fíjate que el Deployment ha creado todas las tres réplicas, y que todas las réplicas están actualizadas (contienen
la última plantilla Pod) y están disponibles (el estado del Pod tiene el valor Ready al menos para el campo .spec.minReadySeconds del Deployment).
Para ver el ReplicaSet (rs) creado por el Deployment, ejecuta el comando kubectl get rs:
NAME DESIRED CURRENT READY AGE
nginx-deployment-75675f5897 3 3 3 18s
Fíjate que el nombre del ReplicaSet siempre se formatea con el patrón [DEPLOYMENT-NAME]-[RANDOM-STRING]. La cadena aleatoria se
genera de forma aleatoria y usa el pod-template-hash como semilla.
Para ver las etiquetas generadas automáticamente en cada pod, ejecuta el comando kubectl get pods --show-labels. Se devuelve la siguiente salida:
NAME READY STATUS RESTARTS AGE LABELS
nginx-deployment-75675f5897-7ci7o 1/1 Running 0 18s app=nginx,pod-template-hash=75675f5897
nginx-deployment-75675f5897-kzszj 1/1 Running 0 18s app=nginx,pod-template-hash=75675f5897
nginx-deployment-75675f5897-qqcnn 1/1 Running 0 18s app=nginx,pod-template-hash=75675f5897
El ReplicaSet creado garantiza que hay tres Pods de nginx ejecutándose en todo momento.
Nota:
En un Deployment, debes especificar un selector apropiado y etiquetas de plantilla Pod (en este caso,
app: nginx). No entremezcles etiquetas o selectores con otros controladores (incluyendo otros Deployments y StatefulSets).
Kubernetes no te impide que lo hagas, pero en el caso de que múltiples controladores tengan selectores mezclados, dichos controladores pueden entrar en conflicto y provocar resultados inesperados.
Etiqueta pod-template-hash
Nota:
No cambies esta etiqueta.
La etiqueta pod-template-hash es añadida por el controlador del Deployment a cada ReplicaSet que el Deployment crea o adopta.
Esta etiqueta garantiza que todos los hijos ReplicaSets de un Deployment no se entremezclan. Se genera mediante una función hash aplicada al PodTemplate del ReplicaSet
y usando el resultado de la función hash como el valor de la etiqueta que se añade al selector del ReplicaSet, en las etiquetas de la plantilla Pod,
y en cualquier Pod existente que el ReplicaSet tenga.
Actualizar un Deployment
Nota:
El lanzamiento de un Deployment se activa si y sólo si la plantilla Pod del Deployment (esto es, .spec.template)
se cambia, por ejemplo si se actualiza las etiquetas o las imágenes de contenedor de la plantilla.
Otras actualizaciones, como el escalado del Deployment, no conllevan un lanzamiento de despliegue.
Asumiendo que ahora quieres actualizar los Pods nginx para que usen la imagen nginx:1.9.1
en vez de la imagen nginx:1.7.9.
kubectl --record deployment.apps/nginx-deployment set image deployment.v1.apps/nginx-deployment nginx=nginx:1.9.1
image updated
De forma alternativa, puedes editar el Deployment y cambiar el valor del campo .spec.template.spec.containers[0].image de nginx:1.7.9 a nginx:1.9.1:
kubectl edit deployment.v1.apps/nginx-deployment
deployment.apps/nginx-deployment edited
Para ver el estado del despliegue, ejecuta:
kubectl rollout status deployment.v1.apps/nginx-deployment
Waiting for rollout to finish: 2 out of 3 new replicas have been updated...
deployment "nginx-deployment" successfully rolled out
Cuando el despliegue funciona, puede que quieras obtener el Deployment:
kubectl get deployments
NAME READY UP-TO-DATE AVAILABLE AGE
nginx-deployment 3/3 3 3 36s
El número de réplicas actualizadas indica que el Deployment ha actualizado las réplicas según la última configuración.
Las réplicas actuales indican el total de réplicas que gestiona este Deployment, y las réplicas disponibles indican
el número de réplicas actuales que están disponibles.
Puedes ejecutar el comando kubectl get rs para ver que el Deployment actualizó los Pods creando un nuevo ReplicaSet y escalándolo
hasta las 3 réplicas, así como escalando el viejo ReplicaSet a 0 réplicas.
kubectl get rs
NAME DESIRED CURRENT READY AGE
nginx-deployment-1564180365 3 3 3 6s
nginx-deployment-2035384211 0 0 0 36s
Si ejecutas el comando get pods deberías ver los nuevos Pods:
kubectl get pods
NAME READY STATUS RESTARTS AGE
nginx-deployment-1564180365-khku8 1/1 Running 0 14s
nginx-deployment-1564180365-nacti 1/1 Running 0 14s
nginx-deployment-1564180365-z9gth 1/1 Running 0 14s
La próxima vez que quieras actualizar estos Pods, sólo necesitas actualizar la plantilla Pod del Deployment otra vez.
El Deployment permite garantizar que sólo un número determinado de Pods puede eliminarse mientras se están actualizando.
Por defecto, garantiza que al menos el 25% menos del número deseado de Pods se está ejecutando (máx. 25% no disponible).
El Deployment también permite garantizar que sólo un número determinado de Pods puede crearse por encima del número deseado de
Pods. Por defecto, garantiza que al menos el 25% más del número deseado de Pods se está ejecutando (máx. 25% de aumento).
Por ejemplo, si miras detenidamente el Deployment de arriba, verás que primero creó un Pod,
luego eliminó algunos viejos Pods y creó otros nuevos. No elimina los viejos Pods hasta que un número suficiente de
nuevos Pods han arrancado, y no crea nuevos Pods hasta que un número suficiente de viejos Pods se han eliminado.
De esta forma, asegura que el número de Pods disponibles siempre es al menos 2, y el número de Pods totales es cómo máximo 4.
kubectl describe deployments
Name: nginx-deployment
Namespace: default
CreationTimestamp: Thu, 30 Nov 2017 10:56:25 +0000
Labels: app=nginx
Annotations: deployment.kubernetes.io/revision=2
Selector: app=nginx
Replicas: 3 desired | 3 updated | 3 total | 3 available | 0 unavailable
StrategyType: RollingUpdate
MinReadySeconds: 0
RollingUpdateStrategy: 25% max unavailable, 25% max surge
Pod Template:
Labels: app=nginx
Containers:
nginx:
Image: nginx:1.9.1
Port: 80/TCP
Environment: <none>
Mounts: <none>
Volumes: <none>
Conditions:
Type Status Reason
---- ------ ------
Available True MinimumReplicasAvailable
Progressing True NewReplicaSetAvailable
OldReplicaSets: <none>
NewReplicaSet: nginx-deployment-1564180365 (3/3 replicas created)
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal ScalingReplicaSet 2m deployment-controller Scaled up replica set nginx-deployment-2035384211 to 3
Normal ScalingReplicaSet 24s deployment-controller Scaled up replica set nginx-deployment-1564180365 to 1
Normal ScalingReplicaSet 22s deployment-controller Scaled down replica set nginx-deployment-2035384211 to 2
Normal ScalingReplicaSet 22s deployment-controller Scaled up replica set nginx-deployment-1564180365 to 2
Normal ScalingReplicaSet 19s deployment-controller Scaled down replica set nginx-deployment-2035384211 to 1
Normal ScalingReplicaSet 19s deployment-controller Scaled up replica set nginx-deployment-1564180365 to 3
Normal ScalingReplicaSet 14s deployment-controller Scaled down replica set nginx-deployment-2035384211 to 0
Aquí puedes ver que cuando creaste por primera vez el Deployment, este creó un ReplicaSet (nginx-deployment-2035384211)
y lo escaló a 3 réplicas directamente. Cuando actualizaste el Deployment, creó un nuevo ReplicaSet
(nginx-deployment-1564180365) y lo escaló a 1 y entonces escaló el viejo ReplicaSet a 2, de forma que al menos
hubiera 2 Pods disponibles y como mucho 4 Pods en total en todo momento. Entonces, continuó escalando
el nuevo y el viejo ReplicaSet con la misma estrategia de actualización continua. Finalmente, el nuevo ReplicaSet acaba con 3 réplicas
disponibles, y el viejo ReplicaSet se escala a 0.
Sobrescritura (o sea, múltiples actualizaciones a la vez)
Cada vez que el controlador del Deployment observa un nuevo objeto de despliegue, se crea un ReplicaSet para arrancar
los Pods deseados si es que no existe otro ReplicaSet haciéndolo. Los ReplicaSet existentes que controlan los Pods cuyas etiquetas
coinciden con el valor del campo .spec.selector, pero cuya plantilla no coincide con el valor del campo .spec.template se reducen. Al final,
el nuevo ReplicaSet se escala hasta el valor del campo .spec.replicas y todos los viejos ReplicaSets se escalan a 0.
Si actualizas un Deployment mientras otro despliegue está en curso, el Deployment creará un nuevo ReplicaSet
como consecuencia de la actualización y comenzará a escalarlo, y sobrescribirá al ReplicaSet que estaba escalando anteriormente
-- lo añadirá a su lista de viejos ReplicaSets y comenzará a reducirlos.
Por ejemplo, supongamos que creamos un Deployment para crear 5 réplicas de nginx:1.7.9,
pero entonces actualizamos el Deployment para crear 5 réplicas de nginx:1.9.1 cuando sólo se ha creado 3
réplicas de nginx:1.7.9. En este caso, el Deployment comenzará automáticamente a matar los 3 Pods de nginx:1.7.9
que había creado, y empezará a crear los Pods de nginx:1.9.1. Es decir, no esperará a que se creen las 5 réplicas de nginx:1.7.9
antes de aplicar la nueva configuración.
Actualizaciones del selector de etiquetas
No se recomienda hacer cambios al selector del etiquetas y, por ello, se aconseja encarecidamente planificar el valor de dichos selectores por adelantado.
En cualquier caso, si necesitas cambiar un selector de etiquetas, hazlo con mucho cuidado y asegúrate que entiendes todas sus implicaciones.
Nota:
En la versión apps/v1 de la API, el selector de etiquetas del Deployment es inmutable una vez se ha creado.
Las adiciones posteriores al selector obligan también a actualizar las etiquetas de la plantilla Pod en la especificación del Deployment con los nuevos valores,
ya que de lo contrario se devolvería un error. Este cambio no es de superposición, es decir, que el nuevo selector
no selecciona los ReplicaSets y Pods creados con el viejo selector, lo que provoca que todos los viejos ReplicaSets se marquen como huérfanos y
la creación de un nuevo ReplicaSet.
Las actualizaciones de selector -- esto es, cambiar el valor actual en una clave de selector -- provocan el mismo comportamiento que las adiciones.
Las eliminaciones de selector -- esto es, eliminar una clave actual del selector del Deployment -- no necesitan de cambios en las etiquetas de la plantilla Pod.
No se marca ningún ReplicaSet existente como huérfano, y no se crea ningún ReplicaSet nuevo, pero debe tenerse en cuenta que
la etiqueta eliminada todavía existe en los Pods y ReplicaSets que se están ejecutando.
Revertir un Deployment
En ocasiones necesitas revertir un Deployment; por ejemplo, cuando el Deployment no es estable, como cuando no para de reiniciarse.
Por defecto, toda la historia de despliegue del Deployment se mantiene en el sistema de forma que puedes revertir en cualquier momento
(se puede modificar este comportamiento cambiando el límite de la historia de revisiones de modificaciones).
Nota:
Cuando se lanza el despligue de un Deployment, se crea una nueva revisión. Esto quiere decir que
la nueva revisión se crea si y sólo si la plantilla Pod del Deployment (.spec.template) se cambia;
por ejemplo, si cambias las etiquetas o la imagen del contenedor de la plantilla.
Otras actualizaciones, como escalar el Deployment,
no generan una nueva revisión del Deployment, para poder facilitar el escalado manual simultáneo - o auto-escalado.
Esto significa que cuando reviertes a una versión anterior, sólo la parte de la plantilla Pod del Deployment se revierte.
Vamos a suponer que hemos cometido un error al actualizar el Deployment, poniendo como nombre de imagen nginx:1.91 en vez de nginx:1.9.1:
kubectl set image deployment.v1.apps/nginx-deployment nginx=nginx:1.91 --record=true
deployment.apps/nginx-deployment image updated
El despliegue se atasca y no progresa.
kubectl rollout status deployment.v1.apps/nginx-deployment
Waiting for rollout to finish: 1 out of 3 new replicas have been updated...
Presiona Ctrl-C para detener la monitorización del despliegue de arriba. Para obtener más información sobre despliegues atascados,
lee más aquí.
Verás que el número de réplicas viejas (nginx-deployment-1564180365 y nginx-deployment-2035384211) es 2, y el número de nuevas réplicas (nginx-deployment-3066724191) es 1.
kubectl get rs
NAME DESIRED CURRENT READY AGE
nginx-deployment-1564180365 3 3 3 25s
nginx-deployment-2035384211 0 0 0 36s
nginx-deployment-3066724191 1 1 0 6s
Echando un vistazo a los Pods creados, verás que uno de los Pods creados por el nuevo ReplicaSet está atascado en un bucle intentando bajar la imagen:
kubectl get pods
NAME READY STATUS RESTARTS AGE
nginx-deployment-1564180365-70iae 1/1 Running 0 25s
nginx-deployment-1564180365-jbqqo 1/1 Running 0 25s
nginx-deployment-1564180365-hysrc 1/1 Running 0 25s
nginx-deployment-3066724191-08mng 0/1 ImagePullBackOff 0 6s
Nota:
El controlador del Deployment parará el despliegue erróneo de forma automática, y detendrá el escalado del nuevo
ReplicaSet. Esto depende de los parámetros del rollingUpdate (maxUnavailable específicamente) que hayas configurado.
Kubernetes por defecto establece el valor en el 25%.
kubectl describe deployment
Name: nginx-deployment
Namespace: default
CreationTimestamp: Tue, 15 Mar 2016 14:48:04 -0700
Labels: app=nginx
Selector: app=nginx
Replicas: 3 desired | 1 updated | 4 total | 3 available | 1 unavailable
StrategyType: RollingUpdate
MinReadySeconds: 0
RollingUpdateStrategy: 25% max unavailable, 25% max surge
Pod Template:
Labels: app=nginx
Containers:
nginx:
Image: nginx:1.91
Port: 80/TCP
Host Port: 0/TCP
Environment: <none>
Mounts: <none>
Volumes: <none>
Conditions:
Type Status Reason
---- ------ ------
Available True MinimumReplicasAvailable
Progressing True ReplicaSetUpdated
OldReplicaSets: nginx-deployment-1564180365 (3/3 replicas created)
NewReplicaSet: nginx-deployment-3066724191 (1/1 replicas created)
Events:
FirstSeen LastSeen Count From SubobjectPath Type Reason Message
--------- -------- ----- ---- ------------- -------- ------ -------
1m 1m 1 {deployment-controller } Normal ScalingReplicaSet Scaled up replica set nginx-deployment-2035384211 to 3
22s 22s 1 {deployment-controller } Normal ScalingReplicaSet Scaled up replica set nginx-deployment-1564180365 to 1
22s 22s 1 {deployment-controller } Normal ScalingReplicaSet Scaled down replica set nginx-deployment-2035384211 to 2
22s 22s 1 {deployment-controller } Normal ScalingReplicaSet Scaled up replica set nginx-deployment-1564180365 to 2
21s 21s 1 {deployment-controller } Normal ScalingReplicaSet Scaled down replica set nginx-deployment-2035384211 to 1
21s 21s 1 {deployment-controller } Normal ScalingReplicaSet Scaled up replica set nginx-deployment-1564180365 to 3
13s 13s 1 {deployment-controller } Normal ScalingReplicaSet Scaled down replica set nginx-deployment-2035384211 to 0
13s 13s 1 {deployment-controller } Normal ScalingReplicaSet Scaled up replica set nginx-deployment-3066724191 to 1
Para arreglar este problema, necesitas volver a una revisión previa del Deployment que sea estable.
Comprobar la Historia de Despliegues de un Deployment
Primero, comprobemos las revisiones de este despliegue:
kubectl rollout history deployment.v1.apps/nginx-deployment
En el momento de la creación, el mensaje en CHANGE-CAUSE se copia de la anotación kubernetes.io/change-cause del Deployment a sus revisiones. Podrías indicar el mensaje CHANGE-CAUSE:
Anotando el Deployment con el comando kubectl annotate deployment.v1.apps/nginx-deployment kubernetes.io/change-cause="image updated to 1.9.1"
Añadiendo el parámetro --record para registrar el comando kubectl que está haciendo cambios en el recurso.
Manualmente editando el manifiesto del recursos.
Para ver más detalles de cada revisión, ejecuta:
kubectl rollout history deployment.v1.apps/nginx-deployment --revision=2
Para más detalles acerca de los comandos relacionados con las revisiones de un Deployment, echa un vistazo a kubectl rollout.
El Deployment se ha revertido ahora a una revisión previa estable. Como se puede comprobar, el controlador del Deployment genera un evento DeploymentRollback
al retroceder a la revisión 2.
kubectl get deployment nginx-deployment
NAME READY UP-TO-DATE AVAILABLE AGE
nginx-deployment 3/3 3 3 30m
kubectl describe deployment nginx-deployment
Name: nginx-deployment
Namespace: default
CreationTimestamp: Sun, 02 Sep 2018 18:17:55 -0500
Labels: app=nginx
Annotations: deployment.kubernetes.io/revision=4
kubernetes.io/change-cause=kubectl set image deployment.v1.apps/nginx-deployment nginx=nginx:1.9.1 --record=true
Selector: app=nginx
Replicas: 3 desired | 3 updated | 3 total | 3 available | 0 unavailable
StrategyType: RollingUpdate
MinReadySeconds: 0
RollingUpdateStrategy: 25% max unavailable, 25% max surge
Pod Template:
Labels: app=nginx
Containers:
nginx:
Image: nginx:1.9.1
Port: 80/TCP
Host Port: 0/TCP
Environment: <none>
Mounts: <none>
Volumes: <none>
Conditions:
Type Status Reason
---- ------ ------
Available True MinimumReplicasAvailable
Progressing True NewReplicaSetAvailable
OldReplicaSets: <none>
NewReplicaSet: nginx-deployment-c4747d96c (3/3 replicas created)
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal ScalingReplicaSet 12m deployment-controller Scaled up replica set nginx-deployment-75675f5897 to 3
Normal ScalingReplicaSet 11m deployment-controller Scaled up replica set nginx-deployment-c4747d96c to 1
Normal ScalingReplicaSet 11m deployment-controller Scaled down replica set nginx-deployment-75675f5897 to 2
Normal ScalingReplicaSet 11m deployment-controller Scaled up replica set nginx-deployment-c4747d96c to 2
Normal ScalingReplicaSet 11m deployment-controller Scaled down replica set nginx-deployment-75675f5897 to 1
Normal ScalingReplicaSet 11m deployment-controller Scaled up replica set nginx-deployment-c4747d96c to 3
Normal ScalingReplicaSet 11m deployment-controller Scaled down replica set nginx-deployment-75675f5897 to 0
Normal ScalingReplicaSet 11m deployment-controller Scaled up replica set nginx-deployment-595696685f to 1
Normal DeploymentRollback 15s deployment-controller Rolled back deployment "nginx-deployment" to revision 2
Normal ScalingReplicaSet 15s deployment-controller Scaled down replica set nginx-deployment-595696685f to 0
Escalar un Deployment
Puedes escalar un Deployment usando el siguiente comando:
Asumiendo que se ha habilitado el escalado horizontal de pod
en tu clúster, puedes configurar un auto-escalado para tu Deployment y elegir el mínimo y máximo número de Pods
que quieres ejecutar en base al uso de CPU de tus Pods actuales.
La actualización continua de los Deployments permite la ejecución de múltiples versiones de una aplicación al mismo tiempo.
Cuando tú o un auto-escalado escala un Deployment con actualización continua que está en medio de otro despliegue (bien en curso o pausado),
entonces el controlador del Deployment balanceará las réplicas adicionales de los ReplicaSets activos (ReplicaSets con Pods)
para así poder mitigar el riesgo. Esto se conoce como escalado proporcional.
Por ejemplo, imagina que estás ejecutando un Deployment con 10 réplicas, donde maxSurge=3, y maxUnavailable=2.
kubectl get deploy
NAME READY UP-TO-DATE AVAILABLE AGE
nginx-deployment 10/10 10 10 50s
Si actualizas a una nueva imagen que no puede descargarse desde el clúster:
kubectl set image deployment.v1.apps/nginx-deployment nginx=nginx:sometag
deployment.apps/nginx-deployment image updated
La actualización de la imagen arranca un nuevo despliegue con el ReplicaSet nginx-deployment-1989198191,
pero se bloquea debido al requisito maxUnavailable indicado arriba:
kubectl get rs
NAME DESIRED CURRENT READY AGE
nginx-deployment-1989198191 5 5 0 9s
nginx-deployment-618515232 8 8 8 1m
Y entonces se origina una nueva petición de escalado para el Deployment. El auto-escalado incrementa las réplicas del Deployment
a 15. El controlador del Deployment necesita ahora decidir dónde añadir esas nuevas 5 réplicas.
Si no estuvieras usando el escalado proporcional, las 5 se añadirían al nuevo ReplicaSet. Pero con el escalado proporcional,
las réplicas adicionales se distribuyen entre todos los ReplicaSets. Las partes más grandes van a los ReplicaSets
con el mayor número de réplicas y las partes más pequeñas van a los ReplicaSets con menos réplicas. Cualquier resto sobrante se añade
al ReplicaSet con mayor número de réplicas. Aquellos ReplicaSets con 0 réplicas no se escalan.
En nuestro ejemplo anterior, se añadirán 3 réplicas al viejo ReplicaSet y 2 réplicas al nuevo ReplicaSet.
EL proceso de despliegue debería al final mover todas las réplicas al nuevo ReplicaSet, siempre que las nuevas
réplicas arranquen positivamente.
kubectl get deploy
NAME READY UP-TO-DATE AVAILABLE AGE
nginx-deployment 18/15 7 8 7m
kubectl get rs
NAME DESIRED CURRENT READY AGE
nginx-deployment-1989198191 7 7 0 7m
nginx-deployment-618515232 11 11 11 7m
Pausar y Reanudar un Deployment
Puedes pausar un Deployment antes de arrancar una o más modificaciones y luego reanudarlo. Esto te permite aplicar múltiples arreglos
entre la pausa y la reanudación sin necesidad de arrancar despliegues innecesarios.
Por ejemplo, con un Deployment que acaba de crearse:
kubectl get deploy
NAME READY UP-TO-DATE AVAILABLE AGE
nginx-deployment 3/3 3 3 1m
kubectl get rs
NAME DESIRED CURRENT READY AGE
nginx-2142116321 3 3 3 1m
El estado inicial del Deployment anterior a la pausa continuará su función, pero las nuevas modificaciones
del Deployment no tendrán efecto ya que el Deployment está pausado.
Al final, reanuda el Deployment y observa cómo se genera un nuevo ReplicaSet con todos los cambios:
NAME DESIRED CURRENT READY AGE
nginx-2142116321 0 0 0 2m
nginx-3926361531 3 3 3 28s
Nota:
No se puede revertir un Deployment pausado hasta que se vuelve a reanudar.
Estado del Deployment
Un Deployment pasa por varios estados a lo largo de su ciclo de vida. Así, puede estar progresando mientras
se despliega un nuevo ReplicaSet, puede estar completo, o puede quedar en estado fallido.
Progresar un Deployment
Kubernetes marca un Deployment como progresando cuando se realiza cualquiera de las siguientes tareas:
El Deployment crea un nuevo ReplicaSet.
El Deployment está escalando su ReplicaSet más nuevo.
El Deployment está reduciendo su(s) ReplicaSet(s) más antiguo(s).
Hay nuevos Pods disponibles y listos (listo por lo menos MinReadySeconds).
Puedes monitorizar el progreso de un Deployment usando el comando kubectl rollout status.
Completar un Deployment
Kubernetes marca un Deployment como completado cuando presenta las siguientes características:
Todas las réplicas asociadas con el Deployment han sido actualizadas a la última versión indicada, lo cual quiere decir
que todas las actualizaciones se han completado.
Todas las réplicas asociadas con el Deployment están disponibles.
No están ejecutándose viejas réplicas del Deployment.
Puedes comprobar si un Deployment se ha completado usando el comando kubectl rollout status. Si el despliegue se ha completado
de forma satisfactoria, el comando kubectl rollout status devuelve un código 0 de salida.
kubectl rollout status deployment.v1.apps/nginx-deployment
Waiting for rollout to finish: 2 of 3 updated replicas are available...
deployment "nginx-deployment" successfully rolled out
$ echo $?
0
Deployment fallido
Tu Deployment puede quedarse bloqueado intentando desplegar su nuevo ReplicaSet sin nunca completarse. Esto puede ocurrir
debido a algunos de los factores siguientes:
Cuota insuficiente
Fallos en la prueba de estar listo
Errores en la descarga de imágenes
Permisos insuficientes
Rangos de límites de recursos
Mala configuración del motor de ejecución de la aplicación
Una forma de detectar este tipo de situación es especificar un parámetro de vencimiento en la especificación de tu Deployment:
(.spec.progressDeadlineSeconds). .spec.progressDeadlineSeconds denota el número
de segundos que el controlador del Deployment debe esperar antes de indicar (en el estado del Deployment) que el
Deployment no avanza.
El siguiente comando kubectl configura el campo progressDeadlineSeconds para forzar al controlador a
informar de la falta de avance de un Deployment después de 10 minutos:
Una vez que se ha excedido el vencimiento, el controlador del Deployment añade una DeploymentCondition
con los siguientes atributos al campo .status.conditions del Deployment:
Kubernetes no emprenderá ninguna acción ante un Deployment parado que no sea la de reportar el estado mediante
Reason=ProgressDeadlineExceeded. Los orquestradores de alto nivel pueden aprovecharse y actuar consecuentemente, por ejemplo,
retrocediendo el Deployment a su versión previa.
Nota:
Si pausas un Deployment, Kubernetes no comprueba el avance en base al vencimiento indicado. Así, es posible pausar
de forma segura un Deployment en medio de un despliegue y reanudarlo sin que se arranque el estado de exceso de vencimiento.
Puede que notes errores transitorios en tus Deployments, bien debido a un tiempo de vencimiento muy pequeño que hayas configurado
o bien a cualquier otro tipo de error que puede considerarse como transitorio. Por ejemplo,
supongamos que no tienes suficiente cuota. Si describes el Deployment, te darás cuenta de la sección siguiente:
kubectl describe deployment nginx-deployment
<...>
Conditions:
Type Status Reason
---- ------ ------
Available True MinimumReplicasAvailable
Progressing True ReplicaSetUpdated
ReplicaFailure True FailedCreate
<...>
Si ejecutas el comando kubectl get deployment nginx-deployment -o yaml, el estado del Deployment puede parecerse a:
Al final, una vez que se supera el vencimiento del progreso del Deployment, Kubernetes actualiza el estado
y la razón de el estado de progreso:
Conditions:
Type Status Reason
---- ------ ------
Available True MinimumReplicasAvailable
Progressing False ProgressDeadlineExceeded
ReplicaFailure True FailedCreate
Puedes solucionar un problema de cuota insuficiente simplemente reduciendo el número de réplicas de tu Deployment, reduciendo
otros controladores que puedas estar ejecutando, o incrementando la cuota en tu espacio de nombres. Si una vez satisfechas las condiciones de tu cuota,
el controlador del Deployment completa el despliegue, entonces verás que el estado del Deployment se actualiza al estado satisfactorio (Status=True y Reason=NewReplicaSetAvailable).
Conditions:
Type Status Reason
---- ------ ------
Available True MinimumReplicasAvailable
Progressing True NewReplicaSetAvailable
Type=Available con Status=True significa que tu Deployment tiene disponibilidad mínima. La disponibilidad mínima se prescribe
mediante los parámetros indicados en la estrategia de despligue. Type=Progressing con Status=True significa que tu Deployment
está bien en medio de un despliegue y está progresando o bien que se ha completado de forma satisfactoria y el número mínimo
requerido de nuevas réplicas ya está disponible (ver la Razón del estado para cada caso particular - en nuestro caso
Reason=NewReplicaSetAvailable significa que el Deployment se ha completado).
Puedes comprobar si un Deployment ha fallado en su progreso usando el comando kubectl rollout status. kubectl rollout status
devuelve un código de salida distinto de 0 si el Deployment ha excedido su tiempo de vencimiento.
kubectl rollout status deployment.v1.apps/nginx-deployment
Waiting for rollout to finish: 2 out of 3 new replicas have been updated...
error: deployment "nginx" exceeded its progress deadline
$ echo $?
1
Actuar ante un despliegue fallido
Todas las acciones que aplican a un Deployment completado también aplican a un Deployment fallido. Puedes escalarlo/reducirlo, retrocederlo
a una revisión previa, o incluso pausarlo si necesitas realizar múltiples cambios a la plantilla Pod del Deployment.
Regla de Limpieza
Puedes configurar el campo .spec.revisionHistoryLimit de un Deployment para especificar cuántos ReplicaSets viejos quieres conservar
para este Deployment. El resto será eliminado en segundo plano. Por defecto, es 10.
Nota:
Poner este campo de forma explícita a 0 resulta en la limpieza de toda la historia de tu Deployment,
por lo que tu Deployment no podrá retroceder a revisiones previas.
Casos de Uso
Despligue Canary
Si quieres desplegar nuevas versiones a un sub-conjunto de usuarios o servidores usando el Deployment,
puedes hacerlo creando múltiples Deployments, uno para cada versión nueva, siguiendo el patrón canary descrito en
gestionar recursos.
Escribir una especificación de Deployment
Al igual que con el resto de configuraciones de Kubernetes, un Deployment requiere los campos apiVersion, kind, y metadata.
Para información general acerca de cómo trabajar con ficheros de configuración, ver los documentos acerca de desplegar aplicaciones,
configurar contenedores, y usar kubectl para gestionar recursos.
Tanto .spec.template como .spec.selector sin campos obligatorios dentro de .spec.
El campo .spec.template es una plantilla Pod. Tiene exactamente el mismo esquema que un Pod,
excepto por el hecho de que está anidado y no tiene apiVersion ni kind.
Junto con los campos obligatorios de un Pod, una plantilla Pod de un Deployment debe indicar las etiquetas
y las reglas de reinicio apropiadas. Para el caso de las etiquetas, asegúrate que no se entremezclan con otros controladores. Ver selector).
.spec.replicas es un campo opcional que indica el número de Pods deseados. Su valor por defecto es 1.
Selector
.spec.selector es un campo opcional que indica un selector de etiquetas
para los Pods objetivo del deployment.
.spec.selector debe coincidir con .spec.template.metadata.labels, o será descartado por la API.
A partir de la versión apps/v1 de la API, .spec.selector y .metadata.labels no toman como valor por defecto el valor de .spec.template.metadata.labels si no se indica.
Por ello, debe especificarse de forma explícita. Además hay que mencionar que .spec.selector es inmutable tras la creación del Deployment en apps/v1.
Un Deployment puede finalizar aquellos Pods cuyas etiquetas coincidan con el selector si su plantilla es diferente
de .spec.template o si el número total de dichos Pods excede .spec.replicas. Arranca nuevos
Pods con .spec.template si el número de Pods es menor que el número deseado.
Nota:
No deberías crear otros Pods cuyas etiquetas coincidan con este selector, ni directamente creando
otro Deployment, ni creando otro controlador como un ReplicaSet o un ReplicationController. Si lo haces,
el primer Deployment pensará que también creó esos otros Pods. Kubernetes no te impide hacerlo.
Si tienes múltiples controladores que entremezclan sus selectores, dichos controladores competirán entre ellos
y no se comportarán de forma correcta.
Estrategia
.spec.strategy especifica la estrategia usada para remplazar los Pods viejos con los nuevos.
.spec.strategy.type puede tener el valor "Recreate" o "RollingUpdate". "RollingUpdate" el valor predeterminado.
Despliegue mediante recreación
Todos los Pods actuales se eliminan antes de que los nuevos se creen cuando .spec.strategy.type==Recreate.
Despliegue mediante actualización continua
El Deployment actualiza los Pods en modo de actualización continua
cuando .spec.strategy.type==RollingUpdate. Puedes configurar los valores de maxUnavailable y maxSurge
para controlar el proceso de actualización continua.
Número máximo de pods no disponibles
.spec.strategy.rollingUpdate.maxUnavailable es un campo opcional que indica el número máximo
de Pods que pueden no estar disponibles durante el proceso de actualización. El valor puede ser un número absoluto (por ejemplo, 5)
o un porcentaje de los Pods deseados (por ejemplo, 10%). El número absoluto se calcula a partir del porcentaje
con redondeo a la baja. El valor no puede ser 0 si .spec.strategy.rollingUpdate.maxSurge es 0. El valor predeterminado es 25%.
Por ejemplo, cuando este valor es 30%, el ReplicaSet viejo puede escalarse al 70% de los
Pods deseados de forma inmediata tras comenzar el proceso de actualización. Una vez que los Pods están listos,
el ReplicaSet viejo puede reducirse aún mas, seguido de un escalado del nuevo ReplicaSet,
asegurándose que el número total de Pods disponibles en todo momento durante la actualización
es de al menos el 70% de los Pods deseados.
Número máximo de pods por encima del número deseado
.spec.strategy.rollingUpdate.maxSurge es un campo opcional que indica el número máximo de Pods
que puede crearse por encima del número deseado de Pods. El valor puede ser un número absoluto (por ejemplo, 5)
o un porcentaje de los Pods deseados (por ejemplo, 10%). El valor no puede ser 0 si MaxUnavailable es 0.
El número absoluto se calcula a partir del porcentaje con redondeo al alza. El valor predeterminado es 25%.
Por ejemplo, cuando este valor es 30%, el nuevo ReplicaSet puede escalarse inmediatamente cuando
comienza la actualización continua, de forma que el número total de Pods viejos y nuevos no
excede el 130% de los Pods deseados. Una vez que los viejos Pods se han eliminado, el nuevo ReplicaSet
puede seguir escalándose, asegurándose que el número total de Pods ejecutándose en todo momento
durante la actualización es como mucho del 130% de los Pods deseados.
Segundos para vencimiento del progreso
.spec.progressDeadlineSeconds es un campo opcional que indica el número de segundos que quieres
esperar a que tu Deployment avance antes de que el sistema reporte que dicho Deployment
ha fallado en su avance - expresado como un estado con Type=Progressing, Status=False.
y Reason=ProgressDeadlineExceeded en el recurso. El controlador del Deployment seguirá intentando
el despliegue. En el futuro, una vez que se implemente el retroceso automático, el controlador del Deployment
retrocederá el despliegue en cuanto detecte ese estado.
Si se especifica, este campo debe ser mayor que .spec.minReadySeconds.
Tiempo mínimo para considerar el Pod disponible
.spec.minReadySeconds es un campo opcional que indica el número mínimo de segundos en que
un Pod recién creado debería estar listo sin que falle ninguno de sus contenedores, para que se considere disponible.
Por defecto su valor es 0 (el Pod se considera disponible en el momento que está listo). Para aprender más acerca de
cuándo un Pod se considera que está listo, ver las pruebas de contenedor.
Vuelta atrás
El campo .spec.rollbackTo se ha quitado de las versiones extensions/v1beta1 y apps/v1beta1 de la API, y ya no se permite en las versiones de la API a partir de apps/v1beta2.
En su caso, se debería usar kubectl rollout undo, tal y como se explicó en Retroceder a una Revisión Previa.
Límite del histórico de revisiones
La historia de revisiones de un Deployment se almacena en los ReplicaSets que este controla.
.spec.revisionHistoryLimit es un campo opcional que indica el número de ReplicaSets viejos a retener
para permitir los retrocesos. Estos ReplicaSets viejos consumen recursos en etcd y rebosan la salida de kubectl get rs.
La configuración de cada revisión de Deployment se almacena en sus ReplicaSets;
por lo tanto, una vez que se elimina el ReplicaSet viejo, se pierde la posibilidad de retroceder a dicha revisión del Deployment.
Por defecto, se retienen hasta 10 ReplicaSets viejos; pero su valor ideal depende de la frecuencia y la estabilidad de los nuevos Deployments.
De forma más específica, si ponemos este campo a cero quiere decir que todos los ReplicaSets viejos con 0 réplicas se limpiarán.
En este caso, el nuevo despliegue del Deployment no se puede deshacer, ya que su historia de revisiones se habrá limpiado.
Pausa
.spec.paused es un campo booleano opcional para pausar y reanudar un Deployment. La única diferencia entre
un Deployment pausado y otro que no lo está es que cualquier cambio al PodTemplateSpec del Deployment pausado
no generará nuevos despliegues mientras esté pausado. Un Deployment se pausa de forma predeterminada cuando se crea.
Alternativa a los Deployments
kubectl rolling update
kubectl rolling update actualiza los Pods y los ReplicationControllers
de forma similar. Pero se recomienda el uso de Deployments porque se declaran del lado del servidor, y proporcionan características adicionales
como la posibilidad de retroceder a revisiones anteriores incluso después de haber terminado una actualización continua.
3.4.2.4 - StatefulSets
Un StatefulSet es el objeto de la API workload que se usa para gestionar aplicaciones con estado.
Nota:
Los StatefulSets son estables (GA) en la versión 1.9.
Gestiona el despliegue y escalado de un conjunto de Pods,
y garantiza el orden y unicidad de dichos Pods.
Al igual que un Deployment, un StatefulSet gestiona Pods
que se basan en una especificación idéntica de contenedor. A diferencia de un Deployment, un
StatefulSet mantiene una identidad asociada a sus Pods. Estos pods se crean a partir de la
misma especificación, pero no pueden intercambiarse; cada uno tiene su propio identificador persistente
que mantiene a lo largo de cualquier re-programación.
Un StatefulSet opera bajo el mismo patrón que cualquier otro controlador.
Se define el estado deseado en un objeto StatefulSet, y el controlador del StatefulSet efectúa
las actualizaciones que sean necesarias para alcanzarlo a partir del estado actual.
Usar StatefulSets
Los StatefulSets son valiosos para aquellas aplicaciones que necesitan uno o más de los siguientes:
Identificadores de red estables, únicos.
Almacenamiento estable, persistente.
Despliegue y escalado ordenado, controlado.
Actualizaciones en línea ordenadas, automatizadas.
De los de arriba, estable es sinónimo de persistencia entre (re)programaciones de Pods.
Si una aplicación no necesita ningún identificador estable o despliegue,
eliminación, o escalado ordenado, deberías desplegar tu aplicación con un controlador que
proporcione un conjunto de réplicas sin estado, como un
Deployment o un
ReplicaSet, ya que están mejor preparados
para tus necesidades sin estado.
Limitaciones
El almacenamiento de un determinado Pod debe provisionarse por un Provisionador de PersistentVolume basado en la storage class requerida, o pre-provisionarse por un administrador.
Eliminar y/o reducir un StatefulSet no eliminará los volúmenes asociados con el StatefulSet. Este comportamiento es intencional y sirve para garantizar la seguridad de los datos, que da más valor que la purga automática de los recursos relacionados del StatefulSet.
Los StatefulSets actualmente necesitan un Servicio Headless como responsable de la identidad de red de los Pods. Es tu responsabilidad crear este Service.
Los StatefulSets no proporcionan ninguna garantía de la terminación de los pods cuando se elimina un StatefulSet. Para conseguir un término de los pods ordenado y controlado en el StatefulSet, es posible reducir el StatefulSet a 0 réplicas justo antes de eliminarlo.
El ejemplo de abajo demuestra los componentes de un StatefulSet:
Un servicio Headless, llamado nginx, se usa para controlar el dominio de red.
Un StatefulSet, llamado web, que tiene una especificación que indica que se lanzarán 3 réplicas del contenedor nginx en Pods únicos.
Un volumeClaimTemplate que proporciona almacenamiento estable por medio de PersistentVolumes provisionados por un provisionador de tipo PersistentVolume.
apiVersion:v1kind:Servicemetadata:name:nginxlabels:app:nginxspec:ports:- port:80name:webclusterIP:Noneselector:app:nginx---apiVersion:apps/v1kind:StatefulSetmetadata:name:webspec:selector:matchLabels:app:nginx# tiene que coincidir con .spec.template.metadata.labelsserviceName:"nginx"replicas:3# por defecto es 1template:metadata:labels:app:nginx# tiene que coincidir con .spec.selector.matchLabelsspec:terminationGracePeriodSeconds:10containers:- name:nginximage:registry.k8s.io/nginx-slim:0.8ports:- containerPort:80name:webvolumeMounts:- name:wwwmountPath:/usr/share/nginx/htmlvolumeClaimTemplates:- metadata:name:wwwspec:accessModes:["ReadWriteOnce"]storageClassName:"my-storage-class"resources:requests:storage:1Gi
Selector de Pod
Debes poner el valor del campo .spec.selector de un StatefulSet para que coincida con las etiquetas de su campo .spec.template.metadata.labels. Antes de Kubernetes 1.8,
el campo .spec.selector se predeterminaba cuando se omitía. A partir de la versión 1.8, si no se especifica un selector de coincidencia de Pods, se produce un error de validación
durante la creación del StatefulSet.
Identidad de Pod
Los Pods de un StatefulSet tienen una identidad única que está formada por un ordinal,
una identidad estable de red, y almacenamiento estable. La identidad se asocia al Pod,
independientemente del nodo en que haya sido (re)programado.
Índice Ordinal
Para un StatefulSet con N réplicas, a cada Pod del StatefulSet se le asignará
un número entero ordinal, desde 0 hasta N-1, y que es único para el conjunto.
ID estable de Red
El nombre de anfitrión (hostname) de cada Pod de un StatefulSet se deriva del nombre del StatefulSet
y del número ordinal del Pod. El patrón para construir dicho hostname
es $(statefulset name)-$(ordinal). Así, el ejemplo de arriba creará tres Pods
denominados web-0,web-1,web-2.
Un StatefulSet puede usar un Servicio Headless
para controlar el nombre de dominio de sus Pods. El nombre de dominio gestionado por este Service tiene la forma:
$(service name).$(namespace).svc.cluster.local, donde "cluster.local" es el nombre de dominio del clúster.
Conforme se crea cada Pod, se le asigna un nombre DNS correspondiente de subdominio, que tiene la forma:
$(podname).$(governing service domain), donde el servicio en funciones se define por el campo
serviceName del StatefulSet.
Como se indicó en la sección limitaciones, la creación del
Servicio Headless
encargado de la identidad de red de los pods es enteramente tu responsabilidad.
Aquí se muestran algunos ejemplos de elecciones de nombres de Cluster Domain, nombres de Service,
nombres de StatefulSet, y cómo impactan en los nombres DNS de los Pods del StatefulSet:
Kubernetes crea un PersistentVolume para cada
VolumeClaimTemplate. En el ejemplo de nginx de arriba, cada Pod recibirá un único PersistentVolume
con una StorageClass igual a my-storage-class y 1 GiB de almacenamiento provisionado. Si no se indica ninguna StorageClass,
entonces se usa la StorageClass por defecto. Cuando un Pod se (re)programa
en un nodo, sus volumeMounts montan los PersistentVolumes asociados con sus
PersistentVolume Claims. Nótese que los PersistentVolumes asociados con los
PersistentVolume Claims de los Pods no se eliminan cuando los Pods, o los StatefulSet se eliminan.
Esto debe realizarse manualmente.
Etiqueta de Nombre de Pod
Cuando el controlador del StatefulSet crea un Pod, añade una etiqueta, statefulset.kubernetes.io/pod-name,
que toma el valor del nombre del Pod. Esta etiqueta te permite enlazar un Service a un Pod específico
en el StatefulSet.
Garantías de Despliegue y Escalado
Para un StatefulSet con N réplicas, cuando los Pods se despliegan, se crean secuencialmente, en orden de {0..N-1}.
Cuando se eliminan los Pods, se terminan en orden opuesto, de {N-1..0}.
Antes de que una operación de escalado se aplique a un Pod, todos sus predecesores deben estar Running y Ready.
Antes de que se termine un Pod, todos sus sucesores deben haberse apagado completamente.
El StatefulSet no debería tener que indicar un valor 0 para el campo pod.Spec.TerminationGracePeriodSeconds.
Esta práctica no es segura y se aconseja no hacerlo. Para una explicación más detallada, por favor echa un vistazo a cómo forzar la eliminación de Pods de un StatefulSet.
Cuando el ejemplo nginx de arriba se crea, se despliegan tres Pods en el orden
web-0, web-1, web-2. web-1 no se desplegará hasta que web-0 no esté
Running y Ready, y web-2 no se desplegará hasta que
web-1 esté Running y Ready. En caso de que web-0 fallase, después de que web-1 estuviera Running y Ready, pero antes
de que se desplegara web-2, web-2 no se desplegaría hasta que web-0 se redesplegase con éxito y estuviera
Running y Ready.
Si un usuario fuera a escalar el ejemplo desplegado parcheando el StatefulSet de forma que
replicas=1, web-2 se terminaría primero. web-1 no se terminaría hasta que web-2
no se hubiera apagado y eliminado por completo. Si web-0 fallase después de que web-2 se hubiera terminado y
apagado completamente, pero antes del término de web-1, entonces web-1 no se terminaría hasta
que web-0 estuviera Running y Ready.
Reglas de Gestión de Pods
En Kubernetes 1.7 y versiones posteriores, el StatefulSet permite flexibilizar sus garantías de ordenación
al mismo tiempo que preservar su garantía de singularidad e identidad a través del campo .spec.podManagementPolicy.
Gestión de tipo OrderedReady de Pods
La gestión de tipo OrderedReady de pods es la predeterminada para los StatefulSets. Implementa el comportamiento
descrito arriba.
Gestión de tipo Parallel de Pods
La gestión de tipo Parallel de pods le dice al controlador del StatefulSet que lance y termine
todos los Pods en paralelo, y que no espere a que los Pods estén Running
y Ready o completamente terminados antes de lanzar o terminar otro Pod.
Estrategias de Actualización
En Kubernetes 1.7 y a posteriori, el campo .spec.updateStrategy del StatefulSet permite configurar
y deshabilitar las actualizaciones automátizadas en línea para los contenedores, etiquetas, peticiones/límites de recursos,
y anotaciones de los Pods del StatefulSet.
On Delete
La estrategia de actualización OnDelete implementa el funcionamiento tradicional (1.6 y previo). Cuando el campo
.spec.updateStrategy.type de un StatefulSet se pone al valor OnDelete, el controlador del StatefulSet no actualizará automáticamente
los Pods del StatefulSet. Los usuarios deben eliminar manualmente los Pods para forzar al controlador a crear
nuevos Pods que reflejen las modificaciones hechas al campo .spec.template del StatefulSet.
Rolling Updates
La estrategia de actualización RollingUpdate implementa una actualización automatizada en línea de los Pods del
StatefulSet. Es la estrategia por defecto cuando el campo .spec.updateStrategy se deja sin valor. Cuando el campo .spec.updateStrategy.type de un StatefulSet
se pone al valor RollingUpdate, el controlador del StatefulSet lo eliminará y recreará cada Pod en el StatefulSet. Procederá
en el mismo orden en que ha terminado los Pod (del número ordinal más grande al más pequeño), actualizando
cada Pod uno por uno. Esperará a que el Pod actualizado esté Running y Ready antes de
actualizar su predecesor.
Particiones
La estrategia de actualización RollingUpdate puede particionarse, indicando el valor del campo
.spec.updateStrategy.rollingUpdate.partition. Si se indica una partición, todos los Pods con un
número ordinal mayor o igual que el de la partición serán actualizados cuando el campo .spec.template
del StatefulSet se actualice. Todos los Pods con un número ordinal que sea menor que el de la partición
no serán actualizados, e incluso si son eliminados, serán recreados con la versión anterior. Si el campo
.spec.updateStrategy.rollingUpdate.partition de un StatefulSet es mayor que el valor del campo .spec.replicas,
las modificaciones al campo .spec.template no se propagarán a sus Pods.
En la mayoría de ocasiones, no necesitarás usar una partición, pero pueden resultar útiles si quieres preparar una actualización,
realizar un despliegue tipo canary, o llevar a cabo un despliegue en fases.
Retroceso Forzado
Cuando se usa Actualizaciones en línea con el valor de la
Regla de Gestión de Pod (OrderedReady) por defecto,
es posible acabar en un estado inconsistente que requiera de una intervención manual para arreglarlo.
Si actualizas la plantilla Pod a una configuración que nunca llega a Running y
Ready (por ejemplo, debido a un binario incorrecto o un error de configuración a nivel de aplicación),
el StatefulSet detendrá el despliegue y esperará.
En este estado, no es suficiente con revertir la plantilla Pod a la configuración buena.
Debido a un problema conocido,
el StatefulSet seguirá esperando a que los Pod estropeados se pongan en Ready
(lo que nunca ocurre) antes de intentar revertirla a la configuración que funcionaba.
Antes de revertir la plantilla, debes también eliminar cualquier Pod que el StatefulSet haya
intentando ejecutar con la configuración incorrecta.
El StatefulSet comenzará entonces a recrear los Pods usando la plantilla revertida.
Un DaemonSet garantiza que todos (o algunos) de los nodos ejecuten una copia de un Pod. Conforme se añade más nodos
al clúster, nuevos Pods son añadidos a los mismos. Conforme se elimina nodos del clúster, dichos Pods se destruyen.
Al eliminar un DaemonSet se limpian todos los Pods que han sido creados.
Algunos casos de uso típicos de un DaemonSet son:
Ejecutar un proceso de almacenamiento en el clúster.
Ejecutar un proceso de recolección de logs en cada nodo.
Ejecutar un proceso de monitorización de nodos en cada nodo.
De forma básica, se debería usar un DaemonSet, cubriendo todos los nodos, por cada tipo de proceso.
En configuraciones más complejas se podría usar múltiples DaemonSets para un único tipo de proceso,
pero con diferentes parámetros y/o diferentes peticiones de CPU y memoria según el tipo de hardware.
Escribir una especificación de DaemonSet
Crear un DaemonSet
Un DaemonSet se describe por medio de un archivo YAML. Por ejemplo, el archivo daemonset.yaml de abajo describe un DaemonSet que ejecuta la imagen Docker de fluentd-elasticsearch:
El campo .spec.template es uno de los campos obligatorios de la sección .spec.
El campo .spec.template es una plantilla Pod. Tiene exactamente el mismo esquema que un Pod,
excepto por el hecho de que está anidado y no tiene los campos apiVersion o kind.
Además de los campos obligatorios de un Pod, la plantilla Pod para un DaemonSet debe especificar
las etiquetas apropiadas (ver selector de pod).
Una plantilla Pod para un DaemonSet debe tener una RestartPolicy
igual a Always, o no indicarse, lo cual asume por defecto el valor Always.
Selector de Pod
El campo .spec.selector es un selector de pod. Funciona igual que el campo .spec.selector
de un Job.
A partir de Kubernetes 1.8, se debe configurar un selector de pod que coincida con las
etiquetas definidas en el .spec.template. Así, el selector de pod ya no asume valores por defecto cuando no se indica.
Dichos valores por defecto no eran compatibles con kubectl apply. Además, una vez que se ha creado el DaemonSet,
su campo .spec.selector no puede alterarse porque, si fuera el caso, ello podría resultar
en Pods huérfanos, lo cual confundiría a los usuarios.
El campo .spec.selector es un objeto que, a su vez, consiste en dos campos:
matchLabels - funciona igual que el campo .spec.selector de un ReplicationController.
matchExpressions - permite construir selectores más sofisticados indicando la clave,
la lista de valores y un operador para relacionar la clave y los valores.
Cuando se configura ambos campos, el resultado es conjuntivo (AND).
Si se especifica el campo .spec.selector, entonces debe coincidir con el campo .spec.template.metadata.labels. Aquellas configuraciones que no coinciden, son rechazadas por la API.
Además, normalmente no se debería crear ningún Pod con etiquetas que coincidan con el selector, bien sea de forma directa, via otro
DaemonSet, o via otro controlador como un ReplicaSet. De ser así, el controlador del DaemonSet
pensará que dichos Pods fueron en realidad creados por él mismo. Kubernetes, en cualquier caso, no te impide realizar esta
operación. Un caso donde puede que necesites hacer esto es cuando quieres crear manualmente un Pod con un valor diferente en un nodo para pruebas.
Ejecutar Pods sólo en Nodos seleccionados
Si se configura un .spec.template.spec.nodeSelector, entonces el controlador del DaemonSet
creará los Pods en aquellos nodos que coincidan con el selector de nodo indicado.
De forma similar, si se configura una .spec.template.spec.affinity,
entonces el controlador del DaemonSet creará los Pods en aquellos nodos que coincidan con la afinidad de nodo indicada.
Si no se configura ninguno de los dos, entonces el controlador del DaemonSet creará los Pods en todos los nodos.
Cómo se planifican los Pods procesos
Planificados por el controlador del DaemonSet (deshabilitado por defecto a partir de 1.12)
Normalmente, el planificador de Kubernetes determina la máquina donde se ejecuta un Pod. Sin embargo, los Pods
creados por el controlador del DaemonSet ya tienen la máquina seleccionada (puesto que cuando se crea el Pod,
se indica el campo .spec.nodeName, y por ello el planificador los ignora). Por lo tanto:
El controlador del DaemonSet no tiene en cuenta el campo unschedulable de un nodo.
El controlador del DaemonSet puede crear Pods incluso cuando el planificador no ha arrancado, lo cual puede ayudar en el arranque del propio clúster.
Planificados por el planificador por defecto de Kubernetes (habilitado por defecto desde 1.12)
FEATURE STATE:Kubernetes v1.31 [beta]
Un DaemonSet garantiza que todos los nodos elegibles ejecuten una copia de un Pod.
Normalmente, es el planificador de Kubernetes quien determina el nodo donde se ejecuta un Pod. Sin embargo,
los pods del DaemonSet son creados y planificados por el mismo controlador del DaemonSet.
Esto introduce los siguientes inconvenientes:
Comportamiento inconsistente de los Pods: Los Pods normales que están esperando
a ser creados, se encuentran en estado Pending, pero los pods del DaemonSet no pasan por el estado Pending.
Esto confunde a los usuarios.
La prioridad y el comportamiento de apropiación de Pods
se maneja por el planificador por defecto. Cuando se habilita la contaminación, el controlador del DaemonSet
tomará la decisiones de planificación sin considerar ni la prioridad ni la contaminación del pod.
ScheduleDaemonSetPods permite planificar DaemonSets usando el planificador por defecto
en vez del controlador del DaemonSet, añadiendo la condición NodeAffinity
a los pods del DaemonSet, en vez de la condición .spec.nodeName. El planificador por defecto
se usa entonces para asociar el pod a su servidor destino. Si la afinidad de nodo del
pod del DaemonSet ya existe, se sustituye. El controlador del DaemonSet sólo realiza
estas operaciones cuando crea o modifica los pods del DaemonSet, y no se realizan cambios
al spec.template del DaemonSet.
Adicionalmente, se añade de forma automática la tolerancia node.kubernetes.io/unschedulable:NoSchedule
a los Pods del DaemonSet. Así, el planificador por defecto ignora los nodos
unschedulable cuando planifica los Pods del DaemonSet.
Contaminaciones (taints) y Tolerancias (tolerations)
A pesar de que los Pods de proceso respetan las
contaminaciones y tolerancias,
la siguientes tolerancias son añadidas a los Pods del DaemonSet de forma automática
según las siguientes características:
Clave de tolerancia
Efecto
Versión
Descripción
node.kubernetes.io/not-ready
NoExecute
1.13+
Los pods del DaemonSet no son expulsados cuando hay problemas de nodo como una partición de red.
node.kubernetes.io/unreachable
NoExecute
1.13+
Los pods del DaemonSet no son expulsados cuando hay problemas de nodo como una partición de red.
node.kubernetes.io/disk-pressure
NoSchedule
1.8+
Los pods del DaemonSet no son expulsados cuando hay problemas de nodo como la falta de espacio en disco.
node.kubernetes.io/memory-pressure
NoSchedule
1.8+
Los pods del DaemonSet no son expulsados cuando hay problemas de nodo como la falta de memoria.
node.kubernetes.io/unschedulable
NoSchedule
1.12+
Los pods del DaemonSet toleran los atributos unschedulable del planificador por defecto.
node.kubernetes.io/network-unavailable
NoSchedule
1.12+
Los pods del DaemonSet, que usan la red del servidor anfitrión, toleran los atributos network-unavailable del planificador por defecto.
Comunicarse con los Pods de los DaemonSets
Algunos patrones posibles para la comunicación con los Pods de un DaemonSet son:
Push: Los Pods del DaemonSet se configuran para enviar actualizaciones a otro servicio,
como una base de datos de estadísticas. No tienen clientes.
NodeIP y Known Port: Los Pods del DaemonSet pueden usar un hostPort, de forma que se les puede alcanzar via las IPs del nodo. Los clientes conocen la lista de IPs del nodo de algún modo,
y conocen el puerto acordado.
DNS: Se crea un servicio headless con el mismo selector de pod,
y entonces se descubre a los DaemonSets usando los recursos endpoints o mediante múltiples registros de tipo A en el DNS.
Service: Se crea un servicio con el mismo selector de Pod, y se usa el servicio para llegar al proceso de uno de los nodos. (No hay forma de determinar el nodo exacto.)
Actualizar un DaemonSet
Si se cambian las etiquetas de nodo, el DaemonSet comenzará de forma inmediata a añadir Pods a los nuevos nodos que coincidan y a eliminar
los Pods de aquellos nuevos nodos donde no coincidan.
Puedes modificar los Pods que crea un DaemonSet. Sin embargo, no se permite actualizar todos los campos de los Pods.
Además, el controlador del DaemonSet utilizará la plantilla original la próxima vez que se cree un nodo (incluso con el mismo nombre).
Puedes eliminar un DaemonSet. Si indicas el parámetro --cascade=false al usar kubectl,
entonces los Pods continuarán ejecutándose en los nodos. Así, puedes crear entonces un nuevo DaemonSet con una plantilla diferente.
El nuevo DaemonSet con la plantilla diferente reconocerá a todos los Pods existentes que tengan etiquetas coincidentes y
no modificará o eliminará ningún Pod aunque la plantilla no coincida con los Pods desplegados.
Entonces, deberás forzar la creación del nuevo Pod eliminando el Pod mismo o el nodo.
Aunque es perfectamente posible ejecutar procesos arrancándolos directamente en un nodo (ej. usando
init, upstartd, o systemd), existen numerosas ventajas si se realiza via un DaemonSet:
Capacidad de monitorizar y gestionar los logs de los procesos del mismo modo que para las aplicaciones.
Mismo lenguaje y herramientas de configuración (ej. plantillas de Pod, kubectl) tanto para los procesos como para las aplicaciones.
Los procesos que se ejecutan en contenedores con límitaciones de recursos aumentan el aislamiento entre dichos procesos y el resto de contenedores de aplicaciones.
Sin embargo, esto también se podría conseguir ejecutando los procesos en un contenedor en vez de un Pod
(ej. arrancarlos directamente via Docker).
Pods individuales
Es posible crear Pods directamente sin indicar el nodo donde ejecutarse. Sin embargo,
la ventaja del DaemonSet es que sustituye los Pods que se eliminan o terminan por cualquier razón, como en el caso
de un fallo del nodo o una intervención disruptiva de mantenimiento del nodo, como la actualización del kernel.
Por esta razón, deberías siempre utilizar un DaemonSet en vez de crear Pods individuales.
Pods estáticos
Es posible crear Pods a partir de archivos en el directorio donde está escuchando el proceso Kubelet.
Este tipo de Pods se denomina pods estáticos.
A diferencia del DaemonSet, los Pods estáticos no se pueden gestionar con kubectl
o cualquier otro cliente de la API de Kubernetes. Los Pods estáticos no dependen del apiserver, lo cual los hace
convenientes para el arranque inicial del clúster. Además, puede que los Pods estáticos se deprecien en el futuro.
Deployments
Los DaemonSets son similares a los Deployments en el sentido que
ambos crean Pods, y que dichos Pods tienen procesos que no se espera que terminen (ej. servidores web,
servidores de almacenamiento).
Utiliza un Deployment para definir servicios sin estado, como las interfaces de usuario, donde el escalado vertical y horizontal
del número de réplicas y las actualizaciones continuas son mucho más importantes que el control exacto del servidor donde se ejecuta el Pod.
Utiliza un DaemonSet cuando es importante que una copia de un Pod siempre se ejecute en cada uno de los nodos,
y cuando se necesite que arranque antes que el resto de Pods.
3.4.2.6 - Recolección de Basura
El papel del recolector de basura de Kubernetes es el de eliminar determinados objetos
que en algún momento tuvieron un propietario, pero que ahora ya no.
Propietarios y subordinados
Algunos objetos de Kubernetes son propietarios de otros objetos. Por ejemplo, un ReplicaSet
es el propietario de un conjunto de Pods. Los objetos que se poseen se denominan subordinados del
objeto propietario. Cada objeto subordinado tiene un campo metadata.ownerReferences
que apunta al objeto propietario.
En ocasiones, Kubernetes pone el valor del campo ownerReference automáticamente.
Por ejemplo, cuando creas un ReplicaSet, Kubernetes automáticamente pone el valor del campo
ownerReference de cada Pod en el ReplicaSet. A partir de la versión 1.8, Kubernetes
automáticamente pone el valor de ownerReference para los objetos creados o adoptados
por un ReplicationController, ReplicaSet, StatefulSet, DaemonSet, Deployment, Job
y CronJob.
También puedes configurar las relaciones entre los propietarios y sus subordinados
de forma manual indicando el valor del campo ownerReference.
Aquí se muestra un archivo de configuración para un ReplicaSet que tiene tres Pods:
No se recomienda el uso de OwnerReferences entre Namespaces por diseño. Esto quiere decir que:
Los subordinados dentro del ámbito de Namespaces sólo pueden definir propietarios en ese mismo Namespace,
y propietarios dentro del ámbito de clúster.
Los subordinados dentro del ámbito del clúster sólo pueden definir propietarios dentro del ámbito del clúster, pero no
propietarios dentro del ámbito de Namespaces.
Controlar cómo el recolector de basura elimina los subordinados
Cuando eliminas un objeto, puedes indicar si sus subordinados deben eliminarse también
de forma automática. Eliminar los subordinados automáticamente se denomina borrado en cascada. Hay dos modos de borrado en cascada: en segundo plano y en primer plano.
Si eliminas un objeto sin borrar sus subordinados de forma automática,
dichos subordinados se convierten en huérfanos.
Borrado en cascada en primer plano
En el borrado en cascada en primer plano, el objeto raíz primero entra en un estado
llamado "deletion in progress". En este estado "deletion in progress",
se cumplen las siguientes premisas:
El objeto todavía es visible a través de la API REST
Se pone el valor del campo deletionTimestamp del objeto
El campo metadata.finalizers del objeto contiene el valor "foregroundDeletion".
Una vez que se pone el estado "deletion in progress", el recolector de basura elimina
los subordinados del objeto. Una vez que el recolector de basura ha eliminado todos
los subordinados "bloqueantes" (los objetos con ownerReference.blockOwnerDeletion=true), elimina
el objeto propietario.
Cabe mencionar que usando "foregroundDeletion", sólo los subordinados con valor en
ownerReference.blockOwnerDeletion bloquean la eliminación del objeto propietario.
A partir de la versión 1.7, Kubernetes añadió un controlador de admisión
que controla el acceso de usuario cuando se intenta poner el campo blockOwnerDeletion a true
con base a los permisos de borrado del objeto propietario, de forma que aquellos subordinados no autorizados
no puedan retrasar la eliminación del objeto propietario.
Si un controlador (como un Deployment o un ReplicaSet) establece el valor del campo ownerReferences de un objeto,
se pone blockOwnerDeletion automáticamente y no se necesita modificar de forma manual este campo.
Borrado en cascada en segundo plano
En el borrado en cascada en segundo plano, Kubernetes elimina el objeto propietario
inmediatamente y es el recolector de basura quien se encarga de eliminar los subordinados en segundo plano.
Configurar la regla de borrado en cascada
Para controlar la regla de borrado en cascada, configura el campo propagationPolicy
del parámetro deleteOptions cuando elimines un objeto. Los valores posibles incluyen "Orphan",
"Foreground", o "Background".
Antes de la versión 1.9 de Kubernetes, la regla predeterminada del recolector de basura para la mayoría de controladores era orphan.
Esto incluía al ReplicationController, ReplicaSet, StatefulSet, DaemonSet, y al Deployment.
Para los tipos dentro de las versiones de grupo extensions/v1beta1, apps/v1beta1, y apps/v1beta2, a menos que
se indique de otra manera, los objetos subordinados se quedan huérfanos por defecto.
En Kubernetes 1.9, para todos los tipos de la versión de grupo apps/v1, los objetos subordinados se eliminan por defecto.
Aquí se muestra un ejemplo que elimina los subordinados en segundo plano:
kubectl también permite el borrado en cascada.
Para eliminar los subordinados automáticamente, utiliza el parámetro --cascade a true.
Usa false para subordinados huérfanos. Por defecto, el valor de --cascade
es true.
Aquí se muestra un ejemplo de huérfanos de subordinados de un ReplicaSet:
Antes de la versión 1.7, cuando se usaba el borrado en cascada con Deployments se debía usar propagationPolicy: Foreground
para eliminar no sólo los ReplicaSets creados, sino también sus Pods correspondientes. Si este tipo de propagationPolicy
no se usa, solo se elimina los ReplicaSets, y los Pods se quedan huérfanos.
Ver kubeadm/#149 para más información.
3.4.2.7 - Controlador TTL para Recursos Finalizados
FEATURE STATE:Kubernetes v1.12 [alpha]
El controlador TTL proporciona un mecanismo TTL para limitar el tiempo de vida de los objetos
de recurso que ya han terminado su ejecución. El controlador TTL sólo se ocupa de los
Jobs por el momento,
y puede que se extienda para gestionar otros recursos que terminen su ejecución,
como los Pods y los recursos personalizados.
Descargo de responsabilidad Alpha: esta característica está actualmente en versión alpha, y puede habilitarse mediante el
feature gateTTLAfterFinished.
Controlador TTL
El controlador TTL sólo soporta los Jobs por ahora. Un operador del clúster puede usar esta funcionalidad para limpiar
los Jobs terminados (bien Complete o Failed) automáticamente especificando el valor del campo
.spec.ttlSecondsAfterFinished del Job, como en este
ejemplo.
El controlador TTL asumirá que un recurso es candidato a ser limpiado
TTL segundos después de que el recurso haya terminado; dicho de otra forma, cuando el TTL haya expirado.
Cuando el controlador TTL limpia un recursos, lo elimina en cascada, esto es, borra
sus objetos subordinados juntos. Nótese que cuando se elimina un recurso,
se respetan las garantías de su ciclo de vida, como con los finalizadores.
Los segundos TTL pueden ser configurados en cualquier momento. Aquí se muestran algunos ejemplos para poner valores al campo
.spec.ttlSecondsAfterFinished de un Job:
Indicando este campo en el manifiesto de los recursos, de forma que se pueda limpiar un Job
automáticamente un tiempo después de que haya finalizado.
Haciendo que el campo de los recursos existentes, ya finalizados, adopte esta nueva característica.
Usando un mutating admission webhook
para poner el valor de este campo dinámicamente en el momento de la creación del recursos. Los administradores del clúster pueden
usar este enfoque para forzar una regla TTL para los recursos terminados.
Usando un
mutating admission webhook
para poner el valor de este campo dinámicamente después de que el recurso haya terminado,
y eligiendo diferentes valores TTL basados en los estados de los recursos, etiquetas, etc.
Advertencia
Actualizar los segundos TTL
Cabe señalar que el período TTL , ej. campo .spec.ttlSecondsAfterFinished de los Jobs,
puede modificarse después de que el recurso haya sido creado o terminado. Sin embargo, una vez
que el Job se convierte en candidato para ser eliminado (cuando el TTL ha expirado), el sistema
no garantiza que se mantendrán los Jobs, incluso si una modificación para extender el TTL
devuelve una respuesta API satisfactoria.
Diferencia horaria
Como el controlador TTL usa marcas de fecha/hora almacenadas en los recursos de Kubernetes
para determinar si el TTL ha expirado o no, esta funcionalidad es sensible a las
diferencias horarias del clúster, lo que puede provocar que el controlador TTL limpie recursos
en momentos equivocados.
En Kubernetes, se necesita ejecutar NTP en todos los nodos
(ver #6159)
para evitar este problema. Los relojes no siempre son correctos, pero la diferencia debería ser muy pequeña.
Ten presente este riesgo cuando pongas un valor distinto de cero para el TTL.
Un Job crea uno o más Pods y se asegura de que un número específico de ellos termina de forma satisfactoria.
Conforme los pods terminan satisfactoriamente, el Job realiza el seguimiento de las ejecuciones satisfactorias.
Cuando se alcanza un número específico de ejecuciones satisfactorias, la tarea (esto es, el Job) se completa.
Al eliminar un Job se eliminan los Pods que haya creado.
Un caso simple de uso es crear un objeto Job para que se ejecute un Pod de manera fiable hasta el final.
El objeto Job arrancará un nuevo Pod si el primer Pod falla o se elimina (por ejemplo
como consecuencia de un fallo de hardware o un reinicio en un nodo).
También se puede usar un Job para ejecutar múltiples Pods en paralelo.
Ejecutar un Job de ejemplo
Aquí se muestra un ejemplo de configuración de Job. Este ejemplo calcula los primeros 2000 decimales de π y los imprime por pantalla.
Tarda unos 10s en completarse.
Para ver los Pods de un Job que se han completado, usa kubectl get pods.
Para listar todos los Pods que pertenecen a un Job de forma que sea legible, puedes usar un comando como:
pods=$(kubectl get pods --selector=job-name=pi --output=jsonpath='{.items[*].metadata.name}')echo$pods
pi-aiw0a
En este caso, el selector es el mismo que el selector del Job. La opción --output=jsonpath indica un expresión
que simplemente obtiene el nombre de cada Pod en la lista devuelta.
El campo .spec.template es el único campo obligatorio de .spec.
El campo .spec.template es una plantilla Pod. Tiene exactamente el mismo esquema que un pod,
excepto por el hecho de que está anidado y no tiene el campo apiVersion o kind.
Además de los campos olbigatorios de un Pod, una plantilla Pod de un Job debe indicar las etiquetas apropiadas
(ver selector de pod) y una regla de reinicio apropiada.
Sólo se permite los valores Never o OnFailure para RestartPolicy.
Selector de Pod
El campo .spec.selector es opcional. En la práctica mayoría de los casos no deberías configurarlo.
Mira la sección sobre configurar tu propio selector de pod.
Jobs en paralelo
Hay tres tipos principales de tarea aptos para ejecutarse como un Job:
Jobs no paralelos
normalmente, sólo se arranca un Pod, a menos que el Pod falle.
el Job se completa tan pronto como su Pod termine de forma satisfactoria.
Jobs en paralelo con un cupo fijo de terminación:
se configura un valor positivo distinto de cero para el campo .spec.completions.
el Job representa la tarea en general, y se completa cuando hay una ejecución satisfactoria de un Pod por cada valor dentro del rango de 1 a .spec.completions.
no implementado todavía: A cada Pod se le pasa un índice diferenente dentro del rango de 1 a .spec.completions.
Jobs en paralelo con una cola de trabajo:
no se especifica el campo .spec.completions, por defecto .spec.parallelism.
los Pods deben coordinarse entre ellos mismos o a través de un servicio externo que determine quién debe trabajar en qué.
Por ejemplo, un Pod podría ir a buscar un lote de hasta N ítems de una cola de trabajo.
cada Pod es capaz de forma independiente de determinar si sus compañeros han terminado o no, y como consecuencia el Job entero ha terminado.
cuando cualquier Pod del Job termina con éxito, no se crean nuevos Pods.
una vez que al menos uno de los Pods ha terminado con éxito y todos los Pods han terminado, entonces el Job termina con éxito.
una vez que cualquier Pod ha terminado con éxito, ningún otro Pod debería continuar trabajando en la misma tarea o escribiendo ningún resultado. Todos ellos deberían estar en proceso de terminarse.
En un Job no paralelo, no debes indicar el valor de .spec.completions ni .spec.parallelism. Cuando ambos se dejan
sin valor, ambos se predeterminan a 1.
En un Job con cupo fijo de terminación, deberías poner el valor de .spec.completions al número de terminaciones que se necesiten.
Puedes dar un valor a .spec.parallelism, o dejarlo sin valor, en cuyo caso se predetermina a 1.
En un Job con cola de trabajo, no debes indicar el valor de .spec.completions, y poner el valor de .spec.parallelism a
un entero no negativo.
Para más información acerca de cómo usar los distintos tipos de Job, ver la sección de patrones de job.
Controlar el paralelismo
El paralelismo solicitado (.spec.parallelism) puede usar cualquier valor no negativo.
Si no se indica, se predeterminad a 1.
Si se indica como 0, entonces el Job se pausa de forma efectiva hasta que se incremente.
El paralelismo actual (número de pods ejecutándose en cada momento) puede que sea mayor o menor que el solicitado,
por los siguientes motivos:
Para los Jobs con cupo fijo de terminaciones, el número actual de pods ejecutándose en paralelo no excede el número de terminaciones pendientes.
Los valores superiores de .spec.parallelism se ignoran.
Para los Jobs con cola de trabajo, no se arranca nuevos Pods después de que cualquier Pod se haya completado -- sin embargo, se permite que se completen los Pods pendientes.
Cuando el controlador no ha tenido tiempo para reaccionar.
Cuando el controlador no pudo crear los Pods por el motivo que fuera (falta de ResourceQuota, falta de permisos, etc.),
entonces puede que haya menos pods que los solicitados.
El controlador puede que regule la creación de nuevos Pods debido al excesivo número de fallos anteriores en el mismo Job.
Cuando un Pod se para de forma controlada, lleva tiempo pararlo.
Gestionar Fallos de Pod y Contenedor
Un contenedor de un Pod puede fallar por cualquier motivo, como porque el proceso que se estaba ejecutando termina con un código de salida distinto de cero,
o porque se mató el contenedor por exceder un límite de memoria, etc. Si esto ocurre, y se tiene
.spec.template.spec.restartPolicy = "OnFailure", entonces el Pod permance en el nodo,
pero el contenedor se vuelve a ejecutar. Por lo tanto, tu aplicación debe poder gestionar el caso en que se reinicia de forma local,
o bien especificar .spec.template.spec.restartPolicy = "Never".
Ver el ciclo de vida de un pod para más información sobre restartPolicy.
Un Pod entero puede también fallar por cualquier motivo, como cuando se expulsa al Pod del nodo
(porque el nodo se actualiza, reinicia, elimina, etc.), o si un contenedor del Pod falla
cuando .spec.template.spec.restartPolicy = "Never". Cuando un Pod falla, entonces el controlador del Job
arranca un nuevo Pod. Esto quiere decir que tu aplicación debe ser capaz de gestionar el caso en que se reinicia en un nuevo pod.
En particular, debe ser capaz de gestionar los ficheros temporales, los bloqueos, los resultados incompletos, y cualquier otra dependencia
de ejecuciones previas.
Nótese que incluso si se configura .spec.parallelism = 1 y .spec.completions = 1 y
.spec.template.spec.restartPolicy = "Never", el mismo programa puede arrancarse dos veces.
Si se especifica .spec.parallelism y .spec.completions con valores mayores que 1,
entonces puede que haya múltiples pods ejecutándose a la vez. Por ello, tus pods deben tolerar la concurrencia.
Regla de retroceso de Pod por fallo
Hay situaciones en que quieres que el Job falle después de intentar ejecutarlo unas cuantas veces debido
a un error lógico en la configuración, etc.
Para hacerlo, pon el valor de .spec.backoffLimit al número de reintentos que quieres
antes de considerar el Job como fallido. El límite de retroceso se predetermina a 6.
Los Pods fallidos asociados al Job son recreados por el controlador del Job con un
retroceso exponencial (10s, 20s, 40s ...) limitado a seis minutos. El contador
de retroceso se resetea si no aparecen Pods fallidos antes del siguiente chequeo de estado del Job.
Nota:
El problema #54870 todavía existe en las versiones de Kubernetes anteriores a la versión 1.12
Terminación y Limpieza de un Job
Cuando un Job se completa, ya no se crea ningún Pod, pero tampoco se elimina los Pods. Guardarlos permite
ver todavía los logs de los pods acabados para comprobar errores, avisos, o cualquier otro resultado de diagnóstico.
El objeto job también se conserva una vez que se ha completado para que se pueda ver su estado. Es decisión del usuario si elimina
los viejos jobs después de comprobar su estado. Eliminar el job con el comando kubectl (ej. kubectl delete jobs/pi o kubectl delete -f ./job.yaml).
Cuando eliminas un job usando el comando kubectl, todos los pods que creó se eliminan también.
Por defecto, un Job se ejecutará de forma ininterrumpida a menos que uno de los Pods falle, en cuyo caso el Job se fija en el valor de
.spec.backoffLimit descrito arriba. Otra forma de acabar un Job es poniéndole un vencimiento activo.
Haz esto poniendo el valor del campo .spec.activeDeadlineSeconds del Job a un número de segundos.
El campo activeDeadlineSeconds se aplica a la duración del job, independientemente de cuántos Pods se hayan creado.
Una vez que el Job alcanza activeDeadlineSeconds, se terminan todos sus Pods y el estado del Job se pone como type: Failed con reason: DeadlineExceeded.
Fíjate que el campo .spec.activeDeadlineSeconds de un Job tiene precedencia sobre el campo .spec.backoffLimit.
Por lo tanto, un Job que está reintentando uno o más Pods fallidos no desplegará nuevos Pods una vez que alcance el límite de tiempo especificado por activeDeadlineSeconds,
incluso si todavía no se ha alcanzado el backoffLimit.
Fíjate que tanto la especificación del Job como la especificación de la plantilla Pod
dentro del Job tienen un campo activeDeadlineSeconds. Asegúrate que pones el valor de este campo de forma adecuada.
Limpiar los Jobs terminados automáticamente
Normalmente, los Jobs que han terminado ya no se necesitan en el sistema. Conservarlos sólo añade
más presión al servidor API. Si dichos Jobs no se gestionan de forma directa por un controlador de más alto nivel,
como los CronJobs, los Jobs pueden
limpiarse por medio de CronJobs en base a la regla de limpieza basada en capacidad que se haya especificado.
Mecanismo TTL para Jobs terminados
FEATURE STATE:Kubernetes v1.12 [alpha]
Otra forma de limpiar los Jobs terminados (bien Complete o Failed)
de forma automática es usando un mecanismo TTL proporcionado por un
controlador TTL de recursos finalizados,
indicando el valor .spec.ttlSecondsAfterFinished del Job.
Cuando el controlador TTL limpia el Job, lo eliminará en cascada,
esto es, eliminará sus objetos subordinados, como Pods, junto con el Job. Nótese
que cuando se elimina el Job, sus garantías de ciclo de vida, como los finalizadores,
se tendrán en cuenta.
Aquí el Job pi-with-ttl será candidato a ser automáticamente eliminado, 100
segundos después de que termine.
Si el campo se pone a 0, el Job será candidato a ser automáticamente eliminado
inmediatamente después de haber terminado. Si no se pone valor al campo, este Job no será eliminado
por el controlador TTL una vez concluya.
Nótese que este mecanismo TTL está todavía en alpha, a través de la característica denominada TTLAfterFinished.
Para más información, ver la documentación del controlador TTL para
recursos terminados.
Patrones de Job
El objeto Job puede usarse para dar soporte a la ejecución fiable de Pods en paralelo. El objeto Job
no se diseñó para dar soporte a procesos paralelos estrechamente comunicados, como los que comúnmente
se encuentran en la computación científica. Eso sí, permite el proceso paralelo de un conjunto de ítems de trabajo independientes, pero relacionados entre sí.
Estos pueden ser correos a enviar, marcos a renderizar, archivos a codificar, rangos de claves en una base de datos NoSQL a escanear, y demás.
En un sistema complejo, puede haber múltiples diferentes conjuntos de ítems de trabajo. Aquí sólo se está
considerando un conjunto de ítems de trabajo que el usuario quiere gestionar de forma conjunta — un proceso por lotes.
Hay varios patrones diferentes para computación en paralelo, cada uno con sus fortalezas y sus debilidades.
Los sacrificios a tener en cuenta son:
Un objeto Job para cada ítem de trabajo vs. un objeto Job simple para todos los ítems de trabajo. El último es mejor
para grandes números de ítems de trabajo. El primero añade sobrecarga para el usuario y para el sistema
al tener que gestionar grandes números de objetos Job.
El número de pods creados es igual al número de ítems de trabajo vs. cada Pod puede procesar múltiplese ítems de trabajo.
El primero típicamente requiere menos modificaciones al código existente y a los contenedores.
El último es mejor cuanto mayor sea el número de ítems de trabajo, por las mismas razones que antes..
Varios enfoques usan una cola de trabajo. Ello requiere ejecutar un servicio de colas,
y modificaciones a las aplicaciones o contenedores existentes para que hagan uso de la cola de trabajo.
Otras estrategias son más fáciles de adaptar a una aplicación ya usando contenedores.
Los sacrificios a tener en cuenta se indican a continuación, donde las columnas 2 a 4 representan los sacrificios de arriba.
Los nombres de los patrones son también enlaces a ejemplos e información más detallada.
Cuando se especifican terminaciones con .spec.completions, cada Pod creado por el controlado del Job
tiene un specidéntico.
Esto significa que todos los pods de una tarea tendrán la misma línea de comandos y la
misma imagne, los mismo volúmenes, y (casi) las mismas variables de entorno.
Estos patrones otorgan diferentes formas de organizar los pods para que trabajen en cosas distintas.
Esta tabla muestra la configuración necesaria para .spec.parallelism y .spec.completions para cada uno de los patrones.
Aquí, T es el número de ítems de trabajo.
Normalmente, cuando creas un objeto Job, no especificas el campo .spec.selector.
La lógica por defecto del sistema añade este campo cuando se crea el Job.
Se elige un valor de selector que no se entremezcle con otras tareas.
Sin embargo, en algunos casos, puede que necesites sobreescribir este selector que se configura de forma automática.
Para ello, puedes indicar el valor de .spec.selector en el Job.
Pero ten mucho cuidado cuando lo hagas. Si configuras un selector de etiquta que no
es único para los pods de ese Job, y que selecciona Pods que no tienen que ver,
entonces estos últimos pueden ser eliminados, o este Job puede contar los otros
Pods para terminarse, o uno o ambos Jobs pueden negarse a crear Pods o ejecutarse hasta el final.
Si se elige un selector que no es único, entonces otros controladores (ej. ReplicationController)
y sus Pods puede comportarse de forma impredecibles también. Kubernetes no te impide cometer un error
especificando el .spec.selector.
Aquí se muestra un ejemplo de un caso en que puede que necesites usar esta característica.
Digamos que el Job viejo todavía está ejeuctándose. Quieres que los Pods existentes
sigan corriendo, pero quieres que el resto de los Pods que se creen
usen una plantilla pod diferente y que el Job tenga un nombre nuevo.
Como no puedes modificar el Job porque esos campos no son modificables, eliminas el Job old,
pero dejas sus pods ejecutándose mediante el comando kubectl delete jobs/old --cascade=false.
Antes de eliminarlo, apúntate el selector actual que está usando:
Entonces, creas un nuevo Job con el nombre nuevo y le configuras explícitamente el mismo selector.
Puesto que los Pods existentes tienen la etiqueta job-uid=a8f3d00d-c6d2-11e5-9f87-42010af00002,
son controlados por el Job nuevo igualmente.
Necesitas configurar manualSelector: true en el nuevo Job, ya qye no estás usando
el selector que normalmente se genera de forma automática por el sistema.
El mismo Job nuevo tendrá un uid distinto a a8f3d00d-c6d2-11e5-9f87-42010af00002.
Poniendo manualSelector: true le dice al sistema que sabes lo que estás haciendo
y que te permita hacer este desajuste.
Alternativas
Pods simples
Cuando el nodo donde un Pod simple se estaba ejecutando se reinicia o falla, dicho pod se termina
y no será reinicado. Sin embargo, un Job creará nuevos Pods para sustituir a los que se han terminando.
Por esta razón, se recomienda que se use un Job en vez de un Pod simple, incluso si tu aplicación
sólo necesita un único Pod.
Replication Controller
Los Jobs son complementarios a los Replication Controllers.
Un Replication Controller gestiona aquellos Pods que se espera que no terminen (ej. servidores web), y un Job
gestiona aquellos Pods que se espera que terminen (ej. tareas por lotes).
Como se discutió en el Ciclo de vida de un Pod, un Jobsólo es apropiado
para aquellos pods con RestartPolicy igual a OnFailure o Never.
(Nota: Si RestartPolicy no se pone, el valor predeterminado es Always.)
Job simple arranca que arranca un controlador de Pod
Otro patrón es aquel donde un Job simple crea un Pod que, a su vez, crea otros Pods, actuando como una especie
de controlador personalizado para esos Pods. Esto da la máxima flexibilidad, pero puede que
cueste un poco más de entender y ofrece menos integración con Kubernetes.
Un ejemplo de este patrón sería un Job que arranca un Pod que ejecuta una secuencia de comandos que, a su vez,
arranca un controlador maestro de Spark (ver el ejemplo de spark),
ejecuta un manejador de spark, y a continuación lo limpia todo.
Una ventaja de este enfoque es que el proceso general obtiene la garantía del objeto Job,
además del control completo de los Pods que se crean y cómo se les asigna trabajo.
Cron Jobs
Puedes utilizar un CronJob para crear un Job que se ejecute en una hora/fecha determinadas, de forma similar
a la herramienta cron de Unix.
3.4.2.9 - CronJob
Un Cron Job ejecuta tareas, Jobs, a intervalos regulares.
Un objeto CronJob es como una línea de un archivo crontab (tabla cron). Ejecuta un trabajo de forma periódica
según un horario programado escrito en formato Cron.
Nota:
Todos los horariosCronJob se basan en la zona horaria del máster donde se inicia el trabajo.
Un trabajo programado crea un objeto job como mínimo una vez por cada ejecución de su programación. Decimos "como mínimo" porque
hay determinadas circunstancias bajo las cuales dos trabajos pueden crearse, o ninguno de ellos se crea. Se intenta que estos casos sean residuales,
pero no pueden evitarse completamente. Por lo tanto, los trabajos deberían ser idempotentes, es decir, que se pueden ejecutar más de una vez con el mismo resultado.
Si el valor de startingDeadlineSeconds se establece a un valor grande o se deja sin especificar (por defecto)
y si el valor de concurrencyPolicy se establece a Allow, los trabajos siempre se ejecutarán por lo menos una vez.
Para cada CronJob, el controlador de CronJob verifica cuántas programaciones se han perdido desde la última programación hasta el momento actual.
Si hay más de 100 programaciones perdidas, entonces ya no vuelve a ejecutar el trabajo y registra el error:
Cannot determine if job needs to be started. Too many missed start time (> 100). Set or decrease .spec.startingDeadlineSeconds or check clock skew.
Es importante destacar que si el campo startingDeadlineSeconds está configurado, es decir, no es nulo (nil), el controlador cuenta cuántos trabajos perdidos se produjeron desde el valor de startingDeadlineSeconds
hasta el momento actual, en vez de la última programación. Por ejemplo, si startingDeadlineSeconds es 200, el controlador cuenta cuántos trabajos perdidos se produjeron en los últimos 200 segundos.
Se cuenta un CronJob como perdido si no se ha podido crear a la hora programada. Por ejemplo, si establecemos el valor de concurrencyPolicy a Forbid y se intentó programar
un CronJob cuando otro previamente programado estaba todavía ejecutándose, entonces contará como perdido.
Por ejemplo, imagina que un CronJob se configura para programar un nuevo Job cada minuto a partir de las 08:30:00, y su campo
startingDeadlineSeconds no se configura. Si el controlador del CronJob no estuviera disponible de 08:29:00 a 10:21:00,
el trabajo no comenzaría porque el número de trabajos perdidos que se habría perdido en su programación sería superior a 100.
Para ilustrar este concepto mejor, vamos a suponer que programamos un CronJob para que ejecute un nuevo Job cada minuto comenzando a las 08:30:00, y establecemos el valor del campo
startingDeadlineSeconds a 200 segundos. Si el controlador del CronJob no se encuentra disponible
durante el mismo período que en el ejemplo anterior (08:29:00 a 10:21:00,) aún así el Job comenzará a las 10:22:00.
Esto ocurre porque el controlador en este caso comprueba cuántas programaciones perdidas ha habido en los últimos 200 segundos (esto es, 3 programaciones que no se han ejecutado), en vez de comprobarlo a partir de la última programación hasta el momento actual.
El CronJob es únicamente responsable de crear los Jobs que coinciden con su programación, y
el Job por otro lado es el responsable de gestionar los Pods que representa.
3.5 - Servicios, balanceo de carga y redes
3.5.1 - Service
Un Service, servicio en castellano, es el objeto de la API de Kubernetes que describe cómo se accede a las aplicaciones, tal como un conjunto de Pods, y que puede describir puertos y balanceadores de carga.
Con Kubernetes no necesitas modificar tu aplicación para que utilice un mecanismo de descubrimiento de servicios desconocido.
Kubernetes le otorga a sus Pods su propia dirección IP y un nombre DNS para un conjunto de Pods, y puede balancear la carga entre ellos.
Motivación
Los Pods de Kubernetes son creados y destruidos para coincidir con el estado de tu clúster.
Los Pods son recursos no permanentes. Si utilizas un Deployment para correr tu aplicación, puede crear y
destruir los Pods dinámicamente.
Cada Pod obtiene su propia dirección IP, sin embargo, en un Deployment, el conjunto de Pods corriendo en un momento dado puede ser diferente al
conjunto de Pods corriendo esa aplicación un momento después.
Esto conlleva un problema: si un conjunto de Pods (llamémoslos "backends") provee funcionalidad a otros Pods (llamémoslos "frontends") dentro de tu clúster,
¿de qué manera los frontends encuentran y tienen seguimiento de cuál dirección IP conectarse, para que el frontend pueda usar la parte del backend de la carga de trabajo?
Entran los Services.
Recursos Service
En Kubernetes, un Service es una abstracción que define un conjunto lógico de Pods y una política por la cual acceder a ellos
(algunas veces este patrón es llamado micro-servicio). El conjunto de Pods a los que apunta un Servicio se determina usualmente por un Selector.
Para aprender más sobre otras maneras de definir Endpoints para un Service, mira Services sin selectores.
Por ejemplo, considera un backend sin estado para procesar imágenes que está corriendo con 3 réplicas. Estas réplicas son fungibles; a los frontends no les importa
cuál backend usar. Mientras que los Pods actuales que componen el backend pueden cambiar, los clientes del frontend no deberían estar al tanto de ello, ni deberían llevar un seguimiento
del conjunto de backends en sí mismos.
La abstracción del Service habilita este desacoplamiento.
Descubrimiento de servicios nativos en la nube
Si eres capaz de usar la API de Kubernetes para descubrir servicios en tu aplicación,
puedes hacer una búsqueda en el servidor API para los Endpoints, que se actualizan cuando cambian el conjunto de Pods en el servicio.
Para aplicaciones no nativas, Kubernetes ofrece una manera de colocar un puerto de red o un balanceador de carga entre tu aplicación y los Pods del backend.
Definiendo un Service
Un Service en Kubernetes es un objeto REST, similar a un Pod. Como todos los objetos REST, puedes hacer un Post a una definición de un Service al servidor API para crear una nueva instancia.
EL nombre de un objeto Service debe ser un nombre RFC 1035 válido.
Por ejemplo, supongamos que tienes un conjunto de Pods en el que cada uno escucha el puerto TCP 9376 y contiene la etiqueta app.kubernetes.io/name=MyApp:
Esta especificación crea un nuevo objeto Service llamado "mi-servicio", que apunta via TCP al puerto 9376 de cualquier Pod con la etiqueta app.kubernetes.io/name=MyApp.
Kubernetes asigna una dirección IP a este Service (Algunas veces llamado "Cluster IP"), la cual es usada por los proxies de los Services (mira IPs Virtuales y proxies de servicios abajo).
El controlador para el selector del Service escanea continuamente a los Pods que coincidan con este selector, y luego hace un Post de cualquier actualización a un objeto Endpoint llamado también "mi-servicio".
Nota:
Un Service puede mapear cualquierport de entrada a un targetPort. Por defecto y conveniencia, el targetPort se establece con el mismo valor que el campo port.
Las definiciones de puerto en los Pods tienen nombres, y puedes hacer referencia a estos nombres en el atributo targetPort del Service. Esto funciona incluso si existe una mezcla
de Pods en el Service usando un único nombre configurado, con el mismo protocolo de red disponible via diferentes números de puerto.
Esto ofrece mucha flexibilidad para desplegar y evolucionar tus Services. Por ejemplo, puedes cambiar los números de puertos que los Pods exponen en la siguiente versión de tu software backend, sin romper los clientes.
El protocolo por defecto para los Services is TCP; también puedes usar cualquier otro protocolo soportado.
Como muchos Services necesitan exponer más de un puerto, Kubernetes soporta múltiples definiciones de puertos en un único objeto Service.
Cada definición de un puerto puede tener el mismo protocolo, o uno diferente
Services sin selectores
Los Services comúnmente abstraen el acceso a los Pods de Kubernetes, pero también pueden abstraer otros tipos de backends.
Por ejemplo:
Quieres tener un clúster de base de datos externo en producción, pero en el entorno de pruebas quieres usar tus propias bases de datos.
Quieres apuntar tu Service a un Service en un Namespace o en un clúster diferente.
Estás migrando tu carga de trabajo a Kubernetes. Mientras evalúas la aproximación, corres solo una porción de tus backends en Kubernetes.
En cualquiera de estos escenarios puedes definir un Service sin un selector de Pod.
Debido a que este Service no tiene un selector, el objeto Endpoints no se crea de forma automática.
Puedes mapear manualmente el Service a la dirección de red y puerto donde está corriendo, añadiendo el objeto Endpoints manualmente:
Las direcciones IPs no deben ser: loopback (127.0.0.0/8 para IPv4, ::1/128 para IPv6), o
link-local (169.254.0.0/16 and 224.0.0.0/24 para IPv4, fe80::/64 para IPv6).
Las direcciones IP del Endpoint no pueden ser IPs de clúster de otros Services de Kubernetes, debido a que el
kube-proxy no soporta IPs virtuales como destino.
Acceder a un Service sin un selector funciona de la misma manera que si tuviese un selector.
En el ejemplo de abajo, el tráfico se dirige al único Endpoint definido en el YAML:
192.0.2.42:9376 (TCP).
Nota:
El servidor de API de Kubernetes no permite hacer proxy a Endpoints que no están mapeados a Pods.
Acciones como kubectl port-forward service/<service-name> forwardedPort:servicePort donde el servicio no tiene un selector fallará debido a esta restricción.
Esto previene que el servidor API de Kubernetes sea utilizado como proxy a endpoints a los que quien llama no tenga acceso autorizado.
Un Service ExternalName es un caso especial de Service que no tiene selectores y usa nombres DNS en su lugar. Para más información, mira la sección ExternalName en este documento.
Endpoints de sobrecapacidad
Si un recurso Endpoint tiene más de 1000 endpoints entonces un clúster de Kubernetes v1.22 (o posterior)
anota los Endpoints con endpoints.kubernetes.io/over-capacity: truncated.
Esta anotación indica que el objeto Endpoints afectado está por encima de la capacidad y que
el controlador de endpoints ha truncado el número de endpoints a 1000.
EndpointSlices
FEATURE STATE:Kubernetes v1.21 [stable]
Los EndpointSlices son un recurso de la API que pueden proveer una alternativa más escalable a los Endpoints.
Aunque conceptualmente es muy similar a los Endpoints, los EndpointSlices permiten distribuir los endpoints de red a través de múltiples recursos.
Por defecto, un EndpointSlice se considera "full" una vez que alcanza 100 endpoints, punto en el cual un EndpointSlice se creará para almacenar cualquier endpoint adicional.
Los EndpointSlices proveen atributos adicionales y funcionalidad que se describe en detalle en EndpointSlices.
Protocolo de aplicación
FEATURE STATE:Kubernetes v1.20 [stable]
El campo appProtocol provee una manera de especificar un protocolo de aplicación para cada puerto de un Service.
El valor de este campo es reflejado por el Endpoint correspondiente y los objetos EndpointSlices.
Este campo sigue una sintaxis estándar de etiquetas de Kubernetes. Los valores deberían ser nombres de servicio IANA estándar
o nombres de dominio con prefijos tales como mycompany.com/my-custom-protocol.
IPS Virtuales proxies de servicio
Cada nodo en un clúster de Kubernetes ejecuta un kube-proxy. El kube-proxyes el responsable de implementar una forma de IP virtual para los
Services de un tipo distinto al de ExternalName.
Por qué no usar DNS round-robin?
Una pregunta que surge algunas veces es por qué Kubernetes depende de proxies para redirigir el tráfico de entrada a los backends. ¿Qué hay de otros enfoques?
Por ejemplo, ¿sería posible configurar registros DNS que tengan múltiples valores A (o AAA para IPv6), y depender en la resolución de nombres round-robin?
Existen algunas razones para usar proxies en los Services:
Hay una larga historia de implementaciones DNS que no respetan los registros TTLs, y cachean los resultados de la búsqueda de nombres luego de que deberían haber expirado.
Algunas aplicaciones realizan la búsqueda de DNS solo una vez y almacenan en caché los resultados indefinidamente.
Incluso si las aplicaciones y las librerías hicieran una resolución apropiada, los TTLs bajos o nulos en los registros DNS podrían imponer una carga alta en los DNS que luego se volvería difícil de manejar.
Más adelante en esta página puedes leer acerca del trabajo de varias implementaciones de kube-proxy. En general, deberías notar que, cuando ejecutas kube-proxy, los niveles de reglas del kernel podrían modificarse (por ejemplo, podrían crearse reglas iptables), que luego no son limpiados, en algunos casos hasta que reinicias. Por tanto, ejecutar kube-proxy es algo que
solo debería hacer un administrador que entienda las consecuencias de tener un servicio de bajo nivel privilegiado de proxy de red en un computador. Aunque el ejecutable de kube-proxy soporta una función de cleanup, esta función no es una característica oficial y solo está disponible para usarse como está.
Configuración
Ten en cuenta que el kube-proxy inicia en diferentes modos, los cuales están determinados por su configuración.
La configuración del kube-proxy se hace via un ConfigMap, y el ConfigMap para el kube-proxy remplaza efectivamente el comportamiento de casi todas las banderas para el kube-proxy.
La configuración del ConfigMap no soporta la recarga en vivo de la configuración.
Los parámetros del ConfigMap para el kube-proxy no se pueden validar y verificar en el arranque. Por ejemplo, si tu sistema operativo no permite ejecutar comandos iptables, el kube-proxy del kernel estándar no funcionará. De igual forma, si tienes un sistema operativo que no soporta netsh, no se ejecutará en modo userspace en Windows.
Modo proxy userspace
En este modo, el kube-proxy observa la adición y eliminación de objetos Endpoint Service del plano de control de Kubernetes.
Para cada Service se abre un puerto (elegido al azar) en el nodo local. Cualquier conexión a este "puerto proxy" es dirigido a uno de los Pods backend del Servicio (como se reporta via Endpoints). El kube-proxy toma el valor sessionAffinity del Service en cuenta cuando decide cuál Pod del backend utilizar.
Finalmente, el proxy del userspace instala reglas de iptables que capturan el tráfico al clusterIP (que es virtual) del servicio y el port. Las reglas redirigen el tráfico al puerto proxy que redirige al Pod del backend.
Por defecto, el kube-proxy en modo userspace elige un backend con un algoritmo round-robin.
Modo proxy iptables
En este modo, el kube-proxy observa la adición y eliminación de objetos Endpoint Service del panel de control de Kubernetes.
Para Service, instala reglas iptables, las cuales capturan el tráfico al clusterIP y el port del Service, y redirige este tráfico a uno de los conjuntos del backend.
Para cada objeto Endpoint, instala reglas de iptables que seleccionan un Pod del backend.
Por defecto, el kube-proxy en modo iptables elige un backend al azar.
Usar iptables para manejar tráfico tiene una sobrecarga más baja del sistema, porque el tráfico es manejado por el netfilter de Linux sin la necesidad de cambiar entre userspace y el espacio del kernel.
Esta aproximación puede llegar a ser más confiable.
Si el kube-proxy está corriendo en modo iptables y el primer Pod seleccionado no responde, la conexión falla. Esto es diferente del modo userspace: en ese escenario, el kube-proxy detectaría que la conexión al primer Pod ha fallado e intentaría automáticamente con otro Pod del backend.
Puedes usar readiness probes para verificar que los Pods del backend están funcionando correctamente, para que kube-proxy en modo iptables solo vea los backends que han sido comprobados como sanos. Hacer esto significa que evitas enviar tráfico via kube-proxy a un Pod que se sabe que ha fallado.
Modo Proxy IPVS
FEATURE STATE:Kubernetes v1.11 [stable]
En el modo ipvs, el kube-proxy observa los Services de Kubernetes y los Endpoints, llama la interfaz netlink para crear reglas IPVS respectivamente y sincroniza las reglas IPVS con los Services de Kubernetes y los Endpoints periódicamente. Este ciclo de control asegura que los estados del IPVS coincidan con el estado deseado.
Cuando accede a un Service, IPVS dirige el tráfico a uno de estos Pods del backend.
El modo proxy IPVS está basado en la función de enlace netfilter que es similar al modo iptables, pero usa una tabla hash como estructura de datos subyacente y opera en el espacio del kernel.
Esto significa que el kube-proxy en modo IPVS redirige el tráfico como menor latencia que el kube-proxy en modo iptables, con mejor desempeño cuando sincroniza las reglas proxy. Comparado con otros modos proxy, el modo IPVS también soporta un rendimiento más alto de tráfico de red.
IPVS provee más opciones para balancear el tráfico a los Pods del backend; estas son:
rr: round-robin
lc: menor conexión (el número más pequeño de conexiones abiertas)
dh: hash de destino
sh: hash de origen
sed: retraso esperado más corto
nq: nunca hacer cola
Nota:
Para correr kube-proxy en modo IPVS, deber estar disponible IPVS en el nodo antes de iniciar el kube-proxy.
Cuando kube-proxy inicia en modo IPVS, este verifica si los módulos kernel IPVS están disponibles. Si no se detectan los módulos del kernel IPVS, kube-proxy vuelve al modo proxy iptables.
En estos modelos de proxy, el tráfico enlazado para la IP:Port del Service es redirigido al backend apropiado sin que el cliente sepa nada de Kubernetes, Services o Pods.
Si quieres asegurarte que las conexiones desde un cliente en particular se pasen al mismo Pod cada vez, puedes seleccionar la afinidad de sesión basada en la dirección IP del cliente al establecer service.spec.sessionAffinity a "ClientIP" (por defecto es "None").
Puedes establecer también el número máximo de tiempo al establecer service.spec.sessionAffinityConfig.clientIP.timeoutSeconds apropiadamente. (El valor por defecto es 10800, que resulta ser unas 3 horas).
Services multi puerto
Para algunos servicios, necesitas exponer más de un puerto. Kubernetes te permite configurar múltiples definiciones puertos en un objeto Service. Cuando usas múltiples puertos para un Service, debes nombrar todos tus puertos para que no sean ambiguos.
Por ejemplo:
Como con los nombres de Kubernetes en general, los nombres para los puertos deben contener alfanuméricos en minúsculas y -. Los nombres de puertos deben comenzar y terminar con un carácter alfanumérico.
Por ejemplo, los nombres 123-abc and web son válidos, pero 123_abc y -web no lo son.
Eligiendo tu propia dirección IP
Puedes especificar tu propia dirección IP para el clúster como parte de la petición de creación de un Service. Para hacer esto, establece el campo .spec.clusterIP. Por ejemplo, si ya tienes una entrada DNS existente que quieres reutilizar, o sistemas legacy que están configurados para direcciones IP específicas que son difíciles de reconfigurar.
La dirección IP que elijas debe ser una dirección IPV4 o IPV6 válida dentro del rango CIDR service-cluster-ip-range que está configurado para el servidor API.
Si intentas crear un Service con una dirección clusterIP inválida, el servidor API devolverá un código de estado 422 para indicar que hay un problema.
Políticas de tráfico
Política de tráfico externa
Puedes establecer el campo spec.externalTrafficPolicy para controlar cómo se enruta el tráfico de fuentes externas. Los valores válidos son Clustery Local. Establece el campo a Cluster para enrutar tráfico externo a todos los endpoints listos y Local para enrutar solamente a los endpoints locales del nodo. Si la política de tráfico es Local y no hay endpoints de nodos locales, kube-proxy no redirige ningún tráfico al Service relevante.
Si habilitas el feature gateProxyTerminatingEndpoints para el kube-proxy, el kube-proxy revisa si el nodo tiene endpoints locales y si todos los endpoints locales están marcados como terminando. Si hay endpoints locales y todos están terminando, el kube-proxy ignora todo tráfico externo de Local. En cambio, mientras que los endpoints locales del nodo permanecen todos como terminando, el kube-proxy reenvía el tráfico para ese Service para endpoints sanos en otro lugar, como si la política de tráfico externo fuese Cluster.
Este comportamiento de reenvío para endpoints que están terminando existe para permitir que los balanceadores de carga externos terminen las conexiones que están respaldadas por Services NodePort gradualmente, incluso cuando la verificación del estado del puerto del nodo comienza a fallar. De lo contrario, el tráfico puede perderse entre el tiempo en que un nodo está todavía en el grupo de nodos de un balanceador de carga y el tráfico se cae durante el periodo de terminación de un Pod.
Política de tráfico interna
FEATURE STATE:Kubernetes v1.22 [beta]
Puedes establecer el campo spec.internalTrafficPolicy para controlar como se enruta el tráfico desde las fuentes internas. Los valores válidos son Cluster y Local. Establece el campo a Cluster para enrutar el tráfico interno a todos los endpoints listos y Local para enrutar solo los endpoints locales del nodo. Si la política de tráfico es Local y no hay endpoints locales de nodo, el tráfico es terminado por el kube-proxy.
Descubriendo servicios
Kubernetes soporta 2 modos primarios para encontrar un Service - variables de entorno y DNS
Variables de entorno
Cuando un Pod está corriendo en un Node, kubelet añade un conjunto de variables de entorno para cada Service activo. Soporta tanto variables Docker links
compatible como variables más sencillas {SVCNAME}_SERVICE_HOST and {SVCNAME}_SERVICE_PORT, donde el nombre del Service está en mayúsculas y los guiones medios se convierten en guiones bajos.
Por ejemplo, el Service redis-master que expone el puerto TCP 6739 y se le ha asignado una dirección IP de clúster 10.0.0.11, produce las siguientes variables de entorno:
Cuando tienes un Pod que necesita acceso a un Service, y estás usando el método de variable de entorno para publicar el puerto y la dirección clúster IP al Pod cliente, debes crear el Service antes de que los Pods del cliente lleguen a existir. De lo contrario, esos Pods cliente no tendrán las variables de entorno pobladas.
Si solo usas DNS para descubrir la clúster IP para un Service, no tienes que preocuparte acerca de este tema de ordenación.
DNS
Puedes (y casi siempre deberías) configurar un servicio DNS para tu clúster de Kubernetes usando un add-on.
Un servidor DNS consciente del clúster, como CoreDNS, observa la API de Kubernetes por nuevos Services y crea un conjunto de registros DNS para cada uno. Si DNS ha sido habilitado a través de tu clúster entonces todos los Pods automáticamente serán capaces de resolver los Services por su nombre DNS.
Por ejemplo, si tienes un Service llamado mi-servicio en un namespace mi-ns, el plano de control y el Service DNS crean un registro DNS para mi-servicio.mi-ns conjuntamente. Los Pods en el namespace mi-ns deberían ser capaces de encontrar el Service haciendo una búsqueda de nombre por mi-servicio (mi-servicio.mi-ns también funcionaría)
Los Pods en otros namespaces deben calificar el nombre como my-service.my-ns. Estos nombres resolverán la clúster IP asignada para el Service.
Kubernetes también soporta registros DNS SRV (Service) para los puertos nombrados. Si el Service mi-servicio.mi-ns tiene un puerto llamado http con el protocolo fijado a TCP, puedes hacer una consulta DNS SRV a _http._tcp.mi-servicio.mi-ns para descubrir el número de puerto para http así como la dirección IP.
El servidor DNS de Kubernetes es la única manera de acceder a los Services ExternalName. Puedes encontrar más información sobre la resolución ExternalName en Pods y Services DNS.
Servicios Headless
Algunas veces no necesitas balancear cargas y una IP única. En este caso, puedes crear lo que llamamos Services "headless", especificando "None" para el clúster IP (.spec.clusterIP).
Puedes usar un Service headless para hacer una interfaz con otros mecanismos de descubrimiento de servicios, sin estar atado a la implementación de Kubernetes.
Para los Services headless, no se asigna una clúster IP, kube-proxy no maneja estos Services, y no hay balanceo de cargas o redirección por la plataforma para ellos. Cómo se configura el DNS automáticamente depende de si el Service tiene selectores definidos:
Con selectores
Para los Services headless que definen selectores, el controlador de endpoints crea registros Endpoints en la API, y modifica la configuración DNS para devolver registros A (direcciones IP) que apuntan directamente a los Pods que respaldan el Service.
Sin selectores
Para Services headless que no definen selectores, el controlador de endpoints no crea registros Endpoints. Sin embargo, el sistema DNS busca y configura:
Registros CNAME para Services del tipo ExternalName.
Registros A para cualquier Endpoints que comparten un nombre con el Service, para todos los otros tipos.
Publicar Services (ServiceTypes)
En algunas partes de tu aplicación (por ejemplo, frontends) puede que necesites exponer un Service a una dirección IP externa, que está fuera de tu clúster local
Los ServiceTypes de Kubernetes permiten especificar qué tipo de Service quieres. El valor por defecto es ClusterIP
Los valores Type y sus comportamientos son:
ClusterIP: Expone el Service en una dirección IP interna del clúster. Al escoger este valor el Service solo es alcanzable desde el clúster. Este es el ServiceType por defecto.
NodePort: Expone el Service en cada IP del nodo en un puerto estático (el NodePort). Automáticamente se crea un Service ClusterIP, al cual enruta el NodePortdel Service. Podrás alcanzar el Service NodePort desde fuera del clúster, haciendo una petición a <NodeIP>:<NodePort>.
LoadBalancer: Expone el Service externamente usando el balanceador de carga del proveedor de la nube. Son creados automáticamente Services NodePorty ClusterIP, a los cuales el apuntará el balanceador externo.
ExternalName: Mapea el Service al contenido del campo externalName (ej. foo.bar.example.com), al devolver un registro CNAME con su valor. No se configura ningún tipo de proxy.
Nota:
Necesitas la versión 1.7 de kube-dns o CoreDNS versión 0.0.8 o más para usar el tipo ExternalName.
También puedes usar un Ingress para exponer tu Service. Ingress no es un tipo de Service, pero actúa como el punto de entrada de tu clúster. Te permite consolidar tus reglas de enrutamiento en un único recurso, ya que puede exponer múltiples servicios bajo la misma dirección IP.
Tipo NodePort
Si estableces el campo type a NodePort, el plano de control de Kubernetes asigna un puerto desde un rango especificado por la bandera --service-node-port-range (por defecto: 30000-32767).
Cada nodo es un proxy de ese puerto (el mismo número de puerto en cada nodo) hacia tu Service. Tu Service reporta al puerto asignado en el campo .spec.ports[*].nodePort
Si quieres especificar una(s) IP(s) particular(es) para hacer proxy del puerto, puedes establecer la bandera --nodeport-addresses para el kube-proxy o el campo equivalente nodePortAddresses del fichero de configuración de kube-proxy para ese bloque particular de IP(s).
Esta bandera recibe un listado de bloques de IP separados por coma (ej. 10.0.0.0/8, 192.0.2.0/25) para especificar rangos de direcciones IP que el kube-proxy debería considerar como local para este nodo.
Por ejemplo, si arrancas el kube-proxy con la bandera --nodeport-addresses=127.0.0.0/8, el kube-proxy solo selecciona la interfaz loopback para los Services NodePort. El valor por defecto es --nodeport-addresses es una lista vacía. Esto significa que el kube-proxy considera todas las interfaces de red disponibles para el NodePort. (Esto es compatible también con versiones más antiguas de Kubernetes).
Si quieres un número de puerto específico, puedes especificar un valor en el campo nodePort. El plano de control te asignará ese puerto o reportará que la transacción API ha fallado.
Esto significa que necesitas prestar atención a posibles colisiones de puerto por tu cuenta.
También tienes que usar un número de puerto válido, uno que esté dentro del rango configurado para uso del NodePort.
Usar un NodePort te da libertad para configurar tu propia solución de balanceo de cargas, para configurar entornos que no soportan Kubernetes del todo, o para exponer uno o más IPs del nodo directamente.
Ten en cuenta que este Service es visible como <NodeIP>:spec.ports[*].nodePort y .spec.clusterIP:spec.ports[*].port.
Si la bandera --nodeport-addresses está configurada para el kube-proxy o para el campo equivalente en el fichero de configuración, <NodeIP> sería IP filtrada del nodo. Si
Por ejemplo:
apiVersion:v1kind:Servicemetadata:name:mi-serviciospec:type:NodePortselector:app:MiAppports:# Por defecto y por comodidad, el `TargetPort` tiene el mismo valor que el campo `port.- port:80targetPort:80# Campo opcional# Por defecto y por comodidad, el plano de control de Kubernetes asignará el puerto desde un rango (por defecto: 30000-32767)nodePort:30007
Tipo LoadBalancer
En proveedores de la nube que soportan balanceadores de carga externos, establecer el campo type a LoadBalancer aprovisiona un balanceador de carga para tu Service. La creación del balanceador de carga ocurre de forma asíncrona, y la información sobre el balanceador de carga provisto se publica en el campo .status.loadBalancer del Service.
El tráfico desde el balanceador de carga externo es dirigido a los Pods del backend. El proveedor de la nube decide cómo balancear la carga.
Algunos proveedores de la nube te permiten especificar la IP loadBalancerIP. En esos caso, el balanceador de carga es creado con la loadBalancerIP especificada por el usuario. Si el campo loadBalancerIP no se especifica, el balanceador de carga se configura con una dirección IP efímera. Si especificas una loadBalancerIP pero tu proveedor de la nube no soporta esta característica, se ignora el campo loadBalancerIP que has configurado.
Nota:
En Azure, si quieres usar un tipo loadBalancerIP público definido por el usuario, primero necesitas crear una dirección IP estática y pública. Esta dirección IP pública debería estar en el mismo grupo de recursos que los otros recursos del clúster creados automáticamente.
Por ejemplo, MC_myResourceGroup_myAKSCluster_eastus.
Balanceadores de carga con tipos de protocolo mixtos
FEATURE STATE:Kubernetes v1.20 [alpha]
Por defecto, para los tipos de Service LoadBalancer, cuando hay más de un puerto definido, todos los puertos deben tener el mismo protocolo, y el protocolo debe estar soportado por el proveedor de la nube.
Si la feature gate MixedProtocolLBService está habilitada para el kube-apiserver se permiten usar diferentes protocolos cuando hay más de un puerto definido.
Nota:
El conjunto de protocolos que pueden ser usados para Services de tipo LoadBalancer es definido por el proveedor de la nube.
Deshabilitar la asignación NodePort del balanceador de carga
FEATURE STATE:Kubernetes v1.20 [alpha]
A partir de v1.20, puedes deshabilitar opcionalmente la asignación del puerto del nodo para un Service de tipo LoadBalancer estableciendo el campo spec.allocateLoadBalancerNodePorts a false. Esto debería ser usado solo para implementaciones de balanceadores de carga que enrutan el tráfico directamente a los Pods al contrario de usar puertos del nodo. Por defecto, spec.allocateLoadBalancerNodePorts es true y los Services de tipo LoadBalancer continuarán asignando puertos. Si spec.allocateLoadBalancerNodePorts es false en un Service existente con puertos asignado, esos puertos del nodo no serán desasignados automáticamente.
Debes quitar explícitamente la entrada nodePortsen cada puerto del Service para desasignar esos puertos del nodo.
Debes habilitar la feature gate ServiceLBNodePortControl para usar este campo.
Especificar la clase de implementación del balanceador de carga
FEATURE STATE:Kubernetes v1.22 [beta]
spec.loadBalancerClass te permite usar una implementación del balanceador de carga distinta que la que viene por defecto para el proveedor de la nube. Esta característica está disponible desde v1.21, debes habilitar la feature gate ServiceLoadBalancerClass para usar este campo en v1.21, y la feature gate está habilitada por defecto desde v1.22 en adelante.
Por defecto, spec.loadBalancerClass es nil y un tipo de Service LoadBalancer usa la implementación por defecto del proveedor de la nube si el clúster está configurado con un proveedor de nube usando la bandera de componente --cloud-provider.
Si spec.loadBalancerClass está especificado, se asume que una implementación de un balanceador de carga que coincida con la clase especificada está observando los Services. Cualquier implementación por defecto del balanceador de carga (por ejemplo, la que es provista por el proveedor de la nube) ignorará los Services que tienen este campo establecido. spec.loadBalancerClass se puede establecer en cualquier Service de tipo LoadBalancer únicamente. Una vez hecho, no se puede cambiar.
El valor de spec.loadBalancerClass debe ser un identificador de etiqueta, con un prefijo opcional como "internal-vip" o "example.com/internal-vip". Los nombres sin prefijo están reservados para usuarios finales.
Balanceador de carga interno
En un entorno mixto algunas veces es necesario enrutar el tráfico desde Services dentro del mismo bloque (virtual) de direcciones de red.
En un entorno de split-horizon DNS necesitarías dos Services para ser capaz de enrutar tanto el tráfico externo como el interno a tus Endpoints.
Para establecer un balanceador de carga interno, agrega una de las siguientes anotaciones a tu Service dependiendo del proveedor de Service en la nube que estás usando.
El primero especifica el ARN del certificado a usar. Este puede ser un certificado de un emisor de un tercero que fue subido en IAM o uno creado dentro del Administrador de Certificados de AWS.
La segunda anotación especifica cuál protocolo habla el Pod. Para HTTPS y SSL, el ELB espera que el Pod se autentique a sí mismo sobre una conexión encriptada, usando un certificado.
HTTP y HTTPS seleccionan un proxy de capa 7: el ELB termina la conexión con el usuario, interpreta los encabezados, e inyecta el encabezado X-Forwared-For con la dirección IP del usuario (los Pods solo ven la dirección IP del ELB del otro lado de su conexión) cuando reenvía las peticiones.
TCP y SSL seleccionan un proxy de capa 4: el ELB reenvía el tráfico sin modificar los encabezados.
En un entorno mixto donde algunos puertos están asegurados y otros se dejan sin encriptar, puedes usar una de las siguientes anotaciones:
En el ejemplo de arriba, si el Service contenía tres puertos, 80, 443 y 8443 entonces 443 y 8443 usarían el certificado SSL, pero 80sería HTTP proxy.
A partir de Kubernetes v1.9 en adelante puedes usar políticas predefinidas de AWS SSL con listeners HTTPS o SSL para tus Services. Para ver cuáles políticas están disponibles para usar, puedes usar la herramienta de línea de comandos aws:
Puedes especificar cualquiera de estas políticas usando la anotación "service.beta.kubernetes.io/aws-load-balancer-ssl-negotiation-policy", por ejemplo:
A partir de la versión 1.3.0, el uso de esta anotación aplica para todos los puertos proxy del ELB y no puede ser configurado de otra manera.
Acceso a los logs ELB en AWS
Existen algunas anotaciones para administrar el acceso a los logs para Services ELB en AWS.
La anotación service.beta.kubernetes.io/aws-load-balancer-access-log-enabled controla si el acceso a los logs están habilitados.
La anotación service.beta.kubernetes.io/aws-load-balancer-access-log-emit-interval
controla el intervalo en minutos para publicar los logs de acceso. Puedes especificar un intervalo de 5 0 60 minutos.
La anotación service.beta.kubernetes.io/aws-load-balancer-access-log-s3-bucket-name
controla el nombre del bucket de Amazon S3 donde se almacenan los logs del balanceador de carga.
La anotación service.beta.kubernetes.io/aws-load-balancer-access-log-s3-bucket-prefix
especifica la jerarquía lógica que has creado para tu bucket de Amazon S3.
metadata:name:mi-servicioannotations:service.beta.kubernetes.io/aws-load-balancer-access-log-enabled:"true"# Especifica si está habilitado el acceso a los logsservice.beta.kubernetes.io/aws-load-balancer-access-log-emit-interval:"60"# EL intervalo para publicar los logs de acceso. Puedes especificar un intervalo de 5 o 60 (minutos)service.beta.kubernetes.io/aws-load-balancer-access-log-s3-bucket-name:"my-bucket"# El nombre del bucket S· de Amazon donde se almacenan los logs de accesoservice.beta.kubernetes.io/aws-load-balancer-access-log-s3-bucket-prefix:"my-bucket-prefix/prod"# La jerarquía lógica que has creado para tu bucket S3 de Amazon, por ejemplo `my-bucket-prefix/prod`
Drenaje de conexión en AWS
Drenaje de conexión para ELBs clásicos se puede administrar con la anotación
service.beta.kubernetes.io/aws-load-balancer-connection-draining-enabled fijada al valor "true".
La anotación service.beta.kubernetes.io/aws-load-balancer-connection-draining-timeout puede
ser usada también para establecer el tiempo máximo, en segundos, para mantener las conexiones existentes antes de dar de baja las instancias.
Existen otras anotaciones para administrar Classic Elastic Load Balancers que se describen abajo.
metadata:name:mi-servicioannotations:service.beta.kubernetes.io/aws-load-balancer-connection-idle-timeout:"60"# El tiempo, en segundos, que se permite a una conexión estar en reposo (no se han enviado datos sobre la conexión) antes que sea cerrada por el balanceador de cargaservice.beta.kubernetes.io/aws-load-balancer-cross-zone-load-balancing-enabled:"true"# Especifica si el balanceo de cargas entre zonas está habilitado para el balanceador de cargaservice.beta.kubernetes.io/aws-load-balancer-additional-resource-tags:"environment=prod,owner=devops"# Un listado separado por comas de valores de clave-valor que será guardados como etiquetas adicionales en el ELB.service.beta.kubernetes.io/aws-load-balancer-healthcheck-healthy-threshold:""# El número de comprobaciones de estado exitosas sucesivas requeridas para considerar sano para el tráfico a un backend.# Por defecto es 2, debe ser entre 2 y 10service.beta.kubernetes.io/aws-load-balancer-healthcheck-unhealthy-threshold:"3"# El número de comprobaciones de estado fallidas requeridas para considerar a un backend no apto para el tráfico.# Por defecto es 6, debe ser entre 2 y 10service.beta.kubernetes.io/aws-load-balancer-healthcheck-interval:"20"# EL intervalo aproximado, en segundos, entre comprobaciones de estados de una instancia individual.# Por defecto es 10, debe ser entre 5 y 300.service.beta.kubernetes.io/aws-load-balancer-healthcheck-timeout:"5"# La cantidad de tiempo, en segundos, durante el cual no recibir respuesta significa una comprobación de estado fallida.# Este valor debe ser menor que el valor de service.beta.kubernetes.io/aws-load-balancer-healthcheck-interval# Por defecto es 5, debe estar entre 2 y 60service.beta.kubernetes.io/aws-load-balancer-security-groups:"sg-53fae93f"# Un listado de grupos de seguridad existentes para configurar en el ELB creado. A diferencia de la anotación# service.beta.kubernetes.io/aws-load-balancer-extra-security-groups, esta reemplaza todos los grupos de seguridad previamente asignados al ELB y también sobreescribe la creación de un grupo de seguridad creado únicamente para este ELB.# El primer ID grupo de seguridad en esta lista se utiliza para permitir tráfico de entrada a los nodos workers objetivo (tráfico de servicio y comprobaciones de estados).# Si se configuran múltiples ELBs con el mismo grupo de seguridad, solo una única línea de permisos será añadida a los grupos de seguridad del nodo worker, lo que significa que si eliminas cualquiera de esos ELBs removerá la línea de permisos y bloqueará el acceso para todos los ELBs que comparten el mismo ID de seguridad de grupo.# Esto puede ocasionar cortes entre servicios si no se usa apropiadamenteservice.beta.kubernetes.io/aws-load-balancer-extra-security-groups:"sg-53fae93f,sg-42efd82e"# Un listado adicional de grupos de seguridad para añadir al ELB creado, esto deja un grupo de seguridad creado únicamente, asegurando que cada ELB tiene un ID de grupo de seguridad único que coincide con la línea de permiso para permitir tráfico a los nodos worker objetivo (tráfico de servicio y comprobaciones de estados)# Grupos de seguridad definidos se pueden compartir entre servicios.service.beta.kubernetes.io/aws-load-balancer-target-node-labels:"ingress-gw,gw-name=public-api"# Un listado separado por comas de clave-valor que se utilizan para seleccionar los nodos objetivos para el balanceador de carga
Soporte para Balanceador de Carga de Red (NLB) en AWS
FEATURE STATE:Kubernetes v1.15 [beta]
Para usar un balanceador de carga de Red en AWS, usa la anotación service.beta.kubernetes.io/aws-load-balancer-type con el valor fijado a nlb.
NLB solo funciona con ciertas clases de instancias; mira la documentación AWS sobre balanceo de cargas elástico para un listado de tipos de instancia soportados.
A diferencia de los balanceadores de cargas, el balanceador de carga de red (NLB) reenvía la dirección IP del cliente a través del nodo. Si el campo .spec.externalTrafficPolicy está fijado a clúster, la dirección IP del cliente no es propagada a los Pods finales.
Al fijar .spec.externalTrafficPolicy en Local, la dirección IP del cliente se propaga a los Pods finales,
pero esto puede resultar a una distribución de tráfico desigual. Los nodos sin ningún Pod para un Service particular de tipo LoadBalancer fallarán en la comprobación de estado del grupo objetivo del NLB en el puerto .spec.healthCheckNodePort y no recibirán ningún tráfico.
Para conseguir trafico equilibrado, usa un DaemonSet o especifica pod anti-affinity para no localizar en el mismo nodo.
Para permitir que el tráfico del cliente alcance las instancias detrás del NLB, los grupos de seguridad del Nodo se modifican con las siguientes reglas de IP:
Regla
Protocolo
Puerto(s)
Rango de IP(s)
Descripción del Rango de IP
Health Check
TCP
NodePort(s) (.spec.healthCheckNodePort para .spec.externalTrafficPolicy = Local)
Subnet CIDR
kubernetes.io/rule/nlb/health=<loadBalancerName>
Tráfico del Cliente
TCP
NodePort(s)
.spec.loadBalancerSourceRanges (por defecto en 0.0.0.0/0)
kubernetes.io/rule/nlb/client=<loadBalancerName>
MTU Discovery
ICMP
3,4
.spec.loadBalancerSourceRanges (por defecto en 0.0.0.0/0)
kubernetes.io/rule/nlb/mtu=<loadBalancerName>
Para limitar cuáles IPs del cliente pueden acceder al balanceador de carga de red, especifica loadBalancerSourceRanges.
spec:loadBalancerSourceRanges:- "143.231.0.0/16"
Nota:
Si no se establece .spec.loadBalancerSourceRanges, Kubernetes permite el tráfico
desde 0.0.0.0/0 a los Grupos de Seguridad del Nodo. Si los nodos tienen direcciones IP públicas, ten en cuenta que el tráfico que no viene del NLB
también puede alcanzar todas las instancias en esos grupos de seguridad modificados.
Otras anotaciones CLS en Tencent Kubernetes Engine (TKE)
Hay otras anotaciones para administrar balanceadores de carga en la nube en TKE como se muestra abajo.
metadata:name:mi-servicioannotations:# Enlaza Loadbalancers con nodos específicosservice.kubernetes.io/qcloud-loadbalancer-backends-label:key in (value1, value2)# Identificador de un balanceador de carga existenteservice.kubernetes.io/tke-existed-lbid：lb-6swtxxxx#Parámetros personalizados para el balanceador de cargas (LB), no soporta la modificación del tipo de LB todavíaservice.kubernetes.io/service.extensiveParameters:""# Parámetros personalizados para el listener LBservice.kubernetes.io/service.listenerParameters:""# Especifica el tipo de balanceador de carga;# valores válidos: clásico (Balanceador de Carga clásico) o aplicación (Balanceador de Carga de aplicación de la nube)service.kubernetes.io/loadbalance-type:xxxxx# Especifica método de pago el ancho de banda de la red pública;# valores válidos: TRAFFIC_POSTPAID_BY_HOUR(bill-by-traffic) y BANDWIDTH_POSTPAID_BY_HOUR (bill-by-bandwidth).service.kubernetes.io/qcloud-loadbalancer-internet-charge-type:xxxxxx# Especifica el valor del ancho de banda (rango valor: [1,2000] Mbps).service.kubernetes.io/qcloud-loadbalancer-internet-max-bandwidth-out:"10"# Cuando se fija esta anotación, los balanceadores de carga solo registrarán nodos con Pods corriendo en él, de lo contrario todos los nodos serán registrados.service.kubernetes.io/local-svc-only-bind-node-with-pod:true
Tipo ExternalName
Los Services de tipo ExternalName mapean un Service a un nombre DNS, no a un selector típico como mi-servicio o cassandra. Estos Services se especifican con el parámetro spec.externalName.
Esta definición de Service, por ejemplo, mapea el Service mi-Servicio en el namespace prod a my.database.example.com:
ExternalName acepta una cadena de texto IPv4, pero como un nombre DNS compuesto de dígitos, no como una dirección IP. ExternalNames que se parecen a direcciones IPv4 no se resuelven por el CoreDNS o ingress-nginx, ya que ExternalName se usa para especificar un nombre DNS canónico. Al fijar una dirección IP, considera usar headless Services.
Cuando busca el host mi-servicio.prod.svc.cluster.local, el Service DNS del clúster devuelve un registro CNAME con el valor my.database.example.com. Acceder a mi-servicio funciona de la misma manera que otros Services, pero con la diferencia crucial de que la redirección ocurre a nivel del DNS en lugar reenviarlo o redirigirlo. Si posteriormente decides mover tu base de datos al clúster, puedes iniciar sus Pods, agregar selectores apropiados o endpoints, y cambiar el type del Service.
Advertencia:
Podrías tener problemas al usar ExternalName para algunos protocolos comunes, incluyendo HTTP y HTTPS, si usas ExternalName entonces el nombre del host usado por los clientes dentro de tu clúster es diferente del nombre al que hace referencia el ExternalName.
Para protocolos que usan el nombre del host esta diferencia puede llevar a errores o respuestas inesperadas. Las peticiones HTTP tendrán un encabezado Host: que el servidor de origen no reconocerá; los servidores TLS no serán capaces de proveer un certificado que coincida con el nombre del host al que el cliente está conectado.
Si existen IPs externas que enrutan hacia uno o más nodos del clúster, los Services de Kubernetes pueden ser expuestos en esas externalIPs. El tráfico que ingresa al clúster con la IP externa (como IP de destino), en el puerto del Service, será enrutado a uno de estos endpoints del Service. Las externalIPs no son administradas por Kubernetes y son responsabilidad del administrador del clúster.
En la especificación del Service, las externalIPs se pueden especificar junto con cualquiera de los ServiceTypes.
En el ejemplo de abajo, "mi-servicio" puede ser accedido por clientes en "198.51.100.32:80" (externalIP:port)
Usar el proxy del userspace for VIPs funciona en pequeña y mediana escala, pero no escalará a clústeres muy grandes con miles de Services. El tópico original design proposal for portals tiene más detalles sobre esto.
Usar el proxy del userspace oculta la dirección IP de origen de un paquete que accede al Service. Esto hace que algún tipo de filtrado (firewalling) sea imposible. El modo proxy iptables no oculta IPs de origen en el clúster, pero aún tiene impacto en clientes que vienen desde un balanceador de carga o un node-port.
El campo Type está diseñado como una funcionalidad anidada - cada nivel se agrega al anterior. Esto no es estrictamente requerido en todos los proveedores de la nube (ej. Google Compute Engine no necesita asignar un NodePort para que funcione el LoadBalancer, pero AWS si) pero la API actual lo requiere.
Implementación de IP Virtual
La información previa sería suficiente para muchas personas que quieren usar Services. Sin embargo, ocurren muchas cosas detrás de bastidores que valdría la pena entender.
Evitar colisiones
Una de las principales filosofías de Kubernetes es que no debe estar expuesto a situaciones que podrían hacer que sus acciones fracasen por su propia culpa. Para el diseño del recurso de Service, esto significa no obligarlo a elegir su propio número de puerto si esa elección puede colisionar con la de otra persona. Eso es un fracaso de aislamiento.
Para permitirte elegir un número de puerto en tus Services, debemos asegurarnos que dos Services no puedan colisionar. Kubernetes lo hace asignando a cada Service su propia dirección IP.
Para asegurarse que cada Service recibe una IP única, un asignador interno actualiza atómicamente el mapa global de asignaciones en etcd antes de crear cada Service. El objeto mapa debe existir en el registro para que los Services obtengan asignaciones de dirección IP, de lo contrario las creaciones fallarán con un mensaje indicando que la dirección IP no pudo ser asignada.
En el plano de control, un controlador de trasfondo es responsable de crear el mapa (requerido para soportar la migración desde versiones más antiguas de Kubernetes que usaban bloqueo en memoria). Kubernetes también utiliza controladores para revisar asignaciones inválidas (ej. debido a la intervención de un administrador) y para limpiar las direcciones IP que ya no son usadas por ningún Service.
Direcciones IP del Service
A diferencia de direcciones IP del Pod, que enrutan a un destino fijo, las IPs del Service no son respondidas por ningún host. En lugar de ello, El kube-proxy usa iptables (lógica de procesamiento de paquetes en Linux) para definir direcciones IP virtuales que se redirigen de forma transparente cuando se necesita. Cuando el cliente se conecta con la VIP, su tráfico es transportado automáticamente al endpoint apropiado. Las variables de entorno y DNS para los Services son pobladas en términos de la dirección IP virtual del Service (y el puerto).
Kube-proxy soporta tres modos — userspace, iptables e IPVS — los cuales operan ligeramente diferente cada uno.
Userspace
Por ejemplo, considera la aplicación de procesamiento de imágenes descrita arriba. Cuando el Service del backend es creado, el nodo maestro de Kubernetes asigna una dirección IP virtual, por ejemplo 10.0.0.1. Asumiendo que el puerto del Service es 1234, el Service es observado por todas las instancias del kube-proxy en el clúster. Cuando un proxy mira un nuevo Service, abre un puerto al azar, establece una redirección iptables desde la dirección IP virtual a este nuevo puerto, y comienza a aceptar conexiones a este.
Cuando un cliente se conecta a la dirección IP virtual del Service, la regla de iptables entra en acción, y redirige los paquetes al propio puerto del proxy. El "proxy del Service" elige un backend, y comienza a redirigir el tráfico desde el cliente al backend.
Esto quiere decir que los dueños del Service pueden elegir cualquier puerto que quieran sin riesgo de colisión. Los clientes pueden conectarse a una IP y un puerto, sin estar conscientes de a cuáles Pods están accediendo.
iptables
Nuevamente, considera la aplicación de procesamiento de imágenes descrita arriba. Cuando se crea el Service Backend, el plano de control de Kubernetes asigna una dirección IP virtual, por ejemplo 10.0.0.1. Asumiendo que el puerto del servicio es 1234, el Service es observado por todas las instancias del kube-proxy en el clúster. Cuando un proxy mira un nuevo Service, instala una serie de reglas de iptables que redirigen desde la dirección IP virtual a las reglas del Service. Las reglas del Service enlazan a las reglas del Endpoint que redirigen el tráfico (usando NAT de destino) a los backends.
Cuando un cliente se conecta a la dirección IP virtual del Service la regla de iptables son aplicadas. A diferencia del modo proxy userspace, el kube-proxy no tiene que estar corriendo para que funcione la dirección IP virtual, y los nodos observan el tráfico que viene desde la dirección IP del cliente sin alteraciones.
El mismo flujo básico se ejecuta cuando el tráfico viene a través de un node-port o de un balanceador de carga, aunque en estos casos la IP del cliente es alterada.
IPVS
Las operaciones iptables ralentizan dramáticamente en un clúster a gran escala, ej. 10.000 Services. IPVS está diseñado para balancear cargas y está basado en tablas hash dentro del kernel. De esta manera puedes alcanzar consistencia en el desempeño en un número grande de Services de un kube-proxy basado en IPVS. Mientras tanto, el kube-proxy basado en IPVS tiene algoritmos de balanceo de cargas más sofisticados (least conns, locality, weighted, persistence).
Objeto API
El Service es un recurso de alto nivel en la API REST de Kubernetes. Puedes encontrar más detalles sobre el objeto API en: Objeto API Service API.
Protocolos soportados
TCP
Puedes usar TPC para cualquier tipo de Service, y es el protocolo de red por defecto.
UDP
Puedes usar UDP para la mayoría de los Services. Para Services type=LoadBalancer, el soporte UDP depende del proveedor de la nube que ofrece esta facilidad.
SCTP
FEATURE STATE:Kubernetes v1.20 [stable]
Cuando usas un plugin de red que soporta tráfico SCTP, puedes usar SCTP para la mayoría de los Services. Para Services type=LoadBalancer, el soporte SCTP depende del proveedor de la nube que ofrece esta facilidad. (La mayoría no lo hace)
Advertencias
Soporte para asociaciones SCTP multihomed
Advertencia:
El soporte para asociaciones SCTP multihomed requiere que el plugin CNI pueda soportar la asignación de múltiples interfaces y direcciones IP a un Pod.
NAT para asociaciones SCTP multihomed requiere una lógica especial en los módulos del kernel correspondientes.
Windows
Nota:
SCTP no está soportado en nodos basados en Windows.
Userspace kube-proxy
Advertencia:
El kube-proxy no soporta la administración de asociaciones SCTP cuando está en el modo userspace.
HTTP
Si tu proveedor de la nube lo soporta, puedes usar un Service en modo LoadBalancer para configurar un proxy invertido HTTP/HTTPS, redirigido a los Endpoints del Service.
Nota:
También puedes usar Ingress en lugar de un Service para exponer Services HTTP/HTTPS.
Protocolo PROXY
Si tu proveedor de la nube lo soporta, puedes usar un Service en modo LoadBalancer para configurar un balanceador de carga fuera de Kubernetes mismo, que redirigirá las conexiones prefijadas con protocolo PROXY.
El balanceador de carga enviará una serie inicial de octetos describiendo la conexión entrante, similar a este ejemplo
Permite que sean accesibles los servicios de red HTTP (o HTTPS) usando un mecanismo de configuración consciente del protocolo, que entiende conceptos como URIs, nombres de host, rutas y más. El concepto de Ingress te permite mapear el tráfico a diferentes backend basado en las reglas que defines a través de la API de Kubernetes.
FEATURE STATE:Kubernetes v1.19 [stable]
Un objeto de la API que administra el acceso externo a los servicios en un clúster, típicamente HTTP.
Un Ingress podría proveer balanceo de cargas, terminación SSL y hosting virtual basado en nombres.
Nota:
El recurso Ingress está congelado.
Las nuevas características se añaden
al API del Gateway
Terminología
Para mayor claridad, esta guía define los siguientes términos:
Nodo: Una máquina worker en Kubernetes, parte de un clúster.
Clúster: Un conjunto de Nodos que ejecutan aplicaciones en contenedores,
administrados por Kubernetes.
Para este ejemplo, y para los despliegues más comunes de Kubernetes, los nodos
en el clúster no son parte del internet público.
Enrutador Edge: un enrutador que refuerza la política de seguridad del
cortafuegos para tu clúster.
Esto podría ser una puerta de entrada administrada por un proveedor de la nube
o una pieza física de hardware.
Red del clúster: un conjunto de enlaces, lógicos o físicos,
que facilitan la comunicación dentro de un clúster de acuerdo con
el modelo de redes de
Kubernetes.
Service: Un Service que identifica
un conjunto de Pods que utilizan selectores de label.
A menos que se indique de otra manera, los Services se asumen que tienen IPs
virtuales que solo se pueden enrutar dentro de la red del clúster.
¿Qué es un Ingress?
Un Ingress
expone rutas HTTP y HTTPS desde el exterior del clúster a los
servicios dentro del clúster.
El control del tráfico es controlado por las reglas definidas en el recurso Ingress.
Aquí tienes un ejemplo simple de un Ingress que envía todo su tráfico a un
Service:
Figure. Ingress
Un Ingress se puede configurar para otorgar URLs a los Services que son
accesibles desde el exterior,
para hacer balance de cargas del tráfico, finalizar SSL/TLS y ofrecer
alojamiento virtual basado en nombres.
Un controlador de Ingress
es responsable de complementar el Ingress,
comúnmente con un balanceador de cargas,
aunque también puedes configurar tu enrutador edge con frontends adicionales para
ayudar a manejar el tráfico.
Un Ingress no expone puertos o protocolos arbitrariamente. Exponer servicios
distintos de HTTP o HTTPS al internet usa un servicio de
tipo Service.Type=NodePort
o Service.Type=LoadBalancer.
Prerrequisitos
Debes tener
un controlador de Ingress
para satisfacer a un Ingress.
Crear únicamente un recurso Ingress no tiene ningún efecto.
Idealmente,
todos los controladores de Ingress deberían encajar con la especificación de
referencia.
En realidad, los distintos controladores de Ingress operan ligeramente
diferente.
Nota:
Asegúrate de revisar la documentación del controlador de Ingress para entender
las precauciones de usarlo.
Los Ingress usan anotaciones frecuentemente para configurar algunas opciones
dependiendo del controlador de Ingress,
un ejemplo de ello es
la anotación rewrite-target.
Distintos controladores de Ingress
soportan anotaciones diferentes.
Revisa la documentación para tu elección del controlador de Ingress para saber
qué anotaciones son soportadas.
La especificación Ingress
tiene toda la información que necesitas para configurar un balanceador de cargas
o un servidor proxy.
Mucho más importante, contiene un listado de reglas que emparejan contra todas
las peticiones entrantes.
El recurso Ingress solo soporta reglas para dirigir el tráfico HTTP(S).
Existen algunos controladores de Ingress,
que trabajan sin la definición de una IngressClass por defecto.
Por ejemplo, el controlador Ingress-NGINX se puede configurar con
una opción--watch-ingress-without-class.
Sin embargo,
se recomienda
especificar el IngressClass por defecto como se
muestra abajo.
Reglas del Ingress
Cada regla HTTP contiene la siguiente información:
Un host opcional.
En este ejemplo,
no se define un host así que la regla se aplica a todo el tráfico de
entrada HTTP a través de la dirección IP especificada.
Cuando se proporciona un host (por ejemplo, foo.bar.com), las reglas se
aplican a ese host.
Un listado de rutas (por ejemplo, /testpath), cada una de las cuales tiene
un backend asociado con un service.name y un service.port.name o
un service.port.number. Tanto el host como la ruta deben coincidir con el
contenido de una petición de entrada antes que el balanceador de cargas dirija
el tráfico al Service referenciado.
Un backend es una combinación de un Service y un puerto como se describe en la
documentación del Service o
un recurso personalizado backend
a través de un CRD.
Las peticiones HTTP (y HTTPS) al Ingress que coinciden con el host y la
ruta de la regla se envían al backend del listado.
Un defaultBackend se configura frecuentemente en un controlador de Ingress
para dar servicio a cualquier petición que no coincide con una ruta en la
especificación.
DefaultBackend
Un Ingress sin reglas envía todo el tráfico a un único backend
y .spec.defaultBackend está en el backend que debería manejar las peticiones
en ese caso.
El defaultBackend es una opción de configuración convencional
del controlador Ingress y no se especifica en tus recursos del Ingress.
Si no se especifican reglas .spec.rules, se debe
especificar .spec.defaultBackend.
Si no se establece un defaultBackend, las peticiones que no coincidan con
ninguna de las reglas las decidirá el controlador ingress (consulta la
documentación de tu controlador de ingress para saber cómo maneja este caso).
Si ninguno de los hosts o rutas coincide con la petición HTTP en los objetos Ingress,
el tráfico será enrutado a tu backend predeterminado.
Resource backends
Un Resource backend es una referencia de objeto
(ObjectRef en inglés)
a otro recurso de Kubernetes dentro del mismo espacio de nombres que el objeto
Ingress.
Este Resource es mutuamente exclusivo con el Service,
y la validación fallará si ambos se especifican.
Un uso común para un Resource backend es para ingresar datos a un backend de almacenamiento de datos con activos estáticos.
Se requiere que cada ruta de un Ingress tenga un tipo de ruta correspondiente.
Las Rutas que no incluyen un pathType explícito fallarán la validación.
Hay 3 tipos de rutas soportadas:
ImplementationSpecific: Con este tipo de ruta, la coincidencia depende de la
IngressClass.
Las implementaciones pueden tratar esto como un pathType separado o
tratarlas de forma idéntica a los tipos de ruta Prefix o Exact.
Exact: Coincide la ruta de la URL exactamente con sensibilidad a mayúsculas
y minúsculas.
Prefix: Coincide basado en el prefijo de una ruta URL dividida por /.
La coincidencia es sensible a mayúsculas y minúsculas, y hecha en un elemento
de la ruta por elemento.
Un elemento de la ruta refiere a la lista de etiquetas en la ruta dividida por
el separador /.
Una petición es una coincidencia para la ruta p si cada p es un elemento
prefijo de p de la ruta requerida.
Nota:
Si el último elemento de una ruta es una subcadena de caracteres del último
elemento de la solicitud de ruta, no es una coincidencia
(por ejemplo: /foo/bar
coincide con /foo/bar/baz, pero no coincide con /foo/barbaz).
Ejemplos
Tipo
Ruta(s)
Ruta de la(s) peticion(es)
¿Coincide?
Prefijo
/
(todas las rutas)
Sí
Exacto
/foo
/foo
Si
Exacto
/foo
/bar
No
Exacto
/foo
/foo/
No
Exacto
/foo/
/foo
No
Prefijo
/foo
/foo, /foo/
Si
Prefijo
/foo/
/foo, /foo/
Si
Prefijo
/aaa/bb
/aaa/bbb
No
Prefijo
/aaa/bbb
/aaa/bbb
Si
Prefijo
/aaa/bbb/
/aaa/bbb
Si, ignora la barra diagonal
Prefijo
/aaa/bbb
/aaa/bbb/
Si, coincide con barra diagonal
Prefijo
/aaa/bbb
/aaa/bbb/ccc
Si, coincide con la subruta
Prefijo
/aaa/bbb
/aaa/bbbxyz
No, no coincide con el prefijo de cadena
Prefijo
/, /aaa
/aaa/ccc
Si, coincide con el prefijo /aaa
Prefijo
/, /aaa, /aaa/bbb
/aaa/bbb
Si, coincide con el prefijo /aaa/bbb
Prefijo
/, /aaa, /aaa/bbb
/ccc
Si, coincide con el prefijo/
Prefijo
/aaa
/ccc
No, usa el backend predeterminado
Mezclado
/foo (Prefijo), /foo (Exacto)
/foo
Si, prefiere la coincidencia exacta
Múltiples coincidencias
En algunos casos,
muchas rutas dentro de un Ingress coincidirán con una petición.
En esos casos,
la precedencia se le dará al primero con la ruta más larga que coincide.
Si dos rutas todavía coinciden por igual, se le dará precedencia a las rutas con
una coincidencia de ruta exacta sobre las rutas que contienen prefijos.
Comodines Hostname
Los hosts pueden ser coincidencias exactas
(por ejemplo “foo.bar.com”) o un comodín (por ejemplo “*.foo.com”).
Las coincidencias precisas requieren que el encabezado host coincida con el
campo host.
Las coincidencias de comodín requieren que el encabezado host sea igual al
sufijo de la regla del comodín.
Host
Encabezado Host
¿Coincidencia?
*.foo.com
bar.foo.com
Coincide basado en el sufijo común
*.foo.com
baz.bar.foo.com
No coincide, el comodín solo cubre una etiqueta DNS
*.foo.com
foo.com
No coincide, el comodín solo cubre una etiqueta DNS
Los Ingress pueden ser implementados por distintos controladores,
comúnmente con una configuración distinta.
Cada Ingress debería especificar una clase,
una referencia a un recurso IngressClass que contiene información adicional
incluyendo el nombre del controlador que debería implementar la clase.
El campo .spec.parameters de un IngressClass te permite hacer referencia a
otro recurso que proporciona la configuración relacionada con esa IngressClass.
El tipo específico de parámetros a usar depende del controlador de Ingress que
especificas en el campo spec.controller de la IngressClass.
Alcance de IngressClass
Dependiendo de tu controlador de ingress, podrías ser capaz de usar parámetros
que se establecen en todo el clúster, o solamente para un namespace.
El alcance por defecto de los parámetros IngressClass es para todo el clúster.
Si estableces el campo spec.parameters y no estableces el
campo spec.parameters.scope,
entonces el IngressClass se refiere al recurso cuyo alcance es todo el clúster.
El atributo kind (en combinación con el apiGroup)
de los parámetros se refiere a la API con alcance a todo el clúster
(posiblemente un recurso personalizado), y el name de los parámetros
identifica al recurso del clúster específico para esa API.
Por ejemplo:
---apiVersion:networking.k8s.io/v1kind:IngressClassmetadata:name:external-lb-1spec:controller:example.com/ingress-controllerparameters:# Los parámetros para este IngressClass se especifican en un# ClusterIngressParameter (API group k8s.example.net) llamado# "external-config-1". Esta definición le indica a Kubernetes # de buscar por un parámetro de recurso con alcance a todo el clúster.scope:ClusterapiGroup:k8s.example.netkind:ClusterIngressParametername:external-config-1
Si estableces el campo spec.parameters y el spec.parameters.scope
al Namespace,
entonces el IngressClass se refiere al recurso cuyo alcance es el namespace.
También debes establecer el campo namespace dentro de spec.parameters con el
Namespace que contiene los parámetros que quieres usar.
El atributo kind (en combinación con apiGroup)
de los parámetros se refiere a la API restringida por un Namespace (por ejemplo:
ConfigMap), y el name de los parámetros identifica al recurso específico en el
namespace que has especificado en namespace.
Los parámetros con alcance al Namespace ayudan al operador del clúster a delegar
el control sobre la configuración
(por ejemplo, ajustes del balanceador de cargas, definición de una API gateway)
que se usa para una carga de trabajo.
Si utilizas un parámetro con alcance al Namespace entonces:
El equipo operador del clúster necesita aprobar los cambios de un equipo
distinto cada vez que se aplica un nuevo cambio a la configuración.
O el equipo operador del clúster debe definir específicamente estos controles
de acceso, tales como asociaciones de
roles RBAC y mapeos, que permitan
a la aplicación hacer cambios al recurso de parámetros con alcance al clúster.
La API de la IngressClass por sí misma siempre tiene alcance al clúster.
Aquí hay un ejemplo de una IngressClass que hace referencia a parámetros que
están restringidos por un Namespace:
---apiVersion:networking.k8s.io/v1kind:IngressClassmetadata:name:external-lb-2spec:controller:example.com/ingress-controllerparameters:# Los parámetros para esta IngressClass se especifican en un # IngressParameter (API group k8s.example.com) llamado "external-config",# que está en el namespace "external-configuration".scope:NamespaceapiGroup:k8s.example.comkind:IngressParameternamespace:external-configurationname:external-config
Anotación deprecada
Antes que el recurso IngressClass y el campo ingressClassName se añadieran a
Kubernetes
1.18,
las clases Ingress se especificaban con una
anotación kubernetes.io/ingress.class en el Ingress.
Esta anotación nunca se definió formalmente,
pero era ampliamente soportada por los controladores de Ingress.
El nuevo campo ingressClassName en los recursos Ingress es un reemplazo para
esa anotación, pero no es un equivalente directo.
Mientras que la anotación se utilizaba generalmente para hacer referencia al
nombre del controlador de Ingress que debería implementar el Ingress, el campo
es una referencia a un recurso IngressClass que contiene configuración adicional
del Ingress, incluyendo el nombre del controlador Ingress.
IngressClass por defecto
Puedes marcar un ingressClass en particular por defecto para tu clúster.
Establecer la anotación ingressclass.kubernetes.io/is-default-class a true
en un recurso IngressClass
asegurará que los nuevos Ingress sin un campo ingressClassName especificado
sean asignados a esta IngressClass por defecto.
Precaución:
Si tienes más de una IngressClass marcada por defecto en tu clúster,
el controlador de admisión impide crear objetos que no tienen
un ingressClassName especificado.
Puedes resolver esto asegurándote que como máximo 1 IngressClass está marcado
como el predeterminado en tu clúster.
Existen algunos controladores de ingress,
que funcionan sin una definición de una ingressClass.
Por ejemplo, el controlador Ingress-NGINX se puede configurar con
una opción--watch-ingress-without-class.
Sin embargo,
se recomienda
especificar el IngressClass predeterminado:
Hay conceptos existentes de Kubernetes que te permiten exponer un Service
único
(mirar alternativas).
También puedes hacerlo con un Ingress especificando un backend predeterminado
sin reglas.
Si lo creas usando kubectl apply -f podrías mirar el estado del Ingress que
has creado:
kubectl get ingress test-ingress
NAME CLASS HOSTS ADDRESS PORTS AGE
test-ingress external-lb * 203.0.113.123 80 59s
Donde 203.0.113.123 es la IP asignada por el controlador Ingress para
satisfacer este Ingress.
Nota:
Los controladores de Ingress y los balanceadores de carga pueden tardar un
minuto o dos en asignar una dirección IP.
Hasta entonces, se podrá ver la dirección marcada como <pending>.
Abanico Simple
Una configuración de abanico enruta el tráfico de una única dirección IP a más
de un Service,
basado en la URI HTTP solicitada.
Un Ingress te permite tener el número de balanceadores de carga al mínimo.
Por ejemplo, una configuración como:
Name: simple-fanout-example
Namespace: default
Address: 178.91.123.132
Default backend: default-http-backend:80 (10.8.2.3:8080)
Rules:
Host Path Backends
---- ---- --------
foo.bar.com
/foo service1:4200 (10.8.0.90:4200)
/bar service2:8080 (10.8.0.91:8080)
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal ADD 22s loadbalancer-controller default/test
El controlador de Ingress aprovisiona un balanceador de cargas específico para
la implementación que satisface al Ingress,
mientras los Services (service1, service2) existan.
Cuando sea así,
podrás ver la dirección del balanceador de cargas en el campo de dirección.
Si creas un recurso Ingress sin ningún host definido en las reglas,
luego cualquier tráfico web a la dirección IP de tu controlador Ingress puede
coincidir sin requerir un host virtual basado en el nombre.
Por ejemplo, el siguiente Ingress enruta el tráfico solicitado
para first.bar.com a service1, second.bar.com a service2,
y cualquier tráfico cuyo encabezado de petición del host no coincida
con first.bar.com y second.bar.com a service3.
Puedes segurizar un Ingress especificando un Secret que contiene una clave privada TLS y un certificado.
El recurso Ingress solo soporta un puerto TLS,
el 443,
y asume la terminación TLS en el punto del ingress
(El tráfico al Service y sus Pods es en texto plano).
Si la sección de configuración TLS especifica hosts diferentes,
se multiplexan en el mismo puerto de acuerdo con el hostname especificado a
través de la extensión TLS SNI (teniendo el cuenta que el controlador de Ingress
soporte SNI).
El secreto TLS debe contener claves llamadas tls.crt y tls.key que contiene
el certificado y llave privad para usar TLS.
Por ejemplo:
Al hacer referencia a este secreto en un Ingress le indica al controlador
Ingress de segurizar el canal desde el cliente al balanceador de cargas usando
TLS.
Necesitas asegurarte que el secreto TLS que has creado viene de un certificado que
contiene un nombre común (CN), también conocido como Nombre de dominio
calificado (FQDN en inglés)
para https-example.foo.com.
Nota:
Ten en cuenta que TLS no funcionará en la regla predeterminada porque los
certificados estarían emitidos para todos los sub-dominios posibles.
Por lo tanto, los hosts en la sección tls tienen que coincidir
explícitamente con el host en la sección rules.
Hay una diferencia entre las características TLS soportadas por varios
controladores Ingress.
Mira la documentación
en nginx, GCE,
o cualquier otro controlador Ingress específico de plataforma para entender cómo
funciona el TLS en tu entorno.
Balanceo de cargas
Un controlador de Ingress está configurado por defecto con algunos ajustes de
política de balanceo de cargas que aplica a todos los Ingress, como los
algoritmos de balanceo de cargas, esquema de pesos del backend y otros.
Otros conceptos más avanzados de balanceo de cargas (ej., sesiones persistentes,
pesos dinámicos) no están expuestos todavía a través del Ingress.
En su lugar, obtienes estas características a través del balanceador de cargas
usado por un Service.
Vale la pena apuntar que aunque las revisiones de salud no se exponen
directamente a través del Ingress, existen conceptos paralelos en Kubernetes
tales
como readiness probes
que permiten lograr el mismo resultado final.
Revisa la documentación específica del controlador para conocer cómo manejar estas
revisiones de salud (por ejemplo:
nginx,
o GCE).
Actualizando un Ingress
Para actualizar un Ingress existente a un nuevo Host,
puedes actualizarlo editando el recurso:
kubectl describe ingress test
Name: test
Namespace: default
Address: 178.91.123.132
Default backend: default-http-backend:80 (10.8.2.3:8080)
Rules:
Host Path Backends
---- ---- --------
foo.bar.com
/foo service1:80 (10.8.0.90:80)
Annotations:
nginx.ingress.kubernetes.io/rewrite-target: /
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal ADD 35s loadbalancer-controller default/test
kubectl edit ingress test
Esto muestra un editor con la configuración existente en formato YAML.
Modifícalo para incluir el nuevo Host:
Luego de guardar tus cambios,
kubectl actualiza el recurso en el servidor API, que le indica al controlador
Ingress de reconfigurar el balanceador de cargas.
Verifica esto:
kubectl describe ingress test
Name: test
Namespace: default
Address: 178.91.123.132
Default backend: default-http-backend:80 (10.8.2.3:8080)
Rules:
Host Path Backends
---- ---- --------
foo.bar.com
/foo service1:80 (10.8.0.90:80)
bar.baz.com
/foo service2:80 (10.8.0.91:80)
Annotations:
nginx.ingress.kubernetes.io/rewrite-target: /
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal ADD 45s loadbalancer-controller default/test
Puedes lograr el mismo resultado invocando kubectl replace -f en un fichero
YAML de Ingress.
Fallos a través de zonas de disponibilidad
Las técnicas para distribuir el tráfico entre dominios de falla difieren entre
los proveedores de la nube.
Revisa la documentación
del Ingress controller
relevante para detalles.
Alternativas
Puedes exponer un Service de muchas maneras que no involucran directamente el
recurso Ingress:
Para que un Ingress funcione en tu clúster, debe haber un ingress controller en ejecución. Debes seleccionar al menos un controlador Ingress y asegurarte de que está configurado en tu clúster. En esta página se enumeran los controladores Ingress más comunes que se pueden implementar.
Para que el recurso Ingress funcione, el clúster necesita tener un controlador Ingress corriendo.
Mientras otro tipo de controladores que corren como parte del binario de kube-controller-manager, los controladores Ingress no son automaticamente iniciados dentro del clúster. Usa esta página para elegir la mejor implementación de controlador Ingress que funcione mejor para tu clúster.
Kubernetes es un proyecto que soporta y mantiene los controladores Ingress de AWS, GCE y
nginx.
Controladores adicionales
Nota: This section links to third party projects that provide functionality required by Kubernetes. The Kubernetes project authors aren't responsible for these projects, which are listed alphabetically. To add a project to this list, read the content guide before submitting a change. More information.
Skipper es un enrutador HTTP y proxy inverso para la composición de servicios, incluyendo casos de uso como Kubernetes Ingress, diseñado como una biblioteca para construir su proxy personalizado.
El Tyk Operator amplía Ingress con recursos personalizados para aportar capacidades de gestión de API a Ingress. Tyk Operator funciona con el plano de control de código abierto Tyk Gateway y Tyk Cloud.
Wallarm Ingress Controller es un controlador Ingress que proporciona capacidades de seguridad WAAP (WAF) y API.
Uso de varios controladores Ingress
Puedes desplegar cualquier número de controladores Ingress utilizando clase ingress
dentro de un clúster. Ten en cuenta el .metadata.name de tu recurso de clase Ingress. Cuando creas un Ingress, necesitarás ese nombre para especificar el campo ingressClassName de su objeto Ingress (consulta referencia IngressSpec v1). ingressClassName sustituye el antiguo método de anotación.
Si no especificas una IngressClass para un Ingress, y tu clúster tiene exactamente una IngressClass marcada como predeterminada, Kubernetes aplica la IngressClass predeterminada del clúster al Ingress.
Se marca una IngressClass como predeterminada estableciendo la anotación ingressclass.kubernetes.io/is-default-class en esa IngressClass, con el valor de cadena "true".
Lo ideal sería que todos los controladores Ingress cumplieran esta especificación, pero los distintos controladores Ingress funcionan de forma ligeramente diferente.
Nota:
Asegúrate de revisar la documentación de tu controlador Ingress para entender las advertencias de tu elección.
Si quieres controlar el tráfico de red a nivel de dirección IP o puerto (capa OSI 3 o 4), puedes considerar el uso de Kubernetes NetworkPolicies para las aplicaciones que corren en tu clúster. Las NetworkPolicies son una estructura enfocada en las aplicaciones que permite establecer cómo un Pod puede comunicarse con otras "entidades" (utilizamos la palabra "entidad" para evitar sobrecargar términos más comunes como "Endpoint" o "Service", que tienen connotaciones específicas de Kubernetes) a través de la red. Las NetworkPolicies se aplican a uno o ambos extremos de la conexión a un Pod, sin afectar a otras conexiones.
Las entidades con las que un Pod puede comunicarse son una combinación de estos 3 tipos:
Otros Pods permitidos (excepción: un Pod no puede bloquear el acceso a sí mismo)
Namespaces permitidos
Bloqueos de IP (excepción: el tráfico hacia y desde el nodo donde se ejecuta un Pod siempre está permitido, independientemente de la dirección IP del Pod o del nodo)
Cuando se define una NetworkPolicy basada en Pods o Namespaces, se utiliza un Selector para especificar qué tráfico se permite desde y hacia los Pod(s) que coinciden con el selector.
Por otro lado, cuando se crean NetworkPolicies basadas en IP, se definen políticas basadas en bloques de IP (rangos CIDR).
Prerrequisitos
Las políticas de red son implementadas por el plugin de red. Para usar políticas de red, debes estar utilizando una solución de red que soporte NetworkPolicy. Crear un recurso NetworkPolicy sin un controlador que lo habilite no tendrá efecto alguno.
Dos Tipos de Aislamiento de Pod
Hay dos tipos de aislamiento para un Pod: el aislamiento para la salida y el aislamiento para la entrada. Estos se refieren a las conexiones que pueden establecerse. El término "Aislamiento" en el contexto de este documento no es absoluto, sino que significa "se aplican algunas restricciones". La alternativa, "no aislado para $dirección", significa que no se aplican restricciones en la dirección descrita. Los dos tipos de aislamiento (o no) se declaran independientemente, y ambos son relevantes para una conexión de un Pod a otro.
Por defecto, un Pod no está aislado para la salida; todas las conexiones salientes están permitidas. Un Pod está aislado para la salida si hay alguna NetworkPolicy con "Egress" en su policyTypes que seleccione el Pod; decimos que tal política se aplica al Pod para la salida. Cuando un Pod está aislado para la salida, las únicas conexiones permitidas desde el Pod son las permitidas por la lista egress de las NetworkPolicy que se apliquen al Pod para la salida. Los valores de esas listas egress se combinan de forma aditiva.
Por defecto, un Pod no está aislado para la entrada; todas las conexiones entrantes están permitidas. Un Pod está aislado para la entrada si hay alguna NetworkPolicy con "Ingress" en su policyTypes que seleccione el Pod; decimos que tal política se aplica al Pod para la entrada. Cuando un Pod está aislado para la entrada, las únicas conexiones permitidas en el Pod son las del nodo del Pod y las permitidas por la lista ingress de alguna NetworkPolicy que se apliquen al Pod para la entrada. Los valores de esas listas de direcciones se combinan de forma aditiva.
Las políticas de red no entran en conflicto; son aditivas. Si alguna política(s) se aplica a un Pod para una dirección determinada, las conexiones permitidas en esa dirección desde ese Pod son la unión de lo que permiten las políticas aplicables. Por lo tanto, el orden de evaluación no afecta al resultado de la política.
Para que se permita una conexión desde un Pod de origen a un Pod de destino, tanto la política de salida del Pod de origen como la de entrada del Pod de destino deben permitir la conexión. Si cualquiera de los dos lados no permite la conexión, ésta no se producirá.
El Recurso NetworkPolicy
Ver la referencia NetworkPolicy para una definición completa del recurso.
Enviar esto al API Server de tu clúster no tendrá ningún efecto a menos que tu solución de red soporte políticas de red.
Campos Obligatorios: Como con todas las otras configuraciones de Kubernetes, una NetworkPolicy
necesita los campos apiVersion, kind, y metadata. Para obtener información general
sobre cómo funcionan esos archivos de configuración, puedes consultar
Configurar un Pod para usar un ConfigMap,
y Gestión de Objetos.
spec: NetworkPolicy spec contiene toda la información necesaria para definir una política de red dado un Namespace.
podSelector: Cada NetworkPolicy incluye un podSelector el cual selecciona el grupo de Pods en los cuales aplica la política. La política de ejemplo selecciona Pods con la etiqueta "role=db". Un podSelector vacío selecciona todos los Pods en un Namespace.
policyTypes: Cada NetworkPolicy incluye una lista de policyTypes la cual puede incluir Ingress, Egress, o ambas. Los campos policyTypes indican si la política aplica o no al tráfico de entrada hacia el Pod seleccionado, el tráfico de salida desde el Pod seleccionado, o ambos. Si no se especifican policyTypes en una NetworkPolicy, el valor Ingress se aplicará siempre por defecto y Egress se aplicará si la NetworkPolicy contiene alguna regla de salida.
ingress: Cada NetworkPolicy puede incluir una lista de reglas ingress permitidas. Cada regla permite el tráfico relacionado con los valores de las secciones from y ports. La política de ejemplo contiene una única regla, la cual se relaciona con el tráfico sobre un solo puerto, desde uno de los tres orígenes definidos, el primero especificado por el valor ipBlock, el segundo especificado por el valor namespaceSelector y el tercero especificado por el podSelector.
egress: Cada NetworkPolicy puede incluir una lista de reglas de egress permitidas. Cada regla permite el tráfico relacionado con los valores de las secciones to y ports. La política de ejemplo contiene una única regla, la cual se relaciona con el tráfico en un único puerto para cualquier destino en el rango de IPs 10.0.0.0/24.
Por lo tanto, la NetworkPolicy de ejemplo:
Aísla los Pods "role=db" en el Namespace "default" para ambos tipos de tráfico ingress y egress (si aún no están aislados).
(Reglas Ingress) permite la conexión hacia todos los Pods en el Namespace "default" con la etiqueta "role=db" en el puerto TCP 6379 desde los siguientes orígenes:
cualquier Pod en el Namespace "default" con la etiqueta "role=frontend"
cualquier Pod en un Namespace con la etiqueta "project=myproject"
La dirección IP en los rangos 172.17.0.0–172.17.0.255 y 172.17.2.0–172.17.255.255 (por ejemplo, todo el rango de IPs de 172.17.0.0/16 con excepción del 172.17.1.0/24)
(Reglas de Egress) permite la conexión desde cualquier Pod en el Namespace "default" con la etiqueta "role=db" hacia CIDR 10.0.0.0/24 en el puerto TCP 5978
Existen cuatro tipos de selectores que pueden ser especificados en una sección ingressfrom o en una sección egressto:
podSelector: Este selector selecciona Pods específicos en el mismo Namespace que la NetworkPolicy para permitir el tráfico como origen de entrada o destino de salida.
namespaceSelector: Este selector selecciona Namespaces específicos para permitir el tráfico como origen de entrada o destino de salida.
namespaceSelectorypodSelector: Una única entrada to/from que especifica tanto namespaceSelector como podSelector selecciona Pods específicos dentro de Namespaces específicos. Es importante revisar que se utiliza la sintaxis de YAML correcta. A continuación se muestra un ejemplo de esta política:
contiene un elemento from permitiendo conexiones desde los Pods con el label role=client en Namespaces con el label user=alice. Por el contrario, esta política:
contiene dos elementos en el array from, y permite conexiones desde Pods en los Namespaces con el label role=client, o desde cualquier Pod en cualquier Namespace con el label user=alice.
En caso de duda, utilice kubectl describe para ver cómo Kubernetes ha interpretado la política.
ipBlock: Este selector selecciona rangos CIDR de IP específicos para permitirlas como origen de entrada o destino de salida. Estas IPs deben ser externas al clúster, ya que las IPs de Pod son efímeras e impredecibles.
Los mecanismos de entrada y salida del clúster a menudo requieren reescribir la IP de origen o destino
de los paquetes. En los casos en los que esto ocurre, no está definido si esto ocurre antes o
después del procesamiento de NetworkPolicy, y el comportamiento puede ser diferente para diferentes
combinaciones de plugin de red, proveedor de nube, implementación de Service, etc.
En el caso de la entrada, esto significa que en algunos casos se pueden filtrar paquetes
entrantes basándose en la IP de origen real, mientras que en otros casos, la "IP de origen" sobre la que actúa la NetworkPolicy
puede ser la IP de un LoadBalancer o la IP del Nodo donde está el Pod involucrado, etc.
Para la salida, esto significa que las conexiones de los Pods a las IPs de Service que se reescriben a
IPs externas al clúster pueden o no estar sujetas a políticas basadas en ipBlock.
Políticas por defecto
Por defecto, si no existen políticas en un Namespace, se permite todo el tráfico de entrada y salida hacia y desde los Pods de ese Namespace. Los siguientes ejemplos muestran cómo cambiar el comportamiento por defecto en ese Namespace.
Denegar todo el tráfico de entrada por defecto
Puedes crear una política que "por defecto" aisle a un Namespace del tráfico de entrada con la creación de una política que seleccione todos los Pods del Namespace pero no permite ningún tráfico de entrada en esos Pods.
Esto asegura que incluso los Pods que no están seleccionados por ninguna otra NetworkPolicy también serán aislados del tráfico de entrada. Esta política no afecta el aislamiento en el tráfico de salida desde cualquier Pod.
Permitir todo el tráfico de entrada
Si quieres permitir todo el tráfico de entrada a todos los Pods en un Namespace, puedes crear una política que explícitamente permita eso.
Con esta política en curso, ninguna política(s) adicional puede hacer que se niegue cualquier conexión entrante a esos Pods. Esta política no tiene efecto sobre el aislamiento del tráfico de salida de cualquier Pod.
Denegar por defecto todo el tráfico de salida
Puedes crear una política que "por defecto" aisle el tráfico de salida para un Namespace, creando una NetworkPolicy que seleccione todos los Pods pero que no permita ningún tráfico de salida desde esos Pods.
Esto asegura que incluso los Pods que no son seleccionados por ninguna otra NetworkPolicy no tengan permitido el tráfico de salida. Esta política no cambia el comportamiento de aislamiento para el tráfico de entrada de ningún Pod.
Permitir todo el tráfico de salida
Si quieres permitir todas las conexiones desde todos los Pods de un Namespace, puedes crear una política que permita explícitamente todas las conexiones salientes de los Pods de ese Namespace.
Con esta política en vigor, ninguna política(s) adicional puede hacer que se niegue cualquier conexión de salida desde esos Pods. Esta política no tiene efecto sobre el aislamiento para el tráfico de entrada a cualquier Pod.
Denegar por defecto todo el tráfico de entrada y de salida
Puedes crear una política que "por defecto" en un Namespace impida todo el tráfico de entrada y de salida creando la siguiente NetworkPolicy en ese Namespace.
Esto asegura que incluso los Pods que no son seleccionados por ninguna otra NetworkPolicy no tendrán permitido el tráfico de entrada o salida.
Soporte a SCTP
FEATURE STATE:Kubernetes v1.20 [stable]
Como característica estable, está activada por defecto. Para deshabilitar SCTP a nivel de clúster, usted (o el administrador de su clúster) tiene que deshabilitar la feature gateSCTPSupport para el API Server con el flag --feature-gates=SCTPSupport=false,....
Cuando esta feature gate está habilitada, puede establecer el campo protocol de una NetworkPolicy como SCTP.
Nota:
Debes utilizar un plugin de CNI que soporte el protocolo SCTP NetworkPolicies.
Apuntar a un rango de puertos
FEATURE STATE:Kubernetes v1.22 [beta]
Cuando se escribe una NetworkPolicy, se puede apuntar a un rango de puertos en lugar de un solo puerto.
Esto se puede lograr con el uso del campo endPort, como en el siguiente ejemplo:
La regla anterior permite que cualquier Pod con la etiqueta role=db en el Namespace default se comunique
con cualquier IP dentro del rango 10.0.0.0/24 sobre el protocolo TCP, siempre que el puerto
esté entre el rango 32000 y 32768.
Se aplican las siguientes restricciones al utilizar este campo:
Como característica en estado beta, está activada por defecto. Para desactivar el campo endPort a nivel de clúster, usted (o su administrador de clúster) debe desactivar la feature gateNetworkPolicyEndPort en el API Server con el flag --feature-gates=NetworkPolicyEndPort=false,....
El campo endPort debe ser igual o mayor que el campo port.
Solo se puede definir endPort si también se define port.
Ambos puertos deben ser numéricos.
Nota:
Su clúster debe utilizar un plugin de CNI que
soporte el campo endPort en las especificaciones de NetworkPolicy.
Si su plugin de red
no soporta el campo endPort y usted especifica una NetworkPolicy que use este campo,
la política se aplicará solo para el campo port.
Cómo apuntar a un Namespace usando su nombre
FEATURE STATE:Kubernetes 1.22 [stable]
El plano de control de Kubernetes establece una etiqueta inmutable kubernetes.io/metadata.name en todos los
Namespaces, siempre que se haya habilitado la feature gateNamespaceDefaultLabelName.
El valor de la etiqueta es el nombre del Namespace.
Aunque NetworkPolicy no puede apuntar a un Namespace por su nombre con algún campo de objeto, puede utilizar la etiqueta estandarizada para apuntar a un Namespace específico.
Qué no puedes hacer con políticas de red (al menos, aún no)
Actualmente, en Kubernetes 1.31, la siguiente funcionalidad no existe en la API de NetworkPolicy, pero es posible que se puedan implementar soluciones mediante componentes del sistema operativo (como SELinux, OpenVSwitch, IPTables, etc.) o tecnologías de capa 7 (controladores Ingress, implementaciones de Service Mesh) o controladores de admisión. En caso de que seas nuevo en la seguridad de la red en Kubernetes, vale la pena señalar que las siguientes historias de usuario no pueden (todavía) ser implementadas usando la API NetworkPolicy.
Forzar que el tráfico interno del clúster pase por una puerta de enlace común (esto se puede implementar con una malla de servicios u otro proxy).
Cualquier cosa relacionada con TLS (se puede implementar con una malla de servicios o un controlador Ingress para esto).
Políticas específicas de los nodos (se puede utilizar la notación CIDR para esto, pero no se puede apuntar a los nodos por sus identidades Kubernetes específicamente).
Apuntar Services por nombre (sin embargo, se pueden orientar los Pods o los Namespaces por sus labels, lo que suele ser una solución viable).
Creación o gestión de "solicitudes de políticas" que son atendidas por un tercero.
Políticas que por defecto son aplicadas a todos los Namespaces o Pods (hay algunas distribuciones y proyectos de Kubernetes de terceros que pueden hacer esto).
Consulta avanzada de políticas y herramientas de accesibilidad.
La capacidad de registrar los eventos de seguridad de la red (por ejemplo, las conexiones bloqueadas o aceptadas).
La capacidad de negar explícitamente las políticas (actualmente el modelo para NetworkPolicies es negar por defecto, con solo la capacidad de añadir reglas de permitir).
La capacidad de impedir el tráfico entrante de Loopback o de Host (actualmente los Pods no pueden bloquear el acceso al host local, ni tienen la capacidad de bloquear el acceso desde su nodo residente).
Ver más recetas de escenarios comunes habilitados por los recursos de las NetworkPolicy.
3.5.5 - EndpointSlices
La API de EndpointSlice es el mecanismo que Kubernetes utiliza para permitir que tu Servicio escale para manejar un gran número de backends, y permite que el clúster actualice tu lista de
backends saludables eficientemente.
FEATURE STATE:Kubernetes v1.21 [stable]
La API de EndpointSlice de Kubernetes proporciona una forma de rastrear los endpoints de red
dentro de un clúster Kubernetes. EndpointSlices ofrece una alternativa más escalable
y extensible a Endpoints.
EndpointSlice API
En Kubernetes, un EndpointSlice contiene referencias a un conjunto de endpoints de red. El plano de control crea automáticamente EndpointSlices para cualquier Servicio de Kubernetes que tenga especificado un selector. Estos EndpointSlices incluyen referencias a todos los Pods que coinciden con el selector de Servicio. Los EndpointSlices agrupan los endpoints de la red mediante combinaciones únicas de protocolo, número de puerto y nombre de Servicio.
Por defecto, el plano de control crea y gestiona EndpointSlices para que no tengan más de 100 endpoints cada una. Puedes configurar esto con la bandera de funcionalidad
--max-endpoints-per-slicekube-controller-manager
hasta un máximo de 1000.
EndpointSlices puede actuar como la fuente de verdad
kube-proxy sobre cómo enrutar el tráfico interno.
Tipos de dirección
EndpointSlices admite tres tipos de direcciones:
IPv4
IPv6
FQDN (Fully Qualified Domain Name)
Cada objeto EndpointSlice representa un tipo de dirección IP específico. Si tienes un servicio disponible a través de IPv4 e IPv6, habrá al menos dos objetos EndpointSlice (uno para IPv4 y otro para IPv6).
Condiciones
La API EndpointSlice almacena condiciones sobre los endpoints que pueden ser útiles para los consumidores.
Las tres condiciones son ready, serving y terminating.
Ready
ready es una condición que corresponde a la condición Ready de un Pod. Un Pod en ejecución con la condición Ready establecida a True debería tener esta condición EndpointSlice también establecida a true. Por razones de compatibilidad, ready NUNCA es true cuando un Pod está terminando. Los consumidores deben referirse a la condición serving para inspeccionar la disponibilidad de los Pods que están terminando. La única excepción a esta regla son los servicios con spec.publishNotReadyAddresses a true. Los endpoints de estos servicios siempre tendrán la condición ready a true.
Serving
FEATURE STATE:Kubernetes v1.26 [stable]
La condición serving es casi idéntica a la condición ready. La diferencia es que los consumidores de la API EndpointSlice deben comprobar la condición serving si se preocupan por la disponibilidad del pod mientras el pod también está terminando.
Nota:
Aunque serving es casi idéntico a ready, se añadió para evitar romper el significado existente de ready. Podría ser inesperado para los clientes existentes si ready pudiera ser true para los endpoints de terminación, ya que históricamente los endpoints de terminación nunca se incluyeron en la API Endpoints o EndpointSlice para empezar. Por esta razón, ready es siemprefalse para los Endpoints que terminan, y se ha añadido una nueva condición serving en la v1.20 para que los clientes puedan realizar un seguimiento de la disponibilidad de los pods que terminan independientemente de la semántica existente para ready.
Terminating
FEATURE STATE:Kubernetes v1.22 [beta]
Terminating es una condición que indica si un endpoint está terminando. En el caso de los pods, se trata de cualquier pod que tenga establecida una marca de tiempo de borrado.
Información sobre topología
Cada endpoint dentro de un EndpointSlice puede contener información topológica relevante. La información de topología incluye la ubicación del endpoint e información sobre el Nodo y la zona correspondientes. Estos están disponibles en los siguientes campos por endpoint en EndpointSlices:
nodeName - El nombre del Nodo en el que se encuentra este endpoint.
zone - La zona en la que se encuentra este endpoint.
Nota:
En la API v1, el endpoint topology se eliminó en favor de los campos dedicados nodeName y zone.
La configuración de campos de topología arbitrarios en el campo endpoint de un recurso EndpointSlice ha quedado obsoleta y no se admite en la API v1. En su lugar, la API v1 permite establecer campos individuales nodeName y zone. Estos campos se traducen automáticamente entre versiones de la API. Por ejemplo, el valor de la clave "topology.kubernetes.io/zone" en el campo topology de la API v1beta1 es accesible como campo zone en la API v1.
Administración
En la mayoría de los casos, el plano de control (concretamente, el endpoint slice controller) crea y gestiona objetos EndpointSlice. Existe una variedad de otros casos de uso para EndpointSlices, como implementaciones de servicios Mesh, que podrían dar lugar a que otras entidades o controladores gestionen conjuntos adicionales de EndpointSlices.
Para garantizar que varias entidades puedan gestionar EndpointSlices sin interferir unas con otras, Kubernetes define el parámetro
labelendpointslice.kubernetes.io/managed-by, que indica la entidad que gestiona un EndpointSlice.
El controlador de endpoint slice establece endpointslice-controller.k8s.io como valor para esta etiqueta en todos los EndpointSlices que gestiona. Otras entidades que gestionen EndpointSlices también deben establecer un valor único para esta etiqueta.
Propiedad
En la mayoría de los casos de uso, los EndpointSlices son propiedad del Servicio para el que el objeto EndpointSlices rastree los endpoints. Esta propiedad se indica mediante una referencia de propietario en cada EndpointSlice, así como una etiqueta kubernetes.io/service-name que permite búsquedas sencillas de todos los EndpointSlices que pertenecen a un Servicio.
Replicación de EndpointSlice
En algunos casos, las aplicaciones crean recursos Endpoints personalizados. Para garantizar que estas aplicaciones no tengan que escribir simultáneamente en recursos Endpoints y EndpointSlice, el plano de control del clúster refleja la mayoría de los recursos Endpoints en los EndpointSlices correspondientes.
El plano de control refleja los recursos de los Endpoints a menos que:
El recurso Endpoints tenga una etiqueta endpointslice.kubernetes.io/skip-mirror con el valor en true.
El recurso Endpoints tenga una anotación control-plane.alpha.kubernetes.io/leader.
El recurso Service correspondiente no exista.
El recurso Service correspondiente tiene un selector no nulo.
Los recursos Endpoints individuales pueden traducirse en múltiples EndpointSlices. Esto ocurrirá si un recurso Endpoints tiene
múltiples subconjuntos o incluye endpoints con múltiples familias IP (IPv4 e IPv6). Se reflejará un máximo de 1000 direcciones
por subconjunto en EndpointSlices.
Distribución de EndpointSlices
Cada EndpointSlice tiene un conjunto de puertos que se aplica a todos los endpoints dentro del recurso. Cuando se utilizan puertos con nombre para un Servicio, los Pods pueden terminar con diferentes números de puerto de destino para el mismo puerto con nombre, requiriendo diferentes EndpointSlices. Esto es similar a la lógica detrás de cómo se agrupan los subconjuntos con Endpoints.
El plano de control intenta llenar los EndpointSlices tanto como sea posible, pero no los reequilibra activamente. La lógica es bastante sencilla:
Iterar a través de los EndpointSlices existentes, eliminar los endpoints que ya no se deseen y actualizar los endpoints coincidentes que hayan cambiado.
Recorrer los EndpointSlices que han sido modificados en el primer paso y rellenarlos con los nuevos endpoints necesarios.
Si aún quedan nuevos endpoints por añadir, intente encajarlos en un slice que no se haya modificado previamente y/o cree otros nuevos.
Es importante destacar que el tercer paso prioriza limitar las actualizaciones de EndpointSlice sobre una distribución perfectamente completa de EndpointSlices. Por ejemplo, si hay 10 nuevos endpoints que añadir y 2 EndpointSlices con espacio para 5 endpoints más cada uno, este enfoque creará un nuevo EndpointSlice en lugar de llenar los 2 EndpointSlices existentes. En otras palabras, es preferible una única creación de EndpointSlice que múltiples actualizaciones de EndpointSlice.
Con kube-proxy ejecutándose en cada Nodo y vigilando los EndpointSlices, cada cambio en un EndpointSlice se vuelve relativamente caro ya que será transmitido a cada Nodo del clúster. Este enfoque pretende limitar el número de cambios que necesitan ser enviados a cada Nodo, incluso si puede resultar con múltiples EndpointSlices que no están llenos.
En la práctica, esta distribución menos que ideal debería ser poco frecuente. La mayoría de los cambios procesados por el controlador EndpointSlice serán lo suficientemente pequeños como para caber en un EndpointSlice existente, y si no, es probable que pronto sea necesario un nuevo EndpointSlice de todos modos. Las actualizaciones continuas de los Deployments también proporcionan un reempaquetado natural de los EndpointSlices con todos los Pods y sus correspondientes endpoints siendo reemplazados.
Endpoints duplicados
Debido a la naturaleza de los cambios de EndpointSlice, los endpoints pueden estar representados en más de un EndpointSlice al mismo tiempo. Esto ocurre de forma natural, ya que los cambios en diferentes objetos EndpointSlice pueden llegar a la vigilancia / caché del cliente de Kubernetes en diferentes momentos.
Nota:
Los clientes de la API EndpointSlice deben iterar a través de todos los EndpointSlices existentes asociados a un Servicio y construir una lista completa de endpoints de red únicos. Es importante mencionar que los endpoints pueden estar duplicados en diferentes EndpointSlices.
Puedes encontrar una implementación de referencia sobre cómo realizar esta agregación y deduplicación de endpoints como parte del código EndpointSliceCache dentro de kube-proxy.
Comparación con endpoints
La API Endpoints original proporcionaba una forma simple y directa de rastrear los endpoints de red en Kubernetes. A medida que los clústeres de Kubernetes y los Services crecían para manejar más tráfico y enviar más tráfico a más Pods backend, las limitaciones de la API original se hicieron más visibles.
Más notablemente, estos incluyen desafíos con la ampliación a un mayor número de endpoints de red.
Dado que todos los endpoints de red para un Servicio se almacenaban en un único objeto Endpoint, esos objetos Endpoints podían llegar a ser bastante grandes. Para los Services que permanecían estables (el mismo conjunto de endpoints durante un largo período de tiempo), el impacto era menos notable; incluso entonces, algunos casos de uso de Kubernetes no estaban bien servidos.
Cuando un Service tenía muchos Endpoints de backend y la carga de trabajo se escalaba con frecuencia o se introducían nuevos cambios con frecuencia, cada actualización del objeto Endpoint para ese Service suponía mucho tráfico entre los componentes del clúster de Kubernetes (dentro del plano de control y también entre los nodos y el servidor de API). Este tráfico adicional también tenía un coste en términos de uso de la CPU.
Con EndpointSlices, la adición o eliminación de un único Pod desencadena el mismo número de actualizaciones a los clientes que están pendientes de los cambios, pero el tamaño de esos mensajes de actualización es mucho menor a gran escala.
EndpointSlices también ha permitido innovar en torno a nuevas funciones, como las redes de doble pila y el enrutamiento con conocimiento de la topología.
Los archivos localizados dentro de un contenedor son efímeros, lo cual presenta problemas
para aplicaciones no triviales cuando se ejecutan en contenedores. Un problema es la
pérdida de archivos cuando el contenedor termina. Kubelet reinicia el contenedor con un estado limpio.
Un segundo problema ocurre cuando compartimos ficheros entre contenedores corriendo juntos dentro de un Pod. La abstracción volume de Kubernetes resuelve ambos problemas.
Se sugiere familiaridad con Pods
Trasfondo
Docker tiene el concepto de volúmenes, aunque es algo más flojo y menos controlado.
Un volumen de Docker es un directorio en disco o en otro contenedor. Docker provee controladores de volúmenes, pero la funcionalidad es algo limitada.
Kubernetes soporta muchos tipos de volúmenes. Un Pod
puede utilizar cualquier número de tipos de volúmenes simultáneamente. Los tipos de volúmenes efímeros tienen el mismo tiempo de vida que un Pod, pero los volúmenes persistentes existen más allá del tiempo de vida de un Pod. Cuando un Pod deja de existir,
Kubernetes destruye los volúmenes efímeros; sin embargo, Kubernetes no destruye los volúmenes persistentes. Para cualquier tipo de volumen en un Pod dado, los datos son preservados a lo largo de los reinicios del contenedor.
En su núcleo, un volumen es un directorio, posiblemente con algunos datos en este, que puede ser accesible para los contenedores en un Pod. Cómo ese directorio llega a crearse, el medio que lo respalda, y el contenido de este se determinan por el tipo de volumen usado.
Para usar un volumen, especifica los volúmenes a proveer al por en .spec.volumes y declara
dónde montar estos volúmenes dentro de los contenedores en .spec.containers[*].volumeMounts.
Un proceso en el contenedor observa una vista del sistema de archivos compuesta por la imagen Docker y volúmenes.
La imagen Docker está en la raíz de la jerarquía del sistema de archivos.
Los volúmenes se montan en las rutas especificadas dentro de la imagen. Los volúmenes no se pueden montar en otros volúmenes o tener enlaces duros a otros volúmenes. Cada contenedor en la configuración del Pod debe especificar de forma independiente donde montar cada volumen.
Tipos de volúmenes
Kubernetes soporta varios tipos de volúmenes
awsElasticBlockStore
Un volumen awsElasticBlockStore monta un
volumen EBS de Amazon Web Services (AWS) en tu Pod. A diferencia de
emptyDir, que se borra cuando se quita un Pod, el contenido de un volumen EBS es persistido cuando se desmonta el volumen.
Esto significa que un volumen EBS puede ser pre-poblado con datos, y que los datos puedes ser compartidos entre pods.
Nota:
Debes crear un volumen EBS usando aws ec2 create-volume o la API de AWS antes de poder usarlo.
Existen algunas restricciones cuando usas un volumen awsElasticBlockStore:
Los nodos en los que corren los pods deben ser instances AWS EC2.
Estas instancias deben estar en la misma región y zona de disponibilidad que el volumen EBS
EBS solo soporta una única instancia EC2 montando un volumen
Creando un volumen AWS EBS
Antes poder usar un volumen EBS en un Pod, necesitas crearlo.
Si el volumen EBS está particionado, puedes suministrar el campo opcional partition: "<partition number>" para especificar cuál partición montar.
Migración CSI AWS EBS CSI
FEATURE STATE:Kubernetes v1.17 [beta]
La función CSIMigration para awsElasticBlockStore, cuando se habilita, redirige todas las operaciones
de complemento desde el complemento existente dentro del árbol existente al controlador de Interfaz de Almacenamiento del Contenedor (CSI) de ebs.csi.aws.com. Para utilizar esta función, el controlador AWS EBS CSI debe ser instalado en el clúster y las características beta
CSIMigration y CSIMigrationAWS deben estar habilitadas.
Migración CSI AWS EBS CSI completa
FEATURE STATE:Kubernetes v1.17 [alpha]
Para desactivar el complemento de almacenamiento awsElasticBlockStore de ser cargado por el administrador de controladores y el kubelet, establece el atributo CSIMigrationAWSComplete a true. Esta función requiere tener instalado el controlador de interfaz de almacenamiento del contenedor (CSI) en todos los nodos en obreros.
azureDisk
El tipo de volumen azureDisk monta un Data Disk de Microsoft Azure en el Pod.
La función CSIMigration para azureDisk, cuando se habilita, redirige todas las operaciones
de complemento desde el complemento existente dentro del árbol existente al controlador de Interfaz de Almacenamiento del Contenedor (CSI) de disk.csi.azure.com. Para utilizar esta función, el controlador Azure Disk CSI debe ser instalado en el clúster y las características beta
CSIMigration y CSIMigrationAzureDisk deben estar habilitadas.
azureFile
El tipo de volumen azureFile monta un volumen de ficheros de Microsoft Azure (SMB 2.1 and 3.0) en un Pod.
La función CSIMigration para azureFile, cuando se habilita, redirige todas las operaciones
de complemento desde el complemento existente dentro del árbol existente al controlador de Interfaz de Almacenamiento del Contenedor (CSI) de file.csi.azure.com. Para utilizar esta función, el controlador Azure File CSI
Driver
debe ser instalado en el clúster y las feature gatesCSIMigration y CSIMigrationAzureFile deben estar habilitadas.
El controlador Azure File CSI no soporta usar el mismo volumen con fsgroups diferentes, si está habilitadla migración CSI Azurefile, usar el mismo volumen con fsgorups diferentes no será compatible en absoluto.
cephfs
Un volumen cephfs permite montar un volumen CephFS existente en tu Pod.
A diferencia de emptydir, que es borrado cuando se remueve el Pod, el contenido de un volumen cephfs es preservado y el volumen es meramente desmontado. Esto significa que un volumen cephfspuede ser pre-poblado por múltiples escritores simultáneamente.
Nota:
Debes tener tu propio servidor Ceph corriendo con el recurso compartido exportado antes de usarlo.
Kubernetes no debe ser configurado con el proveedor cloud OpenStack.
El tipo de volumen cinder se usa para montar un volumen Cinder de OpenStack en tu Pod.
Cinder volume configuration example
apiVersion:v1kind:Podmetadata:name:test-cinderspec:containers:- image:registry.k8s.io/test-webservername:test-cinder-containervolumeMounts:- mountPath:/test-cindername:test-volumevolumes:- name:test-volume# Este volumen de OpenStack debe existir anteriormente.cinder:volumeID:"<volume id>"fsType:ext4
Migración CSI OpenStack
FEATURE STATE:Kubernetes v1.21 [beta]
La función CSIMigration para Cinder está habilitada por defecto en Kubernetes 1.21.
Esta redirige todas las operaciones de complemento desde el complemento existente dentro del árbol existente al controlador de Interfaz de Almacenamiento del Contenedor (CSI) de cinder.csi.openstack.org.
El controlador OpenStack Cinder CSI Driver debe estar instalado en el clúster.
Puedes deshabilitar la migración CSI para tu clúster estableciendo el feature gateCSIMigrationOpenStack a false.
Si deshabilitas la función CSIMigrationOpenStack, el complemento del volumen Cinder dentro del árbol toma la responsabilidad para todos los aspectos de la administración del almacenamiento del volumen Cinder.
configMap
Un ConfigMap
provee una manera de inyectar datos de configuración a los pods.
Los datos almacenados en un ConfigMap se pueden referenciar en un volumen de tipo configMap
y luego ser consumidos por aplicaciones contenerizadas corriendo en un Pod.
Cuando haces referencia a un ConfigMap, provees el nombre del ConfigMap en el volumen.
Puedes personalizar la ruta para una entrada específica en el ConfigMap.
La siguiente configuración muestra cómo montar un ConfigMap log-config en un Pod llamado configmap-pod:
apiVersion:v1kind:Podmetadata:name:configmap-podspec:containers:- name:testimage:busybox:1.28command:['sh','-c','echo "The app is running!" && tail -f /dev/null']volumeMounts:- name:config-volmountPath:/etc/configvolumes:- name:config-volconfigMap:name:log-configitems:- key:log_levelpath:log_level
El ConfigMap log-config es montado como un volumen, y todo el contenido almacenado en su entrada log_level es
montado en el Pod en la ruta /etc/config/log_level. Ten en cuenta que esta ruta se deriva del mountPathdel volumen y el path cuya clave es log_level.
Un contenedor usando un ConfigMap montado como un volumen subPath no recibirá actualizaciones del ConfigMap
Los datos de texto son expuestos como ficheros usando la codificación de caracteres UTF-8. Para otras codificaciones de caracteres, use binaryData.
downwardAPI
Un volumen de downwardAPI hace que los datos API descendentes estén disponibles para las aplicaciones.
Monta un directorio y escribe los datos solicitados en archivos de texto sin formato.
Nota:
Un contenedor usando la API descendiente montado como un volumen subPath no recibirá actualizaciones API descendientes.
Un volumen emptyDires creado primero cuando se asigna un Pod a un nodo, y existe mientras el Pod está corriendo en el nodo.
Como su nombre lo indica un volumen emptydirestá inicialmente vacío. Todos los contenedores en el Pod pueden leer y escribir
los archivos en el volumen emptyDir, aunque ese volumen se puede montar en la misma o diferente ruta en cada contenedor. Cuando un Pod es removido del nodo por alguna razón, los datos en emptydir se borran permanentemente.
Nota:
Un contenedor que colapsa no remueve el Pod del nodo. Los datos en un volumen emptyDir están seguros en caso de
colapso del contenedor.
Algunos usos para un emptyDir son:
Espacio temporal, como para una clasificación de combinación basada en disco
Marcar un largo cálculo para la recuperación de fallos
Contener archivos que un contenedor de administrador de contenido recupera mientras un contenedor de servidor web
sirve los datos
Dependiendo de tu entorno, los volúmenes emptydir se almacenan en cualquier medio que respalde el nodo tales como disco SSD, o almacenamiento de red. Sin embargo, si se establece el campo emptydir.medium a Memory, Kubernetes monta en su lugar un tmpfs (sistema de ficheros respaldado por la RAM). Mientras que tmpfs es muy rápido, ten en cuenta que a diferencia de los discos, tmpfs se limpia cuando el nodo reinicia y cualquier archivo que escribas cuenta con el límite de memoria del contenedor.
Nota:
Si el feature gateSizeMemoryBackedVolumes está habilitado,
puedes especificar un tamaño para los volúmenes respaldados en memoria. Si no se especifica ningún tamaño, los volúmenes respaldados en memoria tienen un tamaño del 50% de la memoria en un host Linux.
Un tipo de volumen fc permite que un volumen de almacenamiento de bloque de canal de fibra existente se monte en un Pod.
Puede especificar nombres mundiales de destino únicos o múltiples (WWN) utilizando el parámetro targetWWNs en su configuración de volumen.
Si se especifican varios WWN, targettWWNs esperan que esos WWN sean de conexiones de múltiples rutas.
Nota:
Debes configurar FC SAN zoning para asignar y enmascarar esos (volúmenes) LUNs para apuntar a los WWNs de destino de antemano
para que los hosts Kubernetes pueda acceder a ellos.
Flocker es un administrador open-source de volúmenes de contenedor agrupado por clúster.
Flocker proporciona administración y orquestación de volúmenes de datos respaldados por una variedad de backends de almacenamiento.
Un volumen flocker permite montar un conjunto de datos Flocker en un Pod. Si el conjunto de datos no existe en Flocker, necesita ser creado primero con el CLI de Flocker o usando la API de Flocker. Si el conjunto de datos existe será adjuntado
de nuevo por Flocker al nodo donde el Pod está programado. Esto significa que los datos pueden ser compartidos entre pods como sea necesario.
Nota:
Debes tener una instalación propia de Flocker ejecutándose antes de poder usarla.
Un volumen gcePersistentDisk monta un volumen de Google Compute Engine (GCE)
de disco persistente (DP) en tu Pod.
A diferencia de emptyDir, que se borra cuando el Pod es removido, el contenido de un disco persistente es preservado
y el volumen solamente se desmonta. Esto significa que un disco persistente puede ser pre-poblado con datos,
y que esos datos se pueden compartir entre pods.
Nota:
Debes crear un disco persistente usando gcloud, la API de GCE o la UI antes de poder usarlo.
Existen algunas restricciones cuando usas gcePersistentDisk:
Los nodos en los que se ejecutan los pods deben ser máquinas virtuales GCE.
Esas máquinas virtuales deben estar en el mismo proyecto GCE y zona que el disco persistente se encuentra.
Una de las características del disco persistente CGE es acceso concurrente de solo lectura al disco persistente.
Un volumen gcePersistentDisk permite montar simultáneamente un disco de solo lectura a múltiples consumidores.
Esto significa que puedes pre-poblar un DP con tu conjunto de datos y luego servirlo en paralelo desde tantos pods como necesites. Desafortunadamente, los DPs solo se pueden montar por un único consumidor en modo lectura-escritura.
No están permitidos escritores simultáneos.
Usar un disco persistente GCE con un Pod controlado por un ReplicaSet fallará a manos que el DP sea de solo lectura o el número de réplicas sea 0 o 1.
Creando un disco persistente GCE
Antes de poder usar un disco persistente GCE en un Pod, necesitas crearlo.
Ejemplo de configuración de un disco persistente GCE
apiVersion:v1kind:Podmetadata:name:test-pdspec:containers:- image:registry.k8s.io/test-webservername:test-containervolumeMounts:- mountPath:/test-pdname:test-volumevolumes:- name:test-volume# Este PD GCE debe existir con anterioridad.gcePersistentDisk:pdName:my-data-diskfsType:ext4
Discos regionales persistentes
La función de discos regionales persistentes
permite la creación de discos persistentes que están disponibles en dos zonas dentro de la misma región.
Para usar esta función, el volumen debe ser provisto como un PersistentVolumen; referenciar el volumen directamente desde un Pod no está soportado.
Aprovisionamiento manual de un PD PersistentVolume Regional
El aprovisionamiento dinámico es posible usando un StorageClass para el DP GCE.
Antes de crear un PersistentVolume, debes crear el disco persistente:
La función CSIMigration para el DP GCE, cuando se habilita, redirige todas las operaciones
de complemento desde el complemento existente dentro del árbol existente al controlador de Interfaz de Almacenamiento del Contenedor (CSI) de pd.csi.storage.gke.io. Para poder usar esta función, el controlador PD GCE debe ser instalado en el clúster y habilitar las funciones beta
CSIMigration y CSIMigrationGCE.
gitRepo (deprecado)
Advertencia:
El volumen gitRepo está deprecado. Para aprovisionar un contenedor con un repositorio git, monta un EmptyDir en un InitContainer que clona un repositorio usando git, luego monta el EmptyDir en el contenedor del Pod.
Un volumen gitRepo es un ejemplo de un complemento de volumen. Este complemento monta un directorio vacío y clona un repositorio git en este directorio para que tu Pod pueda usarlo.
Un volumen glusterfs permite montar un volumen Glusterfs en tu Pod.
A diferencia de emptyDir, que se borra cuando se remueve un Pod, el contenido de un volumen glusterfs es preservado
y el volumen solamente se desmonta. Esto significa que un volumen glusterfs puede ser pre-poblado con datos,
y que los datos pueden ser compartidos entre pods. GlusterFS puede ser montado por múltiples escritores simultáneamente.
Nota:
Debes tener tu propia instalación de GlusterFS ejecutándose antes de poder usarla.
Un volumen hostPath monta un archivo o un directorio del sistema de archivos del nodo host a tu Pod.
Esto no es algo de muchos Pods necesiten, pero ofrece una trampa de escape poderosa para algunas aplicaciones.
Por ejemplo, algunos usos de un hostPath son:
ejecutar un contenedor que necesita acceso a los directorios internos de Docker, usa un hostPath de /var/lib/docker
ejecutar un cAdvisor en un contenedor; usa un hostPath de /sys
permitir a un Pod especificar si un hostPath dado debería existir ante de correr el Pod, si debe crearse, cómo debe existir
Además de la propiedad requerida path, puedes especificar opcionalmente un tipopara un volumen hostPath.
Los valores soportados para el campo tipo son:
Valor
Comportamiento
Una cadena vacía (por defecto) es para compatibilidad con versiones anteriores, lo que significa que no se harán revisiones antes de montar el volumen hostPath.
DirectoryOrCreate
Si no hay nada en la ruta dada, se creará un directorio vacío como es requerido con los permisos a 0755, teniendo el mismo grupo y propiedad que el Kubelet.
Directory
Un directorio debe existir en la ruta dada
FileOrCreate
Si no hay nada en la ruta dada, se creará un archivo vacío como es requerido con los permisos a 0644, teniendo el mismo grupo y propiedad que el Kubelet.
File
Un archivo debe existir en la ruta dada
Socket
Un socket de UNIX debe existir en la ruta dada
CharDevice
Un dispositivo de caracteres debe existir en la ruta data
BlockDevice
Un dispositivo de bloques dbe existir en la ruta dada
Ten cuidado cuando uses este tipo de volumen, porque:
Los Pods con configuración idéntica (tales como los creados por un PodTemplate) pueden comportarse de forma distinta
en nodos distintos debido a diferentes ficheros en los nodos.
Los ficheros o directorios creados en los hosts subyacentes son modificables solo por root. Debes ejecutar tu proceso como root en un Contenedor privilegiado o modificar los permisos de archivo en el host para escribir a un volumen hostPath
Ejemplo de configuración hostPath
apiVersion:v1kind:Podmetadata:name:test-pdspec:containers:- image:registry.k8s.io/test-webservername:test-containervolumeMounts:- mountPath:/test-pdname:test-volumevolumes:- name:test-volumehostPath:# localización del directorio en el hostpath:/data# este campo es opcionaltype:Directory
Precaución:
El modo FileOrCreate no crea el directorio padre del archivo. Si el directorio padre del archivo montado no existe,
el Pod falla en iniciar. Para asegurar que este modo funciona, puedes intentar montar directorios y ficheros de forma separada,
tal como se muestra en la confugiración FileOrCreate
ejemplo de configuración hostPath FileOrCreate
apiVersion:v1kind:Podmetadata:name:test-webserverspec:containers:- name:test-webserverimage:registry.k8s.io/test-webserver:latestvolumeMounts:- mountPath:/var/local/aaaname:mydir- mountPath:/var/local/aaa/1.txtname:myfilevolumes:- name:mydirhostPath:# Asegúrate que el directorio del archivo es creado.path:/var/local/aaatype:DirectoryOrCreate- name:myfilehostPath:path:/var/local/aaa/1.txttype:FileOrCreate
iscsi
Un volumen iscsi permite que se monte un volumen ISCSI (SCSI sobre IP) existente
en tu Pod. A diferencia de emptydir, que es removido cuando se remueve un Pod,
el contenido de un volumen iscsi es preservado y el volumen solamente se desmonta.
Esto significa que un volumen iscsi puede ser pre-poblado con datos, y que estos datos se pueden compartir entre pods.
Nota:
Debes tener tu propio servidor ISCSI corriendo con el volumen creado antes de poder usarlo.
Una función de SCSI es que puede ser montado como de solo lectura por múltiples consumidores simultáneamente.
Esto significa que puedes pre-poblar un volumen con tu conjunto de datos y servirlo en paralelo para tantos Pods como necesites.
Desafortunadamente, los volúmenes ISCSI solo se pueden montar por un único consumidor en modo lectura-escritura.
Escritores simultáneos no está permitido.
Un volumen local representa un dispositivo de almacenamiento local como un disco, una partición o un directorio.
Los volúmenes locales solo se pueden usar como un PersistenVolume creado estáticamente.
El aprovisionamiento dinámico no está soportado.
Comparados con volúmenes hostPath, los volúmenes local se usan de manera duradera y portátil sin programar pods manualmente
a los nodos. El sistema está consciente de las limitaciones del nodo del volumen al mirar la afinidad del nodo en el PersistenVolumen.
Sin embargo, los volúmenes localestán sujetos a la disponibilidad del nodo subyacente y no son compatibles para todas las aplicaciones.
Si un nodo deja de estar sano, entonces el volumen local se vuelve inaccesible al Pod.
El Pod que utiliza este volumen no se puede ejecutar.
Las aplicaciones que usan volúmenes local deben ser capaces de tolerar esta disponibilidad reducida,
así como la pérdida potencial de datos, dependiendo de las características de durabilidad del disco subyacente.
El siguiente ejemplo muestra un PersistentVolume usando un volumen localy nodeAffinity:
Debes establecer un valor de nodeAffinity del PersistenVolume cuando uses volúmenes local.
El Scheduler de Kubernetes usa nodeaffinity del PersistenVolume para programar estos Pods al nodo correcto.
El volumeMode del PersistentVolume se puede establecer en "Block" (en lugar del valor por defecto, "Filesystem")
para exponer el volumen local como un dispositivo de bloque sin formato.
Cuando usas volúmenes locales, se recomienda crear un StorageClass con volumeBindingMode en WaitForFirstConsumer.
Para más detalles, mira el ejemplo de StorageClass. Retrasar el enlace con el volumen asegura que la decisión del PersistenVolumeClaim sea evaluada con otras limitaciones que el Pod pueda tener,
tales como requisitos de recursos del nodo, selectores de nodo, afinidad del Pod, y anti-afinidad del Pod.
Se puede ejecutar un aprovisionador estático externo para un manejo mejorado del ciclo de vida del volumen local.
Ten en cuenta que este aprovisionador no soporta aprovisionamiento dinámico todavía. Para un ejemplo de un aprovisionador local externo, mira la guía de usuario de aprovisionador de volumen local
Nota:
El PersistentVolume local requiere limpieza y borrado manual por el usuario si no se utiliza el aprovisionador estático externo para manejar el ciclo de vida del volumen.
nfs
Un volumen nfs permite montar un NFS (Sistema de Ficheros de Red) compartido en tu Pod.
A diferencia de emptyDir que se borra cuando el Pod es removido, el contenido de un volumen nfs solamente se desmonta.
Esto significa que un volumen NFS puede ser pre-poblado con datos, y que estos datos puedes ser compartidos entre pods.
NFS puede ser montado por múltiples escritores simultáneamente.
Nota:
Debes tener tu propio servidor NFS en ejecución con el recurso compartido exportado antes de poder usarlo.
Un volumen persistenceVolumeClain se utiliza para montar un PersistentVolume en tu Pod. PersistentVolumeClaims son una forma en que el usuario "reclama" almacenamiento duradero (como un PersistentDisk GCE o un volumen ISCSI) sin conocer los detalles del entorno de la nube en particular.
Un portworxVolume es un almacenamiento de bloque elástico que corre hiperconvergido con Kubernetes.
Almacenamiento de huellas de Portworx en un servidor, niveles basados en capacidades y capacidad agregada en múltiples servidores.
Portworx se ejecuta como invitado en máquinas virtuales o en nodos Linux nativos.
Un portworxVolume puede ser creado dinámicamente a través de Kubernetes o puede ser pre-aprovisionado y referido dentro de un Pod. Aquí un Pod de ejemplo refiriendo a un volumen Portworx pre-aprovisionado:
apiVersion:v1kind:Podmetadata:name:test-portworx-volume-podspec:containers:- image:registry.k8s.io/test-webservername:test-containervolumeMounts:- mountPath:/mntname:pxvolvolumes:- name:pxvol# Este volumen portworx debe sxistir con anterioridad.portworxVolume:volumeID:"pxvol"fsType:"<fs-type>"
Nota:
Asegúrate de tener un PortworxVolume con el nombre pxvol antes de usarlo en el Pod.
Cada volumen proyectado está listado en spec bajo sources. Los parámetros son casi los mismos salvo dos excepciones:
Para los secrets, el campo secretName ha sido cambiado a name para ser consistente con el nombre del configMap.
El defaultMode solo se puede especificar en el nivel proyectado y no para cada fuente de volumen. Sin, como se muestra arriba, puedes establecer explícitamente el mode para cada proyección individual.
Cuando la función TokenRequestProjection está habilitada, puedes inyectar el token para el service account actual en un Pod en la ruta especificada.
Por ejemplo:
El Pod de ejemplo tiene un volumen proyectado que contiene el token del serviceAccount inyectado.
Este token se puede usar por el contenedor de un Pod para acceder a la API del servidor de Kubernetes.
El audience contiene la audiencia dirigida del token. Un recipiente del token debe identificarse a sí mismo con
un identificador especificado en la audiencia del token, de lo contrario debería rechazar el token. Este campo es opcional y por defecto tiene el valor del identificador del servidor API.
EL campo expirationSeconds es la duración esperada de la validez del token del serviceAccount.
Su valor por defecto es 1 hora y debe ser al menos 10 minutos (600 segundos). Un administrador puede limitar
su valor máximo al especificar la opción --service-account-max-token-expiration para el servidor API. El campo path especifica una ruta relativa al punto de montaje del volumen proyectado.
Nota:
Un contenedor que usa una fuente de volumen proyectado como un volumen subPath no recibirá actualizaciones de estas fuentes de volumen.
quobyte
Un volumen quobyte permite montar un volumen Quobyte en tu Pod.
Nota:
Debes tener tu propia configuración Quobyte ejecutándose con los volúmenes creados antes de usarlo.
Quobyte soporta el Container Storage Interface.
CSI es el complemento recomendado para usar Quobyte dentro de Kubernetes. El proyecto Github de Quobyte tiene instrucciones para desplegar usando CSI, junto con ejemplos.
rbd
Un volumen rbd permite montar un volumen Rados Block Device (RBD) en tu Pod.
A diferencia de emptyDir, que se borra cuando el Pod es removido, el contenido de un volumen rbd es preservado y el volumen se desmonta. Esto significa que un volumen RBD puede ser pre-poblado con datos, y que estos datos pueden ser compartidos entre pods.
Nota:
Debes tener una instalación de Ceph ejecutándose antes de usar RBD.
Una función de RBD es que solo se puede montar como de solo lectura por múltiples consumidores simultáneamente.
Esto significa que puedes pre-poblar un volumen con tu conjunto de datos y luego servirlo en paralelo desde tantos pods como necesites. Desafortunadamente, los volúmenes RBD solo se pueden montar por un único consumidor en modo lectura-escritura. No se permiten escritores simultáneos.
ScaleIO es una plataforma de almacenamiento basada en software que usa el hardware existente para crear clústeres de almacenamiento en red de bloques compartidos escalables. El complemento de volumen scaleIO permite a los pods desplegados acceder a volúmenes existentes ScaleIO. Para información acerca de aprovisionamiento dinámico de nuevos persistence volumen claims, mira ScaleIO persistent volumes
Nota:
Debes tener un Cluster ScaleIO ya configurado y ejecutándose con los volúmenes creados antes de poder usarlos.
El siguiente ejemplo es una configuración de un Pod con ScaleIO:
Un volumen seret se utiliza para pasar información sensible, como contraseñas, a los Pods.
Puedes guardar secrets en la API de Kubernetes y montarlos como ficheros para usarlos con los pods sin acoplarlos con Kubernetes directamente. Los volúmenes secret son respaldados por tmpfs (un sistema de ficheros respaldado por la RAM) así que nunca se escriben en un almacenamiento no volátil.
Nota:
Debes crear un secreto en la API de Kubernetes antes de poder usarlo.
Nota:
Un contenedor que usa un Secret como un volumen subPath no recibirá las actualizaciones del Secret.
Un volumen storageos permite montar un volumen existente StorageOS en tu Pod.
StorageOS corre como un contenedor dentro de tu contenedor Kubernetes, haciendo accesible el almacenamiento local o adjunto desde cualquier node dentro del cluster de Kubernetes.
Los datos pueden ser replicados para protegerlos contra fallos del nodo. Este aprovisionamiento y compresión pueden mejorar el uso y reducir costes.
El contenedor StorageOs requiere Linux de 64 bits y no tiene dependencias adicionales.
Una licencia gratuita para desarrolladores está disponible.
Precaución:
Debes correr un contenedor StorageOS en cada nodo que quiera acceder a los volúmenes StorageOS o que contribuyan a la capacidad de almacenamiento al grupo.
Para instrucciones de instalación, consulta la documentación StorageOS
El siguiente ejemplo es una configuración de un Pod con Storage OS:
apiVersion:v1kind:Podmetadata:labels:name:redisrole:mastername:test-storageos-redisspec:containers:- name:masterimage:kubernetes/redis:v1env:- name:MASTERvalue:"true"ports:- containerPort:6379volumeMounts:- mountPath:/redis-master-dataname:redis-datavolumes:- name:redis-datastorageos:# El volumen `redis-vol01` debe existir dentro de StorageOS en el namespace `default`.volumeName:redis-vol01fsType:ext4
Para más información sobre StorageOS, aprovisionamiento dinámico, y PersistentVolumeClaims, mira los
ejemplos de StorageOS examples.
vsphereVolume
Nota:
Debes configurar el proveedor en la nube de vSphere de Kubernetes.
Para configuración de proveedores en la nube, mira la guía de inicio de vSphere .
Un volumen vsphereVolume se usa para montar un volumen VMDK vSphere en tu Pod. El contenido de un volumen es preservado cuando se desmonta. Tiene soporte para almacén de datos VMFS y VSAN.
Nota:
Debes crear un volumen vSphere VMDK usando uno de los siguientes métodos antes de usarlo con un Pod.
Creando un volumen VMDK
Elige uno de los siguientes métodos para crear un VMDK.
vmware-vdiskmanager -c -t 0 -s 40GB -a lsilogic myDisk.vmdk
Ejemplo de configuración vSphere VMDK
apiVersion:v1kind:Podmetadata:name:test-vmdkspec:containers:- image:registry.k8s.io/test-webservername:test-containervolumeMounts:- mountPath:/test-vmdkname:test-volumevolumes:- name:test-volume# Este volumen VMDK ya debe existir.vsphereVolume:volumePath:"[DatastoreName] volumes/myDisk"fsType:ext4
Para mayor información, mira el ejemplo de vSphere volume.
Migración CSI vSphere
FEATURE STATE:Kubernetes v1.19 [beta]
Cuando la función CSIMigration está habilitada, redirige todas las operaciones de complemento desde el complemento existente en el árbol al controlador CSIcsi.vsphere.vmware.com. Para
usar esta función, el controlador vSphere CSI debe estar instalado en el clúster y las feature gatesCSIMigration y CSIMigrationvSphere deben estar habilitadas.
Esto también requiere que la versión de vSphere vCenter/ESXi sea la 7.0u1 y la versión mínima de HW version sea VM versión 15.
Nota:
Los siguientes parámetros de Storageclass desde el complemento incorporado vsphereVolume no están soportados por el controlador vSphere CSI:
diskformat
hostfailurestotolerate
forceprovisioning
cachereservation
diskstripes
objectspacereservation
iopslimit
Los volúmenes existentes creados usando estos parámetros serán migrados al controlador vSphere CSI, pero los volúmenes nuevos creados por el controlador vSphere CSI no respetarán estos parámetros
migración completa de vSphere CSI
FEATURE STATE:Kubernetes v1.19 [beta]
Para apagar el complemento vsphereVolume y no cargarlo por el administrador del controlador y el kubelet, necesitas establecer eta función a true. Debes instalar un controlador de tipo csi.vsphere.vmware.com en todos los nodos worker.
Uso de subPath
Algunas veces es útil compartir un volumen para múltiples usos en un único Pod.
La propiedad volumeMounts[*].subPath especifica una sub-ruta dentro del volumen referenciado en lugar de su raíz.
El siguiente ejemplo muestra cómo configurar un Pod con la pila LAMP (Linux Apache MySQL PHP) usando un único volumen compartido. Esta configuración de ejemplo usando subPath no se recomienda para su uso en producción.
El código de la aplicación PHP y los recursos apuntan al directorio html del volumen y la base de datos MySQL se almacena en el directorio mysql. Por ejemplo:
The PHP application's code and assets map to the volume's html folder and
the MySQL database is stored in the volume's mysql folder. For example:
