转载https://blog.csdn.net/weixin_38748858/article/details/103514909?utm_medium=distribute.pc_relevant_bbs_down.none-task--2~all~first_rank_v2~rank_v25-1.nonecase&depth_1-utm_source=distribute.pc_relevant_bbs_down.none-task--2~all~first_rank_v2~rank_v25-1.nonecase云原生的解释可以说五花八门，本文从不同角度探讨云原生的内涵以及如何从不同维度准确理解它的含义。云原生起源网上有些文章提到云原生是“Pivotal公司的Matt Stine于2013年首次提出云原生（CloudNative）的概念”。我搜索了英文“CloudNative”，阅读了首页的所有文章，里面没有一篇提到“Matt Stine首次提出云原生”，但它们每一篇都提到了“云原生计算基金会”的定义。“Matt Stine”确实写了一本书，叫《迁移到云原生架构》，他以前确实在Pivotal公司工作，但说他“首次提出云原生（CloudNative）的概念”应该是不准确的, 而且他的定义和云原生的含义是有一定偏差的。我觉得比较接近的说法是Netflix公司首创了云原生，详见Going Cloud Native: 6 essential things you need to know。虽然那篇文章主要是讲的Netflix如何开创了微服务，但Netflix的微服务是部署在亚马逊云上的。而当时亚马逊云也才刚起步，各方面都不成熟，Netflix是它的最大客户。是Netflix的层出不穷的需求帮助亚马逊云不断完善它的功能和性能，最终登顶云服务商。因此Netflix的微服务演进是和云计算交织在一起，共同推进的。Netflix在微服务领域的开创和领先地位是大家公认的，它的“Netflix OOS”系列工具至今仍被广泛使用，特别是Java社区，并被移植到其他语言。在这个过程中，也同时开创了云计算的先河，它的起点是2009年。详情请见Goto Berlin - Migrating to Microservices (Fast Delivery)。但我想说的是云计算（Cloud）和云原生（Cloud Native）还是有很大区别的。Netflix是云计算的开拓者，但并不是云原生的创造者。云原生的基石是k8s，没有k8s就没有云原生， 而k8s的1.0版诞生于2015年。云原生计算基金会（CNCF）也诞生于2015年并致力于推动云原生的发展。云原生的概念是在2017才开始被广泛接受和流行，因此云原生和云计算是由本质区别的。云原生的诞生是和云原生计算基金会密切相关的。云原生计算基金会（CNCF）的定义：下面就让我们看一下CNCF给出的云原生的定义：“云原生技术有利于各组织在公有云、私有云和混合云等新型动态环境中，构建和运行可弹性扩展的应用。云原生的代表技术包括容器、服务网格、微服务、不可变基础设施和声明式API。这些技术能够构建容错性好、易于管理和便于观察的松耦合系统。结合可靠的自动化手段，云原生技术使工程师能够轻松地对系统作出频繁和可预测的重大变更。云原生计算基金会（CNCF）致力于培育和维护一个厂商中立的开源生态系统，来推广云原生技术。我们通过将最前沿的模式民主化，让这些创新为大众所用。”摘要来源：CNCF Cloud Native Definition v1.0这个定义还是比较靠谱的，尽管它并不严谨，也并没有挖掘出云原生的本质。但考虑到每个组织的目的和立场不同，看问题的角度不同，CNCF的主要目的是培育云原生工具市场，因此它的定义带有很重的实用色彩，偏重工具方面。若是从这个角度看，这个定义还是比较贴切的。我觉得唯一不严谨的地方是把微服务列了进去，其他的都没什么问题。让我们来分析一下定义中提到的工具。其中k8s是整个云原生的基石，也是CNCF的第一个项目。云原生的整个生态体系都是依靠k8s建立起来的。因此在k8s之前是不可能有云原生的。定义里还提到了容器（Container）、服务网格（Service Mesh）、微服务（Microservice）、不可变基础设施（immutable infrastructure）和声明式API（declarative APIs）。其中容器（Container）是k8s的底层引擎，服务网格（Service Mesh）是建立在k8s上的针对请求的扩展功能，不可变基础设施（immutable infrastructure）是现代运维的基石，声明式API（declarative APIs）是k8s的编码方式，这些无一不是和k8s紧密相关的。但微服务（Microservice）就不同了，它其实跟云原生没什么关系，它们是两个完全不同的东西并沿着各自的轨道独立向前发展。但由于认容器技术和微服务是天生的良配，它们现在的演进轨道交织在一起密不可分。但实际上没有容器技术，微服务也可以部署在虚机上，只不过资源的利用率可能不够高。没有微服务，容器技术虽然不能大展宏图，但也能在分布式应用里找到一席之地。当然把它们放在一起确实能如虎添翼，但把微服务划归到云原生里实在是有点扩大外延，**圈地的意味。因为云原生的重点还是在基础设施，运维和运行环境以及软件的开发环境，而微服务是一个软件的架构，两者之间有明显的不同。云原生的表层含义那么到底什么是“云原生（Cloud Native）”呢？它分表层含义和深层含义。表层含义从字面上理解就比较容易了，我们管母语叫“Native Language”，也就是你一生下来就说的语言。“Cloud Native”就是一开始开发的时候就是为了最终部署到云环境上的。而在云计算初创时，大部分的程序都是从本地环境移植到云上的，它们在设计是就根本没考虑云环境的问题。云环境与本地环境的差异那么部署到云环境和部署到本地服务器有什么不同？这个才是问题的本质。你可能会说“是容器技术”，这个是现代云计算的不可或缺的支撑，但云计算开始的时候是基于虚拟化的，并没有容器技术，是在发展的过程中才有了容器技术。是“自动伸缩（auto-scaling）”吗?这是云环境的一个主要优点和特性，但它只是结果，不是本质。云技术的三大基石：基础设施即代码 (Infrastructure As Code）基础设施即代码是指把创建基础设施（包括服务器和网络环境）的命令像应用程序一样储存在源码库中，并进行版本管理。这样创建基础设施的过程就变成了部署软件的过程。它的最大的好处就是可重复性。以前的方法是用人工敲入命令来创建运行环境，出了问题就在原来的基础之上进行修修补补，一旦需要把整个环境重新建立，很难保证与原来的一样。 当使用基础设施即代码之后，再也没有了这个担心。详情请见 InfrastructureAsCode不可变基础设施（immutable infrastructure）说道这里，我们不得不提“不可变基础设施（immutable infrastructure）“，它是基础设施即代码的升级版。有了基础设施即代码之后，随时都可以通过运行软件再构建出一个一模一样的服务器和其他需要的设备，并且还能预装应用程序，创建的时间还是秒级的。这时当服务器出现问题时，就没有必要去花时间查找原因了并修复了，而是直接把服务器销毁重新创建一个新的。因此这时的基础设施是不可变的，只有创建和删除，而没有修改操作。这彻底改变了运维的方式。详情请见 What is “Immutable Infrastructure”?声明式API（declarative APIs）声明式API也是基础设施即代码的升级版。最开始时，当用软件定义基础设施时是用的过程式描述，也就是通过运行一系列的命令来创建运行环境。后来发现更好的办法是描述最终运行环境的状态，而由系统来决定如何来创建这个环境。例如，你的描述就变成“创建一个有三个Nginx的集群”，而不是把创建Nginx的命令运行三次组成一个集群。这样的好处是当运行环境与描述不符合时，系统能检测到差异，并自动修复，这样系统就有了自动容错的功能。上面讲了云计算环境和传统基础设施的不同，其实随着云计算的发展，传统基础设施也在不断地采纳云计算的先进技术和理念，例如虚拟化和容器技术，而各个云计算厂商也提供了本地私有云的版本。只不过在公有云上的管理功能更强大，而通常本地私有云的版本是公有云的一个简化版。云原生应用程序的不同上面讲到了，只有一开始就是按照部署到云环境的要求来设计的应用程序才是云原生的。那么部署到云环境需要做哪些特殊设计呢？它主要有两个部分:第一部分是服务调用。不论是微服务之间的调用，还是微服务调用数据库或前端调用后端，调用的方式都是一样的。都需要知道IP地址，端口和协议，例如“http://127.0.0.1:80”, 其中“http”是协议，“127.0.0.1”是IP地址，“80”是端口。由于程序是部署在k8s上的，k8s会负责程序之间的寻址和调用。由于k8s会自动销毁出错的服务器，并创建新的服务器，IP地址就变成了动态的，而不是静态的。这时就只能通过服务名而不是IP地址来进行调用。也就是说k8s会给每个服务一个服务名，并通过k8s内部的DNS对服务名进行寻址。服务名是写在k8s的配置文件里的，软件设计的关键让应用程序和k8s配置文件都共享相同的调用地址。第二部分是数据的持久存储。在程序运行时，经常要访问持久存储（硬盘）上的数据，例如日志，配置文件或临时共享数据。程序在容器中运行，一旦出现问题，容器会被摧毁，k8s会自动重新生成一个与原来一模一样的容器，并在上面重新部署应用程序。在集群环境下，用户感觉不到容器故障，因为系统已经自动修复了。但当容器被摧毁时，容器上的数据也一起被摧毁了，因此要保证程序运行的连续性，就要让持久存储不受容器故障的影响。如果你对它的具体设计感兴趣，请参见把应用程序迁移到k8s需要修改什么？云原生的深层含义不过云原生还有一层引申含义。当你的最终生产环境是云环境时，你的本地开发环境最好也是云环境，这虽然不是必须的，但它能保证本地环境和生产环境的一致性，减少部署时的意外，是一个很自然的选择。而要在本地使用云环境来进行开发，你需要一系列的工具来保证开发的顺利和高效。要想了解云原生的开发环境及工具，请继续阅读下一篇“ 云原生开发环境初探"。索引：Going Cloud Native: 6 essential things you need to knowGoto Berlin - Migrating to Microservices (Fast Delivery)CNCF Cloud Native Definition v1.0InfrastructureAsCodeWhat is “Immutable Infrastructure”?把应用程序迁移到k8s需要修改什么？云原生开发环境初探不堆砌术语，不罗列架构，不迷信权威，不盲从流行，坚持独立思考

