【云计算】打造高效容器云平台：规划、部署与架构设计

引言

随着移动互联网时代的大步跃进，互联网公司业务的爆炸式增长发展给传统行业带来了巨大的冲击和挑战，被迫考虑转型和调整。对于我们传统的航空行业来说，还存在传统的思维、落后的技术。一项新业务从提出需求到立项审批、公开招标、项目实施、上线、交付运维，没有一年半载下不来。而此中最为严重的问题是，系统交付时的功能可能已经偏离最初的需求，系统使用方不满意，IT人员觉得付出的劳动没有被认可，双方矛盾加剧。大力发展移动互联网业务，因此对业务需求的响应速度有了更高的要求，越来越多传统应用架构，为了适应不断变化的业务需求和难以预估的访问量而开始进行分布式改造、微服务改造，实现持续集成、持续发布、自动化测试、支持弹性伸缩、灰度发布、蓝绿部署等能力，容器云平台恰恰可以很好的支撑上述需求。容器技术是近些年来最火爆的技术方向之一，容器云能更好服务于应用，不断提升客户满意度。按照云计算的三种类型，建设PaaS(Platform as a service)平台将有助于我们实现这些目标。

目前许多公司采用了VMware技术完成了Iaas虚拟化建设，而IaaS虚拟化层仅提供了对存储、网络、计算资源的管理，在IaaS上即使经过了深度的定制化自动改造，流程走完时也是普遍在交付时将带有应用软件及软件配置的一台虚拟机交付到申请者手中，申请者需要自己通过IP登录到机器上部署相应的应用，更不用说各应用组件之间的配合设置。而在容器平台中从代码开发集成到一个容器镜像打包了应用程序和运行环境，加上容器的配置文件，一整套流程走下来时，应用已经可以直接上线了，负载均衡，安全策略都可以具备，可以说容器云平台是Devops理论的最佳实践。

对于容器平台的建设，从初期就需要做好平台的整体规划，切莫为了容器化而容器化，还是要因地制宜，寻找平衡点逐渐落地，混合实施，了解开发运维等多方面的需求、平台相关技术的原理机制，团结开发、运维、用户等才能共同设计好一个容器平台。

本文基于对容器云平台的应用和研究，详细探讨容器云平台的规划部署和架构设计。

1 云基础架构介绍

1.1 IaaS/PaaS/SaaS

IaaS：基础架构即服务

云基础架构服务称为基础架构即服务（IaaS），由高度可扩展和自动化的计算资源组成。IaaS是完全自助服务，用于访问和监控计算、网络，存储和其他服务等内容，它允许企业按需求和需要购买资源，而不必购买全部硬件。

PaaS：平台即服务

云平台服务或平台即服务（PaaS）为某些软件提供云组件，这些组件主要用于应用程序。PaaS为开发人员提供了一个框架，使他们可以基于它创建自定义应用程序。所有服务器，存储和网络都可以由企业或第三方提供商进行管理，而开发人员可以负责应用程序的管理。

SaaS：软件即服务

软件即服务（也称为云应用程序服务）代表了云市场中企业最常用的选项。SaaS利用互联网向其用户提供应用程序，这些应用程序由第三方供应商管理。大多数SaaS应用程序直接通过Web浏览器运行，不需要在客户端进行任何下载或安装。

1.2 CaaS（容器即服务）

CaaS（容器即服务）——相对于IaaS和PaaS服务，CaaS对底层的支持比PaaS更灵活，而对上层应用的操控又比IaaS更容易。CaaS是以容器为核心的，它介于IaaS和PaaS之间，起到了屏蔽底层系统IaaS，支撑并丰富上层应用平台PaaS的作用。将底层的IaaS封装成一个大的资源池，我们只要把自己的应用部署到这个资源池中，不再需要关心资源的申请、管理，以及与业务开发无关的事情。

2 容器云平台功能架构

2.1 集群框架

集群框架是容器集群管理及编排系统。目前国内外的容器云管平台有很多，目前选型都倾向于选择基于Google Kubernetes为主的容器管理平台。直接采用Google Kubernetes进行二次开发，但是一般开发成本相对较高，相对比较复杂，为了节约项目成本，加快项目实施进度，一般企业会采用企业级的混合云容器平台，如Red hat的Openshift平台。

2.2 云持续交付管理（CI/CD）

