Kubernetes控制平面组件：Controller Manager详解

云原生学习路线导航页（持续更新中）

• kubernetes学习系列快捷链接
  • Kubernetes架构原则和对象设计（一）
  • Kubernetes架构原则和对象设计（二）
  • Kubernetes架构原则和对象设计（三）
  • Kubernetes控制平面组件：etcd（一）
  • Kubernetes控制平面组件：etcd（二）
  • Kubernetes控制平面组件：API Server详解（一）
  • Kubernetes控制平面组件：API Server详解（二）
  • Kubernetes控制平面组件：调度器Scheduler（一）
  • Kubernetes控制平面组件：调度器Scheduler（二）
  • Kubernetes控制平面组件：Controller Manager 之 内置Controller详解
  • Kubernetes控制平面组件：Controller Manager 之 NamespaceController 全方位讲解

本文对 kubernetes 的控制面组件ControllerManager进行了详细讲解，包括：ControllerManager的基本功能、架构定位、编写控制器的流程、Lister-watch机制原理、informer机制原理、kube-controller-manager配置参数、CloudControllerManager架构设计、Controller高可用设计（Leader Election）等，并且给出一些生产建议

• 希望大家多多 点赞 关注 评论 收藏，作者会更有动力继续编写技术文章

1.ControllerManager是什么

在 Kubernetes架构原则和对象设计（一） 中我们曾详细介绍过kubernetes控制器工作的基本流程，忘记的可以回顾一下

• Controller Manager 以 单进程多控制器 形式运行，内部包含诸多Controller控制器
• 每个Controller逻辑是大同小异的，都是一个生产者消费者模型
  • Controller里的watcher就是一个生产者：使用watch机制监控APIServer中某些资源的变化，观察到的变化事件都会放入一个队列中
  • Controller里的处理逻辑作为消费者：不断从队列中取出数据去做调谐。如果调谐失败，需要有将事件重新放回队列，等待一段时间后重试，以此达到 最终一致性。
• 最终一致性：不能保证一次就能达到spec期望状态，但是会有重试机制，保证经过多轮处理后，最终能够达到spec期望状态。
• ControllerManager其实是一个控制器合集，内置资源的Controller都在这里，比如：
  • Deployment Controller
  • ReplicaSet Controller
  • Service Controller
  • …

2.编写一个控制器的过程

2.1.编写控制器基本流程

• 先编写 types.go，定义你的 对象结构，包括 spec、status 的定义
• 然后在 type.go 中，编写一些 code generation 代码生成的tag
• 代码生成器会根据tag生成对应的代码框架，其中就包括：Informer框架、Lister框架的代码
  • Lister框架 负责从apiserver list 符合条件的全量对象
  • Informer框架 负责与apiserver建立watch长连接，监听对象变化

2.2.如何定义一个对象

• 对象一般都是在types.go文件中
  

2.3.使用代码生成的Tags

2.3.1.code-generator项目

• code-generator项目：https://github.com/kubernetes/code-generator

• code-generator项目下包含很多代码生成的工具，包括生成 深拷贝代码、client代码、informer代码、lister代码、conversion代码等
  

• 代码生成器，是通过文件中的 特定tag 生效的，比如下面有一些常用的tag
  

  标签	解释
  // +k8s:deepcopy-gen=package	全局标签，为包内所有类型生成深拷贝方法。
  // +k8s:deepcopy-gen:interfaces=k8s.io/apimachinery/pkg/runtime.Object	生成实现 runtime.Object 接口的深拷贝方法，用于序列化与版本转换。
  // +genclient	生成客户端代码（CRUD 方法、Lister、Informer）。
  // +genclient:nonNamespaced	标记资源为集群作用域（Cluster-scoped），生成不带命名空间参数的方法。
  // +genclient:noVerbs	不生成默认客户端方法（需配合其他标签指定特定动词）。
  // +genclient:onlyVerbs=create,delete	仅生成指定的客户端方法（如仅 Create 和 Delete）。
  // +genclient:skipVerbs=get,list,watch	跳过生成指定的客户端方法（如 Get、List、Watch）。
  // +genclient:method=Create,verb=create,result=...	自定义客户端方法名称、HTTP 动词及返回类型（如返回 metav1.Status）。