摘要：KubeEdge 是首个基于 Kubernetes 扩展的，提供云边协同能力的开放式智能边缘计算平台，也是 CNCF 在智能边缘领域的首个正式项目。依托 Kubernetes 强大的容器编排和调度能力，实现云边协同、计算下沉、海量设备接入等。边缘计算场景与挑战边缘计算是一种分布式计算概念，拥有去中心化处理能力的分散型开放 IT 架构，数据由设备本身或本地计算机或服务器处理，无需传输到数据中心，也可在更靠近终端的网络边缘上提供服务。但边缘计算无法单独存在，它必定要和远程数据中心 / 云打通，以 IoT（Internet of Things，物联网）场景为例，边缘设备除了拥有传感器收集周边环境的数据外，还会从云端接收控制指令，因此边缘计算与云计算二者是相依而生、协同运作的。据2020边缘计算状态报告显示，到2022年，75%的数据将通过边缘分析和处理。这种数据处理的流动性，将伴随有4大边缘技术演进方向：人工智能的实用性增强，从云端渗透到边缘物联网设备的数量呈指数级增长5G时代的快速到来边缘计算中心逐步克服分布式设施复杂性和单位成本经济性的问题结合边缘计算的场景与技术演进方向，可以总结出当前边缘计算领域面临的几个挑战：云边协同：逐步从云端渗透到边缘的AI/安全等业务，在云和边的智能协同、弹性迁移；网络：边缘网络的可靠性和带宽限制；设备管理：呈指数级增长的物联网设备，边缘节点与边缘设备的管理；扩展：高度分布和大规模的可扩展性；异构：边缘异构硬件和通信协议。Kubernetes构建边缘计算平台的优势与挑战Kubernetes 已经成为云原生的事实标准，并且能够在任何基础设施上提供一致的云上体验。我们经常能够看到“容器 + Kubernetes”的组合在 DevOps 发挥 10X 效率。基于Kubernetes的技术架构与生态优势，近几年也有越来越多的将Kubernetes 运行在数据中心外（边缘）的需求。基于Kubernetes构建的边缘计算平台，将会具备众多天然的优势：（1）容器化应用封装：容器的轻量化和可移植性非常适合边缘计算的场景，边缘容器应用Build一次，可以运行在任何边缘节点上。（2）通用的应用抽象定义：Kubernetes的应用定义已成为云原生业界的事实标准，被广泛接受。通过原生的Kubernetes应用API，用户可以将云上与边缘的应用统一管理。例如用户可以使用熟悉的 kubectl 或者 helm chart管理云上与边缘的应用。（3）平台易扩展性：Kubernetes 已经被证明具备良好的可扩展性，基于CRD可以自定义API，如边缘设备管理；基于CRI、CNI、CSI等插件可以扩展各种边缘自定义插件。（4）强大的技术生态圈：围绕 Kubernetes 已经形成了一个强大的云原生技术生态圈，诸如：监控、日志、CI、存储、网络都能找到现成的工具链。然而 Kubernetes 毕竟原生是为云数据中心设计的，要将Kubernetes 的能力扩展到边缘，必须解决以下问题：（1）边缘设备资源有限：很多设备边缘的资源规格有限，特别是 CPU 处理能力较弱，内存资源较少，因此无法部署完整的 Kubernetes。（2）边缘网络的不稳定性：Kubernetes依赖数据中心稳定的网络，边缘场景下网络通常又是不稳定的。（3）边缘节点离线自治：Kubernetes依赖 list/watch 机制，不支持离线运行，而边缘节点的离线又是常态，例如：设备离线重启。（4）海量边缘设备管理：如何使用Kubernetes管理指数级增长的海量边缘设备以及产生的数据。另外，关于如何在边缘使用 Kubernetes，Kubernetes IoT/Edge WG 组织的一个调查显示，30% 的用户希望在边缘部署完整的 Kubernetes 集群，而 70% 的用户希望在云端部署 Kubernetes 的管理面并且在边缘节点上只部署 Kubernetes 的 agent。边缘容器开源现状Kubernetes社区很早就已经关注到边缘计算场景，早在2018年社区就已经成立专门的Edge工作组来研讨边缘相关场景。而2018年底，华为在业界首次开源Kubernetes边缘项目KubeEdge，将华为云智能边缘平台产品IEF（Intelligent EdgeFabric）核心代码开源，并于19年初捐献给CNCF基金会，成为CNCF迄今为止唯一边缘计算官方项目。随后，Rancher、阿里云也陆续跟进，开源了K3s、OpenYurt等项目，边缘容器这个领域真正进入到快速发展期。下面，我们对这三个代表性的K8s@Edge的项目进行一些简要分析。KubeEdge架构分析KubeEdge 是华为云于2018年11月开源，2019年3月捐献给 CNCF 的开源项目。KubeEdge 是首个基于 Kubernetes 扩展的，提供云边协同能力的开放式智能边缘计算平台，也是 CNCF 在智能边缘领域的首个正式项目。KubeEdge 的名字来源于 Kube + Edge，顾名思义就是依托 Kubernetes 强大的容器编排和调度能力，实现云边协同、计算下沉、海量设备接入等。KubeEdge架构上分为云、边、端三个层次。云端中心管控边缘节点与设备，边缘节点实现边缘自治，云上管控边缘节点的架构也符合Kubernetes IoT/Edge WG 调查结果中大多数用户的诉求。KubeEdge完整的打通了边缘计算中云、边、设备协同的场景，整体架构如下图。针对边缘特定的场景，KubeEdge 重点解决的问题是：云边协同：KubeEdge 通过 Kubernetes 标准 API 在云端管理边缘节点、设备和工作负载的增删改查。边缘节点的系统升级和应用程序更新都可以直接从云端下发，提升边缘的运维效率；在边缘AI场景下，云端训练好的模型可以直接下发到边缘节点，进行推理等，实现边缘AI的云边一体化。边缘自治：KubeEdge 通过消息总线和元数据本地存储实现了节点的离线自治。用户期望的控制面配置和设备实时状态更新都通过消息同步到本地存储，这样节点在离线情况下即使重启也不会丢失管理元数据，并保持对本节点设备和应用的管理能力。极致轻量：KubeEdge 则是保留了 Kubernetes 管理面，对Kubernetes的节点端组件进行重组，达到极致轻量的目的，节点组件可以运行在内存256M的边缘节点上。海量边缘设备管理：KubeEdge了可插拔式的设备统一管理框架，在云端基于Kubernetes的CRD能力，自定义了设备管理的API，完全符合Kubernetes的原生标准，用户可以在云端通过API来管理海量边缘设备；在边缘可根据不同的协议或实际需求开发设备接入驱动，当前已经支持和计划支持的协议有：MQTT，BlueTooth，OPC UA，Modbus 等，随着越来越多社区合作伙伴的加入，KubeEdge 未来会支持更多的设备通信协议。K3s架构分析K3s 是 Rancher于2019年2月开源的一个自己裁剪的 Kubernetes 发行版，K3S 名字来源于 K8s – 5，这里的“5”指的是 K3S 比 Kubernetes 更轻量使得它能更好地适配 CI，ARM，边缘技术，物联网和测试这 5 个场景。K3S 是 CNCF 官方认证的 Kubernetes 发行版，开源时间较 KubeEdge 稍晚。K3S 专为在资源有限的环境中运行 Kubernetes 的研发和运维人员设计，目的是为了在 x86、ARM64 和 ARMv7D 架构的边缘节点上运行小型的 Kubernetes 集群。K3S 的整体架构如下所示：K3S 就是基于一个特定版本 Kubernetes（例如：1.17）直接做了代码修改。K3S 分 Server 和 Agent，Server 就是 Kubernetes 管理面组件 + SQLite 和 Tunnel Proxy，Agent 即 Kubernetes 的数据面 + Tunnel Proxy。为了减少运行 Kubernetes 所需的资源，K3S 对原生 Kubernetes 代码做了以下几个方面的修改：删除旧的、非必须的代码。K3S 不包括任何非默认的、Alpha 或者过时的 Kubernetes 功能。除此之外，K3S 还删除了所有非默认的 Admission Controller，in-tree 的 cloud provider 和存储插件；整合打包进程。为了节省内存，K3S 将原本以多进程方式运行的 Kubernetes 管理面和数据面的多个进程分别合并成一个来运行；使用 Containderd 替换 Docker，显著减少运行时占用空间；引入 SQLite 代替 etcd 作为管理面数据存储，并用 SQLite 实现了 list/watch 接口；将所有Kubernetes原生进程打包在同一个进程中。K3s项目本质上是一个K8s的“轻量化”版本，而不是一个真正意义上的“边缘”版本。从架构上看，K3s 的所有组件（包括 Server 和 Agent）都运行在边缘侧，这意味着 K3S 并不是一个去中心化的部署模型，每个边缘都需要额外部署 Kubernetes 管理面，因此不涉及云边协同。也缺乏针对边缘网络不稳定性的边缘自治能力，也不涉及边缘设备的管理。此外，如果 K3s 要落到生产，在 K3s 之上应该还有一个云上的统一集群管理方案负责跨集群的应用管理、监控、告警、日志、安全和策略等，遗憾的是 Rancher 尚未开源这部分能力。OpenYurt架构分析OpenYurt是阿里云于2020年5月开源的云原生边缘计算项目，跟KubeEdge架构基本相似，OpenYurt也是依托原生Kubernetes的容器编排及调度能力，提供云边协同能力的边缘计算平台。OpenYurt 也是依托 Kubernetes 强大的容器应用编排能力，实现云-边一体化的应用分发、管控的诉求，也是从云端集中管控边缘节点，OpenYurt 的整体架构如下所示：项目目前还未发布0.1版本，从已开源部分可以看出，OpenYurt架构与KubeEdge类似，也是打通了云边协同的场景。提供的能力也与KubeEdge类似，包括边缘自治、云边协同、单元化管理能力（未开源）等。OpenYurt并未对Kubernetes进行改造，而是通过Addon（插件化）的形式提供边缘计算所需要的管控能力，边缘端的YurtHub，作为节点上的临时配置中心，在网络连接中断的情况下，持续为节点上所有设备和客户业务提供数据配置服务。这种简化的架构，重点在于解决“离线自治”问题，且比较有利于保留现有K8s的完整功能，但由于未对Kubelet进行修改，因此OpenYurt无法运行在资源有限的边缘设备中；物联网场景中的对于边缘设备的管理，OpenYurt也不涉及；并且一些边缘场景下涉及到Kubelet原生不支持的高级特性比如离线自愈、自调度等无法实现。边缘容器总结与展望对比三个开源项目， K3s 最让人印象深刻的特点在于其对 Kubernetes 进行了轻量化、部署便捷化做的尝试，通过剪裁了 Kubernetes 一些不常用功能并且合并多个组件到一个进程运行的方式，使得一些资源较充足的边缘节点上能够很方便的获得与Kubernetes一致的体验。但是从测试数据看K3s 的资源消耗还是很高，而且动辄几百 MB 的内存也不是大多数设备边缘节点所能提供的，而且目前只适合运行在边缘，不具备云边协同、边缘自治等边缘计算领域的核心诉求。OpenYurt通过非侵入的插件化形式在原生Kubernetes的基础上提供边缘计算能力，虽然提供了云边协同、边缘自治等能力，但是未做轻量化改造，只能运行在资源充足的边缘节点，无法运行在大量资源有限的边缘节点上，并且也未提供边缘计算中海量边缘设备管理的能力。KubeEdge是一个从云到边缘再到设备的完整边缘云平台，100% 兼容Kubernetes的原生API，基于Kubernetes解决了边缘计算领域的核心诉求，包括云边协同、边缘网络不稳定、边缘自治、边缘轻量化、海量边缘设备管理以及异构扩展等问题。未来边缘容器技术仍将聚焦于解决边缘计算领域所面临的云边协同、网络、设备管理、扩展及异构等挑战，KubeEdge 已经是 CNCF正式项目，未来将持续与社区合作伙伴一起制定云和边缘计算协同的标准，解决边缘计算领域的难题，结束边缘计算没有统一标准和参考架构的混沌状态，共同推动边缘计算的产业发展。转载自：华为云开发者论坛

【转载华为云社区】当今K8s独霸天下之时，咱们站在更高的角度，好好的看看K8s的网络是以什么理念构筑的。以及一个容器集群的好保姆，是如何分别照顾 南北流量和东西流量的。1      简单介绍下Kubernetes略。。容器集群管理的事实标准了，不知道要打屁股。（ps：本章节可参考唐老师的《K8S前世今生》文章）2      世界上的集群都一个样有点标题党哈，不过我接触过的各种集群也不少，各种各样：Ø  OpenStack：在一大堆物理机上面，管理（启动/停止）VM的。Ø  SGE，Slurm，PBS：在一大堆电脑集群里面，管理（启动/停止）App的。Ø  Yarn：在一大堆电脑集群里面，管理（启动/停止）大数据App的。Ø  CloudFoundry：在一大堆电脑集群里面，管理（启动/停止）容器的Ø  Kubernetes：在一大堆电脑集群里面，管理（启动/停止）容器的。它们都有一些共同特点：2.1      跨节点跑xx程序这个xx程序一定是首先单机可以运行的。比如OpenStack：单机上面可以用qemu启动VM，想跨节点管理VM，就引入了OpenStack。Kubernetes也一样：单机上面可以跑Docker容器；想跨节点管理容器，就得引入集群管理老大的概念。2.2      有一个管事的老大A）集群管理的老大，负责让手下的某个小弟干活。别管是命令式（直接下命令）的，还是申明式（发告示）的，小弟收到命令后，乖乖干活就是了。B）       同时，这个集群管理的老大，需要有脑子，不然小弟数量多了管不好。所以它需要拿笔记一记。比如OpenStack的老大得带个Mysql数据库；Kubernetes把笔记记在了ETCD里面（不过ETCD这个本子太小，记得东西不能太大，这是另话）。C）       不管哪种老大，都得有个军师。一个新活来到老大这里，那么多小弟，指派给谁不是干呀。这活实际分配给哪个小弟，这得军师说了算，所以每中集群软件都自己写了一套 Scheduler 算法，可谓程序员间浪费重复轮子之典型代表。2.3      小弟上面都有一个Agent这个小弟上面的Agent，时刻向老大汇报自己的状态：活不活着，忙还是闲，方便老大派活。同时，Agent也就是那台电脑里面的地头蛇了，帮忙老大负责各种临时事物。只是大家的取名不一样：OpenStack：取名NovaKubernetes：取名KubeletYarn：取名NodeManager2.4      老大怎么给小弟发号施令一般老大都是通过：消息队列来，给小弟发号施令的，而不是亲自上门（直连）下达命令。原因么，当然是小弟可能临时出门（故障）了呗~ 直接上门可能不通，放消息队列里面就可靠多了。等小弟出差回来，还能看到老大下达的任务令。Ø  OpenStack：用 RabbitMQ 发号施令Ø  Kubernetes：用 ETCD 发号施令Ø  CloudFoundry：用 NATS 发号施令上面这些组件都是带消息通知的功能，区别有些有名，有些没那么出名罢了。比如我们的K8s：特别需要提一下：K8s这个老大不简单，找了个ETCD这个好帮手。这小家伙挺神，既能当笔记本记点事情（代替OpenStack中的Mysql），又能当公告牌，通知点消息（代替OpenStack中的Rabbit）。所以K8s这个容器集群管理相对OpenStack这个虚机管理不需要数据库，666~3      K8s怎么设计容器网络的呢3.1      南北流量要看到K8s诞生的时候，那时是有CloudFoundry和Docker的，且都已经比较成熟。那时作为PaaS一哥的CF对容器网络的抽象：主要考虑平台外部，怎么访问容器里面的App。而平台内部的App之间如何互相访问，几乎没有太多的设计。由上图所示，可以看到，平台外部访问，一般都是上下画的，所以也叫做南北流量。我们这么叫，也是便于程序员之间沟通和理解。Ps：PaaS的基本原型大致都这样：3.2      东西流量K8s吸取了前辈们的精华，除了平台外部访问App，还新增考虑了平台内部，App之间如何互相访问。即K8s通过增加一个负载均衡的“LB”设备，来搞定平台内部的App间互相访问。给每个App取个别名，在LB上面登记一下，就可以被内部其他App访问。由上图所示，可以看到，平台内部访问，一般都是水平画的，所以也叫做东西流量。一个完整的PaaS平台，就是需要南北流量+东西流量，全套治理的。3.3      Docker原生访问方式还记得唐老师的《Docker网络实现》章节吧，Docker容器可以通过“节点IP+节点Port”的方式访问到容器。原理的容器所在节点，设置了NAT规则。报文一到达节点，根据目的端口，转发进入容器。3.4      小结：K8s中3种访问容器的通道（1）       通过南北流量（从集群外部访问App）访问App容器（2）       通过东西流量（集群内App之间）访问App容器（3）       通过Docker原生自带的方式，访问App容器下一章节，我们简单介绍下每种方式，K8s分别怎么去实现的。4      K8s怎么实现容器访问虽然K8s上面，有多种访问App容器的方法。但是不管用什么方式访问，一个App想要能被访问，就得得到K8s的同意。K8s把这个许可证叫做“Service”：也就是不管什么南北流量、东西流量，你的App想要能被访问，就得先申请Service许可证。4.1      南北流量要实现一个App的访问通道，一定要2个东西：（1）LB负载均衡器 + （2）注册映射关系。映射关系就是：报文来了，应该转发给哪个App实例？ 即：找到 “哪个App + 哪个实例”。负载均衡器呢，一般大家爱用Nginx，不过也有其他类型的实现。K8s比CF聪明的地方是，没有自己去实现LB。而只定义了App需要怎么样才能登记到LB上面。即只定规范，不限制实现（这种思路，在k8s里面好多，比如存储的CSI，运行时的CRI的，容器网络的CNI 都是这样。）Ø  4层LB最简单的4层LB实现，K8s取了个名字：LoadBalancer（1）。即定义：xx协议+xx端口 =》xx应用，具体规则自己去看资料。Ø  7层LB为了定义7层LB的规则，K8s给规范取了名字：Ingress（2）。即定义：xx网址+xx-URL路径 =》xx应用，具体规则也自己看K8s资料。南北LB都是全局级的，即：全局一个（HA多实例，咱也当一个整体）就行；不需要每个Slaver节点上一个。4.2      东西流量东西流量，也一样，需要LB+规则注入。这里，K8s设计就比较有意思。逻辑上，如上图所示。在LB部分的实现上，K8s很巧妙的要求每个节点上面都一个“小LB”。所以实现上，大致如上图所示。Ø  本地LB本地LB，要求每个节点都有。所以最开始的版本，K8s使用了Linux使用广泛的iptables来实现。后面由于iptables性能不是特别给力，又有了 IPVS 实现。然后其他各式各样的民间实现也有。Ø  本地控制器LB需要一个控制器，每个本地“小LB”带配备一个小控制器，一样的，也是每个节点一个。和小LB一一对应。K8s给它取了个名字：Kube-proxyØ  假IP地址每个K8s上的App，都可以申请“行走江湖的名号”，用来代表自己。K8s就会给你的App分配一个Service许可证，许可证上面带着“影子IP”，任何集群内部只要访问这个IP，就等于访问你的App。实现上：1.     先到K8s那登记，说我想要个“名号”2.     通过后，K8s会告知每个节点上的本地LB3.     从此以后，每个LB都认识这个“影子IP”了，访问它，就代表访问对应App。由于这个“名号”是集群颁布的，所以仅在集群内有效。K8s取名：ClusterIP（3）。关于东西流量的故事，还可以去看看唐老师之前的《网络骗子》篇。4.3      Docker原生访问方式除了上面几种访问方式，K8s也为原生的Docker访问通道留了个名字：NodePort（4）。这种方式，在《Docker网络实现》里面说过，靠主机Host转发实现。既然是主机搞定，所以这条路和本地LB实现，就合并一起搞定了。如上图，K8s下发规则的时候，顺便把这条路的规则也下发下去。ps：由于每个本地LB都收到了K8s的通告小皮鞭，所以每个K8s的节点，都开通了NodePort通道哦。即：无论哪个Slaver节点的Port都可以通往该App。4.4      小结K8s在实现容器网络的时候，造了很多概念：（1）       LoadBalancer（2）       Ingress（3）       ClusterIP（4）       NodePort本质都是一样的，就是LB+登记规范。 如果你看过《DNS篇》+《Docker网络实现》，这些就比较好理解。ps：具体本地LB怎么实现？真有兴趣可以去搜搜Kube-proxy的代码解读。我本身不是很关心，因为其实你给每个节点安装一个 Nginx 也可以做到的。5      总结K8s的网络概念，特别是Service，是K8s里面的精华，务必需要搞明白。（1）       K8s南北流量，用Loadbalancer（4层）和Ingress（7层）搞定。（2）       K8s的东西流量，用Service概念搞定。特别的，还给了个“行走江湖用的名号”，取名ClusterIP（一个不存在的假IP地址）。（3）       容器所在Host组网，存在Docker原生通道，K8s给重新包装了个名字：NodePort。所以只要报文到达Slaver节点，就能通到容器里面。另外，提一下一直没有说的东西（怕概念太多，影响理解）：K8s的整个网络底座，是要求节点IP和容器IP是能互相连通的（即：在节点上面ping容器IP，是可以通的）。具体则是通过容器网络实现的。这个实现很多，Flannel，Calico等，本质要么隧道，要么子网（可以看看物理网络里面的《VLAN和Vxlan》篇，关于如何划分门派的篇章）。

