导读：云原生操作系统进化，详解阿里云 ACK Pro、ASM、ACR EE、ACK@Edge 等四款企业级容器新品。

KubeCon 2020 中国站，阿里云容器服务负责人易立会在《云原生，数字经济技术创新基石》的演讲中，分享阿里云原生如何助力数字技术抗‘疫’，阐述阿里云对云原生操作系统的思考，同时详解阿里云 ACK Pro、ASM、ACR EE、ACK@Edge 四款企业级容器新品。

容器服务 ACK Pro，为企业级大规模生产环境提供增强的可靠性安全性，以及与可赔付标准 SLA，现已开启公测。同时还有三款产品商业化：服务网格 ASM，统一精准管控容器化微服务应用流量；容器镜像服务企业版 ACR EE，公共云首个独享实例形态的容器镜像仓库产品，是支撑阿里巴巴经济体的双十一同款利器，具备如下能力：多维度安全保障、全球镜像分发加速、DevSecOps 交付提效特点，保障企业客户云原生制品的安全托管及高效分发；边缘容器 ACK@Edge 采用非侵入方式增强，提供边缘自治、边缘单元、边缘流量管理、原生运维 API 支持等能力，以原生方式支持边缘计算场景下的应用统一生命周期管理和统一资源调度。

疫情期间，争分夺秒的云原生

云计算是数字时代新基建，而 2020 疫情也为数字化生活按下了快进键。“上班用钉钉，上学云课堂，出门健康码，订菜送到家”成为了日常生活一部分，这背后是一系列云计算、云原生技术支撑的业务创新。

2 小时内支撑了钉钉业务 1 万台云主机的扩容需求，基于阿里云服务器和容器化的应用部署方案，钉钉应用发布扩容效率大大提升，顺利扛住有史以来最大的流量洪峰，为全国用户提供线上工作的流畅体验。

停课不停学，希沃课堂整体业务性能提升 30%、运维成本降低 50%，洋葱学院系统资源利用率提升 60%。

健康码基于云原生大数据平台具备弹性、韧性和安全的特点，平稳支撑每日亿次调用。

盒马通过阿里云边缘容器服务 ACK@Edge，快速构建人、货、场数字化全链路融合，云、边、端一体化协同的天眼 AI 系统。结合了云原生技术体系良好的资源调度和应用管理能力，与边缘计算就近访问，实时处理的优势，轻松实现全方位的『降本提效』，门店计算资源成本节省 50%，新店开服效率提升 70%。

云原生操作系统的诞生与进化

容器技术的发展揭开了云原生计算的序幕，在易立看来， Kubernetes 为基础的云原生计算也已经成为新的操作系统，云原生操作系统的雏形被越来越多的行业和企业采纳并因此受益：容器应用化、容器编排系统和 Istio 服务网格等技术依次解耦了应用与运行环境、资源编排调度与底层基础设施、服务实现与服务治理等传统架构的依赖关系。

阿里云为用户提供了怎样的云原生操作系统？这个云原生操作系统又有哪些突出特点呢？

首先基础设施层是强大的 IaaS 资源，基于第三代神龙架构的计算资源可以更弹性的扩展，以更加优化的成本提供更高的性能；云原生的分布式文件系统，为容器持久化数据而生；云原生网络加速应用交付能力，提供应用型负载均衡与容器网络基础设施。

其次在容器编排层，阿里云容器服务自 2015 年上线来，伴随数千家企业客户，共同实践过各行各业大量生产级场景。越来越多的客户以云原生的方式架构其大部分甚至全量应用，随着业务深入发展，为了满足大中型企业对可靠性、安全性的强烈需求，阿里云推出新品可供赔付 SLA 的容器服务企业版 ACK Pro。

容器服务企业版 ACK Pro 横空出世：全面安全、高性能，支持新一代神龙架构，SLA 可赔付

容器服务企业版 ACK Pro，是在原容器服务 ACK 托管版集群的基础上发展而来，其继承了原托管版集群的所有优势，例如 Master 节点托管和高可用等。同时，相比原托管版进一步提升了集群的可靠性、安全性和调度性能，并且支持赔付标准的 SLA，高达 99.95%，单集群可支持 5000 节点。ACK Pro 非常适合生产环境下有着大规模业务、对稳定性和安全性有高要求的企业客户。

ACK Pro 支持神龙架构，凭借软硬一体的优化设计，可为企业应用提供卓越的性能；支持无损 Terway 容器网络，相比路由网络延迟下降 30%；为企业提供全面安全防护，支持阿里云安全沙箱容器，满足企业客户对应用的安全、隔离需求，性能相比开源提升 30%。此外，ACK Pro 提供了对异构算力和工作负载优化的高效调度，支持智能 CPU 调度优化，在保障 SLA 和密度的前提下，Web 应用 QPS 提升 30%；支持 GPU 算力共享, AI 模型预测成本节省 50% 以上。

阿里云视频云已在全球十多个区域使用容器服务作为服务基础，有效管理全球万级节点的资源，其中 ACK Pro 切实保障基础设施层大规模计算资源的运维效率和高稳定性，使视频云团队可以将更多时间精力聚焦在视频领域从而为客户提供更多价值。

近日， 阿里云容器服务并成为国内首批通过可信云容器安全先进性认证的企业级容器平台，以 49 个满分项目荣获最高级别先进级认证，特别是在最小化攻击面，二进制镜像验签名，密文的 BYOK 加密等能力上国内领先，达到国际先进水平。

容器服务 ACK Pro 现已正式开启公测，非常适用于互联网、大数据计算、金融政府及跨海业务企业等，欢迎各位感兴趣的客户在官网上申请试用。

业内首个全托管 Istio 兼容服务网格 ASM，多种异构应用服务统一治理

在服务网格技术诞生前，应用服务治理的逻辑实现通常都是以代码库的方式嵌入在应用程序中，随着应用复杂度的增长和团队规模的扩大，代码库变更和维护会变地越来越复杂。服务网格通过 Sidecar 代理功能，将服务治理能力与应用程序本身解耦，将服务治理能力标准化、统一化，且更好地支持多种编程语言和技术框架的应用服务。

作为业内首个全托管 Istio 兼容的服务网格产品 ASM，已经正式商业化发布，用户可以在多个地域部署使用。阿里云一开始从架构上就保持了与社区、业界趋势的领先性，控制平面的组件托管在阿里云侧，与数据面侧的用户集群独立。ASM 在托管的控制面侧提供了用于支撑精细化的流量管理和安全管理的组件能力。通过托管模式，解耦了 Istio 组件与所管理的 K8s 集群的生命周期管理，使得架构更加灵活，提升了系统的可伸缩性。

商米科技使用服务网格 ASM 之后，充分享受了 Service Mesh 带来的好处，解决了 GRPC-HTTP2.0 多路复用引起的负载不均衡的问题，得以分离控制平面和数据平面，受益于 ASM 的可视化方式对控制平面进行管理，对规则配置一目了然。同时还无缝结合链路监控（Tracing Analysis）解决服务化体系下调用链排查追踪问题。

作为多种类型计算服务统一管理的基础设施, ASM 提供了统一的流量管理能力、统一的服务安全能力、统一的服务可观测性能力、以及统一的数据面可扩展能力, 并提出了相应的实践之成熟度模型。针对用户不同的场景, 逐步采用, 分别为一键启用、可观测提升、安全加固、多种基础设施的支持以及多集群混合管理。

全球镜像同步加速，ACR EE 保障云原生制品的安全托管及高效分发

容器镜像服务企业版 ACR EE 面向安全及性能需求高，业务多地域大规模部署的企业级客户，提供了公共云首个独享实例模式的企业版服务。

在制品托管部分，ACR EE 除了支持多架构容器镜像，还支持多版本 Helm Chart 等符合 OCI 规范制品托管。在分发及安全治理部分，ACR EE 加强了全球多地域分发和大规模分发支持，提供网络访问控制、安全扫描、安全加签、安全审计等多维度安全保障，助力企业从 DevOps 到 DevSecOps 的升级。目前已有数百家企业线上环境大规模使用，保障企业客户云原生应用制品的安全托管及高效分发。

某国际零售巨头是全球多地域业务形态，存在多地研发协作及多地域部署的场景。采用 ACR EE 之后，客户只需配置实例同步规则，在业务迭代更新容器镜像后，可实现分钟级自动同步至全球指定地域，自动触发 ACK 集群业务部署。完美应对跨海网络链路不稳定、分发不安全的问题，极大提高业务研发迭代效率和部署稳定性，保障企业业务的全球化部署。

除了业务镜像全球自动化部署，也有很多企业通过 ACR EE 的云原生应用交付链功能，通过全链路可追踪、可观测、可自主配置等实践容器化 DevSecOps。

业界首创“云边一体化”理念 ，边缘容器服务 ACK@Edge 正式商业化

与此同时，阿里云深度挖掘了“边缘计算+云原生落地实施”诉求，在去年 KubeCon 上，重磅发布了边缘容器（ACK@Edge），时隔一年，宣布 ACK@Edge 正式商用。此外，ACK@Edge 也将其核心能力开源，并向社区贡献完整的云原生边缘计算项目——OpenYurt。

在过去短短一年的时间里，该款产品已经应用于音视频直播、云游戏、工业互联网、交通物流、城市大脑等应用场景中，并服务于盒马、优酷、阿里视频云和众多互联网、新零售企业。

YY 使用 ACK@Edge 之后，可以 API 统一管理、统一运维边缘容器集群和中心容器集群，边缘算力快速接入并实现边缘节点自治，同时也可以无缝接入 Prometheus 服务实现监控数据上报，总体上运维效率和资源使用率都得到显著改善。

ACK@Edge 适用于丰富的应用场景， 包括边缘智能、智慧楼宇、智慧工厂、音视频直播、在线教育、CDN。

云原生技术不但可以最大化云的弹性，帮助企业实现降本提效；而且还意味着更多创新的想象空间， 云原生将和 AI, 边缘计算，机密计算等新技术相结合，为数字经济构建智能、互联、信任的创新基础设施。

“新基石、新算力、新生态是容器产品发展策略 ” ，易立称，“云原生技术正成为释放云价值的最短路径，团队会帮助企业更好支撑混合云、云边一体的分布式云架构和全球化应用交付。基于云原生的软硬一体化技术创新，如神龙架构，含光芯片，GPU 共享调度等，阿里云将加速业务智能化升级。同时我们还会通过开放技术生态和全球合作伙伴计划，让更多企业分享云时代技术红利。”

“阿里巴巴云原生关注微服务、Serverless、容器、Service Mesh 等技术领域、聚焦云原生流行技术趋势、云原生大规模的落地实践，做最懂云原生开发者的公众号。”