• 说明：

  • 全局标签作用于整个包，局部标签作用于单个资源。
  • 标签需严格遵循格式（如空格不可省略），否则会被代码生成器忽略。

2.3.2.代码生成使用示例

• 通过编写脚本文件，指定code-generator项目下各种工具的路径，然后使用命令生成具体的代码。如下图：
• --input-dirs：源代码目录
• -O：生成的文件名称
• --bounding-dirs：输出目录
• --go-header-file：加什么样的header描述
  

3.Controller Lister-Informer 机制

3.1.Controller 基本处理流程

• Controller的 list-Informer 机制一般都包含两部分
  • Lister：负责从APIServer List全量数据
  • Informer：负责从APIServer Watch数据的变化
• Controller 处理的基本流程
  • 首先Lister会从 APIServer List 全量数据。
  • 之后Informer 会持续Watch资源的变更事件，并将不同的事件使用对应的 EventHandler（可以自行注册） 处理后，将资源key（namespace+name）加入队列
  • 启动一个或多个协程goroutine，作为消费者，从队列中取出资源key并处理
• 注意点：
  • 自己编写controller的时候，一般都会在list里使用 label selector，只获取自己关心的 对象
  • 但是这里的label selector筛选动作是在apiserver做的，所以对apiserver来说每次list都要检索所有对象，然后再过滤，这个过程消耗很大，控制器内部要尽量避免与apiserver的list操作，尽量使用watch监听代替全量拉取

3.2.Informer的内部机制

• Informer的组件及其职责
  • Reflector：反射器，负责将APIServer发过来的对象数据（一般是json或protobuf），反序列化成一个go struct
  • Delta FIFO Queue：循环FIFO队列，负责存储 待处理对象，Delta FIFO Queue是一个循环队列，满的时候会覆盖旧数据
  • Informer：通知器，负责从Delta FIFO Queue中不断弹出对象，做两件事：
    • 通过Indexer索引器，以key-value形式存入Thread Safe Store本地存储。
      • key：namespaceName
      • value：对象本身
    • 通过Handler，调用当前Event类型 对应的那一个Handler，处理后将对象的key添加到WorkQueue
  • Indexer：本地缓存索引器，负责处理和本地缓存相关的查询、写入操作
  • Thread Safe Store：线程安全的本地存储，负责在Informer内部维护一份对象缓存，这样控制器的查询操作，就不用到APIServer查询，直接在本地查询即可
    • 提高了查询效率，而且缓解了 APIServer 的压力
  • Handler：事件处理器，负责处理资源的不同Event，每种Event都应该有一个对应的Handler，所以应该有很多类型的Resource Handler。比如 Create Handler、Update Handler、Delete Handler…。
    • 本质上就是一些回调函数，当发生具体事件时回调对应的函数
  • WorkQueue：工作队列，负责存储所有待处理对象的key（namespaceName）
  • Process NextWorkItem：负责不断从WorkQueue取出key，交给某个Worker处理
  • Worker：资源处理工作器，负责真正的对象调谐工作。一般会启动多个Worker，每个Worker都是一个goroutine，并行处理WorkQueue中的事件
• Informer是一个概念，SharedInformer是一个具体实现
• Controller的整个处理流程如下（以Deployment Controller为例）：
  • Controller 启动时，会通过Lister 先List一下所有Deployment资源，存入Thread Safe Store本地缓存
  • 然后 SharedInformer 通过长连接建立 Deployment资源的 watch 连接
  • 当发生Deployment资源变化时，APIServer会把事件及对应的Deployment资源对象，发送给Deployment控制器的SharedInformer
  • 首先会使用 Reflector将其反序列化为go struct，然后存入Delta FIFO Queue
  • Informer 组件会 从Delta FIFO Queue中取出对象，通过IndexerThread Safe Store本地缓存，并通过Handler将对象的key放入WorkQueue
  • Process NextWorkItem会从WorkQueue中取出key，找到一个worker对这个deployment资源进行处理

