这篇文章总结了容器技术（包括Docker）、Kubernetes和微服务在云计算中的应用及其对企业的影响。主要内容包括：
技术趋势：

• 容器化技术的普及与成熟
• Kubernetes作为容器编排工具的统一标准
• 微服务架构的应用与开发效率提升
  企业级容器PaaS平台建设：
• 基于Docker的轻量级虚拟化技术
• Kubernetes的高可用性和扩展性
• 开发模式从试用性转向规模化
  关键技术和解决方案：
• 开发工具如Jenkins和Helm支持自动化交付
• 问题解决方法如调整系统日志限制、修复配置文件等
  架构与部署：
• Openshift作为container PaaS平台的核心框架
• 高可用性和网络设计（如软件定义网络SDN）
  应用场景与优势：
• 降低IT运维成本
• 提供灵活的应用部署与运维支持
• 支持快速开发与部署
  未来趋势：
• 容器云PaaS将推动企业向基础设施即服务（IaaS）转型
• 硬件定义网络（SDN）和多租户隔离成为主流
  这篇文章强调了 containers/ Kubernetes 微服务架构对企业上云的重要性和实际应用价值，并提供了具体的解决方案和技术建议。

摘要

前言

国内保险业客户逐渐向线上转移，在产品和服务形式上展现出显著的偏好趋势：他们更加注重简洁易用性、即时可及性和个性化定制。近年来开始深度布局大健康产业领域，并致力于构建全方位的保险服务体系覆盖所有场景。作为一家具有国际视野的世界级保险公司，在推动相关业务发展的同时积极构建'保险+医疗+养老'生态闭环，并引领服务业发展与供给侧改革进程。伴随着互联网技术与大数据分析手段的进步以及先进的人工智能技术的应用前景愈发广阔的新机遇正在重塑现有的IT系统架构面临更高要求

就衍生出对IT基础设施实施敏捷化改造的需求。计算资源经历了从物理机向虚拟化发展、进而迈向IaaS阶段的过程。新一代企业级云计算的重点转移至PaaS服务，在云计算领域具有重要战略地位。相较于已经趋于完善的IaaS和SaaS服务，在PaaS领域仍处于持续创新阶段，在Openstack平台及VMware技术生态的发展趋势分析可知,IaaS与PaaS正在加速融合在一起的基础上, container、Kubernetes、微服务等新兴技术逐步成熟,已在多个行业实现广泛应用并发挥显著生产力优势,由此带来的对container技术和PaaS平台的需求也已从试探性探索转向系统性规划与深度开发,最终打造专业的企业级container-PaaS平台已成为必然的发展方向。

背景

技术方面：

1.容器 - 量变引发质变，形成PaaS平台新契机

容器是2016年软件行业七大趋势之首

以Docker为代表的容器技术是一种

轻量级 “虚拟化”(隔离)技术

实现应用封装标准化，形成混合云部署标准

虚拟机 VS 容器

2.微服务架构引领企业软件架构的变革

微服务是一种将应用分割成一系列细粒度服务的应用架构模式

微服务与容器成就企业应用开发、部署和性能伸缩的敏捷，

围绕企业的业务的关联性拆分微服务，使IT敏捷带动业务敏捷

3.Kubernetes成为容器编排技术标准

为PaaS技术演进，PaaS与IaaS融合提供基础

云原生为企业生产环境运行容器应用而设计

企业方面：

企业业务应用系统分层

在PaaS平台中应用日益增多的是微服务和云原生；这不仅要求我们不得不采用全新的视角来构建容器云PaaS平台。此外还涉及开发方式和运维策略的转变，以及IT资源生命周期的管理等多方面的内容。

容器云PaaS的建设目标

容器云PaaS平台作为企业IT集中化建设的关键基础设施平台，在设计时必须紧扣业务场景实际需求开展规划与应用，并避免追求功能全面性的同时忽略技术成本平衡；基于容器云PaaS平台框架构建基础层的容器PaaS基础设施；在该框架内拓展完善包括软件定义网络架构、软件定义存储方案、权限管理模块、企业级镜像存储服务、统一入口路由配置、持续集成与持续交付流程支撑以及统一管理控制台界面等基础功能，并配上DevOps工具链套装、微服务管理平台以及IT运维监控系统等配套解决方案。

