金融企业上容器云平台如何进行应用容器化改造难点分享

字数 11294阅读 9075评论 2赞 5

应用容器化改造的成功与否决定了容器云平台的价值，只有给应用能带来实实在在的帮助和好处，容器云平台建设才能算是成功。应用容器化改造难点主要是形成一套行之有效的应用容器化改造规范，包括基础镜像选择，应用微服务化拆分，部署模板选择，日志改造，对外服务发布方式，应用高可用机制实现，PVC使用方式等。

为了能更好的解决大家在应用容器化改造上的难点问题，twt社区特别邀请了来自民生银行的容器云专家，进行线上难点交流答疑。上周进行了应用容器化改造难点的交流，进行了难点梳理总结。

## 一、应用容器化改造难点之：容器化后核心系统和非核心系统如何共存在同一主机，兼顾成本和安全性？
容器的隔离性没有虚拟机强，他们共享同一主机内核，如果一个核心系统和非核心系统共存在一台主机运行，可能非核心服务因为某种缘故导致内核crash，所在主机所有的服务都回收到影响，我们也不可能一个物理机只跑一个核心服务，那样的话成本太高。

**回复1：**首先，对于银行业，容器技术适用于敏态业务（互联网业务），虚机技术适用于稳态业务，容器技术不是一概而论的。
1、首先关于运行的系统进行讨论，无论是核心还是非核心系统，都是分布式的，都是多个节点的，理论上，一台物理机可以跑多个容器，即运行一个核心或者非核心的系统的多个服务实例（1个系统对应M个服务，1个服务运行N个实例）。
2、计算节点（物理机），无论是容器还是虚拟机都是运行在多个计算节点（冗余高可用），单个计算节点宕机，容器或虚机均会自动漂移至新计算节点，提供服务；而虚机内核crash，并不会漂移，而产生当然虚机的服务不可用，需手动重启。
3、根据上述描述，1）隔离性方面，一个核心系统和非核心系统共存在一台主机运行，存在相互影响的情况，但是容器会自动漂移重新提供服务。2）成本方面，如需进行隔离，则可采用核心业务非核心业务分计算集群的方式运行，而一个计算节点可以跑多个核心服务，一个计算节点发生crash时可以漂移至另一个计算节点，漂移过程中出现轻微服务波动的情况。
4、如果考虑核心业务的高SLA，那还是建议核心业务使用虚机或者物理机，而非核心业务使用容器技术，容器应用从非核心业务进行试点推广。

**回复2：**一般来说容器部署，底层物理设备都是多台X86服务器，很少有单点的。如果的确有这种需求，可以先把底层物理设备先进行虚拟化，再在虚拟机上面部署容器，通过虚拟化层面实现故障隔离，资源配额。

**回复3：**个人觉得首先考虑应用和资源的分层问题。应用只是使用资源，资源统一由基础设施资源平台来管理，需要什么资源分配什么资源。
不要尝试直接用docker或k8s cmd去管理应用，否则自己会玩死自己。应用管理平台要考虑产品化
容器的优点在于弹性，云计算的优点在于体量，没有大量的需求，不会节约成本，反而造成浪费。
安全性需要通过产品化和不同层次的安全措施实现。

**回复4：**目前我们的做法是核心业务和非核心业务承载在不同的K8S集群上。同一集群内的应用可以共享宿主机。为了避免因为单个节点故障影响应用，要求所有的应用必须至少部署2个副本，分布在不同的宿主机上，同时对于核心业务，要求应用必须双活部署，也即部署在双活数据中心的两个独立K8S集群上，前端通过负载均衡或者自动发现机制引流，这样即使某个数据中心发生了全局性故障，也不会影响应用。

## 二、应用容器化改造难点之：怎样实现应用的高可用，需要考虑哪些方面？

