105 lines
5.1 KiB
Markdown
105 lines
5.1 KiB
Markdown
---
|
|
title: Leases
|
|
content_type: concept
|
|
weight: 30
|
|
---
|
|
|
|
<!-- overview -->
|
|
|
|
Distributed systems often have a need for _leases_, which provide a mechanism to lock shared resources
|
|
and coordinate activity between members of a set.
|
|
In Kubernetes, the lease concept is represented by [Lease](/docs/reference/kubernetes-api/cluster-resources/lease-v1/)
|
|
objects in the `coordination.k8s.io` {{< glossary_tooltip text="API Group" term_id="api-group" >}},
|
|
which are used for system-critical capabilities such as node heartbeats and component-level leader election.
|
|
|
|
<!-- body -->
|
|
|
|
## Node heartbeats {#node-heart-beats}
|
|
|
|
Kubernetes uses the Lease API to communicate kubelet node heartbeats to the Kubernetes API server.
|
|
For every `Node` , there is a `Lease` object with a matching name in the `kube-node-lease`
|
|
namespace. Under the hood, every kubelet heartbeat is an **update** request to this `Lease` object, updating
|
|
the `spec.renewTime` field for the Lease. The Kubernetes control plane uses the time stamp of this field
|
|
to determine the availability of this `Node`.
|
|
|
|
See [Node Lease objects](/docs/concepts/architecture/nodes/#heartbeats) for more details.
|
|
|
|
## Leader election
|
|
|
|
Kubernetes also uses Leases to ensure only one instance of a component is running at any given time.
|
|
This is used by control plane components like `kube-controller-manager` and `kube-scheduler` in
|
|
HA configurations, where only one instance of the component should be actively running while the other
|
|
instances are on stand-by.
|
|
|
|
## API server identity
|
|
|
|
{{< feature-state feature_gate_name="APIServerIdentity" >}}
|
|
|
|
Starting in Kubernetes v1.26, each `kube-apiserver` uses the Lease API to publish its identity to the
|
|
rest of the system. While not particularly useful on its own, this provides a mechanism for clients to
|
|
discover how many instances of `kube-apiserver` are operating the Kubernetes control plane.
|
|
Existence of kube-apiserver leases enables future capabilities that may require coordination between
|
|
each kube-apiserver.
|
|
|
|
You can inspect Leases owned by each kube-apiserver by checking for lease objects in the `kube-system` namespace
|
|
with the name `kube-apiserver-<sha256-hash>`. Alternatively you can use the label selector `apiserver.kubernetes.io/identity=kube-apiserver`:
|
|
|
|
```shell
|
|
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
|
|
|
|
```
|
|
|
|
The SHA256 hash used in the lease name is based on the OS hostname as seen by that API server. Each kube-apiserver should be
|
|
configured to use a hostname that is unique within the cluster. New instances of kube-apiserver that use the same hostname
|
|
will take over existing Leases using a new holder identity, as opposed to instantiating new Lease objects. You can check the
|
|
hostname used by kube-apisever by checking the value of the `kubernetes.io/hostname` label:
|
|
|
|
```shell
|
|
kubectl -n kube-system get lease apiserver-07a5ea9b9b072c4a5f3d1c3702 -o yaml
|
|
```
|
|
```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"
|
|
```
|
|
|
|
Expired leases from kube-apiservers that no longer exist are garbage collected by new kube-apiservers after 1 hour.
|
|
|
|
You can disable API server identity leases by disabling the `APIServerIdentity`
|
|
[feature gate](/docs/reference/command-line-tools-reference/feature-gates/).
|
|
|
|
## Workloads {#custom-workload}
|
|
|
|
Your own workload can define its own use of Leases. For example, you might run a custom
|
|
{{< glossary_tooltip term_id="controller" text="controller" >}} where a primary or leader member
|
|
performs operations that its peers do not. You define a Lease so that the controller replicas can select
|
|
or elect a leader, using the Kubernetes API for coordination.
|
|
If you do use a Lease, it's a good practice to define a name for the Lease that is obviously linked to
|
|
the product or component. For example, if you have a component named Example Foo, use a Lease named
|
|
`example-foo`.
|
|
|
|
If a cluster operator or another end user could deploy multiple instances of a component, select a name
|
|
prefix and pick a mechanism (such as hash of the name of the Deployment) to avoid name collisions
|
|
for the Leases.
|
|
|
|
You can use another approach so long as it achieves the same outcome: different software products do
|
|
not conflict with one another.
|