建设一个合适的PaaS平台对于企业来说至关重要。首要认识到云计算技术本身具有较高的复杂性，在这种背景下，
OpenStack、Kubernetes和Ceph等系统代表了开源云技术领域的典型方案，
企业若想要真正运用好这些平台并非易事，
其所涉及的技术栈几乎涵盖了整个计算领域的知识体系，
又处于数据中心的核心位置，
这一点牵一发而动全身，
企业的重大事务关系到能否周全把握其发展脉络。
在功能选择上不宜一味追求"大而全"的特性，
这种特性在实际应用中并不一定带来优势，
反而"做减法"这一操作往往更具挑战性，
因此，
PaaS建设的核心需求应聚焦于提供稳定可靠的数据中心底座支撑系统。

建设原则

技术先进性和成熟性

新兴技术和开源资源推动了互联网行业的快速发展。各大企业都积极融入开源社区生态，在这一过程中必须从高端起点出发，并充分汲取开源社区的技术与经验支持。为了确保系统运行的安全性和稳定性的同时，请权衡技术和成本因素后发现，在3到5年的时间周期内能够提供稳定的解决方案是较为合理的策略。

开发性和标准化

平台的整体架构必须严格遵循行业内的最佳实践和标准。借助开源社区的力量是实现这一目标的关键。Kubernetes通过一致性认证计划成功地保持了社区的一致性。产品需与主流技术生态相融合，在DevOps工具链、CI/CD以及微服务架构等方面实现良好的兼容性。基于松耦合的设计原则并采用标准化接口，在保证灵活性的同时仍能保持较高的可配置性。这种架构能够很好地适应企业现有的技术基础和业务需求，并且具有高度的可配置性和灵活性。同时具有高度的可配置性和灵活性的同时还能最大限度地发挥现有技术的优势并降低开发成本。

可靠性与安全性

安全性与可靠性构成了系统建设的核心要素，在面对日益复杂的容器云PaaS平台上表现得尤为关键。该平台必须具备一系列可靠的工具集合，并且能够实现以下功能：实时监控运行状态（即具有良好的可观测性），全面容错机制（包括备份恢复方案），自主诊断能力（如完整的调试日志记录），以及保障数据存储的准确性和完整性。

合理的技术演进路线

基于容器云PaaS技术的成熟度考量下，请您分析以下几点：首先确定哪些业务场景适合采用容器化部署；其次需评估数据库系统的兼容性；建议当前阶段先对技术可行性进行评估；后续需制定科学的推进方案；可分阶段逐步推进实施；请确保第一步的顺利实施至关重要

风险与应对措施

1、 容器技术的弱隔离性

容器并非传统意义上的虚拟化技术而是基于进程隔离机制的技术它通过内核空间、资源分配以及安全机制对运行中的进程进行隔离这种做法使其无法像虚拟机或沙盒环境那样提供相同的隔离效果目前轻量级的虚拟机容器技术尚未普及在当前阶段Docker及其后端引擎Containerd仍是主要的应用工具因此在选择容器化方案时需综合考虑业务需求和技术可行性避免一刀切式的迁移策略

2、 企业多租户隔离

多租户隔离在容器云PaaS中主要基于网络特性进行划分，在实际应用中主要分为弱隔离和强隔离两种类型。弱隔离模式适用于同一组织内多个用户共享同一容器集群的情况，在逻辑上能够实现资源的独立性；而针对复杂的业务需求和技术限制，在单个集群难以满足的情况下通常建议部署多个独立集群，并通过统一管理平台实现资源的集中配置与调度

3、 配套的DevOps工具链和CI/CD流水线

相较于虚拟机时代的应用交付方式而言，在容器时代下开发与运维职责界限变得模糊，并非简单的权责划分差异而是呈现出更为复杂的关联性特征；这一体系可以通过DevOps框架来实现对这种复杂关联性的管理；构建了一套包含Helm、Jenkins等多种工具的应用生态；涉及的技术与工具十分丰富；生态系统完善的程度仍需提升；企业在采购这些工具时往往面临流程复杂的问题