**回复1：**1.无状态，或者存储状态在应用本地的转移到第三方服务上（如本地会话转移到redis等，本地存储转移到分布式存储上）
2.配置管理，配置接入配置中心，最好有应用实现配置治理
3.服务最好不依赖ip，hostname等本地标识
4.调度亲和性，反亲和性（不在一个机架或者主机上）
5.应用健康检查
6.优雅启停

**回复2：**总结起来，有以下几点：
1. 应用无状态，多副本部署，副本分布到不同节点
2. 使用PVC的话，尽量不要使用共享PVC
3. 使用独占PVC，要确保没有外部应用程序去访问
4. liveness/readiness机制要尽可能覆盖完善
5. 应用跨集群容灾双活部署
6. 服务间有启动顺序依赖的话，需要做好对所依赖服务的探活和重连机制

## 三、应用容器化改造难点之：如何选择对外发布服务的方式，Nodeport、Ingress和LoadBalance如何选择？

**回复1：**也可以直接与负载均衡厂商（如F5）进行集成，不需要另外开发。既能满足容器对灵活性的要求，也能保留F5的传统优势。
F5的解决方案包含2个组件，VE（Virtual Edition）和CC（Container Connector）。VE是F5LTM的软件化产品，可以安装在虚拟机上，其功能与硬件设备完全一致。CC是F5的一个开源组件，它以容器的形式部署在Kubernetes集群中，通过读取Kubernetes API获取集群内的服务资源并将其转化为VE上的配置。管理员可以为每一个租户部署一组CC，每组CC独立控制VE上的一个对象配置隔离区域（partition），该partition下的资源完全由该组CC独立控制。兼顾了稳定性、灵活性与安全性。该方案中，负载均衡策略的定义提供多种方式，可以使用Ingress，也可以使用ConfigMap。
采用CC+VE技术，利用CC与Kubernetes通过API进行联动，完全适应容器平台对灵活性的要求；另外，配置上采用ConfigMap定义负载均衡策略，架构上采用VE直接对集群中的POD进行负载分发，减少网络层次，提升负载均衡性能；同时，通过将Kubernetes的Namespace与VE的partition一一对应，实现不同容器租户服务资源的隔离。

**回复2：**nodeport 四层协议的适用 中小规模的时候可以使用（ipvs目前不是特别的稳定，个人认为还没到生产可用，我们经常遇见服务没有及时更新的问题，但是是未来的方向）
ingress 七层http和https协议适用 有多种ingress类型
loadbalance 需要自己去开发对接了。

**回复3：**K8s发布服务有4种方式，ClusterIp, Nodeport, loadbalancer, externalName
ClusterIp是对容器内部服务调用
Nodeport是提供对外的调用方式，但Ip:port的方式通常不够友好。
Loadbalancer是需要k8s 外部负载均衡工具的支持。
基于Ingress机制可以实现负载均衡，比如用Nginx实现Ingress负载均衡。通常可以使用Ingress机制，辅以DNS实现域名访问。不过需要优化的工作不少。
ExternalName没有详细研究。

**回复4：** Openshift产品推荐通过NodePort类型的Service为某个应用对外暴露一个服务端口。NodePort类型的Service会在集群中的所有节点上监听一个特定的端口，访问任意一个计算机节点的端口，即可访问内部容器中的服务。在集群的所有节点的这个端口都会预留给该应用所用。
• 在F5 VS的Pool Member中配置所有节点，通过Keepalived来实现HA
• 应用系统和用户不用改变现有的访问方式。

**回复5：**从我们实际使用情况看，三种方式适用于不同场景。Nodeport适用于需要将服务端口注册到服务注册中心，不需要负载均衡的应用，典型的如使用了Spring Cloud服务治理架构的应用，应用和应用之间通过注册到服务中心的IP+端口通信。Ingress适合于对外的微服务较多，需要收敛到统一对外服务入口的应用，比如有20个微服务，都通过NodePort或者Loadbalance对外服务并不现实，通过Ingress对外提供统一服务入口就变得很有必要了。LoadBalance适用于除上述两种类型应用的其它场景。

