本帖最后由 test 于 2021-2-3 19:19 编辑
云原生技术生态发展至今，越来越多的企业从传统集中式架构转移到基于 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 平台方案的一部分开源了出来，请问具体开源了哪些部分？外部的团队是否可以直接利用该项目目前开源的部分来自建私有云平台？
| 