4、 应用的容器化改造

企业需采用容器云平台服务（PaaS），例如实施无状态化改造策略；
统一的日志格式输出方案能够满足监控需求；
同时具备持续监控和数据收集功能；
推动自动化集成与部署流程；
通过以上措施确保系统的高效运行。

产品/技术选型

自2016年以来, 我司就开始进行容器技术的试验性研究. 不像现在的Kubernetes一统江湖, 当时的container领域由Docker一枝独秀. 在容器编排领域, swarm、mesos和Kubernetes各自展露锋芒, 形成三分天下之势. Mesos被定位为数据中心技术底座, 自然吸引了大量大型企业的关注; 而Kubernetes凭借谷歌的技术加持, 则占据了一席之地. 在国内, 容器技术相关的创业公司如雨后春笋般涌现出来,充分展现了这一领域的火爆程度. 经过一番了解后发现, 容器编排的实际落地仍然存在诸多挑战. 一方面难以找到合适的解决方案; 另一方面也不敢轻易下结论认为完全实现容器PaaS功能.

到2017年这个时候, 容器编排领域的技术发展已不言而喻, Kubernetes一跃而成行业标准；上半年我们便迅速认定Kubernetes作为容器PaaS的核心技术, 将其作为产品解决方案的目光也渐渐清晰起来；作为一个技术底座, Kubernetes本身的健壮性毋庸置疑, 但受限于其专精于编排领域的特性, 如何实现其他功能的技术栈仍需企业自行构建这一难题摆在眼前；经过深入研究与实践尝试后, 我们最终将目光投向了 Openshift这一方案； Openshift是一个基于Kubernetes的企业级PaaS平台, 基于Docker构建, 同样具备Kubernetes的所有优势特点, 同时针对性地弥补了Kubernetes在扩展性等方面的不足, 从而更好地满足企业在应用开发及运维过程中对生产效率的要求

Openshift VS Kubernetes

OpenShift项目和Kubernetes项目的定位不同，属于不同层次的创新。

Kubernetes项目的首要目标在于提供一个通用的容器部署与编排平台，并特别强调为容器集群环境提供快速部署与运行管理的基础技术支撑。通过构建完善的基础设施来实现资源的有效调度与优化配置。

OpenShift项目致力于为用户提供一个便于使用且可靠的容器应用云平台解决方案（Platform-as-a-Service）。该方案涵盖SDN技术整合、系统日志管理及数据存储优化等预设配置。

基于该技术的基础，在实现自动化运维方面具有极强的扩展性和适应性，并能实现资源调度和容器编排功能

作为接近用户侧的一个方案而言，在诸多可能性之中达成某种或几种特定的目标。

改写说明

能够为企业构建一个内部的应用市场，并为企业开发人员便捷地支持所需的应用开发所需的中间件、数据库等服务。

通过OpenShift平台实现应用开发、自动化测试以及系统上线的无缝衔接。不同岗位人员（包括开发者、测试员及运维人员）可在单一平台上协同工作。为企业提供支持与优化DevOps实践，并在此过程中提升资源使用效率与优化业务运营效能。

3、 支持LDAP用户权限管理，支持细粒度的权限资源管理。

4、良好的开源社区支持。

5、 强大的厂商支持和长生命周期管理。

采用软件定义网络架构（SDN），借助开放平台OpenVSwitch实现灵活配置与可靠部署。该系统不仅支持跨机群共享资源与独立化运营多租户架构，并且能够整合第三方SDN解决方案（需经过Red Hat认证），包括Cisco Contiv、Juniper Contrail、Nokia Nuage、Tigera Calico以及VMware NSX-T等先进技术产品。

该平台预装了完整的性能监控和日志管理组件集合。其中不仅具备对系统运行状态实时监测的能力，并且能够迅速提取关键业务指标数据，并对所有业务日志进行系统化收集与深入分析。这些功能有助于全面掌握企业运营状况并及时优化各项业务流程。

该系统支持多种接入方式。通过友好的Web界面实现、命令行工具以及RESTful API的功能访问和使用。

该系统具备自动化集群部署与管理的能力。Openshift借助Ansible技术实现了集群的自动部署功能，并通过提供相应的接口支持其自动扩展能力。