**回复6：**Nodeport方式在某些场景上还是存在一些问题的，NodePort的实现方式是通过直接访问计算节点的端口，通过计算节点的iptables来转发请求至pod，而iptables只能基于源IP地址做会话保持，不能基于cookie等信息。另外，如果F5在没有开启X-Forwarded-For的情况下，由于计算节点接收到请求的源IP都为F5的地址，所以基于iptables的源地址会话保持机制，会将访问的所有流量都转发到一个pod中，导致在有多个pod的情况，只有一个pod有业务访问流量，其他pod没有负载（实际情况下，其他pod也有流量，但是流量非常少），不能做到流量负载均衡；
Ingress方式适合的场景会更多，可以通过Nginx或者HAProxy实现负载均衡，不过这种方式可能会带来一些额外的工作。如果现有环境中，系统间的接口调用方式不是域名方式的话，就需要接口调用方及提供方更改接口地址为域名地址，同时还需要引入DNS配合。

## 四、基于容器云平台灰度发布功能是如何设计实现的？
在灰度发布功能方面，容器云能提供哪些帮助？如何设计并实现基于容器云的灰度发布功能？

**回复1：**灰度发布通常是互联网类应用，快速迭代，以新版本逐步发布替换旧版本，以验证新版本是否存在重大缺陷，在新版本有问题的情况下可以快速回滚。
实现方式有多种，容器云平台层就是用同一个服务对应多个不同的容器实例，在发布新版本时，这些容器实例可以实现逐步的替换（服务名不变），就实现了灰度发布功能。
还有一种方法是通过流量负载分发，这种方式可以部署服务为多个版本，每个版本引流部分流量，需要有路由负载分发组件支持。
或者可以直接在容器云平台外部署API网关，在网关层实现路由分发，支持更多选择。

**回复2：**我们目前并没有用istio来做灰度发布，主要是对于istio在生产环境使用还有一些顾虑。目前灰度发布的流量切换还是通过F5负载均衡实现。K8S层面可以申请两个命名空间，其中一个用于灰度版本的发布。一旦验证通过，在F5上做流量切换即可。F5的member添加和删除已经完全自动化，所以流量切换或者回切都会很方便。

**回复3：**灰度发布功能，服务网格能做，不过可能对现有的技术体系和服务管控有比较大的冲击，而且服务网格还不是真正的很成熟。
容器云能很快的创建应用的新版本服务实例，剩下的结合负载均衡器结合业务做流量分发管理就能实现灰度发布。
1.创建新的应用版本集群，老的应用版本并存，这样资源的使用要多不少，逐步扩大新版本的分发流量比例，并且逐步减少老应用版本实例数
2.采用滚动升级的方法，比如运行一个新应用版本实例，删除老的应用版本实例。逐步替换。
另外灰度发布是一个很复杂的体系工程，除了流量管理外，还涉及新旧版本存储数据如何平滑迁移以及如何回滚

**回复4：**istio k8的方案很完备
mesos的话可以通过拆分成两个应用实现灰度版本，通过服务发现和服务注册组件配合istio实现引流。

## 五、关于容器网络隔离现在有什么好的解决方案？
容器云中为保证应用安全，如何对不同级别的应用进行网络隔离，选择什么样的模式及技术，或者对网络安全方面全面的解决方案介绍。

**回复1：**容器的隔离是软隔离，网络策略基本依靠iptables完成（通过k8s管理的）
应用安全等级高的 可以采用物理网络隔离，硬件隔离（防火墙，硬件网络），网络完全不共享
应用安全等级中等的，可以采用vxlan（看看是否需要多租户的网络隔离），在四层网络协议下做网络隔离（四层port 三层ip，二层vlan）
应用安全等级低的，容器的软隔离方案就可，网络共享性高，必然导致网络隔离性低、

**回复2**：这个要看安全要求的隔离力度是什么，和现有安全策略一致即可。如果安全只要求网络隔离区之间有网络隔离，那么每个隔离区放一个K8S集群即可。如果安全要求网络隔离区内，不同应用的网络也要做隔离，那就需要用到支持network policy的网络模型，如calico。但是这个同一隔离区内的细粒度隔离，我知道的传统应用也很少去做，最多也就是应用层面的白名单机制。

