初探云原生私有化容器云平台

本文的主要目的是分享一些企业在私有化场景下关于容器化改造方面的经验，这也是我们站在平台提供者的角度和业务方交流沟通后的一些思考，希望能够对大家有所启发。

传统企业的技术变革之路

随着互联网的飞速发展，很多企业都希望可以在这个快速变化的商业时代追随潮流的步伐，迫使其 IT 系统需要转型以应对与日俱增的商业压力。

一些传统类型的企业对高可用有非常严格的要求，在应用变更和发布方面有着严苛的控制流程，从项目立项到最后投入生产会经历一个漫长的周期，交付效率无法应对业务快速迭代的压力。而互联网企业必须支持敏捷开发，通过快速迭代实现对产品需求快速变更的支持。借助 DevOps 工具，从提交代码、单元测试、集成测试到持续部署可以在短时间内自动完成，从而面对业务需求的快速变化。因此，如何借鉴互联网企业的经验和能力实现敏捷开发，往往是传统型企业的探索方向。

传统企业的技术架构也在持续变革，从直接使用物理机转换到虚拟机部署应用，虽然提高了服务器的资源利用情况，但是由于虚拟机在快速部署、一致性保障等方面能力的缺乏，仍然满足不了云原生时代业务快速创新的需求。而容器技术拥有比传统虚拟化方法更高的性能和效率，可以快速地在多节点集群中实现实例的快速伸缩和迁移以满足业务需求。开发者将应用打包到一个可移植的容器镜像中，再发布到任何运行容器的节点上，就可以达到“一次编写，到处运行”的效果。在云计算逐渐成为传统行业 IT 基础架构的选择时，应用向云原生迁移成为企业数字化转型的利器，利用 Docker、Kubernetes 、Service Mesh等项目构建私有云或混合云的云原生平台正在成为业界的主流选择。

容器云平台

作为云原生架构的重要载体，容器的易用性和可用性需要得到足够的保障，原生的 Kubernetes 虽然可以做到生产级别的业务保障，但作为一个业务平台来使用还是显得太单薄。一方面，作为一个平台系统，还需要权限管理、镜像仓库、日志、告警等功能来支撑管理和运营相关的工作；另一方面，一个优秀的业务平台需要界面化、高可用等各方面的技术投入和保障。而要把 Kubernetes 建设成一个企业级平台，需要的大量资源投入。不过幸好，在云原生迅猛发展的今天，各大厂商都投入了大量的精力建设容器云平台，我们无需重复建设，有很多种现成的方案可以选择：

公有云容器平台

对于可以把业务放在公有云的用户，直接使用云厂商提供的云服务是最佳选择。一方面可以省去自行建设带来的硬件、软件成本，另一方面云服务产品的用户体验和可用性保障也往往是自建集群难以达到的。并且云丰富的IAAS资源，可以补齐容器业务在存储、负载均衡、数据库、消息通道等各方面的不足，极大地拓展了容器的应用场景。

使用公有云产品的另一个好处是，伴随着行业的迅速发展，各种云原生理念正在快速落地，各大厂商都在加快 Service mesh、Serverless 等热门技术产品化，用户投入少量的成本，既可以得到可靠、好用的业务管理平台，跟随云厂商一起在主流的技术方向上持续迭代。

私有云容器平台

对于不能在公有云部署服务的企业，在做架构容器化转型时会考虑使用私有云容器平台。它具有更高的灵活性和可扩展性，支持自定义云环境以满足特定业务需求，比如在不改变业务方原有网络结构的情况下部署容器。同时私有化部署可以与企业云中其他平台、基础设施打通，更方便地进行统一管理。

私有云部署在企业防火墙内，数据放置于本地数据中心，可以极大的保障安全性问题。银行、政企、金融这种对安全监管有要求的行业也会选择私有云容器平台来部署他们的服务。

混合云容器平台

部分业务方拥有自己的 IDC 集群，往往会根据企业需求，将敏感和稳定的业务部署在私有云容器平台，将常规和动态变化的业务部署在公有云容器平台。通过将公有云和私有云进行混合与匹配，以获得最佳使用效果。比如很多车厂在做车联网：汽车在采集到的各式各样的数据后，都会优先上传到公有云中进行处理，再交由私有云进行汇总。

使用 Service Mesh 等云原生技术也可以方便地将混合云容器平台管理的服务打通，在保证安全的同时提供混合云场景下服务级别的通信与治理能力，将混合云容器平台打造成一个真正的云原生平台。

容器平台应该具备的能力

把业务迁移进容器云平台并不是一件容易的事，因为 Kubernetes 目前只对微服务、无状态应用足够友好，所以如果用户原来的业务架构存在 All in One、写死配置等耦合性高、有状态的情况，用 Kubernetes 来部署业务会带来很大的改造和适应成本（当然收益也会非常可观）。你的应用需要一定改造才能成为一个合格的微服务架构，例如将单机多业务进程应用改造为一个容器一个业务进程，将IP调用改为域名，服务名调用等等。此外，开发者也需要适应制作镜像、服务编排等新的开发部署模式。

然而在实际的场景中，用户往往还面临着存量业务无法改造，需要原架构、原配置迁移的场景，这就要求容器平台需要有兼容存量业务的能力。这里主要分为两个部分:

1. 对传统业务架构的支持，这就要求容器云平台能力提供富容器模式、容器网络与 node 节点在同一网络平面、IP 预分配、IP 随实例迁移等等特性。

2. 对传统运维习惯的兼容，例如故障不迁移、Pod 原地升级、一个Workload内灰度发布、多版本发布、不重启发布等特性。

此外，一个好的业务平台还应该具备对其他系统兼容、简化开发部署等方面的能力，主要为以下几部分：

1. 对接其他系统的能力，例如对接用户已有的权限认证系统、负载均衡、存储系统、消息通道等等；

2. CI/CD 工具，这在容器化的业务场景下为强需求，否则容器业务难以做到敏捷开发；

3. 提供常用组件简化安装的工具、服务编排能力，通过这些工具用户可以借助公司内部、开源社区的力量，实现低成本部署应用。

业务容器化的注意事项

我们发现，新用户在使用容器时，会碰到大量的实际问题，导致业务管理举步维艰，为此，我们针对常见的问题总结了如下优化策略：

◆ 优化镜像大小：减少镜像分层、合理的镜像分层可以大大提升镜像的构建和拉取效率。另外，应该尽量避免把业务数据和配置放在镜像中，避免镜像过大和频繁更新镜像。

◆ 数据清理机制：Kubernetes 的 node 节点往往承载了多个业务容器，可以通过 logrotate 等日志管理工具设置日志清理规则，避免日志爆满导致节点异常。容器化的业务往往需要统一的日志平台来汇总和分析日志，可以通过filebeat等日志采集工具将异常日志实时发送到日志系统中进行分析处理。

◆ 合理调度规则：跨节点Pod在通信时会有较高延迟，通过 affinity&anti-affinity 将频繁交互的 Pod 调度到相同节点上运行，以减少因网络通信而带来的性能损耗。还可以将相同工作负载下的Pod调度到不同节点运行，来提高HA 。

◆ 重点应用保障：不同于检测 CPU、内存等物理指标，配置 readiness probe 和 liveness probe 来检测业务级别的健康程度更能说明应用的运行状态。同时业务方重点应用需要支持数据容灾，可以通过备份核心数据库和 etcd来避免数据丢失。另外要做到管理节点挂掉，对应用无影响；计算节点挂掉，应用跨机迁移，从而实现高可用架构。