已开启
update: 增加BKE支持安装K8S和ETCD拆分设计文档 #116
mmmonsterrr创建于 2月12日
update: 增加BKE支持安装K8S和ETCD拆分设计文档 #116
已开启
共 2 个文件变更+178-0
| @@ -0,0 +1,178 @@ | |||
| 1 | +### 1 特性描述 | ||
| 2 | + | ||
| 3 | +#### 背景 | ||
| 4 | +大规模集群的安装部署能力当前是独立的工具进行安装，需要将能力统一到 bke 中，支持不同场景的安装部署。 | ||
| 5 | +bke 安装能力现状：支持按照角色区分节点，完成组件在节点上安装的编排。 | ||
| 6 | + | ||
| 7 | +#### 目标 | ||
| 8 | +大规模场景可以使用 bke 进行集群的规划安装部署。 | ||
| 9 | + | ||
| 10 | +#### 1.1 依赖组件 | ||
| 11 | +不涉及 | ||
| 12 | + | ||
| 13 | +#### 1.2 License | ||
| 14 | + | ||
| 15 | +Mulan PSL v2 License | ||
| 16 | + | ||
| 17 | +### 2 需求场景威胁建模 | ||
| 18 | +未新增组件，不涉及新增威胁场景。 | ||
| 19 | + | ||
| 20 | +### 3 特性设计 | ||
| 21 | + | ||
| 22 | +#### 3.1 上下文/USE-CASE视图 | ||
| 23 | +**交互视图** | ||
| 24 | +```mermaid | ||
| 25 | +flowchart LR | ||
| 26 | + A[User] -->|1. Apply 集群配置| K(BKE Console) | ||
| 27 | + K -->|2. Apply BKECluster 和 BKENode 资源| B(引导集群 kube-apiserver) | ||
| 28 | + B -->|3. Watch 资源数据 | C[clusterapi-provider-bke] | ||
| 29 | + C -->|4. 调谐安装部署命令| B | ||
| 30 | + D[bke-agent] -->|5. Watch 安装部署命令| B | ||
| 31 | + D -->|6. 执行安装后更新安装部署结果| B | ||
| 32 | +``` | ||
| 33 | + | ||
| 34 | +#### 3.2 具体分析 | ||
| 35 | + | ||
| 36 | +整体思路：BKE 安装不对外体现是否大规模集群，提供配置能力支持按照大规模集群的最佳实践来规划管理节点组件的部署形态。 | ||
| 37 | + | ||
| 38 | +##### 3.2.1 安装部署现状 | ||
| 39 | +在集群中，业务组件部署在特定的节点上，是使用节点 Role 来进行区分的，包含如下字段： | ||
| 40 | +| Role | Components | | ||
| 41 | +| --- | ---- | | ||
| 42 | +| master | etcd、kube-apiserver、kube-controller-manager、kube-scheduler、addons | | ||
| 43 | +| etcd | etcd | | ||
| 44 | +| node | kubelet、kube-proxy、addons | | ||
| 45 | + | ||
| 46 | +以 3 master + 1 worker 集群为例，Node 示例资源如下： | ||
| 47 | +```yaml | ||
| 48 | +spec: | ||
| 49 | + hostname: master1 | ||
| 50 | + ip: 10.44.244.1 | ||
| 51 | + role: | ||
| 52 | + - master/node | ||
| 53 | + - etcd | ||
| 54 | +--- | ||
| 55 | +spec: | ||
| 56 | + hostname: master2 | ||
| 57 | + ip: 10.44.244.2 | ||
| 58 | + role: | ||
| 59 | + - master/node | ||
| 60 | + - etcd | ||
| 61 | +--- | ||
| 62 | +spec: | ||
| 63 | + hostname: master3 | ||
| 64 | + ip: 10.44.244.3 | ||
| 65 | + role: | ||
| 66 | + - master/node | ||
| 67 | + - etcd | ||
| 68 | +--- | ||
| 69 | +... | ||
| 70 | +spec: | ||
| 71 | + hostname: node1 | ||
| 72 | + ip: 10.44.244.4 | ||
| 73 | + ... | ||
| 74 | + role: | ||
| 75 | + - node | ||
| 76 | +``` | ||
| 77 | +部署结果如下： | ||
| 78 | +| 节点 | etcd | apiserver | controller | scheduler | coredns | | ||
| 79 | +| ---- | ---- | ------ | ------ | ------ | ------ | | ||
| 80 | +| master1 | √ | √ | √ | √ | √ | | ||
| 81 | +| master2 | √ | √ | √ | √ | | | ||
| 82 | +| master3 | √ | √ | √ | √ | | | ||
| 83 | +| node1 | | | | | √ | | ||
| 84 | + | ||
| 85 | +当前部署后的节点标签如下： | ||
| 86 | +| NAME | Role | LABELS | | ||
| 87 | +| ---- | ---- | ------ | | ||
| 88 | +| master1 | control-plane,master,node,worker | node-role.kubernetes.io/control-plane=control-plane<br>node-role.kubernetes.io/worker=worker<br>node-role.kubernetes.io/master=<br>node-role.kubernetes.io/node= | | ||
| 89 | +| master2 | control-plane,master,node,worker | node-role.kubernetes.io/control-plane=control-plane<br>node-role.kubernetes.io/worker=worker<br>node-role.kubernetes.io/master=<br>node-role.kubernetes.io/node= | | ||
| 90 | +| master3 | control-plane,master,node,worker | node-role.kubernetes.io/control-plane=control-plane<br>node-role.kubernetes.io/worker=worker<br>node-role.kubernetes.io/master=<br>node-role.kubernetes.io/node= | | ||
| 91 | +| node1 | node,worker | node-role.kubernetes.io/worker=worker<br>node-role.kubernetes.io/node= | | ||
| 92 | + | ||
| 93 | +##### 3.2.2 安装部署调整 | ||
| 94 | +在大规模集群场景下，相比传统集群部署形态，管理节点上有如下变化： | ||
| 95 | +- etcd 集群拆分：etcd-data、etcd-pods、etcd-events/lease | ||
| 96 | +- 集群组件支持部署在不同的 master 节点上 | ||
| 97 | +- 组件实例数可变 | ||
| 98 | +- 管理组件的部署参数调整 | ||
| 99 | + | ||
| 100 | +因此需要对节点角色重新定义，支持用户指定节点角色来规划大规模集群组件的部署分布： | ||
| 101 | +| Role | Components | Optional | Default behavior| | ||
| 102 | +| ---- | ---- | ---- | ---- | | ||
| 103 | +| master | kube-apiserver、kube-controller-manager、kube-scheduler、addons | false | all master | | ||
| 104 | +| apiserver | kube-apiserver | true | all master | | ||
| 105 | +| controller-manager | kube-scheduler | true | all master | | ||
| 106 | +| scheduler | kube-apiserver | true | all master | | ||
| 107 | +| etcd | etcd-data | false | all master | | ||
| 108 | +| etcd-event | etcd | true | all master | | ||
| 109 | +| etcd-pod | etcd | true | all master | | ||
| 110 | +| node | kubelet、kube-proxy、addons | false | | | ||
| 111 | + | ||
| 112 | +##### 3.2.3 调整后需要增加的能力 | ||
| 113 | + | ||
| 114 | +1. 在 bkecluster 中的 ensure_certs 阶段，根据节点是否有相关角色配置，来给新拆分的组件生成对应的证书，主要包含如下组件： | ||
| 115 | + - etcd-pods | ||
| 116 | + - etcd-events/lease | ||
| 117 | + | ||
| 118 | +2. 静态 Pod yaml 模版文件修改 | ||
| 119 | + - 需要添加新拆分组件的静态 Pod yaml 模板文件，与2中组件对应 | ||
| 120 | + - 并将最佳实践中可用于小规模集群的参数默认带进去，如 `--goaway-chance`，以及新版本针对 list 请求资源优化的特性等 | ||
| 121 | + | ||
| 122 | +3. 安装细节调整 在 masterinit 阶段给节点上生成静态 Pod manifest 配置文件适配点 | ||
| 123 | + - masterinit 需要拆分出先安装 etcd 集群 phase，再初始化 apiserver（节点中 kubelet 需要先安装） | ||
| 124 | + - 然后在 masterinit 阶段和 masterjoin 阶段根据当前节点的角色，生成对应组件的yaml文件 | ||
| 125 | + - 针对有 etcd 拆分集群的时候，补充 apiserver 配置文件中对应的 etcd-servers-overrides 配置 | ||
| 126 | + - 其他支持自定义的配置按需添加到静态 Pod yaml中（界面能力不具备，后端已支持 extraArgs） | ||
| 127 | + | ||
| 128 | +4. 如何区分默认场景和组件拆分场景？ | ||
| 129 | + - 在安装部署时判断是否有节点均存在对应组件标签，如果有，则仅在有对应标签节点中安装该组件，如果均没有，则保持现状，在所有 master 节点上进行安装部署。 | ||
| 130 | + | ||
| 131 | +5. 升级场景 | ||
| 132 | + - 不支持非拆分场景到拆分场景的升级； | ||
| 133 | + - 拆分场景的升级流程不变，但需要在对应的 phase 中更新对应节点 etcd 拆分组件的 yaml。 | ||
| 134 | + | ||
| 135 | +6. 前台安装服务需要增加支持配节点部署组件的能力，该部分可先不做，优先后台能力 | ||
| 136 | + - 前台界面需要支持用户配置规划 master 节点部署组件的能力，在已有界面中增加一列用于选择节点部署组件，对应到节点的角色信息，不可新增，只能选择，示意图如下： | ||
| 137 | +  | ||
| 138 | + - 前台界面需要支持用户配置管理面组件参数的能力（后端已支持 extraArgs） | ||
| 139 | + | ||
| 140 | + | ||
| 141 | +#### 3.3 质量属性设计 | ||
| 142 | + | ||
| 143 | +##### 3.3.1 性能规格 | ||
| 144 | +不涉及 | ||
| 145 | + | ||
| 146 | +##### 3.3.2 可靠性设计 | ||
| 147 | +- 新增组件，流程不变，现有流程可以保证安装失败后重试成功。 | ||
| 148 | + | ||
| 149 | +##### 3.3.3 安全/韧性/隐私设计 | ||
| 150 | +- 证书按需生成 | ||
| 151 | +- 前台界面增加参数，需要做安全校验 | ||
| 152 | + | ||
| 153 | +##### 3.3.4 兼容性设计 | ||
| 154 | +- 不需要考虑升级回滚场景，不涉及； | ||
| 155 | + | ||
| 156 | +##### 3.3.5 可服务性设计 | ||
| 157 | +- 无新增资源，原始信息中包含安装步骤和具体状态信息。 | ||
| 158 | + | ||
| 159 | +##### 3.3.6、可测试性设计 | ||
| 160 | + | ||
| 161 | +- 单元测试：Go 代码中对应新资源有详尽的单元测试覆盖。 | ||
| 162 | +- 集成测试：通过集成测试验证能够按照规划完成集群的安装部署。 | ||
| 163 | + | ||
| 164 | +# 4、需求分解分配表 | ||
| 165 | + | ||
| 166 | +| 序号 | 模块名称 | Story名称 | Story描述 | | ||
| 167 | +|:--- |:---- |:------- |:------- | | ||
| 168 | +| | | | | | ||
| 169 | +| | | | | | ||
| 170 | + | ||
| 171 | +# 5、修改日志 | ||
| 172 | + | ||
| 173 | +| 版本 | 发布说明 | | ||
| 174 | +|:--- |:---- | | ||
| 175 | +| | | | ||
| 176 | +| | | | ||
| 177 | + | ||
| 178 | +# 6、参考目录 | ||