架构方案

主机：

虚拟机方案：

双方各有其长（短），从灵活性上讲，虚拟机部署的优势在于灵活且易于配置；其中最为关键的是节点的扩展非常方便。在平台健robustness方面，则相当于为系统提供了双重保障：一方面依赖于虚拟化技术的支持，在另一层面则依靠PaaS服务体系的辅助；然而这种设计也带来了一定的成本：即引入了额外的一层虚拟化支持，在一定程度上增加了系统的复杂度；这必然会影响到整体系统的可靠性水平

裸金属方案：

该方案通过去掉了额外虚化层带来的性能消耗，在裸服务器环境中实现了对Kubernetes及容器服务的时间差距明显缩短（相比在虚拟机环境中运行Kubernetes所呈现的时间差距明显缩短），约为其三分之一的时间差距。开源社区与企业正致力于开发基于容器化的虚拟化解决方案（如kubevirt）。就成本效益而言（即在许可费用方面），如果仅需解决当前问题，则无需同时为两种技术买单（因为容器已提供解决方案）。综合考虑时间和资源投入效率（长期来看），建议优先选择私有云环境下的裸金属部署方案。（本次讨论重点即为此方案）

高可用：

在openshift集群中存在两种类型的高可用性。其中一种情况是集群内部各个组件之间的高可用性；另一种情况是内部应用自身的高可用性。该平台从设计阶段开始就已经充分考虑了这两种不同的高可用性。

在kubernetes集群高可用架构中，openshift提供了丰富的组件类型组合，默认配置下各组件均可实现自我高可用性部署。其中最为关键的是router组件的支持能力，在不中断现有服务的情况下动态扩展其负载至最大集群规模。通过openshift oc scale命令管理模块，在不中断现有服务的情况下动态扩展router组件至最大集群规模。

针对部署于集群内的应用程序而言，Openshift能够将多个应用实例分散至不同的物理拓扑区域（如节点、机架、机房等），从而最大限度减少同一时间发生故障的可能性。该系统还提供健康检查探针组件，在检测到某个节点出现异常时（如主控节点或基础节点故障），会将该故障节点的任务重新部署到其他可用节点上，并保证集群内应用总实例数量与管理人员配置的一致性。其中主控节点分为Master类（Master）和受控类（Node），而受控类又细分为基础类（Infra）与计算类（Compute）。具体配置模式为：Master 3 + Infra 2 + Infra n（n代表可扩展数量），并根据实际需求分配不同角色。

硬件配置配置示例(企业可根据自己情况进行定制)：

Master控制节点 *3

Infra-node节点 *2

Compute-node节点 *n

部署架构图

网络架构图

网络

Openshift通过软件定义网络（SDN）实现了集群内部统一的网络环境，在集群内部不同节点之间实现Pod间的通信功能。 Openshift SDN架构非常灵活，在配置中可以选择多种不同的实现方案切换使用。 当前版本采用基于Open vSwitch的VXLAN方案作为默认配置方案。 该方案为用户提供了两类功能各异的选择：ovs-subnet提供了整体连通的平面网络模式，默认情况下集群内的所有Pod均可直接通信;而ovs-multitenant则采用虚拟专用网的方式实现了Project间的隔离管理模式，在每个Project内所有资源均互通共享但不同Project间对应的Pod及服务无法互相访问。 管理人员可通过手动配置解除隔离实现不同Project间的互联连接操作，并保证了对企业原有网络架构无侵入性的同时实现了快速部署需求

多租户支持：

每个用户项目分配一个惟一的虚拟网络ID (VNID)

防止交叉项目沟通；

项目VNIDs可以合并以允许通信；

VNID 0预留给管理服务，不受限制；

节点内的SDN 流量

存储

持久化存储分为平台内置组件的持久化存储和应用的持久化存储。

平台在持久化存储方面可采用基于企业现有存储方案的方法进行配置；该系统内置有包括NFS、GlusterFS、Cinder以及Ceph等多种不同的存储技术。

在应用系统中涉及持久化数据时，优先推荐采用对象存储方案，并将nas技术作为补充策略

监控和日志

推荐和企业已有的统一监控和日志平台。