【转载华为云社区】华为鲲鹏服务器安装docker-compose前一久天参加了华为举办的云南省大学生自主创新大赛·鲲鹏赛道要求充分理解和认知鲲鹏云服务，且将云服务应用到参赛作品中且解决具体的系统问题华为鲲鹏服务器华为鲲鹏服务器采用华为自研cpu ARMv8架构,提供 Windows 和多个Linux 系统，作为服务器使用我一直使用Centos系统本次使用 CentOS 7.6 64bit with ARMdocker 作为官方的编排工具，是非常重要的，它可以让用户通过编写一个简单的模板文件，快速地创建和管理基于docker容器的应用集群。Compose 定位是“定义和运行多个docker容器的应用”。Compose中有两个重要的概念：项目(project)：由一组关联的应用容器组成的一个完整业务单元，在docker-compose.yml文件中定义。服务(service)：一个应用的容器，实际上可以包括若干运行相同镜像的容器实例。Compose 的默认管理对象是项目，通过子命令对项目中的一组容器进行便捷地生命周期管理。实验了好多次发现：不要用python2来安装docker-compose，得下载python3还有一点，在开始前找到对应的ARM架构的yum源换一个（我已经找到标记好了），因为自带的源安装会有问题得通过备份换源解决1234567891011121314151617181920212223242526272829#!/bin/bash# 更新yummv  /etc/yum .repos.d /CentOS-Base .repo  /etc/yum .repos.d /CentOS-Base .repo.backupwget http: //mirrors .aliyun.com /repo/Centos-altarch-7 .repo -O  /etc/yum .repos.d /CentOS-Base .repoyum makecache# 安装dockercurl -fsSL https: //get .daocloud.io /docker  |  bash  -s docker --mirror Aliyun # 配置dockermkdir  -p  /etc/docker tee  /etc/docker/daemon .json <<- 'EOF'{   "registry-mirrors" : [ "http://*********" ],       "log-driver" :  "json-file" ,     "log-opts" : {         "max-size" :  "50m" ,         "max-file" :  "3"     }}EOF systemctl daemon-reloadsystemctl restart docker # docker-composeyum  install  -y libffi libffi-devel openssl-devel python3 python3-pip python3-devel pip3  install  -i https: //pypi .tuna.tsinghua.edu.cn /simple  docker-compose查看安装是否成功：1docker-compose - vDocker Compose 常用命令build：构建或者重新构建项目中的服务容器1$ docker-compose build [options] [service...]start: 启动已经存在的服务容器1$ docker-compose start [service...]stop: 停止已经处于运行状态的容器，但不删除它。通过docker-compose start 可以再次启动这些容器。1$ docker-compose stop [options] [service...]up: 它将尝试自动完成包括构建镜像，（重新）创建服务，启动服务，并关联服务相关容器的一系列操作。链接的服务都将会被自动启动，除非已经处于运行状态。1234567$ docker-compose up [options] [service...] options:   -d 在后台运行服务容器   --no-deps 不启动服务所链接的容器   --force-recreate 强制重新创建容器，不能与 --no-recreate同时使用   --no-recreate 如果容器已经存在了，则不重新构建，不能与--force-recreate同时使用rm: 删除所有（停止状态的）服务容器。推荐先执行docker-compose stop 命令来停止容器。12345$ docker-compose  rm  [options] [service...] options:   -f,--force 强制直接删除，包括非停止状态的容器。一般尽量不要使用该选项。   - v  删除容器所挂载的数据卷。kill：通过发送 SIGKILL 信号来停止指定服务的容器docker-compose kill eureka1$ docker-compose  kill  eurekascale：设置指定服务运行容器的个数，以 service=num 形式指定1$ docker-compose scale web=5 db=3将启动5个容器运行web服务，3个容器运行db服务。一般情况下，当指定数目多于该服务当前实际运行容器，将新创建并启动容器；反之，将停止容器。

【转载华为云】产品信息请点击：https://www.huaweicloud.com/product/cce.html体验云原生之旅：https://activity.huaweicloud.com/cloudnative.html?ggw_hd1.导言当今全球正处于一个数字化颠覆的时代，对于企业而言，积极拥抱数字化转型能够带来业务和管理上的双重提升。华为云容器CCE敏捷版，为企业提供数字化新基建的云原生技术平台，帮助您实现业务敏捷上线、业务战略快速落地。1、企业对数字化转型的需求搭建企业的数据底座：全量数据进湖，实时计算，实时分析，发挥数据的“魔力”提升业务快速上线能力：借助ServiceMesh服务网格强大商用能力，实现业务快速上线高效可靠的运维能力：提供可靠的容器镜像构建和部署，可以快速上线、扩缩容、回滚构建企业微服务架构：基于Istio的非侵入微服务治理能力，进行微服务改造2、云容器技术对企业的价值降低基础设施成本：资源的细粒度管理，可以大幅提升资源利用率，减少基础设施成本缩短应用上线周期：统一应用打包标准，快速在研发/测试/生产环境间分发、部署、上线快速构建跨云业务：标准的运行环境和API，在不同的容器平台上能无缝迁移、统一管理提升应用运维效率：完善的应用生命周期管理能力和自动扩缩容机制，提升运维效率30%+2.华为云容器CCE敏捷版介绍华为云容器CCE敏捷版（简称：CCE敏捷版），是基础设施解耦的企业级、轻量化、智能化的云原生平台，面向混合云形态下，企业业务云原生化转型升级场景，提供云原生业务基础，帮助企业快速转型升级。*部署方式：适用于客户本地机房、公有云、混合云、多云等环境CCE敏捷版的优势：组织匹配、精细控制的租户权限模型完善的租户权限模型（组织-用户），匹配企业研发组织模型、跨集群实现资源、业务的灵活隔离基于角色访问权限控制（RBAC），精细的控制每个租户的资源权限；支持跨云多集群的多租户级别的RBAC管控支持对接多种用户系统（LDAP、SAML、OpenID、华为云IAM等），免除多套租户系统的维护负担支持资源使用计量计费，适合企业内部结算场景云原生、高性能、安全的容器网络方案高性能自研插件：多种UnderLay模式网络，容器网络性能接近主机网络与主流厂商的ELB对接，动态为容器提供对外访问能力（华为云、阿里云、F5、Nginx等）网络QOS：精细化实现流量控制，避免网络堵塞精细化的网络策略：灵活实现组织、项目、Pod三级网络隔离支持容器网络固定IP、源地址保留全面兼容社区生态及华为云商业软件Everest容器存储管理，支持多云存储网关丰富的存储方案：全面支持云容器存储标准，原生支持业界主流存储方案及华为商业存储方案支持AI容器：kubeflow、gpu、Atlas服务器/昇腾芯片支持大数据容器：spark、flink支持基因容器：KubeGene/GCS支持Volcano批量计算引擎面向各类业务场景，兼容各类基础设施兼容物理机与虚拟机：支持直接部署在物理机或业界主流IaaS虚拟化之上与主流云厂商的计算能力对接，动态增删节点，自动弹性伸缩集群（华为云、阿里云、openstack、vsphere等）多异构计算支持：GPU、鲲鹏服务器、昇腾芯片，支持全栈国产化兼容多种操作系统：支持业界主流的操作系统，如CentOS，RedHat，Ubuntu等支持多集群的创建和管理; 支持5000节点规模集群; 支持非高可用集群（单master节点）支持混合云场景：支持线上线下集群统一管控；支持跨云故障检测，应用迁移生态丰富、精细化的运维能力，专业的运维保障全面兼容Prometheus生态：云原生标准监控采集和日志采集接口，支持自定义扩展，全面涵盖集群、容器、应用各层次的监控、日志、告警、调用链等。监控告警信息持久化运维管理RBAC：支持租户的运**限管理，根据角色精细化控制用户的运维管理权限专业运维支持：提供7*24小时运维支持，技术专家现场咨询、培训、维护，为用户提供专业的运维保障。原生服务网格Istio，实现非侵入式云原生应用发布和治理精细化应用发布：金丝雀、蓝/绿发布，提高版本迭代速度，降低业务风险服务级流量治理：一键使能Istio服务网格，非侵入式流量治理策略配置，轻松管理运行态应用智能化、自动化：全面应用流量健康诊断，智能化提供精准治理策略，轻松高效构建应用SLA能力多云/混合云网络流量管理：灵活应对业务流量突发，业务可靠和容灾等问题容器化DevOps解决方案开箱即用，内置标准化流程模板简化使用支持alpha-beta-gamma多环境端到端敏捷交付开放式架构，易于与企业已有系统集成镜像P2P加速，解决各类行业场景问题，支持1W节点分钟级镜像分发3.华为云容器发展历程华为云的业界影响和贡献：CNCF初创成员和白金会员，10多个maintainer席位，K8s累计贡献全球TOP4 /国内TOP1OCI（Open Container Initiative）初创成员，社区累计贡献排名全球TOP3/国内TOP1Istio社区贡献排名全球TOP3/国内TOP1华为主导开源的项目：KubeEdge，Volcano，KubeGene，CNI-Genie华为云产品CCE通过全球首批 “Kubernetes软件一致性认证”华为云全球首批通过了Kubernetes认证的服务提供商， KCSP（Kubernetes Certified Service Provider）4.华为云容器业务全景图 基于华为自身实践与社区的贡献积累，华为云自上线之初，就持续利用云原生技术为用户提供标准化、可移植的领先云原生服务。目前，华为云容器及相关服务已覆盖CNCF技术全景图中的七大类别，华为云容器业务全景图如下：华为云提供高性能、高可用、高安全的企业级容器服务，通过CNCF官方认证的两种Kubernetes服务供用户选择。核心的商业产品包括云容器引擎 CCE和云容器实例 CCI，以及与这两个服务配套的镜像仓库、交付流水线、服务网络、智能运维等服务。在核心产品之上，构建了三大水平解决方案，分别是：裸金属容器解决方案、容器混合云解决方案和批量计算解决方案。     云容器引擎（Cloud Container Engine，简称CCE）提供高度可扩展的、高性能的企业级Kubernetes集群，支持运行Docker容器。提供了Kubernetes集群管理、容器应用全生命周期管理、应用服务网格、Helm应用模板、插件管理、应用调度、监控与运维等容器全栈能力，为您提供一站式容器平台服务。借助云容器引擎，您可以在华为云上轻松部署、管理和扩展容器化应用程序。5.典型应用场景场景一：企业业务云原生转型-企业级、轻量化、智能化    企业有数字化转型诉求，希望建设容器平台，实现降本增效目标。价值：CCE敏捷版使您能够在本地IDC构建更可靠、更高效、更安全的Kubernetes集群，帮助用户轻松创建和管理多样化的容器工作负载，并提供容器故障自愈、监控日志采集、自动弹性扩容等高效运维能力，企业级服务网格Istio以及容器化Devops方案。场景二：微服务治理-开箱即用、无缝对接、一站式监测伴随着互联网技术的不断发展，各大企业的系统越来越复杂，传统的系统架构越来越不能满足业务的需求，取而代之的是微服务架构。微服务是将复杂的应用切分为若干服务，每个服务均可以独立开发、部署和伸缩；微服务和容器组合使用，可进一步简化微服务的交付，提升应用的可靠性和可伸缩性。随着微服务的大量应用，其构成的分布式应用架构在运维、调试、和安全管理等维度变得更加复杂，在管理微服务时，往往需要在业务代码中添加微服务治理相关的代码，导致开发人员不能专注于业务开发，还需要考虑微服务治理的解决方案，并且将解决方案融合到其业务系统中。价值：CCE敏捷版深度集成应用服务网格，提供开箱即用的应用服务网格流量治理能力，用户无需修改代码，即可实现灰度发布、流量治理和流量监控能力。场景三：DevOps交付-一站式交付、效率提升80%当前IT行业发展日益快速，面对海量需求必须具备快速集成的能力。经过快速持续集成，才能保证不间断的补全用户体验，提升服务质量，为业务创新提供源源不断的动力。大量交付实践表明，不仅传统企业，甚至互联网企业都可能在持续集成方面存在研发效率低、工具落后、发布频率低等方面的问题，需要通过持续交付提高效率，降低发布风险。价值：CCE敏捷版搭配容器镜像服务提供DevOps持续交付能力，能够基于代码源自动完成代码编译、镜像构建、灰度发布、容器化部署，实现一站式容器化交付流程，并可对接已有CI/CD，完成传统应用的容器化改造和部署。场景四：高性能批量计算-高效调度、异构算力、效率提升30%对于AI、大数据、基因测序、视频处理等行业的用户，其业务特点是数据量大，并且需要大量的计算资源。价值：支持普通业务和AI和大数据业务混合调度，实现底层平台统一。大数据计算业界趋势从存算合一走到存算分离，性价比提升40%，以某行信用卡中心批处理出报告为例，时间从3天缩短到1天。计算由容器承载，原生K8s不支持成组、队列优先级等AI&大数据批处理场景，通过Volcano智能调度，提升30% AI、大数据、基因测序的速度。 场景五：跨云部署-流量自动分发、降低成本多云部署、容灾备份为保证业务高可用，需要将业务同时部署在多个云的容器服务上，在某个云出现事故时，通过统一流量分发的机制，自动的将业务流量切换到其他云上。流量分发、弹性伸缩大型企业客户需要将业务同时部署在不同地域的云机房中，并能自动弹性扩容和缩容，以节约成本。业务上云、数据库托管对于金融、安全等行业用户，业务数据的敏感性要求将数据业务保留在本地的IDC中而将一般业务部署在云上，并需要进行统一管理。开发与部署分离出于IP安全的考虑，用户希望将生产环境部署在公有云上，而将开发环境部署在本地的IDC。价值：云容器引擎利用容器环境无关的特性，将私有云和公有云容器服务实现网络互通和统一管理。应用和数据可独立部署在本地IDC，也可部署在云端，实现本地和云端的无缝迁移，并可统一运维多个云端资源，从而实现资源的灵活使用以及业务容灾等目的。

