微众开源 Dockin：自建 K8s 不易，开源可帮助有同类需求的企业

云原生技术生态发展至今，越来越多的企业从传统集中式架构转移到基于 K8s 的微服务架构，享受容器技术带来的技术红利。国内以阿里云、腾讯云、华为云等大厂为代表的公有云厂商也陆续推出了各自基于 K8s 的公有云平台迁移方案，帮助传统企业与中小型互联网公司快速使用基于 K8s 的公有云服务，从而降低自建服务器带来的开发运维成本。

尽管市场上已经有不少公有云厂商提供的 K8s 迁移方案，但对于一些政府或金融机构来说，受限于业务数据的敏感性，难以将后端系统托付到公有云厂商手中，这就导致很多政企和金融机构仍然将业务系统停留在传统的集中式架构，服务器采用自建私有云的方案。而想要在私有云上实现基于 K8s 的架构迁移，则会在技术人力或采购成本方面遇到诸多的难点。

微众银行作为一家拥有互联网属性的银行，在业内以技术见长，其内部基于 K8s 的私有云技术架构一直让我们颇感好奇。近日，微众银行将内部自建私有云 K8s 容器平台的项目 Dockin 开源。借此机会，我们邀请到了 Dockin 项目负责人、微众银行容器平台工程师陈广镇接受我们的采访。受访嘉宾与我们分享了微众银行内部的技术架构变迁以及云原生容器技术在国内金融业务中的落地实践，同时还对大家关心的 K8s 放弃支持 Dockershim 事件造成的影响表达了自己的观点。

以下是采访内容：

微众银行是从什么时候开始迁移到基于 K8s 的容器架构的呢？能否为我们简单介绍一下微众内部的技术架构发展史。

微众银行在成立之初，就非常有前瞻性地确立了内部的 IT 基础架构的方向：摒弃传统的基于商业 IT 产品的集中架构模式，走互联网模式的分布式架构，应用按子系统划分，较早实现了服务化。但当时还是基于虚拟机部署，资源交付周期较长，新业务上线资源需要预留，无法完全自动化。从 2018 年底，微众银行中间件平台团队研发了基于 K8s 的容器平台，支持业务应用进行容器化。容器平台满足了多 IDC、多 K8s 管理的需求，应用进行了标准化，研发了 API 网关，屏蔽了底层的 K8s，对上游提供最简化的协议，服务调用也开始向微服务转型。

我们知道，很多公有云服务商都提供了完整的 K8s 迁移方案，而银行这类业务通常对数据安全性拥有极高的要求，因此很难直接把整体业务迁移到公有云服务商手中，这也是很多地方中小型金融机构仍维持传统系统架构的原因之一。那么对于私有云来说，要部署容器化的云原生系统有哪些难点？微众在私有云容器化的过程中踩过哪些坑呢？

这是一个很好的问题，确实金融 IT 上公有云会遇到监管的问题，因此不少的金融机构还是将核心系统保留在私有云上，应用系统还是停留在传统的集中式的 IT 架构。在私有云上想要实现云原生的容器化会遇到很多的难点，对开发运维的挑战也更大，通常在容器化的早期阶段，成本相较于改造前是直线上升的。其中难点包括基础设施和传统 IT 开发运维人员的思维转变等，具体来说有以下难点：

• 云原生基础设施缺失
• 企业级应用高可用要求
• 极低的故障容忍度
• 开源软件维护成本高
• IT 历史包袱
• 开发运维人员的思维转变

微众银行的容器化采取的是折中的策略，先实现一套由 VM 应用进行容器化的平滑过渡策略，先让应用系统容器化，再通过平台层的优化，逐步朝云原生方向发展。将 VM 应用过渡到容器的这套应用管理系统未来将会开源。

当然，我们在全面容器过程中也踩过很多坑，比如监控的准确性问题、容器稳定性问题、K8s 平滑升级问题等。我这里讲一下我们实际遇到关于系统内核的坑：

我们的金融系统还是 Java 为主，在应用容器化初成规模的时候，偶尔会出现 JVM Crash、应用在实际使用内存不多的情况下被 oom killed，这个问题发生的频率很低，也很难通过压测环境复现。后来我发现了这是一个内核的 Bug，我们不少机器是基于 centos 7.x 3.10 内核，这个版本对内核内存的统计存在问题，会产生 SLUB 分配内存失败的问题，我们通过重新编译 kubelet 和docker 解决，经过我们编译修复后的文件也会放到开源的安装包里。