3.3.控制器之间协同工作原理

以创建一个Deployment资源为例

• 用户使用kubectl或http请求方式，发起一个创建Deployment资源的请求
• 请求到达APIServer，会经过 认证、鉴权、资源变形、schema校验、其他校验 等一系列处理后，APIServer 将deployment数据写入自己的watch缓存 和 etcd
  • Kubernetes 内部的 DeploymentController 早就已经和APIServer建立了Watch长连接
  • 当APIServer将数据写入缓存之后，就会把Deployment资源的变化，通知所有关心Deployment资源的watcher，其中就包括DeploymentController
• DeploymentController 根据自己的处理逻辑，编排出对应的 ReplicaSet 资源，向APIServer发送了创建ReplicaSet请求
• 请求到达APIServer，会经过 认证、鉴权、资源变形、schema校验、其他校验 等一系列处理后，APIServer 将ReplicaSet数据写入自己的watch缓存 和 etcd
  • Kubernetes 内部的 ReplicaSetController 早就已经和APIServer建立了Watch长连接
  • 当APIServer将数据写入缓存之后，就会把ReplicaSet资源的变化，通知所有关心ReplicaSet资源的watcher，其中就包括ReplicaSetController
• ReplicaSetController 根据自己的处理逻辑，编排出对应的 Pod 资源，向APIServer发送了创建Pod请求
• 请求到达APIServer，会经过 认证、鉴权、资源变形、schema校验、其他校验 等一系列处理后，APIServer 将Pod数据写入自己的watch缓存 和 etcd
  • Kubernetes 内部的 Scheduler调度器 和 每个Worker Node上的Kubelet 都早就已经和APIServer建立了Watch长连接
  • 当APIServer将数据写入缓存之后，就会把Pod资源的变化，通知所有关心Pod资源的watcher，其中就包括 Scheduler调度器.
  • 同时，Scheduler调度器还 watch 了所有的node对象
• Scheduler调度器 发现该pod属于新创建，还没有调度，就会经过计算选择一个node，将 node名称 写到 pod的 spec.nodeName 中，即绑定pod与node，并向 APIServer 发起 pod update 请求。
• APIServer一样会更新 watch缓存+etcd，并通知所有关心Pod资源的watcher，其中就包括 Worker Node 上的 kubelet
• 某一个node上的kubelet 发现pod的 spec.nodeName 和自己的名称一致，就知道这个pod被调度到自己身上
  • 这个node上的kubelet，就会以此调用 CRI、CNI、CSI，启动容器，挂载网络和数据卷

4.Controller详解

4.1.ControllerManager配置参数

4.1.1.ControllerManager支持哪些Controller

• ControllerManager是一个Controller集合，那么它究竟包含哪些controller呢？
• –controllers 参数中列出来了

# 找到controller-manager pod
[root@VM-226-235-tencentos ~]# kubectl get pods -n kube-system | grep kube-controller
kube-controller-manager-vm-226-235-tencentos   1/1     Running   3          375d# 查看支持的所有controllers
[root@VM-226-235-tencentos ~]# kubectl exec -it kube-controller-manager-vm-226-235-tencentos -n kube-system -- kube-controller-manager -h | grep controllers
--controllers strings                      A list of controllers to enable. '*' enables all on-by-default controllers, 'foo' enables the controller named 'foo', '-foo' disables the controller named 'foo'.All controllers: attachdetach, bootstrapsigner, cloud-node-lifecycle, clusterrole-aggregation, cronjob, csrapproving, csrcleaner, csrsigning, daemonset, deployment, disruption, endpoint, endpointslice, endpointslicemirroring, ephemeral-volume, garbagecollector, horizontalpodautoscaling, job, namespace, nodeipam, nodelifecycle, persistentvolume-binder, persistentvolume-expander, podgc, pv-protection, pvc-protection, replicaset, replicationcontroller, resourcequota, root-ca-cert-publisher, route, service, serviceaccount, serviceaccount-token, statefulset, tokencleaner, ttl, ttl-after-finished