【转载华为云社区】产品信息请点击：https://www.huaweicloud.com/product/cce.html体验云原生之旅：https://activity.huaweicloud.com/cloudnative.html?ggw_hd1.导言当今全球正处于一个数字化颠覆的时代，对于企业而言，积极拥抱数字化转型能够带来业务和管理上的双重提升。华为云容器CCE敏捷版，为企业提供数字化新基建的云原生技术平台，帮助您实现业务敏捷上线、业务战略快速落地。1、企业对数字化转型的需求搭建企业的数据底座：全量数据进湖，实时计算，实时分析，发挥数据的“魔力”提升业务快速上线能力：借助ServiceMesh服务网格强大商用能力，实现业务快速上线高效可靠的运维能力：提供可靠的容器镜像构建和部署，可以快速上线、扩缩容、回滚构建企业微服务架构：基于Istio的非侵入微服务治理能力，进行微服务改造2、云容器技术对企业的价值降低基础设施成本：资源的细粒度管理，可以大幅提升资源利用率，减少基础设施成本缩短应用上线周期：统一应用打包标准，快速在研发/测试/生产环境间分发、部署、上线快速构建跨云业务：标准的运行环境和API，在不同的容器平台上能无缝迁移、统一管理提升应用运维效率：完善的应用生命周期管理能力和自动扩缩容机制，提升运维效率30%+2.华为云容器CCE敏捷版介绍华为云容器CCE敏捷版（简称：CCE敏捷版），是基础设施解耦的企业级、轻量化、智能化的云原生平台，面向混合云形态下，企业业务云原生化转型升级场景，提供云原生业务基础，帮助企业快速转型升级。*部署方式：适用于客户本地机房、公有云、混合云、多云等环境CCE敏捷版的优势：组织匹配、精细控制的租户权限模型完善的租户权限模型（组织-用户），匹配企业研发组织模型、跨集群实现资源、业务的灵活隔离基于角色访问权限控制（RBAC），精细的控制每个租户的资源权限；支持跨云多集群的多租户级别的RBAC管控支持对接多种用户系统（LDAP、SAML、OpenID、华为云IAM等），免除多套租户系统的维护负担支持资源使用计量计费，适合企业内部结算场景云原生、高性能、安全的容器网络方案高性能自研插件：多种UnderLay模式网络，容器网络性能接近主机网络与主流厂商的ELB对接，动态为容器提供对外访问能力（华为云、阿里云、F5、Nginx等）网络QOS：精细化实现流量控制，避免网络堵塞精细化的网络策略：灵活实现组织、项目、Pod三级网络隔离支持容器网络固定IP、源地址保留全面兼容社区生态及华为云商业软件Everest容器存储管理，支持多云存储网关丰富的存储方案：全面支持云容器存储标准，原生支持业界主流存储方案及华为商业存储方案支持AI容器：kubeflow、gpu、Atlas服务器/昇腾芯片支持大数据容器：spark、flink支持基因容器：KubeGene/GCS支持Volcano批量计算引擎面向各类业务场景，兼容各类基础设施兼容物理机与虚拟机：支持直接部署在物理机或业界主流IaaS虚拟化之上与主流云厂商的计算能力对接，动态增删节点，自动弹性伸缩集群（华为云、阿里云、openstack、vsphere等）多异构计算支持：GPU、鲲鹏服务器、昇腾芯片，支持全栈国产化兼容多种操作系统：支持业界主流的操作系统，如CentOS，RedHat，Ubuntu等支持多集群的创建和管理; 支持5000节点规模集群; 支持非高可用集群（单master节点）支持混合云场景：支持线上线下集群统一管控；支持跨云故障检测，应用迁移生态丰富、精细化的运维能力，专业的运维保障全面兼容Prometheus生态：云原生标准监控采集和日志采集接口，支持自定义扩展，全面涵盖集群、容器、应用各层次的监控、日志、告警、调用链等。监控告警信息持久化运维管理RBAC：支持租户的运**限管理，根据角色精细化控制用户的运维管理权限专业运维支持：提供7*24小时运维支持，技术专家现场咨询、培训、维护，为用户提供专业的运维保障。原生服务网格Istio，实现非侵入式云原生应用发布和治理精细化应用发布：金丝雀、蓝/绿发布，提高版本迭代速度，降低业务风险服务级流量治理：一键使能Istio服务网格，非侵入式流量治理策略配置，轻松管理运行态应用智能化、自动化：全面应用流量健康诊断，智能化提供精准治理策略，轻松高效构建应用SLA能力多云/混合云网络流量管理：灵活应对业务流量突发，业务可靠和容灾等问题容器化DevOps解决方案开箱即用，内置标准化流程模板简化使用支持alpha-beta-gamma多环境端到端敏捷交付开放式架构，易于与企业已有系统集成镜像P2P加速，解决各类行业场景问题，支持1W节点分钟级镜像分发3.华为云容器发展历程华为云的业界影响和贡献：CNCF初创成员和白金会员，10多个maintainer席位，K8s累计贡献全球TOP4 /国内TOP1OCI（Open Container Initiative）初创成员，社区累计贡献排名全球TOP3/国内TOP1Istio社区贡献排名全球TOP3/国内TOP1华为主导开源的项目：KubeEdge，Volcano，KubeGene，CNI-Genie华为云产品CCE通过全球首批 “Kubernetes软件一致性认证”华为云全球首批通过了Kubernetes认证的服务提供商， KCSP（Kubernetes Certified Service Provider）4.华为云容器业务全景图 基于华为自身实践与社区的贡献积累，华为云自上线之初，就持续利用云原生技术为用户提供标准化、可移植的领先云原生服务。目前，华为云容器及相关服务已覆盖CNCF技术全景图中的七大类别，华为云容器业务全景图如下：华为云提供高性能、高可用、高安全的企业级容器服务，通过CNCF官方认证的两种Kubernetes服务供用户选择。核心的商业产品包括云容器引擎 CCE和云容器实例 CCI，以及与这两个服务配套的镜像仓库、交付流水线、服务网络、智能运维等服务。在核心产品之上，构建了三大水平解决方案，分别是：裸金属容器解决方案、容器混合云解决方案和批量计算解决方案。     云容器引擎（Cloud Container Engine，简称CCE）提供高度可扩展的、高性能的企业级Kubernetes集群，支持运行Docker容器。提供了Kubernetes集群管理、容器应用全生命周期管理、应用服务网格、Helm应用模板、插件管理、应用调度、监控与运维等容器全栈能力，为您提供一站式容器平台服务。借助云容器引擎，您可以在华为云上轻松部署、管理和扩展容器化应用程序。5.典型应用场景场景一：企业业务云原生转型-企业级、轻量化、智能化    企业有数字化转型诉求，希望建设容器平台，实现降本增效目标。价值：CCE敏捷版使您能够在本地IDC构建更可靠、更高效、更安全的Kubernetes集群，帮助用户轻松创建和管理多样化的容器工作负载，并提供容器故障自愈、监控日志采集、自动弹性扩容等高效运维能力，企业级服务网格Istio以及容器化Devops方案。场景二：微服务治理-开箱即用、无缝对接、一站式监测伴随着互联网技术的不断发展，各大企业的系统越来越复杂，传统的系统架构越来越不能满足业务的需求，取而代之的是微服务架构。微服务是将复杂的应用切分为若干服务，每个服务均可以独立开发、部署和伸缩；微服务和容器组合使用，可进一步简化微服务的交付，提升应用的可靠性和可伸缩性。随着微服务的大量应用，其构成的分布式应用架构在运维、调试、和安全管理等维度变得更加复杂，在管理微服务时，往往需要在业务代码中添加微服务治理相关的代码，导致开发人员不能专注于业务开发，还需要考虑微服务治理的解决方案，并且将解决方案融合到其业务系统中。价值：CCE敏捷版深度集成应用服务网格，提供开箱即用的应用服务网格流量治理能力，用户无需修改代码，即可实现灰度发布、流量治理和流量监控能力。场景三：DevOps交付-一站式交付、效率提升80%当前IT行业发展日益快速，面对海量需求必须具备快速集成的能力。经过快速持续集成，才能保证不间断的补全用户体验，提升服务质量，为业务创新提供源源不断的动力。大量交付实践表明，不仅传统企业，甚至互联网企业都可能在持续集成方面存在研发效率低、工具落后、发布频率低等方面的问题，需要通过持续交付提高效率，降低发布风险。DevOps持续交付场景价值：CCE敏捷版搭配容器镜像服务提供DevOps持续交付能力，能够基于代码源自动完成代码编译、镜像构建、灰度发布、容器化部署，实现一站式容器化交付流程，并可对接已有CI/CD，完成传统应用的容器化改造和部署。场景四：高性能批量计算-高效调度、异构算力、效率提升30%对于AI、大数据、基因测序、视频处理等行业的用户，其业务特点是数据量大，并且需要大量的计算资源。价值：支持普通业务和AI和大数据业务混合调度，实现底层平台统一。大数据计算业界趋势从存算合一走到存算分离，性价比提升40%，以某行信用卡中心批处理出报告为例，时间从3天缩短到1天。计算由容器承载，原生K8s不支持成组、队列优先级等AI&大数据批处理场景，通过Volcano智能调度，提升30% AI、大数据、基因测序的速度。 场景五：跨云部署-流量自动分发、降低成本多云部署、容灾备份为保证业务高可用，需要将业务同时部署在多个云的容器服务上，在某个云出现事故时，通过统一流量分发的机制，自动的将业务流量切换到其他云上。流量分发、弹性伸缩大型企业客户需要将业务同时部署在不同地域的云机房中，并能自动弹性扩容和缩容，以节约成本。业务上云、数据库托管对于金融、安全等行业用户，业务数据的敏感性要求将数据业务保留在本地的IDC中而将一般业务部署在云上，并需要进行统一管理。开发与部署分离出于IP安全的考虑，用户希望将生产环境部署在公有云上，而将开发环境部署在本地的IDC。价值：云容器引擎利用容器环境无关的特性，将私有云和公有云容器服务实现网络互通和统一管理。应用和数据可独立部署在本地IDC，也可部署在云端，实现本地和云端的无缝迁移，并可统一运维多个云端资源，从而实现资源的灵活使用以及业务容灾等目的。

