草稿
[WIP]feat: add first version upgrade doc #162
xuyouh创建于 4月10日
[WIP]feat: add first version upgrade doc #162
草稿
共 1 个文件变更+147-0
| @@ -0,0 +1,147 @@ | |||
| 1 | +# bke集群安装和升级流程 | ||
| 2 | + | ||
| 3 | +cluster-api-provider-bke是社区自研调谐器，监听bkecluster和bkenode自定义资源，配合k8s社区cluster-api组件完成集群的生命周期管理，包括集群的创建、删除、扩缩容和升级。 | ||
| 4 | + | ||
| 5 | +## bke集群安装 | ||
| 6 | + | ||
| 7 | +集群的安装大概分为推送bkeagent、节点环境初始化、LB配置、节点加入、addon扩展件安装和集群状态检测。 | ||
| 8 | + | ||
| 9 | +#### 推送bkeagent | ||
| 10 | + | ||
| 11 | +bkeagent作为集群的节点代理，监控commands这个自定义资源，通过参数`--kube-config`监听上一级集群的APIServer。 | ||
| 12 | + | ||
| 13 | +#### 节点环境初始化 | ||
| 14 | + | ||
| 15 | +调谐器会给集群的节点下发一系列环境初始化的commands，处理节点满足后续的部署要求。 | ||
| 16 | + | ||
| 17 | +其中containerd就是这个阶段安装到各个节点上，配置文件是从cct这个自定义资源中获取的。 | ||
| 18 | + | ||
| 19 | +#### LB配置（cluster-api-provider-bke） | ||
| 20 | + | ||
| 21 | +使用haproxy+keepalived配置ha高可用集群，配置了ha才会执行该阶段，会生成haproxy和keepalived的配置和静态pod的yaml文件。 | ||
| 22 | + | ||
| 23 | +#### 节点加入（cluster-api-provider-bke） | ||
| 24 | + | ||
| 25 | +k8s组件包含kube-apiserver、kube-controller-manager、kube-scheduler和etcd，目前这几个组件只会在master节点上安装。 | ||
| 26 | + | ||
| 27 | +具体流程是调谐器生成bootstrap的commands，bkeagent会执行kubeadm的操作。 | ||
| 28 | + | ||
| 29 | +- master节点 | ||
| 30 | + - 安装kubectl | ||
| 31 | + - 生成证书 | ||
| 32 | + - 生成静态pod的yaml文件 | ||
| 33 | + - 安装kubelet | ||
| 34 | +- worker节点 | ||
| 35 | + - 生成证书 | ||
| 36 | + - 安装kubectl和kubelet | ||
| 37 | + | ||
| 38 | +### addon扩展件安装（bke-manifests） | ||
| 39 | + | ||
| 40 | +调谐器通过addon安装所需的扩展件，当前支持kubeproxy、calico、coredns、bkeagent-deployer、cluster-api、openfuyao-system-controller等addon，用户已可以安装自定义扩展件。 | ||
| 41 | + | ||
| 42 | +- kubeproxy：网络组件，会部署ds的节点pod。 | ||
| 43 | + | ||
| 44 | +- calico：网络插件，会部署ds的calico-node和deployment的calico-kube-controller（副本数1）。 | ||
| 45 | + | ||
| 46 | +- coredns：集群dns服务，会部署deployemnt的coredns（副本数2）。 | ||
| 47 | + | ||
| 48 | +- bkeagent-deployer：bkeagent升级所需的ds节点pod。 | ||
| 49 | + | ||
| 50 | +- cluster-api：部署k8s社区和自研的cluster相关调谐器，会涉及到很多的crd，部署deployment的capi-controller-manager和bke-controller-manager（副本数1）。 | ||
| 51 | + | ||
| 52 | +- openfuyao-system-controller：这是deployment部署的pod，shell脚本合集，专门用来拉起openFuyao管理面组件。 | ||
| 53 | + | ||
| 54 | + - helm chart | ||
| 55 | + | ||
| 56 | + 包含console-website、console-service、monitoring-service、marketplace、application-managerment、plugin-managerment、user-managerment、web-terminal、oauth-server、oauth-webhook、installer-service、installer-website、local-harbor | ||
| 57 | + | ||
| 58 | + - yaml文件 | ||
| 59 | + | ||
| 60 | + 包含ingress-nginx、kube-prometheus、metrics-server | ||
| 61 | + | ||
| 62 | +### 集群状态检测 | ||
| 63 | + | ||
| 64 | +定期检测集群中的pod状态，最终确定集群的监控状态。 | ||
| 65 | + | ||
| 66 | +## bke集群升级 | ||
| 67 | + | ||
| 68 | +**bke集群的升级能力集成在cluster-api-provider-bke调谐器中，其只能处理bkecluster对应的集群，因此目前的升级能力只能覆盖管理集群和业务集群，引导集群是没法通过当前的升级结构来处理的。** | ||
| 69 | + | ||
| 70 | +目前的升级涉及到下面的组件： | ||
| 71 | + | ||
| 72 | +- cluster-api-provider-bke调谐器自升级 | ||
| 73 | + | ||
| 74 | + 业务集群升级：升级业务集群时会把其上一层管理集群的调谐器升级（问题，需要修复） | ||
| 75 | + | ||
| 76 | + 管理集群升级：直接替换镜像tag，未考虑到crd变更、部署yaml的变更 | ||
| 77 | + | ||
| 78 | + **问题点：未处理crd变更、部署yaml的变更、已部署的bc数据的处理** | ||
| 79 | + | ||
| 80 | + 解决手段，下面提供两种思路 | ||
| 81 | + | ||
| 82 | + - 新旧数据的转换+履约新的yaml部署 | ||
| 83 | + - 使用operator来处理cluster-api-provider-bke的升级 | ||
| 84 | + | ||
| 85 | +- bkeagent节点代理升级 | ||
| 86 | + | ||
| 87 | + 识别到集群中bkeagent-deployer需要进行镜像替换，调谐器就会进行镜像tag的替换，然后调谐器下发节点bkeagent升级的commands，节点就会从bkeagent-deployer挂载的路径下拿出最新的bkeagent，重启bkeagent服务。 | ||
| 88 | + | ||
| 89 | + - 升级bkeagent-deployer的镜像tag | ||
| 90 | + - 下发bkeagent升级的commands | ||
| 91 | + | ||
| 92 | + **问题点：未考虑到bkeagent-deployer部署yaml的变更、bkeagent启动方式的变更** | ||
| 93 | + | ||
| 94 | + 解决手段：1、直接使用新的部署yaml文件替换掉旧的 2、调谐器下发升级的commands增加相关的能力（或者参数放置到bkeagent-deployer） | ||
| 95 | + | ||
| 96 | +- kube组件升级，连带kubeproxy一块 | ||
| 97 | + | ||
| 98 | + - 生成新的静态pod的yaml文件，替换新的kubectl和kubelet，会重新生成kubelet的配置 | ||
| 99 | + - kubeproxy直接替换镜像tag | ||
| 100 | + | ||
| 101 | + **问题点：版本之间的部署模板文件出现变更，没法处理** | ||
| 102 | + | ||
| 103 | + 解决手段：尝试维护不同的k8s版本对应的模板文件（依赖于先升级cluster-api-provider-bke） | ||
| 104 | + | ||
| 105 | +- etcd组件升级 | ||
| 106 | + | ||
| 107 | + 选择备份etcd数据的节点，然后master节点依次处理etcd的升级，etcd的升级也是生成新的静态pod的yaml文件，然后重启kubelet触发新的etcd的拉起。 | ||
| 108 | + | ||
| 109 | + **问题点和解决手段同kube组件。** | ||
| 110 | + | ||
| 111 | +- containerd升级 | ||
| 112 | + | ||
| 113 | + 识别到containerd版本变更，就需要进行containerd的替换。 | ||
| 114 | + | ||
| 115 | + - reset删除旧的containerd； | ||
| 116 | + - 重新部署新的containerd，会重新生成containerd的配置，然后启动新的containerd服务。 | ||
| 117 | + | ||
| 118 | + **问题点：不同版本之间的模板文件出现变更，没法处理** | ||
| 119 | + | ||
| 120 | + 解决手段：尝试维护不同的containerd版本对应的模板文件（依赖于先升级cluster-api-provider-bke），然后升级时根据不同的版本选择模板文件 | ||
| 121 | + | ||
| 122 | +- 剩余组件升级（包含calico、coredns、openFuyao管理面组件和capi-controller-manager） | ||
| 123 | + | ||
| 124 | + 当前处理仅是替换pod中容器使用的镜像tag，使用k8s的升级能力，重新拉起新的pod。 | ||
| 125 | + | ||
| 126 | + **问题点：出现部署yaml的变更，未能正常处理** | ||
| 127 | + | ||
| 128 | + 解决手段：尝试不同版本维护不同的yaml文件，升级时使用新的yaml拉起新的pod | ||
| 129 | + | ||
| 130 | +## 当前批次结论 | ||
| 131 | + | ||
| 132 | +k3s引导集群能拉起管理K8s集群和业务K8s集群，管理K8s集群能拉起业务K8s集群。 | ||
| 133 | + | ||
| 134 | +k3s引导集群和管理K8s集群都包含cluster-api组件。**k3s引导集群不支持升级处理。** | ||
| 135 | + | ||
| 136 | +规则约束： | ||
| 137 | + | ||
| 138 | +- 组件升级自行保证 | ||
| 139 | +- 无状态的pod，存在crd变更，自行保证 | ||
| 140 | +- 有状态的pod，数据处理自行保证 | ||
| 141 | + | ||
| 142 | +## 下一步计划 | ||
| 143 | + | ||
| 144 | +1. **安装过程中的所有组件的配置yaml来源（细化下）** | ||
| 145 | +2. openFuyao版本包和升级包 | ||
| 146 | +3. 升级路径 | ||
| 147 | +4. 升级通用机制（升级前检查、存量数据转换（升级前处理）、升级操作） | ||