跟大家分享几个好消息：

在今天“2020 可信云线上峰会”上，中国信通院公布了多项可信云认证的评估结果。阿里云原生在容器平台安全能力、函数及服务、分布式消息队列服务、可信云服务最佳实践（服务云）、可信云技术最佳实践（容器及管理）等评选中获得可信云认证！

多年来，阿里巴巴作为云原生领域的先行者、实践者，基于自身累积多年的最佳实践，对社区赋能，为企业提供普惠的云原生产品服务。在这次可信云评选中，阿里云原生更是拿到5项大奖，从技术到实践，以最全面的技术影响力推动云原生进入新的阶段！

下面我们来一一揭开这些奖项！

NO.1：阿里云 49 个满分，获得可信云容器安全能力先进级认证

今天，信通院发布了国内云厂商的容器安全评估结果：阿里云容器服务 ACK 和容器镜像服务 ACR 荣获最高级别先进级可信云安全能力认证，特别是在最小化攻击面，二进制镜像验签名，密文的 BYOK 加密等能力上国内领先，达到国际先进水平。

早在 2018 年，阿里云容器服务团队率先提出了“端到端的企业级安全能力”概念，并推出立体式的端到端云原生安全架构，从三个层面来解决安全问题：

• 最底层依托于阿里云平台已有的安全能力，包括物理安全，硬件安全，虚拟化安全和云产品安全能力;
• 中间是容器基础设施安全层，基于最小化攻击面原则，提供了包括访问控制，权限收敛，配置加固和身份管理等重要的底座安全能力；同时针对凭证下发，证书、密钥，集群审计等用户访问链路上的安全要素，构建了对应的自动化运维体系；
• 在容器基础设施安全层之上，针对容器应用从构建到运行的生命周期在供应链和运行时刻提供对应的安全能力，比如在构建阶段提供了镜像安全扫描和镜像签名能力；在部署和运行时刻，提供了集运行时策略管理，配置巡检，运行时安全扫描的一体化安全管理能力，同时支持安全沙箱容器和TEE机密计算技术，为企业容器应用提供更好的安全隔离性和数据安全私密性。

2020 年 5 月， Gartner 发布《Solution Comparison for the Native Security Capabilitieis 》报告，首次全面评估全球 TOP 云厂商的整体安全能力。阿里云作为亚洲唯一入围厂商，其整体安全能力拿下全球第二，11 项安全能力被评估为最高水平（High）。目前，阿里云沉淀了最丰富的云原生产品家族、最全面的云原生开源贡献、最大的容器集群和客户群体以及广泛的云原生应用实践。

NO.2：阿里云函数计算以满分成绩通过可信云认证 21 项测试

在今天公布的函数即服务认证中，阿里云函数计算通过了基础能力要求、平台可观测能力、服务性能、服务安全和服务计量准确性等 21 项测试，最终以满分成绩通过可信云函数即服务能力认证。

今年 3 月，独立的全球咨询与服务机构 Forrester 发布《The Forrester New WaveTM: Function-As-A-Service Platforms, Q1 2020》报告，阿里云凭借函数计算被 Forrester 官方给予「强劲表现者」评价。

早在 2019 年，阿里云就推出函数计算 2.0，通过一系列创新的功能，解决了 Serverless 计算服务的痛点。在函数计算出现之前，客户要通过很多胶水代码完成多个云产品间的集成，还要仔细处理各种错误情况。当函数计算和阿里云对象存储集成后，对象存储中产生的上传 / 删除对象等事件能够自动、可靠地触发函数处理，而且每个环节都是弹性高可用的，用户能够快速实现大规模数据的实时并行处理。同样的，通过消息中间件和函数计算的集成，客户可以快速实现大规模消息的实时处理。在未来，无论是一方云服务，还是三方应用，所有事件都可被函数计算等服务可靠地处理。

更重要的是，函数计算 2.0 新增预留实例类型，允许用户自行管理实例的申请和释放。通过预留实例，用户能够提前预热函数或者长期保持常驻实例，杜绝因为实例启动带来的请求延迟。当负载超过预留实例处理能力，系统会自动扩容，使用按量实例处理请求。同时函数计算提供了详细的实例使用指标，帮助用户轻松预留合理数目的实例。函数计算 2.0 大幅增强了 Serverless 应用构建、运维等方面的用户体验。

阿里云函数计算有丰富的应用场景。以新浪微博为例，明星事件、红包飞等业务经常会遇到高达几倍的瞬间峰值。同时，微博也具有明显的流量潮汐效应，峰谷值相差 5 倍以上。微博采用阿里云函数计算，根据请求量动态分配执行环境，毫秒级调度计算资源，确保在负载高时保持稳定的延时，在负载低时有着较高的资源利用率，且只会对代码运行时使用的计算资源付费。更棒的是函数计算与对象存储服务无缝集成，可以方便地对存储在对象存储中的图片进行实时处理。

在这次疫情中，函数计算更是应用在数字抗疫中，助力 20 万+ 企业远程复工。未来，阿里云会进一步加速推动基础设施和服务 Serverless 化，Serverless 会站在云计算的浪潮之巅，引领新一轮的技术升级。

NO.3：阿里云获得可信云分布式消息队列服务增强级认证

在信通院公布的分布式消息队列服务认证评选中，阿里云获得可信云分布式消息队列服务增强级认证。

消息队列是分布式互联网架构中必不可少的基础设施，广泛应用于应用解耦、异步通知、削峰填谷等领域。消息队列 RocketMQ 是阿里云基于 Apache RocketMQ 构建的低延迟、高并发、高可用、高可靠的分布式消息中间件。该产品服务于阿里集团十多年，覆盖全集团所有业务。作为 双11 交易核心链路的官方指定产品，支撑千万级并发、万亿级数据洪峰，历年刷新全球最大的交易消息流转记录。

阿里云消息队列服务一直都处于业内领先地位，并获得了国内外多项大奖：

2016 年度最受欢迎中国开源软件奖
2017 年度最受欢迎中国开源软件奖
第16届中日韩三国IT局长OSS会议暨东北亚开源软件推进论坛开源软件优秀技术奖
2018 年度最受欢迎中国开源软件奖
2019 年度最受欢迎中国开源软件奖

2019 年，在第十八届中日韩三国 IT 局长 OSS 会议暨东北亚开源软件推进论坛上，阿里巴巴 Linux OpenMessaging 项目获得 2019 东北亚优秀开源项目。OpenMessaging 项目由阿里巴巴发起，与雅虎、滴滴出行、Streamlio 公司共同参与创立，作为分布式系统消息服务规范标准，OpenMessaging 的愿景是成为全球化、无国界、无公司边界，面向云和大数据，多行业领域的一站式方案标准。

今年，在线教育业务增长迅猛，企业对于消息服务也提出了更高的要求。以编程猫为例，随着业务的迅猛增长，编程猫亟需一个消息种类丰富，接入简单，稳定高效的消息中间件。阿里云提供的 RocketMQ 在消息种类，接入简易，稳定高效方面完全符合编程猫的场景诉求。

通过使用阿里云提供的消息队列 RocketMQ 作为系统的消息总线，编程猫实现了系统的解耦、削峰填谷、分布式事务、数据复制与广播等功能。依赖于有保障的 SLA（99.99999999% 数据可靠性，99.95% 服务可用性），就像是站在巨人的肩膀上构建系统。另外消息控制台还提供了消息查询、消息轨迹等实时监控功能，并且可以设定各种资源的报警规则 , 用于快速定位问题，提升诊断效率，指导优化系统。

正如编程猫 CTO 所言：“RocketMQ 是我们中国软件界的骄傲，其开源版本成为 Apache 的顶级项目而被广泛使用，而作为商业版也历经 双11 这样的大考，并能以云产品的形式向广大客户提供更优质的专业服务。简单易用够用，必须支持！”

NO.4：阿里云开放应用模型（OAM）荣获可信云技术最佳实践-云原生类（容器及管理）

在可信云技术最佳实践（容器及管理）评选中，阿里云 OAM 以领先的优势通过可信云技术最佳实践认证，掀起下一代云原生 DevOps 的技术革命。

OAM 是阿里巴巴联合微软在社区推出的一款用于构建和交付云原生应用的标准规范，旨在通过全新的应用定义、运维、分发与交付模型，推动应用管理技术向“轻运维”的方向迈进。2020 年 5 月，OAM 项目同 Crossplane 项目进行了深度整合，更是把能力扩张到了标准化的定义云服务的范畴当中。目前，OAM 正在迅速成为云原生生态进行标准化应用定义和构建现代应用管理平台的事实标准。

其实在 OAM 发布之前，云原生生态里其实并没有一个叫做 “应用” 的概念。社区里各种各样 “应用” 的概念抽象程度层次不齐，定义方式也丰富多样，这就导致了所有围绕着这些 “应用” 构建出来的系统，就成为了一个又一个的大烟囱，呈现出碎片化和烟囱化的现状。此外，Kubernetes 作为一个面向基础设施工程师的系统级项目，主要负责提供松耦合的基础设施语义，这就使得用户学习和操作 Kubernetes YAML 文件的时候，往往会感觉这些文件里的关注点非常底层，学习门槛很高。

而 OAM 其实就是一个真正面向最终用户侧的应用定义，能够为业务研发和应用运维人员提供各自视角的应用定义原语，解决了 Kubernetes 真正的最终用户，比如业务研发人员和运维人员希望有更高维度的抽象，而不是陷在配置底层的资源信息中。OAM 加持下的 Kubernetes 应用管理平台，可以像乐高积木一样灵活组装底层能力、运维特征、以及开发组件，使得应用管理变得统一，功能却更加强大。

NO.5：阿里云获得可信云服务最佳实践（服务云）

在可信云服务最佳实践评选中，阿里云提供技术支持的完美日记和特步荣获可信云服务行业云最佳实践（服务云），树立云原生技术落地实践的标杆案例！

案例 1：阿里云神龙裸金属+容器 ACK 助力完美日记应对大促

对于电商企业而言，大促期间流量瞬间上涨，系统经常发生故障， IT 资源利用率较低，成本也高。完美日记通过阿里云提供的以神龙裸金属+容器服务 ACK 为基础的云原生微服务体系架构，同时结合阿里云的中间件及应用产品如 ARMS、AHAS、日志服务等产品，采用基于 Spring Cloud 的微服务架构，并做了优化改造。

完美日记为什么要选择阿里云原生提供的技术和产品？

作为国内最早举办线上大规模营销活动的公司，阿里在应对电商高并发、大规模用户访问等方面积累了丰富的经验：

