Kalm——基于 Kubernetes 的部署工具

大家好，我是 Kalm 的工程师 David。Kubernetes 正在成为运维的实事标准。Kubernetes 标准化了基于容器的运维，但同时也提高了团队使用 Kubernetes 的门槛。我们开发了 Kalm，一套开源的基于 kubernetes 的 Devops 工具，目的在于：

1. 简化安装，集成 Kubernetes 周边常见的组件，提供便捷的流量管理、证书、单点登录、权限控制等功能。

2. 提供 Web UI 来降低团队成员上手 Kubernetes 的难度。

3. 让开发工程师能简单快速的融入部署环节，有利于技术路线的正确选择，方便调试和排错，提高迭代效率。

4. 使运维工程师更专注于底层基础设施和自动化流水线，避免成为专职救火队员。

写给谁？

如果你的公司已经有相当规模的专职运维工程师和完善成熟的内部工具链，kalm 可能并不适合你们。不过十分欢迎你们指正文中观点，提提建议。

如果您感兴趣 Kubernetes 周边的技术， 或是以下任何以下一条正在困扰着你：

• 你们想要切换到 Kubernetes，但是担心迁移成本，犹豫如何迁移

• 你们对自己运维环境并不很满意，想要提升自动化水平和改善运维和开发之间的合作效率

• 你们已经开始做一些内部的运维工具来提升效率，担心今后的维护成本

那么请花上 5 分钟，往下看几眼，Kalm 也许可以帮到你们。

开发和运维

开发工程师和运维工程师的工作之间有一个显著的边界。开发人员主要关注在如何构建符合 12-Factor 的应用，他们负责的产出依赖清晰，配置标准的程序。运维工程师则关注于如何部署和维护这些程序，并且负责维护基础架构设施。开发团队和运维团队生活在两个不同的世界，而彼此又坚守着各自的利益，所以在这两者之间工作到处都是冲突。

并且在某些团队中，开发和运维可能是同样一批人，虽然这种方式没有了人员之间的冲突，但是工作方式上的隔阂依然存在。那这部分工程师的体验是前一天还在开发团队中跟随敏捷的开发节奏，后一天又要以传统的方式像消防队员那样维护这些系统，这种在两种工作氛围的切换会令人十分沮丧。

DevOps 与 Kubernetes

为了解决上述的矛盾，Devops 的概念也因此逐渐兴起——以业务敏捷为中心，构造适应快速发布软件的工具和文化。在 DevOps 的流程下，运维人员会在项目开发期间就介入到开发过程中，了解开发人员使用的系统架构和技术路线，从而制定适当的运维方案。而开发人员也会在运维的初期参与到系统部署中，并提供系统部署的优化建议。

DevOps 是敏捷的概念在 IT 工作部分的延伸，是一个方法论，因此并不存在一个软件或者工具让你轻松 DevOps 的所有优点。真正想要实践 DevOps 的团队都会根据自己团队的特定情况，结合产品特点，采用合理的方式来实践自己对 DevOps 的理解。遵循行业标准是是大家实践中避免弯路的好选择。

容器和 Kubernetes 出现之前，我们依然可以通过虚拟机也可以实现广义上的 DevOps 建设，只是相对速度较慢。容器的出现，为 DevOps 工具层面的落地提供非常好的承载平台。好比是在 3G 时代，手机流量又贵又慢，大家对各类直播也不会有兴趣。但是 4G 就完全改变了游戏规则。如今的运维环境中，容器、微服务都几乎成为了标配。Kubernetes 更是很多团队的不二选择。Kubernetes 进一步封装了底层的资源，让很多的运维工作可以通过声明式的配置来完成。

问题

基于容器和微服务的运维方案正优势正在逐步体现，Kubernetes 正在成为基于容器运维的实事标准，但也更复杂更难学。是这让开发工作和运维工作之间的距离变得越来越远，合作的难度也在加深。

如果你想要在 kubernetes 中完成一个 Deployment 的部署，表面看来你只需要写出一个 yaml 文件，但也正是这个 yaml 体现着开发和运维之间的割裂。作为一个开发工程师，你只关注其中 containers 这部分如何添加一个进去。但是想要这个部署真正跑起来，还需要运维工程师帮你完成 volumes，考虑 pvc 用哪个，背后绑的 pv 是哪个；是不是还需要注入一个 sidecar container？

问题 1：如何让开发工程师不需要详尽的了解运维细节，就可以搞定大部分部署工作？

即使有了 Kubernetes 这样的工具仍然不够，还需要一些自动化的脚本或 CI 工具将各个部分整合粘在一起。伴随着自己的业务需求和运维习惯，大家还会不可避免的开发一些内部工具来进一步提升工作效率。这些内部工具就脱离了标准的指导，可以说是五花八门。举一些例子：例如有的团队为了方便管理权限，自己封装了更便捷的 RBAC（Role base access control）；有的则是为了快速发布任意 branch 的代码到一个隔离的测试环境，整合了从 git webhook 到 kubernetes 配置生成，再到 api gateway 这一整套的逻辑到单一系统中。

问题 2：如何能能集中精力在自己的产品上，避免过度开发和维护内部运维工具？

解决办法

我和自己的开发团队完整的走过了这些步骤，封装了自己的工具，体会到了价值，也感受到了难度。我认为应该不止我们一个团队遇到了这些问题，也许我们的解决方案可以帮助到其他人。所以我们开源了 Kalm。

Kalm 在整个开发链条中处于 CI 之后，基础设施之上。和 CI 通过 webhook 对接，依赖 Kubernetes 工作于计算资源之上。

Kalm 以CRD和Operator的模式存在于 Kubernetes 中。

Kalm 提供了

• WebUI：提供一套方便操作的 WebUI，可以创建、修改部署，更改网络接口，修改环境变量、配置等等操作

• 授权与验证：单点登录，提供基于身份的权限管理。

• https 证书：全自动的 https 证书（支持通配符证书）申请、更新。

• 流量管理：可以配置多域名（支持通配符）到暴露接口的服务，灵活的配置转发规则（路径，强制 https，请求方法过滤、CORS 等），可以实现蓝绿发布或灰度发布。

• 回调接口：可以通过 webhook 来更新或者回滚各个部署，轻松与各种 CI 工具集成对接。

联系 Kalm

Kalm 项目开源托管于https://github.com/kalmhq/kalm。

欢迎任何对此项目感兴趣的朋友联系我，可以一起讨论、预约 demo 等等。

邮箱：david@kalm.dev