4.1.2.ControllerManager支持的功能开关

# 查看支持的所有功能开关，会展示哪个默认开 哪个默认关
[root@VM-226-235-tencentos ~]# kubectl exec -it kube-controller-manager-vm-226-235-tencentos -n kube-system -- kube-controller-manager -h | grep feature-gates -A 100--feature-gates mapStringBool              A set of key=value pairs that describe feature gates for alpha/experimental features. Options are:APIListChunking=true|false (BETA - default=true)APIPriorityAndFairness=true|false (ALPHA - default=false)APIResponseCompression=true|false (BETA - default=true)AllAlpha=true|false (ALPHA - default=false)AllBeta=true|false (BETA - default=false)AllowInsecureBackendProxy=true|false (BETA - default=true)AnyVolumeDataSource=true|false (ALPHA - default=false)AppArmor=true|false (BETA - default=true)BalanceAttachedNodeVolumes=true|false (ALPHA - default=false)BoundServiceAccountTokenVolume=true|false (ALPHA - default=false)CPUManager=true|false (BETA - default=true)CRIContainerLogRotation=true|false (BETA - default=true)CSIInlineVolume=true|false (BETA - default=true)CSIMigration=true|false (BETA - default=true)CSIMigrationAWS=true|false (BETA - default=false)CSIMigrationAWSComplete=true|false (ALPHA - default=false)CSIMigrationAzureDisk=true|false (BETA - default=false)CSIMigrationAzureDiskComplete=true|false (ALPHA - default=false)CSIMigrationAzureFile=true|false (ALPHA - default=false)CSIMigrationAzureFileComplete=true|false (ALPHA - default=false)CSIMigrationGCE=true|false (BETA - default=false)CSIMigrationGCEComplete=true|false (ALPHA - default=false)CSIMigrationOpenStack=true|false (BETA - default=false)CSIMigrationOpenStackComplete=true|false (ALPHA - default=false)CSIMigrationvSphere=true|false (BETA - default=false)CSIMigrationvSphereComplete=true|false (BETA - default=false)CSIStorageCapacity=true|false (ALPHA - default=false)CSIVolumeFSGroupPolicy=true|false (ALPHA - default=false)ConfigurableFSGroupPolicy=true|false (ALPHA - default=false)CustomCPUCFSQuotaPeriod=true|false (ALPHA - default=false)DefaultPodTopologySpread=true|false (ALPHA - default=false)DevicePlugins=true|false (BETA - default=true)DisableAcceleratorUsageMetrics=true|false (ALPHA - default=false)DynamicKubeletConfig=true|false (BETA - default=true)EndpointSlice=true|false (BETA - default=true)EndpointSliceProxying=true|false (BETA - default=true)EphemeralContainers=true|false (ALPHA - default=false)ExpandCSIVolumes=true|false (BETA - default=true)ExpandInUsePersistentVolumes=true|false (BETA - default=true)ExpandPersistentVolumes=true|false (BETA - default=true)ExperimentalHostUserNamespaceDefaulting=true|false (BETA - default=false)GenericEphemeralVolume=true|false (ALPHA - default=false)HPAScaleToZero=true|false (ALPHA - default=false)HugePageStorageMediumSize=true|false (BETA - default=true)HyperVContainer=true|false (ALPHA - default=false)IPv6DualStack=true|false (ALPHA - default=false)ImmutableEphemeralVolumes=true|false (BETA - default=true)KubeletPodResources=true|false (BETA - default=true)LegacyNodeRoleBehavior=true|false (BETA - default=true)LocalStorageCapacityIsolation=true|false (BETA - default=true)LocalStorageCapacityIsolationFSQuotaMonitoring=true|false (ALPHA - default=false)NodeDisruptionExclusion=true|false (BETA - default=true)NonPreemptingPriority=true|false (BETA - default=true)PodDisruptionBudget=true|false (BETA - default=true)PodOverhead=true|false (BETA - default=true)ProcMountType=true|false (ALPHA - default=false)QOSReserved=true|false (ALPHA - default=false)RemainingItemCount=true|false (BETA - default=true)RemoveSelfLink=true|false (ALPHA - default=false)RotateKubeletServerCertificate=true|false (BETA - default=true)RunAsGroup=true|false (BETA - default=true)RuntimeClass=true|false (BETA - default=true)SCTPSupport=true|false (BETA - default=true)SelectorIndex=true|false (BETA - default=true)ServerSideApply=true|false (BETA - default=true)ServiceAccountIssuerDiscovery=true|false (ALPHA - default=false)ServiceAppProtocol=true|false (BETA - default=true)ServiceNodeExclusion=true|false (BETA - default=true)ServiceTopology=true|false (ALPHA - default=false)SetHostnameAsFQDN=true|false (ALPHA - default=false)StartupProbe=true|false (BETA - default=true)StorageVersionHash=true|false (BETA - default=true)SupportNodePidsLimit=true|false (BETA - default=true)SupportPodPidsLimit=true|false (BETA - default=true)Sysctls=true|false (BETA - default=true)TTLAfterFinished=true|false (ALPHA - default=false)TokenRequest=true|false (BETA - default=true)TokenRequestProjection=true|false (BETA - default=true)TopologyManager=true|false (BETA - default=true)ValidateProxyRedirects=true|false (BETA - default=true)VolumeSnapshotDataSource=true|false (BETA - default=true)WarningHeaders=true|false (BETA - default=true)WinDSR=true|false (ALPHA - default=false)WinOverlay=true|false (ALPHA - default=false)WindowsEndpointSliceProxying=true|false (ALPHA - default=false)