• 大规模高稳定的容器服务：阿里运行着中国最大的在线交易系统，并且通过容器的方式来进行云上 IT 资源的编排和调度。阿里云容器服务帮助客户在秒级进行资源扩容，从几百节点到几千甚至上万节点，应对突增的用户访问；
• 完善的容量评估工具：利用阿里云 PTS，可以模拟真实地理位置的用户访问，并可以模拟出大促常见的流量洪峰和瞬时毛刺，真实还原大促时的系统负载，帮助客户评估当前系统的瓶颈点和容量水位；
• 完善的监控工具：利用阿里云 ARMS，可以帮助客户在复杂的 IT 环境中定位出系统异常点，直接定位到代码行级，快速发现问题；
• 可靠的稳定性保障工具：阿里云 AHAS 可以帮助客户进行多种维度的系统稳定性保障，包括服务限流、依赖降级、系统防护、故障隔离等功能，充分保障客户云上系统的稳定性；
• 成熟的服务支持体系：阿里云 GTS 专家团队可以为客户提供云上护航保障服务，从护航前、护航中到护航后，有完整的服务 SOW 和标准流程，并已经成功支持多个客户举办大型营销活动，具有丰富的经验。

使用阿里云 ACK 容器服务，帮助完美日记快速拉起测试环境，利用 PTS 即时高并发流量压测确认系统水位，结合 ARMS 监控，诊断压测过程中的性能瓶颈，最后通过 AHAS 对突发流量和意外场景进行实时限流降级，保证了完美日记每一次大促活动的系统稳定性和可用性，同时利用 ACK 容器快速弹性扩缩容，节约服务器成本 50% 以上。

案例 2：特步定制基于云原生架构的全渠道中台解决方案实现数字化转型

特步集团从 2017 年 1 月开始探索互联网+数字化转型，从传统的 IOE 架构升级到云原生分布式架构，并且信息化团队从早期的以支撑业务为导向，转型为以技术能力推动赋能业务创新。特步全渠道分销零售系统平台采用阿里中台架构进行建设，正好满足特步混合业务架构的模式。采用中台架构设计能真正的灵活快速响应业务变化，让特步从烟囱式建设方式中解脱出来，同时也能把阿里共享服务的建设理念融入全渠道分销零售系统平台的项目中。

特步为什么选择基于阿里云原生架构建设中台？

阿里是最早提出中台概念，并成功实施落地的公司，阿里中台所配套的中间件是经过阿里多年 双11 打磨的成熟产品。阿里内部几百个业务应用，共享一个技术中台底座，服务新的业务场景，带来更好的用户业务体验。同时，阿里云通过为上百个外部客户实施业务中台，培养了一大批具备中台实施交付能力的行业 ISV，同时沉淀了大量行业最佳实践。

阿里云提供一整套“业务中台技术解决方案”，将企业核心能力下沉共享，加速企业创新速度；规范 IT 全生命周期管理，提升研发效率与质量；提供行业最佳实践，助力企业快速落地中台战略。基于云原生架构，可以支持弹性调度、微服务化解耦，自动化运维；通过阿里中间件产品支持，历经多年 双11 考验，保证系统的高可靠。同时，阿里云支持按流量线性扩展，支撑海量用户。

作为云原生领域的先行者，阿里云持续赋能企业数字化转型

来源：阿里云 20+ 技术专家共同编撰《云原生架构白皮书》，目前已正式发布

阿里的核心优势之一就是全部的核心业务运行在云上，形成新技术最好的创新土壤，最先进的技术首先会在阿里自己的业务体系中进行尝试，得到了大规模的运用，证明其技术的普适性与价值后再开放给客户。

从 2011 年迈进容器大门算起，阿里的云原生之路已经走了十年。这期间经历了十年 双11 的历练，例如 2015 年全面容器化帮助 双11 大促实现快速弹性扩容。容器技术对于 双11 的显著影响还包括在具体的混部技术实施中，通过混部技术，阿里巴巴集团范围内能够节省 30% 左右的 IT 成本支出，在 双11 这个特殊时间段里，将每万笔交易成本下降超过 75%。

云原生架构与技术一定是开放的，需要全行业共同定义与建设。阿里巴巴作为云原生领域的先行者、实践者，基于自身累积多年的最佳实践，对社区赋能，为企业提供普惠的云原生产品服务，帮助更多用户享受云原生时代的技术红利。

“阿里巴巴云原生关注微服务、Serverless、容器、Service Mesh 等技术领域、聚焦云原生流行技术趋势、云原生大规模的落地实践，做最懂云原生开发者的公众号。”

https://v.qq.com/x/page/a312354ftqa.html

这是关于PX-Backup的一个Demo。在左侧，有PX-Backup和两个集群。我们使用上面那个集群，运行的是1.17.8版本的K8S。在右侧有一个终端，也是访问的那个集群，我们可以看到集群运行的是1.17.8版本的K8S。

 

我们要介绍如何对MySQL进行备份，以及前置和后置规则。这部分是设置命名空间的，里面有一个MySQLns1的命名空间，它里面运行的是MySQL的数据库，也可以看到与数据库关联的PVC和PV。我们可以通过终端登录到MySQL，存在一个数据库表，我们可以用来检测我们的备份操作的过程是否正确。

 

我们有一个叫做“家”的数据库，里有一个叫做“宠物”的表，在这个表里只有一行数据，描述了一只狗。我们会对这个数据库进行备份操作，我们的第一步是填写这个界面的信息，我们要介绍一下备份的前置和后置规则。我们可以在备份规则的界面管理这些规则，有两个规则是针对MySQL应用的，如果我们点击进去，通过选择器选择MySQL，MySQL在我的右侧，有个标签，前置规则是通过readlock来flush数据库表，它会确保数据库表是锁定状态，没有新的IO来改变数据库表，Flush数据到磁盘，后置规则是flush日志，并且解锁数据库表。使得数据库可以重新正常使用。

 

我们回到这个命名空间，用这些规则配置我们的备份。我们会选择MySQLns1命名空间，选择备份，给备份起一个名字，选择备份的位置，我们这里选S3，选择是否要按时间计划来备份，或者是现在备份，我们选现在。选择前置和后置规则，完成后，可选的部分是标签，一旦创建完成，就会显示进展和状态，一开始是Pending，一旦备份开始，状态就是In Progress，你可以查看细节信息，你可以看到前置规则正在执行。即通过Read Lock，flush数据库表，正在进行。接下来就会备份PV和其他资源，在细节信息里，我们可以看到，资源备份状态是In Progress，包括PV，PVCs, 数据，K8S对象等等，现在状态是“成功”，表示我们的备份成功了，后置规则开始运行了。

 

这样我们就有了一个可以用来恢复的备份，现在我们加入一些数据，来验证我们的备份是否正确，现在我们看到数据库表中有两条狗的记录，我们继续，点击“恢复”，在备份这个菜单的旁边，填写恢复界面的相关信息，首先是恢复的名称，恢复到哪一个集群，可以恢复到原来的集群，也可以恢复到一个新的集群，在这里，我们就恢复到原来的集群，但是一个新的命名空间，我们选择定制化恢复，会从原来的命名空间，备份到一个新的“测试”命名空间。这个“测试”命名空间我们可以用来做一些测试，我们选择覆盖已经存在在那个命名空间的资源，现在我们的恢复已经完成了，我们登录到新的Pod里，MySQLns1“测试”命名空间，我们选择数据库和数据库表，我们可以看到数据库表只有一条记录，表示我们的恢复是正确的。前置和后置规则，确保了备份过程中应用的一致性。

近日，KubeSphere 社区子项目面向物理机环境的负载均衡器 Porter 正式进入 CNCF Landscape。CNCF Landscape 在云原生实践过程中的每个环节帮助用户了解有哪些具体的软件和产品选择，Porter 进入 CNCF Landscape，意味着 Porter 正式成为了 CNCF 认可的构建云原生最佳实践中的一环。

云原生计算基金会（CNCF, Cloud Native Computing Foundation）致力于云原生技术的普及和可持续发展。在每年的 CNCF 年度报告中都会提及 CNCF Landscape，CNCF Landscape 是 CNCF 中的一个重要项目，帮助企业和开发人员快速了解云原生体系的全貌，同时，也受到广大开发者和使用者对该项目的关注和重视。CNCF Landscape 意图从云原生的层次结构，以及不同的功能组成上，让用户了解云原生体系的全貌，并帮助用户在不同组件层次去选择恰当的软件和工具进行支持。

新晋 CNCF Landscape 的 Porter，解决什么问题？

在 Kubernetes 集群中可以使用 “LoadBalancer” 类型的服务将后端工作负载暴露在外部。云厂商通常为 Kubernetes 提供云上的 LoadBalancer 插件，但这需要将集群部署在特定 IaaS 平台上。然而，许多企业用户通常都将 Kubernetes 集群部署在物理机上，尤其是用于生产环境或数据敏感的环境。而且对于本地物理机集群，Kubernetes 不提供 LoadBalancer 的解决方案。Porter 是 KubeSphere 社区开源的专为物理机 Kubernetes 集群暴露服务而设计的开源的负载均衡器，为用户提供在物理环境暴露服务和在云上暴露服务一致性体验的插件。

Porter 主要特性

面向物理机环境的 Kubernetes 开源负载均衡器 Porter 主要特性有：

• 基于路由器 ECMP 的负载均衡
• 基于 Layer 2 的负载均衡
• 基于 BGP 路由动态配置
• 支持 VIP 管理
• 支持在 Kubernetes Service 中指定 LoadBalancerIP （v0.3.0）
• 支持通过 Helm Chart 安装（v0.3.0）
• 支持通过 CRD 动态配置 BGP 服务端（v0.3.0）
• 支持通过 CRD 动态配置 BGP 对等体（v0.3.0）

与 MetalLB 的区别

优点

• 对 Kubernetes 用户友好。基于 CRD-Controller 模式，使用 kubectl 控制 Porter 的一切
• 配置文件动态更新，无需重启，自动更新 BGP 配置。根据网络环境灵活配置 BGP，动态启用各种 BGP 特性
• 更友好地处理与 Calico 的冲突，提供 Passive 模式和端口转发模式

缺点

• 无法跨平台，目前仅支持 Linux

Kubernetes 服务

在 Kubernetes 集群中，网络是非常重要的基础设施。对于大规模的节点和容器来说，要保证网络的连通性、网络转发的高效，同时能做的 IP 和 Port 自动化分配和管理，并提供给用户非常直观和简单的方式来访问需要的应用，这是非常复杂且细致的设计。

