Lease

Les systèmes distribués ont souvent besoin de Lease, qui fournissent un mécanisme pour verrouiller les ressources partagées et coordonner l'activité entre les membres d'un ensemble. Dans Kubernetes, le concept de bail est représenté par les objets Lease dans le groupe d'API coordination.k8s.io Groupe d'API, qui sont utilisés pour des fonctionnalités critiques du système telles que les battements de cœur des nœuds et l'élection du leader au niveau des composants.

Battements de cœur des nœuds

Kubernetes utilise l'API Lease pour communiquer les battements de cœur des nœuds kubelet au serveur API Kubernetes. Pour chaque Node, il existe un objet Lease avec un nom correspondant dans le namespace kube-node-lease. Sous le capot, chaque battement de cœur kubelet est une demande de mise à jour de cet objet Lease, mettant à jour le champ spec.renewTime pour le bail. Le plan de contrôle Kubernetes utilise le horodatage de ce champ pour déterminer la disponibilité de ce Node.

Consultez Objets de bail de nœud pour plus de détails.

Élection du leader

Kubernetes utilise également des Lease pour s'assurer qu'une seule instance d'un composant est en cours d'exécution à tout moment. Cela est utilisé par les composants du plan de contrôle tels que kube-controller-manager et kube-scheduler dans les configurations HA, où une seule instance du composant doit être en cours d'exécution activement tandis que les autres instances sont en attente.

Lisez élection coordonnée du leader pour en savoir plus sur la façon dont Kubernetes s'appuie sur l'API Lease pour sélectionner quelle instance de composant agit en tant que leader.

Identité du serveur API

À partir de Kubernetes v1.26, chaque kube-apiserver utilise l'API Lease pour publier son identité au reste du système. Bien que cela ne soit pas particulièrement utile en soi, cela fournit un mécanisme pour les clients afin de découvrir combien d'instances de kube-apiserver opèrent sur le plan de contrôle Kubernetes. L'existence des Lease kube-apiserver permet des fonctionnalités futures qui peuvent nécessiter une coordination entre chaque kube-apiserver.

Vous pouvez inspecter les Lease détenus par chaque kube-apiserver en vérifiant les objets de bail dans le namespace kube-system avec le nom kube-apiserver-<sha256-hash>. Alternativement, vous pouvez utiliser le sélecteur d'étiquettes apiserver.kubernetes.io/identity=kube-apiserver:

kubectl -n kube-system get lease -l apiserver.kubernetes.io/identity=kube-apiserver

NOM                                         HOLDER                                                                           ÂGE
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

Le hachage SHA256 utilisé dans le nom du bail est basé sur le nom d'hôte du système d'exploitation tel que vu par ce serveur API. Chaque kube-apiserver devrait être configuré pour utiliser un nom d'hôte qui est unique dans le cluster. Les nouvelles instances de kube-apiserver qui utilisent le même nom d'hôte prendront le contrôle des Lease existants en utilisant une nouvelle identité de détenteur, au lieu d'instancier de nouveaux objets de bail. Vous pouvez vérifier le nom d'hôte utilisé par kube-apisever en vérifiant la valeur de l'étiquette 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"

Les Lease expirés des kube-apiservers qui n'existent plus sont collectés par les nouveaux kube-apiservers après 1 heure.

Vous pouvez désactiver les Lease d'identité du serveur API en désactivant la fonctionnalité APIServerIdentity feature gate.

Charges de travail

Votre propre charge de travail peut définir son propre usage des Lease. Par exemple, vous pouvez exécuter un contrôleur personnalisé où un membre principal ou leader effectue des opérations que ses pairs ne font pas. Vous définissez un bail afin que les réplicas du contrôleur puissent sélectionner ou élire un leader, en utilisant l'API Kubernetes pour la coordination. Si vous utilisez un bail, il est bon de pratiquer de définir un nom pour le bail qui est clairement lié au produit ou au composant. Par exemple, si vous avez un composant nommé Example Foo, utilisez un bail nommé example-foo.

Si un opérateur de cluster ou un autre utilisateur final peut déployer plusieurs instances d'un composant, sélectionnez un préfixe de nom et choisissez un mécanisme (comme le hachage du nom du déploiement) pour éviter les collisions de noms pour les Lease.

Vous pouvez utiliser une autre approche tant qu'elle atteint le même résultat : les différents produits logiciels ne entrent pas en conflit les uns avec les autres.