【转载华为云社区】当今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       问题现象：解决：

01 什么是云原生（Cloud Native）      在目前这个互联网时代，无论是中小型企业、还是大型的互联网公司都是可以拥抱到云计算的好处，各大公有云产商的平台提供了接近零的停机时间、无限的扩展性、可控的容错及成本控制等。但我们的业务如何配合云计算达到最大化的收益呢？那么就是云原生，通过云原生构建具有弹性、轻量级、无状态的应用以适应目前互联网发展所需的大流量及大负载服务处理的能力。02 云原生可以解决什么痛点应用需支持快速上线 应用需支持快速扩容 应用需实现故障监控探测 应用需实现故障自我隔离应用需实现故障自我恢复... 03 如何达到云原生      云原生并不是一种具体的技术，具体来说应该是一种思想的集合，包括敏捷、DevOps、CI/CD、微服务、服务治理、容器技术、云计算等，整合并重组以致于推动公司商业业务的发展。也可以说云原生是对技术、管理的一种整合。DevOpsDevOps（Development与Operations的单词组合）DevOps并不是一种技术，而是应用交付的文化，是促进开发、运维、测试3个部门间的沟通协作的整合，目标就是为了快速、稳定的交付应用。传统的开发方式会设计到多个部门，开发人员在对配置修改之后没有通知到运维人员，运维人员缺少对应用的运行环境及应用内部实现的了解，开发周期长等问题，会造成应用在发布时运维人员难以选择正确的运行环境或者配置、开发人员无法感知到应用运行潜在的问题，往往这些问题需要花费大量的时间进行解决。而为了解决这些传统开发方式的问题，就有必要引入DevOps文化。CI/CD持续集成（Continuous Integration）持续集成是指开发人员会持续的将代码更改提交到代码仓库中，更改会触发编译、测试等作业验证此次提交的代码是否满足预期要求，已确保新提交代码可以对原有代码进行集成，已防止新提交的代码造成部署后应用出现问题。持续交付（Continuous Delivery）持续交付是指持续集成的进一步扩展，已经正常通过测试及验证代码的稳定性，下一步就是将代码部署在预发环境中，可以使用自动化的方式重复的进行频繁的交付，这可以避免因为人工配置错误等原因造成问题。持续部署（Continuous Deployment）持续部署是指在持续交付的基础上，证实应用在预发环境中通过测试，将应用自动化的部署到生产环境的过程。有些应用场景也突出持续交付旨在交付构建的产物，而持续部署是负责在构建仓库中将构建产物部署到运行环境中。敏捷（Agile）敏捷是一种软件交付迭代方法，从项目开始就逐步构建应用，而不是试图在即将结束时立即交付所有应用。是将项目分解成一些称为用户故事的用户功能 ，对它们进行优先级排序，然后在较短周期中连续性的交付。微服务（Micro Services）微服务是一种架构模式，将单一大应用拆分成多个独立的轻量级服务，每个服务围绕具体的业务进行构建，服务可支持水平扩展，功能单一且独立。服务之间相互协调、互相配合并可以支持独立部署。服务治理（Service Governance）服务治理是为了实现对服务的生命周期管理与定义策略及规范，主要有服务注册、服务发现、负载均衡、服务限流、服务降级、服务熔断、服务重试、链路追踪、服务配置、API网关等等。主流有Dubbo、Spring Cloud等框架，但这些框架是针对于特定语言，如果有其他语言想要实现同等的服务治理能力，那么需要重复的造轮子去实现。服务网格应求而出，解决了开发语言之间的壁垒，解耦了服务访问者和服务提供者的拓扑，并把服务治理能力下降成通用的能力提供给不同的服务，大大的降低了服务复杂度及减少了开发人员压力。容器技术（Container Technology）容器是基于操作系统隔离的进程，这些进程间是受到资源限制并相互隔离，容器是没有自己的操作系统的，直接共享宿主机的内核，这比传统的操作系统虚拟化更加轻量级。目前容器解决方案主流是Docker，而容器管理解决方案是Kubernetes，为容器化的应用提供部署运行、资源调度、服务发现、动态伸缩、故障自愈等一些功能。云计算（Cloud Computing）云计算是提供按需弹性的计算、存储、网络资源的服务模式，这种模式可以快速提供安全可靠的IT基础设施，例如数据库、消息队列等服务，用户不需要关心太过于底层实现的事情，只需要用很简单的方法就可以接入使用。康威定律（Conway's Law）一个应用最终是什么样子大概率是由企业组织结构决定的，是组织内部、组织之间的沟通结构。要得了一个合理设计的应用或者系统架构，单单从技术方面考量是不够的，还需要从组织架构入手才真正有效。04 云原生总结再回顾下什么是云原生？我认为是软件的未来。而这个未来已经来到。      应用的架构从单机 -> 垂直扩展 -> 水平扩展 -> SOA -> 微服务一直在变革。类似互联网应用总是需要满足快速迭代、高可用性、高性能等，那么首先我们需要将应用设计成无状态并运行于容器平台之上，需要高服务能力时水平伸缩容器组的数量即可，通过容器特性实现高可用等，通过CI/CD打通实现自动化发布流程，服务网格打通语言间的壁垒及重复造轮子的问题，降低开发团队的压力。云原生应用需要与基础架构解耦，可以随意在任何一家公有云或者私有云上运行，并支持水平或垂直的扩展性要求。通过打通技术与管理上的壁垒，将二者更好的结合在一起创造出云原生应用。简单而又重复的事情，应该交由系统自动化去完成，把重点放在创造更多的业务价值上。关于作者叶康铭南开大学计算机系毕业、云计算及云原生的布道者、阿里云认证云栖专家、华为云认证云享专家、深圳HDZ社区核心组织者。熟悉国内外各大云产商，在大规模的服务应用、安全防护、计算平台、架构设计有多年的实践经验及管理方法，致力于让更多人和企业更好认识及应用云计算及云原生。为何书写作为一个布道者，有一个平台提供知识传播能力，帮助更多的人学习并应用云计算、云原生。作为一个技术人，记录下自己走过的技术道路，作为技术的沉淀积累，人生也需要定期的复盘，不断去思考优化调整。未来期待每周会定期输出云原生技术文章、从入门开始逐步剖析深入到企业级的项目中，也分享一些在架构设计领域的技术文章及想法。如果有技术上的问题，也欢迎一起探讨及分享。联系作者添加好友时麻烦请备注来源、公司及名称，谢谢HDZ社区—携手全球开发者 共建开放、创新、多元的开发者社区组织       HDZ是Huawei Developers Zone的英文缩写，是华为开发者生态面向全球开发者建立开放、创新、多元的开发者社区组织。      致力于帮助开发者学习提升、互动交流、挖掘机会，推动ICT、互联网等产业生态的建立和发展。      对云计算、IoT、人工智能、5G、区块链、鲲鹏、昇腾、软件开发与运维、开源等各技术领域感兴趣的开发者、软件工程师、创业者、运营人、产品人、大学生、老师等都可以参与到HDZ。      HDZ秉承开放、创新、多元的社区文化，完全由各地HDZ组织者、志愿者自发组建和领导。华为公司不直接参与HDZ组织建设和领导，只按需对HDZ社区活动提供必要的方向指导、资源支持、活动支撑等，并为各地HDZ组织者提供与全国组织者互动交流的机会。扫描上方二维码即可报名申请成为各城市核心者、志愿者

