大家是否曾经考虑过更改 Kubernetes 集群的 etcd 数据的“低级”方法?就是说在不使用任何通用的 Kubernetes 工具(例如 CLI 程序甚至 API)就更改 etcd 存储的数据。

一切从这开始

越来越多的客户(大多是开发人员)要求提供对 Kubernetes 集群的访问权限,以便与内部服务进行交互。他们希望能够直接连接到数据库或服务,将本地应用程序连接到集群中的其他应用程序等等。

例如,从本地计算机连接到 memcached.staging.svc.cluster.local service。我们可以通过客户端连接的集群内部 VPN 来实现。我们公开与 Pod 和 service 相关的子网,并将集群的 DNS 推送到客户端。结果,当客户端尝试连接到 memcached.staging.svc.cluster.local service 时,请求转到了集群的 DNS,它从集群的服务网络或 Pod 的地址返回该 service 的地址。

我们使用 kubeadm 配置 K8s 集群。在这种情况下,默认 service subnet(子网)是 192.168.0.0/16,而 Pod 子网是 10.244.0.0/16。此方法大部分时候效果很好,但是也有几点值得注意:

  • 192.168.*.* 子网往往是在客户办公室中使用,甚至是开发商的家庭办公室。这就出现了问题:家用路由器会使用相同的地址空间,VPN 会将这些子网从集群推送到客户端。
  • 有几个集群(production、stage、多个 dev 集群)的情况下,它们将默认全部具有与  Pod 和服务的相同子网,这使得同时使用多个集群中的 services 非常困难。

我们在同一项目中使用了不同的子网来实现同一项目中的不同 service 和 Pod。在这种情况下,任何集群都有其自己的网络。在维护大量 K8s 集群时,我们不希望它们从头开始重新部署,因为会有许多正在运行的 service、有状态的应用程序等。这时候就出现了一个问题:我们如何更改现有集群中的子网?

解决方案

最常见的方法是重新创建所有 ClusterIP 类型的 service。不过也有问题:

以下过程存在问题:配置完所有内容后,Pod 在 /etc/resolv.conf 中将旧 IP 用作 DNS nameserver。由于仍然找不到解决方案,因此不得不使用 kubeadm reset 重置整个集群,再次将其初始化。

这并不适合所有场景,这里是案例更详细的情况:

  • 使用 Flannel。
  • 既有裸机集群,也有 Kubernetes 云集群。
  • 希望避免重新部署集群中的所有 service。
  • 希望尽可能轻松地进行过渡。
  • 该集群由 Kubernetes v1.16.6管理(但也适用于其他版本)。
  • 目标是在使用 kubeadm 在部署的集群中将 192.168.0.0/16 service subnet 替换为 172.24.0.0/16

实际上,很多人一直想研究 Kubernetes 是如何将其数据存储在 etcd 中以及该存储可以做什么。那我们为什么不通过替换旧的来更新 etcd 中的数据子网 IP 与新 IP ?最好有现成的工具来修改 etcd 中的数据,虽然目前没有任何工具可以很好地满足我们的需求,但 OpenShift 的 etcdhelper 是一个很好的起点。这个工具可以使用证书连接 etcd,并能用 lsgetdump 命令阅读 etcd 数据。

扩展 etcdhelper

因此,我们准备扩展 etcdhelper,以便将数据写入 etcd。我们创建了具有两个新功能的 etcdhelper 的更新版本: changeServiceCIDR 和 changePodCIDR。其源代码可在此处获得:https://github.com/flant/examples/tree/master/2020/04-etcdhelper

新功能有什么作用?这是 changeServiceCIDR 算法:

  • 创建一个反序列化器(deserializer)。
  • 编译正则表达式以替换 CIDR。
  • 遍历集群中的 ClusterIP service 列表,并对每个 service 执行操作。

这是我们的操作:

  • 解码 etcd 值并将其放置在 Go 对象中。
  • 使用正则表达式替换地址的前两个字节。
  • 从新子网的地址范围为 service 分配 IP 地址。
  • 创建一个序列化器,将 Go 对象转换为 protobuf,将新数据写入 etcd。

changePodCIDR 功能与 changeServiceCIDR 基本上相同,唯一的区别是我们编辑节点的规范时,用新的子网替换了 .spec.PodCIDR 的值,而不是 service。

用法

更换 serviceCIDR

这事很容易实现,但会导致停机,并且集群中的所有 Pod 都将被重新创建。这里我们先展示主要步骤,然后分享如何最大程度地减少停机时间。准备步骤:

  • 安装必要的软件并构建补丁 etcdhelper 工具;
  • 备份 etcd 和 /etc/kubernetes

以下是更改 serviceCIDR 的操作摘要:

  • 更改 apiserver 和控制器管理器清单。
  • 重新颁发证书。
  • 修改 etcd 中 services 的 ClusterIP 规范。
  • 重新启动集群中的所有 Pod。

以下是这些步骤的详细说明:

1.安装 etcd-client 用于转储数据:

2.构建 etcdhelper 工具:

  • 安装 golang
  • 复制 etcdhelper.go,下载依赖项,构建工具:

3.备份 etcd 数据:

4.在 Kubernetes 控制平面清单中切换 service subnet。在 /etc/kubernetes/manifests/kube-apiserver.yaml 和 /etc/kubernetes/manifests/kube-controller-manager.yaml 中替换 --service-cluster-ip-range 值与新子网(172.24.0.0/16 替代 192.168.0.0/16)。

5.由于我们在对 kubeadm 颁发 apiserver 证书(以及其他证书)的service subnet进行更改,因此我们需要重新颁发:

5.1.检查当前证书颁发的域和 IP 地址:

5.2.准备 kubeadm 基本配置: