架构分析：「转转云平台」的 Kubernetes 实践
我主要从实现层面来介绍 K8s 在转转的实践。本着让 rd 无感容器相关概念的原则，转转云平台主要包括镜像管理、发布升级、容器监控、日志收集四个部分。
总体架构
这是转转云平台架构图，其中包括组件镜像存储、日志收集、K8s、服务治理、NG 治理、监控等，云平台统一管控这些组件。如图所示，云平台屏蔽以上组件，让 rd 无感，减少复杂性，学习曲线平缓。
功能流转
这幅图是云平台的结构关系，该图包含了用户行为和数据流转关系，属于系统的反馈回路图。
从左边来看，rd 通过 CI/CD 平台编译部署，通过日志平台查询日志，通过大数据收集平台配置日志收集信息，最后这些平台统一和云平台交互，由云平台统一管理和 K8s 的交互，而其他系统与 K8s 无耦合。如图所示，云平台负责镜像编译、发布升级、日志收集等功能。
镜像管理
镜像管理的目标是让 rd 对 Dockerfile 无感，减少学习成本。由于容器之前，编译系统有现成的编译产物，我们选择直接复用，来减少 CI/CD 开发成本，同时也能提高编译性能。
对应实现方案为应用分类（ZZJAVA、ZZWEB、WF），这样每种技术栈类型对应一种基础镜像，也就是各自对应相应的启动脚本，做到用户无需感知 Dockerfile。物理机编译产物+CMD（启动命令）就和物理机应用无异，做到物理机编译产物直接复用到容器中。
对于容器编译的执行过程，我们把编译镜像的程序以 pod 的形式部署到 K8s 集群运行，天然继承 K8s 的优势，做到分布式编译，以此打破性能瓶颈。
下面看一下镜像管理的流程交互图。如上图，rd 通过 CI/CD 编译工程，按原有编译流程执行编译，产物推送到 FTP 服务，然后利用云平台能力产生编译 pod，最终编译镜像程序在编译 pod 中编译镜像并推送到镜像仓库（Harbor）。下面是云平台的 Dockerfile，业务镜像输入参数是编译产物 url 和服务名称，而编译镜像的 Dockerfile 的本质就是用 Docker client 在 pod 中进行 docker build，这样编译镜像程序本身也能享受到隔离且编译后自我清理中间产物的优势。
发布升级
对于发布升级，我主要讲两个点：
- 转转发布技术的演进，包括 Deployment 控制器和转转自定义控制器
- 不同应用类型服务的实现细节，包括 rpc 服务和 Web 服务
通用问题
Deployment 控制器使用过程中重点考虑的通用问题包括：cpu 如何超分、超分会出现什么问；ready 检查如何做；亲和策略怎么选择；以及针对不同服务类型的具体实现是什么等。
CPU 超分
CPU 超分的目标是让重点集群控制 CPU 超分比例，以此保证重点集群机器性能。
实现方案：保证重点集群性能就要控制其他非重点集群不调度到对应机器，所以本质来说是对宿主机集群进行分类。具体来说，就是为宿主机打不同的 label，部署的时候使用 NodeSelector 去匹配相应的宿主机，同时控制 CPU request=limit*设置比例，做到宿主机超分比率控制。
ready 检查
ready 检查的目标是，在 pod 在滚动升级时保证新启动容器进程可以提供服务，避免新容器出现问题时全部替换老容器，导致服务不可用。
实现方案：对于 Web 服务来说，访问 health 接口返回 200 认为 ready；rpc 服务判断端口启动成功即可，我们的 rpc 服务保证端口暴露时注册到服务治理服务。
亲和策略
亲和策略的目标是将同一个集群 pod 调度到不同宿主机，防止宿主机 crash 导致整个集群不可用。
实现方案：podAntiAffinity 技术。
rpc 服务
rpc 服务遇到的挑战：
- 转转 rpc 支持节点分组；
- 服务治理联动。
实现方案：针对分组配置节点数，rpc 框架改造支持分组发现，云平台支持针对分组部署，具体分组发现依靠 env 中的分组 id。
Web 服务
Web 服务遇到的挑战：
- Web 服务没有注册中心 ；
- Nginx 如何自动上下线。
实现方案：利用容器的生命周期控制 Nginx 上下线，实现 Nginx 服务化，即在 Nginx 上提供服务上下线接口。这样在容器 prestop 时下线 Nginx，readyness 时上线 Nginx，做到容器自我管理上下线 Nginx 功能。
自定义控制器
使用 Deployment 控制器会遇到 IP 漂移、日志丢失、kubelet 不支持 subPath 等问题。我们自定义控制器是为了方便开发，直接重写 RC 控制器，复用 pod，解决 ip 漂移和日志丢失问题。我们还重写了 emptyDir 实现 subPath，解决相同集群调度到同一机器日志冲突问题。
自定义控制器的实现
这幅图是 K8s 控制器流程图，经典的 list/watch 模型。
我们重写 RC 的逻辑也比较简单：监听 Replication、发现 image 版本变化，直接替换 pod 的镜像版本，做到本地升级。但也有例外情况，如果 cpu、内存、env 等发生变化，我们就更换 pod。
容器监控
关于云平台的监控，我们也经历了几个版本：从 Heapster 到 Metrics-server，最后直接使用 Prometheus 抓取 cAdvisor 数据。这里有个小细节，Prometheus 抓取 cAdvisor 数据没有 IP 和 pod 关联关系的数据，是需要处理的。
容器监控示例
这幅图是转转的容器监控，可以看到相应 pod 的宿主机以及自身性能数据。
日志收集
日志收集遇到的问题：
- Java 技术栈日志一般不往 stdout 打印，有自己的日志框架，而且是多文件的，比如 info、warn、error，这点和 Docker 设计有些出入 ；
- 日志量很大 ；
- 日志丢失 。
我们的应对方案：日志使用 hostpath 直接打到宿主机，解决丢失问题，然后使用异步收集解决量大问题。所谓异步收集是指宿主机上有专门的 agent 读取 Docker 启动/销毁事件，进而生成 flume 配置文件，做到收集日志和云平台解耦。