建议优先选择内置的Prometheus平台进行部署，并根据实际需求自定义多层次、多维度的告警体系；node节点的基本监控功能建议搭配zabbix等第三方工具进行扩展；同时重点部署OCP内部的核心组件（如etcd、ovs-sdn和router）的相关监控指标；此外建议重点部署syslog关键字相关的日志收集模块，并对整体运行状态进行实时跟踪；最后需要确保所有相关问题都能及时进行处理。

平台调度

Openshift在接收到API Server发出创建Pod的任务后，并不会立即采取行动；相反地它会立即开始处理这一请求并迅速为其分配一个能够运行其进程所需的资源。调度系统在执行任务时首先会对所有符合条件的任务进行筛选，并依据不同的算法对这些任务进行评分；最终系统会将任务分配到最优配置的位置上。通过结合Node labels以及NodeSelector机制；系统能够实现复杂的任务调度策略。管理员可以根据需求为基础设施设置多级标签（例如region=r1, zone=z1, rack=s1）；当部署应用时；系统可以根据配置好的标签信息自动识别出最适合该应用运行的位置；从而实现资源的最佳利用效率。另外还可以通过指定Affinity参数来设定 Pod 间的亲缘关系；从而在实际部署时将互访频率高的 Pod 放置在网络位置较近的位置（如同一台服务器或同一个机架内）。此外还可以设置反Affinity策略；尽量将同一服务的不同 Pod 分散部署至不同的服务器、机架甚至机房区域；从而进一步提高集群的整体可靠性和可用性

权限和多租户管理

虚拟机池是指多组不同的应用或者用户同时运行在一个基础资源池之上，并通过该资源池实现软件与硬件资源的共享。为了解决安全需求的问题，平台必须提供资源隔离的能力。在OCP中，容器池是一个进行租户隔离的概念，在此架构下，默认情况下容器属于一个特定的租户所有。通过容器池这一机制，在OCP平台上可以从多个层面实现多租户的支持。

1. 权限控制

2. 网络隔离

3. Router隔离

4. 物理资源池隔离

5. 对接外部LDAP，可实现细粒度的权限控制；

6. 根据要求定制个性化scc角色；

负载均衡

该设备本身支持嵌入式多级架构设计，在平台层内部实现7个层次的自适应管理功能。外部环境需配置负载均衡功能模块以实现跨域流量分配策略，并与企业现有部署的F5系列、LVS和Nginx等负载均衡设备进行对接。建议在原有架构基础上增加一层7层协议控制节点，并按网络分区分别配置内网负载均衡器和外网负载均衡器以提升业务扩展能力。

https证书也置于这一层，这样router直接启用http的80服务即可。

团队组织架构

应用系统上云方案

上容器云流程

开发测试环境流程

生产环境流程

应用上容器云评估(架构梳理)

1. 了解目前项目的架构，确定哪些组件采用容器化方案

2. 目前数据库采用传统架构，部署到物理机或虚机

3. 微服务架构，单体应用

4. 主流微服务框架(SpringCloud、dubbo)的kubernetes方案；

混合云下的交付

Jenkins + Helm，这里不做展开

应用容器化改造过程中应注意的几个问题

应用的无状态化，日志输出

1、jdk版本是否要升级

参考：https://developers.redhat.com/blog/2017/04/04/openjdk-and-containers/#more-433899

基于Java的企业应用开发已成为主流趋势。 container化云服务已成为企业应用开发的重要方向。 JDK 2.2.99（即JDK 7）已经实现了对Docker CPU和内存限制的支持。 Java语言规范委员会于2022年宣布，在JDK 9及其之后版本中将移除对JDK 7与JDK 8的支持。 如果企业无法及时升级到JDK 9或更高版本，则应考虑转而选择JDK 8以及更高版本中的相应替代方案。

cpu limit

如果没有显式设置-XX:ParallelGCThreads或-XX:CICompilerCount，则默认情况下JVM会应用容器的CPU限制。当容器指定了CPU限制时，并且相应地设置了这些JVM参数，则按照相应的设置执行。

memory limit

