文章摘要:

随着云计算和虚拟化技术的快速发展，容器技术正逐渐成为现代应用程序部署的首选方案。对于传统企业来说，采用容器化技术可以帮助实现应用程序的现代化、跨平台部署、弹性伸缩、敏捷开发和交付，以及提升应用程序的安全性和隐私保护。这将有助于传统企业更好地适应市场变化和提高竞争力，传统企业容器化过程中,往往会面临一些互联网企业无需面对的问题。本文介绍了国内某车企容器化的选型和使用经验以及目前存在的一些痛点问题和未来发展规划。

一、项目背景介绍

1.1建设驱动力

随着企业信息化的发展，IT应用不断增加，对服务器及运维资源的需求量呈爆发式增长。利用率及效率问题也随之暴露出来，服务器及运维资源利用率、宕机故障发生率、处理及时率等方面存在很大的提升空间。早期公司借助物理机虚拟化技术，在一定程度上降低了服务器运维的复杂性，增加了资源的利用率。但应用依然面临严峻的问题:

1. 服务器利用率依然比较低、资源浪费；
2. 应用部署步骤繁杂，容易出错，应用无法标准化交付；
3. 企业开发、测试、预发、生产多环境需要重复搭建，重复调试，稳定性差、成本高昂；
4. 由于流量高峰时，无法及时弹性扩容，服务崩溃的风险性增加。

基于以上问题，我们决定引入容器技术，建设容器云平台。

建设目标：

1. 通过容器云平台对资源的智能调度，提高资源利用率，节约成本；
2. 通过引入容器云平台，推动业务应用容器化微服务化改造；
3. 通过容器云平台的CICD工具链，实现面向多环境的敏捷开发交付流程，提高交付效率；
4. 通过容器云平台应用调度、编排部署能力，实现业务应用的秒级部署、灰度蓝绿发布、自动容错、弹性伸缩。

1.2建设现状

公司从2019年引入容器技术以来，经历了多次容器平台的实施。在容器化、微服务化、Devops、容器化中间件、虚拟机容器化等领域形成了一定的基础能力。

容器平台建设现状：

1.3建设困难点

传统企业推进容器化负担较重，在容器技术在内部推广过程中碰到一系列问题：

1. 传统企业存在大量老旧系统，部分系统无法进行容器化改造（主要是Windows类）；
2. 外部采购系统占比较大，难以推进标准化，对容器平台的兼容能力挑战较大；
3. 业务系统数量非常多，对于应用的规模化治理带来一定难度；
4. 资源异构，使用5~6个公有云的基础设施，容器平台需要逐一兼容；
5. 业务开发人员对于容器等相关云原生技术比较陌生，推广比较困难。

二、容器云平台选型经验

在容器化平台选型上主要考虑：

1. 容器平台的稳定性；
2. 容器平台的易用性，对业务侧必须有统一的管理页面；
3. 容器平台的自动化能力，容器平台本身的运维成本需要可控；
4. 容器平台对于业务的兼容性，满足不同类型的业务容器化的需求；
5. 容器平台必须能够在不同的基础设施上落地；
6. 容器云平台的建设需要考虑数据安全性、访问控制等方面的问题，确保企业的核心资产和敏感信息的安全。

2.1OpenShift优势

基于以上考虑的维度，我们对比了开源Kubernetes、rancher、OpenShift等一些平台，最终选择OpenShift作为平台的基座，OpenShift具备以下优势：

1. 简化部署和管理：OpenShift提供了一套简化的工具和界面，可以快速部署和管理容器应用。它提供了自动化的应用构建、部署和扩展功能，使开发人员和运维人员能够更轻松地管理应用的生命周期。
2. 多云支持：OpenShift支持在各种云平台上部署和运行，包括公有云、私有云和混合云环境。这使得企业可以根据需求选择最适合的云平台，同时也方便了跨云平台的应用迁移和管理。
3. 强大的扩展性：OpenShift基于Kubernetes，具有强大的扩展能力。它支持水平和垂直的扩展，可以根据应用的需求自动调整资源，确保应用的高可用性和性能。
4. 安全性和合规性：OpenShift提供了一系列安全功能，包括身份认证、访问控制和网络隔离等。它还支持与现有的安全工具和流程集成，以满足企业的安全和合规要求。
5. 开放的生态系统：OpenShift是一个开放的容器平台，支持多种编程语言和开发框架。它还有丰富的插件和扩展，可以与其他开源工具和服务集成，提供更多的功能和灵活性。

三、容器化建设过程

公司从2019年引入容器技术，技术上经历了无状态业务、中间件服务、大数据类业务的容器化实现，业务上完成了从自研的Java类服务到外采服务包括（Windows）的覆盖。在基础设施环境上覆盖了从国内到海外、中心到边缘的全面覆盖。

2019~2020: 引入容器化技术，进行项目试点，通过CICD工具打通应用的部署流程；
2020~2021: 全面推广应用容器化、建设容器化中间件能力、建设Devops平台；
2021~2022: 建设微服务平台能力，引入Istio技术进行服务治理；
2022~2023: 建设大数据类服务能力、边缘数据中心场景的覆盖；
2023~至今：建设混合云场景下以容器技术为底座的混合云平台。

公司在整个容器发展过程中经历过很多，这里介绍几个我们在容器化过程中碰到的一些问题以及对应的解决方案。

3.1借助OCP CNV实现虚拟机容器化

公司内部存在大量的Windows服务，早期都是以传统进行发布运维：

1. Windows类服务编译发布还是手工方式,发布需要专人负责，效率低下；
2. Windows类服务的质品包没有有效的版本化管理；
3. 多个服务部署在同一台机器下，运行和发布过程存在风险；
4. 虚拟机业务扩容过程需要小时级别；
5. 系统内部分业务容器化之后，存量的虚拟机业务没办法统一方式管理和发布；
6. 虚拟机的版本更新、配置更新没办法同步覆盖到现有业务服务。

借助OCP CNV技术完成了虚拟机和容器的统一管理，虚拟机提供两类服务：

1. 用户可以直接在平台申请虚拟机，通过固定IP、堡垒机自动打通、域控打通等动作为用户提供虚拟机服务；
2. 基于Windows类的服务，通过流水线完成此类业务的发布，实现和Pod一样的运维管理。

（1）虚拟机和容器同等对待

（2）主机网络规划：

（3）Windows业务自动发布:

借助CNV对VM和容器的集中化管理，完成了容器平台对Windows服务的收敛:

1. 使用和容器应用相同的CI/CD工具集成和交付虚拟机应用;
2. 更好的管理虚拟机软件和应用程序的标准化、版本化;
3. 复用容器的调度、存储、网络等资源。降低基础设施复杂、度提高自动化、降低运维成本;
4. 利用容器的快速弹性和秒级扩缩容能力；
5. 健康检查机制充分保障业务可用性。

3.2实现托管OCP集群

公司内OCP集群的安装主要由基础设施提供，以公共集群方式对业务部门提供服务。此类方式存在一些痛点：

1. OCP提供了在不同基础设施的安装工具，但对于国内公有云的支持上还不够;
2. 业务的部分特殊业务需要独立的Kubernetes环境。

通过我们的调研，通过红帽提供的HyperShift 和CNV技术可以满足在不同基础设施的情况下实现OCP集群的托管。用户可以方便的拉起和销毁、运维OCP容器底座。借助此项技术，10分钟内在任何环境搭建一套OCP集群并且可以满足业务独立OCP集群的需求；

四、容器云平台建设的稳定性和安全性如何规划与实践

公司内部基于红帽StackRox产品对于容器安全进行统一管控，目前对于容器安全的建设主要分为几个方面:

1. 镜像安全（构建&部署）；
2. 运行时安全（运行时安全监测）；
3. 网络隔离（网络策略）。
   

4.1镜像安全防护

1. 统一管理业务基础镜像，定期扫描基础镜像库存，定期更新基础镜像安全漏洞；
2. 业务基于基础镜像构建出业务镜像，推送到镜像仓库，镜像仓库执行扫描任务（集成StackRox），阻断非安全镜像的下载；
3. 基于流水线构建的镜像在流水线进行扫描卡点（集成StackRox），识别出镜像或软件风险进行整改；
4. 阻断业务直接从公网拉取非授信镜像；
5. 运行时监测镜像来源合法性，对于非法镜像由安全运营人员进行识别和处理。
   

4.1.1运行时安全
通过Kubernetes SecurityContextConstraints严格控制容器内用户的权限，比如运行用户和用户组、文件系统访问权限、特权模式限制。普通业务只拥有最低级别的权限，按需申请。
通过StackRox产品对容器通过实时监测和分析容器的运行时行为，检测和防止容器中的潜在威胁和漏洞，包括恶意代码、容器逃逸、容器漏洞等。

4.1.2网络安全
落地OpenShift平台时，严格限制业务的网络访问。

1. 通过networkpolicy管控租户之间的网络隔离；
2. 严格管控公网访问，通过egress gateway实现按需的公网访问；
3. 通过StackRox监测和记录非法的网络请求；
4. 限制容器镜像中curl、wget等网络工具的安装；
5. 非法端口暴露监测，比如22等高危端口。

4.1.3应用安全

1. 使用Kyverno，在OCP集群中定义和管理各种策略，如访问控制、资源限制、网络策略, 确保集群的安全和合规性。
2. 使用valut对敏感数据进行加密处理，防止用户名密码、AKSK等信息暴露

五、容器云平台运维的一些经验

在日常的容器运维过程中，积累到一些最佳实践的内容，简单分享几点：

1. 容器集群自动化运维
容器平台除了考虑稳定性的因素，随着集群规模越来越大，集群数量越来越多，容器集群本身的运维必须能够自动化。我们在容器集群的日志、监控、备份、扩容、资源交付等方面都开发了对应的operator，通过operator打通IAAS层资源以及公司内部的CMDB、自动化交付平台，可观测性平台等外部系统。不仅提升了运维的效率，也方便标准化管理。

2. 定期进行故障演练
随着容器平台引入的东西越来越多，技术越来越复杂，故障点增高的同时也变得越来越复杂。为了最大程度上降低故障出现的频率和造成的损失，我们采取主动演练的方式定期对平台以及业务进行主动的故障制造。这些手段包括人为的停机或者断流、主动的安全攻击，我们也在尝试使用混沌工程的一些开源项目例如Chaos进行更为系统全面的故障注入方式。通过演练，不仅整改了问题项，同时也提高了工程师的排障能力，对系统的稳定性更为有信心。

3. 应用可观测
在公司内部业务容器化的过程中，我们发现容器化业务对于可观测性的要求相比传统运行在虚机的业务更高。一方面是因为部分业务开发人员对容器技术不够熟悉，另一方面是由于容器的动态和自动化程度过高导致。除了日志、指标、链路追踪等基础知识，我们为核心业务系统建设了包含虚拟机、网络、负载均衡、应用服务器、数据库、中间件、应用等维度的统一大盘，聚合和联动容器的日志、指标、事件等信息，为业务的故障排查和预测提供了很好的支撑。

具体运维经验

1. 出向流量安全管理
我们通过networkpolicy能够很好的控制Kubernetes集群内部的流量调用，隔离业务系统之间的服务调用。然而，容器里的服务不会只在集群内部封闭运行，它需要访问集群外部应用、数据库、第三方API服务、互联网服务等。出向流量里可能包含业务需要的外部访问，开源组件更新的访问，也有可能是入侵应用对外的一些访问。从安全的角度出发，必须能够对容器内的服务进行出向流量的控制,传统模式下通常通过IP地址进行防火墙或者黑白名单的设置达到控制访问的目的。但由于容器的动态性，IP地址发生变化，必须使用其他方式进行细粒度的控制。