【转载华为云社区】大家言必称云原生，却鲜少有人告诉你到底什么是云原生，若是找资料来看，读完大多会感觉云绕雾罩，一知半解，总之虚得很；甚至会让你一度怀疑自己的智商，不过我对于读不懂的文章，一律归因于写文章的人太蠢，当然这不一定是事实，但这样的思考方式能让我避免陷入自我怀疑的负面情绪。云原生之所以解释不清楚，是因为云原生没有确切的定义，云原生一直在发展变化之中，解释权不归某个人或组织所有。何谓云原生？技术的变革，一定是思想先行，云原生是一种构建和运行应用程序的方法，是一套技术体系和方法论。云原生（CloudNative）是一个组合词，Cloud+Native。Cloud表示应用程序位于云中，而不是传统的数据中心；Native表示应用程序从设计之初即考虑到云的环境，原生为云而设计，在云上以最佳姿势运行，充分利用和发挥云平台的弹性+分布式优势。Pivotal公司的Matt Stine于2013年首次提出云原生（CloudNative）的概念；2015年，云原生刚推广时，Matt Stine在《迁移到云原生架构》一书中定义了符合云原生架构的几个特征：12因素、微服务、自敏捷架构、基于API协作、扛脆弱性；到了2017年，Matt Stine在接受InfoQ采访时又改了口风，将云原生架构归纳为模块化、可观察、可部署、可测试、可替换、可处理6特质；而Pivotal最新官网对云原生概括为4个要点：DevOps+持续交付+微服务+容器。2015年云原生计算基金会（CNCF）成立，CNCF掺和进来后，最初把云原生定义为包括：容器化封装+自动化管理+面向微服务；到了2018年，CNCF又更新了云原生的定义，把服务网格(Service Mesh)和声明式API给加了进来。可见，不同的人和组织对云原生有不同的定义，相同的人和组织在不同时间点对云原生也有不同的定义，真是乱的一匹，搞得鄙人非常晕菜，我的应对很简单，选一个我最容易记住和理解的定义：DevOps+持续交付+微服务+容器。总而言之，符合云原生架构的应用程序应该是：采用开源堆栈（K8S+Docker）进行容器化，基于微服务架构提高灵活性和可维护性，借助敏捷方法、DevOps支持持续迭代和运维自动化，利用云平台设施实现弹性伸缩、动态调度、优化资源利用率。云原生构建应用简便快捷，部署应用轻松自如、运行应用按需伸缩。优点不一而足，缺点微乎其微；秒杀传统Web框架，吊打祖传IT模式，实在是保命**、评优晋级不可多得的终极绝密武器。云元素的四要素微服务：几乎每个云原生的定义都包含微服务，跟微服务相对的是单体应用，微服务有理论基础，那就是康威定律，指导服务怎么切分，很玄乎，凡是能称为理论定律的都简单明白不了，不然就忒没b格，大概意思是组织架构决定产品形态，不知道跟马克思的生产关系影响生产力有无关系。微服务架构的好处就是按function切了之后，服务解耦，内聚更强，变更更易；另一个划分服务的技巧据说是依据DDD来搞。容器化：Docker是应用最为广泛的容器引擎，在思科谷歌等公司的基础设施中大量使用，是基于LXC技术搞的，容器化为微服务提供实施保障，起到应用隔离作用，K8S是容器编排系统，用于容器管理，容器间的负载均衡，谷歌搞的，Docker和K8S都采用Go编写，都是好东西。DevOps：这是个组合词，Dev+Ops，就是开发和运维合体，不像开发和产品，经常刀刃相见，实际上DevOps应该还包括测试，DevOps是一个敏捷思维，是一个沟通文化，也是组织形式，为云原生提供持续交付能力。持续交付：持续交付是不误时开发，不停机更新，小步快跑，反传统瀑布式开发模型，这要求开发版本和稳定版本并存，其实需要很多流程和工具支撑。如何云原生？首先，云原生借了云计算的东风，没有云计算，自然没有云原生，云计算是云原生的基础。随着虚拟化技术的成熟和分布式框架的普及，在容器技术、可持续交付、编排系统等开源社区的推动下，以及微服务等开发理念的带动下，应用上云已经是不可逆转的趋势。云计算的3层划分，即基础设施即服务(IaaS)、平台即服务(PaaS)、软件即服务(SaaS)为云原生提供了技术基础和方向指引，真正的云化不仅仅是基础设施和平台的变化，应用也需要做出改变，摈弃传统的土方法，在架构设计、开发方式、部署维护等各个阶段和方面都基于云的特点，重新设计，从而建设全新的云化的应用，即云原生应用。1. 本地部署的传统应用往往采用c/c++、企业级java编写，而云原生应用则需要用以网络为中心的go、node.js等新兴语言编写。2. 本地部署的传统应用可能需要停机更新，而云原生应用应该始终是最新的，需要支持频繁变更，持续交付，蓝绿部署。3. 本地部署的传统应用无法动态扩展，往往需要冗余资源以抵抗流量高峰，而云原生应用利用云的弹性自动伸缩，通过共享降本增效。4. 本地部署的传统应用对网络资源，比如ip、端口等有依赖，甚至是硬编码，而云原生应用对网络和存储都没有这种限制。5. 本地部署的传统应用通常人肉部署手工运维，而云原生应用这一切都是自动化的。6. 本地部署的传统应用通常依赖系统环境，而云原生应用不会硬连接到任何系统环境，而是依赖抽象的基础架构，从而获得良好移植性。7. 本地部署的传统应用有些是单体(巨石)应用，或者强依赖，而基于微服务架构的云原生应用，纵向划分服务，模块化更合理。可见，要转向云原生应用需要以新的云原生方法开展工作，云原生包括很多方面：基础架构服务、虚拟化、容器化、容器编排、微服务。幸运的是，开源社区在云原生应用方面做出了大量卓有成效的工作，很多开源的框架和设施可以通过拿来主义直接用，2013年Docker推出并很快成为容器事实标准，随后围绕容器编排的混战中，2017年诞生的k8s很快脱颖而出，而这些技术极大的降低了开发云原生应用的技术门槛。虽说云原生的推介文档有引导之嫌，但面对它列举的优点，作为杠精的我亦是无可辩驳。这么说的话，云原生也忒好了吧，应用是不是要立刻马上切换到云原生架构？我的观点是：理想很丰满，现实经常很骨感，需从应用的实际需要出发，目前的问题是否真的影响到业务发展，而推倒重来的代价能否承受得来。技术的趋势和影响软件设计有两个关键目标：高内聚、低耦合，围绕这2个核心目标，又提出了单一职责、开闭原则、里氏替换、依赖导致、接口隔离、最少知识等设计原则。软件工程师一直都在为这两个目标而努力奋斗，以求把软件编写得更加清晰、更加健壮、更加易于扩展和维护。但后来，人们发现有更多的诉求，希望开发软件变得更简单、更快捷，程序员希望更少编写代码，非专业人员也希望能开发程序，于是，更多的更傻瓜的编程语言被发明出来，更多的编程技术和编程思想被发明出来，比如库、组件、云基础设施。于是很多技术变成了屠龙之技，比如汇编，时代变了，建国后动物不能成精了，没有龙可以宰了，然后很多软件工程师摇身一变成了调参工程师、Call API砖家、用库包能手、拼组件达人，这是效率分工的结果，也是技术发展的使然。纵观近二十年的科技互联网发展历程，大的趋势是技术下沉，特别是近些年，随着云计算的发展和普及，基础设施越来越厚实，业务开发变得越来越容易，也越来越没有技术含量，而之前困扰小团队的性能、负载、安全性、扩展性问题都不复存在，这不禁让互联网行业的油腻大叔们噤若寒蝉，仿佛分分钟就要被卷入历史洪流而万劫不复。虽然不可否认技术的重要性在降低，但也还不至于那么悲观。遥想PC时代，当VB、Delphi、MFC出现的时候，也有类似论调，所见即所得，点点鼠标，就可以开发PC桌面程序，是不是很高端？那时候码农的担心相比现在恐怕是只多不少吧，但后来随着互联网兴起，出现了后端开发这个工种，码农很快找到了新的战场，网络、分布式、数据库、海量服务、容灾防错，于是又玩出一堆新花样。如果说PC时代的基础设施是控件库，互联网时代的基础实施是云，那AI时代基础设施是什么？又会有什么高端玩法？---------------------------作者：“人民副首席码仔”

