Information in this document may be out of date
This document has an older update date than the original, so the information it contains may be out of date. If you're able to read English, see the English version for the most up-to-date information: Leases
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».
Ve Objetos Lease de nodos para más detalles.
Elección del líder
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
Kubernetes v1.26 [beta]
(enabled by default: true)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
apiVersion: coordination.k8s.io/v1
kind: Lease
metadata:
creationTimestamp: "2023-07-02T13:16:48Z"
labels:
apiserver.kubernetes.io/identity: kube-apiserver
kubernetes.io/hostname: master-1
name: apiserver-07a5ea9b9b072c4a5f3d1c3702
namespace: kube-system
resourceVersion: "334899"
uid: 90870ab5-1ba9-4523-b215-e4d4e662acb1
spec:
holderIdentity: apiserver-07a5ea9b9b072c4a5f3d1c3702_0c8914f7-0f35-440e-8676-7844977d3a05
leaseDurationSeconds: 3600
renewTime: "2023-07-04T21:58:48.065888Z"
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í.