用户可以创建项目的Gitlab服务，镜像仓库服务以及Jenkins服务，实现对项目的代码以及镜像的管理，运用Jenkins实现项目的持续集成，持续部署，持续交付等功能。不同角色处理不同的业务需求。系统管理员的主要任务是进行集群管理和云持续交付管理。系统管理员可以将部署好的集群添加到容器云平台上进行管理，同时可以进行修改集群，查看计算资源等操作；在集群添加成功的情况下，系统管理员可以选择相应的集群和项目，创建项目Gitlab服务进行代码管理，创建项目镜像仓库服务进行项目镜像的管理，创建项目的Jenkins服务，实现持续交付，持续集成，持续部署等功能。

2.3 多租户管理

在同一硬件平台的基础上实现多用户的环境下共用相同的系统或程序组件，并且仍可确保各用户间资源的隔离性和安全性。在对外运营的云平台中，租户管理用于监控用户使用的资源情况，方便进行资源的可用度计算和租户的计费。而在企业内部中，多租户的用户往往为各个不同的项目组，便于企业内部不同项目之间的隔离。

2.4 跨主机集群

可以将本地云平台内部的容器资源与平台外部的客户自有容器资源，及各种第三方公有云容器资源结合到一起形成混合容器云资源模式，增强平台的包容性，降低用户的使用门槛，同时用户无需放弃自身原有的基础资源。

2.5 镜像仓库

提供本地公有/私有镜像仓库，提供第三方镜像仓库如Quay等的镜像资源集成。可以将本地镜像push到指定的镜像仓库中，也可以查看镜像的版本等信息。镜像仓库可以对平台使用人员应用开发成果进行统一保存管理，平台支持将应用制作成镜像，方便测试和运维。

2.6 应用编排服务

应用编排服务是使容器之间能够通信、彼此可以传递运行期,同时管理多个容器的行为。当容器集群共同构建应用架构时，需要考虑集群环境中的容器，哪些端口需要暴露、哪些卷需要挂载等信息。

2.7 平台支撑服务

容器云平台中需要一些公共服务，基于PaaS之上的公有中间层SDK开发组件或API调用接口，及公有PaaS服务平台。例：用户统一身份认证组件，APP的消息推送组件，公有消息队列平台等。

2.8 容器管控

对容器进行CPU/内存资源配置，SSH或控制台容器接入，网络配置，环境变量设置，数据卷挂接，资源监控，日志管控，事件记录，二级域名或自有域名分配等功能。

2.9 数据卷或云盘

基于云平台的数据存储工具。主要用于容器间数据共享，或某容器的外接数据卷进行数据持久化存储。

3 容器云平台架构设计

容器云在未来有可能会成为云管理平台的统治者，也还会有更多的应用在容器云上原生运行起来。因为对于容器云，它可以把很多分散的物理计算资源抽象成一个大的资源池，利用这些资源来执行用户的计算任务。对于用户来说，操作一个分散的集群资源就像在使用一台计算机。无论是容器技术，还是DevOps和微服务，都说明灵活、弹性、轻量化的IT应用模式逐渐形成。而这种模式的形成对于复杂产品的快速开发有着积极意义。容器云架构方案，划分为六大部分，每个部分承担了重要的职责。具体技术架构如下：

3.1 容器管理方案

Kubernetes的主要功能包括：1.基于容器的应用部署、维护和滚动升级；2.负载均衡和服务发现；3.跨机器和跨地区的集群调度；4.自动伸缩；5.无状态服务和有状态服务；6.广泛的Volume支持；7.插件机制保证扩展性。

Kubernetes提供了很多的功能，它可以简化应用程序的工作流，加快开发速度。这里最佳实践是选择基于kubernetes的容器云平台，以便更轻松地部署、扩展和管理应用程序。用户可以使用Label以自己的方式组织管理资源，还可以使用Annotation来自定义资源的描述信息，比如为管理工具提供状态检查等。此外，Kubernetes控制器也是构建在跟开发人员和用户使用的相同的API之上。用户还可以编写自己的控制器和调度器，也可以通过各种插件机制扩展系统的功能。这种设计使得可以方便地在Kubernetes之上构建各种应用系统。

3.2 平台监控方案

3.2.1 容器监控

容器监控的对象主要包括 Kubernetes 集群（各组件）、应用服务、Pod、容器及网络等。这些对象主要表现为以下三个方面：1.Kubernetes 集群自身健康状态监控（5个基础组件、Docker、Etcd、Calico等）2.系统性能的监控，比如：CPU、内存、磁盘、网络、filesystem 及 processes 等；3.业务资源状态监控，主要包括：rc/rs/deployment、Pod、Service 等；针对容器的整体运行状况及性能状况监控，目前主流的开源监控技术对比如下：

笔者所使用的Prometheus监控方案如下：

3.2.2 主机监控