多接入边缘计算（MEC）作为云计算的演进，将应用程序托管从集中式数据中心下沉到网络边缘，更接近消费者和应用程序生成的数据，在靠近移动用户的网络边缘提供IT和云计算的能力，并利用网络能力开放获得高带宽、低延迟、近端部署优势，从而产生新的业务和收入的机会，创造出新的商业模式。MEC是实现5G低延迟和提升带宽速率等的关键技术之一，同时MEC为应用程序和服务打开了网络边缘，包括来自第三方的应用程序和服务，使得通信网络可以转变成为其它行业和特定客户群的多功能服务平台。MEC系统架构根据欧洲电信标准协会（ETSI）的定义，MEC系统分主机级和系统级两个层次，其中MEC系统级网管包含MEC编排器MEO、OSS、应用生命周期管理代理，主机级包含MEC主机和MEC主机级网管。MEC主机由虚拟化基础设施VI、MEC平台MEP、MEC应用组成，其中MEC平台为MEC应用发现和使用提供内部或外部服务的环境，并通过对第三方MEC应用的开放，从而加强网络与业务的深度融合。MEC主机级网管含MEC平台网管MEPM和虚拟化基础设施网管VIM。5G MEC系统整体架构如图1所示图1 5G MEC系统整体架构MEC主机部署方案分析随着5G和垂直行业的成熟商用，网络需要接入更多设备、处理海量数据、满足低时延业务需求，传统核心网集中式部署模式已不能满足新业务需求，网络随业务流向边缘迁移已是产业趋势，5G网络原生采用云化建设，更加轻盈和灵活，以中心DC（大区中心机房）、区域DC（省层面机房）、核心DC（本地网核心机房）、边缘DC（本地网汇聚机房）、接入局所DC、基站机房为基础架构的分层DC化机房布局模式成为各运营商传统机房改造演进的共同路线。MEC系统级网管需要协调不同MEC主机之间以及主机与5GC之间的操作（如选择主机、应用迁移、策略交互等），一般部署在区域DC（省层面）或者中心DC（大区中心）。通常所说的MEC部署位置主要针对MEC系统的主机级部分，MEC对低时延业务的支持能力以及对流量和计算分流的能力，使其在5G的三大业务场景（增强型移动宽带、超可靠低时延通信和海量大规模连接物联网）中都有用武之地，三大业务场景及不同应用、不同用户对时延、带宽和计算分流的要求各不一样，对应MEC的部署要求也不尽相同。MEC主机部署方面应以业务为导向按需部署，并与UPF的下沉和分布式部署相互协同，在实际组网中，根据对操作性、性能或安全的相关需求，MEC可以灵活地部署在从基站附近到中央数据网络的不同位置。但是不管如何部署，都需要由UPF来控制流量指向MEC应用或是指向网络。图2概述了MEC物理位置的一般可行选项。图2 5G网络部署架构MEC部署在接入局所DC此种模式一般采用MEC和基站CU共机房，部署在基站后面，数据业务离用户更近，终端发起的业务经过基站、MEC主机到互联网/第三方内容服务，主要针对新型超低时延业务在边缘才能满足需求的场景，时延可控制在1ms~10ms之内，如无人机投递业务（10ms，15Mbit/s）、智慧场馆（10ms，1Gbit /s）、自动驾驶（1ms，50Mbit/s以上）、远程医疗诊断（10ms，50Mbit/s）、机器人协作（1ms，1~10Mbit/s）、远程手术（1ms~10ms，300Mbit/s）等。MEC部署在边缘DC此种模式MEC一般部署在本地网汇聚机房，逻辑位置在UPF/PGW-U（用户面网关）之后，会增加一部分回传网络的时延，可以为用户提供低时延、高带宽服务，如AR/VR业务（20ms，1Gbit/s）、移动视频监控（20ms，50Mbit/s）、移动广播（小于100ms，10Mbit/s）、公共安全（20ms，10Mbit/s）、高清视频（20ms，10Mbit/s）等。为降低时延，使用户可以就近取得所需的内容，以提高用户访问网站的响应速度，MEC设备通常具有CDN（内容分发网络，Content Delivery Network）功能，相较于传统CDN，MEC更靠近无线接入网，下沉的位置更深。由于物理距离的减少，自然移动边缘计算相较于CDN时延进一步降低，并且MEC还包括了本地化的计算能力和能力开放能力，因此具备了低时延和智能化特点，在传统CDN的应用场景之外，在诸如车联网、智慧医疗等要求智能化的应用场景中也将起到非常大的作用。MEC部署中面临的挑战及解决建议当前运营商在部署MEC主机时，普遍面临传统接入局房、汇聚机房配套基础设施薄弱的困境，同时由于边缘计算的业务特征和开放的需求，部署过程中面临机房配套不足、应用管理/编排统一性、安全防护和能力开放等典型问题。一是机房配套基础设施薄弱。传统接入局房、汇聚机房环境差异较大，如果虚拟化基础设施采用NFV架构下的通用硬件，大部分机房需改造承重、电源、空调等，机房面积也无法满足NFV庞杂的边缘设备群需求，可以考虑采用更加灵活适配的增强型硬件，比机架式服务器占地小、功耗低，更适合于边缘机房部署。并且为解决NFV中虚拟层占用资源比例较多问题，边缘采用I层轻量化方案，支持裸机容器，降低管理面资源占用。二是应用管理/编排缺乏统一性。MEC业务特性决定系统中存在运营商网元和第三方IT应用等多种业务，需要对编排管理采用统一流程和接口。建议由运营商云管平台统管资源，根据不同业务场景灵活进行编排管理：对于强合作业务，可以通过统一门户进行应用编排部署；对于自管理类业务，可以直接在边缘节点进行应用编排部署。三是安全防护不到位。边缘机房相对开放，安全防护措施较少，第三方应用部署后电信内部网络会面临被攻击风险，需要设置由外而内的分层隔离与防护方案，如外部攻击防护方案、分子域隔离方案、应用隔离方案等。四是核心网能力要开放。在eMBB业务2C场景下，第三方APP存在无法让用户访问边缘节点的问题，需要靠核心网能力开放解决，在无法通过用户报文IP地址识别用户的区域的情况下，通过辅助AF实现边缘调度和按需分流。MEC平台的广泛部署将为运营商、设备商、OTT和第三方公司带来新的运营模式。在实际部署中，运营商可根据规划的业务场景以及对网络的时延、安全性、容量等方面的要求，视服务范围、用户特点，对局部化的业务需求具体需求具体分析，按需选择差异化的部署方案，对部署中面临的典型问题需要选择合适的解决方案。

         转载自：https://bbs.huaweicloud.com/blogs/170483        博文作者：无微不至            “未来的软件一定是生长于云上的”1. 云原生时代的应用云原生时代，随着容器技术、微服务架构思想、产品研发运营模式不断地推陈出新和迅速发展，应用的设计和开发落地门槛已经降低到了历史低点。根据国际知名数据咨询公司IDC（国际数据公司）的调查研究表明，从2018年到2023年将有超过500,000,000个应用被创建，这个数字是过去40年所有创建应用的总和。另外，在IDC于2020年2月发布的《IDC FutureScape: 全球云计算2020 年预测——中国启示》中显示，云原生应用所影响的领域正逐渐从互联网走向非互联网，从传统应用升级走向云原生。当下，云原生技术的成熟正极大地影响着个人、企业乃至整个社会的生产生活方式。下面是几条与云原生应用强相关的预测内容：分布式云：到2021年，中国90%以上的企业将依赖于本地/专属私有云、多个公有云和遗留平台的组合，以满足其基础设施需求。API生态：到2023年，90%的新数字服务将使用公有云和内部API提供的服务构建复合型应用程序；其中一半将利用人工智能（AI）和机器学习（ML）。多云管理：到2022年，50%的企业将部署统一的VMs、Kubernetes和多云管理流程和工具，以支持跨本地和公有云部署的多云管理和治理。云堆栈扩展：到2024年，10%的企业内部工作负载将由公有云服务商数据中心以外的、位于客户数据中心和边缘位置的公有云堆栈提供支持。超敏捷APP：到2023年，50%的中国企业应用将部署在容器化的混合云/多云环境中，以提供敏捷的、无缝的部署和管理体验。在这场应用的变革中，越来越多的应用所有方会将应用基础设施交由更加专业的公有云/混合云服务商进行管理，通过API的方式对基础设施进行管理，由服务商提供更加敏捷和无缝的部署管理功能。如此，应用所有方可以将更多的投资及人力投入聚焦到应用本身的业务逻辑设计、开发、运维和体验优化，大大减少了产品上市的时间并得到了更高的可伸缩性，使应用开发的ROI（投资回报率）最大化。2. 使用微服务架构构建云原生应用云原生应用的定义有多种版本，最早为2015年pivital提出了云原生应用的定义，随后CNCF在2015年也对云原生应用进行了定义，2018年进行了重定义，具体定义可以参考kubernetes-handbook。可以发现自从云原生的概念出现，微服务架构就是云原生应用中浓墨重彩的一部分。这一节里会讲到微服务架构使用场景，微服务应用在整个应用技术栈中的位置，和开发一个微服务你需要做的事情。2.1. 使用微服务的场景构建云原生应用，首先一定是企业或者个人想要最大程度将自己的时间和精力从复杂的底层依赖开发维护中解放出来，集中在业务场景的设计和实现上，并且能够独立解耦的自动化完成应用各个模块的开发落地。这意味着独立开发的某一模块或负责某一单独业务的开发者，会最大程度的利用云厂商提供地DevOps工具链完成整个应用开发运维的共同目标，这样大家可以轻松地将应用作为一个松耦合的服务集合快速发布和更新，降低成本的同时也更容易避免单点故障。2.2. 微服务应用在技术栈中的位置假设应用所有者已经做好了微服务的业务设计，我们来看看在落地阶段，微服务应用在产品研发和运行中的位置： 红色部分为微服务应用的核心模块，是由应用所有者开发和维护地运行时微服务应用。随着业务的增长，受系统能力影响，为了提高微服务的高可用、可靠性以及韧性，需要对微服务进行治理。常见的治理手段有：负载均衡、熔断、限流、降级、容错和隔离等，篇幅有限这里不加赘述。黄色部分从左到右代表从Dev到Ops的技术栈。首先，应用开发者需要根据应用类型，选择依赖的微服务开发框架（chassis），使用框架时可以通过添加注解的方式，处理微服务运行时面临的横切面问题（crosscutting concern），比如：日志框架（log4j/logback）、健康检查、metrics、分布式追踪等。其次，编码完成后，可使用云服务厂商提供的DevOps工具链能力实现代码的归档、编译构建、发布部署等能力，将微服务部署在运行环境中。最后，还可以利用云服务厂商提供的运维能力对微服务进行运维监控。一般来说，云服务厂商提供的应用平台能力也是独立而解耦的，应用所有者可根据自己的需求和预算来自定义选择自己需要的服务。紫色部分是运行时技术栈，蓝色箭头代表流量的流向。当微服务部署运行起来后，流量会从各种客户端首先连接到入口（比如服务网关/ELB），同时，流量在这里会根据请求特征分发到各个对应的业务处理微服务，随后对请求进行一系列的处理，返回结果。微服务的运行还依赖了很多中间件，比如：缓存、消息等；还有一些微服务的功能特性，比如：服务网格、服务注册发现等，这些中间件或特性也都由框架或者云服务厂商提供。微服务和中间件等其实都是上层服务部署在基础设施上，比如：虚机、容器或CCI实例。 综上所述，一个应用的落地其实涉及到很多技术和场景，使用微服务架构开发应用可以最大程度的简化应用所有者对底层设施和中间件的管理运维，通过自定义使用云服务厂商提供地全场景、端到端的应用平台能力，将资源聚焦在业务创新和落地上（红框部分）。3. 实践 - 一元体验all above最后打个小广告：华为云CSE微服务平台提供了以ServiceComb开源框架拖底的配置中心和服务中心，提供动态配置和可靠的服务中心服务。ServiceComb服务中心在华为内部的大规模生产实践（支撑华为商城运行），支撑起数十万级别的tps的服务集群，可靠性得到了充分的验证。开发者可以在云上享受开箱即用的微服务中间件，通过CSE微服务平台既可以学习实践又能作为生产实践，学习微服务可以跟进当下最新技术潮流。华为云回馈活动指路↓一元体验原价500元包周期引擎（100实例），快来体验吧！https://activity.huaweicloud.com/paas_devcloud0.html铛铛铛~新用户体验，还有码豆回馈，豪礼多多喔！CSE还提供了免费试用产品（20实例）回馈广大开发者，快来试用吧https://console.huaweicloud.com/servicestage/?region=cn-east-2&package=basic&new=true#/appdev/engine/list 

DevOps，是Development和Operations的组合词，是指一组过程、方法与系统的统称，用于促进开发、技术运营和质量保障部门之间的沟通、协作与整合。DevOps是一种重视“软件开发人员（Dev）”和“IT运维技术人员（Ops）”之间沟通合作的文化、运动或惯例。透过自动化“软件交付”和“架构变更”的流程，来使得构建、测试、发布软件能够更加地快捷、频繁和可靠。它的出现是由于软件行业日益清晰地认识到：为了按时交付软件产品和服务，开发和运营工作必须紧密合作。DevOps的出现，源于在传统模式下的开发和运维组织上的分离造成的管理混乱，开发要不断的迭代新版本上线新功能，但是运维关注的是稳定，这两种需求实际上是矛盾的。但DevOps旨在打破这道混乱之墙，让开发、运维、测试协同作战，提高研发效率，实现高效交付，解决传统模式下的运维之痛。而事实证明，DevOps确实能够较好的解决开发和运维之间的混乱问题，提升研发效率，实现高效交付。在近期中国信通院（CAICT）发布的《中国DevOps现状调查报告（2019年）》（以下简称报告）中，超八成企业表示，通过采用DevOps中的核心工程实践——持续交付——获得了研发效率的显著提升。同时调查发现，具备清晰、明确变更管理系统的组织，平均变更前置时间（即从代码被成功提交到成功运行在生产环境平均需要的时间），即通常意义上的交付时间也相对较短。正是因为DevOps能够给企业带来的诸多益处，目前，DevOps已经成为企业软件研发的主流，被众多企业所采用。报告显示，超半数企业使用DevOps的敏捷工程实践管理开发项目，近6成企业选择编码规范、单元测试和持续集成。然而，虽然众多企业都期望DevOps能够给它们带来更高效的交付效率，提升客户满意度，创造更多的商业价值，但成功实践DevOps依然是一个难题。在报告中，实际能够真正成功实施DevOps的企业仅有31.65%，另外，还有接近四成（41.13%）的企业居然不清楚自己是否成功实施DevOps，这不得不说是一个令人感到意外的结果。而当我们认真研究当前中国企业的DevOps现状时，就会明白这个结果也在情理之中。当前，虽然国内应用DevOps的众多，DevOps已经在国内逐步落地实践，但大部分企业仍然位于DevOps能力成熟度初始级和基础级，其比例高达7成。而在DevOps的细分领域，例如DevOps的敏捷开发管理成熟度方面，同样是近七成企业仍然处在基础级和全面级，仅有1.83%的企业处于卓越级。而且虽然大多数企业企业普遍采取了敏捷开发方法以提升研发效率，但敏捷开发技术普及率有待提升，研发管理流程严谨性不足。同样，在应用设计方面和安全风险管理方面，多数企业也是位于初始级和基础级。同时，在持续交付方面，企业的自动化测试整体覆盖率普遍偏低；在技术运营方面，企业整体运营能力有待提高，缺乏对潜在风险的管理。再加上企业中有近7成的的研发人员DevOps经验少于1年，在这样的情况下，得到上述的调查结果也就不足为奇了。总之，从报告来看，目前国内大多数企业的DevOps应用还是处在初始级和基础级的阶段，需要向全面级、优秀级、卓越级转变。而要实现企业DevOps从初始级、基础级向全面级、优秀级、卓越级转变，除了企业要增强对于DevOps的重视度之外，选择合适的DevOps工具和技术就显得至关重要了。而从报告中显示，近九成的企业会选择云来助力DevOps实践落地，这是因为，DevOps就是在开发和部署周期中设计开发人员需要的环境的自动化，以最大限度地减少开发人员的等待时间，并允许开发人员在代码基础上获得更多的迭代。考虑到这些环境一直处于变化状态，因此，DevOps是基于云计算的天然盟友，在云计算的支撑下企业能够立即启动支持开发和部署过程中涉及的各种环境所需的资源以实施DevOps。同时，在易用性、可伸缩性和性能方面有着卓越表现的微服务，成为了企业软件开发最受欢迎的架构，而微服务和DevOps有着非常密切的联系。微服务在具有众多优势外也带来了实施上的复杂性，整个系统由单一应用拆分为多个服务，微服务之间存在较强的依赖关系，服务之间如何协作如何处理就变得非常复杂。由于微服务是一个网状分布的，有很多服务需要维护和管理，对它进行部署维护和监控管理的时候就比较复杂。因此使用微服务，第一步是要构建一个一体化的DevOps平台。DevOps包含了持续集成与持续发布，服务依赖关系管理，服务的发现与负载均衡，以及集中化监控管理，这些都是微服务生态系统所必不可少的工具和实践。而近几年火热的容器技术也被誉为是DevOps的天作之合，它的出现使DevOps落地实践相对容易，而保持跨环境的一致性和灵活的可移植性是企业选择容器的主要因素。这些调查结果表明，大多数企业在DevOps实践过程中，基于云计算、微服务、容器给企业带来的诸多益处，都会选择云+微服务+容器的方式来具体落地DevOps。而在具体的工具选择上，国外厂商的产品仍然占据大半江山，JIRA在需求和项目管理领域拔得头筹、Gitlab位居代码管理首位。虽然国外老牌传统工具JIRA仍然以52.13%的市占率高居DevOps工具选择之首，但与云结合的DevOps工具的发展势头良好，国内厂商也在其中占据了一席之地，特别是在软件开发一体化管理领域，排名前两位的分别是国内公有云大厂华为云DevCloud与阿里云效，分别占据16.46%与10.98%的市场份额。尽管从整体上来看，软件开发一体化的DevOps平台目前在市场中的占有率仍然偏低，但从未来发展的趋势来看，与云结合的一体化DevOps将是未来DevOps平台发展的一个重要方向，这从报告中的企业广泛选择云以及与云计算有着紧密联系的微服务架构和容器可以得到很好地佐证。而在这个领域，之所以中国厂商能够占据领先的地位，和两家厂商在中国公有云市场的强势发展是分不开的。特别是华为云DevOps之所以能够成为报告中唯一占据一个首位的DevOps工具，首先应该得益于华为30多年软件研发的沉淀，这些在多年软件研发中积累的丰富经验，使得华为深知开发者到底需要怎样的DevOps工具，在这样的理念上推出的DevCloud，受到企业和开发者的青睐，自然就是水到渠成的事情了。其次，华为云DevCloud针对需求变动频繁、开发测试环境复杂、多版本分支维护困难、无法有效监控进度和质量等开发者研发中的普遍痛点，使开发人员实现软件研发过程可视、可控、可度量，还可以实现一键式部署，解决开发者在应用部署方面的挑战。而云端代码检查、自动化测试管理和APP测试功能，能够显著避免代码出错情况的发生，分布式代码托管功能更是为开发者的代码提供了一个可靠的“家园”。第三，华为云DevCloud不仅对外服务，其本身就孵化于华为内部的软件研发能力中心，至今还在为内部所有软件研发人员服务，在可用、可靠、安全性方面都经过了实践应用的检验。这些优点汇聚起来，得到这样的结果也就在情理之中了。实际上，从本质上讲，DevOps 不只是一种技术或方案，它更多的是文化，它重视“软件开发人员（Dev）”和“IT运维技术人员（Ops）”之间沟通合作，以提高整个软件开发生命周期的效率以及质量。因此，谁拥有更多的开发者，谁更加了解开发者，谁就能更加准确的掌握开发者的需求，引领软件工程能力的趋势，也能做出更加接地气的产品，谁更新迭代的速度更快，谁就越有可能在未来的长跑中获胜。虽然从此次调查结果来看，国外厂商的DevOps产品仍然处于领先地位，但我们相信，在以华为云为代表的国内厂商的共同努力下，我国的软件工程能力将会得到显著的提升，我国的DevOps产品的能力也会得到迅速的提高，从而帮助中国企业落地DevOps，推动中国企业从DevOps的初始级和基础级的阶段，向全面级、优秀级、卓越级转变，全方位的促进国内软件产业发展，打造软件产业发展新模式，推动中国软件产业不断向前发展。                                                                                                                                                                  转载自：云计算开源产业联盟