4.1.3.ControllerManager不同Controller的配置项

• ControllerManager 把不同 Controller 的配置都分好了，执行 kube-controller-manager -h可以看到

......
Deployment controller flags:--concurrent-deployment-syncs int32                                                                             The number of deployment objects that are allowed to sync concurrently. Larger number = more responsivedeployments, but more CPU (and network) load (default 5)--deployment-controller-sync-period duration                                                                    Period for syncing the deployments. (default 30s)Statefulset controller flags:--concurrent-statefulset-syncs int32                                                                            The number of statefulset objects that are allowed to sync concurrently. Larger number = more responsivestatefulsets, but more CPU (and network) load (default 5)Deprecated flags:Endpoint controller flags:--concurrent-endpoint-syncs int32                                                                               The number of endpoint syncing operations that will be done concurrently. Larger number = faster endpointupdating, but more CPU (and network) load (default 5)--endpoint-updates-batch-period duration                                                                        The length of endpoint updates batching period. Processing of pod changes will be delayed by thisduration to join them with potential upcoming updates and reduce the overall number of endpoints updates.Larger number = higher endpoint programming latency, but lower number of endpoints revision generatedEndpointslice controller flags:--concurrent-service-endpoint-syncs int32                                                                       The number of service endpoint syncing operations that will be done concurrently. Larger number = fasterendpoint slice updating, but more CPU (and network) load. Defaults to 5. (default 5)--endpointslice-updates-batch-period duration                                                                   The length of endpoint slice updates batching period. Processing of pod changes will be delayed by thisduration to join them with potential upcoming updates and reduce the overall number of endpoints updates.Larger number = higher endpoint programming latency, but lower number of endpoints revision generated--max-endpoints-per-slice int32                                                                                 The maximum number of endpoints that will be added to an EndpointSlice. More endpoints per slice willresult in less endpoint slices, but larger resources. Defaults to 100. (default 100)Endpointslicemirroring controller flags:--mirroring-concurrent-service-endpoint-syncs int32                                                             The number of service endpoint syncing operations that will be done concurrently by theEndpointSliceMirroring controller. Larger number = faster endpoint slice updating, but more CPU (andnetwork) load. Defaults to 5. (default 5)--mirroring-endpointslice-updates-batch-period duration                                                         The length of EndpointSlice updates batching period for EndpointSliceMirroring controller. Processing ofEndpointSlice changes will be delayed by this duration to join them with potential upcoming updates andreduce the overall number of EndpointSlice updates. Larger number = higher endpoint programming latency,but lower number of endpoints revision generated--mirroring-max-endpoints-per-subset int32                                                                      The maximum number of endpoints that will be added to an EndpointSlice by the EndpointSliceMirroringcontroller. More endpoints per slice will result in less endpoint slices, but larger resources. Defaultsto 100. (default 1000)Garbagecollector controller flags:--concurrent-gc-syncs int32                                                                                     The number of garbage collector workers that are allowed to sync concurrently. (default 20)--enable-garbage-collector                                                                                      Enables the generic garbage collector. MUST be synced with the corresponding flag of the kube-apiserver.(default true)
......