1. networkpolicy是最容易想到的限制外部访问的方式，但在实施过程中发现一些问题；
2. 没有全局性的策略，必须为每个namespace分别配置；
3. 没有以Kubernetes svc名称为条件的选择能力；
4. 没有明确的集群外访规则，外部目标服务只能依靠宽泛的ipblock；
5. 没有显式拒绝能力，通过策略的隔离性特点，然后施加具体的白名单；
6. OCP提供了几种相关的实现；
7. EgressIP；
8. 在集群中选取一组节点作为出向网关，以namespace为粒度设置egress IP地址。所有该namespace下的流量通过OVS网络路由到出向网关节点并snat成对应egress IP进行外部访问。此方式的控制粒度太粗，只能以namespace为最小粒度。当多个namespace共享出口节点时容易互相影响引发一些故障，比如某个namespace内的业务流量过大影响到其他节点的出向访问；
9. Egress Router Pod；
10. 它是一种特殊的Pod，拥有两个网卡，使用MacVlan技术将其中一个容器网卡与外部网络直接连通。所有Pods出集群流量都会经过该Pod。根据不同的CNI（SDN或OVN-kubernetes）,具有的功能也不同，在OVN-kubernetes CNI下仅支持重定向操作。一般来说这并不适合大规模使用，从Egress安全策略设定角度，这也依然无法区分不同服务，且集中的Egress Pod容易成为性能瓶颈；
11. Egress NetworkPolicy；
12. 允许为某个project或namespace设置出向访问规则，可以基于协议，端口，IP，DNS等维度。协议支持TCP，UDP，SCTP三种。

由于EgressIP、Egress Router Pod都存在性能瓶颈，我们最终使用Egress NetworkPolicy方案。在项目初始化时，通过项目模版生成规则，默认deny掉非必要的所有外部访问、结合运维管理流程，业务按需进行IP地址或者域名的开放。

2、节点管理
目前运行在OCP平台上的业务类型分为无状态服务、中间件服务、大数据类的服务。不同节点对于机器配置、存储、稳定性以及内核参数的要求不一致。目前集群内除了Master以外管理了几类不同的节点池:

1). 基础设施节点
部署容器集群基础设施类服务例如日志、监控、微服务管理服务、集群和中间件的operator服务、云控制器服务

2). Route节点
多组七层网络入口服务，每组Route服务通过水平扩容的方式扩展流量承载能力。通过Router分片方式，当集群内路由数量超过一定阈值（5000），创建新的一组Router节点

3). 普通工作节点（包括无状态业务服务、大数据类服务）
无状态服务以Java居多，对于内存的需求量较多。节点的规格cpu和内存的比例设置在1:4。跑在此类节点上的服务必须具备随时被驱逐或者调度的情况下也能实现服务高可用的要求。同时为了提高节点资源的利用率，将Spark、Flink等大数据的Job类服务也调度到此类节点。

4). 中间件节点
中间件对于稳定服务的要求比较高，应该尽量避免重启或者调度的操作。由于ocp通过machine管理节点的方式要求每次节点都必须进行重启，所以此类节点的machineconfig自动更新设置为暂停。以人工干预的方式进行此类节点的升级。通过自定义调度器，实现中间件类的Pod都会被调度到此类节点上。

5). 存储节点
使用ocp的ocs作为块存储和文件存储的服务，存储节点应尽量避免被其他业务干扰，同时可以做到灵活的扩容。此类节点的自动更新也被关闭

3、集群标准化
我们在不同的数据中心按照业务环境划分了不同的OCP、OKD容器集群。集群数量多了以后，多个集群的统一管理和配置给运维造成了不小的负担，人工方式配置集群也会给稳定性带来一定的挑战。关于集群的统一管理，我们也做了一些工作：
1). 通过OCP统一纳管不同的集群，实现统一的集群管理和API管理入口;
2). 通过GITOPS实现集群配置的统一下发，比如一些策略配置、集群设置等;
3). 将内部的一些自动化Operator、中间件Operator封装成内部的index镜像，管理这些operator的安装和更新;
4). 汇聚所有集群的监控、事件、日志、运营等数据到外部平台，统一管理集群的观测性和运营数据。

4、统一流量调度
早期每个OCP集群都有自己的Ingress网络入口，业务发布在不同环境需要配置不同的DNS解析和证书。为了收敛，我们建设了统一流量入口服务。统一入口提供证书卸载、安全防护、限流熔断等基础能力，容器后端的Ingress入口作为流量入口的公共upstream，配置泛域名解析，业务只需在配置时选择对应集群和服务即可完成流量的配置,在业务迁移时也借助公共的负载配置一些灰度迁移的能力。

