亿级音乐服务容器化实践

作者：李乾坤

来源：qiankunli.github.io/2021/08/02/kubernetes_xima_practice.html

喜马的容器化历程伴随着公司的发展，并带有很深刻的喜马的烙印：

• 以 Java 项目为主；

• Java 项目主要分为 Web 项目和 RPC 项目（基于公司自研的、类似 Dubbo 的框架）；

• 发布平台、RPC 微服务框架、网关自研。

在这个过程中，我们坚持了一些原则：

• 开发不用写 Dockerfile，即开发不需要懂容器相关知识；

• 测试环境下，开发的电脑可以直接访问容器，即 IP 可以互通。在任何环境，容器集群的物理机上的容器可以和其它物理机 IP 互通；

• K8S 分为 Test、UAT、Product 三个环境，项目配置分为跟环境有关的部分和无关的部分，发布系统及项目信息 DB 部署在测试环境，发布系统可以跨环境访问 Test、UAT、Product 的三个 K8S 集群；

• 项目启动失败后，保留现场，不要一直重启。

如何让开发发布代码到容器环境

2016 年底，我在 Jenkins 机器上安装了 docker，制作一个基于 docker 的项目模板。开发克隆 docker  项目模板，更改源码地址、CPU、内存等配置，由 Jenkins 触发 shell 脚本：

• Maven 编译项目得到 war/jar 包；

• 根据 war/jar 拼装 Dockerfile；

• docker build 制作 docker 镜像并 push 到镜像仓库；

• 调用 marathon 发布指令。

当时大概用了 5 天时间搭建了组件，跑通了所有步骤，我们的容器化事业就是从这个最low 的版本开始发展起来的，后来逐步做了以下演进：

1. 从 marathon 逐步迁移到 Kubernetes。在过渡时期，我们自己实现了一个 docker  发布系统，对外提供发布接口，屏蔽 marathon 和 Kubernetes 的差异；

2. 实现了一个命令行工具 barge。开发在项目文件中附加一个 barge.yaml 文件，里面设定了项目名等基本配置：

• 开发只需 barge deploy 便可以发布项目，barge exec -m $projectName 便可以进入容器内调试代码；

• 使用 Google jib 框架基于代码直接制作 docker 镜像，免去了开发电脑上装 docker 的要求，此外也将代码编译、镜像制作过程分散到了每个开发的电脑上，绕过了 Jenkins 单机负载的瓶颈；

• 镜像仓库 harbor 的单词 含义的是海港（对应容器的集装箱）。大船是没办法直接开到海港的，到港口后要靠接驳船弄进去，接驳船英文是 barge，所以给项目起名叫 barge， 形容给 harbor 送镜像。至今仍很得意这个命名。

与公司的发布系统对接（类似阿里云），屏蔽物理机与容器环境的使用差异。

一个容器要不要多进程

容器世界盛行的理念是：one process per container。但容器在最开始落地时，为了降低推广成本，减少使用差异过大（相比物理机）给开发带来的不适应，需要在容器内运行ssh，实质上要求在容器内运行多进程，这需要一个多进程管理工具（entrypoint不能是业务进程），最终在 runit/systemd/supervisor 中选择了 runit。

此外，Web 服务每次发布时 IP 会变化，需要让 Nginx 感知到 Web 服务 IP 的变化。我们在每个容器内启动了一个 nile 进程，负责将项目信息注册到 ZooKeeper 上。使用微博一位小伙伴开源的 upsync 插件，并改写了部分源码使其支持了 ZooKeeper（upsync 只支持 etcd 和 Consul），进而使得 Nginx 的 upstream 可以感知到项目实例ip的变化。后来在另一个场景中，Nginx 改用了其它插件，我们将实例信息写入到 Consul 上即可。

随着 Kubernetes 的铺开，我们使用 gotty + kubectl exec 逐步推广了在浏览器上通过Web console 访问容器。专门的网关系统也投入使用，HTTP 访问由 nginx => Web服务变成了 nginx => 网关 => Web 服务，网关提供了 Web 接口同步 Web 实例数据。ssh 及 nile 进程逐步退出历史舞台。目前，我们的 entrypoint 仍是 runit， 并对其做了微调，当业务进程启动失败时，不会重启（如果 entrypoint 是业务进程时则会频繁重启），以保留现场方便开发排查问题。

