不同的公司容器云平台的建设思路和方法可能是不同的，会有差别，但对运维人员来说，首先要明白运维的范围和内容。
（一）梳理要运维哪些内容
作为运维人员最重要的职责是采用一切合适的方法保障系统的正常运行，从而保障业务的正常运营。一旦系统出现问题了，就会影响到业务，可能影响到客户，可能会带来损失，因此运维人员要对自己的运维内容有清晰的认识。才能定义设计合适的部署架构，运维架构。
容器云平台运维可能包括基础设施资源运维，比如服务器、存储、网络层、操作系统等，也包括容器云平台自身的运维，Docker，kubernetes，镜像仓库，Portal、数据库、ETCD、ingress等，还会涉及日志、监控、告警、认证权限、配置等，更重要的是支撑应用的运维，应用的部署、迁移、运行状况查看、监控、告警提醒、扩容、弹性伸缩、配置更新、流量分发管控、负载均衡、访问控制等等都是容器云平台制成应用运维的能力。
（二）明确运维的工具和手段
软件运维不是靠赤手空拳，从效率方面讲借助于工具的运维效率是成级数倍的。因此需要熟练掌握和使用运维工具，运维方法。
GoogleSRE其实就是一个专职做运维工具的团队，借助于工具化不但提高运维效率，也提高了系统的稳定性和可靠性。自动化运维工具、监控工具、配置管理工具等等都是在日常运维过程中不可少的。
（三）选择运维架构
不同的系统运维方法和运维架构也是不一样。容器云平台有其独特的特点，不同于传统系统的运维。对运维人员来说，最大的要求就是确定性。容器的弹性、自恢复、自动迁移等特性在带来便利的同时也带来了不确定性。特别是在庞大的云计算环境。不确定性会对运维人员来说面临着巨大的压力。因此作为运维人员就需要选择合适的架构来规避不确定性和不稳定性。结合容器云平台的特性和API网关组成两层服务治理体系，在提高安全性和可靠性的同时也充分利用了容器的轻量弹性特点。
（四）开发测试和运维工作的差别在哪
我们都知道做运维和开发测试工作是不一样的。开发追求敏捷、快速，所以这些年DevOps大行其道。但运维可能就是另外一个方向了。运维追求的是稳定与可靠性，每次变动都会存储风险，所以尽可能稳定。但完全稳定是不可能的，运维就需要实现一种动态的稳定，这和容器的弹性和可迁移性非常匹配。
（五）DevOps和SRE的精髓在哪里
DevOps追求开发运维一体化，但在国内并没有多少人真正思考DevOps该如何落地。GoogleSRE我觉得是一种非常好的实践，他并没有要求开发人员去做运维，而是很多运维人员去做开发，而开发的主要是运维工具。所以我们看到国内很多DevOps的宣传其实都是很片面的，并不是基于实践的总结，而是概念的炒作。当前云计算环境下的运维已经不同于传统的应用系统运维。当前应用系统逐步的融合、微服务化，以云计算为底座，云就像一个大的容器，docker是这个大的容器中的小容器，承载微服务应用的敏捷部署和弹性伸缩等能力。
所以运维重点还是要保障系统的稳定性，但侧重在采用或自主开发众多的、适合自己的运维工具来协助提升运维效率和系统稳定性。
其实，认真想一下，谁开发谁运维，一个开发人员能开发几个服务几个应用？开发和运维的工作量基本上是2：8，所以一个开发人员如果同时也做运维的话，就会陷入运维之中，也无法体现效率。
二、运维架构设计
基于上面的思考，那么对于容器云平台来说，该如何设计其运维架构？首先镜像仓库是一个神一般的存在，用好镜像仓库将非常省力。
（一）镜像仓库的作用
一个镜像仓库可以同时配置给不同的集群，甚至不同的容器云平台。这些集群和平台是可以共用同一个镜像仓库的。基于这些考虑，我们就把镜像仓库作为容器云平台不同环境之间的媒介。测试镜像库隔离开发和测试，生产镜像库隔离测试和生产，镜像仓库之间可以实现镜像的同步，或者下载上传操作。
镜像保证了在不同环境中部署的环境一致性。实现了应用分发的标准化。而存储镜像的镜像仓库就很好的充当起应用标准化接收和分发的能力。镜像仓库就可以作为一个中转连接站，将开发、测试、生产隔离，在提高安全性的同时也提高了稳定性。
（二）实践SRE
SRE非常注重运维人员的开发能力，而不是开发人员的运维能力。所以SRE其实是全能人才。在国内很多人对运维有误解，觉得不懂开发的人才去做运维。如何提升运维的效率是运维人员需要关注的问题。而采用工具，自动化是必要的运维手段。为了更好的使专业的人员去做专业的工作，将资源运维与应用运维分离。
（三）运维分层
从运维的内容我们知道，运维从基础设施资源、到平台、到应用的维护都是运维人员的工作内容。所以作为运维人员要维护这么多内容，往往是比较困难的，所以一个比较好的方法是把运维内容划分为不同的层次，基础设施资源、平台、应用。这样运维人员可以更专注自己的工作，更好的提供服务。
（四）接口标准化
要高效协同，定义标准化接口是必须的。就像基础设施资源团队提供基础设施资源服务，需要标准化的虚拟机接口服务（云管平台来实现），这样才能做到敏捷扩展，或者动态扩容。
（五）流程自动化
运维架构中要想提高运维效率，就需要考虑运维流程的自动化，减少人为的介入和干预。比如虚拟机申请，尽量不要众多的审批节点。完全自动化。像ip地址网段、虚拟机配置、操作系统参数调整等都可以在扩容虚拟机之前定义好，根据不同的需求自动来创建分配（按规则定义自动化创建）。
（六）将资源运维与应用运维分离
资源运维相对比较简单，就是运维我们常用的服务器、网络、存储、虚拟化、超融合等基础设施资源。这些工作大部分是相对标准化的，通常可以采用自动化方式来实现。也没有太多的开发工作量，基本上有一套监控管理系统就可以了。不过随着多云资源管理需求的普及，多云资源管理可能会有一些复杂度。
资源运维同样需要不同专业的人员，比如网络、存储、虚拟化等。这些人员专注于基础设施资源的维护，为容器云平台或容器化PaaS平台提供资源服务。
（七）应用运维是核心
我们一直觉得应用运维才是容器云平台的核心。因为最终是为业务应用来服务的。应用运维通常是在平台提供的应用管理的能力下，由业务应用使用团队来负责应用的运维，研发团队给予支持。容器云平台的能力就成为了关键。如果容器云平台能提供完善的部署、监控、弹性扩容、灰度、负载策略、访问控制、统计查询等等能力，对应用运维人员则使运维工作非常简单。
（八）平台和组件支撑应用运维
容器云平台的能力在于平台和平台周边组件所实现的能力。平台和组件需要持续的完善和优化，才能更好的支撑应用运维的需要。我们觉得这是容器云平台运维的重点。需要容器云平台运维团队来持续的开发和建设运维工具、流程、方法来优化容器云平台运维。
（九）微服务架构微服务治理是难点
应用运维中，微服务架构下，服务治理可能是个难点。微服务架构带来了服务运维的复杂度，服务的部署、迁移、弹性伸缩、流量分发、内外部负载均衡、高可用、稳定性等需求对容器云平台支撑的应用运维能力要求很高。选择了什么样的微服务架构，如何更好的管理治理好微服务，是容器云平台不得不考虑的一个重要问题。比如微服务中实现了注册发现，比如用springcloud的开发框架，已经有了一套自己的服务治理方法，如何跟容器云平台更好的融合？开发的微服务是否需要自己去实现注册发现，流量控制，熔断降级等机制，或是简单可以在容器云平台来实现？
我们有个需求是根据响应时间来弹性扩容。我们没有采用cpu内存作为弹性伸缩的指标，因为cpu内存是不准确的。Java内存机制不适合采用内存方式，而cpu变化又太快，如果拉长时间则可能导致延误，出现大量超时。所以根据响应时间作为扩容指标则相对更优。那么这就需要在服务网关或容器云平台或者api网关来实现了。服务网关的话需要开发人员自己实现，每个团队都需要部署个这么的网关，明显不合适。在容器云平台如果实现这样的能力，则每个服务都可以直接使用。形成了标准化。
因此，在容器云平台可以把服务治理能力固化，既可以减少开发工作量，也提高了运维的效率，降低了运维的难度。
（十）两层治理体系
把服务治理划分为容器云平台层和API网关层则可以更好的利用容器的特点，同时又保留了虚拟化部署、物理服务器部署的应用服务治理的需求。
在传统企业向云迁移的过程中，还有众多的系统可能不适合容器化，或者目前阶段不能完全容器化（稳定压倒一切），因此目前可以考虑利用API网关来实现两层的微服务治理体系，更好的管理和维护微服务应用。
总的来说,我们定义了容器云平台的“镜像仓库为媒介,将开发测试运维分离,应用管理为核心,将资源运维、平台运维和应用运维分析,实现容器云/API网关两次服务治理体系,既利用容器的优点,也尽可能规避其弱点”。
