Kubernetes 内部很多核心组件是有状态的，都以一主多从多实例的方式运行。这些组件的一主多从中，只有主实例负责处理数据，从实例处在热备状态。当主实例异常时从实例将竞选成为主实例并接替进行任务处理，所以这个选举机制是 Kubernetes 对于这有状态组件高可用的保障。

核心组件如 kube-scheduler 或 kube-controller-manager 等组件，在同一时刻只有一个实例在处理业务逻辑，因此需要在启动的实例中进行选主，决定哪个实例负责处理任务。这些核心组件都是使用的 client-go 中提供的工具类 leaderelection，也就是本文的主角。

leaderelection 依赖于 Kubernetes 中提供的 Endpoints、ConfigMap 和 Lease 三种资源锁，leaderelection 选主的实现方式就是基于这三种资源锁：

• 多个副本去创建资源，创建成功则获得锁成为 leader；
• leader 在租约内去刷新锁；
• 其他副本则通过比对锁的更新时间，判断是否竞争成为 leader。

除了能在核心组件中使用，这个组件也能使用在我们开发的应用中，前提是我们的应用运行在 Kubernetes 环境且有操作资源锁的权限。

最近公司在组织各个系统的开发人员在搞信创改造，其中有部分改造内容就是要让系统能兼容 ARM 架构的 CPU。我们的系统都是运行在 Kubernetes 的容器中的，所以需要将应用打包到不同架构的镜像中。

Docker 提供了多平台的支持，可以将不同架构的镜像打包成一个镜像，部署时再根据运行的架构不同拉取不同架构的镜像运行，构建多平台镜像可以使用 BuildX 组件实现。

在 HomeLab 的自建 Docker Swarm 集群中，在尝试删除集群中的节点时报了 permission denied 的错误。这个问题可能是 AppArmor 安全策略的问题。

由于在 HomeLab 安装 Docker 和组建 Swarm 集群时都是按照 Quick Start 相关的指引，使用的默认的 Docker AppArmor 安全配置文件。在删除节点时，
操作的配置是没有权限的。

所以这里可以简单的将 AppArmor 先禁用，再把节点删除。

1

sudo systemctl disable apparmor.service --now