Kubernetes 本身在这方面下了很大的功夫，它通过 CNI、Service、DNS、Ingress 等一系列概念，解决了服务发现、负载均衡的问题，也大大简化了用户的使用和配置。其中的 Service 是 Kubernetes 微服务的基础，Kubernetes 是通过 kube-proxy 这个组件来实现服务的。kube-proxy 运行在每个节点上，监听 API Server 中服务对象的变化，通过管理 iptables 来实现网络的转发。用户可以创建多种形式的 Service，比如基于 Label Selector 、Headless 或者 ExternalName 的 Service，kube-proxy 会为 Service 创建一个虚拟的 IP（即 Cluster IP），用于集群内部访问服务。

暴露服务的三种方式

如果需要从集群外部访问服务，即将服务暴露给用户使用，Kubernetes Service 本身提供了两种方式，一种是 NodePort，另外一种是 LoadBalancer。另外 Ingress 也是一种常用的暴露服务的方式。

NodePort

如果将服务的类型设置为 NodePort，kube-proxy 就会为这个服务申请一个 30000 以上的端口号（默认情况下），然后在集群所有主机上配置 IPtables 规则，这样用户就能通过集群中的任意节点加上这个分配的端口号访问服务了，如下图

NodePort 是最方便的暴露服务的方式，缺点也很明显：

• 基于 SNAT 进行访问，Pod 无法看到真正的 IP。
• NodePort 是将集群中的一个主机作为跳板访问后端服务，所有的流量都会经过跳板机，很容易造成性能瓶颈和单点故障，难以用于生产环境。
• NodePort 端口号一般都是用大端口，不容易记忆。

NodePort 设计之初就不是用于生产环境暴露服务的方式，所以默认端口都是一些大端口。

LoadBalancer

LoadBalancer 是 Kubernetes 提倡的将服务暴露给外部的一种方式。但是这种方式需要借助于云厂商提供的负载均衡器才能实现，这也要求了 Kubernetes 集群必须在云厂商上部署。在物理机部署的 Kubernetes 环境则需要 Porter 来解决服务暴露的问题。

LoadBalancer 的原理如下：

LoadBalancer 通过云厂商的 LB 插件实现，LB 插件基于 Kubernetes.io/cloud-provider 这个包实现，这个包会自动选择合适的后端暴露给 LB 插件，然后 LB 插件由此创建对应的负载均衡器，网络流量在云服务端就会被分流，就能够避免 NodePort 方式的单点故障和性能瓶颈。LoadBalancer 是 Kubernetes 设计的对外暴露服务的推荐方式，但是这种方式仅仅限于云厂商提供的 Kubernetes 服务上，对于物理部署或者非云环境下部署的 Kubernetes 集群，这一机制就存在局限性而无法使用。

Ingress

Ingress 并不是 Kubernetes 服务本身提供的暴露方式，而是借助于软件实现的同时暴露多个服务的一种类似路由器的插件。Ingress 通过域名来区分不同服务，并且通过 annotation 的方式控制服务对外暴露的方式。其原理如下图：

快速部署和体验 Porter

完全开源

Porter 的所有代码和文档已在 Github 开源，欢迎大家关注 (Star) 和贡献：https://github.com/kubesphere/porter

快速部署

Porter 目前已在如下三种环境下进行过部署和测试，并将部署测试与使用步骤的详细文档记录在 GitHub，可以通过以下链接查看和部署实践：

• 使用 Helm Chart 在 Kubernetes 部署 Porter：https://github.com/kubesphere/porter/blob/master/doc/zh/porter-chart.md
• 在物理机部署的 Kubernetes 部署 Porter：https://github.com/kubesphere/porter/blob/master/doc/zh/deploy_baremetal.md
• 在云平台用模拟路由器的方式测试：https://github.com/kubesphere/porter/blob/master/doc/zh/simulate_with_bird.md

最新动态

Porter 将在本月中旬发布新版本 v0.3.0，新版本由青云QingCloud、本来生活和北京吉恒科技三家公司联合开发，由社区定义与贡献，非常感谢非青云的社区贡献者 @k0ngk0ng 和 @chinazj。新版本的主要功能已在文中 Porter 介绍中标注，欢迎大家安装体验！

延伸阅读

• Porter-面向物理机环境的 Kubernetes 开源负载均衡器：https://kubesphere.com.cn/conferences/porter/
• Porter 如何帮助本来生活在 K8s 物理环境暴露集群服务：https://mp.weixin.qq.com/s/Us6DZbf_GhRT69-dL1GD4g
• Porter 官网：https://porterlb.io/

关于 KubeSphere

KubeSphere 是在 Kubernetes 之上构建的以应用为中心的开源容器平台，提供全栈的 IT 自动化运维的能力，简化企业的 DevOps 工作流。

KubeSphere 已被 Aqara 智能家居、本来生活、中国人保寿险、新浪、北京银行、华夏银行、浦发硅谷银行、四川航空、国药集团、微众银行、VNG Corporation、Radore 等海内外数千家企业采用。KubeSphere 提供了运维友好的向导式操作界面和丰富的企业级功能，包括 Kubernetes 资源管理、DevOps (CI/CD)、应用生命周期管理、微服务治理 (Service Mesh)、多租户管理、监控日志、告警通知、存储与网络管理、GPU support 等功能，帮助企业快速构建一个强大和功能丰富的容器云平台。

KubeSphere 官网：https://kubesphere.io/ KubeSphere GitHub：https://github.com/kubesphere/kubesphere

欢迎关注我们的微信公众号：

如何在K8S上备份和恢复MySQL

越来越多的生产系统和关键应用运行在K8S上。在生产系统运行有状态应用，并不是一件容易的事情，它需要我们仔细的计划并部署。我们之前有一篇文章专门介绍如何在K8S上运行高可用的MySQL。这次我们来介绍下如何备份和恢复MySQL。当我们在生产环境中备份和恢复MySQL，我们需要思考下面的问题：

• 我们需要备份哪些K8S对象？
• 我如何备份我的持久卷（PVs）？
• 我的备份文件存储在哪里？
• 我的备份需要保持多久的可用性？
• 我能否恢复我的备份到另外一个K8S集群？
• 谁有访问这些备份的权限？
• 谁有权限实施备份？
• 我们能否按照预定的时间计划自动进行备份？
• 备份需要多长时间？
• 我的备份是安全的吗？

下面的介绍会逐一回答上面的问题，以及介绍如何在K8S生产环境备份和恢复MySQL。

在K8S上备份MySQL的必要步骤

在我们制定备份和恢复计划的时候，很重要的一点是不是所有的数据都需要同等级别的保护。在生产环境中，我们需要满足我们的商业需求和客户需要的最合适的保护级别。下面我们来了解一下在生产环境中创建备份和恢复的一些必要的步骤。1.   了解谁负责来创建备份2.   所需RPO（恢复点目标）的级别

3.   确保清晰的知道备份到哪个位置

4.   备份的时间计划以及备份的留存时间计划

5.   确保与应用关联的数据也被正确备份了，从而确保应用的一致性

我们来详细过一遍备份MySQL的关键步骤，包括一些代码样例和截图。

对MySQL进行备份和恢复

在我们备份MySQL之前，我们必须首先正确配置PX-Backup，使它可以访问集群。>本篇文章并没有覆盖如何安装PX-Backup，可以参考以前的系列文章，有一篇专门讲解如何安装PX-Backup。在PX-Backup界面里，选择“Add Cluster”

