用Deployment快速扩展kube-apiserver

概述

一直以来对 kube-apiserver 的说法都是，kube-apiserver 作为一个无状态的组件，可以支持水平扩容，对于这个说法，不禁会有个疑问，如果将 kube-apiserver 作为集群中类似其他 Deployment 的方式进行部署，需要做什么改造，以及这样做，是否会有风险呢。本文从可行性分析和实验操作两个部分进行验证的描述。

可行性分析

用 Deployment 部署 kube-apiserver 主要用于快速扩容、恢复 kube-apiserver 等目的，因为查阅过社区和网络上的资料，没有太多公开成熟的 case，所以先根据 Kubernetes 部署的架构，先讨论一下可行性。关于 Kubernetes 集群的部署细节。跟 kube-apiserver 有网络连接的组件主要有以下:

1. kubelet通过kube-apiserver的域名如访问
2. kube-apiserver各自需要访问ETCD
3. kube-scheduler/kube-controller-manager通过conf文件里的ClientConfig，一般是也是域名访问kube-apiserver
4. 自定义controller通过in-cluster的配置，通过kubernetes这个svc访问到kube-apiserver

整体的架构上，我们主要是通过 【域名】→ 【VIP】 → 【kube-apiserver实例】这样的路径进行访问，证书签的也是域名而非后端实例的 IP，所以从可行性上看，通过 Deployment 部署的 kube-apiserver 只要能够注册到 VIP，即可实现通过 Deployment 快速扩容 kube-apiserver 的能力。如果内部已经实现自动注册 Pod IP 到 VIP 的机制的话，结合以上两点，这个方案可以在测试环境进行实际的实验和验收。

实验环境

申请一个测试环境的域名，然后注册一个测试环境 VIP 的应用，获取一个 VIP: 10.189.142.29

测试环境里使用 db1 集群做一下测试。

因为测试集群是通过 kubeadm 搭建的，所有证书都是 kubeadm 生成的，另外我们后面需要通过 vip 访问 Kubernetes 集群，所以需要 renew 一下原来的证书，把 VIP 作为 SAN 加入，然后更新证书，重启 kubelet，重启 kube-apiserver，这一步在生产环境是不需要的。

1
2

# --config指定的是kubeadm的配置文件
kubeadm certs renew apiserver --config=/root/dok-release/bin/k8s/dok.yaml

一切就绪之后，按道理是不会影响集群的运作的。然后准备 kube-apiserver 的 Deployment 部署文件，注意这里的镜像，为了方便测试，把 CA 和 kube-apiserver 等所有证书，包括 ETCD 的客户端证书都打入了的，所以不需要额外配置本地的证书文件，连路径都跟原来一模一样，可以参考下面这个 Dockerfile。

1
2
3

FROM kube-apiserver:v1.30.4
# pki文件夹下的证书来源于10.189.110.45的/etc/kubernetes/pki
ADD pki /etc/kubernetes/pki/

最后通过 kubectl 指定 server 地址，即可通过 vip 访问后端的 kube-apiserver。

从 Deployment 方式部署的 kube-apiserver 的日志可以查看到个人客户端的访问 IP，这样也验证了这种方式部署的 kube-apiserver 在网络连通性上是没有问题的。

结合HPA

针对新版本的 K8s 集群，HPA 是基础的能力，且因为 Static Pod 的存在，kube-apiserver 的实例数理论上永远不会为0，所以依赖 HPA 的能力，可以很容易实现 kube-apiserver 根据流量或者其他负载指标进行扩缩容。

预期问题

1. 非Controlplane节点上没有相关的证书，可能要考虑镜像或者下载的方式获取
2. 社区上没有太多类似的样例参考，可能需要考虑一下原因，不成熟还是有循环依赖，鸡生蛋蛋生鸡之类的问题？

💡赞赏支持

微信打赏 支付宝打赏