## 六、银行企业应用如何做无状态化？
对于有状态应用，容器需要额外技术负担去保证容器不漂移或者存储数据不丢失，对于运维和技术要求很高，所以银行企业应用如何做无状态化就显得很重要。

**回复1：**1、应用（主要介绍java应用）无状态化分为两个部分，session无状态化和存储无状态化。
2、一般银行应用均采用F5作为负载均衡，并采用session粘滞模式，如应用容器化则需实现session无状态化，如果采用springboot技术，添加@EnableRedisHttpSession来开启spring session支持，同时在application.properties中配置redis服务器信息；如果传统应用采用非springboot技术，容器采用tomcat，可以采用tomcat-redis-session-manager组件。以上redis建议采用高可用模式（如哨兵或集群），并强烈建议redis开启密码认证等安全配置。
3、有少部分应用需要挂载NAS存储，如应用容器化则需有两种方案，一种方案是宿主机和容器都挂载NAS存储，但这样会加强运维复杂度以及存储管理难度，不建议；第二种方案是存储无状态化，需采用分布式对象存储代替传统NAS存储，同时应用需改造采用S3接口，银行引入新技术分布式对象存储的可用性有待进一步验证，形成风险点。
4、建议挂载NAS存储的应用暂不上容器，规避技术复杂性，而敏态业务（互联网）应用改造上容器。
5、建立《容器平台应用适云规范》。

**回复2：**这个问题应该是问怎么样去做有状态应用。
我先回答一下如何做无状态应用，应用部署包的组成主要为代码，配置文件，初始化脚本，启停脚本，各类依赖管理。
无状态应用，我们要显式声明应用依赖管理，配置文件应该外部化，或环境变量，或配置中心管理，我们build出的镜像应该能在各种环境下使用。日志输出应该对接elk，要对日志输出格式进行改造，适配集中式日志系统规范。
有状态应用，我们除了要对接共享存储之外，还要注意有状态应用的扩缩容，比如如何弹性扩容三主三从redis集群，读写分离mysql，这些都是共享存储之外需要做的。
对于共享存储，对于强监管的银行应用，我们要做好存储的生命周期管理，审计，权限控管，配额管理，qos，故障追踪，平滑扩容等等一系列共享存储本身技术之外的东西。

**回复3：**个人觉得应用是需要考虑分层实现的，不是一个容器就运行一个应用。基于这样的考虑，其实可以实现容器层的无状态，可以利用容器的弹性等优点。
一个应用有一到多个服务，每个服务部署一到多个服务实例。配置由配置中心统一管控。实例、服务配置可以相同也可以不同，做到按需配置。
日志、监控等实现统一接口，应用服务不需要关注，通过配置就可以实现不同日志、监控平台的接入
数据可以通过messaging等方式实现和底层存储的松耦合，可以存储于数据库、大数据平台等
中间可以按需加入缓存、数据处理等逻辑
不妨基于这样的考虑尝试下

**回复4：**容器云环境下，应用和基础环境资源是解耦的，应用的扩缩容不需要涉及基础环境资源的扩缩容，仅仅需要修改应用部署模板文件中的副本数，然后在容器云平台执行即可。容器云平台会根据副本数来自动创建或者删除副本，使得最终的副本数是部署模板文件中定义的副本数。整个扩容或缩容流程可以在数秒到数十秒内完成。这样当应用面临突发业务量增长，需要紧急扩容的时候，就可以非常快的完成，实现了真正意义上的弹性扩容。

