华为云应用服务课程综合帖上线啦~这里有技术大咖精彩解读前沿技术；有一线攻城狮现身知识分享~内容持续更新，学习充电好轻松~还有产品实践Demo大集合，等你来玩！《此处传送门》序号课程名称课程介绍课程链接课程提取码121天转型区块链实战营本课程主要内容包括：区块链基础和Hyperledger   、华为云区块链服务、华为云区块链BCS实战。https://education.huaweicloud.com:8443/courses/course-v1:HuaweiX+CBUCNXV006+Self-paced/about/221天转型容器实战营本课程主要内容包括：手把手教你使用Docker容器、容器集群管理、Istio服务与架构、企业应用的容器化实践等前沿实用技术。https://education.huaweicloud.com:8443/courses/course-v1:HuaweiX+CBUCNXI010+Self-paced/about/321天转型微服务实战营本课程主要内容包括：微服务基础知识，华为云微服务引擎CSE框架、开发、治理等多种应用能力，微服务应用实战。https://education.huaweicloud.com:8443/courses/course-v1:HuaweiX+CBUCNXP012+Self-paced/about/4 云上应用立体运维7天实战营本课程主要内容包括：云化场景下如何运维、华为云应用立体运维服务、华为云应用运维实战。通过本课程，您可以了解云化场景下运维工作的变化与挑战，学习云上运维技术，掌握华为云应用立体运维服务的能力与使用，提升云上运维效率。https://education.huaweicloud.com:8443/courses/course-v1:HuaweiX+CBUCNXP010+Self-paced/about/5微服务上云实践本课程为微服务上云开发的指导课程，涵盖微服务架构解析、服务中心、路由网关、服务生产与消费、缓存服务、消息系统等多个技术点的深度解析。配备真实云端开发环境的实践作业，帮助开发者快速掌握微服务上云开发能力。https://education.huaweicloud.com:8443/courses/course-v1:HuaweiX+CBUCNXV007+Self-paced/about/6CKA   1~8期视频课  本系列课程参考CKA   (Certificted Kubernetes   Administrator)知识体系进行课程设计，并结合华为在kubernetes项目推广过程中的实践经验，理论+实践让用户快速掌握kubernetes的使用和维护技能。https://pan.baidu.com/s/1ht5bgjnrhR3dPaDzwyWNsg提取码: a9yd7Istio   1~6期课程 本课程主要内容包括：Istio架构与技术原理、技术实现及基本应用等介绍  https://pan.baidu.com/s/17n30-2b8oLOF5Rivdlfkrw提取码: adea8区块链服务BCS：快速构建区块链应用  本课程主要内容包括：云化场景下如何运维、华为云应用立体运维服务、华为云应用运维实战。通过本课程，您可以了解云化场景下运维工作的变化与挑战，学习云上运维技术，掌握华为云应用立体运维服务的能力与使用，提升云上运维效率。https://education.huaweicloud.com:8443/courses/course-v1:HuaweiX+CBUCNXP008+Self-paced/about/9K8S   1~8期视频课本系列直播将带你走进云原生技术的核心，深入浅出的为您讲解云原生技术的方方面面：容器化、微服务、动态管理。https://bbs.huaweicloud.com/forum/thread-9573-1-1.html/10实践训练营-基于区块链实现银行账户跨行开户本实践是基于区块链身份共享的银行II类账户跨行开户的示例,   来介绍区块链服务开发流程。    其中将以场景化的案例, 重点讲解如何进行链代码开发https://devcloud.huaweicloud.com/classroom/joinhomework/e52406dd92b44b7b94dd24070b7fb4a5/b3dcf07d94784bfcb9af09eed433dac0/11实践训练营-基于微服务搭建天气预报应用本实践通过一个示例向您展示华为云微服务引擎的治理能力,   包括注册发现、服务降级、路由策略以及灰度发布。https://devcloud.huaweicloud.com/classroom/joinhomework/e52406dd92b44b7b94dd24070b7fb4a5/0ac06bbfde504f9db0ccb5d2a2215e87/12实践训练营-Magento电商网站编排部署本实践使用华为云应用编排服务(Application   Orchestration Service,简称AOS), 快速部署一个Magento电子商务网站容器应用。https://devcloud.huaweicloud.com/classroom/joinhomework/e52406dd92b44b7b94dd24070b7fb4a5/6cb06a3734b843d9812e91dd5f2d422c/13实践训练营-基于微服务实现自动化运维本实践以电商类网站-Shoppingmall为场景案例,   使用华为云DevCloud 和AOM/APM 服务, 提供 应用快速部署上线 、 自动运维 和 运营保障 等能力。通过应用拓扑和调用链分析,   快速发现和诊断系统访问慢、数据库链接异常等业务问题。https://devcloud.huaweicloud.com/classroom/joinhomework/e52406dd92b44b7b94dd24070b7fb4a5/8cb2619cf2a44775b44dcc0fef555ea8/14FunctionGraph实现图片压缩和水印添加本课程帮助用户了解图片压缩和水印添加实现方式，掌握FunctionGraph云服务的基本知识https://edu.huaweicloud.com/certifications/13f2f4c983ec4400b06455c056cd6576/15一节课入门：CCI快速创建容器负载本课程主要内容包括华为云容器实例CCI介绍和基本使用操作。https://education.huaweicloud.com:8443/courses/course-v1:HuaweiX+CBUCNXI011+Self-paced/about?isAuth=0&cfrom=hwc/16 一节课入门：由浅入深探索微服务云应用平台课程包括ServiceStage及产品的介绍，使用ServiceStage进行容器部署和开发微服务的操作，以及如何基于微服务、容器技术构建航空订票系统https://education.huaweicloud.com:8443/courses/course-v1:HuaweiX+CBUCNXP002+2018.5/about?isAuth=0&cfrom=hwc/17一节课入门：CPTS快速定位优化性能问题内容包括云性能测试服务CPTS概述、基本操作、快速入门，并提供一站式电商性能测试解决方案的实践指导。https://education.huaweicloud.com:8443/courses%2fcourse-v1%3aHuaweiX+CBUCNXP007%2bSelf-paced%2fabout/18一节课入门：BCS快速构建区块链应用  本课程主要内容包括：云化场景下如何运维、华为云应用立体运维服务、华为云应用运维实战。通过本课程，您可以了解云化场景下运维工作的变化与挑战，学习云上运维技术，掌握华为云应用立体运维服务的能力与使用，提升云上运维效率。https://education.huaweicloud.com:8443/courses/course-v1:HuaweiX+CBUCNXP008+Self-paced/about/19一节课入门：云中间件基础与入门讲述了华为云的3类云中间件的使用场景和基本操作，并提供B2C商旅中间件服务集成的实践指导https://education.huaweicloud.com:8443/courses/course-v1:HuaweiX+CBUCNXP003+2018.5/about?isAuth=0&cfrom=hwc/20一节课入门：CSE敏捷开发微服务应用本课程讲述了CSE的基本概念和基本操作，并提供了企业应用云化DevOps微服务开发、上线、治理的理论和实践知识。https://education.huaweicloud.com:8443/courses/course-v1:HuaweiX+CBUCNXP004+2018.5/about?isAuth=0&cfrom=hwc/21一节课入门：APM速解分布式架构问题本课程包括：应用性能管理APM概述、快速入门、基本操作和企业应用云化DevOps微服务运维。https://education.huaweicloud.com:8443/courses/course-v1:HuaweiX+CBUCNXP006+2018.5/about?isAuth=0&cfrom=hwc/22一节课入门：AOS助力应用上云自动化本课程包括：介绍应用编排服务AOS的基本概念；通过一个示例向您演示如何手动编写AOS模板，熟悉AOS模板的语法规则；使用AOS设计器编写模板，熟悉AOS设计器的使用。https://education.huaweicloud.com:8443/courses/course-v1:HuaweiX+CBUCNUP006+2018.6/about?isAuth=0&cfrom=hwc/23 一节课入门：API网关助力API经济本课程主要内容包括API网关基本介绍、操作实战及常见问题。https://education.huaweicloud.com:8443/courses/course-v1:HuaweiX+CBUCNXP009+Self-paced/about?isAuth=0&cfrom=hwc/内容持续更新中！精彩不要错过呦~

第一步：点击https://console.huaweicloud.com/cce2.0/?region=cn-north-1#/app/guidance/list，在领取免费集群弹窗中，勾选“我已阅读并同意上述条款”，点击“立即领取”，即可获得3天免费集群，并进入云容器引擎管理控制台。  第二步：在云容器引擎管理控制台，点击“工作负载”-“无状态”- “创建无状态工作负载”如图所示。 第三步：如图所示，配置基本信息，实例数量1个，然后点击“下一步”。第四步：点击“添加容器”，如图所示。第五步：点选“第三方镜像”，镜像名称处 输入下面的镜像地址：swr.cn-north-1.myhuaweicloud.com/hc_cce/flappybird:latest第六步：如图所示，基本信息保持默认值不变，点击“下一步”。 第七步：点击“添加服务”，然后如图所示，填写服务名称，选择公网访问，弹性IP，注意容器端口处填 80 。配置完毕后 点击“确定”-“下一步”。 第八步：点击“创建”，即可完成无状态工作负载创建环节。可查看负载详情、返回负载列表。第九步：在工作负载列表中，点击“外部访问地址”，即可开始享受这一虐心小游戏啦~更多实践指引帖传送门：https://bbs.huaweicloud.com/forum/thread-15463-1-1.html

