一. EdgeGallery
简介
MEC场景下的EdgeGallery是让资源边缘化，实时完成移动网络边缘的业务处理，MEC场景下的EdgeGallery让开发者能更便捷地使用 5G 网络能力，让5G能力在边缘触手可及。
EdgeGallery是由华为、信通院、中国移动、中国联通、腾讯、九州云、紫金山实验室、安恒信息等八家创始成员发起的一个MEC边缘计算开源项目。目的是打造一个符合5G 边缘"联接+计算"特点的边缘计算公共平台，实现网络能力（尤其是5G网络）开放的标准化和MEC应用开发、测试、迁移和运行等生命周期流程的通用化。
EdgeGallery 平台采用 Apache License 2.0 作为开源代码协议，并已在 Gitee 发布第一批种子代码。目前，EdgeGallery 社区已在深圳和西安建立了两个自动化测试中心，并将于2020年底在北京、南京、上海、东莞等地陆续建成 5 个场景化测试验证中心。
解决的问题
EdgeGallery要解决的是5G MEC边缘计算平台的标准不统一带来的生态碎片化，产业规模做不大的问题。
MEC本质上是一个面向开发者的ICT基础设施市场，竞争力体现在为应用开发者提供的软件基础平台和工具链的丰富程度，市场结果体现在应用生态的丰富程度。如果没有统一的MEC平台框架，会造成不同运营商/厂商系统的不兼容。应用和解决方案开发者往往需要针对不同平台进行应用的定制开发，这导致巨大的学习成本和开发成本，结果就是大部分开发者无法承受这样的成本而放弃，MEC的应用生态难以发展。通过开源来打造一个公共的MEC平台和相关工具链，就是为了让整个电信产业形成统一的MEC标准，一起做大MEC的市场空间。
关键特性
EdgeGallery的特性：
- 可以将开源应用布置到edgegallery平台上，它有APPStore是一个边缘应用市场，用户可以直接上传边缘应用，经过测试后对外展示。
- 提供开放的API能力，实现二次开发，使得开发者更加方便快捷的开发应用集成到edgegallery平台。
- 快速集成位置信息和调用人脸识别算法服务
EdgeGallery总体架构
EdgeGallery的原生架构设计目的，是为了解决应用复制难、开发门槛高、商业变现难以及行业部署多样化四大问题，总共分为三个功能态，包含应用设计态、应用分发态、应用运行态，孵化出四个子系统：开发者平台、应用仓库、管理平面编排器、MEP平台。
开发者平台：
- AI 硬件能力增强：支持昇腾/Atlas 硬件以及开放 API、ETSI MEC API、3GPP CAPIF 以及昇腾能力支持情况匹配。
- 应用开发设计态框架 ：提供 EdgeGallery 小程序、设计态等。
应用设计平台：
- 部署包设计：通过上传部署应用所需的YAML文件自动生成应用部署的Helm包。
- 应用包设计：部署调测完成后可以继续打包成TOSCA规范的CSAR包
APP 仓库：
- 体验优化：APP 分类、APP 推荐、爆款动态刷新。
- APP store 分布式联邦：实现与三方 APP 仓库的 APP 推送共享、完成 80+ 应用集成、落地近 20 个创新基地等。
编排管理（MECM）：
- 跨平台支持：支持基于 Openstack 的虚拟应用和基于 k8s 容器应用的部署管理。
- 安全增强：应用远程登陆（如 VNC）支持安全全协议登陆、分权分域等。
- 模板管理：该功能没具体介绍，但1.3.0版本的发行说明里面说明了该功能，看上去像是标准化工业平台配置管理
边缘平台（MEP）:
- 按需部署：IaaS/PaaS/应用都支持按需部署、应用框架自动生成。
- 节点服务管理：MEP 微服务管理架构可视化。
- 社区实验室增强：资源一键申请，一键释放，可视化管理。
- 边缘自治：无论是管理面组件还是用户面数据都部署在边缘，在边缘侧分中心集群和边缘集群，中心集群部署EdgeGallery管理面组件，边缘集群部署MEP和MEPM和用户业务。EdgeGallery中的一个边缘节点指的就是一个集群，拥有管理自己业务的能力，其业务通过中心集群的管理面组件下发。
- ETSI协议支持：目前仅MEP符合ETSI协议Mp1规范，Mm3、Mm1等协议均不支持。
EdgeGallery部署视图
下图中的边缘节点和中心节点代表的都是集群，EdgeGallery部署分为中心和边缘两部分，中心集群部。EdgeGallery的管理面组件，包括Developer、AppStore、ATP和MECM几个核心组件，边缘集群部署MEPM和MEP组件，业务通过中心集群的EdgeGallery管理面使用Mm3接口下发到边缘集群的MEPM组件，由于业务运行在自己的边缘集群中，因此拥有一定的边缘自治能力。
各个组件的功能
EdgeGallery各个组件的前端界面基本使用Vue.js渐进式JavaScript框架 开发，MEO相关组件使用Java语言开发 ，MEPM相关组件以及MEP基本使用Go语言开发。组件的详细描述如下：
1.一站式集成开发平台
架构
提供开源开发者统一入口，包括开发流程、开发工具、开放的API能力、集成测试验证，开发者交流论坛等，使开发者更加方便快捷的开发应用并集成到edgegallery平台。
Developer分为前后台两个部分，developer-be是后台部分，提供主要功能接口供前台或其他三方系统调用，developer-fe是前台部分，提供界面展示。其架构设计如下图所示：
- Developer-fe 开发者平台前台框架，使用VUE开发。
- Developer-be 开发者平台后台框架，使用SpringBoot+ServiceComb开发。SpringBoot是由Java编写的Web后端框架，而ServiceComb是一个微服务的开源解决方案，本项目用于实现服务注册和服务发现的功能。
- Developer DB 后台依赖Postgres数据库。
Service Center 是一个服务注册中心，和其他注册中心一样，其主要作用在于解决服务的注册与发现，即动态路由的问题。
能力中心
能力中心是EdgeGallery平台对外提供平台能力和生态能力的API管理中心，开发者在完成应用开发后，如果需要将这个APP的能力开放给其他用户使用，可以发布成为生态应用，开发者也可以使用能力中心的API进行二次开发
EdgeGallery会将该APP的对外接口提供给其他开发人员使用，并且将该服务通过MECM部署在需要的边缘侧，供其他APP能够使用，其API管理功能具体包括以下几个方面：
- 平台提供可用的MEP接口供开发者使用，提高开发者的开发效率，并能够开发出更加实用的App应用。
- MEP接口会持续更新，丰富能力。
- 开发者也可以将自己开发的App通过接口的形式贡献出来，供其它开发者调用。
2.Appstore（应用仓库）
AppStore是开发者发布和上线App应用的边缘应用市场，由Developer平台开发的边缘应用，经过ATP测试后可以直AppStore 是 EdgeGallery 的应用仓库模块，主要负责5G边缘应用的存储与管理等工作，
AppStore分为前后台两个部分，AppStore BE是后台部分，提供主要功能接口供前台或其他三方系统调用，AppStore FE是前台部分，提供界面展示。
架构
- AppStore FE：开发者平台前台框架，使用VUE开发。
- AppStore BE：开发者平台后台框架，使用SpringBoot+ServiceComb开发。（有关ServiceComb请参考这里：https://servicecomb.apache.org/cn/）
- AppStore DB：后台依赖Postgres数据库。
功能详解
EdgeGallery中的AppStore进行了分权控制，不同的用户角色包含不同的特性。
管理员用户包含 应用上传、应用测试、应用发布、应用查询、应用评论、下载/删除所有应用、外部仓库管理、应用推送、应用拉取、消息管理、操作分析、应用管理、沙箱管理、应用在线体验、应用同步、应用变现、文档中心。
租户用户包含 应用上传、应用测试、应用发布、应用查询、应用评论、下载/删除本用户应用、应用在线体验、应用变现、文档中心。
游客用户包含 应用查询、文档中心。
3.ATP（应用测试平台）
应用测试服务对于应用包，提供了检测的功能，只有通过了应用测试服务的测试用例，才能将应用包发布到应用商城中。应用测试服务分为前后台两个部分，atp是后台部分，提供主要功能接口供前台或其他三方系统调用，atp-fe是前台部分，提供界面展示。
功能分类
应用测试服务目前分为管理面功能和用户面功能：
- 管理面功能包括测试场景的管理、测试套的管理、测试用例的管理、模型模型批量导入、测试任务的管理、贡献的管理以及配置项的管理，其中贡献管理的菜单仅管理员可见。管理员可以在管理面动态的新增测试场景、测试套和测试用例，修改测试任务中手工用例的状态，还可以下载脚本类型贡献的测试用例，对于合理的用例，将加入到平台的用例集中。
- 用户面功能包括选择要测试的场景、测试过程可视化、测试报告展示、贡献测试用例以及上传自测报告。目前用户面的功能主要集成在开发者平台和应用商店中，对于生成的应用包进行测试。
框架说明
EdgeGallery中ATP的整体框架流程如下，应用测试平台主要对应图中的认证测试部分。
- atp-fe：开发者平台前台框架，使用VUE开发。
- atp：开发者平台后台框架，使用SpringBoot+ServiceComb开发。（有关ServiceComb请参考这里：https://servicecomb.apache.org/cn/）
- atp DB：后台依赖Postgres数据库。
补充：http://docs.edgegallery.org/zh_CN/latest/Projects/ATP/ATP_Overview.html
4.MECM（多访问边缘计算管理器）
架构
MECM在边缘库架构中提供应用程序的编排和生命周期管理。 MECM 提供各种功能，包括应用程序载入、通过基于部署策略选择适当边缘的应用程序编排、应用程序生命周期管理、基于分析和策略的应用程序归位和放置、应用程序/边缘资源监控，并提供统一的拓扑视图。
应用程序包管理器APM(App Packet Manager)
应用程序包管理器 (APM) 使 edgegallery 能够通过从应用商店下载应用程序包来将应用程序分发/装载到边缘存储库。
应用编排器Application Orchestrator
Application Orchestrator（APPO）主要负责MEC应用编排，通过在保持生命周期状态的同时执行指定的工作流，请求对边缘主机上的MEC应用进行生命周期管理。编排工作流使用 Camunda 建模工具建模，工作流由 Camunda 引擎执行。
Inventory库存清单
Inventory 提供边缘主机上部署的应用程序和应用程序配置的实时视图。I
North北向接口
North提供获取主机列表和应用分布部署的接口。目前主要帮助Appstore 实现订阅功能。
LCM控制器
LCM 控制器负责 MEC 应用程序生命周期管理操作，方法是通过k8splugin或osplugin向VIM发送请求。
K8s 插件
K8s Plugin 负责 Kubernetes 基础设施上的 MEC 应用生命周期管理操作。 K8s 插件使用 helm 客户端执行应用生命周期管理操作。
应用规则管理器
APP Rule Manager 负责通过向 MEP 发送应用规则配置来配置应用规则。应用规则配置包括需要配置的流量规则和DNS。
资源控制器
资源控制器Resource Controller是针对Openstack开发出的新功能，对 flavor、网络、虚拟机等资源执行 LCM 操作.
5.MEP
项目整体介绍
随着物联网、人工智能、云计算、移动互联网、大数据和大视频等产业技术的蓬勃发展，以及围绕ICT开放生态的成熟，网络资源和计算能力逐步朝着资源集中化和边缘化方向演进。
多接入边缘计算MEC（Multi-access Edge Computing）为典型的资源边缘化模式，在移动网络边缘提供IT服务环境和云计算能力，实时完成移动网络边缘的业务处理。MEC将随着CT和IT深度融合趋势，物联网的兴起、人工智能技术的发展，以及企业对生产数据的安全性、实时性的诉求，持续快速的发展。
EdgeGallery MEP项目旨在打造一个边缘侧的开源、开放的参考MEP平台。在MEC场景下，海量的应用将运行在网络边缘进行业务处理，并且应用能够使用网络的开放能力，应用之间也能够互相进行能力提供和消费。
MEP整体架构
图中涉及的MEP关联主要接口有：
- Mp1 APP与MEP之间，提供APP服务注册发现，APP状态通知订阅等能力。
- Mp2 MEP与UPF之间，提供数据面的配置能力。
- Mm3 MEO与MEPM之间，提供包管理，APP生命周期管理能力。
- Mm5 MEPM与MEP之间，执行MEP平台配置管理，配置APP规则等能力。
对于应用App来说，Mp1是APP与MEP交互最重要的接口，APP能通过Mp1将自身服务注册到MEP平台，同时也能够通过服务发现调用MEP对外提供的服务。
对于MEP提供的对外API接口来说，主要包含 MEP-server 和 MEP-auth 两个主要功能模块。MEP server 接口分为两类，一类为遵循 ETSI MEC 011 v2.1.1 标准的 Mp1 接口，主要为 App 提供服务注册发现，App 状态通知订阅，Dns 规则获取等功能；另一类为 Mm5 接口，主要为 MECM/MEPM 提供配置管理功能。MEP auth 目前主要作为鉴权模块，为 App 提 供 token 申请发放功能。
MEP特性设计
|------------|-------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| 模块名称 | 功能 | 详细描述 |
| MEP-auth | App鉴权 | 提供token申请接口，APP可以基于AK/SK签名算法，向MEP-auth提供正确的签名，获得token，然后通过该token访问MEP-server相关接口。 |
| MEP-auth | API网关提供配置功能 | 首先对API网关（kong）进行初始化 1. 在kong添加一个consumer 2. 为MEP-auth自身配置service和route 3. 为MEP-server配置servcie和route 4. 为MEP-auth和MEP-server配置并启用kong插件 MEP-auth在初始化kong过程中开启的插件包括： * JWT 插件 为相应接口提供token校验能力 * Appid-header插件 在接口request中插入X-AppinstanceID头，以供MEP-server校验；校验申请token的client ip与调用接口的client ip一致 * Rate Limiting插件 为MEP-auth和MEP-server接口提供流量控制能力 * IP Restriction插件 为MEP-auth提供客户端IP白名单功能支持 * response-transformer插件 提供清除response中server header能力 * pre-function插件 提供修改接口请求x_forwarded_for能力 |
| MEP Server | 服务治理功能 | MEP提供服务注册，更新，删除，查询相关API接口。应用能够通过LDVS-MEP进行服务的注册，更新，删除，查询。 |
| EG-LDVS | 应用集成 | LDVS MEP管理应用的服务，应用需要将其服务注册到MEP中，MEP-Agent作为适配器，将服务信息（包括应用实例ID）导入给应用，同时提供配置的方式将应用的服务注册到MEP中。 |
DNS Srever特性
- DNS 管理操作。
DNS 配置由 MECM 模块在启动期间创建，或直接从 OSS 创建。DNS 管理支持创建、更新、查询和删除操作。
- 查询配置和 MEC 应用程序的激活/停用。
MEC 可以查询为其创建的 DNS 配置，并可以激活或停用相同的配置。可以通过修改 DNS 配置的状态来执行激活或停用。
- 设备应用程序的 DNS 查询。
UE中的设备应用程序可以查询DNS服务器的域名解析。
详见https://docs.edgegallery.org/zh_CN/latest/Projects/MEP/MEP_Features.html#dns-server
6.用户管理
User Management模块是为EdgeGallery项目提供用户管理的基本能力，包括用户注册/登录/权限认证等功能。为AppStore/开发者平台/MECM/ATP提供统一的用户鉴权和认证服务。
部署关系
User-management模块主要包含四个模块：
- Portal：提供登录/登出的界面操作。
- Auth-server：提供JWT服务，用于API接口访问的token生成。
- User-mgmt：提供用户帐号管理，包括获取/修改用户信息、密码找回等功能。
- Mail: 提供邮箱服务。
User-mgmt和其他模块之间的关系
User-mgmt是EdgeGallery的用户管理模块：
- 用户首先通过User Management登录到EdgeGallery平台
- User Management会给登录成功的用户签发AccessToken，用于后台API接口的访问，token默认超时时间12小时，token携带以下数据：
- userId: 登录用户ID
- enableMail：是否开启邮箱服务
- ssoSessionId：全局SessionId，用户单点登录
- userName：用户名
二. Kubernetes（K8s）
概述
Kubernetes 是一个可移植、可扩展的开源平台，用于管理容器化工作负载和服务，有助于实现声明式配置和自动化,有一个庞大、快速增长的生态系统。Kubernetes 服务、支持和工具广泛可用。
节点（Node）
节点是K8s中最小的计算硬件单元，可以是一个虚拟机或者物理机器，取决于所在的集群配置。Kubernetes 通过将容器放入在节点上运行的 Pod 中来执行工作负载。
Kubernetes集群由Master节点和Node节点组成，Master节点主要负责集群的控制，对pod进行调度、令牌管理等功能，Node节点主要负责干活，启动和管理容器。通过Master节点管理一个高度可用的计算机集群，这些计算机连接起来作为一个单元工作，实现集群访问的功能。Kubernetes 会在内部创建一个 Node 对象作为节点的表示。
Node节点在计算节点上部署容器化应用程序，无需将它们专门绑定到某个计算机上，由集群自动的在各个节点上分发和调度应用容器，实现计算节点扩缩容的功能。
Kubernetes集群的整体架构图
下图是一个Kubernetes集群的整体架构图，整个集群由一个Master节点和多个Node节点构成，整个集群的对外交互均通过KubernetesAPI Server完成。实际生产环境中一般部署多个Master节点以确保集群的稳定性和高可靠性。
节点组件
- API Server：采用Restful的方式对外暴露Kubernetes的API接口，是外界进行资源操作的唯一入口，并提供认证、授权、访问控制、API注册和发现等机制；
- Scheduler：负责资源的调度，按照预定的调度策略将Pod调度到相应的机器上；就是监视新创建的 Pod，如果没有分配节点，就选择一个节点供他们运行，这就是pod的调度；
- Controller Manager：集群内部的管理控制中心，负责集群资源管理和维护集群的状态，比如故障检测、自动扩展、滚动更新等；它是以Pod方式运行的，每个控制器都是Pod内运行进程的一个线程，负责后台处理集群中的常规任务。
- Etcd：Kubernetes的后端数据库，key/vaule方式存储，所有的Kubernetes集群的数据都存放在此处。保存了整个集群对象的状态信息和元信息配置。
- Kubelet是Kubernetes所有组件中唯一一个以服务方式运行的进程，通过CRI接口与Docker的Containerd进行交互，负责维护容器的生命周期，同时也负责Volume和网络的管理。
- Kube-proxy负责节点的维护。
Pod（容器组）
在Kubernetes集群中，Pod是所有业务类型的基础，也是Kubernetes管理的最小单位级，它是多个容器的组合。这些容器共享存储、网络和命名空间，以及如何运行的规范。在Pod中，所有容器都被统一安排和调度，并运行在共享的上下文中。对于具体应用而言，Pod是它们的逻辑主机，Pod包含业务相关的多个应用容器。
定期检查
- 定期检查Pod内主进程是否退出
Kubernetes提供的默认健康检查能检测Pod内Pid为1的进程的运行状态，Kubernetes会根据Pod设置的重启策略决定在进程退出后是否需要重启Pod。
- 定期检查Pod能否正常提供服务
liveness和readiness探针能执行Pod内存在的某些指令探测Pod内进程提供的服务是否正常。探测的指令和接口一般由业务方提供。liveness在探测失败一定次数后会根据重启策略决定是否重启Pod，而readiness在探测失败一定次数后会退出负载均衡组。
故障迁移
如下图是Pod的故障迁移图。
- 通过Node Controller节点控制器周期性检查所有节点状态，当发现有节点的状态为notReady时，会驱逐该节点上所有的Pod。
- 通过 Replication Controller或者Deployment等副本控制器管理Pod的副本数量，实现自动创建、补足、替换、删除Pod副本。
如图 在节点控制器和副本控制器的共同作用下，当集群中一个Node节点发生故障，会驱逐该节点上所有Pod，该节点上的Pod状态被置为Terminating。此时Running状态的Pod副本数量发生变化，副本控制器会在其他节点上启动新的Pod来补足副本数。当故障的Node恢复，此时Running中的Pod副本数量已经满足设置的值，故障恢复后的Node上Terminating的Pod会被副本控制器删除。
存储
Kubernetes持久化存储方案分为：配置资源存储、本地存储和网络存储。
- 配置资源存储：
将Kubernetes特定类型的配置资源对象在创建Pod时将其从Etcd下载到宿主机后映射为目录或文件，主要有：
- ConfigMap 配置项挂载：将ConfigMap配置项中的key映射到容器中，可以用于挂载配置文件到指定容器目录。配置项（ConfigMap）是一种用于存储工作负载所需配置信息的资源类型，内容由用户决定。
- Secret 私密凭据挂载：将Secret资源的数据挂载到容器的某一路径中。密钥是一种用于存储工作负载所需要认证信息、密钥的敏感信息等的资源类型，内容由用户决定。其主要作用是保管私密数据，比如密码、Tokens、SSH Keys等信息。
这两者都是存储在Etcd数据库中，在任意主控节点使用kubectl客户端生成上述资源后，可供整个集群任意节点使用。
- 本地存储：
- HostPath本机路径挂载：将容器所在Node节点宿主机的文件目录挂载到容器指定的挂载点中，但同时增加了Pod与节点的耦合，限制了Pod的使用和调度。
- EmptyDir临时路径挂载：用于临时存储，生命周期与容器实例相同。EmptyDir是在Pod被分配到Node时创建的，它的初始内容为空，并且无需指定宿主机上对应的目录文件，因为Kubernetes会自动分配一个目录，当pod销毁时，EmptyDir中的数据也会被永久删除。
- 网络持久化存储：
相较于本地存储，采用网络持久化存储可解耦存储和集群，对存储设备的维护不会影响到集群，同时网络存储还有存储容量大、数据有限制共享、信息充分利用、数据可靠性高、安全性高、数据管理的简单化和统一化等特点，另外网络存储通常都具有较强的扩展性。
NFS是网络文件系统Network File System的缩写，NFS服务器可以让PC将网络中的NFS服务器共享的目录挂载到本地的文件系统中。
上图为存储的存在形式：
- 最上层的Pod和PVC由用户管理，PVC创建volume卷，并指定存储方式。
- 中间部分由集群管理者创建StorageClass对象，StorageClass只需确定PV属性（存储类型，大小等）及创建PV所需要用的存储插件；K8s会自动根据用户提交的PVC来找到对应的StorageClass，之后根据其定义的存储插件，创建出PV。
- 最下层指代后端存储，主要由管理员管理。
集群管理
Kubernetes 集群是一组用于运行容器化应用的节点计算机。Kubernetes 集群能够在内部或云端跨一组机器（无论是物理机还是虚拟机）调度和运行容器。
- 管理内存、CPU和API资源
主要是为命名空间配置默认的内存/CPU请求和限制。
- 控制节点集群访问
Kubernetes API Server通过一个名为kube-apiserver的进程提供服务，该进程运行在Master节点上。如所示，kube-apiserver接受来自集群外部和集群内部的客户端调用。
外部Client主要为常用的命令行工具kubectl、Kubernetes官网提供的SDK以及RESTful API。
内部Client主要为集群控制面kube-controller-manager、kube-scheduler、kube-proxy、kubelet以及数据面的其他Pod。
- 计算节点扩容
为了能够更好的满足业务需求，当现有集群环境无法满足后续的业务运行需求，此时可以对计算节点进行扩容，新增计算节点。在计算节点上部署容器化应用程序，无需将它们专门绑定到某个计算机上，由集群自动的在各个节点上分发和调度应用容器，实现计算节点扩缩容的功能。
通过kubeadm命令实现计算节点的扩容：
在新节点上安装Docker和kubernetes环境，在Master节点生成用于验证加入集群的令牌（token），查看生成的token并获取其sha256编码hash值，在新节点执行kubeadm join命令加入集群，在Master节点查看集群当前节点状态，判断新Node是否加入成功。
- 控制面数据面分离
控制面数据面分离，控制节点物理机宕机时，从而不影响计算节点上数据面上业务的运行。
亲和性与反亲和性
利用Kubernetes提供的亲和性和反亲和性功能来实现Pod的高级调度。就是在编写Pod部署使用的yaml文件时，设定相应的调度策略，集群会根据调度策略中对label的约束条件来调度Pod。
主要分为两类，Node亲和策略和Pod亲和策略（Pod策略中又分为亲和和反亲和），分别针对Node的label和已经运行的 Pod上 的label。
Kubernetes中主要的亲和性/反亲和性调度策略如下图所示：
同时，每种调度策略都有以下两个参数，分别控制硬亲和和软亲和：
- requiredDuringSchedulingIgnoredDuringExecution：硬亲和，必须满足的条件，Pod 要调度到的节点必须满足规则条件，不满足则不会调度，Pod 会一直处于 Pending 状态。
- preferredDuringSchedulingIgnoredDuringExecution：软亲和，优先满足的条件，优先调度到满足规则条件的节点，如果不能满足则可以调度到其他节点。
日志管理
容器云平台日志模块由Fluentd，Elasticsearch和Kibana组成：
- Fluentd是一个流行的开源数据收集器。
- Elasticsearch是一个实时的，分布式的，可扩展的搜索引擎，它允许进行结构化搜索以及对日志进行分析。它通常用于索引和搜索大量日志数据。Kibana是Elasticsearch 的功能强大的数据可视化的dashboard（仪表板）。
- Kibana可以通过Web界面浏览Elasticsearch日志数据，也可自定义查询条件快速检索出Elasticccsearch中的日志数据。
获取Pod日志文件、过滤和转换日志数据，然后将数据传递到 Elasticsearch集群，在该集群中对其进行索引和存储，并提供一个功能强大的数据可视化 Dashboard。
日志模块收集的日志包括：
- 收集并且显示集群内Docker管理组件日志。
- 收集并且显示集群内业务Pod的标准输出、标准错误日志。
- 收集显示API Server、Scheduler、Controller Manager等组件的日志。
Kubernetes日志收集架构图如图所示：
利用DaemonSet来让Fluentd Pod在每个Node上运行，将日志文件搜集备份存储到宿主机目录并发送到Elasticsearch，在Kibana提供的webui中进行索引查看。
DaemonSet是Kubernetes的一种资源类型，它确保全部Node上运行一个Pod的副本。当有Node加入集群时，也会为他们新增一个Pod。当有Node从集群移除时，这些 Pod 也会被回收。
监控
容器云平台Kubernetes方案监控模块使用Prometheus方案。Prometheus（普罗米修斯）是一个开源系统监控和警报工具，项目拥有一个非常活跃的开发者和用户社区。Prometheus 制定了一套监控规范，符合这个规范的样本数据可以被 Prometheus 采集并解析样本数据。Exporter 在 Prometheus 监控系统中是一个采集监控数据并通过 Prometheus 监控规范对外提供数据的组件，针对不同的监控对象可以实现不同的 Exporter，这样就解决了监控对象标准不一的问题。从广义上说，所有可以向 Prometheus 提供监控样本数据的程序都可以称为 Exporter。
主要功能
Kubernetes的Prometheus监控方案：
- 基础设施层：监控各个物理服务器资源，如CPU，内存，网络吞吐和带宽占用，磁盘I/O和磁盘使用等指标。
- Kubernetes集群：监控Kubernetes集群管理组件的关键指标，如API Server、Scheduler、Controller Manager等组件的指标。如kubelet的kubelet_running_pods（运行中的pod总数）。
- Kubernetes集群上部署的Pod：监控部署在Kubernetes集群上Pod的CPU,内存,网络吞吐和带宽占用,磁盘I/O和磁盘使用量以及pod运行状态等指标。
- 展示方式：快速灵活的客户端图表，面板插件有许多不同方式的可视化指标和日志，官方库中具有丰富的仪表盘插件，比如热图、折线图、图表等多种展示方式。
- 通知提醒：以可视方式定义重要指标的警报规则，在数据达到阈值时向boss网管发送报警；
三、KubeSphere
概述
KubeSphere 将 前端 与 后端 分开，实现了面向云原生的设计，后端的各个功能组件可通过 REST API 对接外部系统。 KubeSphere 无底层的基础设施依赖，可以运行在任何 Kubernetes、私有云、公有云、VM 或物理环境（BM）之上。 此外，它可以部署在任何 Kubernetes 发行版上。
除了针对 Kubernetes 资源管理之外，还提供了统一的集群管理、包含日志、审计、监控在内的强大的可观测性等许多附加功能。同时提供可插拔组件的部署方式，既满足了功能多样性，又满足了部署的灵活性需求。
KubeSphere 很好的集成了 DevOps 自动化流程，而 DevOps 自动化流程是提高软件交付速度、保障质量和可靠性的最佳实践方法。
组织架构
KubeSphere 整体组织结构分为前端、后端，以及基础设施三层。
- 前端即页面，为用户提供直接的 web 交互入口，包括普通用户页面、管理员页面、平台监控页面。
- 后台主要是在 kubernetes 的基础设施上构建用户需要的业务的具体支持，包括系统管理、监控管理、自动化运维。
- 底层设施主要是运行KubeSphere的底层云平台，使用虚拟机和kubernetes等搭建的最底层的平台支持。
组件列表
kubesphere是 多个组件灵活开发，实现多维管控并且降低了运维难度。
主要组件有：
- ks-console：前端服务组件，提供 KubeSphere 的控制台服务，为用户提供便捷的可视化操作界面，提供相关权限的API接口。
- ks-apiserver：后端服务组件，是整个集群管理的 API 接口和集群内部各个模块之间通信的枢纽，负责后端数据的交互，请求的代理分发、认证与鉴权。
- ks-controller-manager：资源状态维护组件，实现业务逻辑的，例如创建企业空间时，为其创建对应的权限；或创建服务策略时，生成对应的Istio配置等。
- plugin：可插拔组件，KubeSphere 解耦了一些核心功能组件。这些组件设计成了可插拔式，可以在安装之前或之后启用它们。如果不启用它们，KubeSphere 可以最小化进行安装部署。不同的可插拔组件部署在不同的命名空间中。
下面的表格列出了KubeSphere的所有可插拔组件：
|---------------|---------------------------|-------------------------------------------------------------------------|
| 配置项 | 功能组件 | 描述 |
| alerting | KubeSphere告警系统 | 可以为工作负载和节点自定义告警策略。当达到某个指标的预定义阈值时，会向预先配置的收件人发出告警（例如，邮件和 Slack、钉钉）。 |
| auditing | KubeSphere审计日志系统 | 提供一套与安全相关并按时间顺序排列的记录，记录平台上不同租户的活动。 |
| devops | KubeSphere DevOps 系统 | 基于 Jenkins 提供开箱即用的 CI/CD 功能，提供一站式 DevOps 方案、内置 Jenkins 流水线与 B2I & S2I。 |
| events | KubeSphere事件系统 | 提供一个图形化的 Web 控制台，用于导出、过滤和警告多租户 Kubernetes 集群中的 Kubernetes 事件。 |
| logging | KubeSphere日志系统 | 在统一的控制台中提供灵活的日志查询、收集和管理功能。可以添加第三方日志收集器. |
| networkpolicy | 网络策略 | 可以在同一个集群内部之间设置网络策略（比如限制或阻止某些实例 Pod 之间的网络请求）。 |
| kubeedge | KubeEdge | 为集群添加边缘节点并在这些节点上运行工作负载。 |
| openpitrix | KubeSphere应用商店 | 基于 Helm 的应用程序商店，允许用户管理应用的整个生命周期。 |
| servicemesh | KubeSphere服务网格 (基于 Istio) | 提供细粒度的流量治理、可观测性、流量追踪以及可视化流量拓扑图。 |
其中配置项 指的是在 cluster-configuration.yaml 文件中更改配置项所对应的内容（false改为true），以启用相应的插件，当需要卸载的时候需要用到Kubernetes命令行工具Kubectl。
可观测功能的可插拔组件
- 日志系统
日志可以帮助更好地了解集群内部和工作负载内部发生的事情。日志对于排除故障问题和监控集群活动特别有用。KubeSphere 基于租户的日志系统中，每个租户只能查看自己的日志，从而可以在租户之间提供更好的隔离性和安全性。
启用日志系统的步骤如下：（以下组件的启用均是在Kubenetes上安装）
安装后成功后，还要以admin用户的身份登录控制台，YAML 文件中，搜索 logging，将 enabled 的 false 改为 true。
- 审计日志
KubeSphere 审计日志系统提供了一套与安全相关并按时间顺序排列的记录，按顺序记录了与单个用户、管理人员或系统其他组件相关的活动。
启用审计日志的步骤如下：
安装后成功后，还要以admin用户的身份登录控制台， YAML 文件中，搜索 auditing，将 enabled 的 false 改为 true
- 告警系统
告警是可观测性的重要组成部分，与监控和日志密切相关，用户可以借助 KubeSphere 强大的监控系统查看平台中的各类数据。
告警系统的启用步骤如下：
安装后成功后，还要以admin用户的身份登录控制台启用告警系统， YAML 文件中，搜寻到 alerting，将 enabled 的 false 更改为 true。完成后，保存配置。
验证组件安装，比如说KubSphere的告警系统内，如果可以在集群管理 页面看到告警消息 和告警策略，则说明安装成功。
在卸载除服务拓扑图和容器组 IP 池之外的可插拔组件之前，必须将 CRD 配置文件 ClusterConfiguration 中的 ks-installer 中的 enabled 字段的值从 true 改为 false。