转载自：华为云开发者公众号近期，Gartner发布最新《Market Share: IT Services, Worldwide 2019》研究报告，华为云全球IaaS市场排名上升至第六，增速高达222.2%，全球增速最快，中国市场排名前三。华为云已服务于政府、互联网、汽车制造、金融、基因等多个行业，包括30多个国家级部委、600多家政府与公共事业单位、互联网50强企业中的30家、20多家大型车企、14家基因领域企业等。2019年华为云新加坡、智利、巴西、墨西哥、秘鲁大区陆续开服，与伙伴在全球23个地理区域运营45个可用区。截至2019年底，华为云已上线200多个云服务、190多个解决方案，包括69款华为云鲲鹏云服务、43款昇腾云服务；300万企业和开发者基于华为云进行云端开发。在基础服务领域，华为云推出系列鲲鹏云服务，为企业提供多样算力；推出容器混合云、以及高性能容器批量计算解决方案，加速企业云原生转型；发布存算分离解决方案BigData Pro、极速IO云硬盘、All-Connect企业级云网络解决方案等。华为云推出43款基于昇腾的AI云服务，释放澎湃算力；提供ModelArts一站式AI开发与管理平台、HiLens端云协同AI开发应用平台、一站式数据运营平台DAYU等开发平台和工具。面向行业，华为云EI推出工业智能体、交通智能体及城市智能体，将AI技术与行业专家经验深度融合，让人工智能用得起、用得好、用得放心。华为云发布企业智能工作平台WeLink，实现以用户为中心的四个联接：联接团队、业务、知识、IoT，助力政府和企业的数字化升级。目前,华为云WeLink稳定高效地支撑了各行各业远程办公，包括中国近万家医院、各级卫健委、疾控中心等医疗机构和政府单位、学校，以及金融、能源、制造、交通等行业的数十万家企业。2019年，华为云发展咨询合作伙伴10000家，伙伴贡献收入占比超过60%，并与全球多家顶级咨询公司、运营商建立战略合作关系。华为云与2000家技术合作伙伴开展深度合作，云市场上架伙伴应用数量3500个，实现技术生态的商业闭环，形成紧耦合的技术生态。围绕鲲鹏，华为云推出鲲鹏凌云伙伴计划，为合作伙伴提供培训、技术、营销、市场的全方位支持，帮助伙伴基于华为云鲲鹏云服务进行开发、应用移植，并开辟云市场鲲鹏专区，助力伙伴商业变现。未来，华为云将继续发挥云、AI和5G的协同优势，通过全栈技术创新，提供稳定可靠、安全可信、可持续发展的公有云服务和混合云解决方案，赋能应用、使能数据，做智能世界的“黑土地”，与伙伴一起使能千行百业，实现数字化转型和智能化升级。

【活动已结束，中奖结果已公布，请各位参与者查看第一条评论内容】 关注华为云的各位开发者们大家应该对“云享读书会”系列课程再熟悉不过没得了解过的童鞋们，今天版主也不吝啬自己的耐心给大家“官方”地再介绍一下↓↓↓华为云·云享读书会系列课程，每期会选取一本技术相关的畅销书籍邀请原作者/业内大咖提炼书籍精华分享领读视频，帮助大家快速积累专业知识↑↑↑自从《云享读书会》上线以来让无数热爱开发的童鞋在大牛的助力下从青铜走向了王者所以，今年版主为了让更多不同段位的童鞋们都可以快速“升段”，完成逆袭特意在温暖的春夏交界—华为云·读书月将全系列云享读书会进行分类整理让大家可以快速找到自己想了解的课程，快速进入学习当然，本次的学习必然是免费并且，版主还不能辜负你们努力的成果这段时间所有来参与学习的开发者们必！须！有！奖！励！ +++++++++++++++++我是正经分割线+++++++++++++++++【云享读书会系列课程介绍及报名】◎敏捷类：▶敏捷转型：打造VUCA时代的高效能组织讲师：王明兰   著名精益&敏捷转型专家   本期书籍作者点击下方链接可直接免费报名  https://education.huaweicloud.com:8443/courses/course-v1:HuaweiX+CBUCNXV014+Self-paced/about▶猎豹行动：敏捷转型之旅讲师：刘华   汇丰软件开发（广东）有限公司软件工程经理点击下方链接可直接免费报名https://education.huaweicloud.com:8443/courses/course-v1:HuaweiX+CBUCNXV019+Self-paced/about◎区块链类：▶区块链技术及应用讲师：Kevin   华为云区块链产品经理   本期书籍作者团专家之一Kai   华为云区块链专家   本期书籍作者团专家之一点击下方链接可直接免费报名https://education.huaweicloud.com:8443/courses/course-v1:HuaweiX+CBUCNXP016+Self-paced/about ◎数据库类：▶数据仓库工具箱讲师：张剑博士  华为GuassDB产品技术专家点击下方链接可直接免费报名https://education.huaweicloud.com:8443/courses/course-v1:HuaweiX+CBUCNXE093+Self-paced/about▶SQL优化核心思想讲师：徐铭  华为高斯数据库主任工程师点击下方链接可直接免费报名https://education.huaweicloud.com:8443/courses/course-v1:HuaweiX+CBUCNXV026+Self-paced/about ◎DevOps类： ▶敏捷无敌之DevOps时代讲师：王立杰  本期书籍作者之一          许舟平  本期书籍作者之一          姚冬    华为云DevCloud首席技术布道师          徐磊    华为云MVP、英捷创软（LEANSOFT）创始人兼首席架构师点击下方链接可直接免费报名https://education.huaweicloud.com:8443/courses/course-v1:HuaweiX+CBUCNXV016+Self-paced/about以上就是云享读书会全部6期内容，想要了解哪个类型书籍，可直接点击链接了解详情并报名+++++++++++++++++我是读书会介绍分割线+++++++++++++++++【如何免费读书又花式得奖】对于本次活动，我们推出了三种玩法，让你获得知识的同时还能花式有奖▶NO.1：报名读书会：即日起报名学习以上6期中任意一本书籍/课程，成功报名后，如图所示截图反馈到本帖，即有奖？（之前报名过读书会的开发者们直接按示例截图就可以参与哦~）▼截图示例如下：keke~~记住截图的时候书籍名称和登录名都要清晰可见哦~ ▶NO.2：提交读书笔记：学完书籍后，写出你的读书心得，要求≥200字，并将读书笔记直接反馈给本帖，即有奖？ ▶NO.3：推荐朋友参与读书会：将任意读书会链接分享或活动海报（上方竖图）到≥10人的群或朋友圈，截图反馈到本帖，即有奖？+++++++++++++++++我是读书会有奖分割线+++++++++++++++++【有奖评判标准&奖品】NO.1：报名读书会：在所有报名者中随机抽取20名，奖励“人人都需-旅行本套装”NO.2：提交读书笔记：在所有提交读书笔记者中，由专家专业评选出5名“优质读后感”，奖励“人人都爱-无线鼠标”NO.3：推荐朋友参与读书会：在所有分享参与者中，随机抽取20名，奖励“人人都备-定制鼠标垫” ============我是奖品============我是奖品人人都需-旅行本套装（20份）人人都爱-无线鼠标（5份） 人人都备-定制鼠标垫（20份）奖品是我============奖品是我============ 怎么样？既能免费学习！还能轻松拿奖？这等好事恐怕不多见吧？各位开发者们，还不赶快搞起来吗？+++++++++++++++++我是拿奖品有标准分割线+++++++++++++++++【活动时间&注意事项】◎本次活动时间为：即日起-6月12日23:59止，请大家注意时间◎三个小分项互动形式均为直接回帖，请各参与者注意，直接与小助手互动无效◎获奖结果将在活动结束后3个工作日内进行公示，所有奖品将在活动结束后15个工作日内发放，请各参与者注意◎每个ID只能得奖一次，同一ID不可重复得奖◎有任何问题都可以随时回帖留言，版主看到会第一时间帮你解决 老铁们，给你们个跟大牛“肩并肩”的机会将自己的业务水平提升的同时还能花式拿奖这！谁不爱？谁不来？ 

IT互联网的变革浪潮奔腾不息，传统企业的数字化转型如火如荼，适应市场需求与创新力的提升是不变的主题，而引入DevOps是企业快速发展的便捷之路，打破开发、测试和IT运营部门之间的沟通壁垒，提升质量与效率，才是企业完美转身的方式。近几年，我们见证了云计算、大数据、微服务架构和容器等技术井喷发展，对于企业打造DevOps生态链也提供了更加便捷的支持，促使企业在市场快速变化时也能实现大跨步有姿态的发展。可行业没有清晰标杆，野蛮生长下对于自身的真实水平，处于行业哪个阶段就成了很多企业的困惑，方向是否正确？未来道路是否平坦？怎样克服实践困难？因此由中国信息通信研究院牵头发起的《研发运营一体化（DevOps）能力成熟度模型》即DevOps标准直击痛点，该标准分别从敏捷开发管理、持续交付、技术运营、应用设计、安全和风险管理及系统和工具等几个环节，全面评估企业DevOps实践的现状，进行优劣势分析，明确改进方向及策略。下图为《研发运营一体化（DevOps）能力成熟度模型》总体框架。2019年，中国信息通信研究院联合云计算开源与产业联盟、华为与南京大学进行了首次关于中国DevOps现状的问卷调查，并发布《2019年中国DevOps现状调查报告》，在业界产生了良好的反响。目前，由中国信息通信研究院联合云计算开源与产业联盟、高效运维社区、南京大学、腾讯蓝鲸智云、百度、京东智联云、苏宁消费金融、华为云 DevCloud、中国移动通信研究院、中国电信天翼云、中国联通软件研究院、中国农业银行、广东移动、浙江移动、平安科技、云智慧等企业共同发起的2020年中国DevOps现状调查已经正式启动，现诚挚地邀请各位业界同仁参与本次调查。本问卷以中国信息通信研究院牵头编制的《研发运营一体化（DevOps）能力成熟度模型》标准为参考，聚焦中国DevOps实践成熟度现状，并根据问卷填写情况实时给出受访者所在组织的DevOps实践成熟度。无论您是刚刚开始 DevOps 之旅，还是已经成为 DevOps 实践专家，我们都非常乐于聆听您的意见，您的见解对整个DevOps行业的发展具有宝贵价值。回答该问卷大约占用您20分钟的时间。这份问卷是匿名的，调查结果只用于统计、分析和生成最终的调查报告，我们将确保不会泄漏每一位受访者的相关信息。如果您希望得到您所在组织的DevOps 实践现状及建议，同时了解国内其他组织实践 DevOps 的最新水平，请您如实填写问卷，以便本调查能够捕捉到每个人真实的情况与想法，我们期待您的参与！同时，也欢迎将问卷推荐给您认为适合参加本次调查的专业人士。我们将赠送给部分幸运受访者由高效运维社区、腾讯蓝鲸智云、京东智联云、云智慧、苏宁消费金融、华为云DevCloud等企业赞助的纪念品，以感谢各位的热情参与，因此请填写准确联系方式和地址，以便纪念品发放，部分纪念品如下图所示。在此，也感谢各位合作单位对本次调查的大力支持！本调查问卷将在线开放一个月的时间，于5月15日截止，并计划于7月份正式发布《2020年中国DevOps现状调查报告》，每一位完整回答问卷的朋友都将第一时间免费收到最新的完整版调查报告。最后，感谢您对我们研究工作的支持！现在就开始您的DevOps实践探索之旅吧！参与2020年中国DevOps现状调查问卷请长按识别下图二维码！《2020年中国DevOps现状调查》全面启动！问卷填写地址：点我参与调研