1. 性能优化面对的挑战以下是整个PaaS平台的架构其中主要包括这些子系统：微服务治理框架：为应用提供自动注册、发现、治理、隔离、调用分析等一系列分布式/微服务治理能力，屏蔽分布式系统的复杂度。应用调度与资源管理框架：打通从应用建模、编排部署到资源调度、弹性伸缩、监控自愈的生命周期管理自动化。应用开发流水线框架：打通从编写代码提交到自动编译打包、持续集成、自动部署上线的一系列CI/CD全流程自动化。云中间件服务：应用云化所需的数据库、大数据、通信和应用中间件服务；通过服务集成管控可集成传统非云化的中间件能力。面对一个如此复杂的系统，性能优化工作是一个非常艰巨的挑战，这里有这么一些痛点：源代码及开发组件多，100+ git repo，整体构建超过1天运行架构复杂，全套安装完需要30+VM，200+进程软件栈深，网络平面复杂集群规模大，5k — 10k节点环境搭建非常困难系统操作会经过分布式的多个组件，无法通过单一组件诊断发现系统瓶颈无法追踪上千个处于不同层次的API的时延和吞吐大部分开发人员专注于功能开发，无法意识到自己的代码可能造成性能问题2. 优化分析那么，对于这么一个大的、复杂的系统，从方法论的角度来讲，应该怎么去优化呢？基本思路就是做拆分，把一个大的问题分解为多个互相不耦合的维度，进行各个击破。从大的维度来讲，一个PaaS容器集群，可以分为3个大的子系统。控制子系统：控制指令的下发和运行(k8s)，例如创建pod业务流量子系统：容器网络(flannel)、负载均衡(ELB/kube-proxy)监控子系统：监控告警数据的采集(kafka, Hadoop)这个看起来仅仅是一个架构上的划分，那么如何和具体的业务场景对应起来呢？我们可以考虑如下一个场景，在PaaS平台上大批量的部署应用。看看在部署应用的过程中，会对各个子系统产生什么压力。应用软件包大小：400M应用模板大小：10M1000个节点，每个节点一个POD，一个实例10种类型的软件包，依赖长度为3，10GB 网络调度及资源管理 3VM这是一个典型的部署应用的一些规格，那么对于这样的一个输入，我们可以按照架构把压力分解到每个子系统上，这样得出的子系统需要支撑的指标是：控制子系统： kubernetes调度速度 > 50 pods/s，仓库支持300并发下载，>40M/s数据子系统：overlay容器网络TCP收发性能损耗 <5%监控子系统：在上面这个场景中不涉及，但可以从别的场景大致告警处理能力100条/秒这里的业务场景：架构分析：子系统指标，这三者是m:1:n的，也就是说在不同场景下对不同的组件的性能要求不同，最后每个组件需要取自己指标的最大值。指标决定了后续怎么进行实验测试，而测试是要花较大时间成本的，所以在指标的选取上要求少求精，尽量力图用2-3个指标衡量子系统。3. 优化测试 & 工具上面讲的还是偏纸上的推演和分析，接下来进入实战阶段对于服务器后端的程序来讲，推荐使用Promtheus这个工具来做指标的定义和采集。Promtheus的基本工作原理是：后端程序引入Promtheus的SDK，自定义所有需要的测量的指标，然后开启一个http的页面，定期刷新数据。Promtheus服务器会定期抓取这个页面上的数据，并存在内部的时间序列数据库内。这种抓而非推的方式减少了对被测试程序的压力，避免了被测程序要频繁往外发送大量数据，导致自身性能反而变差而导致测量不准确。Promtheus支持这几种数据类型：计数(对应收集器初始化方法NewCounter、NewCounterFunc、NewCounterVec，单一数值，数值一直递增，适合请求数量统计等)测量(对应收集器初始化方法NewGauge、NewGaugeFunc、NewGaugeVec，单一数值，数值增减变动，适合CPU、Mem等的统计)直方图测量(对应收集器初始化方法NewHistogram、NewHistogramVec，比较适合时长等的统计)概要测量(对应收集器初始化方法NewSummary、NewSummaryVec，比较适合请求时延等的统计)我们可以看看在kubernetes项目里面是怎么用的：var ( // TODO(a-robinson): Add unit tests for the handling of these metrics once // the upstream library supports it. requestCounter = prometheus.NewCounterVec( prometheus.CounterOpts{ Name: "apiserver_request_count", Help: "Counter of apiserver requests broken out for each verb, API resource, client, and HTTP response contentType and code.", }, []string{"verb", "resource", "client", "contentType", "code"}, ) requestLatencies = prometheus.NewHistogramVec( prometheus.HistogramOpts{ Name: "apiserver_request_latencies", Help: "Response latency distribution in microseconds for each verb, resource and client.", // Use buckets ranging from 125 ms to 8 seconds. Buckets: prometheus.ExponentialBuckets(125000, 2.0, 7), }, []string{"verb", "resource"}, ) requestLatenciesSummary = prometheus.NewSummaryVec( prometheus.SummaryOpts{ Name: "apiserver_request_latencies_summary", Help: "Response latency summary in microseconds for each verb and resource.",// Make the sliding window of 1h. MaxAge: time.Hour, }, []string{"verb", "resource"}, ) )在这里，一个http请求被分为verb, resource, client, contentType, code这五个维度，那么后面在PromDash上就能图形化的画出这些请求的数量。 从而分析哪种类型的请求是最多，对系统造成最大压力的，如图除了Promtheus，还可以引入其他的测量手段，对系统进行分析。在kubernetes调度过程中，各个状态Pod的数量，看哪一步是最卡的go pprof分析，哪些函数是最耗CPU的4. 优化开发发现了瓶颈之后，下一步就是解决瓶颈，和具体业务逻辑有关，本文在这里就不做过多的阐释。需要对相关代码非常熟悉，在不改变功能的情况下增强性能，基本思路为并发/缓存/去除无用步骤等。5. 优化成果这是我们在kubernetes项目上控制面优化的成果控制面指标华为分支数据社区版数据Master节点数量5无明确数据Node节点(kubemark模拟)数量10000节点5000节点部署吞吐率>100 pod/s约为50 pod/sPod端到端延时<2s<5sAPI延时<79.321ms<1s这里仅仅显示了控制子系统的指标，其他子系统还没有支持那么大的集群，尤其在网络方面，不同用户的网络架构差别很大。所以数据仅供参考。6. 优化的优化在上面的优化过程当中，基本上工程师要做几百次优化的测试和开发。这里会产生一个循环：测试寻找瓶颈点修改代码突破这个瓶颈点重新测试验证这段代码是否有效，是否需要改优化思路这就是一个完整的优化的迭代过程，在这个过程当中，大部分时间被浪费在构建代码、搭建环境、输出报告上。开发人员真正思考和写代码的时间比较短。为了解决这个问题，就需要做很多自动化的工作。在kubernetes优化的过程中，有这么几项方法可以节省时间：kubemark模拟器 ：社区项目，使用容器模拟虚拟机，在测试中模拟比达到1：20，也就是一台虚拟机可以模拟20台虚拟机对apiserver产生的压力。在测试过程当中，我们使用了500台虚拟机，模拟了10000节点的控制面行为。CI集成：提交PR后自动拉性能优化分支并开始快速构建CD集成：使用I层的快照机制，快速搭建集群并执行测试案例输出测试报告以上都是在实践过程中总结的一些点，对于不同的项目工程应该有很多点可以做进一步的优化，提升迭代效率。在搭建完这套系统后，我们发现这个系统可以从源头上预防降低系统性能的代码合入主线。如果一项特性代码造成了性能下降，在CI的过程当中，功能开发者就能收到性能报告，这样开发者就能自助式的去查找自己代码的性能问题所在，减少性能工程师的介入。

什么是“容器”和“虚拟机”容器和虚拟机它们的目的很相似：即将应用程序和它的依赖放到一个可以在任何环境运行的自足单元中。此外，容器和虚拟机消除了对物理硬件的需求，从而在能源消耗和成本效益方面能让我们更有效地使用计算资源，容器和虚拟机的主要区别在于它们的架构方式。让我们继续深入了解。虚拟机虚拟机在本质上是对现实中计算机的仿真，它会像真实的计算机一样执行程序。使用 “hypervisor” 可以将虚拟机运行于物理机上。hypervisor 可以在主机运行，也可以在“裸机”上运行。让我们来揭开这些术语的面纱：hypervisor（之后都以虚拟机管理程序称呼）是能让虚拟机在其上运行的软件，固件或者硬件。虚拟机管理程序本身会在物理计算机上运行，称为**“主机”**。主机为虚拟机提供资源，包括 RAM 和 CPU。这些资源在虚拟机之间被划分并且可以根据需要进行分配。所以如果一个虚拟机上运行了资源占用更大的应用程序，相较于其它运行在同一个主机的虚拟机你可以给其分配更多的资源。运行在主机上的虚拟机（再次说明，通过使用虚拟机管理程序）通常也被叫做“访客机”。访客机包含了应用以及运行这个应用所需要的全部依赖（比如：系统二进制文件和库）。它还带有一个自己的完整虚拟化硬件栈，包括虚拟化的网络适配器，储存和 CPU-这意味着它还拥有自己成熟的整个访客操作系统。从虚拟机内部来看，访客机的操作都认为其使用的都是自己的专用资源。从外部来看，我们知道它是一个虚拟机-和其它虚拟机一起共享主机提供的资源。就像前面所提到的，访客机既可以运行在托管的虚拟机管理程序上，也可以运行在裸机虚拟机管理程序上。它们之间存在一些重要的差别。首先，托管的虚拟化管理程序是在主机的操作系统上运行。比如说，可以在一台运行 OSX 操作系统的计算机的系统上安装虚拟机（例如：VirtualBox 或者 VMware Workstation 8）。虚拟机无法直接访问硬件，因此必须通过主机上运行的操作系统访问（在我们的例子中，也就是 Mac 的 OSX 操作系统）。托管虚拟机管理程序的好处是底层硬件并不那么重要。主机的操作系统会负责硬件的驱动而不需要管理程序参与。因此这种方式被认为具备更好的“硬件兼容性”。在另一方面，在硬件和管理程序之间这个额外的附加层会产生更多的资源开销，这会降低虚拟机的性能。裸机虚拟机管理程序通过直接在主机硬件上安装和运行来解决这个性能问题。因为它直接面对底层的硬件，所以并不需要运行在主机的操作系统之上。在这种情况下，安装在主机上第一个作为操作系统运行的就是这个裸机虚拟机管理程序。与托管虚拟机管理程序不同，它有自己的设备驱动直接与每个组件交互，以执行任何 I/O，处理或特定于操作系统的任务。这样可以获得更好的性能，可伸缩性和稳定性。这里的权衡在于其对硬件的兼容性有限，因为裸机虚拟机管理程序内置的设备驱动只有那么多。在讨论了虚拟机管理程序之后，你可能想知道为什么我们需要在虚拟机和主机之间这个额外的“虚拟机管理程序”层。好吧，虚拟机管理程序在其中确实发挥了重要的作用，由于虚拟机拥有自己的虚拟操作系统，管理程序为虚拟机管理和执行访客操作系统提供了一个平台。它允许主机与作为客户端运行的虚拟机之间共享其资源。虚拟机图示正如你可以在图示中所看到的，VMS 会为每个新的虚拟机打包虚拟硬件，一个内核（即操作系统）和用户空间。容器与提供硬件虚拟化的虚拟机不同，容器通过抽象“用户空间”来提供操作系统级别的虚拟化。当我们详解容器这个术语的时候你就会明白我的意思。从所有的意图和目的来看，容器看起来就像一个虚拟机。比如说，它们有执行进程的私有空间，可以使用 root 权限执行命令，具有专有的网络接口和 IP 地址，允许自定义路由和 iptable 规则，可以挂载文件系统等。容器和虚拟机之间的一个重要区别在于容器和其它容器共享主机系统的内核。容器图示这图表明容器只会打包用户空间，而不是像虚拟机那样打包内核或虚拟硬件。每个容器都有自己独立的用户空间从而可以让多个容器在单个主机上运行。我们可以看到所有操作系统级别的体系架构是所有容器共享的。要从头开始创建的部分只有 bins 和 libs 目录。这就是容器如此轻巧的原因。Docker 是从哪来的？Docker 是基于 Linux 容器技术的开源项目。它使用 Luinux 的内核功能（如命名空间和控制组）在操作系统上创建容器。容器已经远远不是一个新技术：Google 已经使用他们自己的容器技术好多年了。其它的容器技术包括 Solaris Zones、BSD jails 和 LXC 也已经存在好多年。那么为啥 Docker 会突然取得成功呢？使用简单：Docker 使得任何人（开发人员，运维，架构师和其他人）都可以更轻松的利用容器的优势来快速构建和测试可移植的应用程序。它可以让任何人在他们的笔记本电脑上打包应用程序，不需要任何修改就可以让应用运行在公有云，私有云甚至裸机上。Docker 的口头禅是：“一次构建，处处运行”。速度：Docker 容器非常轻量级和快速。因为容器只是运行在内核上的沙盒环境，因此它们占用的资源更少。与可能需要更多时间来创建的虚拟机相比，你可以在几秒钟内创建一个 Docker 容器，因为虚拟机每次都必须启动一个完整的操作系统。Docker Hub：Docker 用户也可以从日益丰富的 Docker Hub 生态中受益，你可以把 Docker Hub 看作是 “Docker 镜像的应用商店”。Docker Hub 拥有数万个由社区构建的公共镜像，这些镜像都是随时可用的。在其中搜索符合你需求的镜像非常容易，你只需要准备拉取镜像而且几乎不需要任何修改。模块化和可扩展性：Docker 可以让你轻松地把应用程序按功能拆分为单个独立的容器。比如说，你的 Postgre 数据库可以运行在一个容器中，Redis 服务运行在另一个容器中，而 Node.js 应用运行在另一个容器中。使用 Docker，将这个容器链接在一起以创建你的应用程序将会变得更简单，同时在将来可以很轻松地扩展和更新单独的组件。最后但并不重要的是，有谁不喜欢 Docker 的鲸鱼（Docker 的标志）呢？：）

KubeEdge v0.2发布KubeEdge在18年11月24日的上海KubeCon上宣布开源的一个开源项目，旨在依托K8S的容器编排和调度能力，实现云边协同、计算下沉、海量设备的平滑接入。KubeEdge脱胎于华为云IEF服务，是第一个具备在生产环境部署能力的边缘计算领域开源项目。前几天K8S IOT/Edge工作组发布了关于边缘计算的白皮书，并将KubeEdge作为K8S在IOT/Edge场景下的参考架构。KubeEdge架构上包含两部分，分别是云端和边缘侧。云端负责应用和配置的下发，边缘侧则负责运行边缘应用和管理接入设备。在v0.2版本中，KubeEdge团队决定开放云端代码，这样KubeEdge v0.1和v0.2的发布分别创造了两个记录：全球首个开源的支持容器部署的边缘计算平台；全球首个开放云边协同能力的边缘计算平台；KubeEdge v0.2 的发布意味着任何人都可以在自己的环境中部署一个完整的涵盖云、边、设备的边缘计算解决方案。另外本次更新还在 v0.1 的基础上新增了云上两个重要组件，分别是：CloudHub和EdgeController，架构如下所示：其中：Cloudhub负责接收EdgeHub同步到云端的信息；EdgeController用于控制K8S API Server与边缘的节点、应用和配置的状态同步；用户可以直接通过kubectl命令行在云端管理边缘节点、设备和应用，使用习惯与K8S原生的完全一致，无需重新适应。Rancher发布轻量级Kubernetes发行版 K3s近期，容器管理软件提供商 Rancher Labs宣布推出轻量级的 Kubernetes 发行版 K3s，这款产品专为在资源有限的环境中运行 Kubernetes 的研发和运维人员设计。根据Rancher描述，为了减少运行Kubernetes所需内存，k3s主要专注于以下三个方向的变化：删除旧的、非必须的代码整合正在运行的打包进程使用 containerd 代替 Docker 作为运行时的容器引擎除了 etcd 之外，引入 SQLite 作为可选的数据存储k3s官方描述的主要使用场景为：边缘计算与应用程序绑定使用嵌入式设备整体来看，k3s相当于kubernetes针对边缘计算等特殊场景的裁剪和优化，而并非专门专门边缘计算场景的解决方案，未来可能还需要长足的演进和适配过程。阿里宣布开源 Flutter 应用框架 Fish Redux3 月 5 日，闲鱼宣布在 GitHub 上开源 Fish Redux，Fish Redux 是一个基于 Redux 数据管理的组装式 flutter 应用框架， 特别适用于构建中大型的复杂应用，它最显著的特征是 函数式的编程模型、可预测的状态管理、可插拔的组件体系、最佳的性能表现。Redux 是来自前端社区的一个用来做 可预测易调试 的数据管理的框架，所有对数据的增删改查等操作都由 Redux 来集中负责。Redux 核心仅仅关心数据管理，不关心具体什么场景来使用它，这是它的优点同时也是它的缺点。在实际使用 Redux 中可能面临两个具体问题：Redux 的集中和 Component 的分治之间的矛盾；Redux 的 Reducer 需要一层层手动组装，带来的繁琐性和易错性；Fish Redux 通过 Redux 做集中化的可观察的数据管理，并且针对传统 Redux 在使用层面上的缺点，在面向端侧 flutter 页面纬度开发的场景中，通过更好更高的抽象，做了改良。开源之后，闲鱼打算通过以下方式来维护 Fish Redux：通过后续的一系列的对外宣传，吸引更多的开发者加入或者使用。配合后续的一系列的闲鱼 Flutter 移动中间件矩阵做开源；进一步提供，一系列的配套的开发辅助调试工具，提升上层 Flutter 开发效率和体验；又现云平台宕机企业应如何尽量避免损失北京时间2019年3月2日23:55分左右开始，监控发现华北2地域部分ECS实例及部分EMR、RDS on ECS、DTS、DBS实例及服务状态异常，事后于3月3日阿里云工程师紧急排查处理，并且逐步恢复异常实例。细数这两年，国际主流云厂商在安全性和可靠性层面做了不少努力，但所有服务都不可能百分百稳定，尽管云平台会发生故障，但企业对云的信赖度依然很高。Gartner 研究主管 Sid Nag 曾表示，云服务市场的增长速度比几乎所有 IT 市场都要快，其中大部分增长是以传统非云服务为代价，尤其是基于云计算的 IaaS 需求在继续增长，预计将在未来 5 年呈现最快增长趋势。在云计算出现之前，企业内部自建数据中心依旧会出现很多问题，不少问题甚至是致命的。上云之后，公有云厂商至少可以帮助技术能力有限的企业进行合理范围内的监控、预警和备份。不可否认，云的出现确实解决了现阶段企业在计算、存储等方面的很多问题。但作为企业而言，完全依靠云计算厂商提供安全性的做法是不可取的。云环境的同城双活、异地灾备等方案基本就绪，尽量在经济和人员条件可行的情况下使用这些分散风险的方法。如果故障只出在一个服务器集群，采用异地灾备方案可以在最快时间切换到另一个集群，从而保持系统可用。虽然还是会有中断，但是可以最快时间恢复。按照此模式，云下系统做云上灾备也是防范传统环境出现可用性问题的一种重要手段。作为企业的 IT 人员，日常做到以下四点可以尽可能避免云故障带来的损失。•备份、备份，还是备份，要异机异地；•数据容灾；•业务双活；•定期对灾备和双活进行演练。从统计上看，中小企业的运维水平远低于主流云平台，故障概率要高得多，损失更不可控。因此，不必对云服务故障抱有恐惧，只需要保持正常的认知和高度灾备意识即可。

ServiceComb的rest支持两个通道：transport-rest-vertxtransport-rest-servlet一般来说，只需要使用其中一个，但是也有可能同时使用，当通过maven将它们同时引入依赖时，初始化策略如下：先尝试transport-rest-servlet如果servicecomb.rest.address指定的端口，已经被监听了，则认为端口被servlet容器监听了（实际不一定，还可能是其他进程，这里不再做识别），需要启用transport-rest-servlet如果端口未被监听，则说明servicecomb.rest.address配置的端口与servlet容器不同，不需要启用transport-rest-servlet再尝试transport-rest-vertx如果servicecomb.rest.address指定的端口未被监听，则说明需要启用transport-rest-vertx，否则不需要启用如果所有两个通道，都判定为不需要启用，则说明肯定不是期望的结果，此时会报“all transport named rest refused to init”注：  当只引入一个依赖时，其实也是按上面的逻辑判定，只不过引入哪个依赖，就按哪个依赖的逻辑运行  如果最终无法启用，则一样会报这个错误

说明：近日，RightScale发布了2019云状态报告，云技术社区第一时间翻译了报告的精华部分。整个报告最核心的信息是：随着云使用的增长，组织专注于云成本和治理。摘要RightScale 2018年9月被Flexera收购，Flexera是一家技术资产管理解决方案提供商，帮助企业深入了解如何优化支出并降低风险。过去八年一直在制作云状态报告的RightScale云行业研究团队加入了Flexera，并再次进行了年度云状态调查，并为RightScale 2019云状态准备了分析结果来自Flexera的报告。在2019年1月，Flexera对广泛的跨组织的786名技术专业人员进行了调查，了解他们采用云计算的情况。2019年云状态调查确定了以下主要发现：一、84％的受访者拥有多云战略84％的企业采用多云战略。具有混合策略（结合公有云和私有云）的企业在2019年从2018年的51％增长到58％，而具有多个公有云或多个私有云策略的组织数量略有下降。二、94％的受访者使用云公有云采用率为91％，私有云采用率为72％。69％的受访者使用至少一个公有云和一个私有云。 企业正在优先考虑公有云和私有云的平衡。公有云是31％企业的首要任务。许多公司采取平衡的方法，28％的公司优先考虑混合云，另外17％的公司优先考虑公有云和私有云。三、组织平均利用近5个云受访者已经在3.4公有云和私有云的组合中运行应用程序，并试验了1.5个以上，共计4.9个云。在使用公有云的用户中，受访者目前正在使用2.0公有云，并尝试使用1.8个公有云。在使用私有云的用户中，受访者目前正在使用2.7私有云，并尝试使用2.0多个私有云。四、企业云支出非常重要且增长迅速2019年与2018年相比，公司计划在公共云上花费24％以上。13％的企业每年在公有云上花费超过1200万美元，而50％的企业每年花费超过120万美元。公有云支出增长速度比私有云增长快3倍（24％对8％）。中小企业的总体工作量通常较少，因此云账单较少，但11％的中小企业年度支出仍超过120万美元。五、公司在云中运行大部分工作负载受访者总体上在公有云中运行38％的工作负载，在私有云中运行41％（可能包括支持云的虚拟环境）。企业在公有云中运行33％的工作负载，在私有云中运行46％。中小企业在公有云中运行43％的工作负载，在私有有云中运行35％。六、企业中心IT专注于管理和优化云成本66％的企业已经拥有中中心云团队或云计算中心，另有21％的企业规划了一个。在中小企业中，只有31％拥有中心云团队。对于企业而言，中心IT的主要职责是管理和优化云服务成本（68％），决定或建议在哪些云中运行哪些应用程序（62％），以及为云使用设置策略（59％）。在企业内部，管理和优化云成本的大部分责任落在中心云团队和基础架构和运营团队上，而业务部门经常拥有云预算。七、管理云支出和云治理是企业面临的最大挑战无论云成熟度如何，云成本管理和云治理都是最大的挑战。在企业中，优化云成本（2019年为84％，2018年为80％）和云治理（2019年为84％，2018年为77％）是越来越多的挑战。管理在公有云环境中运行的软件许可证也成为首要问题。 主要挑战是了解云中运行的许可软件（52％）的成本影响，公有云中许可规则的复杂性（42％），以及确保遵守规则（41％）。八、2019年的首要优先事项是云成本优化优化现有的云用于节省成本仍然是2019年连续第三年的首要举措，从2018年的58％增加到64％。随着云使用的增加，管理云支出的挑战也在增加。 虽然64％的受访者认为优化云支出是最重要的举措，但中等和高级云用户的这一数字甚至更高，分别为70％和76％。其他重要举措包括将更多工作负载迁移到云（58％），扩展容器的使用并采用云优先策略（**率为39％），并实施自动化治理策略（35％）。九、云用户没有尽其所能来优化成本云用户低估了浪费的云花费。 受访者估计2019年浪费了27％，而Flexera已将实际浪费测量为35％。尽管人们越来越关注云成本管理，但只有少数公司实施了自动化策略来解决此问题，例如关闭未使用的工作负载或修改实例。云用户未充分利用各种云提供商折扣选项。 在AmazonWebServices®（AWS）用户中，只有47％的用户使用AWS预留实例，而Microsoft Azure用户仅在23％的时间内使用预留实例。十、容器使用量增加，Kubernetes的使用率暴涨。Docker®容器的使用持续增长，采用率从2018年的49％增加到57％。Kubernetes是一个利用Docker的容器编排工具，实现了更快的增长，从27％增加到48％。企业采用率更高，66％使用Docker，60％利用Kubernetes。AWS容器服务（ECS / EKS）在2019年的采用率为44％（2018年持平），而Azure容器服务采用率达到28％（2018年为20％），Google容器引擎略有增长，达到15％的采用率。十一、Ansible在配置工具中占据首位在所有受访者中，Ansible的采用率为41％，其次是Chef和Puppet，采用率为37％。Ansible在企业中的采用率甚至更高（53％），Chef和Puppet的采用率各占50％。Ansible今年再次在中小企业中领先，采用率为26％，其次是Terraform和Chef。Terraform自去年以来增长最强劲，从20％增加到31％，增幅达55％。十二、Azure继续快速增长并缩短AWS领先优势，特别是在企业用户中整体Azure采用率从45％增长到52％，以缩小与AWS的差距。因此，Azure采用率现已达到AWS采用率的85％，高于去年的70％。Azure继续追赶AWS，特别是在企业中，Azure的采用率从58％略微增加到60％，而这一组的AWS采用率相对持平，为67％。这使得Azure基于使用每个云的受访者总数达到了89％的AWS采用水平。谷歌保持第三名的位置，从18％增加到19％。在可用性的第二年，AWS上的VMware Cloud升级至今年的第四位，从2018年的8％增加到12％，增长率为50％。去年调查中包含的其他公共云提供商中，今年的所有公共云提供商都有所增加，尤其是企业，其中Oracle从10％增长到16％（增长率为60％），IBM Cloud从15％增长到18％（20％）增长率），阿里巴巴从2％到4％（增长率为100％）。未来项目的企业受访者（实验和计划使用的组合）显示出对Google的最大兴趣（41％）。在早期阶段的云用户中，AWS和Azure更加接近，52％的云初学者选择AWS，而Azure则选择41％。 Google认为用户使用时会更加强大十三、使用来自公有云提供商的PaaS服务正在爆炸式增长无服务器连续第二年成为增长最快的扩展云服务，2018年增长50％（掺杂率为24％至36％）。流处理首先并列，采用率从20％提高到30％。机器学习，容器即服务和物联网是下一个增长最快的。在企业中，关系型DBaaS（60％），数据仓库（50％）和推送通知（50％）位居前三位，而容器即服务排名第四（48％）。机器学习对未来的使用具有最高的兴趣，48％的受访者尝试或计划使用它。十四、私有云采用率正在缓慢增长2019年，大多数提供商对私有云的采用增长缓慢。总体而言，VMware vSphere继续领先，采用率为50％，与去年持平。与2018年相比，OpenStack（28％），VMware vCloud Director（27％），Microsoft System Center（25％）和裸机云（24％）都显示出小幅增长。Azure Stack位于第六个位置，但增长率最高（2019年为22％，2018年为17％）。AWS Outpost于2018年底宣布，显示出强大的采用率（12％）和未来使用的强烈兴趣（29％）。十五、Azure中的工作负载正在增长，但落后于AWS在所有受访者中，13％的用户在vSphere中拥有超过1,000个虚拟机，而AWS中为11％，Azure中为6％。AWS在拥有超过100个虚拟机的受访者中处于领先地位（AWS为33％，VMware为27％，Azure为25％）。年复一年，Azure显示用户百分比增幅最大，超过100个虚拟机从2018年的17％增加到2019年的25％。十六、云成熟度模型在本报告中，RightScale使用其云成熟度模型根据云采用水平对组织进行细分和分析。 云成熟度模型确定了云成熟度的四个不同阶段。 表示组织从最少到最好的经验采用云，这四个阶段是：观望者是正在开发云战略和计划但尚未将应用程序部署到云中的组织。 他们希望评估可用的云选项，并确定在云中实施哪些应用程序。初学者是云计算的新手，正致力于概念验证或初始云项目。 初学者希望获得云的经验，以确定未来的项目。中级用户已在云中部署了多个项目或应用程序。 他们专注于改进和扩展他们对云资源的使用。高级企业大量使用云基础架构，并且正在寻求优化云运营和云成本。 Flexera的RightScale 2019云状态报告所依据的调查包括云成熟度所有阶段的组织。在比较大型和小型公司的云采用情况时，超过三分之二（68％）的企业受访者现在处于两个最成熟的阶段--中级和高级。中级和高级阶段的企业比例持续增加，2019年占受访者中的68%，而2018年为66％。（内容来源于互联网，如侵犯您的合法权益或有其他任何疑问，请联系：huaweicloud.bbs@huawei.com沟通处理。谢谢！）

本次课程希望能够帮助您深入理解华为云镜像服务，包括私有镜像与公共镜像之间的区别，探讨当前华为云镜像服务的各种功能。简单的说，镜像就好像是克隆体，它可以把一个已有的云主机操作系统和应用服务，快速的复制到您的云主机中，省时又省力。温馨小提示：还没有华为云账户来体验本节课程的操作吗？戳这里，免费注册华为云账户！有账户没有云服务器？戳这里，免费试用4核8G高速云服务器！镜像是一个包含了软件及必要配置的云服务器模版，包含操作系统或业务数据，还可以包含应用软件（例如，数据库软件）和私有软件。选择使用的镜像类型创建弹性云服务器时，在选择完规格后接下来就是选择镜像。华为云支持使用公共镜像、私有镜像、共享镜像、市场镜像创建云服务器。知识拓展：什么是镜像服务？镜像的常见格式有哪些？选择“公共镜像”：云平台提供的公共镜像，包括操作系统以及预装的公共应用，所有用户可见，请根据您的实际情况自助配置应用环境或相关软件。当前云平台所有支持的操作系统均在下拉列表中可见。使用公共镜像创建的云服务器可以提供官网OS的技术支持。同时，公共镜像预装了Cloudbase-Init/Cloud-Init工具、PV driver、UVP VMTools等常用工具，免去了用户自定义安装配置。我本次购买选择的是CentOS 7.5的公共镜像。可以在后期云服务器购买完成后检查是否已经安装了上述工具。知识拓展：Cloud-Init可以对新创建的云服务器中指定的自定义信息（主机名、密钥和用户数据等）进行初始化配置。点击获取：如何检查云服务器是否已经安装Cloud-init工具？云服务器的正常运行依赖于XEN Guest OS driver（PV driver）和KVM Guest OS driver（UVP VMTools），为了同时支持XEN虚拟化和KVM虚拟化，需要确保镜像安装了PV driver和UVP VMTools。点击获取：如何查看Windows操作系统云服务器虚拟化类型？、如何查看Linux操作系统云服务器器虚拟化类型？选择“私有镜像”：用户自己制作的， 包含操作系统或业务数据，预装了用户的私有应用的镜像，仅用户自己可见。我们可以在镜像服务的列表页面详细查看当前区域下可用的私有镜像。注意：在创建私有镜像时需自行安装Cloud-init，最近镜像服务新增“采用源码编译安装方法”，Cloud-init配置的相关内容已在源码包编译完成，采用源码编译安装方法安装Cloud-init后无需执行Cloud-init配置操作，创建私有镜像时推荐大家使用源码编译方法安装Cloud-init。知识拓展：如需指定云服务器的镜像，请提前使用指定云服务器创建私有镜像：使用Windows云服务器创建私有镜像。如需使用本地的镜像文件，请提前将镜像文件导入并注册为云平台的私有镜像：如何将外部镜像文件注册为华为云平台私有镜像。如需使用其他区域的私有镜像，请提前复制镜像：跨区域复制镜像。选择“共享镜像”：其他用户共享的私有镜像，作为自己的镜像进行使用、可以用来创建云服务器、裸金属服务器和云硬盘。如果需要使用其他账号的私有镜像，请提前完成镜像共享。我们可以在镜像服务的列表页面详细查看当前区域下可用的共享镜像。知识拓展：当前镜像共享的范围只能在区域内。如需跨区域共享镜像可以和镜像服务当前的跨区域复制镜像功能相互结合，先跨区域复制镜像至同一区域，然后再共享镜像。选择“市场镜像”：第三方提供的预装操作系统、应用环境和各类软件的优质镜像。市场镜像的优势在于提供预装操作系统、应用环境和各类软件的优质第三方镜像。按照市场镜像的协议购买后，即可享受第三方的服务支持，无需配置，可一键部署，满足建站、应用开发、可视化管理等个性化需求。当前很多基础功能的市场镜像是免费的，只需支付云服务器的按需/包年包月的费用。知识拓展：使用市场镜像部署WordPress（Windows）使用市场镜像部署Windows环境趣味课堂：镜像服务针对各种类型的镜像制作一张精美问云图说，可以快速了解公共镜像、私有镜像、共享镜像、市场镜像与弹性云服务器之间的关系，推荐大家点击查看。镜像服务最新推出的整机镜像功能支持使用弹性云服务器携带其挂载的数据盘一起创建整机镜像，创建的整机镜像包含用户的业务数据，可用于快速发放包含用户业务数据的弹性云服务器。         -  使用云服务器创建整机镜像         -  使用云服务器备份创建整机镜像随堂小测当前华为云镜像服务仅支持在同一区域内共享镜像，如果用户小A想要将华北-北京1的私有镜像共享至用户小B的华南-深圳区域，应该怎样实现呢？随堂小测奖励规则：1、通过直接回帖的方式回答小测，我们会根据回答正确答案的先后顺序打分：2、回答正确的前十名朋友可以获得分数，即：第一个回答正确得10分，第二个回答正确得9分……以此类推；3、每五次随堂小测一汇总，得分最高的朋友将得到实物奖励（荣耀手环一个）；希望大家踊跃回答，更多奖励等你来拿哦~~~~【以文会友，以友辅仁】华为云帮助中心正式开源啦。文档协同编辑，共建优质帮助体系！IMS资料开源地址：镜像服务帮助文档开源地址更多资料开源地址：华为云帮助文档开源地址【往期回顾】【第一课】我该怎么选择云主机的规格？

镜像交付流水线ContainerOps是华为云容器镜像服务（SWR）推出的面向从源代码到生产上线全流程服务，提供镜像仓库、镜像构建、版本管理、交付流水线等一系列服务，助力企业落地容器DevOps最佳实践。镜像交付流水线ContainerOps正在公测中，点此立即体验：https://console.huaweicloud.com/swr?c_yuntu  ContainerOps帮助中心文档，请参见https://support.huaweicloud.com/usermanual-swr/swr_01_0034.html更多产品信息请点击：https://www.huaweicloud.com/product/cce.html0元起体验云原生之旅：https://activity.huaweicloud.com/cloudnative.html?ggw_hd更多免费体验请点击：https://www.huawei.com/audience/answer.do?u=1664982欢迎关注官方公众号了解更多云原生内容：

之前给大家讲了构建镜像的原理，那么有了镜像之后，我们怎么样能将它快速的部署到kuberentes集群上呢？ 早期，大家都习惯于使用kubernetes接口，或者cli命令行来完成这些操作，但是yaml文件语法的复杂性、大量容器和kuernetes的概念，让人难以理解，无疑成为容器化交付路上的又不障碍。为了解决这些问题，华为云容器服务推出了向导式镜像部署，通过一步步引导、对复杂概念的屏蔽或抽象，在一定程度上降低了用户首次部署镜像的难度，但是灵活度相对较差，对于经常变更版本的场景，还是需要使用原生接口进行操作，使得整体研发交付流程的复杂度并未降低太多。鉴于此现状华为云容器团队又推出了一款易用性更好、自动化程度更高的服务产品——容器交付流水线，它以容器技术为基础，践行DevOps的理念，围绕容器业务端到端场景提供持续集成和持续交付能力，包括代码编译、镜像构建与交付、自动化部署、升级回滚等能力，并提供全量能力接口，便于与企业已有流程相结合，同时接口屏蔽底层容器概念，对接口进行了二次封装，接口定义更贴近于CI/CD业务概念，使得熟悉CI/CD流程的用户能快速切换。发布组件作为该产品的一个重要组成部分，其直接影响了整个发布周期，我们今天就跟大家一起聊聊该部件的一些实现原理。01Kubernetes DeploymentKubernetes Deployment提供了官方的用于更新Pod和ReplicaSet（下一代的Replication Controller）的方法，我们可以在Deployment对象中填写我们需要用到的配置和版本信息，Deployment控制器将现在的实际状态转换成我们所期望的状态，例如，将nginx:v1.0升级成nginx:v2.0，我们只需创建一个Deployment，Kubernetes会按照Deployment自动进行升级。而随着Kubernetes的迭代更新，目前云容器引擎服务提供了几个版本的集群，那么如何使得部署组件支持不同的集群版本呢？由于我们的CI/CD的工具提供了deployment的yaml页面编辑，部署组件会根据deployment中apiversion即：apps/v1, apps/v1beta1, extensions/v1beta1。提供不同版本的API接口。自行封装接口使得发布组件自主能动性强，免于受制于第三方库。02如何判断发布成功？解决了版本问题，还有一个最重要的问题，是如何判断组件发布结果呢？对于一个CI/CD工具，我们判断工作负载运行成功的标准并不仅仅是Pod处于running状态又或者工作负载处于可用状态。我们需要保证的是工作负载运行的镜像或者配置是新版本的。因此我们判断成功的标志应该是新起的pod处于running状态，那如何找到这些新起的pod呢？下图展示了Deployment，ReplicaSet和Pod之间的关系，以无状态工作负载为例，我们通过查询deployment中Annotations的"deployment.kubernetes.io/revision"，根据这个revision寻找Deployment控制的ReplicaSet。最后根据ReplicaSet的label去寻找这些新起的pod。我们已经找到这些新起的Pod了，那么现在就需要对pod的状态进行分析了。在K8s源码中PodPhase字段表示了pod的不同阶段：Pending: k8s已经接受创建pod的请求，但是容器并没有启动成功，这个阶段包括调度之前的，下载镜像等。 Running: pod已经绑定到node节点，并且所有的容器已经启动成功，或者至少有一个容器在运行，或者在重启中。 Succeeded: pod中的所有的容器已经正常的自行退出，并且k8s永远不会自动重启这些容器。 Failed: pod中的所有容器已经终止，并且至少有一个容器已经终止于失败（退出非零退出代码或被系统停止）。 Unknown: 由于一些未知的原因，无法获得pod的状态，通常是因为pod的主机通信错误。而以上四个阶段只是一个粗略状态阶段。而对于每一个阶段都有更详细的pod conditions信息，podcondition数组的元素都包含了类型和状态字段，这个类型分为以下四种:"Ready"：Pod能够提供服务"PodScheduled"：pod正处于调度中"Unschedulable"：调度程序现在无法调度Pod，例如由于缺乏资源或其他限制;"Initialized"：所有pod的容器初始化已经完成。"ContainersReady"：pod中的容器都已准备好。其中状态字段用"true" 表示处于,"false"表示不处于，我们发现当阶段为Running, condition中Ready状态为True时， 即表示pod中的容器可以提供服务了。因此，我们现在就可以依次判断新起的pod是否升级成功了。03如何判断发布失败？现在我们能够判断成功了，下一步就需要对失败的状态进行一个判断，其实理论上负载的成功或者失败不是一个确定性的东西，k8s本身具有重试机制，也存在概率性调度失败的情况。所以一开始我们考虑的是通过一个超时机制来判断发布失败的情况。但后面分析考虑到，发布作为一个重要的组件，需要第一时间知道问题所在，以致可以快速进行版本回退等操作。对于容器的状态，pod中的containerstatus包含了更详细的当前容器的状态。其state字段表示容器当前的状态，state分为三种状态：等待中，运行中和已终止，对应三种不同类型的结构体。等待中的结构体包含了处于非运行状态的原因和信息。其他结构体就不在此一一赘述。结合podphase、podcondition、以及containerstatus，我们总结了如下几个升级异常状态（如有不全，欢迎补充）：PodPhase == FailedPodPhase == SucceededContainerStatuses 中有一项为state.waiting 并且 waiting 的原因不是ContainerCreating 或者 PodInitializing(ContainerCreating表示容器创建中，PodInitializing表示pod初始化中)ContainerStatuses 中有一项为state.running 并且 containerStatuses.ready == falseConditions中存在一项的type为Ready且status为False且Containerstatues存在Conditions中存在一项的type为PodScheduled且status为False：调度失败由于pod的状态是动态变化的，为了保证发布结果的准确性，我们选择pod超过3次时置为失败状态，即发布失败。看完上面这些原理解析，您是不是有什么收获，或者有什么想法与我们交流呢？请在下方留下您宝贵意见和建议吧？说不定下个版本，您的创意就会出现在我们的产品里。相关服务请访问https://www.huaweicloud.com/product/swr.html?cce_helpcenter_2019

Istio利用k8s的探针对service进行流量健康检查，有两种探针可供选择，分别是liveness和readiness:liveness探针用来侦测什么时候需要重启容器。比如说当liveness探针捕获到程序运行时出现的一个死锁，这种情况下重启容器可以让程序更容易可用。readiness探针用来使容器准备好接收流量。当所有容器都ready时被视为pod此时ready。比如说用这种信号来控制一个后端服务，当pod没有到ready状态时，服务会从负载均衡被移除。使用场景：liveness探针被用来移除异常的pod，不重启pod就无法恢复的应用常使用liveness探针。比如前文提到的死锁，进程会一直处于活跃状态，k8s会认为正常并继续发送流量。但使用liveness探针之后会发现应用已经不再处理请求，继而重启异常pod。readiness探针被用来控制流量进入pod。比如应用程序需要加载一个大的文件或者需要启动后进行一些配置。但默认只要容器进程启动完成就会有流量发送过来。使用readiness探针会一直等待直到完成所有加载或配置再让流量进入。两种探针的配置相似，区别在于使用livenessProbe还是readinessProbe字段探针配置参数：探针有以下几个参数：initialDelaySeconds：容器启动之后到启动探针之间的时延periodSeconds：探针的循环执行时间，最小单位为1秒timeoutSeconds：探针超时时间，默认值1秒successThreshold: 成功阈值数，失败之后最小的连续成功信号数，liveness必须是1failureThreshold：失败阈值数，当探针失败之后，在放弃之前k8s尝试重新执行探针次数,如果是liveness探针放弃意味着重启容器，readiness探针意味着pod标记为unready，默认值为3次。HTTP探针还有以下额外的参数：host: 所连接主机名，默认值是pod IPscheme: HTTP或者HTTPSpath： 访问HTTP 服务器的路径httpHeaders: 访问HTTP的报头port:访问容器的端口探针可以进行三种操作：命令行：在容器中执命令行操作，exit 0为成功状态HTTP请求：向容器发送HTTP GET请求，如果返回值为200-400之间为成功状态TCP 请求：向指定端口发送TCP请求，如果该端口开放监听，则为成功下面我们来演示以下健康检查的操作：命令行操作首先准备busybox镜像，设置如下的yaml配置文件：在配置文件中我们设置了一个liveness探针，在容器启动之后的5s,每隔5s去执行一下访问/tmp/healthy这个文件的操作，如果操作成功返回0，则为容器健康，如果返回值不为0， 会重启容器。当容器启动之后会执行：touch /tmp/healthy; sleep 30; rm -rf /tmp/healthy; sleep 600前30s会建立/tmp/healthy文件，30s之后删除，此时访问会返回错误.使用kubectl create -f ./your-exec-liveness.yaml建立pod在30s之内通过kubectl describe pod liveness-exec来查看pod状态，为健康：在30s之后查看pod的状态，发现无法访问文件，返回不健康：之后查看pod的状态，pod的重启次数为1，此时通过liveness探针检测到不健康状态已经重启pod。如果使用readiness探针，需要修改上文your-exec-liveness.yaml的红框字段：通过与上文相同的方法，在30s之前查看pod的状态，为ready:在30s之后查看pod状态，readiness探针将应用容器置为unready, ready的容器是istio-proxy：可以看到readiness探针并不会重启容器。HTTP请求另一种使用liveness探针的方法是HTTP GET请求，可以用来监测网页的运行状态，我们用google liveness镜像来进行演示：这里我们让HTTP的服务器/healthz路径前10s返回200 的OK状态，10s之后返回状态500。设置如下的配置文件：liveness探针会向容器的8080端口发送请求访问/healthz， 在容器启动3s之后每隔3s发送一次。我们建立pod并查看pod的运行状态kubectl describe pod liveness-http：会发现10s之后 liveness探针监测到了返回值是500，状态标记为不健康。TCP请求两种探针还可以共同使用，下面以TCP请求为例，TCP和HTTP连接类似。使用google的goproxy镜像，该镜像会在8080端口开放TCP socket连接，使用如下的配置文件：我们用探针去访问8000端口查看pod状态；此时理论上应该无法连接：可以看到readiness探针会每隔10s监测，无法访问时会将pod置于unready状态，liveness探针20s监测，无法成功则重启pod。 通过以上演示我们了解了如何配置两种探针和执行三种操作。通过合理的探针配置，可以实时监控Istio各个pod的运行状态，提供方便的应用治理手段。相关服务请访问https://support.huaweicloud.com/cce/index.html?cce_helpcenter_2019

华为开源镜像站体验第一次作为体验官体验华为的产品， 要输出报告。本次报告输出体验报告内容要求要涵盖部分内容，再加一点个人的体会吧。操作体验是否能顺畅的找到自己所需要的组件镜像，并加入到自己的项目中。首页图片， 标语是` 华为开源镜像站由华为云DevCloud团队开发及维护，DevCloud致力于打造让软件开发更简单的一站式DevOps工具云服务`其实这行可以更大一点， 竟然比登陆注册的文字都要小。从导航条能看出来提供了语言类，工具类，操作系统类，容器类等几个大类别， 还有华为SDK。系统类这个页面进来之后感觉稍微有点问题， 默认的排序方式是首字母， 作为展示推荐的功能， 默认按照热度排序召回会更好些。然后点了按照热度这个界面好，每个卡片标注了类别， 但看了之后第一反应是我要找ubuntu的镜像， 按照系统类筛选下。点了操作系统类之后， 怎么又跳回默认的字母排序了。这Ubuntu按说也算是常用源，但是按照字母排序，妥妥的排在倒数。再回看刚才那个图，发现热度排序首页也已经有了， 只是屏幕小，在最下面，没注意到。Ubuntu在系统类排序中排名第四。建议1. 这个建议做两级筛选， 排序方式和类别筛选分开做。 1. 搜索条可以更大点，挺好用的。容器类提供了Docker的镜像，虽然官方国内也能访问。性能构建过程，加载组件的速度。Ubuntu界面指引这个里面点赞是可以水的，不停的点就可以。使用说明觉得也还OK了下载了下Docker，一分钟左右吧，还可以Docker容器镜像和系统类的还不太一样，标题点不了，还没来得及融合的更好。和原镜像对比了下centos的镜像下载，还是， 挺慢的。但是在华为云的服务器上， 速度还是很快的，可以感受下对比下。功能特性k8s阿里云有提供镜像， 华为云没有。满意度及推荐度如果服务器在HWC的话，还是蛮推荐用的， 速度很快。就Docker来讲， 本地速度似乎没有优势。采用华为的云生态DevOps的话，这个开源站无疑很棒， 速度各方面都有保证。从初心上来讲， OK了。` 华为开源镜像站由华为云DevCloud团队开发及维护，DevCloud致力于打造让软件开发更简单的一站式DevOps工具云服务`这个活动也蛮好， 之前还没太关注镜像站。

微服务为我们带来了快速开发部署的优秀特性，而如何降低开发和变更的风险成为了一个问题。Istio的流量镜像，也称为影子流量，是将生产流量镜像拷贝到测试集群或者新的版本中，在引导实时流量之前进行测试，可以有效地降低版本变更风险。流量镜像有以下优点：1.当流量镜像到不同的服务时，会发生在请求的关键路径之外，这样流量镜像产生的任何问题都不会影响到生产；2.忽略对任何镜像流量的响应; 流量被视为“即发即忘”，这样就不会干扰到正常的生产流量的响应；3.当流量被镜像时，请求将通过其主机/授权报头发送到镜像服务附上 –shadow，用以区分流量从何处被镜像到何处；4.利用实时生产用例和流量可以有更真实的测试服务环境，有效降低了部署的风险；下面介绍几种典型的使用场景可以发挥流量镜像的优势：1.用于测试：测试集群的测试可以使用生产实例真实流量，不会影响正常生产的关键路径。2.用于新版本校验：可以实时对比生产流量和镜像流量的输出结果。3.用于协作服务版本回退:当用到镜像流量的服务需要修改协作服务时，因为镜像模式添加了-shadow标记, 所以可以正常处理镜像请求，并在提交之前回滚。不会让镜像版本的更改影响生产版本。4.隔离测试数据库：与数据处理相关的业务，可以使用空的数据存储并加载测试数据，针对该数据进行镜像流量操作，实现测试数据的隔离。下面通过实例来演示一下，先让所有流量都到v1版本，然后使用规则将流量镜像到v2版本：环境准备：需要httpbin和tutum/curl两个应用镜像步骤一(配置并启动服务)：首先部署两个版本的httpbin服务：httpbin-v1:httpbin-v2:部署sleep服务，为curl来提供负载：当完成以上的配置文件后，就可以用kubectl create –f ./yourconfig.yaml来启动服务，用kubectl get pod 来查看服务的运行状态：启动httpbin service:先通过kubectl get svc 查看是否有httpbin service。如果已创建service, 需要用kubectl delete service httpbin 删除，并通过下图所示yaml 新建service：步骤二（创建路由策略）：1.使用kubectl delete virtualservice httpbin，kubectl delete destinationrule httpbin删除已有httpbin策略，并通过下图yaml来创建新的路由策略，将全部的流量导入到v1版本：通过kubectl create –f ./yourrules.yaml生效：2.现在服务已经搭建好了，我们向服务发送一些流量：3.分别查看httpbin的v1,v2的pod中的日志：我们可以发现v1 pod中有刚才流量访问的记录，而v2的pod中日志为空，说明流量并没有进入到v2的pod中，这与我们全部流量导入到v1中的策略相匹配。步骤三（镜像流量）：1. 修改路由规则将流量镜像到v2服务：删除之前部署的virtualservice规则，将上图的yaml用kubectl create –f 部署，其中mirror字段将流量镜像指定到v2服务。2.发送流量：通过指令kubectl exec -it $SLEEP_POD -c sleep -- sh -c 'curl  http://httpbin:8080/headers' | python -m json.tool 发送流量：3.查看v1和v2的访问日志:通过对比记录的时间戳我们可以发现在更改策略后，v1的流量被镜像到了v2。日志中的v2报文比v1大是流量被标记为影子流量所致。步骤四（清除）：1.清除路由规则：kubectl delete virtualservice httpbinkubectl delete destinationrule httpbin2.关闭httpbin/sleep服务：kubectl delete deploy httpbin-v1 httpbin-v2 sleepkubectl delete svc httpbin通过以上步骤我们知道了如何设置路由规则来引入流量镜像。相关服务请访问https://support.huaweicloud.com/cce/index.html?cce_helpcenter_2019

作者：桑酱写在前面随着越来越多企业应用上云，云上应用的规模与复杂度日趋增长，对云上应用的运维，也提出了新的挑战。华为云AOM服务面向大规模企业应用的运维，在实践中演进并构建了一套完整的面向云上应用的立体化运维系统。下面以一个典型的云上应用架构为例，分享华为云AOM立体运维的架构与定位。后续会有立体运维系列的文章，讲述各子系统的技术细节及优秀实践，欢迎持续关注。目录一、常见云上应用的架构二、华为云立体运维的定位及架构1、立体运维定位2、资源模型化3、数据可视化4、服务平台化5、分析智能化6、华为云AOM整体架构一、常见云上应用的架构云上应用早期较多的是购买云服务I层资源（多为基础设施如主机等计算资源）自建各种集群，运维人员多以主机监控为中心进行运维，同时自己搭建应用及数据库等监控系统进行应用层和业务层运维。随着容器技术的普及，越来越多的企业转向CaaS和PaaS来管理应用，通过微服务框架开发，业务的实现也更多的使用云上服务，如分布式中间件，函数服务，AI服务等，同时运维也转向云上的运维服务。一个典型的现代云上应用架构： 经过域名解析阶段后，静态资源命中CDN后直接返回，无命中时会回源去拉取，动态请求直接访问WEB服务，在请求到达四层和七层ELB之前，多数企业应用也会选择WAF来清洗异常流量。经过ELB后，请求到达业务应用服务器，业务实例多为分布式构架，微服务之间相互调用，一般情况下企业运维人员较多的关注点是应用实例这一层，多为企业自行开发的服务。持久化层当前各CSP提供的中间件不一样，华为云上用户使用较多的如分布式缓存，分布式数据库等。由于提供动态扩容及较高级别的SLA，越来越多的企业不再需要专业的DBA，转而使用云上的服务，开发上也更加敏捷。如此多的云服务和各种资源，任何一个环节出现问题，都将导致应用KPI异常，用户体验下降，进而导致企业运营受到影响，而每个使用公有云服务的企业，如果投入大量人力去自建运维系统并且将整个请求的各个环节关联起来，成本会非常高。因此华为云AOM在帮助企业对应用运维的过程中，通过实践构建了一套立体运维体系，帮助企业更好的进行一站式运维。下面章节将为您介绍立体运维的定位及架构。二、立体运维的定位及架构1、立体运维定位AOM立体化运维主要是围绕用户应用进行监控，一站式完成用户体验监控，应用性能监控，基础设施监控。参考以上典型云应用架构，通过将业务请求路径上经过的不同资源进行分层，围绕分层设计不同的专业运维服务子系统，将不同数据在不同子系统上串联协同、关联分析，构筑一个云上的运维平台，从而最大化的实现数据价值，为运维人员提供一个统一的运维中心，达到一站式立体化运维的目的。如下为AOM立体运维分层： 图为华为云AOM立体运维分层构建AOM立体运维，除了要覆盖应用的端到端资源以外，重点还要通过多种运维数据进行数据分析，通过多种可视化手段进行友好的界面展示。因此AOM立体运维体系建设包括以下工作： 2、资源模型化其实就是将应用依赖的资源接入CMDB，但是云上业务的CMDB与自建数据中心运维有所区别，后者多对应的是SRE（网站可靠性工程师）层面的CMDB，而AOM所需要的CMDB是面向云资源的量身打造的CMDB。主要有以下特征分离业务模型与存量资源模型（后续文章后详细解读）存量模型能表述不同的云服务下的不同云资源支持对云服务内云资源建立映射关系支持对跨云服务的资源建立映射关系支持云资源标签管理（打标签，同步标签，按标签查询）支持历史资源快照资源模型化这一步是所有数据关联及运维平台化的基础，通过统一的模型将不同资源关联起来后，可以帮助用户快速的找到故障的根因，也能通过关联关系对大量告警进行分析，抑制重复告警等。3、数据可视化良好的可视化界面不但能提高运维人员运维效率，还可以通过直观的展示查看各种资源消耗趋势，帮助企业分析运营走势，预测未来资源使用情况等。AOM数据可视化遵从以下原则进行设计·          建立左右逢源的资源拓扑图资源拓扑是指一个资源与其他资源的关联关系，如ECS与应用，服务，实例及数据库的关系，通过一个资源拓扑图进行展示。如下所谓左右逢源是指以一个资源为中心，拓扑图展示其上下各一层的关联资源即可，避免拓扑过大，但又能通过一个资源找到上层或者下层资源。·          关联资源下钻建立拓扑后，通过图上的资源链接，可以跳转到选中的另一个资源的拓扑图中去，而新的拓扑图是以新的资源为中心，如此来达到通过关联资源不断下钻的目标，方便运维人员查找问题。·          云资源快速跳转一个云资源可能涉及到多个云服务，如ELB实例，涉及ELB服务本身，VPC，CDN，ECS，而各个云服务入口较分散，需要在资源名称增加超链接快速跳转到云服务console。·          视图模板化各资源监控数据的展示，由AOM默认提供模板，但同时要支持用户自定义模板，由于运维人员关注的指标或其他数据侧重点不一样，因此要能通过模板支持同一个资源不同视角的查看方式。·          功能向导化复杂功能需要通过向导快速指导用户进行设置或配置，以减少用户学习文档或者视频的时间成本。 4、服务平台化平台化目标要支持用户通过各子系统通过开放API实现自动化运维。指标，日志，事件告警等数据要支持用户通过接口订阅，转发到外部系统供用户运维平台进行分析，分析结果通过API输入立体运维平台并通过事件驱动平台业务持续分析。也就是通过数据流，实现平台与用户运维系统的协同，实现流程化自动化。自动化将会协助用户实现故障自动恢复，如通过数据分析后发现需要扩容，可以通过事件触发或者API调用弹性伸缩子系统进行实例扩容。还可以在资源空闲时缩容以节省企业运营成本。5、分析智能化针对指标数据提供动态阈值计算能力，无需用户设置阈值，通过机器学习进行异常检测，对于大型系统的运维可以有效的降低人工配置成本。同时也避免静态阈值设置不合理需要不断调整的重复工作。针对日志数据，智能提取模板，分析可变参数与静态文本，通过日志关键字监控，实时掌握应用异常情况。 6、AOM整体架构以下为AOM整体的架构，主要分为五个子系统，每个子系统通过多个微服务提供不同功能，整体协同实现立体运维目标。 ALM模块负责事件告警的管理及相关性分析，支持用户配置通知策略以及时将告警发送给运维人员。ALS模块负责分析日志。INV模块即CMDB模块，实现资源的管理及资源的映射及查询等能力。AMS模块主要负责指标数据的管理，提供阈值配置能力。DPA模块主要负责智能化能力，在线和离线分析数据，以事件驱动各子系统运行。 另外架构图中的底座环境，展示了AOM运维范围，从基础设施到PaaS层应用及容器和VM应用，覆盖了应用运行所依赖各层资源。后续文章将针对不同模块的设计进行解读，敬请期待。更多干货可关注公众号阅读

虽然docker、kubernetes的命令集并非十分复杂，后台操作也比较快捷，但是对于大多数徘徊在容器化门口的企业和个人用户来说，仍旧是一块心病，docker or not docker， that's a question，SWR服务通过提供界面化的操作，屏蔽原生命令行，简化用户操作和技术门槛，为企业和个人用户提供极简的容器化交付平台，我们接下来会通过一系列的文章，向大家介绍SWR的这些功能特性。今天要为大家介绍的是用户0命令行，通过WEB界面实现镜像的上传及实现原理剖析。 我们从这个最为常用并极为简单的docker push功能开始讲，为什么呢？由于我们在与客户交流过程中发现，大多数都未接触过容器化管理系统，甚至镜像，对后端操作不熟悉的他们，对页面操作是有一定需求的。目前主流的PaaS平台基本都支持通过页面操作构建镜像、创建集群、创建应用等等，它们都在不断地封装底层集群管理系统（如kubernetes）的接口，设计一款对于云下用户友好的前端页面，让尽可能多的后端复杂操作可以通过鼠标的几次点击完成。我们可以将这个趋势解释为，用户的业务云化的成本（包括金钱成本和时间成本）越低，上云的倾向也就越大。如今，我们支持用户在页面上完成构建、部署等操作，如果可以实现镜像上传下载都在页面上完成，用户就可以在尝试云化的早期尽可能避开后端操作，将尽可能多的时间成本花在业务调试上，普通运维人员不需要熟悉docker命令，也可以从内网或者第三方镜像仓库下载镜像，上传并完成升级操作。接下来，我们从镜像上传逻辑和镜像结构开始讲起，阐述如何去实现页面上传镜像的功能。后端上传镜像流程分析我们的目的是实现另一种镜像上传方式，首先要了解原生的镜像上传流程是怎样的。上传镜像层docker push时，最先被上传的是镜像层文件。如下面的busybox，每一行的short ID都表示着一个镜像层的sha256值，它有两个镜像层：上传元数据文件由于层之间有顺序依赖关系，我们可以想到，上传的层文件是不足以完备地描述整个镜像的。除了镜像层文件外，docker push的时候还额外会上传一个镜像的元数据文件。该文件主要保存了镜像的环境变量、层结构、构建信息等等，并且它的sha256值就是镜像的ID。由于字段太多，在此不详细列出各字段的含义，感兴趣的朋友可以使用docker inspect命令查看，参阅docker官方文档了解一下。上传manifest你们是否注意到，每个镜像在上传结束之后，屏幕上都会多一行`xxx: digest: xxx size: xxx`，最后一行信息的打印，标识着镜像最后一部分数据上传完成，这部分数据就是manifest，而digest后面的长ID，就是manifest的sha256值。manifest主要是负责关联镜像的元数据文件和镜像层。在所有层都上传结束后，它才被传到仓库端的，用于校验是否所有实体文件都上传完成。通过抓包或者查阅官方文档，我们可以得知，manifest的结构是这样的：由上述分析可知，要完备地描述一个镜像，需要存储如下数据：镜像层元数据文件Manifest我们接下来分析一下，从docker save生成的镜像包里，我们是否能获取到这些数据。镜像压缩包结构分析通过docker save保存镜像压缩包，解压开之后，可以发现，它的文件结构是比较有序的。根目录下有这三个文件：此外，包内还有多个以长ID命名的目录，每个目录下均有如下三个文件：这里，有两个较为普遍的误区需要澄清一下：误区一：manifest.json就是manifestmanifest里描述的是元数据文件名称，以及各个层的sha256值，此外，还有它们的大小。而manifest.json里存放的不是完整的manifest信息，它仅仅记录了元数据文件的全路径名称，以及各个镜像层的全路径名称，没有记录各个层的sha256值和大小。误区二：各个层所在的目录名就是镜像层的sha256值其实目录名是用各个层的链ID（chain ID）和关联父层的链ID联合计算出来的一个特殊sha256值。这个特殊的sha256值，我们可以称之为v1 ID，它被设计于兼容较早版本(1.10之前)的docker镜像，早期版本，一个镜像中可能存在多个sha256值相同的层（如空层）。顺带提一下，上面的链ID是docker daemon使用递归的方式将每一层与依赖的所有父层联合算出sha256得到的，它可以有效解决层相同导致目录重名的问题，具体计算方式在此就不赘述了。明白了这两点之后，我们可以发现，镜像压缩包里是可以获取到与docker push同样完备的镜像数据的。其中，镜像层和元数据文件可以通过解压直接获取，而manifest则需要我们通过补充manifest.json获得。接下来我们看一看华为云容器镜像服务是怎么实现这一过程的。页面上传是怎么实现的解压并校验镜像压缩包传至后端时，先对压缩包里的文件类型校验（普通文件、软链接、目录），确认无误之后，解压至临时目录并进行大小校验（前端上传目前有大小限制）。此外，有一类镜像需要被过滤：通过`docker save image_id > image.tar`命令生成的镜像包。这类镜像是没有有效的镜像仓库和版本号信息的，我们无法判断要将其归于哪个仓库下，因此，这样的镜像可以认为是不合法的。对于页面上传而言，合法的镜像压缩包里必须有镜像仓库和版本号信息(如使用`docker save repository:tag > image.tar`的方式生成的镜像)。保存实体文件接下来，通过临时目录下的manifest.json，找到对应的元数据文件xxxx.json和各个目录下的镜像层文件进行存储。保存之前，通过元数据文件xxxx.json中各个层的sha256值，对实际镜像文件进行校验，保存过程中，我们在manifest.json的基础上，补充各个镜像层和元数据文件的sha256值、大小等信息，得到manifest。在这里有个需要注意的地方，层文件一般都是普通文件，但是个别情况下（如docker1.10之前的版本），层文件可能是软链接，指向同镜像压缩包里的的另一个层文件，如果要兼容老版本，需要识别出这一部分特殊文件，跳过实体文件的保存。保存元数据最后，将镜像层元数据列表和manifest元数据在同一事务里存进数据库，保证镜像元数据的存储是一个原子操作，则镜像所有数据保存完成。该镜像可以通过docker pull的方式正常下载。这只是华为云容器镜像服务基于优化用户体验的目的而开发的特性之一，我们一直致力于降低云容器技术的槛和使用成本，推进软件行业容器化的进程，希望有兴趣的朋友可以来体验一下，并提供你们宝贵的意见。除此之外，我们最近还新上线了容器持续交付的工具，可以将您的源码快速编译、构建成镜像，省去本地编写Dockerfile、镜像制作、发布和部署的繁琐过程，后面文章我们将详细为您介绍。