也就是说，微众把自建基于私有云的 K8s 平台方案的一部分开源了出来，请问具体开源了哪些部分？外部的团队是否可以直接利用该项目目前开源的部分来自建私有云平台？

微众银行容器平台是一个组件较多的复杂系统，Dockin 当前选取了四个与行内系统结构的组件，涵盖了K8s安装、容器资源管理、网络插件、运维工具等方面。

• Dockin-CNI，一款支持固定 IP 的网络插件

多数开源的 CNI 是基于软件实现的 Overlay 组网，这种方式性能和稳定性不如直接使用底层网络。开源的网络插件大多只支持单网卡，且无法固定 IP。固定 IP、支持底层网络和多网卡是 Dockin CNI 的优势所在。

• Dockin-Ops，一套安全的运维编排服务

Dockin 运维管理系统是安全的运维管理服务，优化 exec 执行性能，支持命令权限管理。原生的 kubectl exec 无法管控用户的输入，容易由于不规范的操作引发应用不稳定，甚至侵害同母机的容器。在私有云上，Dockin Ops 是很好的运维内控系统。同时 Ops 支持场景化的运维编排，现在已提供查日志、上传下载文件等功能。

• Dockin-Installer，一套离线 Kubernetes 集群安装器

Dockin 平台安装器，快速部署 Docker、高可用 kubernetes 集群、etcd 集群，生产级参数调优。全离线安装，不需要连外网，支持十年的证书续订、自动证书轮换、etcd 备份恢复。对于私有云的生产环境，通常无法连接外网，安装 kubernetes 十分困难，高可用配置也不易实现。Installer 是一个很简单的项目，但也能够解决最有用的问题。

• Dockin-RM，一款应用资源管理系统

Dockin RM，是应用定义和容器实例管理的核心模块，提供容器资源和网络分配、回收、查询等功能。在微众银行内部，RM 用于容器应用定义、资源管理。当前开源只是适配了 CNI 和 Ops，提供简单的查询接口。后续会提供一整套应用管理规范。

总的来说，目前我们开源的组件还比较少，外部团队可以用这些组件构建自己的私有云平台，如果功能未能满足需求，可以使用一些基于 K8s 的云原生组件组合使用，也可以与原来已有的平台结合。Dockin 开源的每个组件都可以独立使用，用户可以自由搭配。

对于金融银行业来说，数据信息安全是非常重要的，Dockin 项目针对银行金融这类业务在安全性方面做了哪些特别的工作？

安全是我们非常看重的一块，是应用信息安全的保障，为此我们主要有三个方面：

一是定期升级有安全问题的开源软件，过去我们还在用 K8s v1.11.2 的时候，遇到了 apiserver 未授权漏洞，于是升级到了 v1.12.5，最近的 runc 的漏洞，我们也升级了 Docker 的版本，Dockin 开源版同样会考虑原生组件的安全漏洞问题。

二是管理平台、应用镜像的漏洞渗透扫描，除了外部公开的漏洞外，我们的信息安全部门还会对容器平台内部自研的系统、应用镜像进行扫描。

三是定制化的工具和规范。包括我们从发布平台限制了应用容器无法使用 root 用户和特权模式、限制容器内系统文件不能随意访问等。与本次开源的相关的 ops 也是我们出于安全考虑的定制化的运维工具。ops 包含了命令行客户端 dockin-opsctl、服务端系统 dockin-opserver、以及节点 agent dockin-opagent。opsctl 提供了操作终端；opserver 提供运维编排、权限控制、操作审计的功能，支持横向扩容；opagent 负责执行 opserver 下达的指令，通过 daemonset 的形式部署。目前 ops 支持安全功能有，执行用户权限管理、执行命令限制、安全的文件上传下载功能、安全的日志查询功能、安全的文件管理功能。通过 opsctl 执行的每一个指令都有审计日志。

Dockin 控制着容器的生命周期、权限和隔离，体现在 CI/CD、应用部署和运维、应用回收各个环节，未来还会研究独立内核的安全容器、数据脱敏、安全画像等。