4.2.常见Controller

4.2.1.通用Controller

4.2.2.Cloud Controller Manager（CCM）

• kubernetes运行在不同的云上，需要和底层云厂商的云平台进行整合。比如底层是Openstack等，这些底层云平台一般提供了一些可用的API，如节点配置API（nova show可以查看节点信息）、LVS配置负载均衡等。此时就希望有一种开箱即用的方法，让kubernetes到不同环境直接和硬件整合起来。

4.2.2.1.早期云厂商集成架构

• 早期与不同云平台的集成，依赖kube-cloud-manager、kube-apiserver、kubelet等与之交互完成

4.2.2.2.引入CCM的新架构

• 后来社区希望把 将云供应商特定代码 和 Kubernetes 核心代码 分离开来，使得 云供应商代码可以 与kubernetes核心管控组件一起运行，也能够以 Kubernetes 插件的形式启动，引入了Cloud Controller Manager。
• 如上图，基于CCM的架构中，将所有与云供应商交互的部分集中到一个组件 cloud-controller-manager 中，便于扩展与维护
• 集成方式：
  • 假设当前有一个 基于openstack的云平台，可以通过指定 Cloud Controller Manager 的 Cloud Provider==openstack，并提供 openstack 的一系列配置，就可以将kubernetes 与 该云平台集成起来。kubernetes 通过 CCM 提供的cloud API，调用底层云平台的一些能力，实现对硬件及环境的管理。
  • 使用举例：比如有一个基于openstack的云平台 使用nova管理节点，kubernetes就可以通过cloud api调用openstack 的 nova查询到节点信息，然后写入自己的etcd中维护。当node被删除时，kubernetes通过cloud api发现node被删除时，也要在自己这边做node移除动作

4.2.2.3.CCM 的组件

参考：云控制器管理器的基础概念

• CCM 将 Kubernetes 控制器管理器（KCM）的一部分功能剥离，并作为独立的进程运行。具体地说，它将 KCM 中依赖云服务的控制器剥离，KCM 中存在以下依赖云服务的控制器：
  • 节点控制器
  • 卷控制器
  • 路由控制器
  • 服务控制器
• 在 kubernetes 1.8 版本中， 已经将 KCM 中 下面3个控制器移入CCM：
  • 节点控制器：API 包含节点的 Get、List、Create、Update、Patch、Watch
  • 路由控制器：API 包含路由 Get
  • 服务控制器：API 包含service的 List、Get、Watch、Patch、Update
• 卷控制器因为涉及比较复杂，没有挪入

4.3.常见Controller详解

• 详见：Kubernetes控制平面组件：Controller Manager 之 内置Controller详解
  • 本文是kubernetes的控制面组件ControllerManager系列文章，本篇详细讲解了kubernetes 内置常用的Controller，包括：Job、HPA、ReplicaSet、StatefulSet、Namespace、NodeIpam/NodeLifecycle Controller、DaemonSet、Endpoint、EndpointSlice、Garbege Controller、CronJob、ControllerRevision、Lease

5.Scheduler 与 Controller 高可用性：Leader Election机制

5.1.Leader Election 机制特点

