云平台运维管理详细设计.docx
《云平台运维管理详细设计.docx》由会员分享，可在线阅读，更多相关《云平台运维管理详细设计.docx（13页珍藏版）》请在冰豆网上搜索。
云平台运维管理详细设计
云平台运维管理详细设计
容器云平台运维架构和容器云平台的架构设计紧密相关。
容器云平台的架构会直接影响着其运维架构的设计。
我们在设计容器云平台的时候，就从DevOps的思想角度出发，就考虑到了开发、测试和运维之间的协作和配合，因此定义了以镜像仓库为媒介，明确分离开发、测试和应用运维职责。
把镜像仓库作为标准化交付库，把应用服务整个生命周期过程就划分为三个阶段：
开发、测试和应用服务运维（应用运维和资源运维分两层）。
应用服务的管理和运维是整个容器云平台的核心。
运维运营能力是整个DevOps过程中最重要的一部分，是企业创造新价值的支撑。
在数字化转型4T（指的是IT信息技术、CT通信技术、DT数据技术、OT运营技术）融合的时代，运维运营是关键。
容器云平台的运维狭义的说是容器云平台自身的运维及对平台运营支持；广义的说也包括容器云平台之上业务应用服务的运维运营支持。
我们在设计容器云平台时，定义了容器云平台“以应用管理为核心”，是从广义上来定义容器云平台的运维架构。
作为传统企业用户，我们觉得不能只关注一个平台或者一个工具，更要关注其价值或潜在的价值在哪里，更更好的协助、配合相关部门团队取得价值，这样我们的运维工作才真的更有意义和更有价值。
毕竟我们不是互联网企业，侧重点不一样，容器云平台、云管平台等都是基本的工具，都是为了更好的服务好业务团队，因此在设计容器云平台架构和定义容器云平台运维架构的时候，更多的是基于实际的需求来确定的。
因此，基于实际的需求考虑，在划分三个阶段的基础上，我们定义容器云平台运维架构包含应用服务运维和基础设施资源运维两个层次。
传统丹田系统的运维运营，通常要自己管理和维护系统的基础设施资源。
但如果采用了容器云平台，就不能从上到下还是自己来维护，否则那运维工作量可能远远超出想象。
也正是基于此考虑，我们将基础设施资源运维和应用服务运维分离，使应用服务运维人员专注于应用运维，基础设施资源运维人员专注于基础设施资源运维。
而又由于基础设施资源类型众多，有虚拟化、私有云、众多共有云等不同类型，需要由多云管理平台来统一管理和维护基础设施资源，并为容器云平台提供标准化的基础设施资源服务。
容器云平台的平台管理员只负责容器云平台的基础设施资源的管理和分配，容器云平台只是使用资源而不运维资源。
同时，为了更好的利用容器的轻量、弹性、无状态等特性，同时又保证满足某些应用和服务的稳定性要求，我们结合容器化部署和非容器化部署各自优缺点，将应用服务管理和治理分为两层体系，容器云平台层和API网关层。
综合上面的思路和分析定义，容器云平台运维架构设计定义为三个阶段、两层运维和双层服务治理架构。
使整个容器云平台运维架构清晰简明，也很便利的划分相关运维人员职责，更好的协调不同团队之间的工作，满足DevOps所期望的减少资源浪费、提升团队协作、提高IT效率、降低业务成本等需求。
一、以镜像仓库为媒介
容器云平台构建了以镜像仓库为媒介的三段过程，使开发、测试和运维分离，既兼顾传统开发运维模式，也满足实现开发运维一体化需求。
（一）开发阶段
开发阶段以交付标准化镜像为重点，以自动化方式编译、打包、提交镜像到测试镜像仓库，这样使开发人员依然关注业务逻辑的设计和实现，同时也要关注满足应用服务架构容器化部署的可扩展性、弹性、高性能等要求，但不需要考虑服务器、网络、存储等来源、管理、监控和维护等事项。
（二）测试阶段
测试阶段以测试镜像仓库为起点，在完成了各项测试任务之后，满足生产部署要求的应用镜像自动化交付到生产镜像库。
镜像不变，则相当于环境不变，从而实现了环境一致性。
在镜像测试部署和生产部署过程中，都能实现分钟级的配置部署，从而提升了效率。
配合标准化基础设施资源的分钟级申请部署，可以在任何测试环境实现快速的测试环境搭建和测试。
（三）运维阶段
运维阶段以生产镜像库为起点，部署、运行、监控、维护业务应用系统，同时需要按需供给这些业务应用运行和业务运营所需的基础设施资源。
这是持续时间最长最重要的过程，也是创造新价值的过程。
运维阶段又可以细分为若干个子阶段和部分，比如持续部署、持续监控、日志管理、服务管理与治理、基础设施资源管理与分配等。
细化这些阶段和部分是为了更好的理解和设计容器云平台运维架构，更好的实现容器云平台的运维能力。
以镜像仓库为媒介，实现了一次构建，多环境部署运行能力。
我们未采用一些人建议的在不同环境都需要打包构建的方式，而是采用“开发环境一次构建，交付标准化镜像，多环境部署运行”的方式，在开发环境一次构建之后，自动上传到测试镜像仓库；由测试人员在容器云平台快速部署构建应用服务的测试环境，可以是多版本并行，通过两层服务治理体系能实现；在完成测试之后，同步镜像到生产环境镜像仓库，然后就可以在生产环境部署运行。
以镜像仓库为媒介既简化了DevOps流程，也提高了安全性和效率。
测试和生产环境可以实现物理隔离，提高了安全性。
虽然构建流程是自动化的，但在不同环境构建既浪费时间和资源，也带来了潜在的不安全因素。
因此，我们采用镜像仓库为媒介这种简单的方式来满足需求，提高效率和安全性。
二、资源运维和应用运维分离
云计算的三层架构（IaaS、PaaS、SaaS）很好的定义了每一层云平台的能力。
容器作为基础的单元，可以作为一种资源，提供运行时环境，可以是在IaaS层，可以通过IaaS云平台或者云管提供容器化服务。
而基于容器而实现的容器云平台，我们认为目的是为了更好支撑应用，简化应用管理工作。
不仅仅简单提供容器服务，否则就复杂化了应用管理的工作。
从云计算的三层体系划分（IaaS、PaaS、SaaS）考虑，我们把容器云平台定义为轻量化PaaS平台。
容器可以作为资源放在IaaS层，但容器云平台一定是在PaaS层。
因此我们设计的容器云平台的四层架构（基础设施资源层、资源调度层、平台层、应用层）很好的解决了应用运维和资源运维的耦合问题，将基础设施资源运维和应用运维分离，使专业的人员用专业的技能去完成专业的事项。
（一）基础设施资源运维
容器云平台的重点并不在基础设施资源运维。
基础设施资源可以通过IaaS层的标准化资源服务来提供。
在容器云平台，平台只是使用基础设施资源而不维护基础设施资源。
租户使用申请或分配的资源来部署运行应用，而不需要考虑基础设施资源的维护和运营，这样就把重心放到了应用本身，按需申请和使用资源。
而不同的云资源也很好的提供了备份、迁移、容灾等能力。
应用服务的部署运行离不开基础设施资源的支持，但对租户来说，基础设施资源应该是透明的。
在基础设施资源维护方面，私有云也需要借鉴公有云的思想。
租户关心的是业务应用，透明的按需申请使用资源。
云厂商越来越多，提供的云资源类型也各不相同，对于任何一家公司来说，必须要整合这些不同的云资源，以标准化资源服务的形式才能更好的支撑企业业务运营。
这就需要依托多云管理平台，通过基础设施资源的整合和融合，构建统一的基础设施资源服务；容器云平台所使用的基础设施资源如CPU、内存、存储、网络等资源由云管平台进行统一的管控和分配，租户只是使用基础设施资源而不需要维护基础设施资源，使他们专注于应用的管理运维。
容器云平台基于云管的抽象定义并提供集群、资源分区、节点、CPU、内存、存储等资源供租户按需使用。
容器云平台也可以根据配置规则在资源不足时自动扩展资源，并同时告警提醒，以提醒租户管理员和平台管理员能及时地检查并更改资源分配。
基础设施资源的维护和纳管不是在容器云平台来实现，而是由多云管理平台来实现。
容器云平台（定位于轻量化PaaS）只是使用标准化基础设施资源而不维护资源。
多云管理平台维护管理私有云、公有云、内部物理服务器、存储、网络、超融合等资源，通过多云管理平台提供标准化的资源服务。
这样也清晰的定位了云管平台和容器云平台的职责，在企业内构建容器云平台和使用内外部不同类型的私有、公有云资源时，整个一个云运维架构结构清晰、职责明确、功能范围合理，容易理解和构建。
1.多云（IaaS）管理平台
市面上多云管理平台几乎包含了云计算的三层能力，导致很多企业在建设云平台时依然面临着单体、重复建设等问题。
不得不在公司内部建设很多朵云，这些云往往难以融合，这是一个很大的问题。
因此，云平台的建设一定需要考虑分层。
从目前云市场的现状来看，更多的还是提供基础设施资源服务和SaaS服务。
PaaS服务很不容易。
PaaS可以认为是云操作系统，提供操作系统级的平台服务。
从实际的需求出发，为更好的服务于企业业务应用生命周期管理，界定多云管理平台的能力。
把多云管理平台划归于IaaS层，而不是跨云计算多层能力，这就比较清晰的定义了云管平台的能力和功能范围。
云管平台的职责是纳管IaaS层的不同类型的资源，抽象并输出标准化资源服务。
而平台服务（PaaS）和应用服务（SaaS）不在云管平台实现。
比如应用部署、中间件服务等。
应用管理和中间件管理都是在PaaS层，而PaaS则支撑SaaS层服务，比如消息服务、财务服务等。
应用部署时由PaaS平台调度云管平台提供的标准化资源，比如，可以把应用调度到阿里云、腾讯云、或者华为云，这项调度是由PaaS平台来实现的，调用云管平台抽象封装过的阿里云、腾讯云或者华为云的标准化资源服务。
所以，为更好的支撑业务应用，需要明确多云管理平台是管理不同的IaaS云资源，包括私有化基础设施资源。
它不应跨层去管应用或者提供SaaS服务。
2.资源分区
资源分区是我们抽象定义的一个资源管理对象。
目的是为了给容器云平台提供标准化资源服务。
基础设施资源可以来自于公有云、私有云、虚拟化、物理服务器、各种存储、不同的网络类型等。
通过资源分区抽象之后，把不同类型的资源都划分为一个个标准化的资源分区，分配给租户，租户按需部署调度应用服务到相应云资源分区中，实现业务部署需求。
（二）应用运维
容器云平台提供平台级的服务能力，为业务应用的部署、运行、监控、升级、维护等提供平台支撑。
应用管理和维护是容器云平台功能实现的核心。
容器云平台建设的目的是为了支撑企业业务应用，实现业务应用微服务化的统一平台部署和运维管理。
把容器云平台建设成为企业级应用管理平台，采用微服务架构，实现业务应用的整合与重构、快速响应业务需求。
因此，容器云平台应用管理是其核心功能。
应用运维包括应用的部署、运行、弹性伸缩、灰度发布、运行时监控、运行时配置更新、升级、服务管理与治理、租户隔离等。
1.租户隔离
多租户的设计既可以满足不同业务场景合规上的隔离要求，也可以根据业务需要进行业务租户的整合和分离部署管理。
由于Kubernetes并没有租户的概念，因此不同的容器云平台对租户的定义可能是不一样的。
有的租户对应Kubernetes的namespace，有的则独立于Kubernetes的单独对象。
基于我们的容器云平台架构，在平台层定义租户，一个租户下可以管理一到多个应用，每个应用对应于Kubernetes的一个namespace。
每个租户有租户资源限额，为了支持应用下服务实例的弹性伸缩需求，namespace则不做资源限额控制。
2.持续部署
持续部署并不适合所有应用场景，因此是否需要实现持续部署能力，要根据业务需求来确定。
持续部署更多可能在测试环境，快速部署应用服务满足bug修复验证、回归测试等要求。
传统企业生产环境往往追求的是稳定，和互联网企业是不一样的，因此在设计实现运维架构和运维能力的时候也要从实际需求出发来确定。
3.弹性伸缩
弹性伸缩是容器云的重要特性，也是采用容器云的重要原因。
我们定义应用管理为应用、服务、实例三层对象管理机制，实例运行在容器中，是支持分布式部署的微服务实例，借助容器的特性和规则定义可以实现微服务实例的弹性伸缩。
4.灰度发布
灰度发布能力主要用来验证新版本的功能，导入或者复制部分实际流量来实现生产验证。
基于服务治理的两层负载分发能力，可以根据需要在API网关层或者容器云平台层进行流量分导和分发。
5.运行时监控
应用服务运行时的状态、流量、资源使用量、响应时间等是判断业务应用实例运行状况的依据。
实时的数据采集和展示是应用服务运行时监控和管理的基础。
容器云平台的平台层对容器运行时数据采集和存储及处理，为业务应用服务的管理和维护提供了数据支持，也为持续的监控管理及趋势分析提供了数据基础。
6.服务运行时配置动态更新
业务应用服务运行时配置的动态更新是应用敏捷运维的要求。
在不需要重新部署应用的情况下，通过配置中心配置的更改，下发给业务服务实现自动配置更新，对于特殊环境或者情况下无法重启应用或者服务，就显得非常重要了。
例如某些情况下，需要打开应用服务的debug日志，如果重启服务则可能无法重现当前异常，如果能支持运行时配置动态更新，则会方便的多。
7.升级/多集群容灾
升级包括平台升级和应用服务升级。
容器云平台多集群设计一个重要的需求场景就是平台升级不会影响业务的运行，对客户不可见。
同时支持业务应用的容灾备份需求，可以部署应用服务到位于不同机房或数据中心的集群中，满足业务多地多中心的容灾备份要求。
8.服务治理双层体系
服务治理实现容器云平台层和API网关层双层服务治理能力，在容器云平台借助容器的特性实现服务的注册、负载均衡、灰度、自愈、弹性伸缩、容灾备份、链路跟踪、拓扑展示、日志、监控等能力，在API网关层则实现服务的认证、访问控制、路由分发、转换、过滤、限流、熔断、访问统计等能力。
（三）平台运维
把容器云平台自身的运维单独拿出来简单说几句。
应用、容器云平台和基础设施资源的关系是平台使用基础设施资源支撑业务应用。
通常容器云平台自身运维也比较简单，没有太多工作量，主要是平台运行状态的监控和组件的维护、升级事项。
1.多集群
容器云多集群场景下部署架构可能是不一样，不过多集群运维基本相同。
集群的部署、节点的维护、集群运行监控、集群升级等是日常的运维工作内容。
2.中间件
容器云平台很重要的一个能力是提供中间件平台化能力，比如消息通信、数据存储、日志采集及处理等。
在容器云平台测试环境，为支撑快速敏捷构建业务场景测试环境，选择容器云平台上的服务组件（中间件）如kafka、redis、mysql、rabbitmq、jenkins、git等实现一键部署和回收，保证环境的一致性和无污染性。
三、应用运维服务治理双层架构
应用管理能力是容器云平台的核心能力。
主要实现应用服务的部署、运行、监控、升级、维护、治理等运维能力。
在应用服务的治理架构设计上，为了充分利用容器的特性和特点，同时兼顾不同业务的稳定性等需求，我们定义了应用运维的两层治理体系，一是利用容器云平台的服务治理能力，充分发挥容器轻量、弹性、无状态等特性；二是利用API网关管理全局API和OpenAPI接口的能力，实现API的全局的服务治理能力。
（一）容器云平台层
容器云平台基于Kubernetes的能力基础上，实现对Kubernetes的封装和扩展，在Kubernetes之上实现了PaaS平台层能力，更好的支撑业务应用服务管理和治理需求。
Kubernetes提供了容器服务的部署、运行、调度、注册、路由分发等能力，但在服务治理方面也有一定的局限性，比如按照服务的响应时间进行流量分发，如果没有平台层则比较难以实现。
只有在平台层记录了请求的响应时间，才能对比不同实例的处理能力，才能将更多的请求分发给响应快的服务实例。
而不是默认轮询的方式，可能导致某个实例压力大而出现超时等问题。
同时还有限流、熔断等都可以在容器云平台层实现，而不用在服务代码中实现。
容器云平台“三视角、四层次、一闭环”的架构很好的满足了应用开发、运维的需求。
也为服务的管理、治理提供了良好的架构支撑。
（二）API网关层
API网关提供了一层稳定的可重用接口层。
API网关在ESB时代就已经广泛应用于对外集成API的管理和治理。
微服务架构使API网关的作用越来越重要。
其不但可以对外提供安全的OpenAPI服务，同样也可以在企业内部实现内部API的管理和治理。
API网关同时可以提供安全的保护能力，阻止客户端应用以非安全和非管理的方式直接访问API，保护企业内外开放的应用接口API。
这是API网关最重要的能力之一。
同时API网关也隔离内外服务也就减少了对外暴露服务的可能性，增加了系统的安全性。
可以在API接口层实现授权认证、访问控制、防范威胁和OWASP漏洞、防御性缓存、通过SSP和统一身份管理等方法来提高安全性，为应用程序、移动和IoT提供端到端的安全机制。
也可能需要在API网关实现流量控制、分流、过滤、熔断、服务优先级控制、超时处理、负载均衡等机制来保护应用服务的安全。
将安全、访问控制等非业务逻辑功能从微服务设计实现中分离出来，也使微服务的设计和实现简化，使微服务更轻盈、更便捷。
这是我们在做微服务设计时很重要的一个考量点，也和容器云平台部署微服务时充分利用容器轻量的特点相匹配。
从API网关的定位和能力来看，主要可以在网关层实现微服务的安全认证及访问控制（包括路由、转换、流量控制等），同时API网关也提供注册发现、日志记录、流量监控、服务编排、负载均衡等能力。
利用这些能力，可以便利的实现微服务的治理，天然融合，无需再开发或者部署一套微服务治理平台或工具，也不用为不同平台之间的集成花费人力物力财力和珍贵的时间。
四、周边支撑体系
目前配合容器化PaaS平台建设的基础上，已经规划或者正在推进集中日志中心平台、统一身份认证和权限平台、kafka消息平台、配置中心、注册中心、统一监控平台、APM等基础技术中台支撑平台的建设。
（一）统一身份认证和权限中心
统一身份认证平台实现企业员工和企业业务客户两级身份管理认证能力，支持多种认证方式、多因子认证和单点登录。
权限中心则实现员工和用户的基于角色的系统和应用的安全访问控制准入机制（RBAC）。
企业新建系统和应用通过统一身份认证和权限中心提供的标准化API，实现登录认证和访问控制的统一管理。
避免重复建设和浪费，更节省时间，实现敏捷响应。
身份认证和权限管理是所有系统的必需组件，因此首先规划和构建统一身份认证和权限中心平台是关键的第一步。
（二）集中日志中心
集中日志中心实现对企业内应用、系统、工具、平台等所产生的日志的统一标准化采集、分类、存储，提供查询、搜索、分析等服务能力，可结合大数据平台数据处理和分析能力、人工智能平台机器学习、模型构建、模型训练等能力，逐步实现企业级智能化监控和运维能力。
（三）配置中心
配置中心实现企业业务应用和平台、工具配置文件和配置信息的统一管理，以支持业务应用的运行时实时更新能力，减少应用和系统重启所带来的影响，更提升敏捷的响应能力。
（四）统一监控中心
统一监控中心实现应用和系统的全链路监控和跟踪。
可以规划两层监控体系：
基础设施资源监控层和APM（ApplicationPerformanceMonitor）层，实现业务应用监控信息的实施下钻钻取能力。
1.基础设施资源监控
基础设施资源监控要实现对基础设施资源的运行状况、资源占用等情况进行分层分类采集，以支持应用和服务的运行时监控钻取能力
2.APM
APM实现对业务应用和服务的运行状况进行监控，同时根据应用运行所在节点资源使用情况，跟踪分析、定位应用和服务运行过程中的异常，预警潜在的异常问题，保证业务应用和服务的良好运行。
3.告警
短信、邮件、微信等告警渠道配合监控体系，及时通知相关运维人员进行检查和维护。
（五）消息中心
消息中心实现消息中间件能力，提供消息交换机制API接口，目前在用的TIBCOEMS和kafka工具提供消息中转服务。
同时可能需要考虑构建端到端消息通信机制。
在企业内多种消息平台可能需要并存，并根据业务场景选择合适的消息处理机制。
1.Kafka平台
Kafka支持大量消息并行处理，适合处理应用、系统日志类消息。
不适合消息顺序处理场景。
Kafka消息通过server中转，对于消息延迟比较小的场景可能也不合适。
2.JMS平台
JMS消息中间件也比较多，比如商用的TIBCOEMS、IBMMQ等，开源的RabbitMQ、ActiveMQ等，都提供稳定的轻量级JMS 消息服务。
JMS消息中间件提供简单易用、稳定的发布订阅和请求应答消息处理机制，相对轻量。
延迟通常在毫秒级，普通业务可以满足需求。
3.端到端消息平台
端到端消息处理平台实现了消息在两端之间的通信，延迟小，通常在微秒级，特定场景可以达纳秒级，适合极低延迟需求业务场景。
例如TIBCOFTL，Solace等。
五、容器云平台运维典型问题案例
容器云平台架构和运维架构尽管很清晰，但运维过程中依然会遇到各种各样的问题，比如资源碎片的问题、资源争抢的问题、多集群部署问题、不同环境需求和定位问题等等。
（一）部署运维资源碎片问题
每个容器或者每个Kubernetespod就是一个独立的整体。
分配给该容器或者pod的资源其他容器或者pod是不可以共享的。
而每个容器节点资源总是有一定限量的。
如果pod的资源分配不合理，就可能导致容器节点的资源虽有剩余却无法调度更多pod运行，导致资源碎片的产生。
而且不同的应用服务需要的资源类型也可能是不一样的。
比如有需要CPU优化的、有需要内存优化的、有需要存储有优化的等。
虽然说通用的资源类型可以满足大部分需求，但不同的资源类型需求也或导致一些资源的碎片和浪费。
特别是容器云需求体量不够大，可能会有更多的资源冗余和浪费。
（二）虚拟化超分可能导致容器资源争抢问题
如果容器云平台是部署在虚拟化平台之上的，已经经过了一层虚拟化，很可能导致在忙时容器出现资源争抢的问题。
为了更好的利用资源，虚拟化通常会超分一些资源，例如CPU会按照1:
2或者1:
3甚至更高比例分配资源。
在通常情况下可能运行正常，不会出现资源争抢问题。
但在某些时点，不同应用的实例调度到同一个节点，而这些实例正好又都在同一时刻繁忙起来，就可能导致资源不足，服务响应缓慢。
当然可以通过监控和治理手段实现服务的重新调度，解决资源争抢的问题，但这样的问题往往比较难以避免，也需要在运维时进行关注。
（三）容器注册问题
如果使用SpringCloud等微服务框架，微服务注册到Eureka等注册中心，则注册的是容器的IP，可能无法直接访问。
容器网络分为underlay二层和overlay三层网络，underlay会占用企业众多IP资源，但可以企业网络内访问；overlay虚拟了一层网络，其容器网络无法直接和企业网络互通，因此如果注册overlay容器网络，就无法从企业网络访问注册中心中注册的服务地址。
（四）应用服务多集群部署问题
多集群环境下，应用服务在集群之间的调度可能会是一个难点。
因为服务在不同集群之间调度会可能会涉及服务的注册发现、配置等问题。
注册发现和配置是集群级或者是平台级的所面临的运维工作是不一样的。
从多集群设计基本原则来说，尽可能避免跨集群调用。
跨集群调用会使整个运维工作非常复杂化，因此服务的注册发现尽可能使用容器平台自身提供的机制，配置管理则可能复杂一些。
应用服务在不同集群的配置可能是不一样的，但通常情况下要使各个集群内的配置尽量保持一致。
在应用服务向不同集群调度时，选择目标集群的配置中心，并检查和确认配置。
（五）容器云平台测试和生产环境不同定位问题
传统企业中，容器云平台生产环境和测试环境的需求和定位是有区别的。
测试环境追求的可能是敏捷的构建业务应用测试所需的各种组件服务测试环境，而生产环境追求的可能是稳定运行、平滑升级，而不是频繁的部署更新。
不同环境的需求不一样，定位也就不一样，功能实现也会有差别。
不是说一个容器云平台就可以打遍天下，而是根据实际的需求来确定部署的组件和能力。
升级会员 