这篇文章在多家媒体网站都有刊载，不过好像内容略有不同，有些文章删除了少量文字。还有些莫名其妙的网站上也有，估计是属于机器人爬新闻，给自己累积访问流量的。中国日报网：http://ex.chi***ily.com.cn/exchange/partners/82/rss/channel/cn/columns/snl9a7/stories/WS5e0ae0bda31099ab995f4935.html凤凰网：http://biz.ifeng.com/c/7slnXHOWBiX天极网：http://news.yesky.com/hotnews/131/1983483631.shtml砍柴网：http://news.ikanchai.com/2019/1230/329499.shtml东方资讯：http://mini.eastday.com/a/191229023826526.html内容如下：2019运维大会在北京国宾酒店盛大开幕，此会由云计算标准和开源推进委员会主办(TC608)，指导单位为中国信息通信研究院、中国标准化协会。2019运维大会面向互联网、金融及传统行业、广大运维技术人员，传播先进技术思想和理念，风向业内最佳实践。来自业界各方的知名机构、企业代表等，深入研讨 IT 运维发展趋势，分享先进运维技术和优秀实践成果。华为云DevCloud专家出席本次会议并发表了精彩演讲。专家分享到，2019年华为云在国内市场已经进入前四，并位居了领导者象限。在这样的背景下运维也具有很大的挑战。运维服务器规模快速增长，但运维人员不增长的情况下如何保证运维效率？一方面实现了运维活动各流程的自动化，一方面通过构建AIOps能力，减少MTTD和MTTR，提升云服务的可用性。实现一分钟发现，五分钟定位及十分钟恢复。依托华为公有云机器学习服务打造公有云SRE AIOps平台，支撑了各运维场景AI算法快速落地。通过自研的算法实现对底层硬件故障预测，使得用户对硬件故障无感知。在故障发现方面，通过对核心KPI的异常检测，实现先于客户发现问题，规避故障对客户的影响。通过调用链及故障定位算法，实现故障快速定位，实现快速止损能力。通过智能客服，提升客服服务质量，提升服务效率。在这次大会上，华为云DevCloud还荣获“2019 运维行业卓越贡献技术专家”和“2019 运维行业年度优秀案例”两大奖项。华为云DevCloud致力于结合华为30年研发实践、前沿研发理念、先进研发工具，推动敏捷、DevOps等研发效能优秀方法与实践在国内蓬勃发展，担任云原生产业联盟DevOps工作组副组长，积极推动和亲自参与行业DevOps标准的编写与推广工作。在2019年还联合中国信息通信研究院、南京大学联合发起了2019年中国DevOps现状调查活动并发布最终报告，为从业人士了解行业发展现状和实践水平提供了可靠的数据支撑。为了更好地支持企业提升软件交付能力，华为云DevCloud今年还推出了敏捷与DevOps专家服务，从人与组织、工程方法、工具平台、最佳实践等方面以咨询、实施、培训与认证等方式使能企业云化与数字化转型。2019年10月底IDC发布了《IDC MarketScape:中国DevOps云服务市场2019厂商评估》报告中，华为云DevCloud位居Leaders象限，在国内厂商中能力和市场份额两大维度均排名第一，全面领跑DevOps云服务市场。徐毅作为华为云DevCloud首席技术布道师，在DevOps领域长期耕耘，荣获“2019 运维行业卓越贡献技术专家”。他作为云原生产业联盟DevOps工作组副组长，不仅对华为公司构建面向云计算的先进运维体系作出突出贡献，而且作为DevCloud技术布道师积极推动DevOps理念在国内传播与实践落地，打造DevCloud专家服务提升企业研发效能，助力企业云化、数字化转型。未来希望能够为行业继续做出更多的贡献，持续推动DevOps优秀实践在国内的发展和落地。“分层分级持续交付流水线”根据研发流程/研发环境定义分级自动化流水线。分级流水线+匹配流水线的代码分支模式，解决了多团队产品协作问题：对于大的开发团队（30人以上），会产生代码提交、产品发布过程中的诸多冲突，没有流程与规则的限制，将会难以执行（如一整天都没有一条能跑通的流水线）。该方案的好处，是把流程固化到可视化的持续交付流水线上，团队可以在遵循大的流程原则基础上，不断地通过改进流水线来改进研发与发布的效率；质量活动放到流水线，分层管控，做到真正的质量内建：分层自定义质量规则，确保不合格的制品无法进入下一个环节，让流水线的自动门禁代替人工管理；高频快速的反馈，提升研发与发布效率：个人级的流水线不会影响到服务级、产品级流水线，可以通过高频的流水线执行，快速获取反馈，大大提升研发和发布效率。在中国软件产业及数字经济迅猛发展下，软件交付工程方法与技术的持续发展为中国DevOps云市场带来了机遇与挑战。华为云DevCloud致力DevOps效能提升，将进一步在华为可信软件变革下，持续增强智能研发、可信软件交付、生态体系等方面投入，为客户的软件交付提供更强的DevOps平台。