镜像是容器运行的基础，在容器的构建开发阶段，镜像一旦存在漏洞，就有可能导致在后续运行环境里面所有运行这个镜像的容器都存在安全问题。例如，镜像中的软件存在漏洞、镜像存在病毒后门，就可能导致容器被不法分子控制利用，从而导致容器中的敏感信息被泄露、整个系统沦陷等风险。那么，如何在构建开发阶段排查镜像的安全性呢？华为云容器安全服务（Container Guard Servic，CGS）的私有镜像漏洞扫描功能帮助您解决这个困扰，让您在容器构建开发阶段就能发现镜像的安全问题，得到一个安全可靠的镜像文件，避免使用危险镜像进行开发。目前，私有镜像扫描功能支持对基于Linux操作系统制作的容器镜像进行检测，且是免费的哦~~还没有开通CGS的用户来体验本节课程的操作？戳这里，了解开通CGS。玩转CGS私有镜像安全扫描CGS支持对容器镜像服务（Software Repository for Container，SWR）中的自有镜像进行检测。将自有镜像上传至SWR，然后更新到CGS后，CGS即可在每日凌晨自动检测更新的镜像。检测完成后，您就可以查看漏洞报告和根据提供的解决方案对镜像进行修复和调整。现在教大家一个口诀，“一更二查三修复”，完成这三个步骤，您就能得到一个安全可靠的镜像文件啦~~【一更】从SWR更新镜像若SWR镜像已更新到CGS，您可以跳过此步骤，直接查看镜像版本的漏洞报告。步骤1：登录管理控制台。步骤2：在页面上方选择区域后，单击，选择“安全 > 容器安全服务”。步骤3： 在左侧导航树中，选择“镜像列表”，进入“镜像列表”界面。步骤4：选择“私有镜像仓库”页签。步骤5： 单击“从SWR更新镜像”，更新镜像到CGS私有镜像仓库。CGS对镜像进行检测需要一段时间，百兆级的镜像，大概需要10分钟左右，扫描耗时随镜像的规模增大而延长。请您过一段时间在进行刷新查看哦~~ 【二查】查看镜像版本的漏洞报告步骤1：自动检测完成后，在需要查看漏洞报告的镜像左侧，单击展开该镜像的版本列表，然后单击“漏洞报告”，查看该镜像各个版本的漏洞报告。步骤2：漏洞报告按照“需尽快修复”、“可延后修复”、“暂可不修复”三个漏洞等级汇总漏洞信息，并且展示了漏洞的具体信息以及相应的漏洞解决方案。小窍门对于漏洞的修复或调整，您可以根据自身业务情况进行选择性修复，对系统影响较小的镜像，可不进行修复【三修复】对镜像进行修复或调整单击解决方案列的链接，根据解决方案对该镜像版本进行修复和调整。修复和调整后，您就可以得到一个安全可信的镜像啦~~对于私有镜像，CGS还提供了恶意文件、基线配置、软件信息和文件信息的检测，有没有很心动，赶紧戳它了解详情吧~~更多关于CGS的功能，戳这里安全无小事，时刻需警惕。2020，华为云普惠云安全，为您的网站、主机、数据提供免费云体检，还有一站式过等保贴心指导，赶紧戳这里，了解详情吧！

1 Hpcg简介    高性能共轭梯度（HPCG）基准项目是一项旨在创建用于对HPC系统进行排名的新指标的工作。HPCG旨在作为高性能LINPACK（HPL）基准的补充，该基准目前用于对TOP500计算系统进行排名。HPL的计算和数据访问模式仍然代表着一些重要的可伸缩应用程序，但不是全部。HPCG旨在行使与不同而广泛的重要应用程序更加紧密匹配的计算和数据访问模式，并激励计算机系统设计人员投资于将影响这些应用程序总体性能的功能。  2 环境信息2.1 环境信息项目版本下载地址CentOS7.6https://www.centos.org/download/Kernel4.14.0包含在操作系统镜像中CPU鲲鹏920服务器配置16U16GB40GB  3 配置编译环境3.1 Yum源配置说明：根据依赖或软件来源的不同，以及配置过程的不同，yum源配置分为如下三种：１、本地yum源２、网络yum源３、华为yum源不作任何配置时，则默认使用Centos官方yum源（需要外网权限）。Yum源详细配置，可以参考：《KunPeng平台软件移植Yum源配置参考》，本次使用本地yum源方式。3.2 安装依赖包步骤1   安装依赖包。yum install wget git gcc-c++ gcc-gfortran----结束   4 安装说明：本文将介绍两种安装方式，请视具体情况选择其中一种安装方式。表 4-1 安装方式说明安装方式安装说明源码编译安装 源码安装，与环境内核无冲突，可定制，但是复杂度高。rpm方式安装rpm包方式，方便简单（当部署环境与本文档环境一致时，推荐使用本方式）。4.1 源码编译安装4.1.1 获取源码步骤 1   下载mpich源码。wget http://www.mpich.org/static/downloads/3.2.1/mpich-3.2.1.tar.gz                                              解压源码tar xzf mpich-3.2.1.tar.gz 步骤 2   下载hpcg源码。git clone https://github.com/hpcg-benchmark/hpcg.git说明：如果提示”git: 未找到命令”，请先用yum install git安装git工具。  4.1.2 编译安装mpich步骤 1   编译配置。cd mpich-3.2.1./configure --prefix=/usr/local 步骤 2   编译安装。make -j16make install 步骤 3   配置环境变量。vi /etc/profile在文件末尾添加：export PATH=/usr/local/bin:$PATHsource /etc/profile查看环境变量是否生效：which mpicc && which mpiexec创建目录：mkdir machinefile测试运行：mpiexec -f machinefile -n 3 hostname && mpiexec -n 5 -f machinefile ./examples/cpi  4.1.3 编译安装hpcg步骤 1   修改配置文件。cd /opt/hpcg/setupvim Make.Linux_MPI文件修改如下：MPdir        = /usr/localMPlib        = $(MPdir)/lib/libmpi.a /usr/lib64/libpthread-2.17.so /usr/lib64/libc-2.17.soCXX          = /usr/local/bin/mpicxx 步骤 2   编译配置。mkdir buildcd build/opt/hpcg/configure Linux_MPI步骤 3   编译安装。make -j16 4.2 RPM方式安装4.2.1 mpich安装说明：附件中的rpm都是通过开源代码编译打包而成，并验证通过，打包过程参考”6 RPM打包“。见附件步骤 1   复制RPM包至服务器“ /opt”目录并安装。ll /opt步骤 2   安装RPM包。yum localinstall /opt/mpich-3.2.1-1.el7.aarch64.rpm 步骤 3   添加环境变量。vi /etc/profile在文件末尾添加：export PATH=$PATH:/usr/local/mpich3.2.1/binexport LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/local/mpich3.2.1/libsource /etc/profile查看环境变量是否生效：which mpicc && which mpiexeccd /usr/local/mpich3.2.1创建目录：mkdir machinefile测试运行：mpiexec -f machinefile -n 3 hostname && mpiexec -n 5 -f machinefile ./examples/cpi----结束 4.2.2 hpcg安装说明：附件中的rpm都是通过开源代码编译打包而成，并验证通过，打包过程参考”6 RPM打包“。见附件步骤 1   复制RPM包至服务器“ /opt”目录并安装。ll /opt步骤 2   安装RPM包。yum localinstall /opt/ hpcg-3.1.0-1.el7.aarch64.rpm  ----结束 5 运行和验证5.1 运行测试步骤 1   执行验证。切换至编译安装目录bin目录。源码方式安装：cd /opt/hpcg/setup/build/binRpm方式安装：cd /usr/local/hpcg-HPCG-release-3-1-0/setup/build/bin 执行验证命令：mpirun -np 8 ./xhpcg会生成以下文件：查看文件结果：  ----结束 6 RPM打包(参考)说明：本段提供了RPM包制作的详细过程，当部署环境与本文档环境不兼容时，可参考此打包过程，自制RPM包，然后再安装到部署环境。6.1 准备RPM 打包环境步骤 1   安装rpmdevtools。yum install rpmdevtools步骤 2   生成打包目录树。cd ~/rpmdev-setuptree步骤 3   进入目录~/rpmbuild，应有如下文件夹：cd ~/rpmbuild----结束 6.2 mpich打包6.2.1 编辑SPEC文件步骤 1   生成SPEC文件模板。1．切换目录至~/rpmbuild/SPECS。cd ~/rpmbuild/SPECS2．生成模板文件mpich3.2.1.spec。rpmdev-newspec mpich3.2.1.specls  步骤 2   修改SPEC文件。vi mpich3.2.1.spec修改后，mpich3.2.1.spec文件内容如下： Name:           mpichVersion:        3.2.1Release:        1%{?dist}Summary:        MPICH is a high performance and widely portable implementation of the Message Passing Interface (MPI) standard. License:        GPLURL:            http://www.mpich.org/%undefine _disable_source_fetchSource0:        http://www.mpich.org/static/downloads/3.2.1/mpich-3.2.1.tar.gz BuildRequires:  gcc gcc-gfortran %descriptionMPICH is a high performance and widely portable implementation of the Message Passing Interface (MPI) standard.MPICH and its derivatives form the most widely used implementations of MPI in the world. They are used exclusively on nine of the top 10 supercomputers (June 2016 ranking), including the world’s fastest supercomputer: Taihu Light. %prep%setup -c -n %{name}-%{version}  %buildcd mpich-3.2.1./configure --prefix=/usr/local/mpich3.2.1make -j16  %installrm -rf $RPM_BUILD_ROOTpwdcd mpich-3.2.1%make_installcp -r /root/rpmbuild/BUILD/mpich-3.2.1/mpich-3.2.1/examples /root/rpmbuild/BUILDROOT/mpich-3.2.1-1.el7.aarch64/usr/local/mpich3.2.1 %files/usr/local/*%doc ----结束 6.2.2 RPM打包步骤 1   rpmlint检查SPEC文件或RPM包。1．安装rpmlint。yum install rpmlint 2．错误检查。说明：如果返回错误/警告，使用 “-i” 选项查看更详细的信息。但由于rpmlint检测较严格，一些错误可忽略，可根据实际情况结合检测结果进行修改。rpmlint –i mpich3.2.1.spec 步骤 2   构建SRPM和RPM。rpmbuild -ba mpich3.2.1.spec 步骤 3   查看生成的RPM包。ls ~/rpmbuild/RPMS/aarch64----结束 6.3 hpcg打包6.3.1 编辑SPEC文件前置条件：打包hpcg必须先安装mpich，可参考第4章节步骤 1   生成SPEC文件模板。1．切换目录至~/rpmbuild/SPECS。cd ~/rpmbuild/SPECS2．生成模板文件hpcg3.1.0.spec。rpmdev-newspec hpcg3.1.0.specls  步骤 2   修改SPEC文件。vi hpcg3.1.0.spec修改后，hpcg3.1.0.spec文件内容如下：                         Name:           hpcg                        Version:        3.1.0                        Release:        1%{?dist}                        Summary:        The High Performance Conjugate Gradients (HPCG) Benchmark project is an effort to create a new metric for ranking HPC systems. HPCG is intended as a complement to the High Performance LINPACK (HPL) benchmark, currently used to rank the TOP500 computing systems.                                                 License:        GPL                        URL:            http://www.hpcg-benchmark.org/                        %undefine _disable_source_fetch                        Source0:        https://github.com/hpcg-benchmark/hpcg/archive/HPCG-release-3-1-0.tar.gz                                                BuildRequires:  gcc-c++                                                %description                        The High Performance Conjugate Gradients (HPCG) Benchmark project is an effort to create a new metric for ranking HPC systems. HPCG is intended as a complement to the High Performance LINPACK (HPL) benchmark, currently used to rank the TOP500 computing systems. The computational and data access patterns of HPL are still representative of some important scalable applications, but not all. HPCG is designed to exercise computational and data access patterns that more closely match a different and broad set of important applications, and to give incentive to computer system designers to invest in capabilities that will have impact on the collective performance of these applications.                                                %prep                        %setup -c -n %{name}-%{version}                                                                        %build                        cd hpcg-HPCG-release-3-1-0/setup/                        mkdir build                        cd build                        %{_builddir}/hpcg-3.1.0/hpcg-HPCG-release-3-1-0/configure Linux_MPI                        make -j16                                                mkdir -p %{_buildrootdir}/hpcg-3.1.0-1.el7.aarch64/usr/local                        cp -r %{_builddir}/hpcg-3.1.0/hpcg-HPCG-release-3-1-0/ %{_buildrootdir}/hpcg-3.1.0-1.el7.aarch64/usr/local                                                %files                        /usr/local/*                        %doc----结束 6.3.2 RPM打包步骤 1   rpmlint检查SPEC文件或RPM包。1．安装rpmlint。yum install rpmlint 2．错误检查。说明：如果返回错误/警告，使用 “-i” 选项查看更详细的信息。但由于rpmlint检测较严格，一些错误可忽略，可根据实际情况结合检测结果进行修改。rpmlint –i hpcg3.1.0.spec 步骤 2   构建SRPM和RPM。rpmbuild -ba hpcg3.1.0.spec 步骤 3   查看生成的RPM包。ls ~/rpmbuild/RPMS/aarch64步骤 4   RPM包验证。RPM包的验证，可参考”5 运行和验证“。----结束 7 FAQ7.1 RPM打包流程、示例及问题集参考：https://bbs.huaweicloud.com/forum/thread-38327-1-1.html7.2 Check-rpath deteced a broken RPATH       问题现象：解决：