**回复5：**无状态应用：Stateless Application 是指并不会在会话中保存下次会话中去要的客户端数据。 每一个会话都像首次执行一样，不会依赖之前的数据进行响应。
有状态的应用: Stateful Application 是指会在会话中保存客户端的数据，并在客户端下一次的请求中来使用那些数据。
在无状态应用中，会话数据将会被存储在客户端或者透传给需要的这些数据的服务。在开发离线应用时，这是一个非常重要的的因素。通过这种方式来开发，会话数据将会被存储在终端用户的设备上，例如：当网络不可用时，用户将数据存储在自己的设备上，当网络重新连接时，会话数据将被上传并复制到云中。
在分布式系统中，无状态应用使实现了分布式水平扩展成为可能。当分布式系统中的一个组建是无状态时，能够在出现故障时轻松的重新部署，也能够自由的水平扩展来适应负载。组建之间也能够方便的使用API来进行通信。

**回复6：**银行业的很多应用，特别是一些核心应用很难做到完全的无状态化，典型的比如需要根据应用容器（或所在宿主机）生成交易流水号的应用。交易流水号很重要，通过它可以知道一笔交易在内部都经过了哪些处理环节，要明确到是哪个容器处理在这个处理环节里。这种情况下就很难做到无状态化。此外，很多核心应用还需要本地保存日志，需要每个容器将自己的日志写入独立的PVC。这种情况下也无法做到无状态化。好在K8S通过StatefulSet提供了对有状态应用的支持，运维难度其实和无状态的差别并不大。

## 七、应用容器化改造难点之：容器化后日志存储该如何改造，如何兼顾本地存储和远程ELK存储？

**回复1：**第一种做法是用分布式存储，使用stateful资源对象模型来编排应用，外部对接elk（日志打印标准输出和本地），这样日志本地和远程都兼顾，但是要注意日志需要定时归档，删除
第二种做法是用hostpath或者emptyDir，使用deployment资源对象模型来编排应用，注意不要把磁盘文件系统空间写满，外部对接elk，

**回复2：**应对分布式环境下日志分散的解决办法是收集日志，将其集中到一个地方。收集到的海量日志需要经过结构化处理，进而交给需要的人员分析，挖掘日志的价值信息。同时不同的人员对日志的需求是不一样的，运营人员关注访问日志，运维人员关注系统日志，开发人员关注应用日志。这样就需要有一种足够开放、灵活的方法让所有关心日志的人在日志收集过程中对其定义、分割、过滤、索引、查询。
OpenShift使用EFK来实现日志管理平台。该管理平台具备以下能力：
■ 日志采集，将日志集中在一起
■ 索引日志内容，快速返回查询结果
■ 具有伸缩性，在各个环节都能够扩容
■ 强大的图形查询工具、报表产出工具

**回复3：**如果采用集中式的日志收集Agent，也就是在应用容器之外单独由一个日志收集程序从PVC收集日志并发往ELK，会很容易导致应用容器切换到新节点时失败，原因是日志收集程序会hold住PVC，如果PVC是独占类型的，就会锁住PVC，导致PVC无法释放，相应的应用Pod在新节点上由于不能加载PVC，就无法启动。为了解决这个问题，我们的做法是给这种需求的应用容器旁挂一个日志收集容器，两个容器在一个Pod里，这样应用Pod退出时，会完全释放PVC，应用Pod也可以在新的节点正常启动。

## 八、同一套应用系统节点分别部署在虚拟机和容器环境，是否可行？有具体生产落地实践吗？
针对某一套具体应用系统，比如8节点，4个节点以虚拟机方式部署和运行，4个以容器方式部署和运行，前端通过负载均衡进行流量控制，这种方式是否有银行生产落地实践？有哪些需要注意的技术难点？

