pika
pika copied to clipboard
OpenAtomFoundation
pika-operator on kubeblocks 现状总结及后续任务、思路
最初关于 Operator 的设计
https://github.com/OpenAtomFoundation/pika/issues/1238
现状
codis-pika 集群, 基于 kubeblocks 实现。
- create cluster 功能：可以将 etcd、codis 和 pika 实例部署在 K8s 上。codis 集群各组件可正常创建连接。 不足：部署后，pika 实例需手动添加至 codis 集群，需手动在 kube-dashboard 设置 pika 主从。
- scale out 功能：支持通过 kbcli 扩容 codis-proxy，pika实例。 不足：pika 实例扩容后的节点需要手动添加并 rebalance。
- scale in 功能：支持通过 kbcli 缩容 codis-proxy，pika实例。 不足：pika 进行实例缩容需要手动将 slot 先迁移走，否则 pika 实例会直接被关闭，导致 slot 当前不可用。
后续任务
1. 状态管理
1.1 create cluster
- [x] [P0] 创建集群后将任务将 pika 自动的添加至 codis 集群，并 reblance。#1931
- [x] [P0] 自动管理 pika 主从，实现一主一从或多从自动添加。 #1931
1.2. scale out
- [x] [P0] scale out 后，将 pika 自动添加至 codis 集群，并 reblance 。需要改版
1.3. scale in
- [ ] [P1] scale in 开始后，先进行 slot 搬迁，再减少实例。
1.4. scale up
- [ ] [P2] 实现集群磁盘的 scale up
- [ ] [P2] 实现集群内存的 scale up
1.5 etcd manager √
- [ ] [P0] 对接 kubeblocks etcd
2. 监控 √
- [ ] [P1] 将 pika-exporter 集成入集群
- [ ] [P1] 实现 codis 集群监控
- [ ] [P2] 在 grafana 中插入 pika 监控 dashboard
3. 存储 backup/restore
- [ ] [P1] 使各个组件可独立配置存储
- [ ] [P1] 实现集群数据 backup
- [ ] [P2] 实现集群从备份拉起
- [ ] [P2] 实现集群恢复备份
5. API demo
- [ ] [P1] 实现从 API 创建 pika 集群 demo
6. 测试
- [ ] [P0] 建立 e2e Test
7. 其他
- [ ] [P1] 修改镜像地址为 pikadb
- [ ] [P2] 增加日志级别配置
- [ ] [P1] 使 pika 的细节参数可在 cluster-definition 及 cluster 中定义 √
- [ ] [P1] 动态修改 pika 配置，容器重启配置不丢失 √
实现思路
1.1 create cluster
- 创建后自动加入集群，为 pika 实例添加一个包含 codis-admin 命令的sidecar，在监测到服务正常启动后，运行命令注册。
- rebalance，[需要协助] 如何得知所有实例都启动，并执行某一命令
- 主从配置，创建两个 component(pika-master, pika-slave) [需要注意] 主从切换后主从关系会有变化，应保持主从配置的一致。pika-master/slave 使用同一个 replica count 参数，并为 slave replica count 增加一个成倍的系数。
1.2 scale out 创建及 rebalance 同1.1
1.3 scale in 考虑在 pika-master preStop 处进行操作，[需要协助] 如何得知是 hscale 操作，而不是手动 kill 实例。
- 监控，增加监控 sidecar 即可
同步下08.15的结论: 8月底支持集群创建后自动加入的功能.
- 每个KB Cluster包含多个KB Component, 每个Component对应一个pika group
- 每个pika group是一主一备形态, 启动时通过pod id来决策角色(0-主, 1-备)
- 多个KB Component可以引用同一个ComponentDef
- 不支持Component的动态添加和删除, 只能在集群创建时指定
- ETCD重启后变量配置的问题, 可以在启动脚本判断是初次启动, 还是重启.
KubeBlocks目前还没有支持Component的动态添加和删除, 会在后续版本中支持.
- https://github.com/apecloud/kubeblocks/issues/4745
对于 component scale out， 现在主要瓶颈是，无法判断集群发生了什么变化，以及是否处于这此变化的最终状态。 具体来说是在服务启动成功后，脚本很难知道，这此启动是因为扩容，还是因为节点被人为重启，或者是发生了故障。
component scale 的 action 需求：
- action 的触发需要一个明确的调用，比如 script run，web hook。
- action 的需要的信息如下
- scale out
- 执行前 无
- 执行后
- 执行的动作。
- scale in
- 执行前
- 要执行的动作。
- 需要排空的 component 的编号（假设一组 component 中，每个 component 有一个编号）
- 执行前 无
- 执行前
scale out 后只需要一个触发来明确具体发生了什么事件，后续的信息都可以从业务系统中拿到。 scale in 需要知道即将操作的组件信息。
关于action发送的数据，我有一个更通用的想法。 可以提供一个模版引擎，在 action 触发的时，渲染预制的模版，把数据发送给执行方。
11-05 日沟通总结
pika on kb 扩容功能任务拆分：
pika team:
- 将 pika 依赖的 kubeblocks 版本升级至 0.7。
- 在 pika on kb 上实现 pika 集群扩容。
kubeblocks team: 3. 在 0.7 版本的后续更新中，增加功能，使 pod 内部可以判断当前 component 是否 ready。
实现具体方案：
- 在 pika instance 中增加一个 sidecar。
- 在实例中执行如下逻辑
对于 component scale out， 现在主要瓶颈是，无法判断集群发生了什么变化，以及是否处于这此变化的最终状态。 具体来说是在服务启动成功后，脚本很难知道，这此启动是因为扩容，还是因为节点被人为重启，或者是发生了故障。
component scale 的 action 需求：
- action 的触发需要一个明确的调用，比如 script run，web hook。
- action 的需要的信息如下
scale out
执行前 无
执行后
- 执行的动作。
scale in
执行前
- 要执行的动作。
- 需要排空的 component 的编号（假设一组 component 中，每个 component 有一个编号）
执行前 无
scale out 后只需要一个触发来明确具体发生了什么事件，后续的信息都可以从业务系统中拿到。 scale in 需要知道即将操作的组件信息。
关于action发送的数据，我有一个更通用的想法。 可以提供一个模版引擎，在 action 触发的时，渲染预制的模版，把数据发送给执行方。
@machinly 关于 scaling 这里有两个问题请教一下：
- 所述的 scale in/out 是指增删新的 components，还是增删某个 component 内的 replicas？
- post-start/post-provision 和 pre-stop/pre-termination 需要执行的 register/unregister、rebalance 等操作，只需要 issue commands 即可呢？还是需要等待命令涉及的数据操作完成才可以继续？
对于 component scale out， 现在主要瓶颈是，无法判断集群发生了什么变化，以及是否处于这此变化的最终状态。 具体来说是在服务启动成功后，脚本很难知道，这此启动是因为扩容，还是因为节点被人为重启，或者是发生了故障。 component scale 的 action 需求：
- action 的触发需要一个明确的调用，比如 script run，web hook。
- action 的需要的信息如下
scale out
执行前 无
执行后
- 执行的动作。
scale in
执行前
- 要执行的动作。
- 需要排空的 component 的编号（假设一组 component 中，每个 component 有一个编号）
执行前 无
scale out 后只需要一个触发来明确具体发生了什么事件，后续的信息都可以从业务系统中拿到。 scale in 需要知道即将操作的组件信息。 关于action发送的数据，我有一个更通用的想法。 可以提供一个模版引擎，在 action 触发的时，渲染预制的模版，把数据发送给执行方。
@machinly 关于 scaling 这里有两个问题请教一下：
- 所述的 scale in/out 是指增删新的 components，还是增删某个 component 内的 replicas？
- post-stop/post-provision 和 pre-stop/pre-termination 需要执行的 register/unregister、rebalance 等操作，只需要 issue commands 即可呢？还是需要等待命令涉及的数据操作完成才可以继续？
我这里把增删都列了出来，但这期暂时不考虑 component 的 scale in 的情况。
- 这个 scale in/out 指的是增删新的 components。现在的结构是 一组分片为一个 component， component 中包含了一主多从。以 component 为单位 scale。
- 在 stop 前涉及数据搬迁的操作，需要等待搬迁结束以保证数据的一致性，可能耗时比较久。
kubeblocks pika 现状介绍 https://meeting.tencent.com/user-center/shared-record-info?id=b11f03fd-96c7-42ec-902c-12c5b31d8b52&reload=1
目前基于 0.8.2 的问题：
问题1 P1
hscale 不支持 pika-group 维度的扩缩，预计 0.8.3 版本支持扩容，缩容应该会在 0.8.4版本发布
问题2 P0
codis-proxy 发生漂移后，在 codis-fe 出现如下异常。
强制 pod 漂移，可以使用 kubectl taint nodes 命令设置污点的方式
问题3 P0 已经修改；
不支持在一个k8s集群中创建多个 pika 集群，主要是没有支持 namespace
问题4 P0
pika 配置文件只是写在容器内部，如果容器发生重启，pika 配置文件如果发生过更改，那更改的配置将会丢失
问题5 P2
现有的 etcd 在扩容时应该将 –initial-cluster-state 的值由 new 改为 existing。如果不进行扩容，使用 new 重启etcd服务，etcd 服务不会存在问题。
问题6 P0 03/05 doing
还不支持监控，需要将 pika-exporter 集成进去。 是否需要集成 Prometheus 和 Grafana？不需要集成。
问题7 P0
pika-group 缩容时，可以正常减少 pika 实例，但是 codis-fe 页面仍然显示该 pika 实例，需要在缩容时，调用 codis-dashboard 接口，删除该实例
问题8 P2
版本升级问题，kubeblock 0.9 版本，预计 4月份发布
问题9 P0
更新到最新的版本（pika/codis） 03/05 Codis 无法获取 codis 二进制的版本号
问题10 P1
pika-group 内部pika实例缩容时，不支持指定节点下线，只能从最大开始缩容
问题11 P0
pika 实例如果发生pod漂移，会导致数据丢失。主从关系是由 codis-dashboard 控制，如果一个Master的pod发生漂移，新的Pod中没有pika数据，但是在 pika-group 中，该节点仍然是主节点，但是新的Pod已经丢失了原有的配置信息。Pod漂移会导致服务异常。
如何控制pod不漂移？？如果支持 pod 漂移，如何通知 codis-dashboard 做主从切换？？
问题12 P0
CPU和内存支持扩容缩容，但是会并发重启 pika-group 内所有 Pika 实例，这样会导致一段时间的服务不可用
问题13 P0
pika 实例和 etcd 实例，数据是存在容器内部，容器重启会导致数据丢失。 本地数据卷只能以静态创建的 PV 使用，对于文件系统来说，kubernetes 并不会限制该目录可以使用的存储空间大小。
本地数据卷
参考：https://kubernetes.feisky.xyz/concepts/objects/local-volume
https://developer.aliyun.com/article/708483
问题14
0.8.3 版本的API有变更导致不兼容，新提交的 PR 代码会使 pika-group 创建异常
https://github.com/OpenAtomFoundation/pika/pull/2411
pika-group Component 的名字由数字变为了随机字符串。