在Java 8 U131版本和Java 9版本中（或在java8u131+及java9中），必须启用选项-XX:+UseCGroupMemoryLimitForHeap以及-XX:+UnlockExperimentalVMOptions以确保Docker能够感知Xmx设置的内存限制。

2、Debug工具：

不建议过度扩展基础镜像，并非建议添加过多调试工具。 BusyBox 软件整合了数百种最常用的Linux命令与功能。它不仅包含了一些基本功能，例如ls、cat和echo等基本操作指令，在某些情况下还提供了更为复杂的管理功能如grep、find、mount等操作以及telnet连接支持。一些人将其视为Linux生态系统中的全能工件。简而言之， BusyBox 软件就像是一个大型工具箱，在整合了大量Linux相关功能的同时还内置了Android系统自带的 shell 功能。对于那些熟悉使用各种独立应用程序的人而言，在使用BusyBox时会感到非常方便和高效；而对于那些希望集中管理所有系统命令的人而言则同样适用。

平台运维过程的几点问题

1、 一次Node节点hang死的处理记录

查看系统syslog发现一下关键日志：

rpc 错误：码 = 2 描述 = oci 运行时错误：进程失败：container_linux.go 行号 247：启动容器过程时触发了"打开 /proc/self/task/124250/attr.exec：系统中已打开文件过多"错误

更改文件数解决

2、 扩容计算节点，新节点的pod报”dial tcp:lookup …no such host”错误

经排查发现新增节点上的DNSMASQ配置信息尚未完成同步至其他节点，请重新启动相关节点的DNSMASQ服务。

3、 扩容新节点后，新节点报错；

atomic-openshift-node[2588]: E0701 19:02:26.547994 2588 summary.go:102] 无法获取系统容器统计信息：未能获取c组统计信息：未能获取容器信息：未知容器 /system.slice/atomic-openshift-node.service

经查此为openshift的一个bug,参考

https://bugzilla.redhat.com/show_bug.cgi?id=1623261

https://github.com/openshift/origin/pull/21138

在Linux系统中使用cat命令修改文件位置为：
$ cat /etc/systemd/system.conf.d/origin-accounting.conf

[Manager]

DefaultCPUAccounting=yes

DefaultMemoryAccounting=yes

systemd v230 or newer

#DefaultIOAccounting=yes

Deprecated, remove in future

DefaultBlockIOAccounting=yes

最后，需重启主机；

4、 平台升级

应用迁移的一些脚本：

1.全量导出项目

切换project

oc project

新建$projectName

mkdir

导出配置

when the object is processed through the incoming routing path, it undergoes a series of transformations as defined by its configuration map. The system manages account services and securely stores sensitive information, which is then analyzed for specific image stream tags. Each pod follows a predefined configuration, and CMS content is accessed according to established exit network policies. Role binding restrictions are applied to ensure compliance with organizational protocols, while range limits are set to manage resource allocation effectively. The deployment process adheres to specific templates, and cronjob tasks are executed in a stateful manner with proper resource management. Specialized configurations for HPAs and Kubernetes deployments ensure optimal performance across multiple replica sets. Pod disruption budgets are allocated to maintain system stability, and endpoints are configured with appropriate security measures to ensure compliance with organizational standards.

do

oc get -o yaml --export object > object.yaml

done

2.复制到新系群环境下

scp ...

3.导入新集群

切换project

oc project

导入配置

指定对象为入口路由配置映射服务角色绑定等选项设置，请确保配置正确

do

oc create -f $object.yaml

done

总结

企业要想成功落地容器云平台体系，则首要因素是人这一资源的有效配置。这需要数据中心团队、架构团队、开发团队及项目管理团队之间建立紧密协作关系，在容器云PaaS平台上线后，数据中心的运维交付模式将逐步向服务中心和价值中心转型，在提升计算资源利用率方面取得了显著成效；经评估显示，在资源利用率方面开发资源池相比传统虚拟化方案已实现了五倍以上的提升；在部署效率上借助 Helm 和 Jenkins 的交付机制实现了近乎一键化的部署流程；而 k8s+Spring Boot 技术则可以直接替代传统负载下的 Spring Cloud 架构设计，在极大程度上缓解了微服务治理过程中的压力。

上云一时爽，一直上云一直爽。