**回复1：**分别部署虚机/物理机和容器环境，可行！
1、目标：对于业务连续性要求，防范新技术（容器技术）应用的技术风险，重要系统可以同时部署在两种环境，形成“本地双活”，当容器平台发生风险时，无业务中断风险，但是此技术会增加配置复杂性、架构复杂性和操作复杂性。待容器技术成熟后，可切至容器平台，也可认为是一种技术过渡性方案。
2、应用节点部署，1）虚机/物理机部署，可采用自动化部署（使用Jenkin、ansible等自动化技术），或者手动部署；2）容器部署，采用镜像进行一键部署。
3、负载均衡，最前端采用F5，1）双负载均衡架构，前端一个总VS，下挂分别挂两个VS：A、虚机/物理机单独再配置一个VS（虚机物理机IP），B、容器部署也配置一个VS（容器软负载IP）；2）单负载均衡架构，前端一个VS，下挂混合虚机/物理机IP以及容器软负载IP。
4、上述两种负载均衡根据各数据中心情况和需求进行相应调整。

**回复2：**这种方案是银行过渡到容器云阶段的必经之路。
1.接入层使用负载均衡来流量分发到虚拟机或者容器集群，虚拟机部署的应用服务endport基本可认为是固定的，负载均衡可以手工配置，但是容器集群的应用容器是动态ip（除非做ip固定），这样就要求负载均衡要有服务自动注册的能力。
2.容器化到一定阶段后，上下游应用混合跑在异构环境中，要注意容器集群和虚拟机集群的互联互通，虚拟机要能访问到容器集群的服务实例，容器集群也要能访问到虚拟机集群里面的关联服务。
3.要注意规划采用哪种容器网络方案，不同的网络方案会有不同的问题。（三层路由或者隧道模式，或者放弃网络隔离性，采用宿主机网络）
4.注意关联服务是否有ip白名单的安全管理要求。

**回复3：**肯定是可行的。
传统企业在进行老系统容器化改造的过程中，应该都会面临这个问题：切割上线的时候，是一刀切，还是先并行（或称之为灰度发布）？
虽然在容器环境生产上线前都会经过各种各样测试，但是很难保证一刀切（将业务系统的访问流量从虚拟化环境全部切换至容器环境）之后不会出现异常。所以，比较稳妥的方式，就是将同一系统在原有环境中与容器环境中同时并行运行。以F5负载均衡为例，将”容器节点“作为新的pool member加入到原有的VS中。需要注意的是，这种方式需要考虑容器环境的外部访问模式，如果是NodePort访问方式，则需要把node+port加入到VS中，如果是域名访问方式，需要把Router加入到VS中。

## 九、集团容器云如何建设？产品选型及标准上有哪些建议？
我们招商局集团是一家大型中央企业，属下业务板块众多，既有金融板块（银行、证券、保险等）、地产板块、交通物流板块、工业板块等。金融板块IT比较独立。集团今年在落实数字化转型中，提出两平台一体系的建设：云平台、大数据平台、数据治理体系。云平台建设是基础，是集团数字化转型的底座，云平台建设重点是PAAS平台。按照集团信息化的特点及现状，总部综合管控系统、下属公司业务系统等基本采用购置第三方的成熟产品套件，这块完全云化，不太现实，需要第三方厂家产品支持。
关于容器云建设，这个在传统行业也刚刚起步，在容器云建设大家认识不统一：
第一、完全自研不太现实，资源配置不足；
第二采用容器云平台，行业的软件提供商在支持容器开发上产品不多。
基于这样的场景，集团容器云如何建设？采用K8s+docker是否能够满足未来的云化需求？行业内的PASS平台缺乏统一标准，各厂家产品的组件化提供方式不太成熟（组件化输出为能力，移植到自有的PASS平台）。在产品选型及标准上有什么好的建议？传统的应用是否有必要向容器云分拆成微服务？