接下来需要提供一个集群名称，以及为集群提供一个Kubeconfig (https://kubernetes.io/docs/concepts/configuration/organize-cluster-access-kubeconfig/)，以及Portworx的一些信息。注意Kubeconfig控制了对集群进行访问的权限类型，对PX-Backup也是这样。如果我们仅仅对一个命名空间有访问权限，我们就只能为这一个命名空间进行备份和恢复。如果你没有Portworx集群信息，或者并没有为卷来使用Portwrox，这部分可以先留空。

这步完成后，就可以看到集群已经被添加到主界面了，在集群那里就会出现一个绿色的备份图标，点击就可以进入备份界面。

如果你的备份图标不是绿色的，看一下集群里运行的是不是Stork 2.4+的版本（https://docs.portworx.com/portworx-install-with-kubernetes/storage-operations/stork/#install）>参考备份界面里面Add Cluster的界面，可以复制下面的命令来为集群增加stork。

(正在运行 Portworx)

KBVER=$(kubectl version --short | awk -Fv '/Server Version: /{print $3}')

curl -fsL -o stork-spec.yaml "https://install.portworx.com/2.5?kbver=${KBVER}&comp=stork"

kubectl apply -f stork-spec.yaml

(没有运行 Portworx)

curl -fsL -o stork-spec.yaml "https://install.portworx.com/2.5?comp=stork&storkNonPx=true"

kubectl apply -f stork-spec.yaml

配置你的备份目标位置

在备份MySQL之前，我们必须创建一个备份目标位置，点击Cloud Settings，继续输入备份目标位置的身份信息等。

关于不同的备份目标位置，这里有详细的文档（https://backup.docs.portworx.com/use-px-backup/credentials/）。一般来说，至少需要创建一个云账户（如AWS，Azure，Google），以及创建一个备份位置（如云对象存储的位置）。

当你创建了一个备份位置，你可以选择之前创建的云账户，输入相关的信息。

创建一个备份的时间计划

这步是可选的。

我们需要创建一个备份时间计划，来明确备份的频率（以达到RPO的目标），以及保存多少个备份。（注意：如果需要RPO为零，则需要使用PX-DR）。点击设定菜单的Schedule Policies，会出现一个界面来帮助你配置备份的时间计划。

点击浏览栏的Add按钮，

在这个界面，创建你需要的备份时间计划。你可以选择定期、每天、每周、或者每月，然后选择需要保存多少个备份。在后续对MySQL进行备份的过程中，就可以选择这个备份时间计划。

创建应用一致的MySQL备份的前置和后置规则

当系统验证发现数据已经准备好可以备份了，就可以开始备份了。这就是我们说的应用感知。为了保持应用的一致性，我们希望在备份前和备份后进行一定的控制。通过PX-Backup，我们可以配置前置和后置规则（https://backup.docs.portworx.com/use-px-backup/rules/），这些规则会通过在一个或多个Pods里运行命令来达到我们的目标。首先，我们需要理解MySQL是如何存储状态的。这会对我们的备份方式和规则有很大的帮助。MySQL服务器管理的信息，都保存在data directory里，(https://dev.mysql.com/doc/refman/8.0/en/data-directory.html)

这个data directory位于MySQL服务器的文件系统的/var/lib/mysql 目录里。在这个目录里存储的文件和数据对于MySQL维持数据一致性非常重要。因此，我们mount K8S持久卷声明（PVCs），到MySQL镜像的data directory也非常重要。在K8S里，volumeMount的配置文件差不多是下面的样子：

        volumeMounts:
        - name: mysql-data
          mountPath: /var/lib/mysql
      volumes:
      - name: mysql-data
        persistentVolumeClaim:
          claimName: mysql-data

在data directory内，MySQL存储与系统、性能和客户数据有关的：数据结构，表，日志文件、配置、以及数据库数据。Mount持久卷，使得PX-Backup可以在需要的时候对MySQL的数据进行快照和备份。

MySQL有一个叫做mysqldump的工具，可以专门用来对MySQL做备份。由于PX-Backup可以为多种数据类型提供数据备份和恢复的抽象，我们可以复制mysqldump的最佳工作方式（https://dev.mysql.com/doc/refman/5.7/en/mysqldump.html#option_mysqldump_add-locks）。例如flush和锁定日志和数据库表，并保存到PX-Backup的前置和后置规则里。PX-Backup的规则和备份可以跨多个MySQL实例和跨云来使用，这对于DevOps团队管理云环境和多云环境很有帮助。

MySQL的前置规则

在备份MySQL的时候，推荐方式是把一些特定数据flush到磁盘里，这样可以确保备份的一致性。如数据库表和日志，就应该被flush。对MySQL而言，另外很重要的一点是锁定数据库表，这样在备份期间，没有新的I/O请求来增加数据库记录，否则MySQL就无法保持一致性。

为了达到这样的目标，我们可以在前置规则中部署FLUSH TABLES WITH READ LOCK命令，它会进行下面的操作：

(FLUSH TABLES WITHREAD LOCK)- 关闭所有打开的数据库表，通过全局化的读锁定，来锁定所有数据库的所有表。对于文件系统是可以及时进行快照的Veritas或者ZFS来说，这是一个非常便捷的备份方式。

可以使用UNLOCK TABLES来解除锁定。

由于PX-Backup对K8S里的持久卷做快照，这会帮助我们完成我们的目标。

在PX-Backup的界面里，创建规则。

> 注意:我们设定规则在后台运行，这需要一个WAIT_CMD（https://docs.portworx.com/portworx-install-with-kubernetes/storage-operations/create-snapshots/snaps-3d/#step-1-create-rules），来使得规则可以正确的执行和退出。

MySQL的后置规则

由于我们在备份之前，Flush并锁定了MySQL的数据。那么在备份完成后，我们必须从全局化的读锁定中，解除对数据库的锁定。根据MySQL的技术文档，这是因为在FLUSH TABLES WITHREAD LOCK操作后，全局化的锁定并不会自动解锁。FLUSH LOGS（https://dev.mysql.com/doc/refman/8.0/en/flush.html#flush-logs）也是一个好的操作，它关闭并重新打开服务器正在执行写入操作的所有日志文件，并且更新日志的序列数字。如果用户需要在备份前后保持一个清晰的日志的区别，这个操作就很重要。Flushing Logs在我们现在的步骤中并不是必须的，但我们把它加入到后置规则中，以保持操作的完整。

在PX-Backup界面中创建规则。

> 注意: 备份的后置规则不允许在后台运行，所以我们需要WAIT_CMD（https://docs.portworx.com/portworx-install-with-kubernetes/storage-operations/create-snapshots/snaps-3d/#step-1-create-rules）

为MySQL创建一个备份

现在我们已经完成了配置，我们也已经为应用创建了规则。我们可以开始备份我们的MySQL了。我们需要进入应用所在集群的备份界面，选择我们的应用正在运行所在的命名空间。

在命名空间内，我们可以选择MySQL相关的标签，可以仅备份具备标签的特定的对象。或者在命名空间备份界面中，通过点击右上角的Backup按钮备份整个命名空间。

如果你需要备份特定的对象，在跳出的菜单栏中，输入下面的信息，

• 名称
• 备份位置
• 选择现在备份，还是有一个备份的时间计划
• 提供前置和后置规则
• 可选的备份标签

信息输入完成后，点击创建，一旦创建完成，备份会进入Pending状态，然后进入In Progress状态。这时的备份图标是下面的样子。

如果需要了解备份过程的进展，可以选择菜单栏里面的Show Details按钮，这会允许你查看当前的状态，以及与备份有关的元数据。所有的进展和错误信息都会在这个界面显示出来。

我们之前创建的前置和后置规则的一些状态信息也会显示出来。当这些规则在执行的时候，会显示为进行中。如果有任何的错误，也会在这个界面显示出来。

当规则执行完成，它会继续备份卷，信息细节也会变化，下面是一些信息的例子：

一旦备份成功完成，图标就会显示成下面的样子。

如果中间有任何错误，图标就会变成下面的红色的样子，在Show Details栏位，会显示错误的信息。

从备份中恢复MySQL

开始恢复，选择菜单栏里的Backups，找到你需要恢复的备份，选择菜单栏里的Restore。

在下面的界面中，你可以提供恢复的名称，恢复到的目标集群，以及其它一些选项，包括：

• • 默认恢复

会恢复备份到这个备份原本来自的命名空间。注意是否需要覆盖现有资源这个选项。

• • 定制化恢复

会允许我们提供一个新的命名空间，来恢复备份。注意这个新的命名空间不需要在此之前就已经创建好。

• • 覆盖现有资源

恢复的过程会覆盖现有的对象。实际操作中这些对象会被删除并重新创建。

• • 恢复Jobs

Jobs通常运行一次就会完成。通常不需要反复运行这些Jobs – 特别是当我们把备份恢复到该备份原本来自的同一集群的情况下。但当我们恢复到一个新的集群或者新的命名空间的时候，就需要再次运行Jobs了。

你会在界面中看到状态从Pending变成了Success，你可以选择菜单里的Show Details，来获得备份相关的信息。

结论

对于K8S上的应用来说，备份和恢复是非常重要的。PX-Backup使得备份和恢复的过程变得非常简单。并且有效地保证了数据的一致性。可以访问Portworx网站获取更详细的文档，或者申请试用。（https://portworx.com/products/px-backup/）

第一讲：DevSecOps——大型金融企业如何落地开源治理

 

主题简介：

在持续交付速度越来越快的时代，金融企业面临着严格的安全监管，如何能够在满足快速发布需求的同时，又兼顾安全、合规性的要求？如何通过自动化的流程，将开源治理和研发、持续交付流程有机地结合在一起？JFrog将为您介绍国内的大型金融企业如何高效地落地DevSecOps最佳实践。

演讲大纲：

1、落地开源治理的痛点

2、DevSecOps的理念

3、落地DevSecOps的最佳实践

演讲收益：

1、了解落地开源治理需要解决的问题

2、了解DevSecOps的概念

3、了解落地DevSecOps的最佳实践，及相关规范

 

第二讲：DevOps实施路径之团队建设和工具链

 

主题简介：

DevOps在国内的迅猛发展，尤其是国家政策支持，企业都在做数字转型。DevOps成了企业的第一选择。我们通过分享来了解下企业在落地DevOps面临的现实问题。如打造一个合格的DevOps团队，如何选择DevOps工具。

演讲大纲：

1、企业落地DevOps面临的现实问题

2、选择一个合格的执行团队管理者

3、打造一个合格的DevOps团队

4、选择合适的DevOps工具

5、博云Paas体系介绍

听众收益：

1、了解DevOps落地需要解决的问题

2、如何建设一个合格DevOps团队

3、了解DevOps工具链

 

报名请点击：https://www.bagevent.com/event/6698088

Portworx: 如何安装PX-Backup

首先，打开PX-Central, 点击Install and Run，点击 New Spec，在下面的PX-Backup，点击Next，输入组织名称，集群名称-即Portworx集群的名称，Admin的Email，Admin的用户名，以及Admin的密码，点击Next, 设置一些环境信息，例如是否是本地部署环境，是否运行在OpenShift上，以及是否需要设置中央端点，这里我们设置成“自动生成”，我们在本地环境不作其他特殊的设置，接下来，指定PX-Central运行的命名空间，在这个命名空间里，会部署你的备份，输入KubeConfigPath，并配置密码，设置你是否需要在PX-Central对集群进行监控，以及是否是Air-Gapped，如果KubeConfig Path不是标准的，请更新一下，点击Next，你会得到一个定制化的命令行脚本，你可以在Kubernetes的环境里运行这个脚本。

 

它就会安装和部署备份，密码这些，连接到集群，这样就可以使用PX-Backup，不同环境下，这个步骤可能会花一点时间，完成后，就会出现一些授权的访问信息，从而通过PX-Central的界面可以访问，复制端点的信息到浏览器，就会打开PX-Central，使用之前配置的管理员用户名和密码，点击登录，进入之后可以点击“增加集群”，来备份Kubernetes环境。

 

 

导语

    Calico是一个纯三层的方案，为虚拟机及容器提供多主机间通信。Calico的网络传输性能主要受底层网络、路由表、IPIP模块的影响。那么IP地址分配的性能有哪些问题要考虑呢？

在大规模集群的场景下，Calico IP地址的分配速率是否受到集群规模的限制?IP地址和Block size怎么配置才能保持高速的IP地址分配?另外，Calico的IP地址在Node节点异常时，IP地址如何回收?什么时候有可能产生IP地址冲突？为了解答这些疑问，需要熟悉CalicoIP地址分配的执行流程。

本文主要针对calico v3.12版本，datastore为k8s的代码进行分析。

主要对象简介

BlockAffinity: 

Ø 存储block和Node的亲和关系

Block: 

Ø 维护已分配的IP地址和未分配的IP地址，Allocation数组，Uanllocated数组

Ø 维护block中运行的Pod

IPAMHandle:

Ø 保存pod与block的对应关系，在释放IP的过程中用于查找block

Ø HandleID由网络名和容器ID组合而成

IP Pool：

Ø 包括cidr内的所有IP

Ø 根据blocksize被划分为多个block

Ø 通过nodeSelector选择亲和的节点

Calico-IPAM流程图

分配IP

分配指定IP

自动分配IP

释放IP

源码分析

分配IP（cmdAdd）

在创建pod时，CNI插件会调用IPAM的cmdAdd函数进行IP地址的分配。CNI将配置文件从标准输入发送给IPAM，IPAM从中读取相关的配置信息，根据是否指定了IP地址，IPAM会采用两种不同的IP分配方式：

l 分配指定IP：pod配置中指定了需要使用的IP地址，接下来会调用AssignIP函数，尝试将指定的IP地址分配给pod。

自动分配IP：pod配置中没有指定IP地址，则尝试读取配置中的IP池信息，List集群内所有的IP池对象，遍历匹配IP池的名称或CIDR。获取匹配的IP池（可能为空）后，调用AutoAssign函数进行IP分配。

分配指定IP（AssignIP）

首先根据参数内的IP地址，List集群内所有状态为enable的IP池对象，遍历查找包含请求的IP地址的IP池，然后根据IP池的blocksize计算出IP地址对应的block cidr。

例如10.10.0.17位于IP池10.10.0.0/24（blocksize=28）中，对应的block cidr为10.10.0.16/28。

接下来使用block cidr查询对应的block：

l 若查询结果为空，即block不存在，则调用getPendingAffinity函数（获取未决亲和）查询或创建block与当前节点的block affinity，然后创建此block并尝试声明此亲和性。声明成功后，从新创建的block中分配指定的IP。如果block已经被其他节点声明了亲和性（被其他节点抢先创建并声明了亲和性），或者block的数据正处于更新中，那么IPAM会自动进行重试（上限为100次）。

l 若查询到了对应的block，则尝试从block中分配指定的IP。

分配IP成功后，创建IP地址的handle id（网络名+容器名）留待释放IP时使用，最后更新block的数据，结束IP分配流程。

获取未决亲和关系（getPendingAffinity）

该函数使用传入的节点名和block cidr创建或获取pending block affinity。

l 如果创建成功，则直接返回创建的pending block affinity。

l 如果创建失败，则表明该block affinity已存在。通过api查询到该block affinity，将其状态修改为pending（处理中）后，更新它的状态，并返回修改后的pending block affinity。

声明亲和块（claimAffineBlock）

该函数使用传入的pending block affinity结构体尝试创建或获取对应的block。

首先使用pending block affinity中的cidr构建block对象，发送创建block的请求。

l 如果创建成功，则将pending block affinity的状态更新为confirmed（已确认），返回block。

l 如果创建失败，则表明该block已存在。通过api查询获得block对象，检验其是否与当前节点亲和。

n 如果亲和性匹配，则确认该pending block affinity，返回block。

n 如果亲和性不匹配，则需要删除该pending block affinity，并返回声明冲突错误。

从块中分配IP（block.assign）

该函数尝试从block中分配一个指定的IP地址。

首先会校验block与节点的亲和性，在设置了StrictAffinity参数后，block必须与节点亲和才能够进行IP分配，否则会报错（亲和不匹配或无亲和）。

之后将IP地址转为序数（block的allocations数组的下标）。

l 若此IP已被分配，则直接返回错误。

l 若此IP未分配，则将handle id等属性添加到allocations数组的对应下标处。

最后遍历unallocated列表，找到刚才分配的IP序数后，将其去除，使用列表的后续项进行补位。

自动分配IP（AutoAssign）

自动分配IP的流程相比分配指定IP的流程复杂许多，主要分为四部分流程，第一部分为回收工作，每次都会执行；而后续的三个部分则是顺序执行，一旦在某个部分中获取了足够数量的IP地址就会直接返回，忽略后面的部分流程。

1. 释放与当前节点亲和、未被IP池使用的空块；

2. 从当前节点的亲和块分配IP；

3. 创建新的亲和块分配IP（可通过配置开启或关闭此流程）；

4. 从所有可能的IP池中的任意块分配IP，忽略亲和性（可通过配置开启或关闭此流程）。

分配前准备

在这四部分流程之前，首先要确定使用的IP池、可用的亲和块和待释放的亲和块。

确定IP池（determinePools）

该函数使用list接口获取了所有开启状态的IP池，并使用cidr进行索引。

l 如果在配置文件中指定的IP池cidr无法查找到对应的IP池，就直接返回；否则将指定的IP池添加到requestedPools列表中，作为后续流程使用的IP池。

l 如果配置文件中没有指定IP池，那么所有状态为enable，且选择了当前节点的IP池将作为后续流程使用的IP池。

获取亲和块（getAffineBlocks）

该函数list了所有blockAffinity对象，遍历进行如下判断：

l 如果上一步返回的IP池列表为空，则将所有blockAffinity的cidr加入IP池内的亲和块cidr列表，用于后续分配IP；

l 如果上一步返回了非空的IP池列表，则遍历blockAffinity进行判断

n 如果blockAffinity的block cidr属于上一步确定的任意一个IP池，则将其加入IP池内的亲和块cidr列表，用于后续分配IP；

n 如果blockAffinity的block cidr不属于上一步确定的任意一个IP池，则将其加入IP池外的亲和块cidr列表，将在下一部分流程中被回收。

第一部分：释放空亲和块

这部分流程负责释放已经无人使用的blockAffinity。这些blockAffinity由getAffineBlocks确定，不属于当前使用的IP池，对每一个待释放的blockAffinity执行如下操作：

l 首先list所有的IP池，根据blockAffinity的cidr遍历查找它所属的IP池；

l 如果该IP池选择了当前节点，则不释放blockAffinity，否则调用releaseBlockAffinity函数进行释放。释放操作返回块声明冲突、块非空或是块不存在错误时，跳过当前块，处理下一块；出现其他错误时，会进行100次以内的重试。

释放亲和关系（releaseBlockAffinity）

该函数将释放给定的block与节点的blockAffinity。

l 首先使用block cidr和节点名查询blockAffinity，并使用block cidr获取block对象；

l 若block不与当前节点亲和，则删除此block与当前节点的blockAffinity，返回块声明冲突错误；

l 若block非空（有IP正在被使用），则返回block非空错误；

l 将blockAffinity的状态更新为等待删除，删除block后再删除blockAffinity。

第二部分：从现存亲和块分配IP

释放了空的亲和块后，IPAM会尝试使用获取的blockAffinity分配IP，如果遍历了所有的亲和块仍未分配足够的IP，则进入下一部分，否则直接返回。分配过程具体如下：

l 首先使用blockAffinity的cidr和节点名获取blockAffinity对象；

l 再通过blockAffinity获取对应的block；

l 尝试从block中分配指定数量的IP，assignFromExistingBlock函数主要调用了从块中自动分配IP函数，分配完成后会添加对应的handle。

从亲和关系获取块（getBlockFromAffinity）

该函数根据blockAffinity获取对应的block。

l 首先根据blockAffinity的cidr获取block；

n 如果block不存在，则将blockAffinity的状态更新为pending，然后调用claimAffineBlock函数创建此block并确认blockAffinity，直接返回；

l 如果block的affinity属性为空，或是与blockAffinity不匹配，则删除blockAffinity（已过期）；

l 如果blockAffinity的状态未确认，则更新block后确认blockAffinity。

从块中自动分配IP（block.autoAssign）

该函数与从块中分配IP类似，能随机分配指定数量的IP地址。

l 如果开启了strictAffinity或是affinityCheck选项，则需要检查block是否与当前节点亲和；

l 随后从block的unallocated数组中取出指定数量的序数（不一定有序）；

l 遍历ordinal数组，将handle ID等属性添加到allocation数组对应下标处；

第三部分：创建新的亲和块并分配IP

如果开启了AutoAllocateBlocks选项，则可以新建block进行分配，否则只能将已分配好的（数量不足的）IP直接返回。

l 首先在给定的IP池范围内，随机找到一个未声明的block cidr；

l 根据block cidr获取当前节点的pending affinity；（参见分配指定IP）

l 使用pending affinity获取block；（参见第二部分）

l 如果这两步都成功，则认为成功创建了block，可以从中分配IP。

第四部分：从任意块分配IP

如果第三部分流程执行完后仍未分配足够的IP地址，则需要进入第四部分。如果开启了StrictAffinity的选项，则直接返回已分配的IP，未开启则能尝试从其他不与节点亲和的块中分配IP。

主要流程与第三部分相似，在指定的IP池中随机获取block。但不论block是否已被声明，是否与节点亲和，都尝试从其中分配IP。

释放IP（cmdDel）

删除pod时，CNI调用IPAM的cmdDel函数来释放pod的IP。首先使用网络名和容器ID构建出handle id，这是分配IP时记录下来的句柄，通过它释放pod使用的IP地址。

根据句柄释放IP（releaseByHandle）

l 首先使用handle id查询对应的block cidr（在ReleaseByHandle函数中获得，随后调用releaseByHandle函数）；

l 通过block cidr查找block；

n 如果block不存在，则认为IP已被释放，直接返回；

l 根据handle id从block中释放指定的IP；

n 释放完成后如果block为空且不存在blockAffinity，则直接删除block；

n 否则更新block内容；

l 移除对应的handle；

l 确保block的亲和性与IP池一致。

从块中根据句柄释IP（block.releaseByHandle）

该函数主要操作block对象的allocation和unallocated数组，将handle指定的IP释放。

l 首先根据handle id找到需要释放的IP的序数；

l 遍历allocation数组，获取已分配的需释放的IP的序数；

l 删除这些序数对应的属性；

l 将所有序数加入unallocated数组；

确保一致亲和性（ensureConsistentAffinity）

该函数用于在释放IP后校验“block所属的IP池”是否选择了“block亲和的节点”，如果IP池已不再选择该节点，则需清理blockAffinity对象。

l 获取block亲和的节点名，若节点名为空，则无需清理；

l 否则使用节点名获取节点对象，使用block cidr获取IP池对象；

l 若IP池为空，或IP池选择了该节点，则无需清理；

l 否则调用releaseBlockAffinity函数清理blockAffinity（参见第一部分）

总结

Calico 在分配IP地址时，会先寻找当前Node亲和的IP Block，然后在IP Block中给Pod分配IP，Blocksize默认为26。Blocksize不宜太大，会影响到Calico在Block中查找可用IP地址的性能。

如果没有找到亲和的IP Block，会在尝试申请新的IP Block，一个IPPool中的IPBlock不能太多太小，Calico逐个尝试申请IP Block会逐个去get 操作，太多次Get也影响IP地址分配速率。

如果不能申请新的IP  Block，Calico会去apiserver查询其他Node亲和的IPBlock，此时会产生IP地址借用的情况 ，借用的过程也是一个多次尝试的过程，如果其他大部分的Block处于饱和状态，而且IP地址非常紧张，这个过程也会有一定的性能损耗。

本文为原创文章，转载需表明出处。

 

关于我们–谐云HARMONYCLOUD

     杭州谐云科技有限公司成立于2016年7月,公司核心团队来自于浙江大学SEL实验室,谐云团队在云计算及相关领域具备深厚的技术积淀,在全球顶级开源社区Docker、Kubernetes、Cloud Foundry等项目贡献累计超过200万行代码,排名全球第四，国内第一。团队曾著书中国第一本深度解析容器云的专业书籍《Docker容器与容器云》，是国内为数不多掌握底层核心技术的容器云提供商。建设了目前中国最大的容器集群落地案例，支撑着国内最大的互联网电视云……

RPM

RPM是用于保存和管理RPM软件包的仓库。我们在RHEL和Centos系统上常用的Yum安装就是安装的RPM软件包，而Yum的源就是一个RPM软件包的仓库。JFrog Artifactory是成熟的RPM和YUM存储库管理器。JFrog的官方Wiki页面提供有关Artifactory RPM存储库的详细信息。

Artifactory索引RPM包的过程

Artifactory 5.5.0及之后版本，针对YUM元数据计算处理进行了重大的改进，加入了并发和增量计算的能力。所以新的索引过程：

• 性能上优于之前自动触发的异步计算
• 同时不需要在单独开发触发元数据计算的插件
• 可以监控并且准确地知道新的元数据计算的状态

如下图：创建RPM仓库时选择“Auto Calculate RPM Metadata”，Artifactory将会拦截Copy或Move的操作，并且自动触发计算步骤。保证在及时提供给用户最新的元数据用来获取软件包的版本

元数据的两种方式

• 异步：

正常情况下，如果启动了以上的选项，那么当你使用REAT API或者UI部署包的时候，异步计算将会拦截文件操作，并且将索引添加操作加入到Artifactory内部的队列中进行计算。

• 同步：

只有关闭“Auto Calculate RPM Metadata”时才可以使用，此时您可以手动触发元数据计算。

例：

有一个CI任务可以将很多版本上传到一个大型仓库里，可以在流水线中增加一个额外的构建步骤。以下为仓库名为“rpm-release-local”，通过Rest API请求手动触发元数据计算

curl -uadmin:password -XPOST “localhost:8081/artifactory/api/yum/rpm-release-local?async=0” -i -Lvv * Connected to localhost (::1) port 8081 (#0) * Server auth using Basic with user ‘admin’ > POST /artifactory/api/yum/rpm-release-local?async=0 HTTP/1.1 > Host: localhost:8081 > Authorization: Basic YWRtaW46cGFzc3dvcmQ= > User-Agent: curl/7.54.0 > Accept: */* < HTTP/1.1 200 OK < Server: Artifactory/6.3.2 < X-Artifactory-Id: a9116dfeb1f6dac4:449dde33:1658a295e45:-8000 < Content-Type: text/plain < Transfer-Encoding: chunked < Date: Sun, 02 Sep 2018 12:19:56 GMT

Artifactory RPM系统属性整选项（5.5.0及以上版本）

artifactory.rpm.metadata.calculation.workers（默认值为8） –本地RPM元数据计算线程数。 artifactory.rpm.metadata.history.cycles.keep（默认值3） –保留元数据记录，包括已经计算完成的计算记录 yum.virtual.metadata.calculation.workers（默认5） -虚拟库计算的线程数

日志

• RPM日志记录artifactory.addon.yum.YumAddonImpl：

INFO级别：Starting to calculate Rpm metadata for

您可以在Artifactory中的以下软件包上启用调试/跟踪级别日志记录（修改$ ARTIFACTORY_HOME / etc / logback.xml）以跟踪/调试您的计算：

自动计算（异步）：

DEBUG级别：{path}的异步Rpm计算

触发（同步）：

DEBUG级别：{path}的同步Rpm计算

• 虚拟RPM存储库计算：

为org.artifactory.addon.yum.virtual.index启用每个日志级别  ：

DBUG级别：为{path}启动虚拟yum元数据计算

整个包逻辑过程的跟踪级别：

为org.jfrog.metadata.indexer.RpmRepoIndexer启用每个日志级别  ：

TRACE级别：准备索引RPM存储库元数据

DEBUG级别：完成对RPM存储库元数据的索引编制

Portworx Essentials vs. Portworx Enterprise:

https://www.iqiyi.com/v_19rzfuk1yw.html

欢迎回到Portworx讲解视频系列，我是Ryan Warner。今天我们来介绍一下Portworx Essentials版本，以及与Portworx Enterprise版本的区别。

 

Portworx Essentials是在K8S上运行数据管理的最必要的功能组合，他的优势是永久免费，如果你不想完整的导入PortworxEnterprise版本，你仍然可以使用Portworx，虽然有一些功能限制，如果你现在的集群规模较小，或者刚刚开始搭建K8S，可以先不用急着购买Portworx Enterprise，仍然可以获得数据管理的重要功能。

 

接下来我来介绍一下Portworx Enterprise的具体功能有哪些。你可以在任何需要的时候升级到Portworx Enterprise。这里我列出了Portworx Enterprise的主要功能，例如，支持1000个节点，100个容器每节点，支持百万级别的卷，30天的免费试用，期间可以获得Portworx的完整功能，7*24，365天的支持，包括所有的组件：PX-DR，PX-Autopilot，PX-Security，PX-Migrate，PX-Backup。所有的企业级功能，当你需要在成规模的集群上运行有状态的关键应用。

 

Portworx Essentials，适合中小型企业客户或者是简单的K8S环境，Portworx Essentials，只支持最大5个节点，最大5TB存储，也就是1TB每节点，每卷容量的上限也是1TB/卷，一个节点可以创建单一的PVC，1TB。适合比如一个跑在3~5个节点上的应用，或者适合一个小型的数据库，会使用更少的存储，这里20G，那里20G，这种情况下，支持每节点30个容器，而Portworx Enterprise是每节点100个容器，你会有社区技术支持，可以访问Portworx Central、访问论坛、提交支持申请，这样来利用社区的技术资源，但是不同于Portworx Enterprise可以有企业级的支持。

 

如果需要组件功能（PX-DR，PX-Autopilot，PX-Security，PX-Migrate，PX-Backup），则需要通过购买Portworx Enterprise来实现，可以通过Portworx Essential来实现一些安全功能，每卷允许做5次快照，给与用户一些机会来保护应用，还允许每天一次的云快照，如果你需要把数据保存在云中，如对象存储中，来为K8S集群达到一定的容灾功能，可以每天做云快照一次，你也可以使用加密功能，但是也只能为集群使用单一的密钥，而不是像Enterprise那样，更复杂的卷和密钥的配置，

 

Portworx Essential仍然是一个很棒的解决方案，只是适用的集群规模会比较小，也适用于小规模的生产系统，如果规模扩大以后，我们还是建议升级到Portworx Enterprise，以上我们介绍了Portworx Essentials，欢迎下载试用，它是永久免费的，下次再见，谢谢！

 

Portworx Kubemotion：在OpenShift集群间迁移有状态应用

Portworx是一个支撑K8S有状态应用的持久存储和数据管理平台。通过Portworx，它为有状态应用提供了一个单一的数据管理层，从而用户可以在任何底层架构上运行类似数据库这样的有状态应用。

Kubemotion是Portworx的核心功能之一，发布在Portworx企业版2.0中。它赋能K8S用户在集群间迁移应用和数据、备份和恢复、以及做蓝绿部署。（https://docs.portworx.com/portworx-install-with-kubernetes/migration/kubemotion/）

下面我们介绍如何在红帽OpenShift集群之间，迁移有状态应用的持久卷和相关K8S资源。

背景

在企业客户中，一个常见的场景是：在一个云区域中运行研发测试环境，而在另一个云区域中运行生产环境。研发测试环境通常会选择距离开发团队比较近，以降低网络延迟，而生产环境则会选择离用户比较近。

K8S的无状态应用迁移相对比较容易，但迁移有状态应用是一个挑战。

在演示中，我们会在AWS位于美国东部（俄亥俄），和美国西部（俄勒冈）的两个数据中心的Openshift集群间，迁移K8S资源。美国东部区域（俄亥俄）部署的是研发测试环境，美国西部区域（俄勒冈）部署的是生产环境。在系统的测试环节完成后，开发团队将使用Portworx和Kubemotion，把存储卷和应用资源，从研发测试环境，迁移到生产环境中。

研发测试环境和生产环境

我们有两个红帽OpenShift集群，分别是研发测试环境、以及生产环境，位于AWS的两个不同区域上，两个环境都安装了最新版本的Portworx集群，并且正在运行。上面的OpenShift集群代表了运行在AWS东部区域（俄亥俄）的研发测试环境。

上面的OpenShift集群代表了运行在AWS西部区域（俄勒冈）的生产环境。

现在有一个基于LAMP的内容管理系统（CMS）运行在研发测试环境上，我们需要把它迁移到生产环境里。

研发测试环境里部署了MySQL和WordPress，它们都位于CMS命名空间里。

关于如何在OpenShift上配置高可用的WordPress，可以参考这里的文档。（https://www.portworx.com/run-multi-tenant-ha-wordpress-platform-red-hat-openshift/）

Portworx存储集群支撑了附加在这些Pod上的持久卷。

下面的卷附加到了MySQL pod上。

对于WordPress CMS, 有个共享的Portworx卷附加到了Pod上。

配置好的应用，可以通过WordPress相关的服务来访问。

准备源环境和目标环境

在我们迁移之前，我们需要配置源集群和目标集群。按照下面的步骤来准备相关的环境。

创建对象存储的访问身份验证我们需要在源集群和目标集群上都创建对象存储的访问身份验证信息。我们需要获得目标集群的UUID，它会被附加在访问身份的名称上。

为了完成这一步，你需要AWS账户的访问密钥和Secret密钥。如果你已经配置好了AWS CLI，可以在这里发现这些密钥。~/.aws/credentials

回到生产环境集群，运行下面的命令来复制UUID。

PX_POD=$(oc get pods -l name=portworx -n kube-system -o jsonpath='{.items[0].metadata.name}')
oc -n=kube-system exec $PX_POD -- /opt/pwx/bin/pxctl status

 

记下集群的UUID，放在一个安全的地方。

我们在生产环境内，来创建生产环境集群的身份验证信息。

oc -n=kube-system exec $PX_POD -- /opt/pwx/bin/pxctl credentials create \
	--provider s3 \
	--s3-access-key  \
	--s3-secret-key  \
	--s3-region ap-southeast-1  \
	--s3-endpoint s3.ap-southeast-1.amazonaws.com clusterPair_c02528e3-30b1-43e7-91c0-c26c111d57b3

确保身份验证信息的名称按照这样的格式：‘clusterPair_UUID’。

回到研发测试集群，重复操作来创建身份验证信息。

获取目标集群的Token

下一步是获取生产环境集群的Token，它会被用来创建集群配对的YAML文件。

到生产环境集群，运行下面的命令来访问Token。

PX_POD=$(oc get pods -l name=portworx -n kube-system -o jsonpath='{.items[0].metadata.name}')
oc -n=kube-system exec $PX_POD -- /opt/pwx/bin/pxctl cluster token show

记下集群Token，放置在一个安全的地方。

为Portworx服务获取负载均衡的端点

我们还需要生产环境集群上的，与Portworx服务关联的负载均衡的DNS名称。我们可以通过下面的命令得到。

oc describe svc portworx-service -n kube-system

到这里，你已经准备好下面的数据了：

1.   目标集群的Token

2.   指向Portworx服务的负载均衡的CNAME

创建集群配对参数

我们从生产环境（目标集群）来创建YAML文件。并且把它应用到研发测试环境（源集群）。

确保你在在生产环境中，运行下面的命令。

storkctl generate clusterpair -n cms prodcluster > clusterpair.yaml

打开clusterpair.yaml，在选项中增加下面的细节信息。它们反映了目标集群里的负载均衡的IP地址或者DNS名称，以及与目标集群关联的Token。

为Kubemotion进行集群配对

通过为源集群配置配对参数，我们可以把集群进行配对。

我们回到源集群（研发测试环境），来进行集群配对。

oc apply -f clusterpair.yaml
oc get clusterpair -n cms

<pre>oc getclusterpairs</pre> 的输出确认了配对已经成功。

验证配对状态

我们可以通过storkctl CLI来验证配对状态。确保存储的状态，和调度器的状态都是正常，没有错误。

storkctl -n=cms get clusterpair

我们验证了，源集群和目标集群已经配对成功。

现在我们开始迁移。

从源集群向目标集群迁移CMS应用

在研发测试环境下，通过下面的步骤开始CMS应用的迁移。

开始迁移

用下面的内容创建一个名为migration.yaml的YAML文件。

apiVersion: stork.libopenstorage.org/v1alpha1
kind: Migration
metadata:
  name: cmsmigration
  namespace: cms
spec:
  # This should be the name of the cluster pair created above
  clusterPair: prodcluster
  # If set to false this will migrate only the Portworx volumes. No PVCs, apps, etc will be migrated
  includeResources: true
  # If set to false, the deployments and stateful set replicas will be set to 0 on the destination.
  # There will be an annotation with "stork.openstorage.org/migrationReplicas" on the destinationto store the replica count from the source.
  startApplications: true
  # List of namespaces to migrate
  namespaces:
  - cms

这里包括一些很重要的信息，例如集群配对的名称、迁移中包括的命名空间，需要被迁移的资源类型。

把YAML文件提交到研发测试集群，来开始迁移。

oc apply -f migration.yaml
migration.stork.libopenstorage.org/cmsmigration created

监控迁移的过程

使用storkctl我们来监控迁移的过程。

storkctl get migration -n cms

 

一旦迁移完成，storkctl 会报告最后迁移到目标集群的卷的数量以及资源。

通过下面的命令，可以得到迁移过程的详细信息。

oc describe migration cmsmigration -n=cms
% oc describe migration cmsmigration -n=cms
Name:         cmsmigration
Namespace:    cms
Labels:
Annotations:  kubectl.kubernetes.io/last-applied-configuration:
                {"apiVersion":"stork.libopenstorage.org/v1alpha1","kind":"Migration","metadata":{"annotations":{},"name":"cmsmigration","namespace":"cms"}...
API Version:  stork.libopenstorage.org/v1alpha1
Kind:         Migration
Metadata:
  Creation Timestamp:  2019-11-08T02:33:44Z
  Generation:          9
  Resource Version:    346702
  Self Link:           /apis/stork.libopenstorage.org/v1alpha1/namespaces/cms/migrations/cmsmigration
  UID:                 2eeb5d56-01d0-11ea-a393-02fec625b80a
Spec:
  Admin Cluster Pair:
  Cluster Pair:        prodcluster
  Include Resources:   true
  Include Volumes:     true
  Namespaces:
    cms
  Post Exec Rule:
  Pre Exec Rule:
  Selectors:
  Start Applications:  true
Status:
  Finish Timestamp:  2019-11-08T02:34:56Z
  Resources:
    Group:      core
    Kind:       PersistentVolume
    Name:       pvc-ac60362f-0170-11ea-8418-06c5879a6a7a
    Namespace:
    Reason:     Resource migrated successfully
    Status:     Successful
    Version:    v1
    Group:      core
    Kind:       PersistentVolume
    Name:       pvc-c5dd1955-0170-11ea-a393-02fec625b80a
    Namespace:
    Reason:     Resource migrated successfully
    Status:     Successful
    Version:    v1
    Group:      core
    Kind:       Service
    Name:       mysql
    Namespace:  cms
    Reason:     Resource migrated successfully
    Status:     Successful
    Version:    v1
    Group:      core
    Kind:       Service
    Name:       wordpress
    Namespace:  cms
    Reason:     Resource migrated successfully
    Status:     Successful
    Version:    v1
    Group:      core
    Kind:       PersistentVolumeClaim
    Name:       px-mysql-pvc
    Namespace:  cms
    Reason:     Resource migrated successfully
    Status:     Successful
    Version:    v1
    Group:      core
    Kind:       PersistentVolumeClaim
    Name:       px-wp-pvc
    Namespace:  cms
    Reason:     Resource migrated successfully
    Status:     Successful
    Version:    v1
    Group:      apps
    Kind:       Deployment
    Name:       mysql
    Namespace:  cms
    Reason:     Resource migrated successfully
    Status:     Successful
    Version:    v1
    Group:      apps
    Kind:       Deployment
    Name:       wordpress
    Namespace:  cms
    Reason:     Resource migrated successfully
    Status:     Successful
    Version:    v1
    Group:      route.openshift.io
    Kind:       Route
    Name:       wp
    Namespace:  cms
    Reason:     Resource migrated successfully
    Status:     Successful
    Version:    v1
  Stage:        Final
  Status:       Successful
  Volumes:
    Namespace:                cms
    Persistent Volume Claim:  px-mysql-pvc
    Reason:                   Migration successful for volume
    Status:                   Successful
    Volume:                   pvc-ac60362f-0170-11ea-8418-06c5879a6a7a
    Namespace:                cms
    Persistent Volume Claim:  px-wp-pvc
    Reason:                   Migration successful for volume
    Status:                   Successful
    Volume:                   pvc-c5dd1955-0170-11ea-a393-02fec625b80a
Events:
  Type    Reason      Age                From   Message
  ----    ------      ----               ----   -------
  Normal  Successful  82s                stork  Volume pvc-ac60362f-0170-11ea-8418-06c5879a6a7a migrated successfully
  Normal  Successful  82s                stork  Volume pvc-c5dd1955-0170-11ea-a393-02fec625b80a migrated successfully
  Normal  Successful  78s                stork  /v1, Kind=PersistentVolume /pvc-ac60362f-0170-11ea-8418-06c5879a6a7a: Resource migrated successfully
  Normal  Successful  78s                stork  /v1, Kind=PersistentVolume /pvc-c5dd1955-0170-11ea-a393-02fec625b80a: Resource migrated successfully
  Normal  Successful  78s                stork  /v1, Kind=Service cms/mysql: Resource migrated successfully
  Normal  Successful  78s                stork  /v1, Kind=Service cms/wordpress: Resource migrated successfully
  Normal  Successful  78s                stork  /v1, Kind=PersistentVolumeClaim cms/px-mysql-pvc: Resource migrated successfully
  Normal  Successful  78s                stork  /v1, Kind=PersistentVolumeClaim cms/px-wp-pvc: Resource migrated successfully
  Normal  Successful  78s                stork  apps/v1, Kind=Deployment cms/mysql: Resource migrated successfully
  Normal  Successful  77s (x2 over 78s)  stork  (combined from similar events): route.openshift.io/v1, Kind=Route cms/wp: Resource migrated successfully

在生产环境上验证迁移

回到生产环境，我们来检查CMS命名空间里的所有资源。

oc get all -n cms

你可以通过为WordPress Pod使用port-forwardding，来访问应用。

小结

Kubemotion为有状态应用增加了迁移功能。它可以在本地环境和云环境之间，以及多云环境之间，无缝的迁移卷。

当您将Ansible与AWS结合使用时，维护清单文件将是一项繁重的任务，因为AWS经常更改IP，自动缩放实例等。但是，有一个简单的解决方案就是ansible动态清单。它基本上是一个Python脚本，当您运行ansible命令时会进行API调用以获取实例信息。这将为您提供动态清单详细信息，这些信息可以用来方便管理AWS基础架构。

设置Ansible AWS动态清单

1.使用pip安装boto库。如果您尚未安装pip，则可以按照此文档进行安装–> 安装python pip

pip install boto

2.将清单脚本下载到/ etc / ansible目录。

Wget https://raw.github.com/ansible/ansible/devel/contrib/inventory/ec2.py

3.使文件可执行。

chmod + x ec2.py

4.将ec2.ini文件下载到/ etc / ansible目录。

https://raw.githubusercontent.com/ansible/ansible/devel/contrib/inventory/ec2.ini

5. ec2.ini文件具有默认的AWS配置，可通过ec2.py文件读取。因此，请注释掉并配置必要的参数，以免查询时间过长。这样的例子就是“ regions”参数。默认情况下，该值为“ all”。这样可以对所有区域进行API调用。因此，最好只提及您使用的特定aws区域。

在[credentials]部分下，您需要提及abos访问密钥和私钥，以便boto库进行API调用。

或者，您可以在家里创建一个凭证文件，如下所示。

touch ~/.aws/credentials

打开凭证文件，然后如下所示进行输入。

[default]

aws_access_key_id = YOUR_ACCESS_KEY

aws_secret_access_key = YOUR_SECRET_KEY

注意：如果您正在使用AWS实例进行此设置，并且具有具有访问AWS服务权限的IAM角色，则无需将访问密钥和秘密密钥添加到凭证文件中

6 现在，使用以下命令测试清单配置。

./ec2.py –list

应该获得如下所示的输出。

{

“ _meta”：{

“ hostvars”：{}

}

}

如果您有一些实例正在运行，则将获得包含所有实例详细信息的输出。

7.如果要将动态清单用作默认的ansible清单，则需要编辑/ etc / ansible目录中存在的ansible.cfg文件，并在ansible.cfg中搜索清单参数。如下所示更改库存参数值。

inventory      = /etc/ansible/ec2.py

现在，您可以对动态清单资源运行正常的ansible命令。例如，以下命令将对使用动态清单获取的所有正在运行的ec2实例运行ping命令。

ansible all -m ping

关注每周二晚八点JFrog在线课堂，获取更多技术分享。关注微信公众号“JFrog杰蛙DevOps”，获取课程通知