边沿计算与云计算总结

一. 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）进行初始化       在kong添加一个consumer 为MEP-auth自身设置service和route 为MEP-server设置servcie和route 为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。

资料出处

• ​​【KubeSphere】KubeSphere 分析​​
  
• ​​Open Source Enterprise Kubernetes Platform | KubeSphere​​
  
• ​​EdgeGallery体系架构​​
  
• ​​Kubernetes Documentation​​
  
• ​​5G智能融合通信体系（iMCS）产物云平台EUCS总体设计方案V2.0.0-Release.doc​​
  

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。