**回复1：**1、云平台，从一个维度上讲包括IaaS、PaaS和SaaS，从另一个维度上讲包括计算云、存储云和网络云。首先贵公司确定建设目标，是基于容器技术的PaaS云平台，所以围绕这个目标进行建设。
2、容器技术，目前技术路线已经非常清晰，由原来的三足鼎立（k8s、mesos、swarm）演变为一枝独秀k8s，大家可以紧追k8s路线，且k8s经历了大版本的变更已逐步稳定、国内外生产案例具有大规模集群案例，基于k8s的方案已逐步走向成熟，k8s生态也逐步建立起来，当然相关组件还需进一步生产实践；
3、云管平台，所有功能基于UI化，以便操作用户和管理员用户进行操作，同时API化，以便各平台调用；同时运维方面，包括资源管理、组件管理、健康、日志、监控、应急、容量、部署、镜像、弹性扩缩、网络、存储、负载均衡等管理，运营方面，包括各应用系统的资源概览、容量分配情况、资源使用等情况；多数据中心管理，数据中心多集群管理、多数据中心集群管理、多数据中心镜像管理、资源统一调度、同城数据中心双活、异地数据中心灾备、灾备演练、灾备一键切换等功能；客户化，由于公司流程复杂、数据中心平台繁多，容器产品需要进行很多客户化开发，并进行各种流程系统对接。
4、容器平台建设，第一阶段采用厂商（建议专业做容器技术的厂商）合作模式，引入产品，由厂商支持底层组件等运维，有条件的情况下逐步过渡到以我为主（规划需求设计）、厂商为辅（开发测试运维），同时建设自主研发团队纳管云管平台建设。
5、团队方面：容器技术本身较难，需要技术研发团队进行新技术的调研、二开、应用的开源治理工作，同时运维支持进行问题排查工作；同时由ITIL流程逐步转换为较为轻量级的DevOps流程来适配容器云平台建设和应用，这需要从制度流程上和团队思维上进行逐步改变；
6、应用方面，应用包括稳态和敏态，容器适合敏态业务的应用（或者互联网应用）。传统应用根据整体规划逐步向微服务演进，一般的传统应用进行无状态改造后可直接上容器；非常厚重的应用需逐步改造为微服务，微服务拆分可按照业务进行拆分。一方面摸着石头过河，一方面最重要的是在改造过程中建设微服务规范和应用适云规范，逐步推广，这是一个长远建设的过程，需要加强技术人员支持。

**回复2：**目前来看，K8S+Docker已经是大势所趋，可以作为容器云平台的核心。当然，一个完善的容器云平台不能只是K8S+Docker，还需要一个统一的自服务管理平台，需要配套的应用日志处理系统、监控系统、DevOps流程和工具体系、资源申请和管理体系、应用容器化改造规范等。这些方面，涉及大量的定制化，市面上不一定能找到合适的产品，如果具备自研能力，可以自己自主设计开发。如果不具备，可以考虑采购一些产品，快速形成能力，并要求厂商支持定制化开发。
容器天生是要求微服务的，所以做应用容器改造实际上就是一个应用微服务化的过程。传统应用里，如果以前都是按照模块化方式开发的，改造起来相对容器，只需要把模块改造成微服务，通信方式从IPC换成RPC，并对日志输出方式做一定改造。如果不是模块化的，改造难度会比较大，可以尽量做一些拆分，让单个容器不要承担太多的功能和压力。

**回复3：**云平台不只是容器云，容器云可以是其中的一部分。集团考虑云计算平台作为数字化转型底座，可以考虑构建统一的基础设施平台，包括IaaS和PaaS，技术实现有很多种，容器云只是其中一部分。
考虑资源管理和应用管理分离，通过租户机制实现使用资源满足应用运营管理需求。
需要构建企业级PaaS平台，支持多集群、多数据中心部署
选型容器云，需要自身具备自主控制能力，否则不建议实施容器云。
采用容器云可能需要同步考虑微服务架构，实现业务应用的改造，能够发挥容器的特性

**回复4：**1.首先需要统一认识，使用容器需要解决什么问题。
2.公司需要有对容器比较熟悉的人牵头建设，或者与容器厂商共建
3.k8s和docker基本能满足大部分的需求，不过容器化建设的难点还在于存储，网络还有与基础设施整合，流程制度等等一切
4.先试点非关键应用，需要频繁变更应用或者需要快速扩缩容的应用，或者是敏捷性应用。

容器化改造容器云平台

著作权归作者所有

如果觉得我的文章对您有用，请点赞。您的支持将鼓励我继续创作！