pika-operator on kubeblocks 现状总结及后续任务、思路

[machinly]

最初关于 Operator 的设计

#1238

现状

codis-pika 集群, 基于 kubeblocks 实现。

1. create cluster
   功能：可以将 etcd、codis 和 pika 实例部署在 K8s 上。codis 集群各组件可正常创建连接。
   不足：部署后，pika 实例需手动添加至 codis 集群，需手动在 kube-dashboard 设置 pika 主从。
2. scale out
   功能：支持通过 kbcli 扩容 codis-proxy，pika实例。
   不足：pika 实例扩容后的节点需要手动添加并 rebalance。
3. scale in
   功能：支持通过 kbcli 缩容 codis-proxy，pika实例。
   不足：pika 进行实例缩容需要手动将 slot 先迁移走，否则 pika 实例会直接被关闭，导致 slot 当前不可用。

后续任务

1. 状态管理

1.1 create cluster

• [P0] 创建集群后将任务将 pika 自动的添加至 codis 集群，并 reblance。operator: automatic registration for the Pika service #1931
• [P0] 自动管理 pika 主从，实现一主一从或多从自动添加。 operator: automatic registration for the Pika service #1931

1.2. scale out

• [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 实例。

2. 监控，增加监控 sidecar 即可

[shanshanying]

同步下08.15的结论: 8月底支持集群创建后自动加入的功能.

1. 每个KB Cluster包含多个KB Component, 每个Component对应一个pika group
2. 每个pika group是一主一备形态, 启动时通过pod id来决策角色(0-主, 1-备)
3. 多个KB Component可以引用同一个ComponentDef
4. 不支持Component的动态添加和删除, 只能在集群创建时指定
5. ETCD重启后变量配置的问题, 可以在启动脚本判断是初次启动, 还是重启.

KubeBlocks目前还没有支持Component的动态添加和删除, 会在后续版本中支持.

• [Features] Support Component Scaling for Shardings apecloud/kubeblocks#4745

[Mixficsol]

0902 马鑫：reblance 还需要完善；显荣：目前测试没问题，等 kubeblock 升级后继续测试，synced_failed 问题跟进

[machinly]

对于 component scale out， 现在主要瓶颈是，无法判断集群发生了什么变化，以及是否处于这此变化的最终状态。
具体来说是在服务启动成功后，脚本很难知道，这此启动是因为扩容，还是因为节点被人为重启，或者是发生了故障。

component scale 的 action 需求：

1. action 的触发需要一个明确的调用，比如 script run，web hook。
2. action 的需要的信息如下

• scale out
  • 执行前 无
  • 执行后
    • 执行的动作。
• scale in
  • 执行前
    • 要执行的动作。
    • 需要排空的 component 的编号（假设一组 component 中，每个 component 有一个编号）
  • 执行前 无

scale out 后只需要一个触发来明确具体发生了什么事件，后续的信息都可以从业务系统中拿到。
scale in 需要知道即将操作的组件信息。

---

关于action发送的数据，我有一个更通用的想法。
可以提供一个模版引擎，在 action 触发的时，渲染预制的模版，把数据发送给执行方。

[machinly]

11-05 日沟通总结

pika on kb 扩容功能任务拆分：

pika team:

1. 将 pika 依赖的 kubeblocks 版本升级至 0.7。
2. 在 pika on kb 上实现 pika 集群扩容。

kubeblocks team:
3. 在 0.7 版本的后续更新中，增加功能，使 pod 内部可以判断当前 component 是否 ready。

实现具体方案：

1. 在 pika instance 中增加一个 sidecar。
2. 在实例中执行如下逻辑

[leon-inf]

对于 component scale out， 现在主要瓶颈是，无法判断集群发生了什么变化，以及是否处于这此变化的最终状态。 具体来说是在服务启动成功后，脚本很难知道，这此启动是因为扩容，还是因为节点被人为重启，或者是发生了故障。

component scale 的 action 需求：

1. action 的触发需要一个明确的调用，比如 script run，web hook。
2. action 的需要的信息如下

• scale out

  • 执行前 无

  • 执行后

    • 执行的动作。

• scale in

  • 执行前

    • 要执行的动作。
    • 需要排空的 component 的编号（假设一组 component 中，每个 component 有一个编号）

  • 执行前 无

scale out 后只需要一个触发来明确具体发生了什么事件，后续的信息都可以从业务系统中拿到。 scale in 需要知道即将操作的组件信息。

关于action发送的数据，我有一个更通用的想法。 可以提供一个模版引擎，在 action 触发的时，渲染预制的模版，把数据发送给执行方。

@machinly 关于 scaling 这里有两个问题请教一下：

1. 所述的 scale in/out 是指增删新的 components，还是增删某个 component 内的 replicas？
2. post-start/post-provision 和 pre-stop/pre-termination 需要执行的 register/unregister、rebalance 等操作，只需要 issue commands 即可呢？还是需要等待命令涉及的数据操作完成才可以继续？

[machinly]

对于 component scale out， 现在主要瓶颈是，无法判断集群发生了什么变化，以及是否处于这此变化的最终状态。 具体来说是在服务启动成功后，脚本很难知道，这此启动是因为扩容，还是因为节点被人为重启，或者是发生了故障。
component scale 的 action 需求：

1. action 的触发需要一个明确的调用，比如 script run，web hook。
2. action 的需要的信息如下

• scale out

  • 执行前 无

  • 执行后

    • 执行的动作。

• scale in

  • 执行前

    • 要执行的动作。
    • 需要排空的 component 的编号（假设一组 component 中，每个 component 有一个编号）

  • 执行前 无

scale out 后只需要一个触发来明确具体发生了什么事件，后续的信息都可以从业务系统中拿到。 scale in 需要知道即将操作的组件信息。
关于action发送的数据，我有一个更通用的想法。 可以提供一个模版引擎，在 action 触发的时，渲染预制的模版，把数据发送给执行方。

@machinly 关于 scaling 这里有两个问题请教一下：

1. 所述的 scale in/out 是指增删新的 components，还是增删某个 component 内的 replicas？
2. post-stop/post-provision 和 pre-stop/pre-termination 需要执行的 register/unregister、rebalance 等操作，只需要 issue commands 即可呢？还是需要等待命令涉及的数据操作完成才可以继续？

我这里把增删都列了出来，但这期暂时不考虑 component 的 scale in 的情况。

1. 这个 scale in/out 指的是增删新的 components。现在的结构是 一组分片为一个 component， component 中包含了一主多从。以 component 为单位 scale。
2. 在 stop 前涉及数据搬迁的操作，需要等待搬迁结束以保证数据的一致性，可能耗时比较久。

[chengyu-l]

kubeblocks pika 现状介绍
https://meeting.tencent.com/user-center/shared-record-info?id=b11f03fd-96c7-42ec-902c-12c5b31d8b52&reload=1

[AlexStocks]

目前基于 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 创建异常

#2411

pika-group Component 的名字由数字变为了随机字符串。