基于kubernetes的本地个性化开发集群

Status: In progress

1.背景

当我收到一个开发任务，较多的时候总是在干一个事情：配置项目启动环境、本地调试、远程调用。

这令我头疼，因为想要减少这种port forward生活。

网上有开源的解决方案，企业级？

可别了，个人电脑实在经不起摧残？

有人说：你为什么不用开发环境啊？

我承认，开发环境能够满足80%的工作需要，但是当你想要或者动了高玩的念头，那么开发环境将是一道坎，你不了解kubernetes下动态配置、多副本 怎么谈高玩呢？

换句话说，逐渐变为了被动方。

如果生产环境低可用，自然有运维大佬维护。

如果开发环境低可用，自然也有运维大佬维护。

总结：大佬，快来维护！！

---

武汉暂居的时光里，品茶，悟道，不觉已然空杯。

最爱人间烟火色，难留岁月几许风。

窗外，绿树成荫，偶有微风轻拂。

闲暇之余，总会追忆起曾经那位意气风发的少年。

---

2.核心痛点

1. 逐渐脱离底层组件掌控｜个人偏见：是好事也是坏事。
2. 开发环境不满足个性化需求。
3. 开发环境不能（不敢）大手大脚破而后立。｜其它同事也在用。
4. 开源解决方案功能太过冗余｜资源占用太高。
5. 组件预研需求。
6. docker compose无法直接代理服务名。
7. 当前现状不满足心理需求✅。

3.需求

1. 灵活拓展多副本。
2. config less。
3. 启动脚本简化。
4. 轻度封装。
5. 低资源。
6. 最新版本｜版本可控。
7. 灵活编排。
8. 统一网关｜kt-connect｜apisix｜预研
9. 为后续架构选型打基建。

4.组件

4.1.zookeeper

4.1.1设计目标

1. 动态配置，无需修改配置文件实现n节点自动扩展（扩容｜缩容）。

4.1.2设计原理｜特性点

1. 主要参考官方文献**ZooKeeper Dynamic Reconfiguration**
2. config map中配置文件dataDir 随意修改，自动创建目录（但需要自己调整持久卷）。
3. config map中配置文件dataLogDir 随意修改，自动创建目录（但需要自己调整持久卷）。
4. myid 自生成，使用者无需关心和手动配置。
5. server.X 自生成，使用者无需关心和手动配置。
6. 其它参数自由修改和自由拓展。
7. 内存优化封装，一般无需修改。高玩党请修改源码或者覆盖环境变量。
8. 网络的名称为zookeeper-service ｜强制不可修改，特殊需求修改源码自由封装。

4.1.3 细节解析

1. 待编写。

4.2.kafka

4.2.1设计目标

1. 动态配置，无需关注底层zk副本，实现n节点扩容缩容。
2. 内存占用优化。

4.2.2设计原理

1. config map中配置文件log.dirs 随意修改，自动创建目录（但需要自己调整持久卷）。
2. broker.id 自生成，使用者无需关心和手动配置。
3. todo listeners 和 advertised.listeners
4. 其它参数自由修改和自由拓展。
5. 内存优化封装，一般无需修改。高玩党请修改源码或者覆盖环境变量。

4.2.3细节解析

1. 待编写

4.3 hadoop