笔者这边使用zabbix全面采集并监控物理和虚拟服务器的可用性，CPU，磁盘空间和内存利用率等关键性能指标。采集网络中的所有性能指标和事件数据，全面监控网络性能，实时检测网络故障，排除故障并防止停，基于zabbix二次开发辅助功能，用于各类中间件的运行状态监控。

3.2.3 特定中间件监控

提供常见中间件的性能监控(WebLogic、Tomcat、Nginx等)，为中间件镜像制作脚本，中间件监控程序直接整合到容器镜像中，容器一启动，即时上报性能数据到监控平台。可以直接在zabbix监控平台查看中间件的运行状况。

3.3 日志收集方案

容器平台的日志系统一般包括：Kubernetes组件的日志，资源的事件日志及容器所运行的应用的日志。

关于容器日志的收集，笔者整理了之前做过的四种方案，并对每种方案进行对比：

本容器云平台，使用fluentd（以DaemonSet的方式启动）来收集日志，并将收集的日志发送给统一日志平台。

3.4 镜像管理方案

容器云平台中的镜像主要来源：

1、用户私有的镜像仓库；

2、云平台公共镜像仓库；

私有镜像仓库作为用户之间部署镜像的基本隔离，是容器隔离的基础；而云平台的公共镜像仓库提供常用开源镜像的基础服务。

目前常用的镜像仓库有Registry、Nexus3、Harbor、Quay等。

Harbor是一个用于存储和分发Docker镜像的企业级Registry服务器，通过添加一些企业必需的功能特性，例如安全、标识和管理等，扩展了开源DockerDistribution。作为一个企业级私有Registry服务器，Harbor提供了更好的性能和安全。提升用户使用Registry构建和运行环境传输镜像的效率。本课程中选取Harbor作为镜像仓库。

下表是部分镜像仓库的基本功能都对比：

3.5 基础资源管理方案

3.5.1 主机管理

容器云平台的宿主机的接入方式是开放的，主机可以基于IaaS云平台，使用IaaS云平台归集所有计算资源，对计算算资源进行二次分配之后，再接入云平台中；也可以直接基于裸机接入容器云平台；租户可以根据自身使用情况任意添加自己的云主机到容器环境中来；而容器的整体资源限制交给容器管理平台来管理，对容器管理平台的规划是：让容器管理平台管理资源，分配容器，容器所在的操作系统归租户所有。

3.5.2 网络管理

底层容器网络可以使用各种符合CNI格式的插件，如Calico。Calico是一个纯三层网络，没有引入一个DP，没有封包。在主机内部做另外一个容器，可以三条到达终端，你可以知道是谁出了问题，调试的时候很容易，很好管理。容器内的应用数据传出来，和二层完全隔离，对于我们绝大多数的应用来讲只需要三层就够了，很少有应用处理二层。而且Calico支持丰富的网络策略，可以实现多租户管理。

3.5.3 存储管理方案

目标：极快的创建速度，极小的存储资源消耗以及容器迁移的便捷性。

后端存储主要采用Ceph驱动。Ceph独一无二地用统一的系统提供了对象、块、和文件存储功能，它可靠性高、管理简便、并且是自由软件。Ceph的强大足以支撑IT基础架构、和管理海量数据。Ceph可提供极大的伸缩性——供成千用户访问PB乃至EB级的数据。Ceph节点以普通硬件和智能守护进程作为支撑点，Ceph存储集群组织起了大量节点，它们之间靠相互通讯来复制数据、并动态地重分布数据。Ceph在容器云中主要应用场景是有状态服务。包括关系型数据库和nosql数据库等数据需要持久化的业务。

4 总结

CaaS平台衍生出来的整个DevOps体系是至关重要的。Kubernetes起初作为用于容器调度的平台，其虽然实现了从容器到应用、从网络到存储的诸多基础架构抽象，但其本身还是运行于传统OS的诸多应用进程，仍然需要通过必要的设计，来加强自身可靠性。CaaS云平台的使用可以节省开发成本,同时让开发、运维人员将精力更加集中于业务本身，大幅度降低运维难度和成本。而使用OpenStack等云技术提供强大的基础设施管理功能,共享计算资源、存储资源和网络资源,可以灵活的分配资源，为上层提供稳定可靠的资源服务。

---

网安零基础入门
对于从来没有接触过网络安全的同学，我们帮你准备了详细的学习成长路线图。可以说是最科学最系统的学习路线，大家跟着这个大的方向学习准没问题。

同时每个成长路线对应的板块都有配套的视频提供：


当然除了有配套的视频，同时也为大家整理了各种文档和书籍资料&工具，并且已经帮大家分好类了。

因篇幅有限，仅展示部分资料，需要点击下方卡片即可获取，无偿分享。