六、容器化带来的收益

6.1业务收益

容器平台上线后，覆盖了公司研发、采购、供应链、销售等多个领域共计200多个业务系统。给业务部门带来的收益如下:

1. 提升业务发布效率，一次构建发布的时间从30分钟缩短到5分钟以内。发布周期明显缩短；
2. 提升业务扩缩容的效率，部分C端业务在面临业务高峰时无需再手动进行扩容服务器，部分业务使用hpa实现了弹性扩缩容；
3. 降低了业务的运维成本，业务容器化之后运维的人力成本下降50%；
4. 提升了资源开通效率。业务通过流程可以在2分钟以内申请到想要的算力资源；
5. 提升了业务的稳定性，容器的健康监测和声明书的特性使得发生故障的频率和RTO指标显著改善。
   

6.2 IT部门收益

1. 资源利用率显著提升。相对虚拟机部署，内存使用率从40%平均提升到70%左右（java类服务居多）；
2. 基础设施标准化和自动化水平提高，降低了运维成本，同样运维200个项目，运维人力成本从20人左右下降到5人；
3. 为IT在微服务能力建设、可观测水平提升等方面提供了基础。容器化之后指标和日志实现100%全覆盖；
4. 业务通过容器能够实现多地发布，降低了和公有云的耦合性，从而提高了于云尝试的议价空间、降低了云的使用成本；
5. 使得业务在多数据中心迁移的工作量明显下降，节约了大量人力成本，业务迁移的周期从数周下降至数天；
6. 对整个基础设施的标准化，安全治理等方面都带来了便捷性。

七、 未来车企容器平台的发展规划

公司在下一步的规划中主要考虑两个方向：

7.1多云业务弹性能力提升

1. 业务的全球化趋势以及业务对于稳定性要求的提升，需要具备异地多活、单元化部署等跨区域的部署场景，比如车联网业务、全球的分销系统等；
2. 公司混合云的背景下，要求基础设施和云厂商解绑，应用以及基础设施能力必须能够以最小成本进行切换和弹性，满足合规要求和更多的议价空间；
3. 公司内集群的数量已经有300+,集群的提供商、版本，集群内部的管理组件差异性给业务使用和运维带来了很大的负担。需要一个面向混合云的容器管理组件，为业务提供统一的容器资源管理管理入口。

7.1.1对比容器多集群的社区开源项目
除了上述业务的需求，另外容器单集群本身存在的的稳定性和容量上限、不同云环境的版本不统一等问题，容器的多集群管理是必须解决的问题。我们对比了多个多集群的社区开源项目：

1. 联邦集群技术选项：

通过对比在功能层面上Karmada吸收了参考Kubernetes Federation v1 v2 两个版本的核心实践，并融入了众多新技术，包括 Kubernetes 原生 API 支持、多层级高可用部署、多集群自动故障迁移、多集群应用自动伸缩、多集群服务发现等，并且提供原生 Kubernetes 平滑演进路径。在可扩展性、现有平台兼容性都满足我们的需求。

2. 容器集群联邦管理：

3. 联邦业务调度：
结合多集群的发布能力以及全局流量平台的建设，满足业务不同的发布需求。

7.2研发流程闭环

公司内部存在大量的外采系统服务于研发流程，比如Devops、原型设计、低代码平台、微服务平台等，系统落地后往往在初期能够收获一定效果，但烟囱式的系统建设方式导致用户面向的系统越来越多，不同系统之间门户独立且无法集成。业务无法以统一视角闭环业务开发流程，应用需要再需求管理、开发、发布、运维等多个阶段使用不同的平台，这些平台之间目前缺乏联动，用户使用起来十分不便。

建设思路: 我们考虑建设统一门户，将外部系统的能力抽象成原子能力服务，同时建设部分原子能力，例如：持续集成、代码管理、注册配置中心、服务治理、中间件等，以类似公有云的服务方式对外提供服务。同时，以企业元数据为基础串联系统设计、研发写作、持续交付、资源管理、监控运维多个阶段。这里的企业元数据是指公司的产品、服务、应用的数据。