• Scheduler/Controller 都是 基于Leader Election机制 来保证高可用的。不过 这里的 leader-election 机制和 etcd 等组件的选主有所不同
  • Controller leader-election 不需要数据同步，也没有主从的概念，这里的 选主 只是选出一个controller成为 工作模式，其他controller作为 故障备选副本，在leader controller发生异常时顶上去处理请求。
  • 因此不管controller有几个副本，都只会有一个在工作的，这是为了防止同一个key被多个controller同时处理发生问题
  • kubernetes 代码中提供了leader-election机制，开发crd控制器时可以直接使用

5.2.Leader Election 机制原理

• 基本原理：
  • 多个Controller pod，或多个Scheduler pod，需要保证只有一个在运行，就需要使用锁。
  • 哪个pod抢到锁，谁就是当前的 Leader，负责处理请求。
  • 其他没抢到锁的无法处理请求，但也不能放弃，需要定期检查，一旦leader有问题释放了锁，自己抢到了就变成了leader，就可以处理请求了
• 这是一种 多个进程抢占资源的模式，这个资源可以是对象，kubernetes提供了一些公共对象，可以作为 Scheduler/Controller 多个pod的锁。比如使用 endpoint/configmap/lease 等对象作为锁

5.2.1.早期使用 endpoint/configmap 作为公共对象

• 早期是使用endpoint/configmap作为公共对象。

  • 如上图的ep，subsets是空的，不过在annotation中使用 control-plane.alpha.kubernetes.io/leader 记录leader信息
  • 哪个controller pod先获取到这个对象，就把自己的信息写进去，就代码抢到了锁成为了leader

• 记录 leader 信息时，control-plane.alpha.kubernetes.io/leader 的值包含哪些信息？

  字段名称	字段作用	示例值或说明
  holderIdentity	当前持有领导权的节点/组件标识符	"minikube"（当前 Leader 名称）
  leaseDurationSeconds	Leader 租约有效期（秒），超时未续期将触发重新选举	15（需大于组件续期间隔）
  acquireTime	当前 Leader 首次获取领导权的时间（RFC 3339 格式）	"2018-04-05T17:31:29Z"
  renewTime	当前 Leader 最后一次续期时间，用于判断活跃状态	"2018-04-07T07:18:39Z"
  leaderTransitions	Leader 切换次数计数器，每次 Leader 变更时递增	0（表示未发生过 Leader 切换）

• 注意事项

  • 时间格式：

    • 所有时间字段均采用 RFC 3339 格式（例如 "2025-05-04T09:30:00Z"）

  • 租约机制：

    • Leader 需在 leaseDurationSeconds 内通过更新 renewTime 证明存活
    • 若超时未续期，其他候选节点将触发重新选举

  • 字段更新逻辑：

    • 只有 Leader 有权更新 renewTime
    • 当新 Leader 当选时，holderIdentity 和 acquireTime 会被重置
    • leaderTransitions 由系统自动维护，禁止手动修改

  • 兼容性说明：

    • 此为 Kubernetes 早期（<1.14）基于 Endpoint 的 Leader Election 实现
    • 新版（≥1.14）建议使用 coordination.k8s.io/Lease 资源（字段作用相同）

5.2.2.新版本使用 Lease 作为公共对象

• 后来提供了一个更轻量级，专用于LeaderElection的类型Lease，记录的leader信息和上面的endpoint类似，只不过是记录在了spec中，比如：

  apiVersion: coordination.k8s.io/v1
  kind: Lease
  metadata:creationTimestamp: "2025-04-25T05:10:14Z"name: leader.devops-manager.infra.tce.ionamespace: tcs-systemresourceVersion: "791250083"uid: 6eb9c7a0-fc64-4fa8-85c9-8dbeca459c37
  spec:acquireTime: "2025-04-25T05:10:14.000000Z"holderIdentity: devops-manager-controller-66c7578995-6gv24_1c1cc322-ead6-4ba1-9dc7-292a7f4d299fleaseDurationSeconds: 15leaseTransitions: 0renewTime: "2025-05-04T12:40:26.194903Z"
  

6.来自生产的经验