健康检查的三心二意

Kubernetes 有一个 readiness probe，用来检测项目的健康状态，上下游组件可以根据项目的 健康状态采取 相关措施。在 readiness probe 的设置上，经过多次改变：

1. 每一个 Web 项目会提供一个 /healthcheck 接口，/healthcheck 通过即表示项目启动成功；

2. 后来发现，对于 RPC 服务，/healthcheck 有时不能表示项目启动成功，需要检测RPC 服务启动时监听的端口是否开启；

3. readiness probe配置（HTTP 和 TCP 方式任选）加大了业务开发的配置负担，经常出现配置不准确或中途改变导致 readiness probe 探测失败，进而发出报警，业务开发不胜其烦，我们也非常困扰；

4. 于是将 readiness probe 配置为 exec 方式，由 nile 根据项目情况自动执行 HTTP 和 TCP 探测，但仍然依赖项目配置信息（比如 RPC 服务端口）的准确性；

5. 基于“RPC 服务场景下，/healthcheck 接口成功，但 RPC 服务启动失败 的场景非常的少”的判断，我们将 readiness probe 改回了 HTTP /healthcheck 方式。

liveness 起初是 /healthcheck

1. 有一次运维改动机房网络，导致 liveness probe 探测失败（kubelet 无法访问本机所在容器 IP）。kubelet 认为 liveness probe 不通过 => livenessProbe 涉及到 RestartPolicy，大量项目重启 => 因为项目之间存在依赖关系，依赖服务失败，项目本身启动失败 => 频繁重启；

2. 后来我们不再配置 liveness probe ，仅配置 readiness probe：对于物理机损坏等场景，K8S 可以正常恢复；如果容器内存不足 导致实例挂掉，K8S 无法自动重启，这个可以通过内存报警来预防。

与发布平台对接

喜马拉雅在发布平台的实践中，为了保障线上服务的稳定，沉淀了一套自己的经验和规则。其中一条硬性规定就是：服务端发布任何项目，最开始只能先发布一个实例，观察效果，确认无误后，再发布剩余实例。在实际使用时，验证时间可能会非常长，有时持续一周。这时，Kubernetes deployment 自带的滚动发布机制便有些弱。

因此，在容器发布系统的设计上，我们让一个项目对应两个 deployment。新代码的发布就是旧 deployment replicas 逐步缩小，新 deployment replicas 逐步扩大的过程。业界有两种方案：

• 每次发布新实例，都创建一个 deployment，扩大新 deployment 数量，缩小旧deployment 数量。

• 每次发布新实例，都创建一个 deployment 作为灰度 deployment。灰度验证成功，则更新旧的 deployment。我们最开始使用的是第一种方案，缺点就是发布工作分散在两个 deployment 上，所有实例的销毁与创建速度无法控制。此外因为deployment 名字不确定，导致 hpa 配置比较麻烦。

阿里的 openkruise 实现了一个 crd 名为 cloneset，可以实现上述类似的功能，后续计划逐步替换掉两个 deployment方案 以精简发布系统代码。全新设计一个crd 也是一个很不错的方案。

此外，容器发布系统对下屏蔽 Kubernetes ，对上提供项目发布、回滚、扩缩容等接口，在接口定义上也多次反复。kubernetes client-java 库也较为臃肿，为此对发布代码也进行了多次优化。

针对开发日常的各种问题，比如项目 IP 是多少，项目为什么启动失败等，我们专门开发了一个后台，起了一个很唬人的名字：容器云平台。试图将我们日常碰到的客服问题通过技术问题来解决，通过一个平台来归拢，哪怕不能实现开发完全自助式的操作，也可以尽量减少容器开发的排查时间。比如我们开发了一个 wrench 检查组件，用来扫描 Java 项目的 classpath、日志等，分析项目是否有 jar 冲突、类冲突、Tomcat 日志报错、业务日志报错等，开发在 Web 页面 上触发 wrench 执行即可。

与已有中间件对接

