「深度学习福利」大神带你进阶工程师,立即查看>>>
11月21日视频直播了KubeEdge系列课程的第二课《KubeEdge云边协同&云端组件设计》,课程首先回顾了KubeEdge的云、边、端三层整体架构。再针对KubeEdge的云上部分,分析了云端组件与K8s Master的关系、各个云端组件的设计原理,Device API的设计原理、云边消息可靠协同的设计原理等,详情见本次课程回放。
回放地址：
媒体中心
Q1：云端环境部署好后,状态处于Notready,云端检测边缘端状态流程是怎样的？（k8s版本 1.15.0,docker -ce 1.18,ubuntu 最新版本）
A1：云端 检测边缘节点状态的工作流程：1. 边缘节点通过Edgehub->Cloudhub->EdgeController->KubeAPIserver将节点状态信息上报到K8s中。之后流程与K8s原生架构一致, 根据上报的状态信息,K8s通过原生的node-controller来设置node的状态。
云端环境部署好后,状态处于Notready,可能的情况是云边的通道（Cloudhub与Edgehub）通信失败,考虑网络地址或证书配置有问题。
Q2 ：能否简单对比KubeEdge与国内外的主流同类型平台产品
A2：
1 . 同类平台里的EdgeX Foundry偏重于端侧设备的管理,提供了一些设备接入、边缘数据传输等场景的实现,但不具备云上对边缘端的应用和设备的管控、云边协同等智能边缘系统的能力。
2 . K3s已在上节课中提到过,K3s选择的是在边缘运行整个K8s集群的方案,不具备云边协同的能力；其次K3s虽然对K8s做了轻量化,但整体资源要求仍然较高,无法运行在IOT Hub、工业网关等小型设备中**。**
3 . KubeEdge打通了云、边、端的整体流程：
· 用户能够在云上统一管理边缘节点上的应用、设备
· 提供了云边协同的能力,能够同步云边的应用、设备的数据
· 针对复杂多样的边缘设备,KubeEdge定义了一套通用的设备管理API（K8s CRD）以及设备协议解耦层,用户可以方便地使用KubeEdge在云上管理各种边缘设备
· 针对云边网络不稳定的情况,提供了云边数据协同的可靠性传输、边缘元数据持久化
· 针对边缘资源不足的情况,轻量化裁剪了Kubelet,支持在256MB的小型设备上运行
Q3 ：目前KubeEdge支持的设备是哪些？
A3：KubeEdge通过MQTT Broker将设备变化状态通过边缘节点上传到边缘节点再到云端。支持MQTT协议的设备可以直接接入到KubeEdge。
使用专有协议（非MQTT）的设备,可通过协议转换器Mapper将数据处理转成MQTT接入KubeEdge。目前KubeEdge针对工业设备场景在DeviceAPI中内置了Bluetooth、Modbus、OPC-UA三种常见通信协议的设备支持,减少了用户设备接入的准备工作。对于尚未内置的协议,用户也可参考KubeEdge给出的设备管理标准自行实现Mapper来接入边缘设备。
Q4 ：在KubeEdge中,有云、边、端,那端中软件服务有吗？有哪些？硬件又包括哪些设备呢？
A4 ：端的硬件、软件都由用户提供,只要满足KubeEdge的接入协议标准的设备,都可以接入到KubeEdge平台。
Q5 ：KubeEdge边缘端的容器监控,哪个版本能够支持？比如在云端执行：kubectl top 命令。
A5 ：目前已有规划支持边缘端基于cAdvisor的容器监控,预计在1.3版本（2020年Q1）中支持。
Q6 ：CSI的插件必须部署在云端吗？
A6 ： K8s社区推荐方案中使用DaemonSet部署的agent组件（node-registrar以及实际的存储后端）应该部署在边缘,而管理面组件（external-provisioner、external-attacher、KubeEdge-CSI-driver）要部署在云端。
Q7 ：KubeEdge的API调用方式,是否计划提供sdk调用方式？
A7 ：由于KubeEdge不屏蔽K8s APIserver,涉及原生功能的API可以直接使用K8s client-go调用,KubeEdge扩展的API,计划于1.3版本（2020年Q1）提供SDK
全开放的项目,完全包容的社区,等你来star和贡献,项目地址：
kubeedge/kubeedge
「深度学习福利」大神带你进阶工程师,立即查看>>>
自从 云桌面 出现到现在已经有十几年的时间了,按理说在这短短的十几年的时间里,云桌面就被应用于企业、学校、医院和房地产中介办公的各个行业,而且和传统PC相比具有维护方便、快速部署、数据安全可控以及使用成本低等特点,云桌面看起来明明还不错的,但是为什么还是有人觉得它坑的呢？
首先3D体验差,之所以有人觉得云桌面不好用和坑,很大一部分原因就是它的3D体验效果没有传统PC好的,云桌面对于大多数的应用来说是可以达到和传统一样的体验的,但是由于受当前技术和网络带宽等因素的影响,在处理3D应用时体验还是无法和传统PC相比的。而这也是很多人觉得云桌面坑和不好的一个重要原因。
其次没选对专业厂家,当我们在网上搜索云桌面时会有一大批的相关厂家出现的,然而在这么多的厂家真正专业的云桌面厂家并不是很多的,很多所谓的厂家只是销售公司的,构成云桌面主要部分的服务器、云终端和云桌面软件都不是自己研发生产的,而是有不同厂家组合而成的,这样就容易导致部署的时候造价高、兼容性不好和保修不知道找谁等一系列的问题。
第三期望值过高,企业上云是一种趋势,但是我们也不能对云桌面的期望过高和太过依赖它的,云桌面的功能是有很多优势也很明显,但是对于它的缺点也要认清的,云桌面并不是万能的,它并不能解决IT办公上的所有问题。也正是因为期望过高,加上部署的时候没有把握好,这就导致很多人觉得被忽悠了。
最后偏见导致,虽然说现在云桌面被越来越多的人所使用和喜爱,但是并不是所有的人都看好它的,有不少的用户对它还是有所偏见,所以在使用过程中只要是出现问题就觉得是它的问题,然后就各种吐槽说云桌面很坑的。
其实云桌面在短短的十几年发展到今天被各行各业所使用,并实现这么多的功能,可以说已经很不错的了,我们不能对它又太过高的要求的,毕竟云桌面也不是万能的。
来源禹龙云
「深度学习福利」大神带你进阶工程师,立即查看>>>
本文作者：yanxin1563 作者：MQA-sherryshare
前言
流畅度测试是客户端性能测试技术中一个深度领域,所以百度App给大家带来流畅度全流程质量监控实践的系列文章。
其中包含:
系列（一）流畅度现状分析,
系列（二）流畅度指标选取,
系列（三）流畅度线上线下监控实践,
系列（四）流畅度竞品评测方案。
希望对大家在流畅度性能测试方向的学习和实践有所帮助。
背景
为什么要关注流畅度？APP容易崩溃、网页新闻打不开等属于痛点问题,用户会投诉甚至卸载。经过不断的优化,提升稳定性、降低白屏率之后,这些痛点问题不那么痛时,我们就需要把关注目标集中到用户的“爽点”上来,影响爽点的典型问题之一就是——卡顿问题。
测试同学通过用户反馈分析,卡顿在不同业务场景下,对用户体验都存在影响,且部分情况用户情绪较差,但实际上case by case处理时,常因为线下无法复现、用户提供线索不足等原因不了了之,因此需要单独建立监控指标进行召回。
另一方面,随着高性能手机不断出现,为了提升用户交互体验,设计不再是简单的弹框或者加载的交互,动效等较“炫”的交互场景被更多的使用。带来高级感体验的同时,在低端机上会不会造成负担呢？会不会给人不仅不“炫”,反而卡的没法用的感觉呢？因此,我们亟需一套好的流畅度监控标准,来掌握高级交互和卡顿之间的平衡
业界流畅度监控方案调研（Android）
1. 基础流畅度概念介绍
1.1 理想帧率：
60FPS,受限于显示器的刷新频率60HZ
1.2 理想帧长：
1/60≈16.6ms
1.3 Vsync机制：
VSync 可以简单的认为是一种定时中断,系统在每次需要绘制的时候都会发送VSync Pulse 信号,cpu/gpu 收到信号后马上处理绘制。
2. 业界方案调研
3. 监控实现原理
3.1 统计帧长基于VSYNC：统计帧长、SM、SF：
Choreographer类就是接受系统垂直同步信号（VSync信号）,在每次接受VSync信号时顺序执行View的Input、Animation、Draw等3个操作,然后等待下一个信号,再次顺序执行3个操作。如果第二个信号到来时,Draw操作没有按时完成,界面将不会更新,显示的还是第一帧的内容。这就表示丢帧了,丢帧是造成画面卡顿的原因。所以我们可以向Choreographer类中加入自己的Callback,通过此Callback的doFrame函数我们可以统计一秒内帧绘制的次数（即流畅值SM ）、绘制耗时（两次doFrame之间耗时,即帧长）、丢帧SF。
3.2 基于Looper：
利用UI线程的Looper打印的日志匹配获取帧长。和VSYNC方案类似,只是当UI线程阻塞严重时,可能出现数据丢失。（对UI线程的影响也是一个待平衡点）
3.3 堆栈监控：
单开线程定期抓取堆栈,基于Vsync或者Looper机制监控到帧长超过指定阈值时,上传最近的堆栈。但由于单开线程实时抓堆栈,会导致应用本身性能退化,不适宜线上长期大面积使用。
3.4 监控注意事项（实测经验）:
实际测试中发现,APP静置时,尤其是网页静置时,SM值亦可能出现变低如接近30的情况,SF值、帧长均可能存在超过理想值的情况。原因是用户虽未对界面进行操作,亦可能在后台发生下载、屏幕显示区域之外的动画等行为,整体界面展现上表现不出卡顿,但可能会对用户肉眼感知不到的加载等造成影响。
——不同阶段、不同场景下,相同流畅度指标的绝对值,对用户实际体验的反应准确度有所不同,因此 建议区分场景和阶段进行监控。
参考资料 萧竹：Android App性能评测分析－流畅度篇 htkeepmoving：移动APP性能评测-流畅度评测 腾讯：【腾讯TMQ】GT3.1简化您的App性能测试（2）——原理讲解,溯本求源 微信读书：卡顿监控系统 腾讯perfdog：PerfDog性能狗帮助文档 whbsspu：为什么帧率达到60fps页面就流畅？ egos：Android中VSync机制的介绍 markzhai’s home：BlockCanary — 轻松找出Android App界面卡顿元凶(AndroidPerformanceMonitor)
原文链接地址： https://developer.baidu.com/topic/show/290493
「深度学习福利」大神带你进阶工程师,立即查看>>>
从德国的“工业4.0”到“中国制造2025”,世界经济舞台上的几大玩家正在制造业这一主战场,掀起没有硝烟的“智能化”升维战。
“智能制造”应该如何理解？ 以传统汽车制造业为例,消费者去4S店购买汽车,可选范围往往是批量生产下的“常规菜单”,选择有限。而在智能制造时代,消费者可以直接给汽车制造商下单,自主挑选外观颜色、发动机、音响、轮胎等几乎所有配置,柔性生产,最大程度实现个性化定制。且生产制造由智能机器和人类专家共同操作,过程中融入分析、推理、判断、构思和决策等智能化活动。不仅如此,整个制造过程并非由一家企业独自完成,而是由产业链上下游多个企业共同协作。
事实上,随着制造业分工的逐步精细化,协同生产已成为主流。很多产品生产者已不再是单个企业,而是众多企业所构成的“供应链体系”。为完成某项生产经营活动,企业不仅需要保证内部生产线,如生产决策、车间运转、库存的高效畅通,还需要与外部相配合,如上游原材料、零部件供应商,下游经销商、物流、消费者等,各参与方之间的联系越来越紧密、频繁。当参与方之间没有形成高效协同机制时,便会严重影响企业生产效率。例如,供应链各环节成员在做采购、生产决策之前都需要对需求进行预测,不准确的预测会导致库存增加、缺货严重及客户满意度下降。因此“链主”企业一般会与上下游企业分享包括预测、订单、库存在内的信息,提高预测准确性,同时与上下游企业进行协同计划和补货。严密的供应链协同体系对提高企业生产效率、产品质量、顾客满意度等有着重要影响。
随着制造业向智能制造升级, “供应链协同”成为制造企业的核心竞争力之一,更是关乎企业能否破题智能制造的关键所在 。
优化供应链协同,企业通常可以从三个方面入手： 组织层面 ,又分为内外部。外部而言,需要实现供应链上下游企业间物流、信息流、资金流的高效畅通,保持开放共赢心态,建立共识,彼此信任。内部,由于各部门责任和立场不尽相同,经常会发生内部受阻的情况。实现组织内协同,需要建立良好的沟通机制,自上而下同步战略,自下而上汇报信息。同时明确各部门职责边界,各司其职,提高组织效率； 业务流程层面 ,供应链涉及的流程众多,如商品建档、采购入库、退货、财务结算等,流程之间相互依存。实现业务流程协同需要确保流程设计的统一、通用、开放性,以提高流程对新业务、新场景以及三方业务的兼容性； 信息系统层面 ,信息系统是实现供应链协同的基石,没有信息系统支撑的供应链协同无法建立。智能制造时代,它需要服务于更智能的生产、管理、销售、售后、生态产业全链条,这对供应链信息化协同提出了更高要求：
1. 更精准掌握供应链运作情况,实现“透明化”管控。 这需要企业打通不同IT信息系统之间的孤岛,建立高效的信息交互管道。供应链上下游参与方众多,涉及企业内外部大量IT系统,如ERP（企业资源计划系统）、MES（制造执行系统）、SCM（供应链管理系统）等。业务交互需要通过系统之间的接口来实现,但大部分企业内部IT系统缺乏规范化统一集成和透明化管控。企业往往面临接口不规范、数量不详、运行状态不清晰等缺乏管控的问题,数据交互、连接、同步速度慢、稳定性差,集成效率低。
2. 提高业务响应速度。 供应链各环节业务繁杂交错,需要多方沟通配合时,原有沟通方式（如电话、邮件等）效率低,导致上下游需求响应速度慢,企业制造流程慢、耗时长,严重影响企业的业务响应速度。
3. 节省IT投入,降低对原厂依赖。 企业IT服务采购费用高,每年涉及对系统升级和接口开发,都需要向供应商采购IT服务。随着人员工资提升,IT服务采购费用也逐年增加。同时,由于这些IT系统往往由不同厂商提供,接口标准不统一、复用性差,企业对原厂依赖性极强。企业内部IT人员需要重复开发,压力大,任务重,亟需降低供应链服务成本和管理便捷化的第三方服务。
作为传统制造升级智能制造的关键一环,企业需要对其IT系统进行全局性升级,改变集成模式和交付模式,更敏捷、高效地服务于传统制造到智能制造的转型升级。
天正电气以“让电力能源更安全、更高效、更智慧地造福人类”为宗旨,近年来紧跟制造业趋势,全力转型智能制造。 “供应链协同”是天正电气智能制造主干项目 , 借助白山云科技 “数聚蜂巢”API中台 ,在短时间内搭建起一个轻量化、具有前瞻性的集成平台,实现对IT信息系统接口统一规范管理,极大改善了天正电气供应链协作效率。
作为一个轻量级数据应用混合集成平台,数聚蜂巢API中台基于API化解耦、微服务化、能力化的三层架构设计理念,依托 API管理平台 与 集成编排平台 构成的底层基础,有效促成企业系统解耦、重组业务逻辑与流程,方便快速地实现数据、应用、服务间的灵活流转与敏捷集成。企业由此具备更强的IT输出能力,提升资源复用性与交付效率,助力业务敏捷创新。
基于API三层架构的数聚蜂巢
使用数聚蜂巢API中台之前,天正电气在系统集成过程中,接口方式仅限于内部系统使用,且方式单一,第三方系统接入困难；内部一些有价值、复用性强、可以带来收益的数据,亟需对外提供服务的渠道；基于老系统架构的数据同步、数据交换效率低,易出错,对IT人员造成很大压力,成为经营效率提升和业务创新的障碍；随着运行时间增长,系统对人的依赖越来越强,若相应技术人员离职,则会面临业务无人懂、不敢动,对企业造成困扰。
数聚蜂巢API中台的使用,成功为天正电气供应链协同项目的建设提供了新思路,打开了不一样的局面。
1. 集成编排,打通核心业务系统,实现供应链各环节纵向一体化。 数聚蜂巢首先通过构造标准API接口的方式打通天正电气供应链条上各系统,包括APS（进阶生产规划及排程系统）、SRM（供应商管理系统）、ERP（企业资源计划系统）、BPM（业务流程管理系统）、CRM（客户全生命周期智能化管理系统）等,提高了系统间数据交互、对接、同步的效率,百万数据量同步耗时从过去1小时以上提高到7分钟左右,同时降低对系统原厂的依赖,保证接口使用稳定持续。
依托数聚蜂巢集成编排平台,将解耦后的IT能力根据新的业务逻辑进行编排重组。通过资源复用,实现敏捷开发,交付效率加快,可以快速满足新业务需求,缩短制造流程时间,推进智能制造深入开展。
2. API全生命周期管理,实时监控供应链中核心信息化资产的运行情况。 API全生命周期管理提供API设计、创建、测试、部署、集成、管理、运维、下线等一站式服务。通过API全生命周期管理,实时掌握数据使用情况,洞察企业内资源价值,助力企业全方位构建管理API资产。
API管理平台上,所有接口的运行状态全景展示,企业可对接口调用情况、调用频次、健康状况及日志等信息随时查看,随时管理。目前通过API管理平台统一构建和管理的API已超过190个,明显提升了天正电气供应链各方沟通协作效率。
访问量数据统计信息
此外,数聚蜂巢提供API Portal用于统一展示API资源,企业可将自主构建的业务服务封装为API统一发布到门户上。API Portal支持API调用申请、审批、授权等操作,并且,API管理者还可根据实际情况对API制定相应访问策略；API消费者在门户上申请自己需要访问的资源,对外提供服务。通过API Portal可方便快速构建以天正电气为核心的产业生态体系。
同时,对API进行权限管控,实现业务隔离。针对API能力、API来源、API归属和主要服务对象划分不同的业务隔离等级。根据使用者角色和身份的不同,赋予不同接口访问权限。方便管理的同时,实现API对指定使用者的定向开放,同时预防错误调用接口,更好实现协同。
3. 开放能力,助力营销智能化,实现数字化业务创新。 智能营销也是企业智能制造的核心命题,“企业信息化,信息条码化”在国家“物联网十二五规划”中有明确体现,是实现两化融合必经之路。数聚蜂巢通过构建条码与后端调用能力API接口,服务前端出口,实现“一物一码”,终端消费者可通过扫描商品二维码获取实时信息,特别是营销类商务信息。以创新服务体验提高消费者黏性和满意度,这是天正电气向智能营销模式转变的新尝试。
4. 简单易用,敏捷赋能IT人员,降低企业IT成本。 天正电气对系统应用有着战略层面的全局规划,对未来创新业务场景也更希望由内部IT团队和业务人员直接对接,这不仅会大幅加快交付速度、提高沟通效率,而且交付的服务将更贴近企业需求。当后续业务变化时也能快速调整,不再受制于第三方供应商和商务谈判等不可控因素。
作为一款便捷易学、可快速上手敏捷交付的系统集成和服务交付平台,数聚蜂巢恰好满足天正电气这一需求。通过一段时间的现场培训和远程技术支持,天正电气内部IT人员已熟练掌握平台使用,可自行操作,快速交付业务。截至目前,基于数聚蜂巢API中台,天正电气依靠内部IT团队已自主集成多个业务系统,构造了100多个业务相关接口服务与新应用交付,不仅大幅提高效率,还极大降低了企业IT服务采购成本。
制造业升维竞争的命运之战已经打响。数聚蜂巢作为一款服务于企业数字化转型的API中台,以现代API架构风格为突破点,为企业升级智能制造提供了强劲动力。正如 天正电气CIO李书育 所言：“ 打造敏捷高效的供应链协同体系,是企业向智能制造转型的必经之途。数聚蜂巢为天正电气供应链协同项目建设提出行之有效的解决方案,为我们攻克了升级智能制造的‘第一关’。 ”
截至目前,数聚蜂巢已收获包括天正电气、万达集团、利星行机械、参天制药、新东方、中船重工、广汇汽车等在内的数十家客户,覆盖政务、制造、地产、零售、教育、医药、能源等各领域。
天正电气简介
浙江天正电气股份有限公司（简称“天正电气”）主要生产以低压配电及工控电器、智能仪表、电源电器、变频器、高压电器、建筑电器为主的工业电器产品,为电力、通讯、新能源、工民建、冶金、石化、机械制造等行业提供优质的低压电器产品和解决方案。在全国范围内,天正电气拥有5000多家销售网点,已为上海世博会、西气东输、京沪高铁、海磁悬浮、西昌卫星发射中心、三峡工程等国内重点工程及电力自动化、成套厂、电力部门提供产品和服务,产品畅销全国各省市,并出口到俄罗斯、东南亚等多个国家和地区。
「深度学习福利」大神带你进阶工程师,立即查看>>>
作者 | 徐迪、张晓宇 导读 ：本文根据徐迪和张晓宇在 KubeCon NA 2019 大会分享整理。分享将会从以下几个方面进行切入：首先会简单介绍一下什么是 Sidecar 容器；其次,会分享几个阿里巴巴经济体的通用场景,以及他们是如何解决这些挑战的。
Sidecar 简介
Sidecar 容器并不是一个新鲜事物。它是一种设计模式,主要用来做一些辅助的工作,比如网络连通性、下载拷贝文件之类的事情；如果大家熟悉 Docker Swarm 的话,就会发现 Docker Ambassador 其实就是 Sidecar。
如上所示,Service Consumer 和 Redis Provider 强耦合,部署在同一个节点上。如果这个时候,Redis Provider 出现问题,需要连接到另外一个 Redis 实例上,需要重新配置,并重启 Service Provider。
那么在引入了 Ambassador 以后,问题变得相对简单些,只需要重启这里的 Redis Ambassador 即可,并不需要 Service Consumer 进行任何变动。
当然这种模式,还可以进行跨节点通信,比如下图。这样 Service Consumer 和 Redis Provider 就可以部署在不同的节点上。在某种程度上,很容易地就将两种服务进行了解耦。
Sidecar 案例分享
1. Sidecar 容器能用来干什么？
一般来讲,Sidecar 容器可以： 日志代理/转发,例如 fluentd； Service Mesh,比如 Istio,Linkerd； 代理,比如 Docker Ambassador； 探活：检查某些组件是不是正常工作； 其他辅助性的工作,比如拷贝文件,下载文件等；
2. 仅此而已？
事实上,Sidecar 越来越被大家接受,并且使用越来越广泛。Sidecar 容器通常和业务容器（非 Sidecar 容器）部署在同一个 Pod 里,共享相同的生命周期,为业务容器提供辅助功能。这是一个非常好的模式,能够极大程度解耦应用,并且支持异构组件,降低技术壁垒。
但目前 Kubernetes 对 Sidecar 的管理还不完善,越来越不满足我们的使用,尤其是在生产环境中使用 Sidecar。
3. 几个典型案例
顺序依赖
假设我们在一个 Pod 内注入了多个 Sidecar,但是 Sidecar 之间或者 Sidecar 和业务容器之间有相互依赖关系。如下这个例子,我们需要先启动 proxy Sidecar 容器用于建立网络连接,这样 mysql client 才能连接到远端的 mysql 集群,并在本地暴露服务。而后主的业务容器才能正常工作。 #1 proxy_container (sidecar) #2 mysql_client #3 svc_container
当然,有的人会觉得这个地方,可以通过诸如更改镜像启动脚本延迟启动等方法来解决。但是这些方法侵入性太强,不利于扩展,还很难进行准确的配置。
Sidecar 管理
我们来看看另外一个案例。Sidecar 容器和业务容器耦合在同一个 Pod 内,共享相同的生命周期。因此,单独来管控 Sidecar 容器非常不方,比如更新 Sidecar 的镜像。
比如,我们已经给很多 Pod 注入了 Istio Proxy 这样的 Sidecar 容器,目前运行状态良好。但是如果这个时候我们想升级这个 Proxy 镜像的话,该怎么办？
如果按照 Istio 社区官方的文档 ,我们需要重新注入这些 Sidecar 容器。具体来说,需要删除原有 Pod,重新生成一份新的 Pod（有些 workload 关联的 Pod,会由相应的 workload 控制器自动生成）。
那如果我们有很多个这样的 Pod 需要处理的话,怎么办？通过命令行的话,太不方便,而且容易出错。通过自己单独写的代码的话,可扩展性是个问题,需要频繁更改这些代码。
而且这里还有另外一个问题,我们肯定不会一下子升级所有的 Sidecar,肯定要有个灰度的过程,也就是只升级一部分 Sidecar,这个时候又该怎么办呢？
社区进展
1. 上游社区
这里我们非常感谢 Joseph Irving (@Joseph-Irving) 提出了一个 Sidecar kep ,通过定义 LifecycleType 来区分是否是 Sidecar 容器。
未来只需要在 Pod Spec 中,按如下方式标记即可： name: sidecarContainer image: foo lifecycle: type: Sidecar
Pod 内容器的启动顺序按照：初始化容器->Sidecar 容器->业务容器 的顺序依次启动。
其中上述 kep 的 kubelet 端实现 正在进行中。
为了支持 Sidecar 更多的使用场景,我们以此为基础提出了 PreSidecar 和 PostSidecar,分别用于在业务容器之前和之后启动。
具体的使用场景见 我们的 PR 。
为什么我们觉得 Sidecar 应该区分前置和后置呢？
这是因为在一些场景下,我们需要 Sidecar 容器优先于应用容器启动,帮助做一些准备工作。例如分发证书,创建共享卷,或者拷贝下载一些其他文件等。
而在另外一些场景下,我们需要一些 Sidecar 容器在应用容器之后启动。考虑到解耦和版本管理的因素,我们将应用分为两部分,应用容器专注于业务本身,而一些数据和个性化的配置放在 Sidecar 容器中。通常情况下,这两个容器将会共享一个存储卷,后置的 Sidecar 容器会更新替换掉一些默认和过时数据。
当然考虑到未来更复杂的场景,我们可能还会对容器的启动顺序做 DAG 编排,当然这个需要视生产实际需要而定。
2. 蚂蚁金服及阿里巴巴如何应对
为了解决 Sidecar 的管理工作,我们需要一个更细粒度的 workload 方便我们进行管理。这个 workload 我们命名为 SidecarSet,目前已经开源,生产可用。大家可以访问 OpenKruise 这个项目,可以在项目的 roadmap 里了解我们目前的一些新进展。OpenKruise 这个项目目前有三个生产可用的 workload,分别是 Advanced StatefulSet、BroadcastJob、SidecarSet。另外2个 workload（AdvancedHPA 和 PodHealer）正在加紧开发中, 很快会开源出来,敬请期待。相关使用 Demo,大家可以观看 Lachlan Evenson 的 尝鲜视频 。
spec 中的 SidecarContainer 的定义就是 Kubernetes 代码库中的 corev1.Container 定义。通过额外的一个 labelSelector,可以很方便地对指定的容器组进行操作。我们支持滚动升级（RollingUpdate）的方式,让用户可以分批的升级 Sidecar,同时也提供了 pause 功能,可以在紧急情况下暂停 Sidecar 的升级。
如果只是简单升级 Sidecar 的镜像, SidecarSet 控制器仅仅会 patch 原有 pod 的,非常方便的就可以一键升级镜像。
其他的挑战
我们在生产实践过程中,还发现了一些其他的挑战,目前还在寻找比较好的解法。
1. Sidecar 容器的资源管理
一般来讲 Sidecar 容器占用的资源都比较小,那么这个资源要不要计算到整个 pod 当中？还是可以直接共享业务容器的资源即可？相同的 Sidecar 在和不同的应用容器搭配使用,如何准确给 Sidecar 容器分配资源这些都需要进行考虑。
2. Sidecar 容器的容错性
一般来讲,Sidecar 容器都是非主要容器,那么这类容器出现问题时,比如 liveness 探活,要不要对主容器的状态或者整个 pod 的状态也产生影响。再或者,Sidecar 镜像更新出现问题时,要不要直接标记整个 pod 出现问题。当然,还有一些其他的挑战,我们只是列举了几个通用的。对于这些挑战,我们需要大家一起集思广益,找到比较合理的解法。
小结
随着 Sidecar 在生产环境使用越来越广泛,对其的管理愈发需要重视。Sidecar 虽然和业务容器部署在同一个 Pod 内,但是其本质上只是辅助性的容器。本文介绍了目前 Sidecar 的典型使用案例,以及面临的挑战,同时跟上游社区一起合作,将阿里经济体的技术解决方案在社区落地,帮助更多的用户.
作者简介： 徐迪 蚂蚁金服技术专家：负责蚂蚁金融云 PaaS 平台建设,Kubernetes 社区老兵,核心代码库贡献量社区前50； 张晓宇 阿里云技术专家：负责阿里巴巴云原生应用容器平台的生态建设,主要设计和研发节点稳定性和资源利用率相关解决方案,同时也是 Kubernetes 社区热心的成员和贡献者。 “ 阿里巴巴云原生 关注微服务、Serverless、容器、Service Mesh 等技术领域、聚焦云原生流行技术趋势、云原生大规模的落地实践,做最懂云原生开发者的技术圈。”
「深度学习福利」大神带你进阶工程师,立即查看>>>
前言
在分布式高并发服务器中,client到server以及server中的多个节点之间的连接往往使用连接池来管理。简单来说就是将提前创建好的连接保存在池中,当有请求到来时,直接使用连接池中的连接对server端访问,省去了创建连接和销毁连接的开销(TCP建立连接时的三次握手和释放连接时的四次挥手),从而提高了性能。
目录 设计原则 基本原理 GRPC特性 GRPC调优 实现细则 延伸阅读
设计原则 连接池的扩缩容 空闲连接的超时与保活 池满的处理机制
连接池的扩缩容
通常连接池属性包含最大空闲连接数和最大活跃连接数。
最大空闲连接数 ：连接池一直保持的连接数,无论这些连接被使用与否都会被保持。如果客户端对连接池的使用量不大,便会造成服务端连接资源的浪费。
最大活跃连接数 ：连接池最多保持的连接数,如果客户端请求超过次数,便要根据 池满的处理机制 来处理没有得到连接的请求。
扩容 ：当请求到来时,如果连接池中没有空闲的连接,同时连接数也没有达到最大活跃连接数,便会按照特定的增长策略创建新的连接服务该请求,同时用完之后归还到池中,而不是关闭连接。
缩容 ：当连接池一段时间没有被使用,同时池中的连接数超过了最大空闲连接数,那么便会关闭一部分连接,使池中的连接数始终维持在最大空闲连接数。
空闲连接的超时与保活
超时 如果连接没有被客户端使用的话,便会成为空闲连接,在一段时间后,服务端可能会根据自己的超时策略关闭空闲连接,此时空闲连接已经失效,如果客户端再使用失效的连接,便会通信失败。为了避免这种情况发生,通常连接池中的连接设有 最大空闲超时时间 (最好略小于服务器的空闲连接超时时间),在从池中获取连接时,判断是否空闲超时,如果超时则关闭,没有超时则可以继续使用。
保活 如果服务器发生重启,那么连接池中的连接便会全部失效,如果此时再从池中获取连接,不论获取到哪一个,都将通信失败。因此,连接池必须考虑连接的保活问题,有两种解决方法：
1、连接池设置一个Ping函数,专门用来做连接的保活。在从池中获取连接的时候,Ping一下服务器,如果得到响应,则连接依然有效,便可继续使用,如果超时无响应,则关闭该连接,生成新的连接,由于每次都要Ping一下,必然会增加延迟。也可以后台用一个线程或者协程定期的执行Ping函数,进行连接的保活,缺点是感知连接的失效会有一定的延迟,从池中仍然有可能获取到失效的连接。
2、客户端加入相应的重试机制。比如重试3次,前两次从池中获取连接执行,如果报的错是失效的连接等有关连接问题的错误,那么第3次从池中获取的时候带上参数,指定获取新建的连接,同时连接池移除前两次获取的失效的连接。
池满的处理机制
连接池不可能无限的容纳连接,当池满时,有两种处理机制：
1、池新建连接,并返回给客户端,当客户端用完时,如果池满则关闭连接,否则放入池中。
2、设置一定的超时时间来等待空闲连接。需要客户端加入重试机制,避免因超时之后获取不到空闲连接产生的错误。
基本原理 服务启动时建立连接池。 初始化连接池,建立最大空闲连接数个连接。 请求到来时,从池中获取一个连接。如果没有空闲连接且连接数没有达到最大活跃连接数,则新建连接；如果达到最大活跃连接数,设置一定的超时时间,等待获取空闲连接。 获取到连接后进行通信服务。 释放连接,此时是将连接放回连接池,如果池满则关闭连接。 释放连接池,关闭所有连接。
GRPC特性
关于GRPC的介绍,不在这里阐述,可阅读 深入了解GRPC协议 ,也可自行Google。这里主要简要说明GRPC的两个特性：多路复用、超时重连。
多路复用 GRPC使用HTTP/2作为应用层的传输协议,HTTP/2会复用底层的TCP连接。每一次RPC调用会产生一个新的Stream,每个Stream包含多个Frame,Frame是HTTP/2里面最小的数据传输单位。同时每个Stream有唯一的ID标识,如果是客户端创建的则ID是奇数,服务端创建的ID则是偶数。如果一条连接上的ID使用完了,Client会新建一条连接,Server也会给Client发送一个GOAWAY Frame强制让Client新建一条连接。一条GRPC连接允许并发的发送和接收多个Stream,而控制的参数便是 MaxConcurrentStreams ,Golang的服务端默认是100。
超时重连 我们在通过调用Dial或者DialContext函数创建连接时,默认只是返回ClientConn结构体指针,同时会启动一个Goroutine异步的去建立连接。如果想要等连接建立完再返回,可以指定grpc.WithBlock()传入Options来实现。超时机制很简单,在调用的时候传入一个timeout的context就可以了。重连机制通过启动一个Goroutine异步的去建立连接实现的,可以避免服务器因为连接空闲时间过长关闭连接、服务器重启等造成的客户端连接失效问题。也就是说通过GRPC的重连机制可以完美的解决连接池设计原则中的空闲连接的超时与保活问题。
以Golang的GRPC客户端为例：
GRPC调优
GRPC默认的参数对于传输大数据块来说不够友好,我们需要进行特定参数的调优。
MaxSendMsgSize GRPC最大允许发送的字节数,默认4MiB,如果超过了GRPC会报错。Client和Server我们都调到4GiB。
MaxRecvMsgSize GRPC最大允许接收的字节数,默认4MiB,如果超过了GRPC会报错。Client和Server我们都调到4GiB。
InitialWindowSize 基于Stream的滑动窗口,类似于TCP的滑动窗口,用来做流控,默认64KiB,吞吐量上不去,Client和Server我们调到1GiB。
InitialConnWindowSize 基于Connection的滑动窗口,默认16 * 64KiB,吞吐量上不去,Client和Server我们也都调到1GiB。
KeepAliveTime 每隔KeepAliveTime时间,发送PING帧测量最小往返时间,确定空闲连接是否仍然有效,我们设置为10S。
KeepAliveTimeout 超过KeepAliveTimeout,关闭连接,我们设置为3S。
PermitWithoutStream 如果为true,当连接空闲时仍然发送PING帧监测,如果为false,则不发送忽略。我们设置为true。
实现细则
代码： https://github.com/shimingyah/pool
基于GRPC的多路复用、超时重连特性,我们很容易实现GRPC连接池。
接口设计
提供简洁的Pool和Conn的接口设计。
连接复用
GRPC是支持多路复用的,所以在设计GRPC池的时候和其他连接池区别之一是支持连接复用,通过 MaxConcurrentStreams 控制,默认64。我们称单个的GRPC为 物理连接 ,复用的连接为 逻辑连接 。池的实际有效连接 逻辑连接 = 物理连接 * MaxConcurrentStreams 。
扩缩容
扩容 初始化池的有效连接数(逻辑连接)为： 最大空闲连接数 * MaxConcurrentStreams ,每一次请求都会对池的引用计数原子++,同时hash求取选取连接,当引用计数超过逻辑连接数时,就需要进行扩容了,如果最大空闲连接没有达到最大活跃连接数,则按照double的方式扩容,如果达到了最大活跃连接数,我们会根据Reuse参数的值来做进一步操作：如果为true,则继续使用池中的连接,即使用的是物理连接的逻辑连接,关闭连接时,对引用计数原子--即可,如果为false,则新建连接,关闭连接时还需要对连接进行真正的Close。
缩容 如果池的引用计数为0时,便会触发缩容操作,是连接维持到最大空闲连接数。
超时保活
基于GRPC的Keepalived特性,我们不需要自己实现保活机制,也无需关注连接池中的连接是否有效,因为就算失效,GRPC会自动重连的,此时只不过耗时会略微增加,即认为除了服务器一直处于down状态等原因,连接池中的连接是始终有效的。
Tips 由于使用hash求余,每个GRPC上并发的Stream可能会超过MaxConcurrentStreams。 不同场景对应的连接池配置也不一样,需要根据自己的场景压测得出连接池的最佳参数配置。
作者：史明亚 现在注册滴滴云,有机会可得30元无门槛滴滴出行券 新购云服务1月5折 3月4折 6月低至3折 滴滴云使者招募,推荐最高返佣50%
「深度学习福利」大神带你进阶工程师,立即查看>>>
2019年11月14日视频直播了KubeEdge系列课程的第一课《KubeEdge架构与核心技术》,课程首先介绍了云原生、边缘计算的发展历程,从持续狂热的Kubernetes到飞速发展的边缘计算。再针对边缘计算网络不稳定、资源有限等条件下,分析了KubeEdge项目如何将云原生生态的众多标准与优势带到边缘计算。包括在K8s的应用编排、调度能力之上,构建的云边协同、边缘自治、应用管理、设备管理等能力。
本次课程的回放地址：
媒体中心huaweicloud.bugu.mudu.tv
课后如下问题讲师进行了详细解答：
Q1 ：KubeEdge云和边的数据协同有什么优势？
A1 ： K8s的原生架构中, Node (Kubelet) 是通过List-watch机制主动与Master通信。 List-watch机制有几个特点：
1.事件传输没有ACK类的校验机制,要依赖数据中心稳定的网络保证不丢事件
2. 每次网络断开,Node侧都会从新执行List操作(取回所有数据),要依赖数据中心稳定的网络保证长连接不频繁断开,否则对Master及网络都是很大的损耗。
在边缘场景下,众所周知网络都是很不稳定的,包括丢失数据、连接断开等。 针对不稳定的网络,在KubeEdge云边协同的设计中：
1. 我们把List-watch中的事件取出来,加了ACK校验机制,只有边缘收到数据且回复ACK信息,云端才认为发送成功,反之则进行重试。
2. 在网络断开(确认节点离线)后,云端会将待同步数据持久化,等到边缘节点上线,再将缓存的待发送数据逐一下发,3. 针对未发送的消息实时检查合并去重,避免网络震荡。
KubeEdge的云边协同机制不仅保证了云和边之间数据的可靠传输,也避免了网络不稳定时重新List造成的网络压力。
Q2 ：KubeEdge目前是如何解决边缘节点自治能力的？
A2 ： KubeEdge会边缘将收到的应用、设备元数据都进行本地持久化。相比Kubelet在内存中缓存对象的方式,可以有效保证节点离线、故障恢复时的业务自治和快速自愈。
Q3 ：边缘节点离线后,依赖数据多次变更,边缘应用和云端数据的最终一致是怎么保证的？
A3 ： KubeEdge目前的应用管理等操作都需要通过K8s master进行,针对边缘节点离线场景主要提供自治的能力,既本地持久化的数据仅用于管理节点上的应用和设备,云边通信恢复时,节点将同步云依据来自CloudCore的最新消息更新本地元数据。这里稍有不同的是边缘设备管理,对设备期望状态的设置需要通过Device CRD中的Desired State来操作（从云到边）,而设备实际状态的上报会体现在Reported State中（从边到云）,两个方向的数据同步不会冲突。
Q4 ：KubeEdge与K3s的区别是什么？
A4 ： 首先是架构选型问题,K3s选择的是在边缘运行整个K8s集群的方案,不具备云边协同的能力；其次K3s虽然对K8s做了轻量化,但整体资源要求仍然较高,无法运行在IOT Hub、工业网关等小型设备中。
KubeEdge针对边缘场景的优化包括：
1. 针对边缘网络不稳定的情况,增加了云边数据协同的可靠性传输、边缘元数据持久化,减少了网络不稳定造成的压力震荡,实现了边缘离线自治的能力,在云边断联、节点故障恢复时保证业务不受影响。
2. 针对边缘资源不足的情况,对Kubelet进行轻量化裁剪,支持在256MB的设备上运行。
3. 针对复杂多样的边缘设备管理,KubeEdge定义了一套通用的设备管理API（K8s CRD）以及设备协议解耦层,用户可以方便地使用KubeEdge进行管理各种边缘设备。
Q5 ：中心K8s对边缘节点的管理主要操作有哪些？
A5 ： KubeEdge运行在K8s完整的应用调度、管理能力之上,意味着KubeEdge的云端不负责应用的调度、管理,只是将调度到边缘节点的应用、设备元数据下发到边缘。KubeEdge在云端的核心组件是CloudCore,包含 EdgeController、DeviceController、CloudHub 三个模块,EdgeController、DeviceController负责将应用、设备元数据下发到边缘,同时将来自边缘的节点状态、应用状态、设备状态刷新到K8s集群中；CloudHub负责直接与边缘通信。
Q6 ：新版本边缘节点的service还是仅支持hostPort吗,nodeport是否支持？
A6 ： 从KubeEdge 1.1版本开始集成了CRI,意味着用户可以使用CNI插件来配置网络,不再限制于hostport。NodePort是K8s中服务访问的概念,需要通过Kube-proxy来配置,目前在边缘端还不支持。另外KubeEdge提供了EdgeMesh实现边缘应用间的互访。
Q7 ：边缘节点的Docker容器镜像是从整个云-边k8s系统统一的镜像仓库拉取的吗？
A7 ： 只要边缘端能够访问到的镜像仓库,都能够用来拉取镜像。
Q8 ：PPT里提到"KubeEdge 用于将容器化应用程序编排功能扩展到Edge的主机。" 那么,是把云上的应用下沉到edge、还把终端设备上的应用提升到edge呢？
A8 ： KubeEdge作为应用管理平台时,可以在云端统一管控,既可以把应用部署到云端节点,也可以部署到边缘节点。用户可以根据自身需求,将云端的部分业务下沉到边缘。如果需要将终端设备上的应用部署到边缘节点,也可以通过KubeEdge来部署。
Q9 ：边缘侧的各个应用是怎么通信的？比如一个做sql过滤的应用和另一个做数据分析的应用是通过hub统一转发的,还是应用间就同步了,亦是通过mqtt等协议？同步异步消息分别怎么实现的？
A9 ： 目前KubeEdge中使用EdgeMesh机制来做边缘端应用的互访,不需要通过hub与mqtt转发,在EdgeMesh实现应用互通的前提下,同步异步消息依赖用户应用自身的机制。
Q10 ：KubeEdge节点和普通节点都在 kubectl get node 中获取到,这两者有什么区别？
A10 ： 没有本质区别,KubeEdge的边缘组件会将Node通过云边协同通道注册到K8s Master,唯一的不同是普通节点由Kubelet直接访问Master完成节点注册,KubeEdge是通过云边协同通道注册,API都是一致的。
Q11：KubeEdge的 modbus协议是用什么设备调试的？
A11： 目前开发调试中使用modbus slave来调试。
Q12 ：KubeEdge的安全层是怎么做的？
A12 ： KubeEdge云边协同使用了安全的WebSocket通道。对于应用间的安全互访要依赖用户自己配置安全证书等。
Q13 ：KubeEdge边缘节点能管理GPU设备吗？
A13 ： 边缘节点可以通过DevicePlugin来管理GPU设备。
项目的地址（欢迎Star、Folk,各种Issue、PR）：
kubeedge/kubeedge
「深度学习福利」大神带你进阶工程师,立即查看>>>
北京时间9月17日,KubeEdge发布了新的特性版本v1.1。
在上个版本发布EdgeMesh、EdgeSite等特性后,KubeEdge持续保持高速的迭代开发,本次发布的v1.1新版本包含了 容器存储标准CSI集成、对象校验组件Admission Webhook、单机一键启动KubeEdge集群工具、边缘节点支持DockerShim、升级Kubernetes依赖到v1.15 Stable版本,以及25处问题修复。
Release下载地址： https://github.com/kubeedge/kubeedge/releases/tag/v1.1.0
接下来本文将逐一解读KubeEdge v1.1的新特性。
KubeEdge项目背景
KubeEdge即Kube+Edge,顾名思义就是依托K8s的容器编排和调度能力,实现云边协同、计算下沉、海量设备的平滑接入。
**KubeEdge架构上分为三个部分,分别是云、边、端三侧。**云端负责云上应用和配置的校验、下发,边缘侧则负责运行边缘应用和管理接入设备,设备端运行各种边缘设备。KubeEdge完整的打通了边缘计算中云、边、设备协同的场景,整体架构如下图。
云端组件包括CloudCore、Admission Webhook ,它们构建在K8s的调度能力之上,100%兼容K8s原生API,可以运行在任何K8s集群中,包括各厂商的K8s产品、用户在云上自建的K8s集群等。CloudCore中主要包含EdgeController、DeviceController、CloudHub三个模块。 EdgeController、DeviceController 即K8s传统意义中的控制器,负责与边缘侧应用、设备元数据的同步。 CloudHub 负责与边缘侧直接通信。
**边缘侧组件包括EdgeCore及接入设备的Mappers。**Mappers负责接入边缘设备,EdgeCore负责边缘应用与设备管理,其模块主要包括EdgeHub、Edged、设备信息管理模块,应用与设备信息持久化模块。 EdgeHub 负责与云端直接通信。 Edged 是边缘侧负责应用生命周期管理的模块,它是裁剪过的Kubelet,在保留上游核心功能的基础上,又满足边缘侧轻量化的需求,其API与Kubelet完全兼容。 设备信息管理模块 主要通过MQTT协议与接入到边缘端的设备交互。 应用与设备信息持久化模块 负责将应用与设备元数据持久化到本地的SQLite数据库中,以在边缘断网的情况下实现边缘自治。
01 容器存储标准CSI集成
边缘侧运行的程序经常有存储数据的需求,例如边缘的视频收集分析程序,需要将视频信息保存下来。KubeEdge在提供了ConfigMap、Secret、HostPath、Emptydir、Downwardapi及Projected这些Volume的基础上,在v1.1版本中又集成了容器存储接口CSI,使得用户可以使用K8s标准的存储方案,如StorageClass（SC）,PersistentVolume（PV）和PersistentVolumeClaim（PVC）在边缘侧存储数据,整体架构如下：
其中蓝色部分为复用的Kubernetes-CSI组件,包括External-Provisioner、External-Attacher、Node-Driver-Registrar、CSI Driver from Vendor,主要负责在云上监听K8s的PV、PVC、VolumeAttachment等资源。黄色部分为KubeEdge中新添加的模块,包括CSI Driver from KubeEdge、UDS Server、Managers in Edge Controller、CSI Volume Plugin(In-Tree),主要负责将存储信息同步到边缘侧,以及调用外部插件来管理存储卷。
02 对象校验组件Admission Webhook
随着越来越多的资源对象如Device、DeviceModel等加入到项目中,KubeEdge需要对它们进行校验。v1.1发布了对象校验组件Admission Webhook,目前主要负责对Device、DeviceModel对象的校验。未来还会对Pod进行校验、修改,保证Pod在边缘的运行以及控制离线场景下的迁移等。
Admission Webhook采用容器化形式部署,用户只需以Pod的形式运行新版本的镜像即可。
03 单机一键启动KubeEdge集群工具
v0.3版本中发布了一键部署工具KubeEdge Installer（keadm）,它包含Cloud和Edge两类子命令,Cloud端的命令负责安装一个Kubernetes集群和CloudCore。Edge端的命令负责初始化一个边缘节点并加入到KubeEdge管理面。KubeEdge Installer可以在实际生产场景中部署KubeEdge。
v1.1提供的一键启动KubeEdge集群工具,可将完整的KubeEdge集群运行在一台机器上。用户只需运行该脚本,即可在一台机器上运行一个KubeEdge集群,方便开发者调测。它使用Kind运行一个K8s集群,将KubeEdge相关的组件运行在一台机器上,可以方便地用于开发测试、CI测试等。
https://github.com/kubeedge/kubeedge/blob/master/hack/local-up-kubeedge.sh
04 边缘节点支持DockerShim
v1.0版本中在边缘侧添加了对CRI接口的支持,使得用户可以在边缘侧使用多种运行时,包括Containerd、Cri-o等。v1.1版本中,为了使用户可以直接使用Docker,且与K8s上游社区保持一致,在边缘侧添加了对DockerShim的支持。
05 其他修改
v1.1将K8s依赖升级到了v1.15 Stable版本,Edged对应的K8s版本也升级到了v1.15,用户可以在边缘侧享用最新版K8s的应用管理、存储管理等能力。
v1.0版本的EdgeMesh只支持REST协议,由于K8s的Service原生是L4的,且应用场景非常广泛。在v1.1中EdgeMesh提供了L4 Proxy的能力。
结语
随着v1.1版本的发布,KubeEdge提供了更完备的边缘应用生命周期管理以及设备管理能力,更加友好的社区贡献者体验,感谢每一位为社区做过贡献的贡献者。后续版本将进一步提升云边协同的效率、可靠性,更多的边缘设备协议支持。更多详情请关注：
项目官网： https://kubeedge.io
代码仓库： https://github.com/kubeedge/kubeedge
「深度学习福利」大神带你进阶工程师,立即查看>>>
3月29日,权威技术分析网站The New Stack在Edge/IoT专栏发表了关于边缘计算项目KubeEdge的最新调研报告。原文观点如下：
https://github.com/kubeedge/kubeedge
云原生计算和边缘计算代表了两个独立并且重要的现代基础设施方向。云原生计算是云计算的第二波浪潮,它提供了对云的最佳投资回报。而边缘计算充当云和物联网（IoT）设备之间的管道,为数以百万计的物联网设备和应用程序提供自主和智能计算。
人工智能的兴起使得边缘计算变得更加重要。在云上经过训练的复杂模型被部署在边缘进行推理。
Kubernetes已经成为在数据中心和公有云中部署和运行容器化工作负载的黄金标准。在很短的时间内,云原生生态系统增添了多种能力,使Kubernetes成为一个强大而可靠的平台,可以大规模的运行互联网应用和企业业务应用。
投资物联网平台的公有云提供商正在将其产品延伸至边缘。物联网应用的设备注册、通信、部署和管理主要在云端运行,并扩展了对边缘的支持。这些提供商现在正在连接IoT、ML和AI平台,无缝地将ML模型从云端推向边缘。Azure IoT Edge、AWS Greengrass和Google Cloud IoT Edge就是公有云支持边缘平台的产品样例。诸如FogHorn、Swim.ai和Rigado等初创公司正在构建多云的边缘计算平台。
Kubernetes正在迅速成为调度和管理超出容器资源范围的通用调度程序。Kubernetes的控制面可以用于处理跨越数百个节点的数万个容器。这个架构体系非常适合管理可扩展的分布式边缘应用部署。每个边缘计算设备可以被视为一个节点,而一个或多个连接的设备可以映射到Pods。开发人员和运维人员可以使用熟悉的Kubectl工具或Helm Charts来把容器化的IoT应用推向边缘,用于一个或多个边缘设备。这种方法不仅使Kubernetes成为容器管理的控制面,而且使其成为能够管理数百万边缘计算设备的控制面。
“大型系统可能运行多个边缘计算节点,这些节点在连接前不会与控制面通信。这种模式与Kubernetes主节点和工作节点的原始设计非常不同。”
云原生社区一直在探索使用Kubernetes进行物联网和边缘计算。微软试图通过Virtual Kubelet方式实现这一点。华为已经建立了基于Kubernetes的智能边缘平台（IEF）。2018年6月,谷歌、华为、红帽和VMware启动了物联网边缘计算工作组开展这些工作。在2018年的西雅图KubeCon+CloudNativeCon大会上,华为展示了一个将Kubernetes的能力延伸至边缘的官方项目KubeEdge。
KubeEdge基于华为的智能边缘平台（IEF）,这是一个基于华为物联网PaaS的商业物联网边缘平台。KubeEdge则是IEF的开源具体实现。在发布的v0.2版本中,KubeEdge提供了稳定和完整的方案,解决物联网和边缘计算相关的关键用户场景。它支持安装在Linux发行版上,也可以安装在ARM设备上,如蓝莓派。
作者Janakiram MSV作为一个Kubernetes和IoT的粉丝,非常看好KubeEdge的设计和架构。与Kubernetes集群的节点不同,边缘节点需要在完全断开连接的模式下自主工作。大型系统可能会运行多个边缘计算节点,这些节点在连接前不会与控制面通信。此模式与Kubernetes主节点和工作节点的原始设计非常不同。
KubeEdge优雅地通过消息总线和边缘本地数据存储来解决这个问题,使得边缘节点自治和独立。用户期望的控制面配置通过同步、缓存到边缘设备的本地数据存储。同样边缘设备的实时状态也是存储到边缘的数据存储中。
KubeEdge使用了原生Kubernetes强大的能力,如控制器和自定义资源定义（CRD）。就像Replication Controller 和StatefulSet Controller一样,KubeEdge有一个Edge Controller控制面,与设备中部署的边缘运行时进行通信。这种设计使得Kubectl来管理边缘应用部署成为可能。
KubeEdge依赖于Eclipse基金会的中的开源MQTT代理,用于机器间通信以及边缘和控制面之间的双工通信。KubeEdge平台还支持设备孪生,以维护物联网设备的状态。SQLite用作边缘本地数据存储,以维护设备孪生状态以及边缘与控制面之间来回流动的消息。Web Sockets用于边缘节点和主节点之间的轻量级通信。
KubeEdge是Kubernetes成为边缘计算的统一控制面的第一步。它的成功很大程度上要取决于主流云提供商包括亚马逊、谷歌和微软等的采用。
原文链接：
https://thenewstack.io/kubeedge-extends-the-power-of-kubernetes-to-the-edge/
「深度学习福利」大神带你进阶工程师,立即查看>>>
边缘计算与KubeEdge
云计算离终端设备（如摄像头、传感器等）较远,对于实时性要求高的计算需求,把计算放在云上会引起较长的网络延时、网络拥塞、服务质量下降等问题。而终端设备通常计算能力不足,无法与云端相比。在此情况下,边缘计算应运而生,将云端计算能力延伸到靠近终端设备的边缘节点,完美解决上述问题。
KubeEdge作为全球首个Kubernetes原生的开源边缘计算平台,依托Kubernetes的容器编排和调度能力,通过纳管用户的边缘节点,提供将云上应用延伸到边缘的能力,联动边缘侧和云端的数据,满足客户对边缘计算资源的远程管控、数据处理、分析决策、智能化的诉求。同时,在云端提供统一的设备/应用监控、日志采集等运维能力,为企业提供完整的边云协同一体化服务的边缘计算解决方案。
本文将介绍KubeEdge是如何在云端管理边缘侧的设备的,例如：用户只需在按下手机上app的一个按钮,就能打开自己家中的电灯。
设备孪生与KubeEdge设备管理
说到IoT设备,不得不提到一个概念叫做设备孪生Device Twin。设备孪生作为一种IoT设备元数据在应用平台上的虚拟映射,已经成为IoT设备管理的重要组成部分。IoT设备通常包含两类数据：一是不会改变的元数据,包括序列号、资产标识符、Mac地址等描述设备的详细信息,也可以称为设备的静态属性。另一类是设备的动态数据,包括特定背景下的设备专有实时数据,例如灯的开、关状态,也可以称为设备的Twin属性。设备孪生具有与物理设备相同的特性,便于设备与应用之间进行更好地通信。应用发送的命令首先到达设备孪生,设备孪生根据应用设置的Expected State进行状态更新,此外IoT设备实时反馈自身的Actual State,设备孪生同时记录IoT设备的Actual State和Expected State 。这种方式也使IoT设备在离线状况下再次上线时,设备的状态也能得到同步。
设备管理也是边缘计算中IoT场景的关键功能。KubeEdge作为一个云端和边缘侧都开源的边缘计算平台,除了实现云端应用的配置和下发之外,另一个很重要的功能就是在云端管理IoT设备,并且实现云边之间的设备状态同步。
KubeEdge设备管理组件
KubeEdge设备管理相关的组件如下： DeviceController：扩展的 Kubernetes 控制器,管理云端的设备信息以及云端与边缘侧设备的同步。 CloudHub：WebSocket 服务端,负责监听云端资源变化, 缓存并发送消息到 EdgeHub。 EdgeHub：WebSocket 客户端,包括同步云端资源更新、报告边缘节点和设备信息到云端等功能。 DeviceTwin：负责存储设备状态并将设备状态同步到云端。 EventBus：与 MQTT 服务器Mosquitto交互的客户端,为其他组件提供订阅和发布消息的功能。 Mapper：用于连接和控制端侧设备,例如开、关灯。
KubeEdge通过CRD（Customer Resource Definition）扩展Kubernetes的API,扩展的API资源包括：Device和DeviceModel等,这样我们能在云端通过Kubernetes命令行工具Kubectl或其他方式对设备资源进行CRUD的操作。Device资源映射与各个边缘节点关联的设备,例如传感器。DeviceModel则是对一类设备定义的模板,方便用户可以在云端依据DeviceModel模板轻易地完成对Device资源的批量操作。
使用KubeEdge点亮您家的灯
在云端点亮您家的灯,让我们来看看KubeEdge如何实现这件有趣的事情？一个设备孪生的参考示例如下所示：
这里就需要用到上面提到Device Twin。例如灯的元数据信息以Json的格式描述如上,包含静态属性attributes和动态属性twin。这里定义一个名为powerstatus的twin属性,它的expected值和actual值可以为ON或者OFF。设备自身可以上报powerstatus的actual值到云端,云端则可以通过修改为powerstatus属性的expected值来控制边缘侧灯的开、关。
首先我们看看如何上报灯的powerstatus的actual值到云端： Mapper实时上报实际状态Actual State给MQTT服务器Mosquitto。 EventBus从Mosquitto收到订阅消息,消息内容包含设备的实际状态Actual State。 EventBus把设备实际状态Actual State发送给Device Twin。 Device Twin更新设备实际状态Actual State到边缘节点本地的轻量级数据库,例如SQLite。 Device Twin同步实际状态Actual State给WebSocket客户端EdgeHub。 EdgeHub发送消息给WebSocket服务端CloudHub。 CloudHub回馈消息给DeviceController。 DeviceController同步实际状态Actual State到Kubernetes API Server。
最后用户就能在云端查询设备的powerstatus的actual值,获取到边缘侧设备上的灯开、关的实际状态。
加入KubeEdge
设备管理毫无疑问是边缘计算IoT场景中十分关键的特性,目前KubeEdge的设备管理特性仍在开发之中,将会在0.3版本发布,敬请期待。
KubeEdge作为一个100%开源的项目,十分欢迎您的加入。KubeEdge Github项目地址：
https://github.com/kubeedge/kubeedge
「深度学习福利」大神带你进阶工程师,立即查看>>>
有人说 云终端 在部署云桌面的过程中只起到一个连接桥梁的作用,加上本地并不进行数据的存储和运行,它和服务器以及云桌面软件相比并不是很重要的。因此有人说云终端是没什么难度的,体积小、配置又不高比传统PC简单多了。云终端真的如大家看起来的这么简单吗？
首先,云终端虽然外观和大小看起来都差不多,但是我们知道云终端它按架构分具有ARM架构和X86架构两种的,而这两种架构的使用功能也是有所不同的,ARM架构的云终端通常情况下是不能单独使用的,需要和服务器搭配起来使用的；而X86架构的云终端除了可以搭配服务器使用之外,还具备单独计算和数据存储的功能。
其次,云终端看起来是很简单,外观和配置这些基本上也是大同小异的,但是并不是所有厂家的云终端都是通用的,即使是两个架构一样配置一样的云终端由于所生产厂家的不同,它们使用起来时的效果也可能是不一样的,因为云终端是需要搭配服务器和云桌面软件一起使用的,在生产云终端的时候,很多厂家都是根据自己的云桌面软件和协议进行专门定制化生产的,因此说不同厂家的云终端很多情况下是不通用的。
第三,虽然说云终端在大多数情况下是通过协议连接服务器使用的,本地并不进行计算和数据的存储,但是这并不意味云终端它的配置高低就不是很重要的了,对于较为简单的使用场景来说较低配置或者ARM架构的云终端就可以完美的适应的。但是对于需要更高要求和功能的一些使用场景来说,但是对于其他一些应用场景来说,还是需要较高配置的云终端才能很好的完成画面的传输和解码能力的。
云终端虽然只看外观和配置的是很简单,但是要使用好它并不是随随便便选择就可以的,还是需要谨慎选择的。
来源禹龙云
「深度学习福利」大神带你进阶工程师,立即查看>>>
点击下载《不一样的 双11 技术：阿里巴巴经济体云原生实践》
本文节选自《不一样的 双11 技术：阿里巴巴经济体云原生实践》一书,点击上方图片即可下载！ 作者 谢于宁（予栖） 阿里云容器服务高级开发工程师 罗晶（瑶靖） 阿里云容器服务高级产品经理 邓隽 阿里云容器服务技术专家 导读 ：2019 年天猫 双11,阿里巴巴核心系统首次实现 100% 上云。面对全球最大的交易洪峰,阿里云扛住了每秒 54.4 万笔的交易峰值,这是“云原生”与“天猫全球狂欢节”的一次完美联名。
（图为 2019 年天猫 双11 成交额）
容器镜像服务作为阿里巴巴经济体云原生领域的重要基础设施之一,早在 双11 备战期间就已面临大规模分发需求。为了更好地支持这一需求,产品提前进行规划及迭代更新,全面提升了大规模分发场景下的性能、可观测性和稳定性。在新的 双11 来临前,容器镜像服务新增了 数 PB 的镜像数据,月均镜像拉取达 数亿次 。同时产品提供了云原生应用交付链等功能,全面覆盖阿里巴巴经济体及云上用户在云原生时代的使用需求。
本文将介绍容器镜像服务如何通过提升产品能力来应对云原生应用万节点分发场景下的新发展和新挑战。
新发展和新挑战
随着云原生技术的迅速普及,Kubernetes 已经成为事实上应用容器化平台的标准,成为了云原生领域的“一等公民”。
Kubernetes 以一种声明式的容器编排与管理体系,让软件交付变得越来越标准化。Kubernetes 提供了统一模式的 API,能以 YAML 格式的文件定义 Kubernetes 集群内的资源。这一些 YAML 格式的资源定义使得 Kubernetes 能轻松被上下游系统所集成,完成一系列原本需要用非标准化脚本、人工来完成的操作。同时社区根据应用交付场景及需求,在原生 YAML 格式的资源定义文件之外衍生出了更多系列的云原生应用交付标准,例如 Helm Chart、Opeartor、 Open Application Model 等。
（图为云原生应用交付标准演进） 除了云原生应用交付标准推陈出新,用户对交付方式也提出了更高的要求。越来越多的用户期望能以流程化、自动化、更安全的方式交付云原生应用,因此单纯的万节点分发场景已经演化成万节点分钟级多环节协同分发。再加上全球化业务发展,这意味着在分钟级时间内完成各个环节之后,还需再完成全球化分发,这对支撑云生应用分发的平台提出了更高的要求。
新实践
通过控制容器镜像大小、采用 P2P 分发镜像层、优化 Registry 服务端等方式,我们极大优化了大规模分发的性能,最终达成了万节点分钟级分发的目标： 优化容器镜像大小,降低镜像传输成本 制作基础镜像,将使用频繁的应用或环境制作成基础镜像复用,尽可能减少镜像的层数,控制每次变更层数 采用多阶段镜像构建,将镜像制作过程中的中间产物与最终产物分离,形成最精简的应用镜像 优化服务端处理性能,提高请求响应速率 服务端通过识别热点镜像,采用热点数据缓存等多种方式应对大规模镜像 Manifest 并发拉取 优化客户端容器镜像层下载方式,减少镜像传输时间 客户端使用蜻蜓下载容器镜像, 基于 P2P 方式大幅减少镜像 Layer 下载时间
（图为镜像大规模分发的优化策略） 为了让拥有同样需求的企业客户能够享受到如上一致的分发能力和体验,容器镜像服务产品在 2019 年 3 月正式推出了容器镜像服务企业版（ACR Enterprise Edition）。容器镜像服务企业版提供了企业级云原生资产托管能力以及云原生应用全球化同步、大规模分发能力,适合有着高安全需求、多地域业务部署、拥有大规模集群节点的企业级容器客户。除此之外,容器镜像服务企业版还在云原生资产 托管 、 交付 、 分发 等几个方面进一步提升云原生应用万节点分钟级分发协同体验。
云原生应用托管 在应用交付物层面,容器镜像服务企业版目前支持 容器镜像 、**Helm Chart **两类云原生应用资产的全生命周期管理； 在访问安全层面,产品提供了独立网络访问控制功能,可以细粒度控制公网及 VPC 网络的访问策略,仅允许符合策略的来源方访问资产,进一步保障云原生资产的访问安全； 在访问体验层面,产品提供容器集群透明拉取插件,支持容器镜像透明拉取,保障业务在弹性场景极速拉取镜像,不因凭证配置有误导致业务更新或扩容异常。
（图为容器镜像服务企业版支持云原生应用交付）
云原生应用交付
云原生应用生产环节,用户可以直接上传托管容器镜像、Helm Chart 等云原生资产；也可以通过构建功能自动从源代码（Github、阿里云 Code、GitLab 等来源）智能构建成容器镜像。同时为了解决流程化、自动化、更安全的方式交付云原生应用这一需求,容器镜像服务企业版引入了云原生应用交付链功能。云原生应用交付链以云原生应用托管为始,以云原生应用分发为终,全链路可观测、可追踪、可自主设置。可以实现一次应用变更,全球化多场景自动交付,从流程层面极大地提升了云原生应用万节点分发的效率及安全性。
（图为控制台创建云原生应用交付链） 云原生应用交付环节,支持自动发起静态安全扫描并自定义配置安全阻断策略。一旦识别到静态应用中存在高危漏洞后,可自动阻断后续部署链路。用户可基于漏洞报告中的修复建议,更新优化构建成新的镜像版本,再次发起交付。
云原生应用分发
云原生应用分发环节,当前置环节完成无阻断后,云原生应用正式进入全球化分发及大规模分发环节。为了保障万节点分钟级分发协同完成,容器镜像服务联合容器服务、弹性容器实例等云产品提供了端到端的极致分发体验。针对全球化分发,由于基于细粒度同步策略调度、同步链路优化等优化手段,云原生应用的全球同步效率相比手动同步提升了** 7 倍**。
（图为云原生应用的全球化分发）
在 P2P 大规模分发方面,产品针对云环境多次优化基于 Dragonfly 的分发方案,最终通过多个创新技术解决了大规模文件下载以及跨网络隔离等场景下各种文件分发难题,大幅提高大规模容器镜像分发能力。平均镜像大规模分发效率比普通方式提高 数倍 ,适用于容器集群单集群节点数达 100 及以上的场景。
(图为基于 P2P 的分发流程示意） 除了 P2P 大规模分发手段外,为了更好地满足特定场景下的大规模分发需求,产品还支持基于镜像快照的大规模分发方式。基于镜像快照的分发方式,可避免或减少镜像层的下载,极大提高弹性容器实例创建速度。在容器集群（ ASK ）及弹性容器实例（ ECI ）的联合使用场景下,产品可以支持** 500 节点秒级**镜像拉取,实现业务突发场景下极速扩容。
新平台
在功能及性能指标满足云原生应用万节点分钟级分发协同需求外,容器镜像服务还对平台能力进行了提升和优化,保障了分发过程的可观测性及稳定性。同时平台提供了集成能力,进一步延展云原生应用分发的使用场景和价值。
稳定性
稳定性层面的具体提升及优化工作从监控报警、容错容灾、依赖治理、限流降级、容量规划等几个方面展开。 在依赖治理方面,平台对云原生应用交付链中的相关重点环节及外部依赖进行统一管理,提升交付链整体交付能力,帮助用户识别热点仓库及追踪交付链执行结果； 在限流降级方面,平台分析识别云原生应用分发核心环节的主次业务功能,优先保障主要业务逻辑完成,次要业务逻辑可降级延后处理； 在容量规划方面,平台根据上下游业务变化情况,对资源进行按需扩容,确保云原生应用正常交付完成。
（图为平台的稳定性保障策略）
生态集成
基于平台提供的丰富的集成能力,用户还可以将容器镜像服务企业版作为云原生资产托管及分发的基础设施,为他们的用户提供云原生应用分发能力。
其中,容器镜像服务企业版支撑阿里云云市场构建容器应用市场,支撑容器应用市场的容器商品托管及商业化分发,构建云上云原生生态闭环。ISV 服务商,例如 Intel、Fortinet、奥哲,将容器化商品以容器镜像或者 Helm Chart 的形式在云市场快速上架,实现标准化交付、商业化变现。市场客户也可以从容器应用市场获取到优质的阿里云官方及 ISV 容器镜像,快速部署至容器服务容器集群,享受到阿里云丰富的云原生生态。
（图为容器应用市场流程示意）
写在最后
从支持阿里巴巴 双11 大规模分发需求,到全面覆盖阿里巴巴经济体及云用户的云原生资产托管及分发需求,再到支撑构建云上容器生态闭环,阿里云容器镜像服务已成为了云原生时代的核心基础设施之一,释放云原生价值的重要加速器。容器镜像服务也将持续为用户带来更加优异的云原生应用分发功能、性能及体验。
本书亮点 双11 超大规模 K8s 集群实践中,遇到的问题及解决方法详述 云原生化最佳组合：Kubernetes+容器+神龙,实现核心系统 100% 上云的技术细节 双 11 Service Mesh 超大规模落地解决方案 “ 阿里巴巴云原生 关注微服务、Serverless、容器、Service Mesh 等技术领域、聚焦云原生流行技术趋势、云原生大规模的落地实践,做最懂云原生开发者的技术圈。”
「深度学习福利」大神带你进阶工程师,立即查看>>>
本文将会简单介绍 Kubernetes 的核心概念。因为这些定义可以在Kubernetes的文档中找到,所以文章也会避免用大段的枯燥的文字介绍。相反,我们会使用一些图表（其中一些是动画）和示例来解释这些概念。我们发现一些概念（比如Service）如果没有图表的辅助就很难全面地理解。在合适的地方我们也会提供Kubernetes文档的链接以便读者深入学习。
什么是Kubernetes？
Kubernetes（k8s）是自动化容器操作的开源平台,这些操作包括部署,调度和节点集群间扩展。如果你曾经用过Docker容器技术部署容器,那么可以将Docker看成Kubernetes内部使用的低级别组件。Kubernetes不仅仅支持Docker,还支持Rocket,这是另一种容器技术。
使用Kubernetes可以： 自动化容器的部署和复制 随时扩展或收缩容器规模 将容器组织成组,并且提供容器间的负载均衡 很容易地升级应用程序容器的新版本 提供容器弹性,如果容器失效就替换它,等等...
实际上,使用Kubernetes只需一个 部署文件 ,使用一条命令就可以部署多层容器（前端,后台等）的完整集群： kubectl create -f single-config-file.yaml
kubectl是和Kubernetes API交互的命令行程序。现在介绍一些核心概念。
集群
集群是一组节点,这些节点可以是物理服务器或者虚拟机,之上安装了Kubernetes平台。下图展示这样的集群。注意该图为了强调核心概念有所简化。 这里 可以看到一个典型的Kubernetes架构图。
上图可以看到如下组件,使用特别的图标表示Service和Label： Pod Container（容器） Label( )（标签） Replication Controller（复制控制器） Service（ ）（服务） Node（节点） Kubernetes Master（Kubernetes主节点）
Pod
Pod （上图绿色方框）安排在节点上,包含一组容器和卷。同一个Pod里的容器共享同一个网络命名空间,可以使用localhost互相通信。Pod是短暂的,不是持续性实体。你可能会有这些问题： 如果Pod是短暂的,那么我怎么才能持久化容器数据使其能够跨重启而存在呢？ 是的,Kubernetes支持 卷 的概念,因此可以使用持久化的卷类型。 是否手动创建Pod,如果想要创建同一个容器的多份拷贝,需要一个个分别创建出来么？可以手动创建单个Pod,但是也可以使用Replication Controller使用Pod模板创建出多份拷贝,下文会详细介绍。 如果Pod是短暂的,那么重启时IP地址可能会改变,那么怎么才能从前端容器正确可靠地指向后台容器呢？这时可以使用Service,下文会详细介绍。
Lable
正如图所示,一些Pod有Label（ ）。一个Label是attach到Pod的一对键/值对,用来传递用户定义的属性。比如,你可能创建了一个"tier"和“app”标签,通过Label（ tier=frontend, app=myapp ）来标记前端Pod容器,使用Label（ tier=backend, app=myapp ）标记后台Pod。然后可以使用 Selectors 选择带有特定Label的Pod,并且将Service或者Replication Controller应用到上面。
Replication Controller
是否手动创建Pod,如果想要创建同一个容器的多份拷贝,需要一个个分别创建出来么,能否将Pods划到逻辑组里？
Replication Controller确保任意时间都有指定数量的Pod“副本”在运行。如果为某个Pod创建了Replication Controller并且指定3个副本,它会创建3个Pod,并且持续监控它们。如果某个Pod不响应,那么Replication Controller会替换它,保持总数为3.如下面的动画所示：
如果之前不响应的Pod恢复了,现在就有4个Pod了,那么Replication Controller会将其中一个终止保持总数为3。如果在运行中将副本总数改为5,Replication Controller会立刻启动2个新Pod,保证总数为5。还可以按照这样的方式缩小Pod,这个特性在执行滚动 升级 时很有用。
当创建Replication Controller时,需要指定两个东西： Pod模板 ：用来创建Pod副本的模板 Label ：Replication Controller需要监控的Pod的标签。
现在已经创建了Pod的一些副本,那么在这些副本上如何均衡负载呢？我们需要的是Service。
Service
如果Pods是短暂的,那么重启时IP地址可能会改变,怎么才能从前端容器正确可靠地指向后台容器呢？
Service 是定义一系列Pod以及访问这些Pod的策略的一层 抽象 。Service通过Label找到Pod组。因为Service是抽象的,所以在图表里通常看不到它们的存在,这也就让这一概念更难以理解。
现在,假定有2个后台Pod,并且定义后台Service的名称为‘backend-service’,lable选择器为（ tier=backend, app=myapp ）。 backend-service 的Service会完成如下两件重要的事情： 会为Service创建一个本地集群的DNS入口,因此前端Pod只需要DNS查找主机名为 ‘backend-service’,就能够解析出前端应用程序可用的IP地址。 现在前端已经得到了后台服务的IP地址,但是它应该访问2个后台Pod的哪一个呢？Service在这2个后台Pod之间提供透明的负载均衡,会将请求分发给其中的任意一个（如下面的动画所示）。通过每个Node上运行的代理（kube-proxy）完成。 这里 有更多技术细节。
下述动画展示了Service的功能。注意该图作了很多简化。如果不进入网络配置,那么达到透明的负载均衡目标所涉及的底层网络和路由相对先进。如果有兴趣, 这里 有更深入的介绍。
有一个特别类型的Kubernetes Service,称为' LoadBalancer ',作为外部负载均衡器使用,在一定数量的Pod之间均衡流量。比如,对于负载均衡Web流量很有用。
Node
节点（上图橘色方框）是物理或者虚拟机器,作为Kubernetes worker,通常称为Minion。每个节点都运行如下Kubernetes关键组件： Kubelet：是主节点代理。 Kube-proxy：Service使用其将链接路由到Pod,如上文所述。 Docker或Rocket：Kubernetes使用的容器技术来创建容器。
Kubernetes Master
集群拥有一个Kubernetes Master（紫色方框）。Kubernetes Master提供集群的独特视角,并且拥有一系列组件,比如Kubernetes API Server。API Server提供可以用来和集群交互的REST端点。master节点包括用来创建和复制Pod的Replication Controller。
「深度学习福利」大神带你进阶工程师,立即查看>>>
IDC机房是用来存放服务器的场所,对IDC机房的维护可以保障服务器的正常运行,减少故障发生,延长设备寿命。那么我们怎么做才能保证IDC机房的稳定呢？
1.机房环境控制
定期对设备进行除尘、清理,调整安保摄像头清晰度,防止由于机器运转、静电等因素将尘土吸入监控设备内部。同时检查机房通风、散热、净尘、供电、架空防静电地板等设施。检查空调运行是否正常,换风设备运转是否正常,机房室内温度应控制在5℃-35℃,相对湿度应控制在30%-85%。
2. UPS及蓄电池维护
根据实际情况进行电池核对性容量测试；进行电池组充放电维护及调整充电电流,确保电池组正常工作；检查记录输出波形、谐波含量、零地电压；查清各参数是否配置正确；定期进行UPS功能测试,如UPS同市电的切换试验。
3. 电路与消防设备维护
镇流器、灯管及时更换,开关更换；线头氧化处理,标签巡查更换；供电线路绝缘检查,防止意外短路。检查火警探测器、手动报警按钮、火灾警报装置外观及试验报警功能；检查火灾警报控制器的自检、消音、复位功能及主备用电源切换功能。
4. 基础维护
静电地板清洗清洁,地面除尘；缝隙调整,损坏更换；接地电阻测试；主接地点除锈、接头紧固；防雷器检查；接地线触点防氧化加固。
5. 机房管理系统
IDC机房承载着服务器的各种事项,服务器上架、下架、处理故障等等。传统的管理模式还有很多是手动表格记录与管理,容易出现错漏。但是目前市场上出现了一些较为专业的管理OA、CRM系统,比如ZKEYS公有云管理系统。 ZKEYS公有云管理系统 由OA、CRM、财务、业务、生产、备案、工单等多个管理模块组成,不仅可以让IDC服务商们更加轻松地管理业务,形成标准化、智能化、一体化管理体系,还可以保障IDC机房的平稳健康运营。
「深度学习福利」大神带你进阶工程师,立即查看>>>
从全排列看回溯算法
最近又刷起了算法,仿佛回到了大一时奋战到深夜场景,走上社会之初发现大学里学的都是啥玩意儿,工作中基本遇不到,各种数据结构都被封装的妥妥的根本不需要我们去操心,以至于越来越浮于表面。
现在觉得大学的课程是真功夫,是无数学者总结提炼的精华,是计算机从业人员是基本功,基本功不扎实很快就会遇到瓶颈,对算法与数据结构掌握与理解不透彻很难写出非常优秀的软件,亡羊补牢为时不晚,所以拿起旧书本回炉重造磨练自己基本功。 学习算法不仅会收获很多还会给你带来成就感。
下面用通俗的方式结合例子给大家介绍回溯算法
回溯算法框架 func backtrack(选择列表,路径) { if 结束条件 { 得到一种结果 } for i in 选择列表 { if 减支条件 { continue } 选择列表加入路径 backtrack(选择列表,路径) 撤销选择 } }
这个先看不太懂没关系,读完全文可再返回阅读。 回溯算法本质就是一个多叉树遍历问题
我们以在袋子里抓球为力来解释一下上面几个名词。 假设袋子里三个球,抓一个那么就有三种选择,所以选择列表是：[1,2,3] , 如果你抓到1,那么[1]便是路径,对应的是树的树枝。
结束条件：比如你只抓一次,那么结束条件就是路径长度等于1 减支条件：比如抓完放回球,那么就没有减支条件,如果抓完不放回那么条件就是路径里如果已经存在就不再遍历。 很多时候不同的问题都是在减支条件这里做手脚,比如N皇后问题. 撤销选择：为啥要撤销选择？其实就是在遍历到叶子节点之后我们需要重新返回到父节点重新寻找其它路径
全排列
给定一个不幸串,输出它的全排列
先来看个最简单的场景：
袋子里有两个球,取出一个记下,放回袋子,再取一个,有多少种结果
输入：[1,2] 输出：[[1,1],[1,2],[2,1],[2,2]]
这样就得出一个二叉树：
所有到叶子节点的路径就是我们需要求解的解集,所以这个问题变成了一个多叉树遍历问题： func tree(选择,路径){ 结束条件 遍历分叉 进入节点前干啥 递归节点 遍历节点后干啥 }
所谓回溯,就是在遍历节点后撤销我们选择路径中的选择,所以想一下第一次遍历： 已经走到了一个叶子节点,这时我们已经得出一个解[1,1]并且已经把它存在res的结果中。
所以我们现在想从叶子节点A走回到B,下一步往C去走。这样在回溯到B之前路径是[1,1],回溯之后路径变成[1], 然后递归遍历到C时路径变成[1,2]得到第二个解 res [][]int func tree(nums []int, track []int) { if len(track) == 2 //我们取两次 { // 取到了一个结果 res = append(res,track) } for _,n := range nums { // 遍历选择列表,把选择列表加入到路径中,所以选择列表多长就是多少叉树 track = append(track, n) tree(nums, track) track = track[:len(track) - 1] // 撤销路径最后一个选择,在此之前已经遍历到叶子节点并把解记录到了res中,因为递归时已经满足了结束条件 } }
有了回溯法,寥寥几行代码就解决了上面问题。下面来加大一下难度： 全排列
一串不重复的数字,输出其全排列,如：
输入：[1,2] 输出：[[1,2],[2,1]]
一眼就能看到结果是上面题目的子集,说明啥？多叉树被剪枝了！ 如何剪枝?
很简单,满足一定条件啥也不做就行,不去选择->递归->撤销选择, 所以： func tree(选择,路径){ 结束条件 遍历分叉 if 满足剪枝条件 continue 进入节点前干啥 递归节点 遍历节点后干啥 }
问题就简化为剪枝条件是啥？
显然特点就是已经出现在路径中的元素就不能再选择：
代码其它部分不变,for循环里变成： for _,n := range nums { if has(track,n) { //表示track列表中包含n continue } track = append(track, n) tree(nums, track) track = track[:len(track) - 1] // 撤销路径最后一个选择,在此之前已经遍历到叶子节点并把解记录到了res中,因为递归时已经满足了结束条件 }
轻松搞定 有重复元素的全排列
现在假设选择列表nums中有重复元素如[1,1,2,3]那又该怎么做？
聪明人立马会意识到,其它不变,只是剪枝条件发生了变化： 选择列表中的元素没有被遍历过 任何节点的树枝不能重复
要注意不能被重复剪枝,在判断是不是重复时不用考虑已经被剪枝的树枝
所以最主要的是修改剪枝条件,但是判断某个元素是否被访问过我们需要引入一个数组来保存选择列表某个元素是否被访问 if flag[i] { continue } if Has(num[:i], num[i], flag) { continue } track = append(track, num[i]) flag[i] = true back(num, flag, track) track = track[:len(track)-1] flag[i] = false func Has(a []int, b int, flag []bool) bool { l := len(a) if l == 0 { return false } for i := 0; i < l; i++ { if flag[i] { // 细节,不用考虑已经被剪枝的树枝 continue } if a[i] == b { return true } } return false }
至此你已经掌握了回溯算法的精髓,然后就是活学活用推广到其它问题中。一定要动手再细细琢磨才能触类旁通。 N皇后问题
在一个N*N的棋盘上摆N个皇后,彼此不攻击对方的摆法。
有了回溯算法的基础此问题就变得简单了。
一行一行的放皇后,第一行就有N种放法,如此就又变成了一颗N叉树,思考三个核心元素： 选择列表是啥,路径是啥,剪枝条件是啥 选择列表就可以用一个N位数组 路径可以用二维数组 剪枝条件就变成放的位置横竖斜有没有皇后
如此问题便可解决,如果建议学完回溯算法再拿N皇后稳定巩固一下。 kubernetes一键HA
「深度学习福利」大神带你进阶工程师,立即查看>>>
JEPaaS云平台,是中国实干型的新一代企业级PaaS平台,由北京凯特科技基于10多年来服务于国企、央企等大型集团性企业管理咨询及信息化落地的实践探索和丰富经验独立研发而成,在商用化程度及性能水平上与国际品牌同类型产品拥有同等竞争力。以低代码快速开发、实干型数字中台工具、SaaS快速开发运营管理、万物互联的物联网接口引擎为代表的四大核心承载力,赋予了JEPaaS独特的优势。JEPaaS可以为企业数字化业务提供按需使用、持续运行的基础能力,快速满足企业多变的需求,允许个性化定制,提供支撑企业业务的完美解决方案,为企业业务的快速创新提供了重要支撑,加速企业数字化转型。
想要了解更多,欢迎访问 JEPaaS官网 ,您还可以拨打400-0999-235与我们随时联系。
（注：本报告转载自中国软件网）
「深度学习福利」大神带你进阶工程师,立即查看>>>
本文作者：y****n
注：该文章来源—— 《智能对话机器人开发实战》
本篇文章会系统性的介绍智能对话机器人的构成组件,通过本篇文章的阅读,可以让你对智能对话机器人的体系结构有初步认识,了解智能对话机器人回答问题的工作原理。
概述
首先我们来看智能对话机器人体系结构的构成,从与机器交互的完整流程角度来给大家做一个系统性的概述。
当人通过声音信号把自己表达的内容以声音的方式来传递给机器的时候,机器人接收声音的过程涉及到了语音识别技术。
这个语音识别在这个里面其实是一个综合体,它既包括语音采集,也包括把声音信号转成文字信号。
其次,当我们把声音信号转换成文本信号后,要做的一件事情就是语义理解,因为你要让机器理解你,那么首先要让机器知道你说的是什么内容。机器在理解你说内容的过程中,依赖于中文分词、词性标注、实体意图识别、语义分析。那这部分内容就涉及到了语义理解技术。
在机器理解人所说的内容后,会把对应的内容交给对话管理平台来进行处理。那么对话管理平台涉及到的内容是什么呢？包括对话状态的跟踪同时也包括对话的策略模型。
对话状态跟踪负责两件事情,第一是负责对对话状态进行跟踪,第二是对“对话活动”进行决策。当完成了对话状态跟踪和对话活动的决策后,会生成对应的答案。那么这种答案往往很多时候有两种情况,一种情况是多答案的情况,另外一个是对多处理模式的选择。
当我在表达一句话的时候,如果机器在备选答案里面找到了多个回答,即出现了第一种情况,多答案情况。这个时候就会涉及到决策模型,这个决策模型就是智能对话的策略模块。这个时候策略模块包括通用决策模型和领域决策模型。
通用决策模型可以理解为适合所有领域的决策分析模块,领域模型对应特定领域,比如教育、医疗,房产。这一部分是对话管理的组件。
以上是可以在备选答案里面找到答案的情况,那么当机器人在备选答案里找不到答案时,会如何处理呢？
这里涉及到两个问题,第一个是优先级,第二个是补位。
优先级指的是当机器对用户话术进行语义理解之后,如果找到答案的过程存在多种方案,应考虑优先选取的策略是什么。另外一个是当在预置的语料库中找不到答案时,可选的补位的方式是什么。在这里,通常意义上来讲会选择知识图谱,搜索引擎和百科类问答等平台作为补位的一种方式。
在对话管理的过程中,寻找到了对应的内容,接下来要涉及到话术合成问题,这个时候对应的是语音合成,指的是我们需要把对应的内容重新合成为声音信号,反馈给最初发出指令的人。
所以系统性的来讲,整个智能对话机器人的体系结构包括智能语音部分、语义理解、对话管理和辅助语料库这四大部分内容。
智能语音部分
针对智能语音部分,主要包括两部分内容,语音识别以及语音合成。
在这里,语音识别负责的一个职责就是把声音信号翻译成文字。“把声音信号翻译成文字”既是语音识别的定义,同时也是语音识别的职能。语音识别往往会涉及到孤立词识别、连续词语识别、大词表连续语音识别。语音合成往往会涉及到的内容包括语言处理、声学处理、韵律处理以及情感处理。
在语音合成中,我们目前遇到的比较明显的问题是语音合成很难达到真正拟人化的一个水平,机器发出的声音比较机械化,让人听起来很奇怪。机器发出声音较为机械化,主要问题在于对情感、语速、韵律的控制较难。
自然语言处理部分
自然语言处理部分, 涵盖两大块内容,一部分是语义理解,另一部分是语言生成。
语义理解涉及到的内容包括中文分词、序列标注、实体识别、意图识别等内容。正是基于以上内容,我们才可以把人的一句话翻译成机器可以理解的一部分内容。
针对语言生成,这部分面临的主要问题是预定义的模板的建设,包括提前准备好的问答语料库、知识图谱。拿知识图谱来说,它的构建需要非常强大的资本和人力的支撑,才能够构建起一个完整的知识图谱体系。到现在为止还没有一套这样的知识图谱体系。再有是针对问答语料库,也需要很大的人力资源才能做成。
通常意义上,大家都在讲的深度学习,包括seq2seq这种生成模式的模型,它产生的效果其实一直都不怎么理想,所以在解决语言生成方面遇到的问题时,预定义的一对一模板是第一选择,提前构建好语料库是第二选择,基于知识图谱的问答体系是第三选择,基于深度学习的生成模式,是最后一种选择。
以上是智能对话机器人中与自然语言处理相关的组件问题。
对话管理
对话管理包括两部分内容,一是对话状态模型构建过程,另一个是对话策略模型构建过程。
对话状态模型可分为三类：
第一类是对话表示模型,是指上一句话和下一句话之间,以及连续的多句话之间如何通过数学模型进行表达出来；
第二类是对话推理模型,是指基于对话的输入,如何最终生成对话输出的模型；
第三类是对话学习模型,重点在于如何提升对话的能力和水平。
关于对话的策略模型,它涉及到通用对话策略以及特定领域的对话策略,包含以下两部分内容,第一部分内容是用户输入话术及语料库选择的策略；第二部分是当对话产生多个答案时,选择优选答案的策略。这是对话的策略模型。
语料库资源
通常意义上讲,当我们讲智能对话机器人的时候,它所涉及到的语料库资源包括预制模板,针对一个完整的问句,会有完整的与之呼应的答案,这个称为预制模板,这部分应用到客服系统中,比如说查询电话号码。
另外一个就是问答语料,就是聊天式机器人AIML会有预制问题和对应答案。这是问答语料库。
再有一部分是涉及到知识图谱,这个里面涉及到的内容包括用户输入一句话,通过解析里面的实体与实体对象,然后通过推理的模式在知识图谱里面去寻找与之匹配符的内容。
然后第四个语料库资源就在于生成模型,通常意义上来讲seq2seq这种生成方式,当然这个方式依赖于大量的语料库,而语料资源的匮乏会导致训练模型本身存在很大质量问题,效果很差。
在以上四种情况下,如果能够产生问题答案,就会让机器来回答问题。但是,当我们没有办法基于以上四种场景找到具体答案时,我们可以选择使用百科问答以及搜索引擎,这个对应的就是一个补位策略。
以上是智能对话机器人的一个简要体系结构介绍,如果同学们想要更加细致地了解智能对话机器人的相关内容,可以点击进入 云智学院官网 ,进行学习。
注：该文章来源—— 《智能对话机器人开发实战》
原文链接地址： https://developer.baidu.com/topic/show/290491
「深度学习福利」大神带你进阶工程师,立即查看>>>
本文作者：yunzhixueyuan
注：该文章来源—— 《智能对话机器人开发实战》
本篇文章会系统性的介绍智能对话机器人的构成组件,通过本篇文章的阅读,可以让你对智能对话机器人的体系结构有初步认识,了解智能对话机器人回答问题的工作原理。
概述
首先我们来看智能对话机器人体系结构的构成,从与机器交互的完整流程角度来给大家做一个系统性的概述。
当人通过声音信号把自己表达的内容以声音的方式来传递给机器的时候,机器人接收声音的过程涉及到了语音识别技术。
这个语音识别在这个里面其实是一个综合体,它既包括语音采集,也包括把声音信号转成文字信号。
其次,当我们把声音信号转换成文本信号后,要做的一件事情就是语义理解,因为你要让机器理解你,那么首先要让机器知道你说的是什么内容。机器在理解你说内容的过程中,依赖于中文分词、词性标注、实体意图识别、语义分析。那这部分内容就涉及到了语义理解技术。
在机器理解人所说的内容后,会把对应的内容交给对话管理平台来进行处理。那么对话管理平台涉及到的内容是什么呢？包括对话状态的跟踪同时也包括对话的策略模型。
对话状态跟踪负责两件事情,第一是负责对对话状态进行跟踪,第二是对“对话活动”进行决策。当完成了对话状态跟踪和对话活动的决策后,会生成对应的答案。那么这种答案往往很多时候有两种情况,一种情况是多答案的情况,另外一个是对多处理模式的选择。
当我在表达一句话的时候,如果机器在备选答案里面找到了多个回答,即出现了第一种情况,多答案情况。这个时候就会涉及到决策模型,这个决策模型就是智能对话的策略模块。这个时候策略模块包括通用决策模型和领域决策模型。
通用决策模型可以理解为适合所有领域的决策分析模块,领域模型对应特定领域,比如教育、医疗,房产。这一部分是对话管理的组件。
以上是可以在备选答案里面找到答案的情况,那么当机器人在备选答案里找不到答案时,会如何处理呢？
这里涉及到两个问题,第一个是优先级,第二个是补位。
优先级指的是当机器对用户话术进行语义理解之后,如果找到答案的过程存在多种方案,应考虑优先选取的策略是什么。另外一个是当在预置的语料库中找不到答案时,可选的补位的方式是什么。在这里,通常意义上来讲会选择知识图谱,搜索引擎和百科类问答等平台作为补位的一种方式。
在对话管理的过程中,寻找到了对应的内容,接下来要涉及到话术合成问题,这个时候对应的是语音合成,指的是我们需要把对应的内容重新合成为声音信号,反馈给最初发出指令的人。
所以系统性的来讲,整个智能对话机器人的体系结构包括智能语音部分、语义理解、对话管理和辅助语料库这四大部分内容。
智能语音部分
针对智能语音部分,主要包括两部分内容,语音识别以及语音合成。
在这里,语音识别负责的一个职责就是把声音信号翻译成文字。“把声音信号翻译成文字”既是语音识别的定义,同时也是语音识别的职能。语音识别往往会涉及到孤立词识别、连续词语识别、大词表连续语音识别。语音合成往往会涉及到的内容包括语言处理、声学处理、韵律处理以及情感处理。
在语音合成中,我们目前遇到的比较明显的问题是语音合成很难达到真正拟人化的一个水平,机器发出的声音比较机械化,让人听起来很奇怪。机器发出声音较为机械化,主要问题在于对情感、语速、韵律的控制较难。
自然语言处理部分
自然语言处理部分, 涵盖两大块内容,一部分是语义理解,另一部分是语言生成。
语义理解涉及到的内容包括中文分词、序列标注、实体识别、意图识别等内容。正是基于以上内容,我们才可以把人的一句话翻译成机器可以理解的一部分内容。
针对语言生成,这部分面临的主要问题是预定义的模板的建设,包括提前准备好的问答语料库、知识图谱。拿知识图谱来说,它的构建需要非常强大的资本和人力的支撑,才能够构建起一个完整的知识图谱体系。到现在为止还没有一套这样的知识图谱体系。再有是针对问答语料库,也需要很大的人力资源才能做成。
通常意义上,大家都在讲的深度学习,包括seq2seq这种生成模式的模型,它产生的效果其实一直都不怎么理想,所以在解决语言生成方面遇到的问题时,预定义的一对一模板是第一选择,提前构建好语料库是第二选择,基于知识图谱的问答体系是第三选择,基于深度学习的生成模式,是最后一种选择。
以上是智能对话机器人中与自然语言处理相关的组件问题。
对话管理
对话管理包括两部分内容,一是对话状态模型构建过程,另一个是对话策略模型构建过程。
对话状态模型可分为三类：
第一类是对话表示模型,是指上一句话和下一句话之间,以及连续的多句话之间如何通过数学模型进行表达出来；
第二类是对话推理模型,是指基于对话的输入,如何最终生成对话输出的模型；
第三类是对话学习模型,重点在于如何提升对话的能力和水平。
关于对话的策略模型,它涉及到通用对话策略以及特定领域的对话策略,包含以下两部分内容,第一部分内容是用户输入话术及语料库选择的策略；第二部分是当对话产生多个答案时,选择优选答案的策略。这是对话的策略模型。
语料库资源
通常意义上讲,当我们讲智能对话机器人的时候,它所涉及到的语料库资源包括预制模板,针对一个完整的问句,会有完整的与之呼应的答案,这个称为预制模板,这部分应用到客服系统中,比如说查询电话号码。
另外一个就是问答语料,就是聊天式机器人AIML会有预制问题和对应答案。这是问答语料库。
再有一部分是涉及到知识图谱,这个里面涉及到的内容包括用户输入一句话,通过解析里面的实体与实体对象,然后通过推理的模式在知识图谱里面去寻找与之匹配符的内容。
然后第四个语料库资源就在于生成模型,通常意义上来讲seq2seq这种生成方式,当然这个方式依赖于大量的语料库,而语料资源的匮乏会导致训练模型本身存在很大质量问题,效果很差。
在以上四种情况下,如果能够产生问题答案,就会让机器来回答问题。但是,当我们没有办法基于以上四种场景找到具体答案时,我们可以选择使用百科问答以及搜索引擎,这个对应的就是一个补位策略。
以上是智能对话机器人的一个简要体系结构介绍,如果同学们想要更加细致地了解智能对话机器人的相关内容,可以点击进入 云智学院官网 ,进行学习。
注：该文章来源—— 《智能对话机器人开发实战》
原文链接地址： https://developer.baidu.com/topic/show/290491
「深度学习福利」大神带你进阶工程师,立即查看>>>
需要协同修改有四个地方,分别是 VPC 、Subnet、Security groups 和实例的网络设置,理论上只有第一个实例需要如此折腾,之后相同 VPC、Subnet 和 Security groups 的实例应当可以直接获取 IPv6 的地址
VPC
找到当前实例所属的 VPC 然后选择 Edit CIDRs：
然后点 Add IPv6 CIDR 就完事了：
新建的 VPC 直接选择 Amazon provided IPv6 CIDR block 就可以了：
Subnet
同样的,找到当前实例所属的 Subnet 然后选择 Edit IPv6 CIDRs：
新建的 Subnet 直接输入想要的 IPv6 block 就可以了（一般从 00 开始,多个 Subnet 后续可以指定 01、02,诸如此类）：
Security groups
如果用户想要通过 IPv6 访问实例,还需要设置防火墙的相应规则,一般来说允许所有地址就是在 Inbound 的 Source 里设置 ::/0：
实例网络设置
进入当前实例的 Networking - Manage IP Addresses,然后选择 Assign new IP 即可：
最后在子网关联的路由表添加一条IPV6 至IGW的路由
测试
1 找一台拥有公网IPV6的地址 测试
2 通过浏览器访问 https://ipv6-test.com/测试
测试结果
作者：光环云 刘丽东
查看原文
「深度学习福利」大神带你进阶工程师,立即查看>>>
作者 | 铃铛、滚动的轮子
Cloud Toolkit 的一键部署方式
今天为大家介绍的这一款免费 IDE 插件——Cloud Toolkit,已经有超 12 万开发者下载,是一种公认的极速部署方式,如果你还不了解,点击下方视频,立即查看详情。
视频链接： https://www.aliyun.com/daily-act/video?src=https://cloud.video.taobao.com/play/u/2311856963/p/1/e/6/t/1/247487624012.mp4
当您每次修改完代码后,是否正在经历反复地打包？采用 SCP 工具上传？使用 XShell 或 SecureCRT 登陆服务器？替换部署包？重启？
从现在开始,请把这些重复繁琐的工作交给 Cloud Toolkit 吧,它能够帮助开发者更高效地开发、测试、诊断并部署应用。Cloud Toolkit 与主流 IDE 及阿里云其他产品无缝集成,帮助您大大简化应用部署到服务器,尤其是阿里云服务器中的操作。通过插件,可以将本地应用一键部署到任意服务器,甚至云端—— ECS、ECS、EDAS、ACK、ACR 和 小程序云 等,而且还可以通过其内嵌的 Arthas 程序诊断、 Terminal Shell 终端和 MySQL 执行器等工具,简化应用开发、测试和诊断的过程。 插件下载地址： 点击即可下载 。
部署到 任意服务器 / ECS
Cloud Toolkit 支持标准 SSH 协议,无需在一系列运维工具之间切换,只需在图形界面上选择目标服务器,即可实现应用快速部署。 部署到 容器镜像（ACR）
针对阿里云 ACR 开发者,可以将登陆、拉取、推送、选择仓库等步骤交给插件自动化,实现一键完成所有操作。 部署到 容器服务（ACK）
针对阿里云 Kubernetes 开发者, 可以将本地代码和云端容器进行关联,实现自动化的镜像上传和部署。 部署到 小程序云
针对阿里云 小程序云 开发者,可以使用 Cloud Toolkit 来部署小程序应用,适用于小程序的首次部署、快速迭代、版本回滚等场景。（小程序云应用是面向小程序的应用场景,为开发者提供的一键构建后端应用运行环境、后端服务部署、运维监控等能力的一站式小程序部署服务。） 部署到 企业级分布式应用服务 （EDAS）
针对阿里云 EDAS 开发者, 可以将本地代码和云端应用进行关联,实现自动化的部署。 部署到 Serverless 应用引擎（SAE）
针对阿里云 SAE 开发者,可以将应用快速部署到 SAE,适用于快速迭代更新应用的场景。 内置数据库 SQL Console
在 IDE 内,开发者可以浏览阿里云的 RDS 资源；同时,在配置好用户名密码之后,即可通过内置的 SQL Console 连接上 RDS 实例,并快速执行 SQL 语句。 文件上传
Cloud Toolkit 帮助开发者在 IDE 内,一键将 本地 或者 远程 URL 文件上传到服务器指定目录下去,无需在各种 FTP、SCP 工具之间频繁切换；更为重要的是,文件上传完毕后,还支持 命令执行 ,比如：文件解压缩、程序启动等。 快速创建 Dubbo 工程
使用 Cloud Toolkit 可以快速创建 Dubbo 工程,在完成 Apache Dubbo 样例工程的创建和调用验证后,可以将该工程打包（JAR 包）并部署到 EDAS 的不同集群（主要为 ECS 集群和容器服务 Kubernetes 集群）中。
程序猿吐槽大会——悬赏活动
一、我们为什么邀请你来吐槽
我们 Cloud Toolkit 团队秉承一贯的 “用户第一” 原则,希望能在一线倾听我们用户的真实声音、寻找你们的真实需求和建议,而后,我们才能在满足用户需求的基础上,为大家研发出更贴心、更高效的插件,一款真正属于广大开发者的插件。所以,我们满怀诚意地邀请您,请您说出心中对于插件的真实感受,或是吐槽,或是表扬。
二、怎么参与活动
活动时间：12月24日（本周二）——12月30日（下周一）
点击下载插件 进行体验（一键部署,不信？你更要来试试）,并在**【阿里巴巴云原生】**公众号文末留言区写下你的吐槽 / 表扬 / 挑战（任选其一）,让文章其他阅读者进行 “点赞 ”投票,或者将文章分享给同事 / 朋友进行 “点赞” 拉票。
所有人均可参与投票。 【吐槽】简单描述 Cloud Toolkit 使用槽点； 【表扬】简单描述 Cloud Toolkit 的闪光点； 【挑战】请输入你认为能够提升 Cloud Toolkit 部署效率的方法； 注意：若出现相同评论,只保留第一个人的评论,第二个人的评论无效；任何言论都要遵循真实的原则,获奖后需要提供使用插件的证明截图。
三、你能获得什么
我们 Cloud Toolkit 官方团队将接收到您的所有真心建议、真实需求,然后有针对性地研发新的功能、提升您的体验。您将获得插件 “定制化” 功能,同时,您还能获得以下奖品： 【一等奖】投票数最高的发言者,获得 Cherry机械键盘 1 个； 【二等奖】投票数第二高的发言者,获得 天猫精灵 1 个； 【三等奖】投票数第三高的发言者,获得 双肩包 1 个； 【鼓励奖】投票数前十的发言者,均可获得指尖陀螺 / 淘公仔,任选其一（前三除外）； 【参与奖】扫描下方二维码进群,艾特客服@郭伟成,即可领奖；
“ 阿里巴巴云原生 关注微服务、Serverless、容器、Service Mesh 等技术领域、聚焦云原生流行技术趋势、云原生大规模的落地实践,做最懂云原生开发者的技术圈。”
「深度学习福利」大神带你进阶工程师,立即查看>>>
点击这里,查看 具体操作步骤及剩余日志查询内容
简介 ：本文将介绍如何基于日志服务实现对 Kubernetes（以下简称 K8s）日志的采集以及查询分析,此外,还附带了对 Ingress、Audit 方案的简要介绍。为了方便大家通过操作来加深理解,本文提供了详细的操作步骤以及对应截图和配置代码。
镜像下载、域名解析、时间同步请点击 阿里巴巴开源镜像站
准备工作
为了完成后续的相关操作,我们需要准备一个 K8s 集群,操作步骤如下： 登陆 容器服务控制台 。 创建一个标准托管集群（杭州区域）,在向导中勾选上**【使用 EIP 暴露 API Server】 和 【使用日志服务】**。 集群创建完毕后,回到集群列表页面,点击**【更多->通过 CloudShell 管理集群】**。 在 CloudShell 中输入 kubectl get ds -n kube-system ,结果中显示的 logtail-ds 即为了实现数据采集所安装的日志服务组件。 打开 日志服务控制台 ,可以看到和 K8s 集群 ID 所对应的 project 也已经创建完毕。
操作截图如下：
图：创建托管集群（步骤 2）
图：打开 CloudShell（步骤 3）
图：在 CloudShell 中查看日志服务组件（步骤 4）
图：打开日志服务控制台,查看 project（步骤 5）
1. 数据采集
在 K8s 环境下,容器日志数据从大体上分为两类：容器标准输出和容器内文本文件,前者是容器特有的一种日志存在形式,后者和传统的文本文件日志类似,只是文件存放在各个容器内部,相互之间隔离。下面我们将介绍如何对这两种类型的日志进行采集。
1.1. Mock 数据
我们将使用如下两个 YAML 文件分别生成标准输出和容器内文件两种形式的 mock 数据。
容器标准输出 # 创建两个 pod 来生成 mock 数据 apiVersion: batch/v1 kind: Job metadata: name: nginx-stdout-log-demo-1 namespace: nginx-stdout spec: template: metadata: name: nginx-stdout-log-demo-1 spec: containers: - name: nginx-stdout-log-demo-1 image: registry.cn-hangzhou.aliyuncs.com/log-service/docker-log-test:latest command: ["/bin/mock_log"] args: ["--stderr=false", "--stdout=true", "--log-type=nginx", "--total-count=100000000", "--logs-per-sec=5"] restartPolicy: Never --- apiVersion: batch/v1 kind: Job metadata: name: nginx-stdout-log-demo-2 namespace: nginx-stdout spec: template: metadata: name: nginx-stdout-log-demo-2 spec: containers: - name: nginx-stdout-log-demo-2 image: registry.cn-hangzhou.aliyuncs.com/log-service/docker-log-test:latest command: ["/bin/mock_log"] args: ["--stderr=false", "--stdout=true", "--log-type=nginx", "--total-count=100000000", "--logs-per-sec=5"] restartPolicy: Never
容器内文本文件（/var/log/access.log） apiVersion: batch/v1 kind: Job metadata: name: nginx-file-log-demo namespace: nginx-file spec: template: metadata: name: nginx-file-log-demo spec: restartPolicy: Never containers: - name: nginx-file-log-demo image: registry.cn-hangzhou.aliyuncs.com/log-service/docker-log-test:latest command: ["/bin/mock_log"] args: ["--log-type=nginx", "--stdout=false", "--stderr=false", "--path=/var/log/access.log", "--total-count=100000000", "--logs-per-sec=5"]
操作步骤： 打开 CloudShell,参考准备工作中的步骤 3。 在集群中应用上面提及的两个 YAML（ Github ）。 执行 kubectl get pods 查看负责生成日志的几个 Pod。 查看两个 Pod 生成日志的情况（根据实际情况替换命令中的 pod 名） 标准输出：执行 kubectl logs -n nginx-stdout --tail=10 nginx-stdout-log-demo-1-7kvwx 。 容器内文件：执行 kubectl exec -n nginx-file nginx-file-log-demo-7frsp -- bash -c "tail /var/log/access.log" 。 $ kubectl create namespace nginx-stdout $ kubectl create -f https://raw.githubusercontent.com/goclis/kubernetes-mock-log/master/pod_nginx_stdout.yaml $ kubectl create namespace nginx-file $ kubectl create -f https://raw.githubusercontent.com/goclis/kubernetes-mock-log/master/pod_nginx_file.yaml
命令：生成 mock 数据（步骤 2） $ kubectl get pods -A NAMESPACE NAME READY STATUS RESTARTS AGE nginx-file nginx-file-log-demo-7frsp 1/1 Running 0 2m9s nginx-stdout nginx-stdout-log-demo-1-7kvwx 1/1 Running 0 2m12s nginx-stdout nginx-stdout-log-demo-2-4x7vw 1/1 Running 0 2m12s
命令：查看日志服务组件（步骤 3）
1.2. 采集标准输出
关键字：kubernetes 案例实践 日志查询
「深度学习福利」大神带你进阶工程师,立即查看>>>
微服务架构下,稳定性和高可用性一个永恒的话题,在实际的治理过程中,我们有可能会遇到以下场景： 某个应用灰度发布,先上了几台机器,由于代码逻辑写的有问题,造成线程池满,出现运行异常。 服务端集群中,某几台机器由于磁盘满,或者是宿主机资源争抢导致 load 过高,客户端出现调用超时。 服务端集群中,某几台机器由于线程池满,造成 Full Garbage Collection。
在以上 3 种场景中,由于客户端并不法感知已经出现问题的那些服务端,依然会发送请求到这些机器上,造成业务调用报错,上游的机子将会被下游的某台机子的短暂故障拖垮,造成应用雪崩的风险。
面对这种场景,如果仅仅为此而进行服务降级,对应用的伤害未免过大,但如果我们可以检测出服务集群中某些故障机子,并对其进行短暂隔离,即可有效保障服务的高可用与系统的稳定性,同时给运维人员提供了宝贵的缓冲时间,用于问题定位,排除故障。
本文将作为《微服务治理实践》系列篇的第一篇,为大家介绍如何实现离群实例摘除。该系列文章是基于阿里云商业化产品 EDAS 的微服务实践,如果您团队具备较强的微服务治理能力,那么希望我们在微服务治理方面的实践和背后的思考,可以为您提供一些参考。
企业级分布式服务 EDAS 重磅升级,12月17日下午15:00--17:00中间件小师妹在直播间等你,携开发工程师十眠为您详细介绍 EDAS 离群实例摘除等微服务治理能力。还有礼品送不停,直播间地址点击“ 传送门 ”。
Microservice Outlier Ejection （微服务离群实例摘除） 什么是离群实例摘除
当单点发生夯机异常时,consumer 能主动判断,并将对应的 provider 实例短时间剔除,不再请求,在一定时间间隔后再继续访问。同时,具有全局异常判断能力,当 provider 异常实例的数量过多时,并且超过一定的控制比例,说明此时 provide 整体服务质量低下,该机制仅保持摘除一定的比例。 离群实例摘除的功能
从服务层容错能力上,对业务稳定性进行增强,有效解决单点故障的问题。 与熔断的区别
熔断是指当服务的输入负载激增时, 避免服务被迅速压垮导致雪崩效应,而对负载进行断路的一种方式 。 熔断一般由熔断请求判断算法,熔断恢复机制,熔断报警等模块组成。隔离是指,为了避免在依赖的服务故障时候造成的故障扩散,而采取的将系统进行单元化设计的一种架构方法。
若仅仅由于服务端集群中单点异常问题,就采用熔断降级方案,将会对应用的伤害过大,离群实例摘除可以有效地解决单点异常问题从而保证服务质量。若 provider 整体服务质量低下时,离群摘除效果不再明显,此时可以采用熔断降级功能。 离群实例摘除支持的版本
只要您的应用版本在列表中,您无需改动一行代码就可以使用到离群实例摘除功能。
目前支持版本 开发中版本（即将支持）
Dubbo Spring Cloud
2.5.0～2.7.3 D、E、F、G、H
< 2.5.0 dubbox 版本 C
目前已经覆盖了市面上大部分微服务场景,后续我们将会持续支持开源最新的 Dubbo/Spring Cloud 版本。
我们提供了 Dubbo 和 Spring Cloud 两种场景的离群摘除功能,本文将先介绍一下 Dubbo Microservice Outlier Ejection 的实践与效果。
下面将通过在 EDAS 上通过演示 Dubbo 离群摘除功能及效果。
企业级分布式应用服务EDAS（Enterprise Distributed Application Service）是一个应用托管和微服务管理的 PaaS 平台,提供应用开发、部署、监控、运维等全栈式解决方案,同时支持 Dubbo、Spring Cloud 等微服务运行环境。 https://www.aliyun.com/product/edas
准备
接下来以微服务Demo为例子示范离群摘除功能,读者可以从github中下载验证 https://github.com/aliyun/alibabacloud-microservice-demo/tree/master/src
微服务Demo是一个简单的电商项目,下图为项目结构,cartservice 为 Dubbo 框架的购物车服务 provider,productservice 为Spring Cloud提供的商品详情服务 provider,frontend 为web controller即前端展示页面,可以理解为consumer。
我们将以cartservice服务即Dubbo服务端为例子,展示离群实例摘除功能。
EDAS 上部署微服务 Demo
首先 cd cartservice 切换到 cartservice 目录下,再通过 mvn clean install 打包,通过 cd cartservice-provider/target 切换到target目录下,我们可以看到新生成的 cartservice-provider-1.0.0-SNAPSHOT.jar 包,然后在 EDAS上 创建一个 cartservice 应用。
点击下一步后,上传刚才打包的jar包,即 cartservice-provider/target/ cartservice-provider-1.0.0-SNAPSHOT.jar 然后下一步,记住登陆密码,直到创建应用成功。
然后启动应用,到目前为止,我们启动了一个 cartservice-provider。点击按此实例规格扩容,该服务我们部署在两个实例上。
我们在这个 provider 的 com.alibabacloud.hipstershop.provider.CartServiceImpl 类中可以看到,这个 provider 是提供了viewCart 和 addItemToCart 的两个关于购物车的服务,我们在 viewCart 中加入一些模拟运行时异常的逻辑。 @Value("${exception.ip}") private String exceptionIp; @Override public List viewCart(String userID) { if (exceptionIp != null && exceptionIp.equals(getLocalIp())) { throw new RuntimeException("运行时异常"); } return cartStore.getOrDefault(userID, Collections.emptyList()); }
其中 exceptionIp 为 ACM 配置中心的exception.ip的配置项,若该项配置为本机ip时,该服务throw RuntimeException,用于模拟业务异常的场景。 为什么将 cartservice 扩容到两个实例,想必大家也猜到了,运行时通过配置ACM配置中心指定其中一个实例的IP,模拟出一个实例异常的场景。
接下来,我们需要部署 frontend / productservice 两个服务,方式一样,分别上传 frontend/target/frontend-1.0.0-SNAPSHOT.jar 和 productservice/productservice-provider/target/productservice-provider-1.0.0-SNAPSHOT.jar
从下图可以看到,我们的微服务Demo在EDAS部署上去了。
模拟业务异常
进入到 frontend 应用中,我们看到其实例的公网 ip 为 47.99.150.33。
进入浏览器访问 http://47.99.150.33:8080/
点击View Cart 访问至 http://47.99.150.33:8080/cart
可以看到,此时服务都是正常的。
我们去 ACM 配置中心 配置 exception.ip 为 172.16.205.180（即cartservice的其中某个实例的IP）。
然后继续访问 http://47.99.150.33:8080/cart ,发现 50 % 的概率错误页面
此时,我们写一个脚本,定时大量访问 http://47.99.150.33:8080/cart 模拟请求。 while : do result=`curl $1 -s` if [[ "$result" == *"500"* ]]; then echo `date +%F-%T` $result else echo `date +%F-%T` "success" fi sleep 0.1 done
然后 sh curlservice.sh http://47.99.150.33:8080/cart
我们看到不断重复的每秒钟 10 次的 50% 的调用成功率。
其实也可以理解到,下游的服务质量随着上游的某台机子的异常而急剧下降,甚至可能导致下游服务被上游某些机子的（系统、业务）异常给拖垮。
开启离群摘除策略
下面我将演示离群摘除的策略的开启及其效果的展示。
创建
我们进入到 EDAS 左侧列表的 [微服务管理] 下的 [离群实例摘除] 界面中,并选择创建离群实例摘除策略。
然后按照提示一步步创建离群摘除的策略。
基本信息
如上图可以选择命名空间、填写策略名称、选择该策略支持的框架类型（Dubbo/Spring Cloud）。
选择生效应用
按照目前的调用方式,我们只需要配置 frontend 应用,保护下游应用 consumer。
配置策略
这些参数都提供了默认值,需要根据自己应用的具体情况调整最合适的值,由于需要保护的 RuntimeException 属于业务异常于是选上 网络异常+业务异常。（需要注意的是即使摘除实例比例上限配得特别低,向下取整数小于1,当集群中实例数目大于1,且某一实例异常,我们也会摘除一实例）。
创建完成
可以看到策略的信息,创建完成。
策略
看到了我们创建的离群摘除策略,且是针对Dubbo框架,并且针对的是 网络异常+业务异常 的异常类型。
验证离群摘除效果
这时,我们看到,再感知到异常后,离群摘除功能生效,请求调用一阵子后,均返回正确结果。
不断刷新浏览器访问 http://47.99.150.33:8080/cart 也均正常
客户端感知到某台服务端机子异常后,主动摘除。仅仅调用业务正常的 Provider 实例,同时我们也可以通 ARMS（EDAS监控系统） 监控看到服务质量的上升,以及流量从异常 Provider 中摘除。
Dubbo框架可以从 /home/admin/.opt/ArmsAgent/logs 目录下的日志中,搜索日志中的 “OutlierRouter” 关键字可以看到一系列离群实例摘除的事件日志。
修改/关闭离群摘除策略
对于EDAS的应用我们支持通过控制台动态修改和删除离群摘除策略。 对应策略规则的修改
点击 修改生效应用 或者 编辑策略。
然后增加删除应用或者调整参数,确定后均立即生效 删除对应策略
控制台的操作,对应用中的配置都是实时生效的,若删除策略后,默认关闭相关策略。
若我们打开ARMS监控观察具体的调用情况。
ARMS监控
若我们开启监控,将会直观看到流量与请求错误等信息。
开启离群摘除前
如下图方式开启,然后跳转至ARMS（EDAS监控系统）应用监控页面,我们需要把三个应用都开启高级监控。
我们可以从下图即ARMS（EDAS监控系统）应用监控页面直观地看到结果。
从以下拓扑图中我们看到,流量不断地访问到cartservice服务上。
开启离群摘除后
离群摘除效果通过简单的例子就看到了,当然可以通过 ARMS （EDAS监控系统）的监控可以明显观察到服务质量的提升。
可以看到,在开启了离群摘除的那个点只后,错误率从50%明显下降。
其中两个小的起伏毛刺是因为,离群摘除一段时间后会重新尝试访问被摘除的 endPoint ,若依旧错误率高于阈值,继续隔离,且间隔时间更长。
离群实例摘除具体控制逻辑
前面我们看到了,离群实力摘除对应用稳定性提高带来的帮助,下面我们将具体分析离群实例摘除的控制逻辑,有助于您更好地理解其各种参数的意义,以及可以根据自己的应用情况,通过调整参数,配置出最合适自己的离群摘除策略。
对于 Dubbo/SpringCloud 框架： 默认QPS下限为1
只有当前某实例的调用QPS大于1才会开始离群实例摘除保护。 默认错误率下限 50%
只有当前某实例的调用错误率高于 50% ,则系统会认为该服务端集群的当前某实例处于异常状态。 默认摘除实例比例上限 20%
若当前服务集群中,有大于20%的实例节点处于异常状态,则系统只会摘除异常状态的实例数占集群总数的50%。 异常类型
若异常类型为 网络异常 ,则系统仅仅把网络异常的错误算进错误率统计中,忽略掉业务异常；反之,若选择了 网络异常 + 业务异常 则系统会将所有异常当成错误算进错误率统计中。 关于恢复检测单位时间（默认30000ms即30s）与未恢复累计次数上限（默认40）的解释
其中第一次摘除时长为 0.5 分钟,时间到了之后 consumer 会继续访问该 provider ,若该 provider 服务质量依旧低下,则会继续摘除,摘除时长随着连续被摘除次数的增加线性递增每次增加 0.5 分钟,每次最多摘除 20 分钟。当然,若继续调用之后,服务质量恢复了,则会当成健康服务,下一次又出现异常导致服务质量低下问题时,会重新隔离 0.5 分钟,并继续上述规则。 兜底
但是当客户端调用的服务仅有1个实例提供服务提供则不会隔离这个实例。
若当前客户端调用的服务实例大于1个,且当前离群摘除隔离比例计算出的实例数小于1,若服务端集群出现单点故障,则会摘除1个实例。
上面所有的实例可以理解为endpoint（ip+port为纬度） 通用最佳实践
可以配置相对的错误率阈值（50%）与过低的摘除实例比例上限（10%）,全链路开启。
离群实例摘除技术细节
无侵入技术
无侵入方案即通过agent技术来实现,一句话来说就是通过字节码增强技术,运行时插入我们的代码,改变应用的原有逻辑,可以理解为运行时AOP,通过在Dubbo的链路中插入Filter/Router,在Spring Cloud中增强LoadBalance逻辑,来实现我们期望的路由控制逻辑。同时因为是agent增强的,再加上 Dubbo 各个版本的链路整体基本没大的变化,Spring Cloud 模型的统一性,因此我们可以花少的代价将能力基本覆盖到所有版本。
Dubbo Agent 方案技术架构
对于用户来说,无需改动一行代码,一行配置,即可享受到稳定性增强的能力。
离群实例摘除技术
Outlier Detection 离群检测
均是基于时间窗口的数据统计。
两种实现
1、Dubbo 2.7 版本通过向链路中嵌入一个MetricsFilter,对于链路的每个request/response做打点处理,统计rt、调用成功与否、异常类型,并且已endpoint（ip+port）为key存储
2、在 Agent 底座中统计经过的http请求,通过url、rt、状态码、异常类型等数据结果,统计最近时间窗口的数据（目前写死 10 秒,暂时不透出）
实时统计前N秒的调用信息,作为离群实例摘除动作的依据。
Outlier Ejection 离群摘除
Dubbo 基于 Dubbo Router 实现,对于调用的上游服务对应的所有 invokers 中,拉黑掉“不健康”的节点,同时记录拉黑的信息。
Dubbo-Router控制逻辑
每次请求过来仅仅check一下并标记状态,后台有专门两个线程将标记的流量进行判断是否进入隔离列表或从中剔除,修改拉黑信息等耗时操作,最大程度上保证请求的实时性。
Spring Cloud 基于 扩展 LoadBalace 实现,原理相似。
原文链接
本文为阿里云内容,未经允许不得转载。
「深度学习福利」大神带你进阶工程师,立即查看>>>
属性配置文件在任何应用程序中都非常重要。它们不仅可以让应用程序具备灵活性,还能够根据文件中配置的值产生不同的功能。实际上,在staging、开发、测试、UAT或生产环境中,我们都使用属性配置文件来驱动不同的行为。
通常情况下,属性配置文件会与代码一起打包,并且整个程序包都部署在执行环境中。这一方法中,如果你想更改任何配置（即便配置文件中也发生了更改）,你需要重新发布代码。尽管这种方法行之有效,但是对于现在而言,效率还是太低了。因此我们需要一种外部化的配置。
在本文中,我将阐述Kubernetes如何为容器提供外部化、灵活的配置以及可移植性。ConfigMap主要是为了让应用程序的配置和部署解耦,这一功能可以让容器化应用程序具备可移植性。
如果你对Spring Cloud的生态很熟悉,那么接下来你会发现ConfigMap与Spring Cloud server十分类似。这里有两种使用ConfigMap的方法： 将ConfigMap作为一种环境变量 将ConfigMap挂载为文件
让我们开始进行实践！我们将使用一个简单的应用程序,基于Spring Boot、Docker和Kubernetes进行演示。
将ConfigMap作为一种环境变量
在本例中,我们将在Kubernetes中创建一个新的环境变量,并将其用于代码中。在Java中,可以通过System.getenv(String) API在代码中使用环境变量。在常规Java应用程序中,可以在J2EE应用程序容器（如Oracle WLS或IBM WAS）中设置环境变量,也可以在OS中设置环境变量。然而,在Kubernetes中情况并不相同。要使用环境变量,我们必须根据literal创建配置映射。
通过 kubectl create configmap 命令,我们创建了两个环境变量：app.name 和 app.desc。
我们来了解一下这背后发生了什么。
现在注意数据部分,在数据部分下,你会找到键值对。从技术上来说,ConfigMap仅仅是键值存储。属性的名称是键,属性的值是值。应用程序的代码会要求你查找这些键值对。
为了在Java代码中使用此环境变量,我们需要编写以下代码：
下面的代码段定义了两个K8s环境变量,分别为“ SPRING_BOOT_HELLO_WORLD_APP_NAME ”和“ SPRING_BOOT_HELLO_WORLD_DESC ”。这些变量将从ConfigMap app-env-config获取值。需要重点关注的是键。
属性配置文件可以在单个文件中保存很多个属性,以在不同环境中运行应用程序。在Spring Boot应用程序中,属性保存在classpath下的application.properties文件中。我们来看一下打包在应用程序jar包中的application.properties文件。
我们正在使用命令kubectl create configmap从单个文件或从多个文件创建ConfigMap。
现在让我们查看完整的代码。
将ConfigMap挂载为文件
在本节中,我将说明如何使用ConfigMap挂载文件以外部化配置。在此示例中,我将使用ConfigMap来外部化 application.properties 文件。即使默认文件打包在jar中,也位于src / main / resources下。简单来说,我们将通过ConfigMap所提供的文件来覆盖默认文件。
第一步是从 application.properties 创建ConfigMap。让我们了解如何在K8s中存储此ConfigMap。
通过ConfigMap,我们将挂载application.properties文件到K8s集群中,并且可以在应用程序中使用它。请注意,数据部分包含了application.properties的内容,键是文件名。
现在,为了覆盖默认配置文件,我们需要（通过ConfigMap）将application.properties挂载到应用程序的classpath中。Spring Boot通过提供不同的选项来提供这一功能。SpringApplication在以下位置从application.properties文件加载属性,并将它们添加到Spring Environment： 当前目录的/config 子目录 当前目录 classpath / config包 The classpath root
如果你想了解更多信息,可以查阅官方文档：
https://docs.spring.io/spring-boot/docs/current/reference/html/boot-features-external-config.html#boot-features-external-config-application-property-files
最简单,最好的方法是将application.properties挂载在“ / config”目录中。
仔细检查挂载路径,请注意ConfigMap的名称应与我们在上面创建的app-file-configmap完全相同,键为文件名。另外,请确保将volume mount配置的名称更改为volume配置的名称。
这段代码说明了如何在application.properties文件中定义属性。如果使用Spring推荐的标准方法的话,这十分简单。具体而言,就是使用 @Value 注释将属性值注入到变量中。
现在,我们可以继续进行ConfigMap示例应用程序了。我们来看一下完整的代码段。
让我们创建一个Docker镜像并将其上传到Dockerhub。在本例中,镜像名称是k8s-springboot-helloworld-configmap—app。
以下是K8S pod配置文件：
现在我们使用NodePort服务类型创建服务,以便可以从K8S集群外部使用Welcome服务。
现在,让我们把这些更改应用于K8S。
导航到浏览器并访问http://:/welcome。在本例,应该是http:// 192.168.99.100:30880/welcome。
认真观察输出,返回的字符串是：
同时,检查代码中硬编码的环境变量的默认值,以及打包在jar中的application.properties的property默认值。你发现从ConfigMap中获取了环境变量和application.properties的值。
这个项目可以从我的Github中获取：
https://github.com/nikhilbhide/MicroServicesTutorial/tree/master/k8s_spring_boot_hello_world_config_map
「深度学习福利」大神带你进阶工程师,立即查看>>>
作者 | 邓洪超 阿里云容器平台软件工程师 导读 ： Open Application Model（OAM） 是阿里云联合微软等国际顶级技术团队联合发布的开放应用模型技术。旨在通过全新的应用定义、运维、分发与交付模型,推动应用管理技术向“轻运维”的方向迈进,全力开启下一代云原生 DevOps 的技术革命。本《开放应用模型操作指南》系列文章,将为广大技术人员（研发、运维、基础设施工程师）提供接地气的、体系化的 OAM 操作和接入指南。
前言
自 OAM 标准推出以来,越来越多的平台和服务开始接入 OAM 标准,朝着 BaaS (Backend as a service) 化的方向迈进。在阿里巴巴集团,我们见证了 EDAS、内部中间件交付平台等以 OAM 的方式打造和推出应用交付和运维产品。并且,ROS、PolarDB 等以开放的姿态逐步接入 OAM 作为跨平台集成方案。
随着跟终端用户和平台提供方的交流日益增多,我们也同时更加清楚地了解到在 OAM 集成各个平台和服务的时候还是有一些不一致、不标准的地方。举些例子,DB 等资源创建起来后连接信息该如何暴露,已有的资源定义该如何模型化成 OAM,什么应该作为 Workload？什么应该作为 Trait 等等。这些问题在不同团队的解决方式是类似却有些许差异的,不仅造成重复劳作,实践经验也缺乏进一步沉淀。
我们希望用户去使用和接入 OAM,能够有一个统一的、清晰的流程和架构。这就是本文尝试去阐述问题、提供解法的地方。
什么人适合读这篇文章？
这篇文章主要面向服务集成方,他们希望自己的服务能够通过 OAM 去被使用。这包括： 服务提供方。比如监控服务 ARMS、日志服务 SLS、分布式追踪服务等； 平台提供方。比如 EDAS、中间件交付平台、ROS、DBaaS 等,一个平台往往包含很多服务。
用 OAM 描述云资源/服务
如果你有一个服务,怎样才能以云原生的方式暴露呢？答案就是在 Kubernetes 上提供该服务。而 OAM,正是帮助大家更好地在 K8s 上描述服务能力、实现扩平台集成的一种标准。
1. 归类 OAM 类型
首先,服务的能力需要归类为 OAM 类型中的某一种。这里有三种类型：
类型 定义 例子 Workload 能单独跑起来、单独使用的服务需要定义的类型。 DB (MySQL)、MQ (Kafka)、Cache (Redis)、Service Mesh
Trait Scope
跟运维相关的服务需要定义的类型。 囊括一组服务组件的边界。目前仅适用少数场景。
Ingress、Monitoring、Logging、服务发现、灰度发布 网络边界 (VPC、Firewall、Gateway)、健康边界 (互相关联的组件的整体健康检测)
服务提供方需要将己方服务归类为上述一种。这样能够在平台上清楚地表达自己的目的,更好地被集成和使用。
2. 编写 OAM 定义
我们通常在把一个服务归类为一种 OAM 类型之后,就会去编写这个服务的 OAM 定义。这包括两部分： 编写 OAM 定义里面的通用元数据； 编写服务自定义的 API。
服务自定义的 API 是用来描述服务对外提供的能力的 API。在这方面,我们选择使用 JSON Schema 来作为 API 描述语言,因为它是一种开放、标准的方式,在工程领域为大家所熟知。
下面,我们就分别以 Workload 和 Trait 为例,结合注释来详解如何去编写服务的 OAM 定义。
OAM Workload 例子 apiVersion: oam.dev/v1alpha1 kind: WorkloadType metadata: name: rds spec: group: alibaba.io/v1 names: [RDS] # 下面用 JSON schema 描述服务能力 settings: | { "$schema": "http://json-schema.org/draft-07/schema#", "type": "object", "required": [ "storageType" ], "properties": { "storageType": { "type": "string", "description": "The type of storage for RDS instance" } } }
OAM Trait 例子 apiVersion: core.oam.dev/v1alpha1 kind: Trait metadata: name: ManualScaler annotations: version: v1.0.0 description: "Allow operators to manually scale a workloads that allow multiple replicas." spec: appliesTo: - core.oam.dev/v1alpha1.Server - core.oam.dev/v1alpha1.Worker - core.oam.dev/v1alpha1.Task # 下面用 JSON schema 描述运维能力 properties: | { "$schema": "http://json-schema.org/draft-07/schema#", "type": "object", "required": [ "replicaCount" ], "properties": { "replicaCount": { "type": "integer", "description": "the target number of replicas to scale a component to.", "minimum": 0 } } }
3. 实现 OAM Operator
在定义了 OAM API 之后,我们还需要有实现层能让这个 spec “跑”起来。这里我们推荐实现 K8s Operator 来作为这个 OAM API 的服务。Operator 具体细节有很多文章介绍,这里不再赘述。
阿里巴巴云原生应用团队实现并开源了 OAM framework（ oam-go-sdk ）来帮助大家简化【构建 API + 实现 Operator】。
大家如果在实现 OAM Operator 过程中有什么问题,欢迎联系我们。可以在上游提 issue 或者钉钉发消息。
服务的暴露与消费
OAM 能给大家带来的一个重要好处就是能够横向联通不同平台之间的服务能力。这里我们介绍下如何实现。
在集成服务的时候,通常要做两件事情： 服务提供方需要暴露服务信息,比如 DB 连接信息写到 CMDB； 服务信息需要提供给用户应用去消费,比如将 DB 连接信息自动注入到（消费者）应用的环境变量。
当前现状是,OAM 对接的项目往往都有自己的一套系统暴露和消费服务的方式。下面我们举些例子： Service Broker 将服务信息写入到 CRD 实例状态中,然后通过工作流读取并写入应用环境变量； ROS 在 DB 模板执行完后有 outputs 属性包含服务信息,然后作为用户应用模板的参数入参； CrossPlane 在多家云厂商上提供统一的 MySQL Resource 定义,然后通过将 connection 信息写入 secret 并挂载到用户应用文件系统里。
除了上面的例子,我们还有很多其他或大或小的服务暴露与消费的例子。现在这里有一个问题,那就是不同的项目之间,没有统一的服务暴露与消费方式,导致不同的平台之间无法互通。在这里,我们希望定义一个统一的接口,让不同平台不同服务在接入 OAM 以后能够互通,更简单地透出服务能力赋能云用户。
解决思路
针对上述问题,我们接下来描述下解决思路： OAM Runtime 解析 AppConfig,发现一个 Component (微服务应用) 需要消费另一个 Component (云服务) 。于是 Runtime 需要安排好 Component 之间的创建顺序； 首先,OAM Runtime 创建云服务 Workload Component,并将相应的服务信息暴露到一个 spec 指定名字的 secret 里面去； 然后,OAM Runtime 创建微服务应用 Component,并将 spec 声明的消费内容通过名字相关联,并将 secret（通过 env、file 等方式）注入到应用中去。
整体架构图如下：
示例
下面我们通过举例来说明整个过程。
通过 CrossPlane 创建一个 CloudSQL Component: apiVersion: oam.dev/v1alpha1 kind: Component metadata: name: mysql spec: workloadType: database.cloud.io/v1beta1.CloudSQL expose: name: mysql-connection ... # 其他一些参数输入
上面我们看到 expose 字段声明了暴露信息的名字,这样做是为了让消费者能关联。具体如何暴露与消费服务信息,则是由 Runtime 层来实现。在这里,创建完 MySQL Workload 实例之后,MySQL 连接信息会被写入到一个 mysql-connection secret 里面去。
另一个应用 Web Component 则如下面定义所示来消费 MySQL： apiVersion: oam.dev/v1alpha1 kind: Component metadata: name: web spec: workloadType: Server consume: - name: mysql-connection as: env # 注入到环境变量当中。也可以设置为 file,则会注入到本地文件当中
总结
在这篇文章里,我们主要针对云服务提供方讲了如何用 OAM 描述服务能力、定义和实现相应的 OAM Runtime、以及如何通过 OAM 集成不同平台的服务。
目前,OAM 还处于一个早期阶段,阿里巴巴团队正在上游贡献和维护这套技术,希望这篇文章能给大家对于 OAM 以及如何接入云服务有更多的了解。如果大家有什么问题或者反馈,也非常欢迎跟我们在上游或者钉钉联系。
参与方式： 钉钉扫码进入 OAM 项目中文讨论群
通过 Gitter 直接参与讨论： https://gitter.im/oam-dev/
期待大家的参与！ “ 阿里巴巴云原生 关注微服务、Serverless、容器、Service Mesh 等技术领域、聚焦云原生流行技术趋势、云原生大规模的落地实践,做最懂云原生开发者的技术圈。”
「深度学习福利」大神带你进阶工程师,立即查看>>>
作者 | 孙健波、汪萌海、陈有坤、李鹏
业界要闻 CNCF 宣布 TUF 毕业
CNCF 宣布 TUF（The update Framework）项目正式毕业,成为继 Kubernetes、Premetheus、Envoy、CoreDNS、containerd、Fluentd Jaeger 以及 Vitess 之后,第九个正式毕业的项目。TUF 是一项用于保护软件更新系统的开源安全技术,也是从云原生计算基金会毕业的第一个以规范与安全性为重点的项目。与此同时,TUF 还是首个源自高校的 CNCF 毕业项目。 Istio 发布安全公告 CVE-2019-18801：该漏洞通过向下游发送 HTTP/2 大 header 请求影响 Envoy 的 HTTP/1 编解码器,利用此漏洞可能导致拒绝服务、权限逃逸或信息泄露； CVE-2019-18802：HTTP/1 编解码器没有修剪掉 header 值之后的空格,使攻击者可以绕开 Istio 的策略,最终导致信息泄露或特权升级； CVE-2019-18838：收到不带 "Host" header HTTP 请求后, Envoy 路由管理器会由于空指针导致 Envoy 进程异常终止。
解决方案 对于 Istio 1.2.x 版本：升级到 Istio 1.2.10 或以上； 对于 Istio 1.3.x 版本：升级到 Istio 1.3.6 或以上； 对于 Istio 1.4.x 版本：升级到 Istio 1.4.2 或以上。 2020 年 Service Mesh 三大发展趋势 随着 Kubernetes 的愈发普及和标准化,应用场景越来越复杂,服务网格的需求会快速增加； Istio 的先发优势会越来越明显,以至于它很难被击败,因为越来越多的软件供应商会提供 Istio 的解决方案； 更多的使用场景会出现,目前服务网格的使用场景主要在 "mTLS（统一鉴权解决方案）",“应用可观测性解决方案”,“流量管理解决方案”,2020 年会出现服务网格技术的杀手级解决方案。
上游重要进展
Kubenetes add KEP: Node Maintenance Lease
增加用于 Node 协作的租约,该提案主要解决的是多个组件对 Node 均有操作,加锁独占的问题,比如在线 debug Node 问题的时候,又比如 Node 更新系统起作用的时候,不希望 Node 快照备份系统起作用。 K8s 调度器升级计划进入到阶段二 一阶段是构建了新的调度框架,目标是把 scheduler 变成一个执行不同扩展插件的 callback 的引擎,可以注册 callback 函数,把一系列调度计算、预测相关的函数作为 plugin； 二阶段 的主要目标是把原先内置在 K8s scheduler 里面的预测和调度算法移入对应的 plugin 中通过调度框架调用,许多 PR 围绕该目标在展开。 K8s 社区子项目 rktlet 正式被归档
rktlet 是基于容器运行时 rkt 项目 的 CRI（Container Runtime Interface） 实现,类似 kubelet,随着 rkt 项目退出 CNCF,rktlet 也无人维护,如今正式被移出。
Knative Knative serving PodSpec 功能性
在 Knative 中,RevisionTemplateSpec 像 PodSpec 的一个子集,只实现了部分功能。为了保持 Knative 的简易性,哪些字段需要加,哪些字段不需要加,文档中列出了一些条件。另外针对运维角色,有些字段不是面向开发的,但 K8s 都把字段暴露出来了,K8s 这样做不意味着 Knative 也需要这样做,可以把它作为一个 Configmap 的配置值或者新增运维的 CRD。 关于事件域 Eventing domains
在事件系统中,事件生产者和消费者通常不直接通信。在许多情况下,都涉及充当事件总线的消息中间件。通过这种方式,可以对事件进行集中管理,消费者和生产者可以发出和订阅哪些内容,并且可以设置过滤器或策略。因此,引入了事件域的定义。
Istio 社区在讨论如何缓解 Istio CNI 竞争问题
Istio CNI 竞争问题是指在通过使用 Istio CNI 插件配置容器网络安装 iptables 规则时,可能会遇到应用程序的 pod 在 Istio CNI 配置完成之前就启动,导致出现没有配置 iptables 规则的应用程序 pod 出现,这会导致安全问题,因为可以绕开所有的 Istio 策略检查。
社区讨论了可能在 Istio1.5 中提供的短期方案,并提出长期方案是希望 K8s 提供标准方法：在节点调度 Pod 之前,确保关键守护程序已经准备好；如果关键守护程序失败,请污染节点。后续将与 K8s 社区继续讨论。
开源项目推荐 OAM Go SDK
基于OAM（开放应用模型）的 Go 语言 SDK,SDK 中包含了 OAM Spec 的解析和 Controller 框架,可以快速构建 OAM 的实现,快速对接标准应用模型。 Vault
Vault 是 HashiCorp公司（旗下还有Vagrant,Terraform,Consul 等知名产品）维护的开源软件,它的设计思想基于云原生背景下动态基础设施的特点,在云上的不同网络层以及不同的服务之间已经很难找到传统的信任边界,服务之间更加强调以身份（identity）为核心的认证和访问控制,而不是像传统静态基础设施中以 IP、主机地址作为信任凭证（ 与 K8s 对接 ）。 kube-score
kube-score 是 K8s 对象静态检查工具,通过分析 K8s 对象的 Yaml 文件做一些推荐,以提升可靠性和安全性。
本周阅读推荐 《The Open Application Model from Alibaba's Perspective》
InfoQ 国际总站发表文章《阿里巴巴视角下的开放应用模型》,详细讲述了 OAM 的由来以及阿里巴巴在 K8s 应用管理上的实践。 《Dynamic Database Credentials with Vault and Kubernetes》
使用 Vault 在 Kubernetes 体系中提供动态数据库鉴权信息,文中针对云原生场景下 Pod 生命周期短、变化快等问题,Vault 提供了一系列 Policy 解决动态鉴权信息注入的问题。 《Debugging and Monitoring DNS issues in Kubernetes》
在 Kubernetes 上 debug DNS 问题的指南。 《将 Sidecar 容器带入新的阶段 | KubeCon NA 2019》
本文介绍了蚂蚁金服和阿里巴巴集团场景下对 Sidecar 容器的各种使用方式。 《容器十年：隔离性、效率与兼容性》
从 2008 年基于内核 cgroup 的 LXC 诞生至今,现代 Linux 的容器化已逾 10 年,先后有基于 cgroup/namespace 的进程隔离容器技术、基于 CPU 硬件指令集的虚拟化技术,以及通过重写内核功能实现的用户空间内核容器技术纷纷登场,各有千秋。 《StackRox 2020 预测：从 Kubernetes 到 DevOps》
StackRox 的联合创始人,首席技术官Ali Golshan 对 2020 年技术发展做了一些预测,这些预测涉及 Kubernetes 和服务网格技术的增长。 “ 阿里巴巴云原生 关注微服务、Serverless、容器、Service Mesh 等技术领域、聚焦云原生流行技术趋势、云原生大规模的落地实践,做最懂云原生开发者的技术圈。”
「深度学习福利」大神带你进阶工程师,立即查看>>>
虽然说经过十几年的发展 云桌面 现在的技术已经很成熟了,但是很多人都知道就桌面的性能和外设的兼容性来说它还是无法跟传统PC相比的,为什么很多人明明知道云桌面的性能不是很好也有不少的坑,但是仍然坚持选择使用云桌面的呢？
首先功能基本满足,虽然说云桌面的性能是相对较差,但这也只是局限于3D应用方面的处理能力比传统PC差的,对于其他方面的功能和应用来说并不弱的,已经能满足大多数的办公需求的。也就是说除了一些特殊的应用场景云桌面的性能可能无法满足之外,其他的一些应用场景如学校云计算机教室、企业办公等应用对于云桌面来说是没有多大难度的。
其次使用成低,传统的PC配置和性能是很高,但是相对来说它的使用成本也高的,除了前期的投入成本之外,它的使用功耗平均在200W左右耗电量大,而且随着数量和使用年限的增加,硬件和系统故障率也高的,而这些问题都将增加后期在使用上的成本。而云桌面采用功耗更低的云终端,平均功耗不超过5W,每年可以节省95%左右的用电成本,同时服务器和云终端故障率低,云终端不需要维护,这都降低企业的使用上的成本。
其次管理维护方便,云桌面采用的是集中管理和计算的方式,所有的数据和计算都通过服务器来进行,终端桌面需要进行系统的升级、软件的安装等工作时,运维人员都可在服务器上安装,而且是全部桌面可以一起操作而无需一台一台的去进行管理维护,而这对于在本地计算和存储的传统PC来说是无法实现的。
第三数据安全可靠,对于有些人来说可能会觉得桌面的性能才是最重要的,但是对于大多数的用户来说数据的安全性才是最重要的,传统PC性能固然强大,但是它并不能很好的进行数据的管控和限制用户拷贝和访问重要数据。而云桌面的数据都集中在云端服务器上,数据不落地,任何人访问数据都需要授权许可的,同时禁止U盘等存储设备接入云终端直接拷贝数据存储,加强数据的安全管理。
虽然说云桌面现在的性能是无法和传统的PC相比,而且很多人也都知道这一点,但是这并妨碍用户选择它的,因为除了在性能这一点无法和传统PC相比之外,其他的功能并不比PC差甚至更好的。
来源禹龙云
「深度学习福利」大神带你进阶工程师,立即查看>>>
嘿~今年快结束了时间过得真快呀
转眼就到年尾了小编掐指一算
emm...年初立下的学习Flag
估计是大概率都没实现吧？
为了缓解大家的“年终焦虑”
为了扶起摇摇欲坠的“2019Flag”
【 京东云培训与认证 】将于明天正式上线！（可点击左侧链接查看哦）
首次上线的课程有
“JCA京东云云计算助理工程师”培训认证
“JAC京东云运维助理工程师”培训认证
值此圣诞佳节
小编专门为大家要到了
“JCA云计算助理工程师”圣诞浓缩版试题
港真,尝试做了一遍的小编已头秃工作数年的你会不会连云计算 助理级 工程师都够不着？不信就来试试看咯~
👇👇👇 扫描下方二维码,参与测试
还将有机会获得我们送出的圣诞大礼包哦！
圣诞礼包投放中...
答题时间 ：2019年12月25日-12月30日18：00
获奖公布 ：2019年12月30日
领取规则 ：扫描下方二维码--参与“JCA云计算助力工程师”测试（圣诞浓缩版）--获得分数后截屏,发送截图至公众号后台兑奖
礼品列表 ：
1、 100分 ：价值800元的培训&认证（前3名回复者）
2、 80-99分 ：价值430元的 5章【JCA精选课程】大礼包（前10名回复者）
3、 60-80分 ：价值199元的京东云定制小音箱（前15名回复者）
4、 60以下 ：要什么“自行车”,快点击 【 京东云培训与认证 】 报名学习吧
关于京东云的培训与认证
京东云云计算助理工程师认证（JCA） 及 京东云运维助理工程师认证（JCA） 为京东云基础产品用户和运维人员提供专业技术认证,该项认证内容包括京东云的计算服务、网络服务、存储服务及安全等方面的核心产品,是对从业人员或希望进入云行业人员的专业性技能认证。通过认证,帮助学习者了解京东云产品、服务和通用解决方案,掌握基本云计算相关知识与技能,对京东云基础产品进行运维管理,保障企业及个人云上业务正常稳定运行
完成学习认证后,你将获得：
想了解关于京东云更多资讯吗,快快点击 【 阅读 】 了解更多课程培训&认证详情~
Merry Christmas
「深度学习福利」大神带你进阶工程师,立即查看>>>
多租户技术（英语：multi-tenancy technology）或称多重租赁技术,是一种软件架构技术,它是在探讨与实现如何于多用户的环境下共享相同的系统或程序组件,并且仍可确保各用户间数据的隔离性。
由于云计算议题的发烧,在共享的数据中心内如何以单一系统架构与服务提供多数客户端相同甚至可定制的服务,并且仍然可以保障客户的数据隔离,让多租户技术成为云计算技术下的显学。
历史
多租户技术源于1960年代,许多公司为了要使用更多的运算资源,向持有大型主机（Mainframe）的供应商租用一部分的运算资源,而这些用户经常会用到相同的应用程序,当时会以用户在登录系统时输入的数据来决定用户的账户ID,基于这个ID,Mainframe的供应商即可利用此ID来计算运算的资源使用量,包含CPU,存储器与磁盘或磁带等,这个作法也被SAP公司用在其R/1到R/3的产品线。
到了1990年代,应用程序服务提供者服务（application service provider）模式出现,它的作法与运作模式与租用大型主机时相同,不过租用的资源是在软件上,除了操作系统以外也包含了其上的应用程序,例如ERP系统或是CRM等应用,系统可能会运行在数台不同的机器上,或是在相同的主机但共享不同的数据库,以区分并计算客户的资源使用量,藉以作为计费的标准,而此技术也有效的缩减供应商的实体机器成本（因为可以在一台电脑上同时运行多个用户所租用的应用程序行程）。到了现代,受欢迎的消费者导向Web应用程序（如Hotmail或Gmail等）也是以单一应用程序平台来支持所有的用户,这已经是多租户技术的自然演化的结果,多租户技术也可以让客户中的一部分用户得以进一步定制他们的应用程序。
在虚拟化（virtualization）技术的成熟与应用性的扩张之下,多租户技术可以驾驭虚拟化的平台,更强化在用户应用程序与数据之间的隔离,让多租户技术能更加发挥它的特色。
概念和技术
在多租户技术中,租户（tenant）是指使用系统或电脑运算资源的客户,但在多租户技术中,租户包含在系统中可识别为指定用户的一切数据,举凡账户与统计信息（accounting data）,用户在系统中建置的各式数据,以及用户本身的客制化应用程序环境等,都属于租户的范围,而租户所使用的则是基于供应商所开发或建置的应用系统或运算资源等,供应商所设计的应用系统会容纳数个以上的用户在同一个环境下使用,为了要让多个用户的环境能力同一个应用程序与运算环境上使用,则应用程序与运算环境必须要特别设计,除了可以让系统平台可以允许同时让多份相同的应用程序运行外,保护租户数据的隐私与安全也是多租户技术的关键之一。
技术上,多租户技术可以透过许多不同的方式来切割用户的应用程序环境或数据。 数据面（data approach）：供应商可以利用切割数据库（database）,切割存储区（storage）,切割结构描述（schema）或是表格（table）来隔离租户的数据,必要时会需要进行对称或非对称加密以保护敏感数据,但不同的隔离作法有不同的实现复杂度与风险。 程序面（application approach）：供应商可以利用应用程序挂载（hosting）环境,于行程（process）上切割不同租户的应用程序运行环境,在无法跨越行程通信的情况下,保护各租户的应用程序运行环境,但供应商的运算环境要够强。 系统面（system approach）：供应商可以利用虚拟化技术,将实体运算单元切割成不同的虚拟机,各租户可以使用其中一至数台的虚拟机来作为应用程序与数据的保存环境,但对供应商的运算能力要更要求。
实现方式
多租户技术的实现重点,在于不同租户间应用程序环境的隔离（application context isolation）以及数据的隔离（data isolation）,以维持不同租户间应用程序不会相互干扰,同时数据的保密性也够强。
应用程序部分：透过行程或是支持多应用程序同时运行的装载环境（例如Web Server,像是Apache或IIS等）来做行程间的隔离,或是在同一个伺服程序（server）行程内以线程的方式隔离。 数据部分：透过不同的机制将不同租户的数据隔离,Force.com是采用中介数据（metadata）的技术来切割,微软 MSDN 的技术文件则是展示了使用结构描述的方式隔离。
特色
多租户技术有下列特色： 由于多租户技术可以让多个租户共享一个应用程序或运算环境,且租户大多不会使用太多运算资源的情况下,对供应商来说多租户技术可以有效的降低环境建置的成本。包含硬件本身的成本,操作系统与相关软件的授权成本都可以因为多租户技术,而由多个租户一起分担。 透过不同的数据管理手段,多租户技术的数据可以用不同的方式进行数据隔离,在供应商的架构设计下,数据的隔离方式也会不同,而良好的数据隔离法可以降低供应商的维护成本（包含设备与人力）,而供应商可以在合理的授权范围内取用这些数据分析,以作为改善服务的依据。 多租户架构下所有用户都共享相同的软件环境,因此在软件改版时可以只发布一次,就能在所有租户的环境上生效。 具多租户架构的应用软件虽可客制,但客制难度较高,通常需要平台层的支持与工具的支持,才可降低客制化的复杂度。
应用
多租户技术在实务上运用的成功且广为人知的案例之一,是由Salesforce.com所建置的CRM应用系统,该公司除了Salesforce.com的CRM软件以外,它还建置了Force.com平台即服务（PaaS）架构,以支持开发人员发展基于Force.com平台上的应用程序。
在云计算的加持之下,多租户技术被广为运用于开发云端各式服务,不论是IaaS,PaaS还是SaaS,都可以看到多租户技术的影子。 本文由博客一文多发平台 OpenWrite 发布！
「深度学习福利」大神带你进阶工程师,立即查看>>>
点击下载《不一样的 双11 技术：阿里巴巴经济体云原生实践》
作者 | 杨育兵（沈陵） 阿里巴巴高级技术专家
我们从 2016 年开始在集团推广全面的镜像化容器化,今年是集团全面镜像化容器化后的第 4 个 双11,PouchContainer 容器技术已经成为集团所有在线应用运行的运行时底座和运维载体,每年 双11 都有超过百万的 PouchContainer 容器同时在线,提供电商和所有相关的在线应用平稳运行的载体,保障大促购物体验的顺滑。
我们通过 PouchContainer 容器运行时这一层标准构建了应用开发和基础设施团队的标准界面,每年应用都有新的需求、新的变化,同时基础设施也有上云/混部/神龙/存储计算分离/网络变革这些升级,两边平行演进,互不干扰。技术设施和 PouchContainer 自身都做了很大的架构演进,这些很多的架构和技术演进对应用开发者都是无感知的。
在容器技术加持的云原生形成趋势的今天,PouchContainer 容器技术支持的业务方也不再只有集团电商业务和在线业务了,我们通过标准化的演进,把所有定制功能做了插件化,适配了不同场景的需要。除了集团在线应用,还有运行在离线调度器上面的离线 job 类任务、跑在搜索调度器上面的搜索广告应用、跑在 SAE/CSE 上面的 Serverless 应用、专有云产品及公有云（ACK+CDN）等场景,都使用了 PouchContainer 提供的能力。
运行时的演进
2015 年之前,我们用的运行时是 LXC,PouchContainer 为了在镜像化后能够平滑接管原来的 T4 容器,在 LXC 中支持新的镜像组装方式,并支持交互式的 exec 和内置的网络模式。
随着云原生的进程,我们在用户无感知的情况下对运行时做了 containerd+runc 的支持,用标准化的方式加内部功能插件,实现了内部功能特性的支持和被各种标准化运维系统无缝集成的目标。
无论是 LXC 还是 runc 都是让所有容器共享 Linux 内核,利用 cgroup 和 namespace 来做隔离,对于强安全场景和强隔离场景是不适用的。为了容器这种开发和运维友好的交付形式能给更多场景带来收益,我们很早就开始探索这方面的技术,和集团 os 创新团队以及蚂蚁 os 虚拟化团队合作共建了 kata 安全容器和 gvisor 安全容器技术,在容器生态嫁接,磁盘、网络和系统调用性能优化等方面都做了很多的优化。在兼容性要求高的场景我们优先推广 kata 安全容器,已经支持了 SAE 和 ACK 安全容器场景。在语言和运维习惯确定的场景,我们也在 618 大促时上线了一些合适的电商使用了 gvisor 的运行时隔离技术,稳定性和性能都得到了验证。
为了一部分专有云场景的实施,我们今年还首次支持了 Windows 容器运行时,在容器依赖相关的部署、运维方面做了一些探索,帮助敏捷版专有云拿下了一些客户。
除了安全性和隔离性,我们的运行时演进还保证了标准性,今年最新版本的 PouchContainer 把 diskquota、lxcfs、dragonfly、DADI 这些特性都做成了可插拔的插件,不需要这些功能的场景可以完全不受这些功能代码的影响。甚至我们还对一些场景做了 containerd 发行版,支持纯粹的标准 CRI 接口和丰富的运行时。
镜像技术的演进
镜像化以后必然会引入镜像分发的效率方面的困难,一个是速度另一个是稳定性,让发布扩容流程不增加太多时间的情况下,还要保证中心节点不被压垮。 PouchContainer 在一开始就支持了使用 Dragonfly 来做 P2P 的镜像分发,就是为了应对这种问题,这是我们的第一代镜像分发方案。在研发域我们也对镜像分层的最佳实践做了推广,这样能最大程度的保证基础环境不变时每次下载的镜像层最小。镜像加速要解决的问题有：build 效率、push 效率、pull 效率、解压效率以及组装效率。第一代镜像加速方案,结合 Dockerfile 的最佳实践解决了 build 效率和 pull 效率和中心压力。
第一代镜像分发的缺点是无论用户启动过程中用了多少镜像数据,在启动容器之前就需要把所有的镜像文件都拉到本地,在很多场景下都是浪费的,特别影响的是扩容场景。所以第二代的镜像加速方案,我们调研了阿里云的盘古,盘古的打快照、mount、再打快照这种使用方式完美匹配打镜像和分发的流程；能做到秒级镜像 pull,因为 pull 镜像时只需要鉴权,下载镜像 manifest,然后 mount 盘古,也能做到镜像内容按需读取。
2018 年 双11,我们小规模上线了盘古远程镜像,也验证了我们的设计思路,这一代的镜像加速方案结合新的 overlay2 技术在第一代的基础上又解决了PouchContainer 效率/pull 效率/解压效率和组装效率。
但是也存在一些问题。首先镜像数据没有存储在中心镜像仓库中,只有 manifest 信息,这样镜像的分发范围就受限,在哪个盘古集群做的镜像,就必须在那个盘古集群所在的阿里云集群中使用这个镜像；其次没有 P2P 的能力,在大规模使用时对盘古后端的压力会很大,特别是离线场景下由于内存压力导致很多进程的可执行文件的 page cache 被清理,然后需要重新 load 这种场景,会给盘古后端带来更大的压力。基于这两个原因,我们和 ContainerFS 团队合作共建了第三代镜像分发方案：DADI（基于块设备的按需 P2P 加载技术,后面也有计划开源这个镜像技术）。
DADI 在构建阶段保留了镜像的多层结构,保证了镜像在多次构建过程中的可重用性,并索引了每个文件在每层的offset 和 length,推送阶段还是把镜像推送到中心镜像仓库中,保证在每个机房都能拉取到这个镜像。在每个机房都设置了超级节点做缓存,每一块内容在特定的时间段内,都只从镜像仓库下载一次。如果有时间做镜像预热,像 双11 这种场景,预热阶段就是从中心仓库中把镜像预热到本地机房的超级节点,后面的同机房的数据传输会非常快。镜像 pull 阶段只需要下载镜像的 manifest 文件（通常只有几 K大小）,速度非常快,启动阶段 DADI 会给每个容器生成一个块设备,这个块设备的 chunk 读取是按需从超级节点或临近节点 P2P 读取的内容,这样就保证了容器启动阶段节点上只读取了需要的部分内容。为了防止容器运行过程中出现 iohang,我们在容器启动后会在后台把整个镜像的内容全部拉到 node 节点,享受超快速启动的同时最大程度地避免后续可能出现的 iohang。
使用 DADI 镜像技术后的今年 双11 高峰期,每次有人在群里面说有扩容任务,我们值班的同学去看工单时,基本都已经扩容完成了,扩容体验做到了秒级。
网络技术演进
PouchContainer 一开始的网络功能是揉合在 PouchContainer 自己的代码中的,用集成代码的方式支持了集团各个时期的网络架构,为了向标准化和云原生转型,在应用无感知的情况下,我们在 Sigma-2.0 时代使用 libnetwork 把集团现存的各种网络机架构都统一做了 CNM 标准的网络插件,沉淀了集团和专有云都在用的阿里巴巴自己的网络插件。在在线调度系统推广期间,CNM 的网络插件已经不再适用,为了不需要把所有的网络插件再重新实现一遍,我们对原来的网络插件做了包装,沉淀了 CNI 的网络插件,把 CNM 的接口转换为 CNI 的接口标准。
内部的网络插件支持的主流单机网络拓扑演进过程如下图所示：
从单机拓扑能看出来使用神龙 eni 网络模式可以避免容器再做网桥转接,但是用神龙的弹性网卡和CNI网络插件时也有坑需要避免,特别是 eni 弹性网卡是扩容容器时才热插上来的情况时。创建 eni 网卡时,udevd 服务会分配一个唯一的 id N,比如 ethN,然后容器 N 启动时会把 ethN 移动到容器 N 的 netns,并从里面改名为 eth0。容器 N 停止时,eth0 会改名为 ethN 并从容器 N 的 netns 中移动到宿主机的 netns 中。
这个过程中,如果容器 N 没有停止时又分配了一个容器和 eni 到这台宿主机上,udevd 由于看不到 ethN 了,它有可能会分配这个新的 eni 的名字为 ethN。容器 N 停止时,把 eth0 改名为 ethN 这一步能成功,但是移动到宿主机根 netns 中这一步由于名字冲突会失败,导致 eni 网卡泄漏,下一次容器 N 启动时找不到它的 eni 了。可以通过修改 udevd 的网卡名字生成规则来避免这个坑。
运维能力演进
PouchContainer 容器技术支持了百万级的在线容器同时运行,经常会有一些问题需要我们排查,很多都是已知的问题,为了解决这个困扰,我还写了 PouchContainer 的一千个细节以备用户查询,或者重复问题问过来时直接交给用户。但是 PouchContainer 和相关链路本身稳定性和运维能力的提升才是最优的方法。今年我们建设了 container-debugger 和 NodeOps 中心系统,把一些容器被用户问的问题做自动检测和修复,任何修复都做了灰度筛选和灰度部署能力,把一些经常需要答疑的问题做了用户友好的提示和修复,也减轻了我们自身的运维压力。
内部的中心化日志采集和即时分析 自带各模块的健康和保活逻辑 所有模块提供 Prometheus 接口,暴露接口成功率和耗时 提供常见问题自动巡检修复的工具 运维经验积累,对用户问题提供修复建议 提供灰度工具,任何变更通过金丝雀逐步灰度 剖析工具,流程中插入代码的能力 Pouch 具备一键发布能力,快速修复
容器使用方式演进
提供容器平台给应用使用,在容器启动之前必然有很多平台相关的逻辑需要处理,这也是我们以前用富容器的原因。 安全相关：安全路由生成、安全脚本配置 cpushare 化相关配置：tsar 和 nginx 配置 运维agent 更新相关：运维agent 更新相对频繁,基础镜像更新特别慢,不能依赖于基础镜像更新来更新运维agent 配置相关逻辑：同步页头页尾,隔离环境支持, 强弱依赖插件部署 SN 相关：模拟写 SN 到/dev/mem,保证 dmidecode 能读到正确的 SN 运维相关的的 agent 拉起,很多运维系统都依赖于在节点上面有一个 agent,不管这个节点是容器/ecs 还是物理机 隔离相关的配置：比如 nproc 这个限制是在用户上面的,用统一个镜像的容器不能使用统一 uid 不然无法隔离 nproc 现在随着基于 K8s 编排调度系统的推广,我们有了 Pod 能力,可以把一些预置逻辑放到前置 hook 中去执行,当然富容器可以瘦下来,还要依赖于运维 agent 可以从主容器中拆出来,那些只依赖于 volume 共享就能跑起来的 agent 可以先移动到 sidecar 里面去,这样就可以把运维容器和业务主容器分到不同的容器里面去,一个 Pod 多个容器在资源隔离上面分开,主容器是 Guaranteed 的 QOS,运维容器是 Burstable 的 QOS。同时在 kubelet 上支持 Pod 级别的资源管控,保证这个 Pod 整体是 Guaranteed 的同时,限制了整个 pod 的资源使用量不超过应用单实例的申请资源。
还有一些 agent 不是只做 volume 共享就可以放到 sidecar 的运维容器中的,比如 arthas 需要能 attach 到主容器的进程上去,还要能 load 主容器中非 volume 路径上面的 jar 文件才能正常工作。对于这种场景 PouchContainer 容器也提供了能让同 Pod 多容器做一些 ns 共享的能力,同时配合 ns 穿越来让这些 agent 可以在部署方式和资源隔离上是和主容器分离的,但是在运行过程中还可以做它原来可以做的事情。
容器技术继续演进的方向
可插拔的插件化的架构和更精简的调用链路在容器生态里面还是主流方向,kubelet 可以直接去调用 pouch-containerd 的 CRI 接口,可以减少中间一个组件的远程调用,不过 CRI 接口现在还不够完善,很多运维相关的指令都没有,logs 接口也要依赖于 container API 来实现,还有运行环境和构建环境分离,这样用户就不需要到宿主机上面执行 build。所有的运维系统也不再依赖于 container API。在这些约束下我们可以做到减少对一个中间组件的系统调用,直接用 kubelet 去调用 pouch-containerd 的 CRI 接口。
现在每个应用都有很多的 Dockerifle,怎么让 Dockerfile 更有表达能力,减少 Dockerfile 数量。构建的时候并发构建也是一个优化方向,buildkit 在这方面是可选的方案,Dockerfile 表达能力的欠缺也需要新的解决方案,buildkit 中间态的 LLB 是 go 代码,是不是可以用 go 代码来代替 Dockerfile,定义更强表达能力的 Dockerfile 替代品。
容器化是云原生的关键路径,容器技术在运行时和镜像技术逐渐趋于稳定的情况下,热点和开发者的目光开始向上层转移,K8s 和基于其上的生态成为容器技术未来能产生更多创新的领域,PouchContainer 技术也在向着更云原生、更好适配 K8s 生态的方向发展,网络、diskquota、试图隔离等 PouchContainer 的插件,在 K8s 生态系统中适配和优化也我们后面的方向之一。
本书亮点 双11 超大规模 K8s 集群实践中,遇到的问题及解决方法详述 云原生化最佳组合：Kubernetes+容器+神龙,实现核心系统 100% 上云的技术细节 双 11 Service Mesh 超大规模落地解决方案 “ 阿里巴巴云原生 关注微服务、Serverless、容器、Service Mesh 等技术领域、聚焦云原生流行技术趋势、云原生大规模的落地实践,做最懂云原生开发者的技术圈。”
「深度学习福利」大神带你进阶工程师,立即查看>>>
在kubernetes环境中,现如今我们对外提供服务我们使用较多的是ingress方案。但对于很多已经长期使用nginx作为反向代理的用户而言,要将复杂的配置迁移到nginx ingress上显然非常麻烦。
所以,对于更广大的用户而言,将nginx的配置信息直接移植到镜像中,然后通过良好的版本管理来进行滚动迭代发布。这样就弥补了相比较于ingress每次更新都要手动做镜像再进行发布的劣势,反而体现了版本管理的优势。
同时,借鉴各厂商ingress controller的解决方案,daemonset+hostport能够保证请求更快更直接的发送到对应的反向代理,从而提高吞吐效率。
接下来我们介绍下如何使用daemonset+hostport实现类ingress的负载均衡服务。
1.测试站点：
首先我们做两个镜像,访问直接返回foo1,以及foo2
2.发布测试站点：
foo1-pod.yaml apiVersion: v1 kind: Pod metadata: name: mytest-site-foo1 labels: app: mytest-site-foo1 spec: containers: - name: mytest-site-foo1 image: 192.168.1.242:5000/mytest-site-foo1
foo1-svc.yaml apiVersion: v1 kind: Service metadata: name: mytest-site-foo1-svc labels: app: mytest-site-foo1-svc spec: selector: app: mytest-site-foo1 type: ClusterIP ports: - protocol: TCP port: 8009 targetPort: 80
再进行发布 kubectl apply -f foo1-pod.yaml;kubectl apply -f foo1-svc.yaml
按照上面的文件再写foo2-pod.yaml,foo2-svc.yaml,并进行发布。
2.制作前端nginx镜像：
nginx的配置文件default.conf： server { listen 80; server_name localhost; #charset koi8-r; access_log /var/log/nginx/host.access.log main; location /foo1 { proxy_pass http://mytest-site-foo1-svc:8009/; } location /foo2 { proxy_pass http://mytest-site-foo2-svc:8009/; } location / { root /var/www/html; } }
再编写dockerfile（当然如果配置文件多可以做成目录一并添加到nginx镜像中）： FROM nginx:latest ADD default.conf /etc/nginx/conf.d/ ENTRYPOINT nginx -c /etc/nginx/nginx.conf && tail -f /dev/null
创建镜像并上传到registry：
制作镜像：docker build -t mytest-site-nginx .
打tag：docker tag mytest-site-nginx 192.168.1.244:5000/mytest-site-nginx
上传：docker push 192.168.1.244:5000/mytest-site-nginx
3.发布nginx
有了对应的镜像,我们就能将nginx以daemonset的方式发布到各个节点。
mytest-site-nginx-ds.yaml: apiVersion: apps/v1 kind: DaemonSet metadata: name: mytest-site-nginx-ds labels: app: mytest-site-nginx-ds spec: template: metadata: labels: app: mytest-site-nginx-ds spec: containers: - name: mytest-site-nginx image: 192.168.1.242:5000/mytest-site-nginx:latest ports: - name: http hostPort: 80 protocol: TCP containerPort: 80 selector: matchLabels: app: mytest-site-nginx-ds
kubectl apply -f mytest-site-nginx-ds.yaml
接下来我们就能用http协议访问各个节点/foo1以及/foo2来访问后端实际运行的网站。
4.如何更新
首先将我们的dockerfile以及配置文件放置到gitlab上。
发布时实现:
下载配置代码->构建镜像->上传镜像->kubectl set image进行发布。
同时可以利用git的版本tag或者kubernetes的roll back进行版本回滚。
「深度学习福利」大神带你进阶工程师,立即查看>>>
作者 | 丁宇（叔同） 阿里云智能容器平台负责人 、刘丹
2019 年阿里巴巴 双11 核心系统 100% 以云原生的方式上云,完美支撑了 54.4w 峰值流量以及 2684 亿的成交量。随着阿里巴巴经济体云原生技术的全面升级,容器性能、稳定性及在线率也得到了全面提升。本文作者将从云计算时代容器的发展路径为出发点,剖析阿里云的容器技术演进历程,借此探析整个行业的发展趋势。
以容器为代表的云原生技术,成为云时代释放云价值的最短路径
过去我们常以虚拟化作为云平台和与客户交互的界面,为企业带来灵活性的同时也带来一定的管理复杂度；容器的出现,在虚拟化的基础上向上封装了一层,逐步成为云平台和与客户交互的新界面之一,应用的构建、分发和交付得以在这个层面上实现标准化,大幅降低了企业 IT 实施和运维成本,提升了业务创新的效率。
从技术发展的维度看,开源让云计算变得越来越标准化,容器已经成为应用分发和交付的标准,可以将应用与底层运行环境解耦；Kubernetes 成为资源调度和编排的标准,屏蔽了底层架构的差异性,帮助应用平滑运行在不同的基础设施上；在此基础上建立的上层应用抽象如微服务和服务网格,逐步形成应用架构现代化演进的标准,开发者只需要关注自身的业务逻辑,无需关注底层实现,云原生正在通过方法论、工具集和理念重塑整个软件技术栈和生命周期。
“以容器为代表的云原生技术,用开放、标准的技术体系,帮助企业和开发者在云上构建和运行可弹性扩展、容错性好、易于管理、便于观察的系统,已经成为释放云价值的最短路径。”在提及容器演进历程中叔同强调道。最早创造和应用容器技术的是互联网公司,今天有了开放标准的云原生生态,使得容器技术得到迅速普及,越来越多的企业和开发者使用容器构建应用,共同享受这一技术红利。
目前企业级用户对于容器技术有何新的需求呢？对此,叔同表示： 云原生应用落地过程中,安全性是企业用户最为关注的需求之一。 传统的 RunC 容器与宿主机 Linux 共享内核,通过 CGroup 和 namespace 提供有限的隔离性,随着越来越多的企业客户开始关注容器安全,近两年新型高隔离、安全的运行时开始出现,包括 MircoVM (Kata Container、FireCracker) 方向和 gVisor 安全沙箱方向。
阿里云和蚂蚁金服团队合作,引入安全沙箱容器技术,于 2019 年 9 月发布了基于轻量虚拟化技术的 RunV 安全沙箱,相比于 RunC 容器,每个 RunV 容器具有独立内核,即使容器所属内核被攻破,也不会影响其他容器。阿里云容器服务提供了端到端的云原生安全架构,包括基础设施安全、软件供应链安全和运行时安全,为企业提供全方位、立体化、多层次的安全防护。
第二个需求是混合云架构 ,上云已是大势所趋,很多客户由于业务原因会考虑混合云的方式,不同云环境的基础设施和安全架构差异会造成企业 IT 和运维体系的割裂,加大管理复杂性。
在云原生时代,以容器、Kubernetes 为代表的技术屏蔽了基础设施差异,作为底座推动了以应用为中心的混合云 2.0 架构到来,满足了用户诉求。同时企业在运营效率、研发效率、运行成本以及系统容错性、可维护性等方面,也提出了更高的要求。阿里云在整个容器产品的研发过程中,致力于解决企业痛点,尽管各个企业对于上云的诉求有诸多不同,但容器和云原生作为一种普适技术,可以满足不同企业不同层次的需求。
谈及阿里云对于容器技术与产品的创新,叔同强调,“阿里云希望在云原生领域继续走社区路线,和开源技术完全兼容,利用阿里巴巴经济体的规模复杂度和阿里云客户的场景丰富度,不断创新,形成云原生的技术领先并回馈社区共建标准。2019 年年初我们将云原生大规模生产落地最佳实践沉淀下来,以开源项目 OpenKruise 的方式向社区开放,一方面帮助企业客户在云原生的探索过程中,少走弯路减少技术碎片化；一方面推动上游社区逐渐完善和丰富应用自动化管理能力。
在 2019 年 10 月,阿里云联合微软一起发布开放应用模型 Open Application Model(OAM),OAM 是专注于描述应用生命周期的标准规范,可以帮助应用开发者、应用运维人员和基础架构运维团队更好地进行协同。在这个模型里开发人员负责定义应用组成、依赖与架构；应用运维人员负责定义应用运行时配置与运维需求,比如发布策略和监控指标,而基础架构运维团队可以针对应用部署环境的不同,配置定制化参数,通过这种关注点分离的设计,可以将应用定义、运维能力与基础设施实现解耦,让应用交付变得更加高效、可靠和自动化,解决行业痛点。
Serverless 通过更高层次的抽象,让开发者免去资源管理、日常运维等工作,做到简化研发、极致弹性、按用付费。阿里云打造了函数计算产品 FunctionCompute： 提供了事件驱动的编程方式； 提供了面向应用的 Serverless 应用托管平台 SAE,用户只需提供应用实现,而平台负责弹性、自动化运维； 提供了面向容器的 Serverless 产品 ECI 和 Serverless Kubernetes,另一方面也在推动一些传统技术的 Serverless 化,例如数据库和消息中间件。
在技术创新的驱动下,阿里云希望成为云原生最佳的产品实现,继续发挥国内最大规模的云原生应用实践、国内最丰富的云原生产品家族、国内最大的云原生客户群体、国内最全面的云原生开源贡献的优势,服务更广泛的企业客户和开发者。”
十一年 双11 的云化架构演进与升级,造就容器技术最好的创新土壤
“阿里云与其他云厂商最大的不同,就是阿里巴巴的核心业务运行在云上,形成最好的创新土壤,也就是说我们最先进的技术,首先会在阿里巴巴自己的业务体系中进行尝试,得到了大规模的运用,证明其技术的普适性与价值后再开放给客户。”
在谈及阿里云容器化进展时,叔同强调：任何技术都会在阿里巴巴自己的业务体系中得到尝试与应用, 2011 年阿里云开始迈进容器大门,2013 年 Docker 问世,阿里云容器迅速融合其先进理念,并在 2015 年推进集团业务全面的容器化演进,而这一系列的发展与演进其实都离不开 双11 大促的需求,例如全面容器化帮助 双11 大促实现快速弹性扩容。
在 双11 活动的历练中,数以百万的容器支撑着 双11 活动顺利进行。由于业务的超大规模使得其复杂程度非常高,这也为容器技术带来了更大的挑战。例如在容器镜像分发过程中,一次发布分发几万个镜像,这样巨大的流量是一个不小的挑战。为实现效率的极致要求,阿里云利用 P2P 技术,实现大规模大批量的快速分发,实现 10 秒内完成跨机房镜像下载容器启动。
容器技术对于 双11 的显著影响还包括在具体的混部技术实施中,叔同表示通过混部技术,阿里巴巴集团范围内能够节省 30% 左右的 IT 成本支出,能够在 双11 这个特殊时间段里,将每万笔交易成本下降超过 75%。
容器、微服务、人工智能未来趋势：协作、融合
容器技术已经获得了业界的广泛认可,在未来的发展前景,不仅取决于其在技术领域的卓越表现,同时也需要与更多的技术相融合,从而成为与时代共同进步的成功产品技术。
早期 Kubernetes 上主要运行无状态的 Web 应用,比如基于 Apache Dubbo/Spring Cloud 的微服务应用,现在越来越多的企业核心业务、数据智能业务和创新业务也运行在 Kubernetes 之上。以阿里云自身的云产品举例,包括企业级分布式应用服务 EDAS 、实时计算平台 Flink 、弹性 AI 算法服务 EAS 、区块链平台 BaaS 都部署在阿里云 Kubernetes 服务 ACK 之上。
从应用架构演进来看,容器的发展促进了微服务的发展。微服务在早期落地遇到的大问题是架构拆分导致的运维复杂度和环境不一致,正是通过容器对应用和其运行环境的打包和隔离,很好的解决微服务体系的痛点,让微服务得以快速发展。微服务架构的引入解决了一些问题的同时,入侵了研发框架,框架迭代和研发迭代被耦合,并且在多语言环境的支持不够友好,在管理上也更加复杂。因此社区开始尝试 Service Mesh,逐渐把微服务能力从框架能力下沉为平台能力,可以看到容器与微服务在互相促进。
“云原生与 AI 是绝佳搭档,两者是相互赋能的。” 在提及 AI 与容器的融合时叔同强调。首先 AI 是新兴领域,架构上没有那么多历史包袱,另外 AI 计算本身对弹性、资源效率和部署效率有所要求,容器技术可以解决上述问题。GPU、FPGA、专有的 ASIC 芯片等新架构,带来巨大算力提升的同时也带来管理维护的难度,利用 Kubernetes 提供对异构资源的统一管理和高效调度,提升弹性支持细粒度共享,可以提升资源利用率 3 到 5 倍。
AI 对于容器云原生技术同样帮助巨大,AI 往往代表着业务场景,这对于云原生技术如何更为普适通用提供了丰富的验证空间,从而提升了云原生技术的成熟度。
容器技术出现已经超过 6 年,Kubernetes 的快速发展已不是新闻,但这并不意味着容器技术的生态系统已经发展平缓。相反的是,容器及其周边的技术体系还在保持高速发展。
谈及未来关注的新技术、新方向,叔同坦承要让容器走到所有的环境中,不仅是传统 IDC,更要走到公共云、专有云、边缘节点、物联网、大数据、AI 等各种场景中,希望运用云原生技术降低云计算的使用门槛,真正实现云上拐点。
原文链接
本文为阿里云内容,未经允许不得转载。
「深度学习福利」大神带你进阶工程师,立即查看>>>
TA-Lib ,全称“Technical Analysis Library”, 即技术分析库,是 Python 金融量化的高级库,涵盖了 150 多种股票、期货交易软件中常用的技术分析指标,如 MACD、RSI、KDJ、动量指标、布林带等等。
TA-Lib 可分为 10 个子板块： Overlap Studies(重叠指标) Momentum Indicators(动量指标) Volume Indicators(交易量指标) Cycle Indicators(周期指标) Price Transform(价格变换) Volatility Indicators(波动率指标) Pattern Recognition(模式识别) Statistic Functions(统计函数) Math Transform(数学变换) Math Operators(数学运算)
本文介绍通过 Funcraft 的模板将 Python 量化交易库 TA-lib 移植到 函数计算 。
依赖工具
本项目是在 MacOS 下开发的,涉及到的工具是平台无关的,对于 Linux 和 Windows 桌面系统应该也同样适用。在开始本例之前请确保如下工具已经正确的安装,更新到最新版本,并进行正确的配置。 Docker Funcraft
对于 MacOS 用户可以使用 homebrew 进行安装： brew cask install docker brew tap vangie/formula brew install fun
Windows 和 Linux 用户安装请参考：
https://github.com/aliyun/fun/blob/master/docs/usage/installation.md
安装好后,记得先执行 fun config 初始化一下配置。
初始化
使用 fun init 命令可以快捷地将本模板项目初始化到本地。 fun init vangie/ta-lib-example
安装依赖 $ fun install using template: template.yml start installing function dependencies without docker building ta-lib-example/ta-lib-example Funfile exist, Fun will use container to build forcely Step 1/5 : FROM registry.cn-beijing.aliyuncs.com/aliyunfc/runtime-python3.6:build-1.7.7 ---> 373f5819463b Step 2/5 : COPY ta-lib-0.4.0-src.tar.gz /tmp ---> Using cache ---> 64f9f85112b4 Step 3/5 : RUN cd /tmp; tar -xzf ta-lib-0.4.0-src.tar.gz ---> Using cache ---> 9f2d3f836de9 Step 4/5 : RUN cd /tmp/ta-lib/ ; ./configure --prefix=/code/.fun/root/usr ; make ; make install ---> Using cache ---> 7725836973d4 Step 5/5 : RUN TA_LIBRARY_PATH=/code/.fun/root/usr/lib TA_INCLUDE_PATH=/code/.fun/root/usr/include fun-install pip install TA-Lib ---> Using cache ---> a338e71895b7 sha256:a338e71895b74a0be98278f35da38c48545f04a54e19ec9e689bab976265350b Successfully built a338e71895b7 Successfully tagged fun-cache-d4ac1d89-5b75-4429-933a-2260e2f7fbec:latest copying function artifact to /Users/vangie/Workspace/ta-lib-example/{{ projectName }} Install Success Tips for next step ====================== * Invoke Event Function: fun local invoke * Invoke Http Function: fun local start * Build Http Function: fun build * Deploy Resources: fun deploy
本地调用 $ fun local invoke using template: template.yml Missing invokeName argument, Fun will use the first function ta-lib-example/ta-lib-example as invokeName skip pulling image aliyunfc/runtime-python3.6:1.7.7... FunctionCompute python3 runtime inited. FC Invoke Start RequestId: dc1495b2-13ec-4ecf-a2dc-a0026d82651a FC Invoke End RequestId: dc1495b2-13ec-4ecf-a2dc-a0026d82651a [ "HT_DCPERIOD", "HT_DCPHASE", "HT_PHASOR", "HT_SINE", "HT_TRENDMODE" ] RequestId: dc1495b2-13ec-4ecf-a2dc-a0026d82651a Billed Duration: 350 ms Memory Size: 1998 MB Max Memory Used: 34 MB
部署 $ fun deploy using template: template.yml using region: cn-shanghai using accountId: ***********4733 using accessKeyId: ***********EUz3 using timeout: 600 Waiting for service ta-lib-example to be deployed... Waiting for function ta-lib-example to be deployed... Waiting for packaging function ta-lib-example code... The function ta-lib-example has been packaged. A total of 39 files files were compressed and the final size was 3.23 MB function ta-lib-example deploy success service ta-lib-example deploy success
执行 $ fun invoke using template: template.yml Missing invokeName argument, Fun will use the first function ta-lib-example/ta-lib-example as invokeName ========= FC invoke Logs begin ========= FC Invoke Start RequestId: 83e23eba-02b4-4380-bbca-daec6856bf4a FC Invoke End RequestId: 83e23eba-02b4-4380-bbca-daec6856bf4a Duration: 213.86 ms, Billed Duration: 300 ms, Memory Size: 128 MB, Max Memory Used: 43.50 MB ========= FC invoke Logs end ========= FC Invoke Result: [ "HT_DCPERIOD", "HT_DCPHASE", "HT_PHASOR", "HT_SINE", "HT_TRENDMODE" ]
参考阅读 函数计算 【手把手教你】股市技术分析利器之TA-Lib（一） “ 阿里巴巴云原生 关注微服务、Serverless、容器、Service Mesh 等技术领域、聚焦云原生流行技术趋势、云原生大规模的落地实践,做最懂云原生开发者的技术圈。”
「深度学习福利」大神带你进阶工程师,立即查看>>>
OpenShift里,有一种资源叫pod。OpenShift里,受控节点（managed node）上,运行着一个个pod；pod之内,又运行着一个或多个Docker容器。这些容器可以是同一种服务的复制体副本,或者是相关的服务的容器,如Apache的容器和MariaDB或MySQL的容器。其实,这个pod的概念来源于OpenShift的三大组件之一——大名鼎鼎的Kubernetes,或简称的K8S。
没有看到有人翻译这个名词。因为它太短了？还是不好翻译？
我觉得不好翻译。上图就是一个原生的pod,豆荚。译成豆荚？于是,我们这样讲： 创建这个豆荚之后,调度器便根据一定的规则,为这个豆荚选择了一个或几个目标服务器,并在上面运行。
是不是感觉有点怪？我们在谈论容器的运行,你却搬出豆荚之类不相干的词汇。我认为,习惯了就好。毕竟,人家原来就是这样用的。容器这个词很形象,可惜已经被Docker占用了。Kuberneste中,受控制节点,或者被管理着的服务器却被冠以一个很屈辱的名字：minion。啥意思？奴仆,下人、跟班。
K8S或OpenShift现在要用一个更大一点的东西把Docker的容器装进去。于是,便找到pod这个名字,除了视觉上,个头比较小之外,也很形象,甚至还有点萌。但是,我建议把pod译为“苞”。
上图是一个花苞。花苞里面包含着花瓣,也算是一个装东西的容器吧。发音跟pod接近,而且,也是一个单音节。
你有什么意见呢？欢迎留言评论。
「深度学习福利」大神带你进阶工程师,立即查看>>>
作者 | 子誉 蚂蚁金服高级技术专家
关注“阿里巴巴云原生”公众号,回复关键词**“入门”**,即可下载从零入门 K8s 系列文章 PPT。
Kubernetes 调度过程
首先来看第一部分 - Kubernetes 的调度过程。如下图所示,画了一个很简单的 Kubernetes 集群架构,它包括了一个 kube-ApiServer,一组 Web-hook Controllers,以及一个默认的调度器 kube-Scheduler,还有两台物理机节点 Node1 和 Node2,分别在上面部署了两个 kubelet。
我们来看一下,假如要向这个 Kubernetes 集群提交一个 pod,它的调度过程是什么样的一个流程？
假设我们已经写好了一个 yaml 文件,就是下图中的橙色圆圈 pod1,然后往 kube-ApiServer 里提交这个 yaml 文件。
此时 ApiServer 会先把这个待创建的请求路由给我们的 webhook Controllers 进行校验。
通过校验之后,ApiServer 会在集群里面生成一个 pod,此时生成的 pod,它的 nodeName 是空的,并且它的 phase 是 Pending 状态。在生成了这个 pod 之后,kube-Scheduler 以及 kubelet 都能 watch 到这个 pod 的生成事件,kube-Scheduler 发现这个 pod 的 nodeName 是空的之后,会认为这个 pod 是处于未调度状态。
接下来,它会把这个 pod 拿到自己里面进行调度,通过一系列的调度算法,包括一系列的过滤和打分的算法后,Schedule 会选出一台最合适的节点,并且把这一台节点的名称绑定在这个 pod 的 spec 上,完成一次调度的过程。
此时我们发现,pod 的 spec 上,nodeName 已经更新成了 Node1 这个 node,更新完 nodeName 之后,在 Node1 上的这台 kubelet 会 watch 到这个 pod 是属于自己节点上的一个 pod。
然后它会把这个 pod 拿到节点上进行操作,包括创建一些容器 storage 以及 network,最后等所有的资源都准备完成,kubelet 会把状态更新为 Running,这样一个完整的调度过程就结束了。
通过刚刚一个调度过程的演示,我们用一句话来概括一下调度过程：它其实就是在做一件事情,即把 pod 放到 合适 的 node 上。
这里有个关键字“合适”,什么是合适呢？下面给出几点合适定义的特点： 首先要满足 pod 的资源要求； 其次要满足 pod 的一些特殊关系的要求； 再次要满足 node 的一些限制条件的要求； 最后还要做到整个集群资源的合理利用。
做到以上的要求后,可以认为我们把 pod 放到了一个合适的节点上了。
接下来我会为大家介绍 Kubernetes 是怎么做到满足这些 pod 和 node 的要求的。
Kubernetes 基础调度力
下面为大家介绍一下 Kubernetes 的基础调度能力,Kubernetes 的基础调度能力会以两部分来展开介绍： 第一部分是资源调度——介绍一下 Kubernetes 基本的一些 Resources 的配置方式,还有 Qos 的概念,以及 Resource Quota 的概念和使用方式； 第二部分是关系调度——在关系调度上,介绍两种关系场景： pod 和 pod 之间的关系场景,包括怎么去亲和一个 pod,怎么去互斥一个 pod？ pod 和 node 之间的关系场景,包括怎么去亲和一个 node,以及有一些 node 怎么去限制 pod 调度上来。
如何满足 Pod 资源要求
pod 的资源配置方法
上图是 pod spec 的一个 demo,我们的资源其实是填在 pod spec 中,具体在 containers 的 resources 里。
resources 包含两个部分： 第一部分是 requests； 第二部分是 limits。
这两部分里面的内容是一模一样的,但是它代表的含义有所不同：request 代表的是对这个 pod 基本保底的一些资源要求；limit 代表的是对这个 pod 可用能力上限的一种限制。request、limit 的实现是一个 map 结构,它里面可以填不同的资源的 key/value。
我们可以大概分成四大类的基础资源： 第一类是 CPU 资源； 第二类是 memory； 第三类是 ephemeral-storage,是一种临时存储； 第四类是通用的扩展资源,比如说像 GPU。
CPU 资源,比如说上面的例子填的是2,申请的是两个 CPU,也可以写成 2000m 这种十进制的转换方式,来表达有些时候可能对 CPU 可能是一个小数的需求,比如说像 0.2 个CPU,可以填 200m。而这种方式在 memory 和 storage 之上,它是一个二进制的表达方式,如上图右侧所示,申请的是 1GB 的 memory,同样也可以填成一个 1024mi 的表达方式,这样可以更清楚地表达我们对 memory 的需求。
在扩展资源上,Kubernetes 有一个要求,即扩展资源必须是整数的,所以我们没法申请到 0.5 的 GPU 这样的资源,只能申请 1 个 GPU 或者 2 个 GPU。
这里为大家介绍完了基础资源的申请方式。
接下来,我会详细给大家介绍一下 request 和 limit 到底有什么区别,以及如何通过 request/limit 来表示 QoS。
Pod QoS 类型
K8S 在 pod resources 里面提供了两种填写方式：第一种是 request,第二种是 limit。
它其实是为用户提供了对 Pod 一种弹性能力的定义。比如说我们可以对 request 填 2 个 CPU,对 limit 填 4 个 CPU,这样代表了我希望是有 2 个 CPU 的保底能力,但其实在闲置的时候,可以使用 4 个 GPU。
说到这个弹性能力,我们不得不提到一个概念：QoS 的概念。什么是 QoS呢？QoS 全称是 Quality of Service,它是 Kubernetes 用来表达一个 pod 在资源能力上的服务质量的标准,Kubernetes 提供了三类 QoS Class: 第一类是 Guaranteed,它是一类高 QoS Class,一般拿 Guaranteed 配置给一些需要资源保障能力的 pods； 第二类是 Burstable,它是中等的一个 QoS label,一般会为一些希望有弹性能力的 pod 来配置 Burstable； 第三类是 BestEffort,它是低QoS Class,通过名字我们也知道,它是一种尽力而为式的服务质量,K8S不承诺保障这类Pods服务质量。
K8s 其实有一个不太好的地方,就是用户没法直接指定自己的 pod 是属于哪一类 QoS,而是通过 request 和 limit 的组合来自动地映射上 QoS Class。
通过上图的例子,大家可以看到：假如我提交的是上面的一个 spec,在 spec 提交成功之后,Kubernetes 会自动给补上一个 status,里面是 qosClass: Guaranteed,用户自己提交的时候,是没法定义自己的 QoS 等级。所以将这种方式称之为隐性的 QoS class 用法。
Pod QoS 配置
接下来介绍一下,我们怎么通过 request 和 limit 的组合来确定我们想要的 QoS level。
Guaranteed Pod
首先我们如何创建出来一个 Guaranteed Pod？
Kubernetes 里面有一个要求：如果你要创建出一个 Guaranteed Pod,那么你的基础资源（包括 CPU 和 memory）,必须它的 request==limit,其他的资源可以不相等。只有在这种条件下,它创建出来的 pod 才是一种 Guaranteed Pod,否则它会属于 Burstable,或者是 BestEffort Pod。
Burstable Pod
然后看一下,我们怎么创建出来一个 Burstable Pod,Burstable Pod 的范围比较宽泛,它只要满足 CPU/Memory 的 request 和 limit 不相等,它就是一种 Burstable Pod。
比如说上面的例子,可以不用填写 memory 的资源,只要填写 CPU 的资源,它就是一种 Burstable Pod。
BestEffort Pod
第三类 BestEffort Pod,它也是条件比较死的一种使用方式。它必须是所有资源的 request/limit 都不填,才是一种 BestEffort Pod。
所以这里可以看到,通过 request 和 limit 不同的用法,可以组合出不同的 Pod QoS。
不同的 QoS 表现
接下来,为大家介绍一下：不同的 QoS 在调度和底层表现有什么样的不同？不同的 QoS,它其实在调度和底层表现上都有一些不一样。比如说调度表现,调度器只会使用 request 进行调度,也就是说不管你配了多大的 limit,它都不会进行调度使用。
在底层上,不同的 Qos 表现更不相同。比如说 CPU,它是按 request 来划分权重的,不同的 QoS,它的 request 是完全不一样的,比如说像 Burstable 和 BestEffort,它可能 request 可以填很小的数字或者不填,这样的话,它的时间片权重其实是非常低的。像 BestEffort,它的权重可能只有 2,而 Burstable 或 Guaranteed,它的权重可以多到几千。
另外,当我们开启了 kubelet 的一个特性,叫 cpu-manager-policy=static 的时候,我们 Guaranteed Qos,如果它的 request 是一个整数的话,比如说配了 2,它会对 Guaranteed Pod 进行绑核。具体的像下面这个例子,它分配 CPU0 和 CPU1 给 Guaranteed Pod。
非整数的 Guaranteed/Burstable/BestEffort,它们的 CPU 会放在一块,组成一个 CPU share pool,比如说像上面这个例子,这台节点假如说有 8 个核,已经分配了 2 个核给整数的 Guaranteed 绑核,那么剩下的 6 个核 CPU2~CPU7,它会被非整数的 Guaranteed/Burstable/BestEffort 共享,然后它们会根据不同的权重划分时间片来使用 6 个核的 CPU。
另外在 memory 上也会按照不同的 QoS 进行划分 OOMScore。比如说 Guaranteed Pod,会固定配置默认的 -998 的 OOMScore；而 Burstable Pod 会根据 Pod 内存设计的大小和节点内存的比例来分配 2-999 的 OOMScore；BestEffort Pod 会固定分配 1000 的 OOMScore,OOMScore 得分越高的话,在物理机出现 OOM 的时候会优先被 kill 掉。
另外在节点上的 eviction 动作上,不同的 QoS 行为也是不一样的,比如说发生 eviction 的时候,会优先考虑驱逐 BestEffort 的 pod。所以不同的 QoS 在底层的表现是截然不同的。这反过来也要求我们在生产过程中,根据不同业务的要求和属性来配置资源的 Limits 和 Requests,做到合理的规划 QoS Class。
资源 Quota
在生产中我们还会遇到一个场景：假如集群是由多个人同时提交的,或者是多个业务同时在使用,我们肯定要限制某个业务或某个人提交的总量,防止整个集群的资源都会被一个业务使用掉,导致另一个业务没有资源使用。
Kubernetes 给我们提供了一个能力叫 ResourceQuota。它可以做到限制 namespace 资源用量。
具体的做法如上图右侧的 yaml 所示,可以看到它的 spec 包括了一个 hard 和 scopeSelector。hard 内容其实和 Resource 很像,这里可以填一些基础的资源。但是它比 Resource list 更丰富一点,还可以填写一些 Pod,这样可以限制 Pod 数量。另外,scopeSelector 还为这个 ResourceQuota 提供了更丰富的索引能力。
比如上面的例子中,索引出非 BestEffort 的 pod,限制的 cpu 是 1000 个,memory 是 200G,Pod 是 10 个。
ScopeName 除了提供 NotBestEffort,它还提供了更丰富的索引范围,包括 Terminating/Not Terminating,BestEffort/NotBestEffort,PriorityClass。
当我们创建了这样的 ResourceQuota 作用于集群,如果用户真的用超了资源,表现的行为是：它在提交 Pod spec 时,会收到一个 forbidden 的 403 错误,提示 exceeded quota。这样用户就无法再提交对应用超的资源了。
而如果再提交一个没有包含在这个 ResourceQuota 里的资源,还是能成功的。
这就是 Kubernetes 里 ResourceQuota 的基本用法。 我们可以用 ResourceQuota 方法来做到限制每一个 namespace 的资源用量,从而保证其他用户的资源使用。
小结：如何满足 Pod 资源要求？
上面介绍完了基础资源的使用方式,也就是我们做到了如何满足 Pod 资源要求。下面做一个小结： Pod 要配置合理的资源要求 CPU/Memory/EphemeralStorage/GPU 通过 Request 和 Limit 来为不同业务特点的 Pod 选择不同的 QoS Guaranteed：敏感型,需要业务保障 Burstable：次敏感型,需要弹性业务 BestEffort：可容忍性业务 为每个 NS 配置 ResourceQuota 来防止过量使用,保障其他人的资源可用
如何满足 Pod 与 Pod 关系要求？
接下来给大家介绍一下 Pod 的关系调度,首先是 Pod 和 Pod 的关系调度。我们在平时使用中可能会遇到一些场景：比如说一个 Pod 必须要和另外一个 Pod 放在一起,或者不能和另外一个 Pod 放在一起。
在这种要求下, Kubernetes 提供了两类能力： 第一类能力称之为 Pod 亲和调度：PodAffinity； 第二类就是 Pod 反亲和调度：PodAntAffinity。
Pod 亲和调度
首先我们来看 Pod 亲和调度,假如我想把一个 Pod 和另一个 Pod 放在一起,这时我们可以看上图中的实例写法,填写上 podAffinity,然后填上 required 要求。
在这个例子中,必须要调度到带了 key: k1 的 Pod 所在的节点,并且打散粒度是按照节点粒度去打散索引的。这种情况下,假如能找到带 key: k1 的 Pod 所在节点,就会调度成功。假如这个集群不存在这样的 Pod 节点,或者是资源不够的时候,那就会调度失败。这是一个严格的亲和调度,我们叫做强制亲和调度。
有些时候我们并不需要这么严格的调度策略。这时候可以把 required 改成 preferred,变成一个优先亲和调度。也就是优先可以调度带 key: k2 的 Pod 所在节点。并且这个 preferred 里面可以是一个 list 选择,可以填上多个条件,比如权重等于 100 的是 key: k2,权重等于 10 的是 key: k1。那调度器在调度的时候会优先把这个 Pod 分配到权重分更高的调度条件节点上去。
Pod 反亲和调度
上面介绍了亲和调度,反亲和调度与亲和调度比较相似,功能上是取反的,但语法上基本上是一样的。仅是 podAffinity 换成了 podAntiAffinity,也是包括 required 强制反亲和,以及一个 preferred 优先反亲和。
这里举了两个例子：一个是禁止调度到带了 key: k1 标签的 Pod 所在节点；另一个是优先反亲和调度到带了 key: k2 标签的 Pod 所在节点。
Kubernetes 除了 In 这个 Operator 语法之外,还提供了更多丰富的语法组合来给大家使用。比如说 In/NotIn/Exists/DoesNotExist 这些组合方式。上图的例子用的是 In,比如说第一个强制反亲和例子里面,相当于我们必须要禁止调度到带了 key: k1 标签的 Pod 所在节点。
同样的功能也可以使用 Exists,Exists 范围可能会比 In 范围更大,当 Operator 填了 Exists,就不需要再填写 values。它做到的效果就是禁止调度到带了 key: k1 标签的 Pod 所在节点,不管 values 是什么值,只要带了 k1 这个 key 标签的 Pod 所在节点,都不能调度过去。
以上就是 Pod 与 Pod 之间的关系调度。
如何满足 Pod 与 Node 关系调度
Pod 与 Node 的关系调度又称之为 Node 亲和调度,主要给大家介绍两类使用方法。
NodeSelector
第一类是 NodeSelector,这是一类相对比较简单的用法。比如说有个场景：必须要调度 Pod 到带了 k1: v1 标签的 Node 上,这时可以在 Pod 的 spec 中填写一个 nodeSelector 要求。nodeSelector 本质是一个 map 结构,里面可以直接写上对 node 标签的要求,比如 k1: v1。这样我的 Pod 就会强制调度到带了 k1: v1 标签的 Node 上。
NodeAffinity
NodeSelector 是一个非常简单的用法,但这个用法有个问题：它只能强制亲和调度,假如我想优先调度,就没法用 nodeSelector 来做。于是 Kubernetes 社区又新加了一个用法,叫做 NodeAffinity。
它和 PodAffinity 有点类似,也提供了两类调度的策略： 第一类是 required,必须调度到某一类 Node 上； 第二类是 preferred,就是优先调度到某一类 Node 上。
它的基本语法和上文中的 PodAffinity 以及 PodAntiAffinity 也是类似的。在 Operator 上,NodeAffinity 提供了比 PodAffinity 更丰富的 Operator 内容。增加了 Gt 和 Lt,数值比较的用法。当使用 Gt 的时候,values 只能填写数字。
Node 标记/容忍
还有第三类调度,可以通过给 Node 打一些标记,来限制 Pod 调度到某些 Node 上。Kubernetes 把这些标记称之为 Taints,它的字面意思是污染。
那我们如何限制 Pod 调度到某些 Node 上呢？比如说现在有个 node 叫 demo-node,这个节点有问题,我想限制一些 Pod 调度上来。这时可以给这个节点打一个 taints,taints 内容包括 key、value、effect： key 就是配置的键值 value 就是内容 effect 是标记了这个 taints 行为是什么
目前 Kubernetes 里面有三个 taints 行为： NoSchedule 禁止新的 Pod 调度上来； PreferNoSchedul 尽量不调度到这台； NoExecute 会 evict 没有对应 toleration 的 Pods,并且也不会调度新的上来。这个策略是非常严格的,大家在使用的时候要小心一点。
如上图绿色部分,给这个 demo-node 打了 k1=v1,并且 effect 等于 NoSchedule 之后。它的效果是：新建的 Pod 没有专门容忍这个 taint,那就没法调度到这个节点上去了。
假如有些 Pod 是可以调度到这个节点上的,应该怎么来做呢？这时可以在 Pod 上打一个 Pod Tolerations。从上图中蓝色部分可以看到：在 Pod 的 spec 中填写一个 Tolerations,它里面也包含了 key、value、effect,这三个值和 taint 的值是完全对应的,taint 里面的 key,value,effect 是什么内容,Tolerations 里面也要填写相同的内容。
Tolerations 还多了一个选项 Operator,Operator 有两个 value：Exists/Equal。Equal 的概念是必须要填写 value,而 Exists 就跟上文说的 NodeAffinity 一样,不需要填写 value,只要 key 值对上了,就认为它跟 taints 是匹配的。
上图中的例子,给 Pod 打了一个 Tolerations,只有打了这个 Tolerations 的 Pod,才能调度到绿色部分打了 taints 的 Node 上去。这样的好处是 Node 可以有选择性的调度一些 Pod 上来,而不是所有的 Pod 都可以调度上来,这样就做到了限制某些 Pod 调度到某些 Node 的效果。
小结
我们已经介绍完了 Pod/Node 的特殊关系和条件调度,来做一下小结。
首先假如有需求是处理 Pod 与 Pod 的时候,比如 Pod 和另一个 Pod 有亲和的关系或者是互斥的关系,可以给它们配置下面的参数： PodAffinity PodAntiAffinity
假如存在 Pod 和 Node 有亲和关系,可以配置下面的参数： NodeSelector NodeAffinity
假如有些 Node 是限制某些 Pod 调度的,比如说一些故障的 Node,或者说是一些特殊业务的 Node,可以配置下面的参数： Node -- Taints Pod -- Tolerations
Kubernetes 高级调度能力
介绍完了基础调度能力之后,下面来了解一下高级调度能力。
优先级调度
优先级调度和抢占,主要概念有： Priority Preemption
首先来看一下调度过程提到的四个特点,我们如何做到集群的合理利用？当集群资源足够的话,只需要通过基础调度能力就能组合出合理的使用方式。但是假如资源不够,我们怎么做到集群的合理利用呢？通常的策略有两类： 先到先得策略 (FIFO) -简单、相对公平,上手快 优先级策略 (Priority) - 比较符合日常公司业务特点
在实际生产中,如果使用先到先得策略,反而是一种不公平的策略,因为公司业务里面肯定是有高优先级的业务和低优先级的业务,所以优先级策略会比先到先得策略更能够符合日常公司业务特点。
接下来介绍一下优先级策略下的优先级调度是什么样的一个概念。比如说有一个 Node 已经被一个 Pod 占用了,这个 Node 只有 2 个 CPU。另一个高优先级 Pod 来的时候,低优先级的 Pod 应该把这两个 CPU 让给高优先级的 Pod 去使用。低优先级的 Pod 需要回到等待队列,或者是业务重新提交。这样的流程就是优先级抢占调度的一个流程。
在 Kubernetes 里,PodPriority 和 Preemption,就是优先级和抢占的特点,在 v1.14 版本中变成了 stable。并且 PodPriority 和 Preemption 功能默认是开启的。
优先级调度配置
怎么使用？
如何使用优先级调度呢？需要创建一个 priorityClass,然后再为每个 Pod 配置上不同的 priorityClassName,这样就完成了优先级以及优先级调度的配置。
首先来看一下如何创建一个 priorityClass。上图右侧定义了两个 demo： 一个是创建了名为 high 的 priorityClass,它是高优先级,得分为 10000； 另一个创建了名为 low 的 priorityClass,它的得分是 100。
同时在第三部分给 Pod1 配置上了 high,Pod2 上配置了 low priorityClassName,蓝色部分显示了 pod 的 spec 的配置位置,就是在 spec 里面填写一个 priorityClassName: high。这样 Pod 和 priorityClass 做完配置,就为集群开启了一个 priorityClass 调度。
内置优先级配置
当然 Kubernetes 里面还内置了默认的优先级。如 DefaultpriorityWhenNoDefaultClassExistis,如果集群中没有配置 DefaultpriorityWhenNoDefaultClassExistis,那所有的 Pod 关于此项数值都会被设置成 0。
用户可配置的最大优先级限制为：HighestUserDefinablePriority = 10000000000(10 亿),会小于系统级别优先级：SystemCriticalPriority = 20000000000(20 亿)
其中内置了两个系统级别优先级： system-cluster-critical system-node-critical
这就是K8S优先级调度里内置的优先级配置。
优先级调度过程
下面介绍简单的优先级调度过程：
首先介绍只触发优先级调度但是没有触发抢占调度的流程。
假如有一个 Pod1 和 Pod2,Pod1 配置了高优先级,Pod2 配置了低优先级。同时提交 Pod1 和 Pod2 到调度队列里。
调度器处理队列的时候会挑选一个高优先级的 Pod1 进行调度,经过调度过程把 Pod1 绑定到 Node1 上。
其次再挑选一个低优先的 Pod2 进行同样的过程,绑定到 Node1 上。
这样就完成了一个简单的优先级调度的流程。
优先级抢占过程
假如高优先级的 Pod 在调度的时候没有资源,那么会是一个怎么样的流程呢？
首先是跟上文同样的场景,但是提前在 Node1 上放置了 Pod0,占去了一部分资源。同样有 Pod1 和 Pod2 待调度,Pod1 的优先级大于 Pod2。
假如先把 Pod2 调度上去,它经过一系列的调度过程绑定到了 Node1 上。
紧接着再调度 Pod1,因为 Node1 上已经存在了两个 Pod,资源不足,所以会遇到调度失败。
在调度失败时 Pod1 会进入抢占流程,这时会进行整个集群的节点筛选,最后挑出要抢占的 Pod 是 Pod2,此时调度器会把 Pod2 从 Node1 上移除数据。
再把 Pod1 调度到 Node1 上。这样就完成了一次抢占调度的流程。
优先级抢占策略
接下来介绍具体的抢占策略和抢占流程
上图右侧是整个kube-scheduler优先级抢占的调度流程。首先一个 Pod 进入抢占的时候,会判断 Pod 是否拥有抢占的资格,有可能上次已经抢占过一次。如果符合抢占资格,它会先对所有的节点进行一次过滤,过滤出符合这次抢占要求的节点,如果不符合就过滤掉这批节点。
接着从过滤剩下的节点中,挑选出合适的节点进行抢占。这次抢占的过程会模拟一次调度,把上面优先级低的 Pod 先移除出去,再把待抢占的 Pod 尝试能否放置到此节点上。然后通过这个过程选出一批节点,进入下一个过程 ProcessPreemptionWithExtenders。这是一个扩展的钩子,用户可以在这里加一些自己抢占节点的策略,如果没有扩展钩子,这里面是不做任何动作的。
接下来的流程叫做 PickOneNodeForPreemption,就是从上面 selectNodeForPreemption list 里面挑选出最合适的一个节点,这是有一定的策略的。上图左侧简单介绍了一下策略： 优先选择打破 PDB 最少的节点； 其次选择待抢占 Pods 中最大优先级最小的节点； 再次选择待抢占 Pods 优先级加和最小的节点； 接下来选择待抢占 Pods 数目最小的节点； 最后选择拥有最晚启动 Pod 的节点；
通过这五步串行策略过滤之后,会选出一个最合适的节点。然后对这个节点上待抢占的 Pod 进行 delete,这样就完成了一次待抢占的过程。
小结
简单介绍了一下调度的高级策略,在集群资源紧张的时候也能合理调度资源。我们回顾一下做了哪些事情： 创建自定义的一些优先级类别 (PriorityClass)； 给不同类型 Pods 配置不同的优先级 (PriorityClassName)； 通过组合不同类型 Pods 运行和优先级抢占让集群资源和调度弹性起来。 “ 阿里巴巴云原生 关注微服务、Serverless、容器、Service Mesh 等技术领域、聚焦云原生流行技术趋势、云原生大规模的落地实践,做最懂云原生开发者的技术圈。”
「深度学习福利」大神带你进阶工程师,立即查看>>>
本文作者：yanxin1563 原创： liushaohua
一 背景
在2019WWDC的开场演讲中,苹果公布了即将推出的iOS13 DarkMode的新特性。此新特性不仅可以在夜晚保护视力,而且对于使用OLED的最新一代设备而言,也可以帮助用户节省电量消耗。不过此特性只支持iOS13以上的系统,为了给全系统所有用户最好的体验,研发出了一套皮肤主题框架,不仅可以全系统支持DarkMode,还可以扩展多套皮肤主题;
二 皮肤主题框架的诞生 BDPAppearance
2.1 业务方使用方式 目前系统所有控件及其Color属性和Image属性均已支持, 此处只列举两个例子: // UIColor view.backgroundColor = BDPAppearanceColor(@"C1"); // UIImage imageV.image = BDPAppearanceImage(@"icon");
业务方只需如上使用简单的API设置Color和Image,即可实现主题换肤；
2.2 实现原理
先来看一下BDPAppearance设计方案的架构图
在项目初始化时,会先加载当前主题所使用的色值资源到内存中,相关控件通过 BDPAppearanceColor 用色名去找出对应主题下的色值,实例化出UIColor对象,并赋值给这些相关控件;
而内置的UIImage图片是存放在Assets中的,通过BDPAppearanceImage用图片名去加载当前主题下的UIImage对象即可； UIColor分类和UIImage分类
可以看到图中,给UIColor分类添加了ColorName属性: 通过BDPAppearanceColor方式获取UIColor实例对象时,通过分类会记录当前Color对象所使用的色号名;
同理,通过BDPAppearanceImage获取UIImage时,通过分类会记录当前Image对象所使用的图片名; changeTheme刷新主题
每一个控件初始化添加到父视图的时候,在- (void)didMoveToSuperview的时机将其添加到NSHashTable中, 点击切换主题时,通过NSHashTable拿到当前视图树上所有的视图控件,取出控件属性中的UIColor和UIImage, 判断其colorName和imageName是否有值,有值即代表当前控件需要适配主题,则用此colorName或者imageName去加载当前主题的新色值和新图片,重新赋值给当前控件即完成了主题切换。
三 设计思路
设计此皮肤主题框架的原则：
业务方在现有业务的基础上以最低成本的方式进行适配:即只需更换获取颜色和图片的方式
那么在基于上述原则的前提下,我们应该如何在切换主题时,让所有的控件重新刷新主题呢？
在项目初期时,采用通知的方案：在didMoveToSuperview方法中给当前控件添加一个通知,当收到切换主题的通知时,则刷新当前控件的相关色值及图片；
但是在做性能测试时,发现采用通知方式初始化,不仅会有一定CPU消耗,同时也会增加初始化的耗时,视图层级越多,性能损耗越明显,所以放弃了此方案; 我们的目的其实就是可以让当前所有的视图可以触发刷新逻辑,最终采用了NSHashTable弱持有控件的方案;
两种方式性能测试数据: 以下数据均是测试20次以上取的平均值;
压力测试环境： 视图层级1w个View:
由以上测试数据得出: 在上万个视图量级下, HashTable 性能是远远优于通知的方式
四 业界开源框架对比
以下是目前业界GitHub排名靠前的开源库对比:
同时对比iOS13系统API适配的方式: UIColor *dynamicColor = [UIColor colorWithDynamicProvider:^UIColor * _Nonnull(UITraitCollection * _Nonnull traitCollection) { if (traitCollection.userInterfaceStyle == UIUserInterfaceStyleDark) { return [UIColor blackColor]; } else { return [UIColor whiteColor]; } }]; view.backgroundColor = dynamicColor;
对比可以看出： BDPAppearance使用方式是在保留RD开发习惯上的基础上最接近系统方式的,改动代码量是最小的;
五 客户端整体主题通信设计
百度App涉及到主题相关模块技术形态有：NA、H5、RN、HN等,而在多种技术形态下主题模式又是如何通信呢？可以参考下边这张图:
如图所示： 初始化WKWebView时采用的方案：在UserAgent中拼接Key-Value的方式初始化WebView,达到在渲染时,最早时机拿到主题模式; 主题变化通信采用的方案：数据通道和端能力,其本质是JS交互；
六 项目工程色值配置 6.1 端内色值表的管理
整个百度App涉及近百个业务,组件近三百个,色号表的管理也显得尤为重要;
每个组件内部所使用到的色号仅仅是有限个, 如果所有组件用到的色值都统一放入一个色值表中管理,显然是不合理的,不利于解耦也更不利于组件化输出;那么最优的色值管理方式是什么呢？
如上图所示, 组件各自管理自己所需的色值表 ,在项目编译时,会通过脚本将所有组件的色值表进行色值去重后,合并成一个总的色值表存储在Themes仓库下,然后初始化主题资源时读取Themes里边总的色值表即可; 此种处理方式则达到了组件间解耦的目的;
6.2 Sketch插件: ThemeMeasure
早期的开发中,UE出图都是用的Sketch导出HTML格式标注图,而根据百度App iOS相关 CRD、FE 对实现技术的选型及配合要求,UE 需要提供并维护一套 NA+H5 色表,标注界面时标颜色的编号而非色值。为了达到此种效果,我们同期研发出了Sketch插件,可以在标注界面直接显示出色号,解决了UE标注色号的痛点,大大提高了效率; 如下图:
此插件共包含三种能力:
1.多种便捷方式助力色号标注 Theme Measure 可以让设计师根据系统的推荐选择色号进行标注,还有贴心的批量标注向导,改变了过去设计师手动写色号进行标注的方式
2.一键转换深色、夜间等主题 Theme Measure 能够让设计师一键将默认主题转换为深色、夜间或者其他主题（需要有相应的色值数据,正确的色号标注）,改变了过去设计师需要手动逐一调整产出深色、夜间设计稿的方式,大幅提升设计师对多主题适配的工作效率及体验
3.熟悉的标注导出方式,所有标注均在一处 还是使用熟悉的工具导出标注,色号、布局、字号等标注均在同一个 HTML 文档内,改变了过去需要额外提供一份色号标注的方式,提升设计与研发的协同效率与体验
在整套皮肤主题机制下业务方仅仅花了不到两周的时间即完成了整个手百的主题适配,也从侧面证实此框架的优点： 轻量级,使用成本低 ;
资源配置同时也支持云端下发,可动态新增多种主题;
七 总结
本文主要从皮肤主题框架实现、色值表的管理以及配套工具链等方面详细的介绍了百度App iOS暗黑模式的适配,欢迎业内的朋友一起交流学习;
原文链接地址： https://developer.baidu.com/topic/show/290490
「深度学习福利」大神带你进阶工程师,立即查看>>>
在前文,我们介绍来了分布式事务,以及分布式事务的解决方案之一的 二阶段提交 。 本文介绍分布式事务处理方案之一的三阶段提交协议。
分布式事务
分布式事务是指发生在多个数据节点之间的事务,分布式事务比单机事务要复杂的多。在分布式系统中,各个节点之间在是相互独立的,需要通过网络进行沟通和协调。由于存在事务机制,可以保证每个独立节点上的数据操作可以满足ACID。但是,相互独立的节点之间无法准确地知道其他节点的事务执行情况。所以从理论上来讲,两个节点的数据是无法达到一致的状态。如果想让分布式部署的多个节点中的数据保持一致性,那么就要保证在所有节点数据的写操作,要么全部都执行,要么全部都不执行。但是,一台机器在执行本地事务的时候无法知道其他机器中的本地事务的执行结果,所以它也就不知道本次事务到底应该commit还是rollback。所以,常规的解决办法就是引入一个"协调者"的组件来统一调度所有分布式节点的执行。
为了解决这种分布式一致性问题,前人在性能和数据一致性的反反复复权衡过程中总结了许多典型的协议和算法。其中比较著名的有二阶提交协议（Two Phase Commitment Protocol）、三阶提交协议（Three Phase Commitment Protocol）和Paxos算法。针对分布式事务,是X/Open 这个组织定义的一套分布式事务的标准X/Open DTP（X/Open Distributed Transaction Processing ReferenceModel）,定义了规范和API接口,可以由各个厂商进行具体的实现。
大部分的关系型数据库通过两阶段提交（Two Phase Commit,2PC）算法来完成分布式事务,比如Oracle中通过dblink方式进行事务处理。下面重点介绍下3PC算法。
下面重点介绍下三阶提交协议算法。
三阶段提交概述
三阶段提交协议可以理解为两阶段提交协议的改良版,是在协调者和参与者中都引入超时机制,并且把两阶段提交协议的第一个阶段分成了两步: 询问,然后再锁资源,最后真正提交。
两阶段提交协议最早是分布式事务的专家Jim Gray在1978年的一篇文章Notes on Database Operating Systems中提及。两阶段提交协议可以保证数据的强一致性,即保证了分布式事务的原子性：所有结点要么全做要么全不做。许多分布式关系型数据管理系统采用此协议来完成分布式事务。它是协调所有分布式原子事务参与者,并决定提交或取消（回滚）的分布式算法。同时也是解决一致性问题的算法。该算法能够解决很多的临时性系统故障（包括进程、网络节点、通信等故障）,被广泛地使用。但是,它并不能够通过配置来解决所有的故障,在某些情况下它还需要人为的参与才能解决问题。两阶段提交协议存在的问题是,协调者在某些时刻如果失败了, 整个事务就会阻塞。于是Skeen发布了"NonBlocking Commit Protocols" （1981）这篇论文,论文指出在一个分布式的事务里面, 需要一个三阶段的提交协议来避免在两阶段提交中存在的阻塞问题。
顾名思义,三阶段提交分为以下三个阶段： CanCommit PreCommit DoCommit
在三阶段提交协议中,系统一般包含两类角色： 协调者（Coordinator）,通常一个系统中只有一个； 参与者（Participant）,一般包含多个,在数据存储系统中可以理解为数据副本的个数。
CanCommit
在CanCommit阶段,协调者协议流程如下： 写本地日志“BEGIN_COMMIT”,并进入WAIT状态； 向所有参与者发送“VOTE_REQUEST”消息； 等待并接收参与者发送的对“VOTE_REQUEST”的响应。参与者响应“VOTE_ABORT”或“VOTE_COMMIT”消息给协调者。
该流程与两阶段提交协议类似。
PreCommit
在PreCommit阶段,,协调者将通知事务参与者准备提交或取消事务,写本地的redo和undo日志,但不提交。
协调者协议流程如下： 若收到任何一个参与者发送的“VOTE_ABORT”消息； 写本地“GLOBAL_ABORT”日志,进入ABORT状态； 向所有的参与者发送“GLOBAL_ABORT”消息； 若收到所有参与者发送的“VOTE_COMMIT”消息； 写本地“PREPARE_COMMIT”日志,进入PRECOMMIT状态； 向所有的参与者发送“PREPARE _COMMIT”消息； 等待并接收参与者发送的对“GLOBAL_ABORT”消息或“PREPARE_COMMIT”消息的确认响应消息。一旦收到所有参与者的“GLOBAL_ABORT”确认消息或者超时没有收到,写本地“END_TRANSACTION”日志流程结束,则不再进入DoCommit阶段。如果收到所有参与者的“PREPARE_COMMIT”确认消息,则进入DoCommit阶段。
该流程与两阶段提交协议相比,多了一个PRECOMMIT状态。
DoCommit
在该阶段,
协调者协议流程如下： 向所有参与者发送的“GLOBAL _COMMIT”消息； 等待并接收参与者发送的对 “GLOBAL_COMMIT”消息的确认响应消息,一旦收到所有参与者的确认消息,写本地“END_TRANSACTION”日志流程结束。
在DoCommit阶段,如果参与者无法及时接收到来自协调者的GLOBAL_COMMIT请求时,会在等待超时之后,会继续进行事务的提交。
三阶段提交状态机
下图为三阶段提交协议中的协调者及参与者的状态机。左侧a为协调者状态机；右侧b为参与者状态机。
三阶段提交的缺陷
相对于2PC,3PC主要解决的单点故障问题,并减少阻塞,因为一旦参与者无法及时收到来自协调者的信息之后,他会默认执行commit。而不会一直持有事务资源并处于阻塞状态。但是这种机制也会导致数据一致性问题,因为,由于网络原因,协调者发送的abort响应没有及时被参与者接收到,那么参与者在等待超时之后执行了commit操作。这样就和其他接到abort命令并执行回滚的参与者之间存在数据不一致的情况。
参考引用 本文同步至: https://waylau.com/three-phase-commitment-protocol/ 分布式事务——两阶段提交: https://waylau.com/two-phase-commitment-protocol/ Distributed systems: principles and paradigms Notes on Database Operating Systems NonBlocking Commit Protocols 分布式系统常用技术及案例分析（第二版）： https://github.com/waylau/distributed-systems-technologies-and-cases-analysis
「深度学习福利」大神带你进阶工程师,立即查看>>>
从编程开发的角度来说,Apache Dubbo （以下简称 Dubbo）首先是一款 RPC 服务框架,它最大的优势在于提供了面向接口代理的服务编程模型,对开发者屏蔽了底层的远程通信细节。同时 Dubbo 也是一款服务治理框架,它为分布式部署的微服务提供了服务发现、流量调度等服务治理解决方案。
在这篇文章中,我们将以以上基础能力为背景,尝试突破 Dubbo 体系自身,探索如何利用 Dubbo 对多协议、多服务发现模型的支持,来实现异构微服务体系间的互联互通。在实际业务场景中,这可以用来解决异构技术体系共存场景下的通信问题,帮助公司实现在异构技术体系间作平滑迁移,解决大规模跨区域、多集群部署场景的地址发现及流量调度等问题。
面向接口代理的透明服务开发框架
我们还是从 Dubbo 是一个微服务开发框架 这个大家熟知的概念开始。就像 Spring 是开发 Java 应用的基础框架一样,我们经常会选用 Dubbo 作为开发微服务业的基础框架。Dubbo 框架的最大优势我认为就在其面向接口的编程模型,使得开发远程服务调用就像开发本地服务一样（以 Java 语言为例）： 1、服务定义 public interface GreetingsService { String sayHi(String name); }
2、消费方调用服务 // 和调用本地服务一样,完全透明。 @Reference private GreetingService greetingService; public void doSayHello(String name) { greetingService.sayHi("Hello world!"); }
下图是 Dubbo 的基本工作原理图,服务提供者与服务消费者之间通过注册中心协调地址,通过约定的协议实现数据交换。
同构/异构微服务体系面临的问题
关于 Dubbo 协议本身及其服务治理相关功能细节并不是本文的重点,我们今天将从一个更高的层次,来看看公司内部构建微服务体系所面的挑战,以及 Dubbo 能为架构选型和迁移等提供哪些解决思路。
一个公司内部的微服务可能都是基于某一个相同的服务框架开发的,比如说 Dubbo,对于这样的架构,我们称之为是同构的微服务体系；而有些公司的微服务可能是使用多个不同的服务框架所建设,我们称之为异构的微服务体系,多个不同技术栈微服务体系的共存在大型组织内还是非常普遍的,造成这种局面可能有很多原因。比如,可能是遗留系统带来的,也可能是公司正在做技术栈迁移,或者就是不同业务部门为了满足各自特殊需求而做的独立选型（这也意味着异构微服务体系的长期共存）。
1、异构微服务体系共存
我们很容易想到的一个挑战是：不同的体系间通常是使用不同的 RPC 通信协议、部署独立的注册中心集群,面对这种多协议、多注册中心集群的场景,要如何实现相互之间透明的地址发现和透明的 RPC 调用？如果我们什么都不做,那么每个微服务体系就只能感知到自己体系内的服务状态,流量也在各自的体系内封闭。而要做到从体系 A 平滑的迁移到体系 B,或者想长期的保持公司内部多个体系的共存,则解决不同体系间的互联互通,实现流量的透明调度将是非常重要的环节。
2、Dubbo 体系内部 多协议、多注册中心集群的问题在同构的微服务体系中也可能存在,尤其是当一个组织内部的微服务规模增长到一定量级的时候。 我们可能要在不同的服务之间采用不同的通信协议,因为不同的服务面临不同的业务场景,而这也进一步导致了数据传输特点的不同,我们需要分别采用更适合各类业务特点的协议。比如典型的场景：我们可能对于普通的业务服务采用 Dubbo 协议,对于和 FrontEnd 交互的服务需要 HTTP 协议,而对于需要流式数据传输的业务则采用 gRPC 协议等等。 Dubbo 体系内部另一个常出现的问题是,在大规模分布式部署的场景下,微服务系统会做跨区域、跨注册中心的部署,这个时候就会出现多集群间地址同步和流量调度的问题。
总结起来,不论是同构体系还是异构体系,都面临对多协议通信、多注册中心集群地址发现的问题。Dubbo 目前是支持多协议、多注册中心的,可以说就是为解决我们上面分析的 Dubbo 同构体系内的场景而设计的,因此下面我们从同构体系的多协议、多注册中心场景讲起,先了解 Dubbo 多协议、多注册中心的基本支持情况以及它们是如何工作的。而在后面的一章再进一步探索怎么扩展这个能力来支持异构微服务体系的互联互通。
Dubbo 体系内的多协议、多注册中心机制
我们将通过两个场景示例,来分别具体的讲一下 Dubbo 的多协议、多注册中心机制的使用方式和工作原理。
多协议
以上是使用 Dubbo 开发的一套微服务,服务间通信使用到了不同的协议,根据我们的调研发现,公司内部启用多协议其实是非常普遍需求,具体场景在此我们暂不做解释。 应用 B 作为服务提供者,发布了 5 个服务,其中： DemoService1 DemoService2 通过 dubbo 协议发布 DemoService3 DemoService4 通过 gRPC 协议发布 DemoService0 通过 dubbo 、gRPC 双协议发布
应用 A 作为消费者,使用 dubbo 协议消费 DemoService1 DemoService2,使用 gRPC 协议消费 DemoService0。
应用 B 作为消费者,使用 gRPC 协议消费 DemoService2 DemoService4,使用 dubbo 协议消费 DemoService0。
以下是具体的代码配置：
1、提供端应用 B
2、消费端应用 A
3、消费端应用C
Dubbo 多协议支持现状
Dubbo 目前所支持的协议包括 Dubbo、REST、Thrift、gRPC、JsonRPC、Hessian 等,基本涵盖了业界大多数主流的 RPC 通信协议。需要注意的是,这些协议的支持都是以直接集成官方 Release 实现的形式来做的,我认为这是一个很好的选择,既保证了协议解析自身的稳定性,又能使 Dubbo 社区更专注的将更多的精力放在 Dubbo 外围服务治理能力的改善上。试想如果 Dubbo 社区自己为每个协议提供实现,那是要花费多少精力和时间才能使每种协议达到稳定的生产可用。
除了以上官方提供支持的协议之外,得益于 Dubbo 灵活的扩展机制,想要为 Dubbo 扩展协议非常容易,开发者可以随时为 Dubbo 增加更多的协议支持,包括自有协议扩展。
关于对 gRPC (HTTP/2) 协议的支持,请参阅 《Dubbo 在跨语言和协议穿透性方向的探索：支持 HTTP/2 gRPC》 。
多协议能解决的问题 将 RPC 框架无缝地接入 Dubbo 的服务治理体系。通过协议扩展将 RPC 协议纳入 Dubbo 服务开发体系,从而复用 Dubbo 的编程模型和服务发现、流量管控等能力。比如 gRPC,其服务治理体系相对比较弱、编程 API 不够友好,很难直接用于微服务开发。 满足不同场景的调用需求。 各个服务可能是为了满足不同业务需求而开发,同时外围消费端应用的技术栈也可能多种多样,通过启用不同的通信协议,可以最优化不同场景的通信需求。 实现协议间的迁移。 通过支持多种协议,借助注册中心的协调,可以快速满足公司内协议迁移的需求。如从自有协议升级到 Dubbo 协议,Dubbo 协议自身升级,从 Dubbo 协议迁移到 gRPC,从 REST 迁移到 Dubbo 协议等。
多注册中心
当服务集群规模小的时候,一个中心化的集群部署方案能很好的解决我们的业务问题。但是随着应用规模的增长、用户流量的增加,我们就不得不考虑要为业务系统引入跨区域、多集群的部署方案,而此时同业务系统密切相关的注册中心集群也面临部署方案的选型：
1、继续维持全局共享的注册中心集群。这种架构方案的优点是简单；缺点是注册中心集群由于要保存全量的地址数据,存储和推送压力会变得很大,另外对于一些注册中心产品（如 Zookeeper 等）在跨集群网络部署的场景下稳定性和性能可能都会面临挑战。
2、每个业务集群部署独立的注册中心集群。多注册中心集群的优点是能解决跨集群网络可用性的问题,同时也能够减轻注册中心的存储和推送压力；缺点则是要求服务框架（如 Dubbo 等）能有同时发布/监听多个注册中心集群的能力。
下面我们具体看一下,Dubbo 为多注册中心集群场景提供的解决方案。
上图有两个业务集群,分别部署在北京和上海,每个业务集群有自己独立的注册中心集群,要解决两个业务集群间服务的透明 RPC 通信问题。 1、服务提供端,双注册中心发布
2、服务消费端,根据消费需求做单/双注册中心订阅
Dubbo 对异构注册中心集群的支持
虽然我们会做多注册中心集群部署,但通常情况下,我们部署的都是相同的注册中心产品,如都是 Zookeeper、Nacos；而对于注册中心迁移的场景,则要求 Dubbo 能提供对更多的注册中心产品的支持,或者最重要的是要有很好的扩展能力。Dubbo 官方目前支持的注册中心实现有：
这里需要特别提到的一点是,当前 Dubbo 的服务注册/发现模型是以接口为粒度的,而从 2.7.5 版本开始,Dubbo 新引入了应用粒度的服务注册/发现模型。这一方面有助于优化 Dubbo 当前服务发现机制、提升服务容量,另一方面对于联通以 SpringCloud 为代表的微服务体系也非常重要（关于这点在下一章中有进一步提及）。更多关于《应用粒度服务发现：服务自省》的介绍,我们将在接下来的文章或文档中予以补充,请持续关注。
多订阅带来的流量调度问题
在引入多注册中心集群后,Dubbo 在流量选址时的多了一层注册中心集群间的负载均衡：
在 Cluster Invoker 这一级,我们支持的选址策略有（2.7.5+ 版本,具体使用请参见文档）：
1、指定优先级
2、同 zone 优先
3、权重轮选
4、默认,stick to 任意可用
多注册中心适用的场景 同区域流量优先调度 出于容灾或者服务伸缩性需求,服务/应用往往需要部署在多个独立的机房/区域,在每个区域有独立注册中心集群的场景下,实现同区域的流量优先调度就能很好的解决延迟和可用性问题。 注册中心迁移 公司的服务一直以来可能是存储在某一个注册中心,如 Zookeeper,但到了某个时间节点,因为各种各样的原因,当我们要迁移到另外的注册中心时,多注册中心模型能够保证平滑的迁移。 异构系统互通 不同微服务体系开发的服务,都封闭在各自的服务发现体系中,而通过统一的多注册中心模型,可以实现不同体系的服务互相发现。
借助 Dubbo 联通异构的微服务体系
上文我们提到了在组织内存在异构微服务体系的各种合理可能性,现在我们来具体看一下异构微服务体系的实际场景,以及使用 Dubbo 实现互联互通的解决方法。首先我们先通过一张图来看一下,联通异构的微服务体系具体是一个什么样的场景。
如上图所示,我们有部分微服务可以是基于 SpringCloud、gRPC、K8S 或者是自建体系构建的,他们各自之间默认是相互隔离无法联通的。当我们再构建一套基于 Dubbo 的微服务体系时,则利用 Dubbo 的多协议、多服务发现模型,我们就可以做到和各个微服务体系间的两两之间的互联互通。进一步的,如图中橙色箭头所示,依赖 Dubbo 体系作为桥接层,我们还可以实现两个异构微服务体系间的打通。
对于以下几个示例场景,由于在地址发现层面目前没有统一的标准,我们暂且假设地址发现层面不同的体系建是没有障碍的,我们将重点关注迁移的基本流程以及通信协议环节。（关于地址发现部分,我们将在后续《服务自省：基于应用粒度的服务发现》之后再深入探讨）
Dubbo 体系内的协议迁移（共存）
绝大多数开发者对 Dubbo 有这么一个固有认知：使用 Dubbo 开发微服务系统,则就要用 Dubbo 协议来作为服务间的通信协议才是最优方案。实际上,我们完全没有必要只束缚在 Dubbo RPC 协议上。Dubbo 作为微服务开发框架和 Dubbo 作为 RPC 协议这是两个概念,其实是完全可以分开来看待的,比如我们用 Dubbo 框架开发的业务系统,选用 rest、gRPC 通信是完全没有问题的（参加 Dubbo 支持的协议列表）,具体用什么协议根据业务特点和技术规划才是最适合的。
当前在云原生、Mesh 的大背景下, HTTP1/2、gRPC 协议开始受到越来越多的关注,一方面原因自然是因为它们在标准化方面做的更好,得到的更多的网络设备和基础设施的支持,具备更好的通用性和穿透性。对于很多有云原生迁移意愿的企业来说,往此类协议迁移无疑将对之后的架构升级有更多的帮助。
下图演示了在 Dubbo 体系内,从 Dubbo 协议向 gRPC 协议迁移的一个中间状态。
最左边的代表尚未迁移的老应用,这类应用在迁移过程中仍然要消费和提供 Dubbo 协议的服务。 中间的代表处于迁移中的应用,他们中间可能有些是服务提供者,既要为左边的老系统提供提供 Dubbo 协议服务；又要为右边的新系统提供 gRPC 服务；因此他们都是双协议暴露服务。 最右边则代表是新开发的或者已经迁移完成的应用,这个体系内已能完全用 gRPC 协议通信。 最终度过中间态后,我们期望所有的应用都达到最左边应用的状态,实现完全的 gRPC 协议通信。
Spring Cloud 体系迁移到 Dubbo 体系（共存）
如前文所述,由于 SpringCloud 和 Dubbo 间服务发现模型的问题,要两个体系间的地址互通需要 Dubbo 侧作相应的适配,关于这部分内容将在接下来的 2.7.5 版本《服务自省》部分发布,在此我们暂且认为已经打通。
Dubbo 体系内的部分应用作为透明的联通两个体系的关键节点,部分服务提供者应用要双协议发布、部分消费者应用要做到选定协议消费。由于老的 Spring Cloud 体系不允许做任何改动,因此联通两套体系的关键是 REST 协议,对 Dubbo 侧的应用来说： 部分应用可能要以 REST 协议消费 SpringCloud 的服务； 部分应用可能要暴露 REST 协议共 SpringCloud 消费； Dubbo 自有体系内则通过自己选定的协议通信,这里就比较灵活了,可以是 Dubbo、REST、gRPC 等其中的任一种。而如果选定 REST 协议则对于与 SpringCloud 体系的联通就变得更加自然了,因为两端的协议都是统一的。
对于消费 Spring Cloud 服务的应用,要配置服务 ：
对于提供服务给 Spring Cloud 侧消费的应用,则指定服务暴露为 rest 协议,或者双协议暴露（因如果这个服务还要被新体系内的应用调用到）：
作为 Dubbo 的维护者,虽然我们这里有明显的偏向性,讲的是从如何从 SpringCloud 体系迁移到 Dubbo 体系。但是反过来考虑,如果你已经或者即将选型 Dubbo 来开发微服务,则未来从 Dubbo 迁移到 SpringCloud 也是同样的思路,Dubbo 的多协议、多注册模型为双向迁移都提供了同样的灵活性。
自建体系迁移到 Dubbo 体系（共存）
这个场景和上一节中讲到的的 SpringCloud 迁移有些类似,最大的区别在于 rest 协议是 Dubbo 官方默认提供支持的,而对于已有的微服务体系内的私有通信协议,则需要先要自己去扩展 Dubbo Protocol 来提供协议层面的支持,关于 Protocol 如何扩展请参见以下官方文档： http://dubbo.apache.org/zh-cn/docs/dev/impls/protocol.html
总结与展望
要实现异构微服务体系间的共存或迁移,关键点在打通异构体系间的协议与服务发现,得益于 Dubbo 自身对多协议、多注册模型的支持,我们可以很容易的使 Dubbo 成为桥接异构微服务体系的中间层。熟悉 Dubbo 多协议实现细节的同学,可能会担心在服务数量较多的场景下,多协议注册会导致地址数量翻倍从而影响地址推送性能。 另外,在本文“借助 Dubbo 联通异构的微服务体系”一节中,关于如何实现异构体系间的透明服务发现部分,我们没有做详细的说明。涉及服务发现的这部分,我们将在接下来的文章中做具体阐述,看看 Dubbo 2.7.5 版本引入新的服务发现机制是如何解决这个问题的,请持续关注后续文章及 Dubbo 官方文档。
作者信息 ： 刘军,GitHub 账号 Chickenlj,Apache Dubbo PMC,项目核心维护者,见证了 Dubbo 从重启开源到 Apache 毕业的整个流程。现任职阿里云云原生应用平台团队,参与服务框架、微服务相关工作,目前主要在推动 Dubbo 开源的云原生化。 “ 阿里巴巴云原生 关注微服务、Serverless、容器、Service Mesh 等技术领域、聚焦云原生流行技术趋势、云原生大规模的落地实践,做最懂云原生开发者的技术圈。”
「深度学习福利」大神带你进阶工程师,立即查看>>>
> 原文链接： Istio 1.4 部署指南
Istio 一直处于快速迭代更新的过程中,它的部署方法也在不断更新,之前我在 1.0 版本中介绍的安装方法,对于最新的 1.4 版本已经不适用了。以后主流的部署方式都是用 istioctl 进行部署,helm 可以渐渐靠边站了~~
在部署 Istio 之前,首先需要确保 Kubernetes 集群（kubernetes 版本建议在 1.13 以上）已部署并配置好本地的 kubectl 客户端。
1. Kubernetes 环境准备
为了快速准备 kubernetes 环境,我们可以使用 sealos 来部署,步骤如下：
前提条件 下载 kubernetes 离线安装包 下载 最新版本sealos 务必同步服务器时间 主机名不可重复
安装 kubernetes 集群 $ sealos init --master 192.168.0.2 \ --node 192.168.0.3 \ --node 192.168.0.4 \ --node 192.168.0.5 \ --user root \ --passwd your-server-password \ --version v1.16.3 \ --pkg-url /root/kube1.16.3.tar.gz
检查安装是否正常： $ kubectl get node NAME STATUS ROLES AGE VERSION sealos01 Ready master 18h v1.16.3 sealos02 Ready
18h v1.16.3 sealos03 Ready 18h v1.16.3 sealos04 Ready 18h v1.16.3
2. 下载 Istio 部署文件
你可以从 GitHub 的 release 页面下载 istio,或者直接通过下面的命令下载： $ curl -L https://istio.io/downloadIstio | sh -
下载完成后会得到一个 istio-1.4.2 目录,里面包含了： install/kubernetes : 针对 Kubernetes 平台的安装文件 samples : 示例应用 bin : istioctl 二进制文件,可以用来手动注入 sidecar proxy
进入 istio-1.4.2 目录。 $ cd istio-1.4.2 $ tree -L 1 ./ ./ ├── bin ├── demo.yaml ├── install ├── LICENSE ├── manifest.yaml ├── README.md ├── samples └── tools 4 directories, 4 files
将 istioctl 拷贝到 /usr/local/bin/ 中： $ cp bin/istioctl /usr/local/bin/
开启 istioctl 的自动补全功能
bash
将 tools 目录中的 istioctl.bash 拷贝到 $HOME 目录中： $ cp tools/istioctl.bash ~/
在 ~/.bashrc 中添加一行： source ~/istioctl.bash
应用生效： $ source ~/.bashrc
zsh
将 tools 目录中的 _istioctl 拷贝到 $HOME 目录中： $ cp tools/_istioctl ~/
在 ~/.zshrc 中添加一行： source ~/_istioctl
应用生效： $ source ~/.zshrc
3. 部署 Istio
istioctl 提供了多种安装配置文件,可以通过下面的命令查看： $ istioctl profile list Istio configuration profiles: minimal remote sds default demo
它们之间的差异如下：
default demo minimal sds remote 核心组件 | istio-citadel | X | X | | X | X |
|---|
| istio-egressgateway | | X | | | |
| istio-galley | X | X | | X | |
| istio-ingressgateway | X | X | | X | |
| istio-nodeagent | | | | X | |
| istio-pilot | X | X | X | X | |
| istio-policy | X | X | | X | |
| istio-sidecar-injector | X | X | | X | X |
| istio-telemetry | X | X | | X |
附加组件 | Grafana | istio-tracing | kiali | prometheus |
| | | X |
| X | X | X | X |
| | | |
| | | X |
| | | |
其中标记 X 表示该安装该组件。
如果只是想快速试用并体验完整的功能,可以直接使用配置文件 demo 来部署。
在正式部署之前,需要先说明两点：
Istio CNI Plugin
当前实现将用户 pod 流量转发到 proxy 的默认方式是使用 privileged 权限的 istio-init 这个 init container 来做的（运行脚本写入 iptables）,需要用到 NET_ADMIN capabilities。对 linux capabilities 不了解的同学可以参考我的 Linux capabilities 系列 。
Istio CNI 插件的主要设计目标是消除这个 privileged 权限的 init container,换成利用 Kubernetes CNI 机制来实现相同功能的替代方案。具体的原理就是在 Kubernetes CNI 插件链末尾加上 Istio 的处理逻辑,在创建和销毁 pod 的这些 hook 点来针对 istio 的 pod 做网络配置：写入 iptables,让该 pod 所在的 network namespace 的网络流量转发到 proxy 进程。
详细内容请参考 官方文档 。
使用 Istio CNI 插件来创建 sidecar iptables 规则肯定是未来的主流方式,不如我们现在就尝试使用这种方法。
Kubernetes 关键插件（Critical Add-On Pods）
众所周知,Kubernetes 的核心组件都运行在 master 节点上,然而还有一些附加组件对整个集群来说也很关键,例如 DNS 和 metrics-server,这些被称为 关键插件 。一旦关键插件无法正常工作,整个集群就有可能会无法正常工作,所以 Kubernetes 通过优先级（PriorityClass）来保证关键插件的正常调度和运行。要想让某个应用变成 Kubernetes 的 关键插件 ,只需要其 priorityClassName 设为 system-cluster-critical 或 system-node-critical ,其中 system-node-critical 优先级最高。
> 注意：关键插件只能运行在 kube-system namespace 中！
详细内容可以参考 官方文档 。
接下来正式安装 istio,命令如下： $ istioctl manifest apply --set profile=demo \ --set cni.enabled=true --set cni.components.cni.namespace=kube-system \ --set values.gateways.istio-ingressgateway.type=ClusterIP
istioctl 支持两种 API： IstioControlPlane API Helm API
在上述安装命令中,cni 参数使用的是 IstioControlPlane API,而 values.* 使用的是 Helm API。
部署完成后,查看各组件状态： $ kubectl -n istio-system get pod NAME READY STATUS RESTARTS AGE grafana-6b65874977-8psph 1/1 Running 0 36s istio-citadel-86dcf4c6b-nklp5 1/1 Running 0 37s istio-egressgateway-68f754ccdd-m87m8 0/1 Running 0 37s istio-galley-5fc6d6c45b-znwl9 1/1 Running 0 38s istio-ingressgateway-6d759478d8-g5zz2 0/1 Running 0 37s istio-pilot-5c4995d687-vf9c6 0/1 Running 0 37s istio-policy-57b99968f-ssq28 1/1 Running 1 37s istio-sidecar-injector-746f7c7bbb-qwc8l 1/1 Running 0 37s istio-telemetry-854d8556d5-6znwb 1/1 Running 1 36s istio-tracing-c66d67cd9-gjnkl 1/1 Running 0 38s kiali-8559969566-jrdpn 1/1 Running 0 36s prometheus-66c5887c86-vtbwb 1/1 Running 0 39s $ kubectl -n kube-system get pod -l k8s-app=istio-cni-node NAME READY STATUS RESTARTS AGE istio-cni-node-k8zfb 1/1 Running 0 10m istio-cni-node-kpwpc 1/1 Running 0 10m istio-cni-node-nvblg 1/1 Running 0 10m istio-cni-node-vk6jd 1/1 Running 0 10m
可以看到 cni 插件已经安装成功,查看配置是否已经追加到 CNI 插件链的末尾： $ cat /etc/cni/net.d/10-calico.conflist { "name": "k8s-pod-network", "cniVersion": "0.3.1", "plugins": [ ... { "type": "istio-cni", "log_level": "info", "kubernetes": { "kubeconfig": "/etc/cni/net.d/ZZZ-istio-cni-kubeconfig", "cni_bin_dir": "/opt/cni/bin", "exclude_namespaces": [ "istio-system" ] } } ] }
默认情况下除了 istio-system namespace 之外,istio cni 插件会监视其他所有 namespace 中的 Pod,然而这并不能满足我们的需求,更严谨的做法是让 istio CNI 插件至少忽略 kube-system 、 istio-system 这两个 namespace,怎么做呢？
也很简单,还记得之前提到的 IstioControlPlane API 吗？可以直接通过它来覆盖之前的配置,只需要创建一个 IstioControlPlane CRD 就可以了。例如： $ cat cni.yaml apiVersion: install.istio.io/v1alpha2 kind: IstioControlPlane spec: cni: enabled: true components: namespace: kube-system values: cni: excludeNamespaces: - istio-system - kube-system - monitoring unvalidatedValues: cni: logLevel: info $ istioctl manifest apply -f cni.yaml
删除所有的 istio-cni-node Pod： $ kubectl -n kube-system delete pod -l k8s-app=istio-cni-node
再次查看 CNI 插件链的配置： $ cat /etc/cni/net.d/10-calico.conflist { "name": "k8s-pod-network", "cniVersion": "0.3.1", "plugins": [ ... { "type": "istio-cni", "log_level": "info", "kubernetes": { "kubeconfig": "/etc/cni/net.d/ZZZ-istio-cni-kubeconfig", "cni_bin_dir": "/opt/cni/bin", "exclude_namespaces": [ "istio-system", "kube-system", "monitoring" ] } } ] }
4. 暴露 Dashboard
这个没什么好说的,通过 Ingress Controller 暴露就好了,可以参考我以前写的 Istio 1.0 部署 。如果使用 Contour 的可以参考我的另一篇文章： Contour 学习笔记（一）：使用 Contour 接管 Kubernetes 的南北流量 。
这里我再介绍一种新的方式, istioctl 提供了一个子命令来从本地打开各种 Dashboard： $ istioctl dashboard --help Access to Istio web UIs Usage: istioctl dashboard [flags] istioctl dashboard [command] Aliases: dashboard, dash, d Available Commands: controlz Open ControlZ web UI envoy Open Envoy admin web UI grafana Open Grafana web UI jaeger Open Jaeger web UI kiali Open Kiali web UI prometheus Open Prometheus web UI zipkin Open Zipkin web UI
例如,要想在本地打开 Grafana 页面,只需执行下面的命令： $ istioctl dashboard grafana http://localhost:36813
咋一看可能觉得这个功能很鸡肋,我的集群又不是部署在本地,而且这个命令又不能指定监听的 IP,在本地用浏览器根本打不开呀！其实不然,你可以在本地安装 kubectl 和 istioctl 二进制文件,然后通过 kubeconfig 连接到集群,最后再在本地执行上面的命令,就可以打开页面啦,开发人员用来测试是不是很方便？Windows 用户当我没说。。。
5. 暴露 Gateway
为了暴露 Ingress Gateway,我们可以使用 HostNetwork 模式运行,但你会发现无法启动 ingressgateway 的 Pod,因为如果 Pod 设置了 HostNetwork=true ,则 dnsPolicy 就会从 ClusterFirst 被强制转换成 Default 。而 Ingress Gateway 启动过程中需要通过 DNS 域名连接 pilot 等其他组件,所以无法启动。
我们可以通过强制将 dnsPolicy 的值设置为 ClusterFirstWithHostNet 来解决这个问题,详情参考： Kubernetes DNS 高阶指南 。
修改后的 ingressgateway deployment 配置文件如下： apiVersion: extensions/v1beta1 kind: Deployment metadata: name: istio-ingressgateway namespace: istio-system ... spec: ... template: metadata: ... spec: affinity: nodeAffinity: ... requiredDuringSchedulingIgnoredDuringExecution: nodeSelectorTerms: - matchExpressions: - key: kubernetes.io/hostname operator: In values: - 192.168.0.4 # 假设你想调度到这台主机上 ... dnsPolicy: ClusterFirstWithHostNet hostNetwork: true restartPolicy: Always ...
接下来我们就可以在浏览器中通过 Gateway 的 URL 来访问服务网格中的服务了。后面我会开启一系列实验教程,本文的所有步骤都是为后面做准备,如果想跟着我做后面的实验,请务必做好本文所述的准备工作。
微信公众号
扫一扫下面的二维码关注微信公众号,在公众号中回复◉加群◉即可加入我们的云原生交流群,和孙宏亮、张馆长、阳明等大佬一起探讨云原生技术
「深度学习福利」大神带你进阶工程师,立即查看>>>
简介
首先介绍下在本文出现的几个比较重要的概念：
函数计算（Function Compute）：函数计算是一个事件驱动的服务,通过函数计算,用户无需管理服务器等运行情况,只需编写代码并上传。函数计算准备计算资源,并以弹性伸缩的方式运行用户代码,而用户只需根据实际代码运行所消耗的资源进行付费。函数计算更多信息 参考
函数工作流（Function Flow）：函数工作流是一个用来协调多个分布式任务执行的全托管云服务。用户可以用顺序,分支,并行等方式来编排分布式任务,FnF 会按照设定好的步骤可靠地协调任务执行,跟踪每个任务的状态转换,并在必要时执行用户定义的重试逻辑,以确保工作流顺利完成。函数工作流更多信息 参考
本文将重点介绍如何快速地通过函数计算与函数工作流部署一个定时离线批量处理图片文件并标注出人脸的服务。
开通服务 免费开通函数计算 ,按量付费,函数计算有很大的免费额度。 免费开通函数工作流 ,按量付费,目前该产品在公测阶段,可以免费使用。 免费开通对象存储 ,按量付费。
解决方案
流程如下： 设定定时触发器,定时触发函数计算中的函数。 函数被触发后,调用一次函数工作流中的流程。 函数工作流中的流程被执行: 调用函数计算中的函数,列举出 OSS Bucket 根路径下的图片文件列表。 对于步骤1中列出的文件列表,对每个文件： - 调用函数计算中的函数处理,进行人脸识别并标注。将标注后的文件存入 OSS,最后将处理过的文件进行转移。 判断当前 OSS 根路径下是否有更多的文件 - 如是,继续步骤1 - 如否,结束流程
快速开始 Clone 工程到本地 git clone git@github.com:ChanDaoH/serverless-face-recognition.git 替换项目目录下 template.yml 文件中的 YOUR_BUCKET_NAME 为在杭州区域的 OSS Bucket (可以不是杭州区域的,需要同步修改 OSS_ENDPOINT ) ROSTemplateFormatVersion: '2015-09-01' Transform: 'Aliyun::Serverless-2018-04-03' Resources: face-recognition: Type: 'Aliyun::Serverless::Service' Properties: Policies: - Version: '1' Statement: - Effect: Allow Action: - 'oss:ListObjects' - 'oss:GetObject' - 'oss:PutObject' - 'oss:DeleteObject' - 'fnf:*' Resource: '*' listObjects: Type: 'Aliyun::Serverless::Function' Properties: Handler: index.handler Runtime: python3 Timeout: 60 MemorySize: 128 CodeUri: functions/listobjects EnvironmentVariables: OSS_ENDPOINT: 'https://oss-cn-hangzhou-internal.aliyuncs.com' detectFaces: Type: 'Aliyun::Serverless::Function' Properties: Handler: index.handler Runtime: python3 Timeout: 60 MemorySize: 512 CodeUri: functions/detectfaces EnvironmentVariables: OSS_ENDPOINT: 'https://oss-cn-hangzhou-internal.aliyuncs.com' timer: Type: 'Aliyun::Serverless::Function' Properties: Handler: index.handler Runtime: python3 Timeout: 60 MemorySize: 512 CodeUri: functions/timer Events: timeTrigger: Type: Timer Properties: CronExpression: '0 * * * * *' Enable: true # replace YOUR_BUCKET_NAME to your oss bucket name Payload: '{"flowName": "oss-batch-process", "input": "{\"bucket\": \"YOUR_BUCKET_NAME\",\"prefix\":\"\"}"}' oss-batch-process: Type: 'Aliyun::Serverless::Flow' Properties: Description: batch process flow DefinitionUri: flows/index.flow.yml Policies: - AliyunFCInvocationAccess 一键部署函数计算和函数工作流资源至云端 安装最新版本的 Fun 在项目根目录下执行 fun deploy
效果验证 在 OSS Bucket 的根目录下放置图片
等待一分钟后,定时触发器触发函数执行函数工作流。
工作流执行完成后,查看 OSS Bucket 标注出人脸的图像放置在 face-detection 目录下
处理过的录像放置在 processed 目录下
总结
通过 函数计算 + 函数工作流 ,搭建了一个定时批量处理图片进行人脸识别的服务。该服务因为使用了函数工作流的流程,将任务分为了多个步骤,只需要确保每个步骤的函数能够在函数计算限制时间(10分钟)内完成即可。 通过 Fun 工具,一键部署 函数计算 + 函数工作流 ,免去去多平台进行操作的步骤。
相关参考 函数计算 函数工作流 Aliyun Serverless VSCode 插件 Fun
参考示例 serverless-face-recognition oss-batch-process “ 阿里巴巴云原生 关注微服务、Serverless、容器、Service Mesh 等技术领域、聚焦云原生流行技术趋势、云原生大规模的落地实践,做最懂云原生开发者的技术圈。”
「深度学习福利」大神带你进阶工程师,立即查看>>>
以前的Dockerfile重新build时出现无法执行 apt-get update,在宿主机是可以的。
找到个攻略,docker build加上--network=host参数,临时解决！
第二种方法： the problem was with Internet connection, as mine connection is at enterprise level and because of that It was unable to execute apt-get update command. Solution worked for me is : find your DNS server address using cat /etc/resolv.conf Open Docker confg file and uncomment DOCKER_OPTS and add your DNS server over there Docker config file : sudo gedit /etc/default/docker
参考： https://www.v2ex.com/t/575898 https://askubuntu.com/questions/1167080/unable-to-update-ubuntu-docker-container-using-apt-get-update https://www.cnblogs.com/surplus/p/11580707.html
.png)
大数据引擎.png)
大数据应用.png)
大数据底层技术.png)
ForeSpider软件
.png)
采集服务.png)
软件学习.png)
智能分析.png)
特征提取.png)
智能计算.png)
数据可视化.png)
数据分析应用.png)
系统集成服务.png)
代码工具.png)
金融方案.png)
制造业&物流.png)
企业数字化.png)
医疗方案.png)
政务方案.png)
实时监测.png)
智能分析.png)
数据智能挖掘.png)
全网自动采集.png)
场景智慧采集.png)
主题识别采集
注册即送：30天知析标讯会员权益
022-2345 2937
185 2247 0110
business@forenose.com
客服微信
订阅号
服务号
022-2345 2937
185 2247 0110（同微信）
business@forenose.com
2779623375
前嗅大数据
津公网安备12010102001008号