我们注意到，很多公有云厂商开源各自的 K8s 平台项目有一部分述求是出于公有云服务市场推广的需要，那么 Dockin 作为一个自建私有云平台的项目，团队将其开源出来是出于哪些方面的考虑？是否有长期维护的规划呢？

我们都知道，私有云容器化落地比较困难，改造成本较高。不同的企业容器化过程中遇到的问题多很多是类似的，开源可以为后来者提供系统组件或方案参考。

Dockin 是微众银行对私有云容器化的探索的成果，经过严苛的生产环境验证，开源可以给有同类需求的企业帮助，为云原生技术栈的发展贡献微众的解决方案。同时，我们期待通过开源让 Dockin 得到更多场景的验证，Dockin 的用户能给我们提 issue 反馈问题，甚至参与到项目里，共同完善，这是我们开源最大的价值所在。

微众银行的云原生进程还在继续，不断有新的需求、新的场景出现，Dockin 项目也会跟随行内的演进持续迭代。当前开源的只是一小部分，后面还会陆续开源其他的模块，这是一个长期维护的项目。

目前还有哪些部分没有开源出来？将来是否会全部开源？

当前开源的四个模块都是比较独立的，可以单独使用且需求比较普遍。未来有开源的组件包括 Dashboard、应用管理套件、镜像管理系统、监控服务、智能调度系统以前 Operator 套件。这些都是 Dockin 生态的一部分，解决不同场景的问题。

总的来说，除了和微众银行内部系统强耦合的模块代码外，其他都会陆续开源。不过我们团队还比较小，主要精力还是在完善内部生产环境容器平台上，开源人力有限，新组件开源上线周期会比较长。同时我们团队也会考虑社区的反响，开源的组件会随需求的变化而调整，优先在通用的需求上投入人力。

据悉，Dockin 目前仍采用 Docker 作为容器运行时，而前段时间 K8s 官方宣布将在未来放弃支持 Docker 作为容器运行时，能否谈谈您对这件事情的看法？这对 Dockin 项目以及微众自身的微服务架构带来了哪些影响？之后会采取哪些应对举措？

K8s 放弃 Docker 实质上是不再维护 Docker API 与 CRI 的适配器 Dockershim，我认为这个是可以理解的，K8s 使用 Docker 作为运行时并没有使用 Docker 的所有功能，用到的功能完全可以通过支持 CRI 的 Containerd 实现，引入了 Docker 反而使调用链变得更长，查问题更困难。举个我们遇到的实际例子，生产中遇到 Pod 处理 Terminating 关不掉的问题，后面分析出是由于 Dockerd 与 containerd 状态不一致引起的。如果绕开 Docker 直接使用 containerd，就不会出现这种问题。

Dockin 当前开源的 K8s 版本基于 v1.16 构建，这个版本仍默认使用 Docker 作为运行时，后面的版本也会跟随 K8s 社区修改容器运行时，我预计首选的是 Containerd，从 Docker 迁移到 Containerd 对应用几乎不需要做改造，由平台改造支持即可。微众银行当前已研发了一整套的容器化方案，CI/CD 工具、容器平台都屏蔽了底层容器 Runtime，更换运行时可以应用无感，对服务架构无影响。即使我们在生产环境不再使用 Docker，Docker 仍然可以用于本地开发、构建管理镜像。

自项目开源以来，Dockin 社区的运营情况如何？项目团队接下来的重点工作规划有哪些？

Dockin 开源差不多两周了，项目受到比较多关注，当前已在 Github 和 Gitee 两大平台开源，主要通过微信社区群解答大家一下关于项目介绍、组件使用、云原生应用的问题，也在引导用户在平台提 Issue。因为人力有限，我们当前开源的组件和文档还有很多不完善的地方，团队接下来的重点工作在完善项目文档、规划 Roadmap、用户答疑和意见收集。对于已开源的组件，持续迭代，增加微众银行内部已上线的特性。对于待开源的组件，筹备开源流程和时间表。

受访嘉宾介绍

陈广镇，Dockin 项目负责人，微众银行容器平台后台开发工程师。

Dockin 详细信息：点击查看

Dockin 下载地址：点击下载