喜马有自己自研的网关及 RPC 框架，最初很少考虑容器的使用场景（比如每次发布 IP 会变化）。此外，服务实例需要先调用网关和 RPC 框架提供的上线接口，才可以对外提供服务。服务销毁时，也必须先调用下线接口，待服务实例将已有流量处理完毕后再销毁。

为此我们提供了一个 k8s-sync 组件，监听 pod 状态变化，在适当时机调用实例的上下线接口。后续计划自定义 crd 比如 WebService/RpcService，由自定义 controller 完成实例的上下线及其它工作。

如何做到 Web/RPC 服务的无损上线下线？

上线

pod 配置 readiness probe 对项目的 healthcheck 进行健康检查。健康检查通过后，pod 进入ready 状态， k8s-sync 监听到 pod ready事件，调用 Web/RPC 上线接口。readiness 由 K8S 确保执行，可保证健康检查不成功不会上线。风险是如果 k8s-sync  挂了则健康检查通过的 pod 无法上线。解决办法：

• k8s-sync 容器部署，或者 systemctl 管理，挂了之后可以立即重启；

• k8s-sync 通过 Prometheus 抓取数据，配置了报警，挂了之后可以迅速通知到容器开发。

下线

K8S 先执行 pod preStop 逻辑，preStop 先调用 Web/RPC 下线接口，执行 xdcs 提供的零流量检查接口，检查通过，则 preStop 执行完毕，销毁。若项目未接入 xdcs，则等待 preStop 等待 10s 后，执行完毕。销毁 => preStop 由 K8S 负责确保执行， 正常发布/删除/节点移除/节点驱逐 都可以确保被执行，以确保服务无损。如果物理机节点直接挂了，则无法保证无损，因为一系列机制都来不及执行。

k8s-sync 同时也将 pod 信息同步到 MySQL 中，方便开发根据项目名、IP 等在后台查询并访问项目容器。随着 k8s-sync 功能的丰富，我们对 k8s-sync 也进行了多次重构。

体会

从 2016 年到现在，一路走来，容器的各种上下游组件、公司的中间件并不是一开始就有或成熟的，落地过程真的可以用“逢山开路遇水搭桥” 来形容。

1、我们花了很大的精力在容器与公司已有环境的融合上，比学习容器技术本身花的精力都多。为此我经常跟小伙伴讲，我们的工作是容器化，其实质上容器技术“喜马拉雅化”。

• 技术上与各种中间件做整合。为此开发了 k8s-sync，改造了 upsync；

• 不要求开发 docker，写 dockerfile。为此开发 barge，容器云平台等。

2、实践的过程仿佛在走夜路，很多方案心里都吃不准。为此看了很多文章，加了很多微信，很感谢一些大牛无私地交流。对于一些方案，走了弯路，兜兜转转又回到了原点。但这个过程逼得我们去想本质，去反思哪些因素是真正重要的，哪些因素其实没那么重要，哪些问题必须严防死守，哪些问题事后处理即可。

3、成长经常不是以你计划的方式得到的。

比如最开始搞 Kubernetes 落地的时候，想着成为一个 Kubernetes 高手，但最后发现大量的时间在写发布系统、k8s-sync，但再回过头，发现增进了对 K8S 的理解。

笔者 Java 开发出身，容器相关的组件都是 GO 语言实现的，在最开始给了笔者很大的学习负担。但两相交融，有幸对很多事情理解得更深刻，比如亲身接触 Java 的共享内存模型与 GO 的 CSP 模型，最终促进了对并发模型的理解。

为了大家多用容器，我们做了很多本不归属于容器开发的工作。尤其是在容器化初期，很多开发项目启动一有问题便认为是 docker 的问题， 我们经常要帮小伙伴排查到问题原因，以证明不是 docker 的问题。这是一个很烦人的事情，但又逼着我们把事情做得更好，更有利于追求卓越。比如 wrench 的开发，真的用技术解决了一个看似不是技术的问题。

4、一定要共同成长，多沟通，容器技术改变了基础设施、开发模式、习惯，尽量推动跟上级、同事同步，单靠一个人寸步难行。

最后想想，感慨很多，还是那句：凡是过往，皆为序章。