K8S容灾方案的五个关键点

Portworx阅读(193)评论(0)

容灾恢复是绝大多数企业级应用的基本要求
在没有Kubernetes也没有容器的时候,备份和恢复解决方案通常在虚拟机(VM)级别上实现。当应用程序在单个VM上运行时,容灾系统适用于这样的传统应用程序。但是,当使用Kubernetes对应用程序进行容器化管理时,这样的容灾系统就无法使用了。有效的Kubernetes容灾恢复方案必须针对容器化架构进行重新设计,并按Kubernetes的原生方式来运行。

传统的基于VM的备份和恢复解决方案,使用快照来收集数据,但这些数据对于某个具体容器化应用并不足够。因为任何一个特定的VM都将包含来自多个应用的数据。如果您尝试通过VM快照来备份APP 1,将会同时获取其他应用的多余数据。但这些数据从容器角度来看又不够:APP 1可能还会将数据存储在其他VM上。因此通过对某个单独VM的快照无法捕获所有APP1的数据。

基于分布式体系结构的现代应用需要的容灾方案,需要能够找到特定应用的所有相关数据和配置信息,并能够以零RPO(Recovery Point Objective,复原点目标)和接近零RTO(Recovery Time Object,复原时间目标)的方式进行恢复。

一个有效的Kubernetes容灾解决方案需要具备:

  • 容器粒度的控制
  • 能够备份数据和配置
  • Kubernetes命名空间感知
  • 针对多云和混合云架构的优化
  • 保持应用的一致性

容灾解决方案必须满足以上五个标准,才能确保Kubernetes上运行的含大量数据的应用程序在容灾恢复的时候,满足服务水平协议(SLA)或相关法律要求。

让我们分析一下为什么这五个标准都很重要。

容器粒度控制??

容器粒度控制容灾方案意味着用户可以备份特定的Pod或Pod组,而不是备份整个VM或服务器。这使得用户可以仅快照属于该应用程序的容器。

假设您有一个三节点Kubernetes集群,其中有一个三节点Cassandra环和三个单节点PostgreSQL数据库,分布在三个虚拟机上。使用传统的灾难恢复解决方案,备份群集的唯一方法是备份三个虚拟机。这将导致提取,转换和加载过程带来的复杂性增加,存储成本增加和RTO增加。备份充足数据的唯一方法是备份超出必要数据的更多数据。

使用容器粒度的方式,可以在三个VM上仅备份一个PostgreSQL数据库或三节点Cassandra环,而无需其他任何备份。

Kubernetes命名空间感知??

传统的备份和恢复解决方案不是以Kubernetes的方式进行的。

Kubernetes中的命名空间通常运行多个相关的应用程序。例如,企业Kubernetes部署中的一种常见模式是使公司/部门所有的应用都运行在同一个命名空间内。在这种情况下,通常有必要一起备份Kubernetes命名空间中的所有应用程序。

但是,像每个单独的应用一样,命名空间分布在许多虚拟机上。每个虚拟机可能还有来自几个不同命名空间的Pod。如果没有支持命名空间的容灾解决方案,则完全备份将需要备份和存储远远超出必要的数据。即使采用了这种过分的备份策略,在发生故障的情况下也很难还原整个命名空间,从而导致较高的RTO。

应用的一致性?

即使您想通过备份系统中的所有VM来解决上述问题,使用传统的容灾恢复方案也很难避免数据损坏。为了成功地备份分布式应用,而没有数据损坏的风险,在快照进行过程中,必须锁定应用程序中的所有Pods。基于VM的快照无法实现此目的,因为它们无法锁定整个应用程序,无法跨多个VM执行应用一致性的快照。

成功的快照,要使数据损坏风险最小化,并必须保持分布式架构的应用的一致性。这意味着在锁定属于应用程序的所有Pods的同时,来执行快照。

 

数据和配置备份?

容灾系统的目标不仅是防止数据丢失,还在于保持RTO较低。您需要应用程序在遇到问题后尽快重新启动并运行。

这需要备份应用数据和配置信息。如果备份中不包含配置信息,则必须就地重建应用程序,这是一个缓慢,手动且可能容易出错的过程。但是,如果仅保存配置,则可能会丢失所有数据。

一个真正的Kubernetes的企业级容灾系统将同时包含数据和配置备份。这样在系统失败后,可以用一两个命令快速重新部署应用程序。

针对多云和混合云架构进行了优化?

绝大多数企业在实践中,应用程序至少在两个环境中运行。这可能意味着多个本地数据中心或多个Amazon Web Services(AWS)区域。在容灾恢复的情况下,通常将一个数据中心作为主站点,而将第二个数据中心作为备份站点。但是,也有许多公司使用公有云和本地数据中心的组合来运行应用程序并满足其业务需求。在大多数情况下,企业会根据其RPO和RTO要求选择最佳的架构方式。

对于容灾恢复解决方案而言,结合这些不同的架构方式以支持不同级别的RPO和RTO至关重要。有效的容灾恢复解决方案应该能够提供同步和异步数据复制,具体取决于主群集和备份群集之间的延迟。

当主站点和备份站点之间的往返延迟通常在10毫秒以下时,可以实现允许RTO和RPO为零的同步复制。这种情况通常是当主集群和备份群集所在数据中心地理相距较近。

在某些情况下,企业希望主站点和备份站点之间的地理距离远一些。在这种情况下,RTO仍可以为零或接近零。但是延迟的增加,同步复制数据会产生比较大的性能问题。如果应用能够接受15分钟或1小时的RPO,则也是可接受的容灾方案。

Kubernetes的企业级容灾恢复方案,应为用户提供适用于多云或混合云架构的,同步复制或异步复制的选择。这样可以使用户能够基于自己的数据中心架构和业务需求情况,来选择不同的容灾恢复方案。

结论??

当企业将关键业务应用迁移至Kubernetes时,重新思考和设计容灾恢复的方案非常重要。实际上可以做到在满足与容灾相关的SLA的同时,

在Kubernetes上运行应用。

但它需要采用专为Kubernetes设计的容灾方法,与Kubernetes的工作方式深入结合。传统的基于VM的容灾解决方案无法做到这一点。

Portworx Enterprise 存储平台是专门为容器和Kubernetes构建的。它可为Kubernetes上运行的应用实现零RPO和接近零的RTO容灾恢复。并具有容器粒度控制的,命名空间感知的,应用一致性的容灾恢复。故障恢复可以完全自动化,从尽可能降低RTO

2019北美KubeCon+CloudNativeCon上的K8S五大趋势

Portworx阅读(141)评论(0)

KubeCon+CloudNativeCon – 业界最隆重的盛会今年在圣地亚哥举办,超过 12000 名参会者以及 100 多个云原生供应商出席了这次大会。越来越多的企业开始采用K8S和容器架构来进行数字化转型的实践。我们总结了目前K8S发展存在的挑战,以及未来K8S发展的五大趋势,在这里分享。

1.?????K8S公认复杂性较高,如何降低部署的复杂性,如何增加系统的可见性和易操作性成为重要发展方向。当前情况下,用户很难知道正在发生什么,以及谁有权限访问数据。系统的复杂性使得许多配置容易出错。另外加密技术的安全性,保护容器集群和多云之间的通信安全。以及通过包括Kubernetes、底层OS和容器内的软件组件等安全更新使系统保持在最新状态。

2.????如何通过K8S在容器架构中使用数据库,成为重要的趋势。目前K8S对数据库功能的支持还不够有力。有状态下存储数据的能力还很一般。这使得K8S很难大规模承载生产系统和核心应用系统。

3.????如何提供更有效和更简单的手段对容器进行管理,应对类似传统架构中用户需要面对的关键问题:如存储和数据管理,包括迁移,备份,加密,容灾等等,成为决定企业能否快速采用容器和微服务架构实现生产系统云原生数字化的重要先决条件。在受调查的K8S用户中,有46%的人提到了安全问题,网络和存储分别排在第二和第三位。

4.????企业越来越多的采用混合云/多云架构,成为驱动容器技术的重要原因。很大一部分公有云用户正采用多供应商策略,这一比例已经从2016年的13%上升到2019年的27%。此外,在同一时间段内,混合云的使用率从24% 上升到了32% 。在多个云平台上运行应用程序已经成为了容器技术使用的主要驱动力,带来了远超以往的益处,如开发者效率的提升以及支持微服务等。

5.? ? ??K8S正在逐步被应用到生产环境和核心应用上。多个Kubernetes集群的集中管理,例如开发、测试和生产集群,或用于动态工作负载处理的多云设置将变得更加普遍。根据知名软件行业分析公司Redmonk的调查,财富100强的企业中有71%使用容器,其中超过50%的企业使用Kubernetes作为容器编排平台。”除此之外,CNCF还指出,纽约时报、eBay、Uber、高盛及Buffer等知名国际企业已经将Kubernetes大规模应用于生产环境。

2020年Service Mesh 三大发展方向

中文社区阅读(199)评论(0)

2019年,Service Mesh已从实验性技术到开始形成技术解决方案,将来也会成为Kubernetes?部署的基本组成部分。今年已经有一部分公司开始大规模采用Service Mesh,受第一批使用Service Mesh企业成功的经验影响,观望中的企业也会开始评估Service Mesh技术,以解决使用Kubernetes?所面临的挑战。
?
随着Service Mesh的采用日益广泛,2019年提供了一个新兴的Service Mesh市场。Istio和Linkerd一直保持竞争,一年中Istio周围的工具和供应商生态系统几乎增加了两倍。当然,也有许多新进入市场的参与者提供了解决第七层网络挑战的替代方法。networking(例如Kuma和Maesh提供的网格)已经出现,以提供不同的Service Mesh方法,以解决各种边缘用例。我们也看到了引进类似的工具服务网接口规范,但在主要参与者等待市场首先选择获胜者的同时还没有收缩。诸如?Network Service Mesh之类的相邻项目将服务网格原理带到了堆栈的较低层。
?
尽管在Service Mesh空间中仍有很多需要解决的问题,但是Service Mesh作为一种技术模式的价值是显而易见的,正如451 Research最近发布的“Voice of the Enterprise: DevOps”调查所证明的那样。
?

 

尽管仍然是一个新兴市场,但企业将Service Mesh作为基础架构的关键部分组成计划,将其迅速赶上Kubernetes和容器。

2020年Service Mesh:三大发展方向

?
1、对Service Mesh需求的快速增长
?
Kubernetes正在爆发,它已成为企业和容器编排的第一选择。Kubernetes是一项新兴技术,并且全球还有很多企业距离采用它还需要很多年。但是很明显,Kubernetes已经并且将继续是软件世界中的主导力量。
?
如果Kubernetes赢得了胜利,并且基于Kubernetes的应用程序的规模和复杂性将增加,那么就有一个临界点,即Service Mesh将成为有效管理那些应用程序所必需的一切。
?
2、Istio将很难被击败
?
未来市场上可能还有其他竞争者的空间,但市场的整合将于2020年开始。从长远来看,我们很可能会看到类似Kubernetes的情况,其中出现了赢家,公司开始标准化那个赢家。可以想象,Service Mesh可能不是解决第7层网络问题的技术模式。但是,如果确实发生了这种情况,则Istio似乎有可能成为事实上的Service Mesh。有很多支持和反对的观点,但是最有说服力的因素是围绕Istio开发的生态系统。几乎每个主要的软件供应商都有Istio解决方案或集成,并且Istio开源社区在活动和贡献方面远远超过任何其他社区。
?
3、案例、案例、案例
?
2019年是解决Service Mesh问题的一年。早期采用者从Service Mesh中选择了自己想要的前两个或三个功能并加入其中。在过去的一年中,最常用的三个解决方案是:
?
  • mTLS.
  • Observability.
  • Traffic management.
?
2020年将是Service Mesh核心用例出现的一年,并将被用作下一波采用者实施服务网格解决方案的模型。
?
客户要求的前三个用例是:
?
  • 可观察性,以更好地了解集群状态,快速调试并更深入地了解系统,构架更灵活,更稳定的系统。
  • 利用Service Mesh策略来驱动预期的应用程序行为。
  • 实施和证明安全且合规的环境。
  • 像WebAssembly这样的技术将使现有功能分配到数据平面边车上以及构建新的智能性和可编程性成为可能。
?
如果您已经使用了Service Mesh,那您将了解它带来的价值。
作者:Zach Jory
?原文:https://thenewstack.io/the-top-3-service-mesh-developments-in-2020/

如何保障云上数据安全?一文详解云原生全链路加密

alicloudnative阅读(166)评论(0)

 

本文节选自《不一样的 双11 技术:阿里巴巴经济体云原生实践》一书。

作者
李鹏(壮怀)阿里云容器服务高级技术专家
黄瑞瑞? 阿里云技术架构部资深技术专家

导读:对于云上客户而言,其云上数据被妥善的安全保护是其最重要的安全需求,也是云上综合安全能力最具象的体现。本文作者将从云安全体系出发,到云数据安全,再到云原生安全体系对全链路加密进行一次梳理,从而回答:在云原生时代,全链路加密需要做什么?如何做到?以及未来要做什么?

什么是云原生全链路加密

数据安全在云上的要求,可以用信息安全基本三要素 “CIA”来概括,即机密性(Confidentiality)、完整性(Integrity)和可用性(Availability)。

  • 机密性专指受保护数据只可以被合法的(或预期的)用户可访问,其主要实现手段包括数据的访问控制、数据防泄露、数据加密和密钥管理等手段;
  • 完整性是保证只有合法的(或预期的)用户才能修改数据,主要通过访问控制来实现,同时在数据的传输和存储中可以通过校验算法来保证用户数据的完整性;
  • 数据的可用性主要体现在云上环境整体的安全能力、容灾能力、可靠度,以及云上各个相关系统(存储系统、网络通路、身份验证机制和权限校验机制等等)的正常工作保障。

在三要素中,第一要素机密性(Confidentiality)最常见也是最常被要求的技术实现手段就是数据加密。具体到云原生维度,需要实现的就是云原生的全链路加密能力。

“全链路”指的是数据在传输 (in Transit,也叫 in-motion)、计算 (Runtime,也叫 in-process),存储 (in storage,也叫 at-rest) 的过程,而“全链路加密”指的是端到端的数据加密保护能力,即从云下到云上和云上单元之间的传输过程、到数据在应用运行时的计算过程(使用/交换),和到数据最终被持久化落盘的存储过程中的加密能力。

? 数据传输 (数据通信加密,微服务通信加密,应用证书和密钥的管理);
? 数据处理(运行时安全沙箱 runV, 可信计算安全沙箱 runE);
? 数据存储 (云原生存储的 CMK/BYOK 加密支持、密文/密钥的存储管理、容器镜像的存储加密、容器操作/审计日志安全)。

1.png

本文中的技术描述针对的是在云原生全链路加密中已有的和未来需要实现的技术目标。

云安全 >?云数据安全 > 云原生全链路加密

2.png

云安全

针对用户群体的不同,对安全链路有不同的层次定义,云安全涵盖了云客户安全和云厂商安全在 IaaS 的软件、硬件以及物理数据中心等的安全。

3.png

  • 云原生客户(Cloud Native Customer)安全
    • 应用安全
    • 操作安全
    • 商业安全
    • 容器网络安全
    • 容器数据安全
    • 容器运行时安全
  • 云客户(Cloud Customer)安全
  • 云厂商(Cloud IaaS DevOps)安全

云原生安全

4.png

云原生安全首先需要遵循云数据安全标准,在复用了云基础架构安全能力的前提下,同时在安全运行时,软件供应链上有进一步的安全支持。

云原生存储是通过声明式 API 来描述了云数据的生命周期,并不对用户透出底层 IaaS 的数据加密细节。不同的云原生存储一般作为云数据的载体,复用了云 IaaS 基础安全能力,还需要包括软件供应链中的镜像安全,和容器运行时 root 文件系统安全和容器网络安全。

  • 云原生安全的运行时 = 数据处理过程中的计算安全,内存安全,文件系统安全和网络安全
  • 云原生软件供应链安全 = 可执行文件/用户代码安全
  • 云原生基础架构的安全 = 云数据存储安全

云数据安全

云用户数据安全包括以下的三个方面的工作:

  • 数据保护:RAM ACL 控制细粒度的数据的访问权限;敏感数据保护(Sensitive
    Data Discovery and Protection,简称?SDDP)、数据脱敏、数据分级分类。
  • 数据加密:CMK 加密数据能力;BYOK 加密数据能力。
  • 密钥/密文管理:KMS/HSM 等云服务;三方 Vault 服务。

数据安全的生命周期

为了更好的理解数据保护,需要对数据安全的生命周期有一个了解,因为数据保护贯穿于整个的数据生命周期:

  • 数据收集
  • 数据传输
  • 数据处理
  • 数据交换
  • 数据存储
  • 数据销毁

5.png

云原生数据生命周期,以 ACK(容器服务 Kubernetes)挂载阿里云云盘为例:

  • 云盘 PV 的申明和创建定义了数据,云盘数据的加密需要在申明定义中就体现,对密钥匙选择、加密算法选择都可以申明式支持,RAM 权限细粒度遵循最小权限;
  • 云盘挂载到虚拟机通过 PVC 在容器组 Pod 引用得以触发和实现;
  • 云盘数据的解密通过用户 CMK/BYOK 在块设备上实现透明加密解密;
  • Pod 生命周期的变化导致 PVC 关联云盘在不同宿主 ECS 上的 Detach/Attach;
  • 对 PV 的 Snapshot 生命触发了云盘 Snapshot 的创建;
  • PV 的删除可以通过 OnDelete 关联到云盘的中止和数据的删除。

全链路的数据安全

在狭义上来说是对数据端到端的加密,主要集中在了数据生命周期中的三个阶段:

  • 数据传输
  • 数据处理
  • 数据存储

数据传输阶段

安全通信设计,密文/密钥的安全管理和传输,既要满足云环境下的安全传输、云原生引入的容器网络、微服务、区块链场景,又对云原生数据安全传输提出了进一步的要求。

  • 云安全传输

在云环境下 VPC/安全组的使用,密文/密钥的安全管理 KMS 南北向流量通过 SSL 证书服务获取可信有效的 CA,对南北流量实现 HTTPS 加密和卸载,以及对 RPC/gRPC 通信使用?SSL 加密,?减小 VPC 的攻击面,通过?VPN/SAG Gateway 来实现安全访问链路。

  • 云原生安全传输

云原生场景,单一集群允许多租户的同时共享网络、系统组件权限控制、数据通信加密、证书轮转管理,多租场景下东西流量的网络隔离、网络清洗;云原生微服务场景,应用/微服务间通信加密,和证书管理;云原生场景下密钥、密文的独立管理和三方集成、KMS 与 Vault CA, fabric-ca, istio-certmanager 等的集成。

数据处理阶段

数据处理阶段,对内存级的可信计算,既有云安全虚拟化安全运行的要求,又有容器安全沙箱和可信安全沙箱的需求。

6.png

  • 云安全虚拟化可信计算:TEE SGX;ARM Trust Zone;
  • 云原生容器安全沙箱:runV Kata?安全容器沙箱?;runE Graphane/Occlum 可信安全沙箱。

7.png

数据存储阶段

既有云安全对云存储加密、云数据服务加密需求,又有对容器镜像存储加密,审计日志、应用日志加密和三方集成的需求,以及对密文密码的不落盘存储支持。

云存储加密方式:

  • 数据 + 加密算法 + 用户密钥或主密钥;
  • 客户端加密/服务端加密。

8.png

云存储数据,以服务端加密为主;安全的密钥管理 KMS/HSM;安全的加密算法,全面支持国产算法以及部分国际通用密码算法,满足用户各种加密算法需求:

  • 对称密码算法:支持?SM1、SM4、DES、3DES、AES;
  • 非对称密码算法:支持?SM2、RSA(1024-2048);
  • 摘要算法:支持?SM3、SHA1、SHA256、SHA384。

阿里云只能管理设备硬件,主要包括监控设备可用性指标、开通、停止服务等。密钥完全由客户管理,阿里云没有任何方法可以获取客户密钥。

云存储加密支持

  • 块存储?EBS 云盘:支持虚拟机内部使用的块存储设备(即云盘)的数据落盘加密,确保块存储的数据在分布式系统中加密存放,并支持使用服务密钥和用户自选密钥作为主密钥进行数据加密;
  • 对象存储?OSS:支持服务端和客户端的存储加密能力。在服务端的加密中,支持使用服务密钥和用户自选密钥作为主密钥进行数据加密;在客户端的加密中,支持使用用户自管理密钥进行加密,也支持使用用户?KMS?内的主密钥进行客户端的加密;
  • RDS?数据库的数据加密:RDS?数据库的多个版本通过透明加密(Transparent
    Data Encryption,简称?TDE)或云盘实例加密机制,支持使用服务密钥和用户自选密钥作为主密钥进行数据加密;
  • 表格存储?OTS:支持使用服务密钥和用户自选密钥作为主密钥进行数据加密;
  • 文件存储?NAS:支持使用服务密钥作为主密钥进行数据加密;
  • MaxCompute 大数据计算:支持使用服务密钥作为主密钥进行数据加密;
  • 操作日志,审计日志的安全存储,以及三方日志系统集成。

云原生存储加密:目前阿里云容器服务 ACK 可以托管的主要以块存储、文件存储和对象存储为主,其他类型的 RDS、OTS 等数据服务是通过 Service Broker 等方式支持。

  • 用户容器镜像/代码 (企业容器镜像服务,OSS CMK/BYOK 加密);
  • 云原生存储卷 PV(申明式支持云存储的 CMK/BYOK 以及数据服务层的加密支持);
  • 操作日志和审计日志 (ActionTrail OpenAPI/Kubernetes AuditLog: SLS 日志加密);
  • 密文密码 (KMS/Vault 对密文的三方加密支持和内存存储,非 etcd 持久化)。

9.png

结论

云原生全链路的数据安全、云安全体系下的全链路加密已经成为了基础配置,新的容器化基础架构和应用架构的变化,结合云原生技术体系的特征,在数据传输、数据处理、数据存储阶段都需要增加相应云原生环境对网络、运行时、存储的全链路加密需求。

  • 既要满足云环境下的安全传输、云原生引入的容器网络、微服务、区块链场景,又对云原生数据安全传输提出了进一步的要求;
  • 既有云安全虚拟化安全运行的要求,又有容器安全沙箱,可信安全沙箱的需求;
  • 既有云安全对云存储加密、云数据服务加密需求,又有对容器镜像存储加密、审计日志、应用日志加密和三方集成的需求,以及对密文密码的不落盘存储的支持。

点击下载《不一样的 双11 技术:阿里巴巴经济体云原生实践》

ban.jpg

本书亮点

  • 双11 超大规模 K8s 集群实践中,遇到的问题及解决方法详述
  • 云原生化最佳组合:Kubernetes+容器+神龙,实现核心系统 100% 上云的技术细节
  • 双 11 Service Mesh 超大规模落地解决方案

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

开放下载 | 《Knative 云原生应用开发指南》开启云原生时代 Serverless 之门

alicloudnative阅读(224)评论(0)

knative海报.png

 

点击下载《Knative 云原生应用开发指南》

自 2018 年 Knative 项目开源后,就得到了广大开发者的密切关注。Knative 在 Kubernetes 之上提供了一套完整的应用 Serverless 编排服务,让应用开发者可以不用为底层的基础设施分心,把更多的精力投入到业务逻辑上。
Knative 的一个很重要的目标就是制定云原生、跨平台的 Serverless 编排标准。它的优势在于:

  • 基于 Kubernetes 实现 Serverless 编排;
  • 基于 Istio 实现服务的接入、服务路由的管理以及灰度发布等功能。

今年 5 月份,我们推出了 Knative 系列文章,由阿里云容器平台技术专家牛秋霖(冬岛)及阿里云容器平台高级开发工程师李鹏(元毅)结合自身的实践经验,由浅入深的介绍了 Knative 的使用、剖析其内部实现。

为了进一步方便大家理解 Knative,我们整理了系列文章中的 25 篇重点内容编排成书《Knative 云原生应用开发指南》,并开放分享给大家,希望能够帮助更多技术爱好者快速掌握 Knative 的应用 Serverless 编排技能,揭开 Knative 的神秘面纱。

为什么你要读这本书?

对于开发者而言,本书可以让你快速掌握 Knative 的应用 Serverless 编排技能;对于管理者或决策者而言,可以通过本书的介绍和案例深入了解企业为什么需要应用的 Serverless 编排;如何对普通应用进行 Serverless 编排;应用编排和 IaaS 无服务器计算的关系以及为什么会是 Knative 等问题。

本书主要分为入门、进阶和实战三个部分。

  • 入门篇可以帮助你快速掌握 Knative 的核心理念和关键设计,让你对应用的云原生编排应该具备什么能力有一个清晰的认识;
  • 进阶篇会对 Knative 各大核心模块的高级功能进行更深入的介绍,剖析 Knative 是如何构建在 Kubernetes 之上的;
  • 实战篇给出了很多基于 Knative 的云原生实战,让你对 Knative 的使用有一个更直观的体感。

目录.png

《Knative 云原生应用开发指南》目录?点击可查看大图

在 All in Cloud 的时代,对云的驾驭能力已经成为企业的核心竞争力,云正在重塑企业 IT 架构。每个企业都在思考如何最大化利用“云”的能力,最大化发挥“云”的价值。而企业上云的过程中是要直接面对众多的云厂商和各种繁杂的云产品,比如最基本的 IaaS 资源,同样是 VM 在不同的云厂商就有不同的特性、不同的 OpenAPI 和不同的创建与销毁方式。

这给企业上云带来了巨大的复杂度,大大打击了企业上云的积极性。所以对于上云的企业和提供云服务的厂商而言都在摸索寻找一个折中的平衡点,既能帮助企业上云,又能帮助云厂商释放云的能力。

云原生理念的形成与完善

云原生理念是在以上过程中逐渐形成和完善的。这套理念是协调所有参与方对服务上云逐渐形成的统一标准,它可以很好地帮助企业上云、帮助云厂商释放云的能力。云原生旨在以更标准化的方式衔接云厂商和上云企业:

  • 这种方式对于企业而言降低了上云和跨云的成本,让企业始终保有和云厂商议价的能力;
  • 对于云厂商而言,因为企业跨云迁移的成本低,所以只要能提供性价比更高的云服务,就能很容易的聚集大量用户。

云原生是在不断促进整个系统的良性循环:既能让企业始终保有选择的能力,又能让优秀的云厂商快速服务更多的客户。如果客户的业务服务能像水一样低成本在不同云厂商之间流动,那么云厂商提供的服务就能像货币一样在客户之间流通。这是一个多赢的局面。

Kubernetes 已经成为分布式资源调度和资源编排的事实标准,它屏蔽了底层基础架构的差异,帮助应用轻松运行在不同的基础设施之中。

目前云原生生态已经在 Kubernetes 之上构建了大量的上层服务支撑框架。比如:服务网格 Istio、 Kubeflow 、各种上层服务的 Operator 等等。我们可以看到构建在 Kubernetes 之上的云原生操作系统的雏形开始出现,这是开发者最好的时代,极大地提升了业务创新的速度。

无服务器(Serverless)的出现

随着 Kubernetes 的普及,开发者已经不需要关心基础设施,有了更多的精力放在业务的核心逻辑上,随之而来的就是无服务器计算的出现。

无服务器首先是在 IaaS 层的变革,用户无需提前准备冗余的 IaaS 资源,只需要在使用的时候自动扩容不用的时候自动缩容。因为应用真正需要的是 IaaS 资源的按需分配按量计费,而不是长期保有 IaaS 资源。

无服务器这个词是从 Serverless 翻译过来的,其实 Serverless 除了基础 IaaS 资源的按量分配以外还有一层就是对应用的 Serverless 编排。

Knative?出现的必然性

IaaS 资源可以按需分配只是一个开始,当 IaaS 完成了 Serverless 进化以后,应用层应该如何做呢?比如:一个普通应用需要具备什么能力才能按量使用 IaaS 资源呢?对应用进行 Serverless 编排是否能保证应用可以很容易的在不同的云厂商之间跨云迁移?

Knative 就是应用 Serverless 编排的云原生解决方案。

Knative 建立在 Kubernetes 和 Istio 之上,通过 Kubernetes 的跨云能力能够让企业应用原生具备跨云迁移的能力。在多云、混合云以及云边端互通的时代,基于 Knative 的应用 Serverless 云原生编排能力可以极大降低企业上云的成本。

云原生时代,如何在云上玩转 Knative?

《Knative 云原生应用开发指南》一书中共收录了 8 篇具体的 Knative 开发实践案例,给出了很多基于 Knative 的云原生实战,借此讲述了如何正确使用 Knative 中的 Build、Serving 以及 Eventing 三大组件来发挥其作用,逐渐精简我们的代码;直观地展示了如何使用 Knative 来一步步简单高效地开发云原生应用,让你对通过? Knative 来实践 Serverless 有一个更全面的体感。

期待《Knative 云原生应用开发指南》能够帮助更多的开发者真正开启云原生时代的 Serverless 之门,轻松解决迎面难题,避免踩坑!

点击下载《Knative 云原生应用开发指南》

knative海报.png

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

从零开始入门 K8s | 手把手带你理解 etcd

alicloudnative阅读(921)评论(0)

作者?| 曾凡松(逐灵)?阿里云容器平台高级技术专家

本文整理自《CNCF x Alibaba 云原生技术公开课》第 16 讲。

导读:etcd?是用于共享配置和服务发现的分布式、一致性的 KV 存储系统。本文从 etcd 项目发展所经历的几个重要时刻开始,为大家介绍了 etcd 的总体架构及其设计中的基本原理。希望能够帮助大家更好的理解和使用 etcd。

一、etcd 项目的发展历程

etcd 诞生于 CoreOS 公司,它最初是用于解决集群管理系统中 OS 升级的分布式并发控制以及配置文件的存储与分发等问题。基于此,etcd 被设计为提供高可用、强一致的小型 keyvalue 数据存储服务。

项目当前隶属于 CNCF 基金会,被 AWS、Google、Microsoft、Alibaba 等大型互联网公司广泛使用。

1.png

最初,在 2013 年 6 月份由 CoreOS 公司向 GitHub 中提交了第一个版本的初始代码。

到了 2014 年的 6 月,社区发生了一件事情,Kubernetes v0.4 版本发布。这里有必要介绍一下 Kubernetes 项目,它首先是一个容器管理平台,由谷歌开发并贡献给社区,因为它集齐了谷歌在容器调度以及集群管理等领域的多年经验,从诞生之初就备受瞩目。在 Kubernetes v0.4 版本中,它使用了 etcd 0.2 版本作为实验核心元数据的存储服务,自此 etcd 社区得到了飞速的发展。

很快,在 2015 年 2 月份,etcd 发布了第一个正式的稳定版本 2.0。在 2.0 版本中,etcd 重新设计了 Raft 一致性算法,并为用户提供了一个简单的树形数据视图,在 2.0 版本中 etcd 支持每秒超过 1000 次的写入性能,满足了当时绝大多数的应用场景需求。2.0 版本发布之后,经过不断的迭代与改进,其原有的数据存储方案逐渐成为了新时期的性能瓶颈,之后 etcd 启动了 v3 版本的方案设计。

2017 年 1 月份的时候,etcd 发布了 3.1 版本,v3 版本方案基本上标志着 etcd 技术上全面成熟。在 v3 版本中 etcd 提供了一套全新的 API,重新实现了更高效的一致性读取方法,并且提供了一个 gRPC 的 proxy 用于扩展 etcd 的读取性能。同时,在 v3 版本的方案中包含了大量的 GC 优化,在性能优化方面取得了长足的进步,在该版本中 etcd 可以支持每秒超过 10000 次的写入。

2018 年,CNCF 基金会下的众多项目都使用了 etcd 作为其核心的数据存储。据不完全统计,使用 etcd 的项目超过了 30 个,在同年 11 月份,etcd 项目自身也成为了 CNCF 旗下的孵化项目。进入 CNCF 基金会后,etcd 拥有了超过 400 个贡献组,其中包含了来自 AWS、Google、Alibaba 等 8 个公司的 9 个项目维护者。

2019 年,etcd 即将发布全新的 3.4 版本,该版本由 Google、Alibaba 等公司联合打造,将进一步改进 etcd 的性能及稳定性,以满足在超大型公司使用中苛刻的场景要求。

二、架构及内部机制解析

总体架构

etcd 是一个分布式的、可靠的 key-value 存储系统,它用于存储分布式系统中的关键数据,这个定义非常重要。

2.png

一个 etcd 集群,通常会由 3 个或者 5 个节点组成,多个节点之间通过 Raft 一致性算法的完成分布式一致性协同,算法会选举出一个主节点作为 leader,由 leader 负责数据的同步与数据的分发。当 leader 出现故障后系统会自动地选取另一个节点成为 leader,并重新完成数据的同步。客户端在多个节点中,仅需要选择其中的任意一个就可以完成数据的读写,内部的状态及数据协同由 etcd 自身完成。

在 etcd 整个架构中,有一个非常关键的概念叫做 quorum,quorum 的定义是 (n+1)/2,也就是说超过集群中半数节点组成的一个团体,在 3 个节点的集群中,etcd 可以容许 1 个节点故障,也就是只要有任何 2 个节点可用,etcd 就可以继续提供服务。同理,在 5 个节点的集群中,只要有任何 3 个节点可用,etcd 就可以继续提供服务,这也是 etcd 集群高可用的关键。

在允许部分节点故障之后继续提供服务,就需要解决一个非常复杂的问题:分布式一致性。在 etcd 中,该分布式一致性算法由 Raft 一致性算法完成,这个算法本身是比较复杂的有机会再详细展开,这里仅做一个简单的介绍以方便大家对其有一个基本的认知。Raft 一致性算法能够工作的一个关键点是:任意两个 quorum 的成员之间一定会有一个交集(公共成员),也就是说只要有任意一个 quorum 存活,其中一定存在某一个节点(公共成员),它包含着集群中所有的被确认提交的数据。正是基于这一原理,Raft 一致性算法设计了一套数据同步机制,在 Leader 任期切换后能够重新同步上一个 quorum 被提交的所有数据,从而保证整个集群状态向前推进的过程中保持数据的一致。

3.png

etcd 内部的机制比较复杂,但 etcd 给客户提供的接口是简单直接的。如上图所示,我们可以通过 etcd 提供的客户端去访问集群的数据,也可以直接通过 http 的方式(类似 curl 命令)直接访问 etcd。在 etcd 内部,其数据表示也是比较简单的,我们可以直接把 etcd 的数据存储理解为一个有序的 map,它存储着 key-value 数据。同时 etcd 为了方便客户端去订阅数据的变更,也支持了一个 watch 机制,通过 watch 实时地拿到 etcd 中数据的增量更新,从而实现与 etcd 中的数据同步等业务逻辑。

API 介绍

接下来我们看一下 etcd 提供的接口,这里将 etcd 的接口分为了 5 组:

4.png

  • 第一组是 Put 与 Delete。上图可以看到 put 与 delete 的操作都非常简单,只需要提供一个 key 和一个 value,就可以向集群中写入数据了,删除数据的时候只需要指定 key 即可;
  • 第二组是查询操作。etcd 支持两种类型的查询:第一种是指定单个 key 的查询,第二种是指定的一个 key 的范围;
  • 第三组是数据订阅。etcd 提供了 Watch 机制,我们可以利用 watch 实时订阅到 etcd 中增量的数据更新,watch 支持指定单个 key,也可以指定一个 key 的前缀,在实际应用场景中的通常会采用第二种形势;
  • 第四组事务操作。etcd 提供了一个简单的事务支持,用户可以通过指定一组条件满足时执行某些动作,当条件不成立的时候执行另一组操作,类似于代码中的 if else 语句,etcd 确保整个操作的原子性;
  • 第五组是 Leases 接口。Leases 接口是分布式系统中常用的一种设计模式,其用法后面会具体展开。

数据版本机制

要正确使用 etcd 的 API,必须要知道内部对应数据版本号的基本原理。

首先 etcd 中有个 term 的概念,代表的是整个集群 Leader 的任期。当集群发生 Leader 切换,term 的值就会 +1。在节点故障,或者 Leader 节点网络出现问题,再或者是将整个集群停止后再次拉起,都会发生 Leader 的切换。

第二个版本号叫做 revision,revision 代表的是全局数据的版本。当数据发生变更,包括创建、修改、删除,其 revision 对应的都会 +1。特别的,在集群中跨 Leader 任期之间,revision 都会保持全局单调递增。正是 revision 的这一特性,使得集群中任意一次的修改都对应着一个唯一的 revision,因此我们可以通过 revision 来支持数据的 MVCC,也可以支持数据的 Watch。

对于每一个 KeyValue 数据节点,etcd 中都记录了三个版本:

  • 第一个版本叫做 create_revision,是 KeyValue 在创建时对应的 revision;
  • 第二个叫做 mod_revision,是其数据被操作的时候对应的 revision;
  • 第三个 version 就是一个计数器,代表了 KeyValue 被修改了多少次。

这里可以用图的方式给大家展示一下:

5.png

在同一个 Leader 任期之内,我们发现所有的修改操作,其对应的 term 值始终都等于 2,而 revision 则保持单调递增。当重启集群之后,我们会发现所有的修改操作对应的 term 值都变成了 3。在新的 Leader 任期内,所有的 term 值都等于3,且不会发生变化,而对应的 revision 值同样保持单调递增。从一个更大的维度去看,可以发现在 term=2 和 term=3 的两个 Leader 任期之间,数据对应的 revision 值依旧保持了全局单调递增。

mvcc & streaming watch

了解 etcd 的版本号控制后,接下来如何使用 etcd 多版本号来实现并发控制以及数据订阅(Watch)。

在 etcd 中支持对同一个 Key 发起多次数据修改,每次数据修改都对应一个版本号。etcd 在实现上记录了每一次修改对应的数据,也就就意味着一个 key 在 etcd 中存在多个历史版本。在查询数据的时候如果不指定版本号,etcd 会返回 Key 对应的最新版本,当然 etcd 也支持指定一个版本号来查询历史数据。

6.png

因为 etcd 将每一次修改都记录了下来,使用 watch 订阅数据时,可以支持从任意历史时刻(指定 revision)开始创建一个 watcher,在客户端与 etcd 之间建立一个数据管道,etcd 会推送从指定 revision 开始的所有数据变更。etcd 提供的 watch 机制保证,该 Key 的数据后续的被修改之后,通过这个数据管道即时的推送给客户端。

如下图所示,etcd 中所有的数据都存储在一个 b+tree 中(灰色),该 b+tree 保存在磁盘中,并通过?mmap 的方式映射到内存用来支持快速的访问。灰色的 b+tree 中维护着 revision 到 value 的映射关系,支持通过 revision 查询对应的数据。因为 revision 是单调递增的,当我们通过 watch 来订阅指定 revision 之后的数据时,仅需要订阅该 b+ tree 的数据变化即可。

7.png

在 etcd 内部还维护着另外一个 btree(蓝色),它管理着 key 到 revision 的映射关系。当客户端使用 key 查询数据时,首先需要经过蓝色的 btree 将 key 转化为对应的 revision,再通过灰色的 btree 查询到对应的数据。

细心的读者会发现,etcd 将每一次修改都记录下来会导致数据持续增长,这会带来内存及磁盘的空间消耗,同时也会影响 b+tree 的查询效率。为了解决这一问题,在 etcd 中会运行一个周期性的 Compaction 的机制来清理历史数据,将一段时间之前的同一个 Key 的多个历史版本数据清理掉。最终的结果是灰色的 b+tree 依旧保持单调递增,但可能会出现一些空洞。

mini-transactions

在理解了 mvcc 机制及 watch 机制之后,继续看 etcd 提供的 mini-transactions 机制。etcd 的 transaction 机制比较简单,基本可以理解为一段 if-else 程序,在 if 中可以提供多个操作,如下图所示:

8.png

If 里面写了两个条件,当 Value(key1) 大于 “bar” 并且 Version(key1) 的版本等于 2 的时候,执行 Then 里面指定的操作:修改 Key2 的数据为 valueX,同时删除 Key3 的数据。如果不满足条件,则执行另外一个操作:Key2 修改为 valueY。

在 etcd 内部会保证整个事务操作的原子性。也就是说 If 操作所有的比较条件,其看到的视图一定是一致的。同时它能够确保多个操作的原子性不会出现 Then 中的操作仅执行了一半的情况。

通过 etcd 提供的事务操作,我们可以在多个竞争中去保证数据读写的一致性,比如说前面已经提到过的 Kubernetes 项目,它正是利用了 etcd 的事务机制,来实现多个 KubernetesAPI server 对同样一个数据修改的一致性。

lease 的概念及用法

lease 是分布式系统中一个常见的概念,用于代表一个分布式租约。典型情况下,在分布式系统中需要去检测一个节点是否存活的时,就需要租约机制。

9.png

上图示例中的代码示例首先创建了一个 10s 的租约,如果创建租约后不做任何的操作,那么 10s 之后,这个租约就会自动过期。接着将 key1 和 key2 两个 key value 绑定到这个租约之上,这样当租约过期时 etcd 就会自动清理掉 key1 和 key2,使得节点 key1 和 key2 具备了超时自动删除的能力。

如果希望这个租约永不过期,需要周期性的调用 KeeyAlive 方法刷新租约。比如说需要检测分布式系统中一个进程是否存活,可以在进程中去创建一个租约,并在该进程中周期性的调用 KeepAlive 的方法。如果一切正常,该节点的租约会一致保持,如果这个进程挂掉了,最终这个租约就会自动过期。

在 etcd 中,允许将多个 key 关联在同一个 lease 之上,这个设计是非常巧妙的,可以大幅减少 lease 对象刷新带来的开销。试想一下,如果有大量的 key 都需要支持类似的租约机制,每一个 key 都需要独立的去刷新租约,这会给? etcd 带来非常大的压力。通过多个 key 绑定在同一个 lease 的模式,我们可以将超时间相似的 key 聚合在一起,从而大幅减小租约刷新的开销,在不失灵活性同时能够大幅提高 etcd 支持的使用规模。

三、典型的使用场景介绍

元数据存储

Kubernetes 将自身所用的状态存储在 etcd 中,其状态数据的高可用交给 etcd 来解决,Kubernetes 系统自身不需要再应对复杂的分布式系统状态处理,自身的系统架构得到了大幅的简化。

10.png

Server Discovery (Naming Service)

第二个场景是 Service Discovery,也叫做名字服务。在分布式系统中,通常会出现的一个模式就是需要多个后端(可能是成百上千个进程)来提供一组对等的服务,比如说检索服务、推荐服务。

11.png

对于这样一种后端服务,通常情况下为了简化后端服务的运维成本(节点故障时随时被替换),后端的这一进程会被类似 Kubernetes 这样的集群管理系统所调度,这样当用户(或上游服务)调用过来时,我们就需要一个服务发现机制来解决服务路由问题。这一服务发现问题可以利用 etcd 来高效解决,方式如下:

  • 在进程内部启动之后,可以将自身所在的地址注册到 etcd;
  • API 网关够通过 etcd 及时感知到后端进程的地址,当后端进程发生故障迁移时会重新注册到 etcd 中,API 网关也能够及时地感知到新的地址;
  • 利用 etcd 提供的?Lease 机制,如果提供服务的进程运行过程中出现了异常(crash),API 网关也可以摘除其流量避免调用超时。

在这一架构中,服务状态数据被 etcd 接管,API 网关本身也是无状态的,可以水平地扩展来服务更多的客户。同时得益于 etcd 的良好性能,可以支持上万个后端进程的节点,使得这一架构可以服务于大型的企业。

Distributed Coordination: leader election

在分布式系统中,有一种典型的设计模式就是 Master+Slave。通常情况下,Slave 提供了 CPU、内存、磁盘以及网络等各种资源 ,而 Master 用来调和这些节点以使其对外提供一个服务(比如分布式存储,分布式计算)。典型的分布式存储服务(HDFS)以及分布式计算服务(Hadoop)它们都是采用了类似这样的设计模式。这样的设计模式会有一个典型的问题:Master 节点的可用性。当 Master 故障以后,整个集群的服务就挂掉了,没有办法再服务用户的请求。

为了解决这个问题,典型的做法就是启动多个 Master 节点。因为 Master 节点内会包含控制逻辑,多个节点之间的状态同步是非常复杂的,这里最典型的做法就是通过选主的方式,选出其中一个节点作为主节点来提供服务,另一个节点处于等待状态。

12.png

通过 etcd 提供的机制可以很容易的实现分布式进程的选主功能,比如可以通过对同一个 key 的事务写来实现抢主的逻辑。一般而言,被选主的 Leader 会将自己的 IP 注册到 etcd 中,使得 Slave 节点能够及时获取到当前的 Leader 地址,从而使得系统按照之前单个 Master 节点的方式继续工作。当 Leader 节点发生异常之后,通过 etcd 能够选取出一个新的节点成为主节点,并且注册新的 IP 之后,Slave 又能够拉取新的主节点的 IP,继续恢复服务。

Distributed Coordination 分布式系统并发控制

在分布式系统中,当我们去执行一些任务,比如说去升级 OS、或者说升级 OS 上的软件的时候、又或者去执行一些计算任务的时候,出于对后端服务的瓶颈或者是业务稳定性的考虑,通常情况下需要控制任务的并发度。如果该任务缺少一个调和的 Master 节点,可以通过 etcd 来完成这样的分布式系统工作。

13.png

在这个模式中通过 etcd 去实现一个分布式的信号量,并且可以利用 etcd leases 机制来实现自动地剔除掉故障节点。在进程执行过程中,如果进程的运行周期比较长,我们可以将进程运行过程中的一些状态数据存储到 etcd,从而使得当进程故障之后且需要恢复到其他地方时,能够从 etcd 中去恢复一些执行状态,而不需要重新去完成整个的计算逻辑,以此来加速整个任务的执行效率。

本文总结

本文分享的主要内容就到此为止了,这里为大家简单总结一下:

  • 第一部分,为大家介绍了 etcd 项目是如何诞生的,以及在 etcd 发展过程中经历的几个重要时刻;
  • 第二部分,为大家介绍了 etcd 的架构以及其内部的基本操作接口,在理解 etcd 是如何实现高可用的基础之上,展示了 etcd 数据的一些基本操作以及其内部的实现原理;
  • 第三部分,介绍了三种典型的 etcd 使用场景,以及在对应的场景下,分布式系统的设计思路。

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

Kubernetes 时代的安全软件供应链

alicloudnative阅读(183)评论(0)

本文节选自《不一样的 双11 技术:阿里巴巴经济体云原生实践》一书。

作者
汤志敏? 阿里云容器服务高级技术专家
汪圣平? 阿里云云平台安全高级安全专家

导读:从 Docker image 到 Helm, 从企业内部部署到全球应用分发,作为开发者的我们如何来保障应用的交付安全。本文会从软件供应链的攻击场景开始,介绍云原生时代的应用交付标准演进和阿里云上的最佳实践。

“没有集装箱,就不会有全球化”。在软件行业里,Docker 和 Kubernetes 也扮演了类似的角色,加速了软件行业的社会化分工和交付运维的效率。2013 年, Docker 公司提出了容器应用打包规范 Docker Image,帮助开发者将应用和依赖打包到一个可移植的镜像里。2015 年,Google 将 Kubernetes 捐献给 CNCF,进一步普及了大规模容器编排调度的标准。

Kubernetes?以一种声明式的容器编排与管理体系,屏蔽了底层基础架构的差异,让软件交付变得越来越标准化。随着 K8s 为代表的云原生技术的大规模运用,越来越多的容器化应用被分发到 IDC、公共云、边缘等全球各地。

在 2019 年,阿里云容器镜像服务 ACR 的月镜像下载量超过了 3 亿次。同年 10 月,阿里云云市场的容器镜像类目发布,越来越多的企业将其软件以容器的方式进行上架和销售。11 月,天猫 双11 的所有核心系统 100% 上云,容器镜像服务 ACR 除了支持 双11 的内部镜像托管以外,也将内部的能力在云上透出,支持更多的 双11 生态公司。

接下来我们看下如何保证容器和 Kubernetes 下的软件供应链安全,并先熟悉下软件供应链的常见攻击场景。

软件供应链攻击面和典型攻击场景

软件供应链通常包括三个阶段:

  • 软件研发阶段
  • 软件交付阶段
  • 软件使用阶段

在不同阶段的攻击面如下:

1.png

历史上著名的 APPLE Xcode IDE 工具攻击就是发生在软件研发阶段的攻击,攻击者通过向 Xcode 中注入恶意后门,在非官方网站提供下载,所有使用此 Xcode 的开发者编译出来的 APP 将被感染后门。同样著名的还有美国的棱镜门事件,亦是在大量的软件中植入后门程序,进行数据获取等恶意操作。

Kubernetes 中的软件供应链攻击面也包括在以上范围之中,以软件使用阶段为例,今年 RunC 漏洞 CVE-2019-5736,漏洞本身与 RunC 的运行设计原理相关,Container 之外的动态编译 Runc 被触发运行时会引用 Conainer 内部的动态库,造成 RunC 自身被恶意注入从而运行恶意程序,攻击者只需要在一个 Container 镜像中放入恶意的动态库和恶意程序,诱发受攻击者恶意下载运行进行模糊攻击,一旦受攻击者的 Container 环境符合攻击条件,既可完成攻击。

2.png

同样的攻击面还存在于 Kubernetes?自身服务组件之中,前段时间爆出的 HTTP2 CVE-2019-9512、CVE-2019-9514 漏洞就是一个非常好的软件研发阶段脆弱性的例子,漏洞存在于 GO 语言的基础 LIB 库中,任何依赖 GO 版本(<1.2.9)所编译的 KubernetesHTTP2 服务组件都受此漏洞影响,因此当时此漏洞影响了 K8s 全系列版本,攻击者可以远程 DOS Kubernetes API Server。同时在 Kubernetes 组件的整个交付过程中也存在着攻击面,相关组件存在被恶意替换以及植入的可能性。

不同于传统的软件供应链,镜像作为统一交付的标准如在容器场景下被大规模应用,因此关注镜像的使用周期可以帮助攻击者更好的设计攻击路径。

3.png

攻击者可以在镜像生命周期的任何一个阶段对镜像进行污染,包括对构建文件的篡改、对构建平台的后门植入、对传输过程中的劫持替换和修改、对镜像仓库的攻击以替换镜像文件、对镜像运行下载和升级的劫持攻击等。

整个攻击过程可以借助云化场景中相关的各种依赖,如 Kubernetes 组件漏洞、仓库的漏洞,甚至基础设施底层漏洞。对于防御者来说,对于镜像的整个生命周期的安全保障,是容器场景中攻击防范的重中之重。

云原生时代的应用交付标准演进(从 Image 到 Artifacts)

在云原生时代之前,应用交付的方式比较多样化,比如脚本、RPM 等等。而在云原生时代,为了屏蔽异构环境的差异,提供统一的部署抽象,大家对应用交付标准的统一也迫切起来。

Helm

Helm 是 Kubernetes 的包管理工具,它提出了 Chart 这个概念。

  • 一个 Chart 描述了一个部署应用的多个 Kubernetes 资源的?YAML 文件,包括文档、配置项、版本等信息;
  • 提供 Chart 级别的版本管理、升级和回滚能力。

CNAB

CNAB 是 Docker 和微软在 2018 年底联合推出平台无关的 Cloud Native Application Bundle 规范。相比于 Helm,有额外几个定义:

  • 在 thick 模式时,CNAB 的 bundle 可以包含依赖的镜像二进制,从而不需要额外去镜像仓库下载,作为一个整体打包;
  • CNAB 定义了扩展的安全标准,定义了 bundle 的签名(基于 TUF )和来源证明(基于 In-Toto)描述;
  • CNAB 的部署是平台无关性,可以部署在 K8s 之上,也可以通过 terraform 等方式来部署。

CNAB 的这些特性,可以在可信软件分发商与消费者之间进行跨平台(包括云和本地 PC)的应用打包和分发。

4.png

OCI?Artifacts

2019 年 9 月,开放容器标准组织(OCI)在 OCI 分发标准之上,为了支持更多的分发格式,推出了 OCI?Artifacts 项目来定义云原生制品(Cloud Native Artifacts)的规范。我们可以通过扩展 media-type 来定义一种新的 Artifacts 规范,并通过标准的镜像仓库来统一管理。

Kubernetes 时代的安全软件供应链

在之前章节也提到过,相对于传统软件的安全软件供应链管理,容器和 Kubernetes 的引入使得:

  • 发布和迭代更加频繁,容器的易变性也使得安全风险稍纵即逝;
  • 更多的不可控三方依赖,一旦一个底层基础镜像有了安全漏洞,会向病毒一样传递到上层;
  • 更大范围的全球快速分发,在分发过程中的攻击也会使得在末端执行的时造成大规模安全风险。

在传统的软件安全和安全准则之上,我们可以结合一些最佳实践,沉淀一个新的端到端安全软件供应链:

5.png

我们来看一些和安全软件供应链相关的社区技术进展:

Grafeas

2017 年 10 月,Google 联合 JFrog、IBM 等公司推出了 Grafeas。Grafeas(希腊语中的”scribe”)旨在定义统一的方式来审核和管理现代软件供应链,提供云原生制品的元数据管理能力。可以使用 Grafeas API 来存储,查询和检索有关各种软件组件的综合元数据,包括合规和风险状态。

6.png

In-toto

In-toto 提供了一个框架或策略引擎来保护软件供应链的完整性

通过验证链中的每个任务是否按计划执行(仅由授权人员执行)以及产品在运输过程中未被篡改来做到这一点。In-toto 要求项目所有者创建布局 (Layout)。布局列出了软件供应链的步骤 (Step) 顺序,以及授权执行这些步骤的工作人员。当工作人员执行跨步操作时,将收集有关所使用的命令和相关文件的信息,并将其存储在链接 (Link) 元数据文件中。通过在完整的供应链中定义每个 Step,并对 Step 进行验证,可以充分完整的完整整个供应链的安全。

Kritis

为强化 Kubernetes 的安全性,Google 引入了二进制授权 (Binary Authorization),确保使用者只能将受信任的工作负责部署到 Kubernetes 中。二进制授权可以基于 Kubernetes 的 Admission Controller 来插入部署准入检测,让只有授权后的镜像在环境中运作。

下图为一个策略示例:

7.png

同时对于在安全软件供应链中占比很大的第三方软件,需要有完善的基线机制和模糊安全测试机制来保障分发过程中的安全风险,避免带已知漏洞上线,阿里云正在与社区积极贡献帮助演进一些开源的工具链。

关于基础镜像优化、安全扫描、数字签名等领域也有非常多的工具和开源产品,在此不一一介绍。

云端的安全软件供应链最佳安全实践

在阿里云上,我们可以便捷地基于容器服务 ACK、容器镜像服务 ACR、云安全中心打造一个完整的安全软件供应链。

安全软件供应链全链路以云原生应用托管为始,以云原生应用分发为终,全链路可观测、可追踪、可自主设置。可以帮助安全需求高、业务多地域大规模部署的企业级客户,实现一次应用变更,全球化多场景自动交付,极大提升云原生应用交付的效率及安全性。

8.png

在云原生应用的安全托管阶段,容器镜像服务 ACR 支持容器镜像、Helm Chart 等云原生资产的直接上传托管;也支持从源代码(Github、Bitbucket、阿里云 Code、GitLab 来源)智能构建成容器镜像。在安全软件供应用链中,支持自动静态安全扫描并自定义配置安全阻断策略。一旦识别到静态应用中存在高危漏洞后,可自动阻断后续部署链路,通知客户失败的事件及相关漏洞报告。客户可基于漏洞报告中的修复建议,一键更新优化构建成新的镜像版本,再次触发自动安全扫描。

  • 在云原生应用的分发阶段,当安全漏洞扫描完成且应用无漏洞,应用将被自动同步分发至全球多地域。

由于使用了基于分层的调度、公网链路优化以及免公网入口开启的优化,云原生应用的全球同步效率,相比本地下载后再上传提升了 7 倍。云原生应用同步到全球多地域后,可以自动触发多场景的应用重新部署,支持在 ACK、ASK、ACK@Edge?集群中应用自动更新。针对集群内大规模节点分发场景,可以实现基于镜像快照的秒级分发,支持 3 秒 500 Pod 的镜像获取,实现业务在弹性场景下的极速更新。

  • 在云原生应用运行阶段,可实现基于云安全中心的应用运行时威胁检测与阻断,实时保障每个应用 Pod 的安全运行。

云安全中心基于云原生的部署能力,实现威胁的数据自动化采集、识别、分析、响应、处置和统一的安全管控。利用多日志关联和上下文分析方案,实时检测命令执行、代码执行、SQL 注入、数据泄露等风险,覆盖业务漏洞入侵场景。结合 K8s 日志和云平台操作日志实时进行行为审计和风险识别,实现容器服务和编排平台存在的容器逃逸、AK 泄露、未授权访问风险。

总结

随着云原生的不断发展,云原生应用也会在安全、交付、全球分发等领域持续演进。我们可以预见一个新的时代:越来越多的大型软件以积木的方式由全球开发者独立开发而最终合并组装。

点击下载《不一样的 双11 技术:阿里巴巴经济体云原生实践》

ban.jpg

 

本书亮点

  • 双11 超大规模 K8s 集群实践中,遇到的问题及解决方法详述
  • 云原生化最佳组合:Kubernetes+容器+神龙,实现核心系统 100% 上云的技术细节
  • 双 11 Service Mesh 超大规模落地解决方案

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

通用电气GE微服务实践:在容器中部署有状态应用

Portworx阅读(459)评论(0)

 

通用电气GE

 

通用电气GE,创立于1892年,是世界上最大的技术和服务跨国公司。自托马斯·爱迪生创建通用电气公司以来,业务遍及世界上100多个国家,拥有员工315,000人。

 

GE在航空,电力,运输,能源等行业具备丰富的产品线和运营经验。同时GE也通过数字化的方式帮助客户进行产品的运维,数据分析和改进。GE为此建立了自己的物联网数字化平台。

 

GE采用微服务架构并通过容器来运行有状态应用。为此,需要建立CSI(Container Storage Interface),GE尝试了一些办法,但是从使用上来说并不成熟,无法给平台的用户和合作伙伴,提供简单易操作的容器存储和数据管理方法。需要有一个能够同时运行无状态应用和有状态应用的基础层。

 

最终,GE选择了与Portworx携手,来建立CSI对容器存储和数据进行有效管理。

 

Portworx建立了物理存储之上的软件定义的存储抽象层,用户不需要思考具体在使用那种物理存储,也不需要知道承载应用的是哪朵公有云或者私有云。

在没有这样一个抽象层之前,用户需要手动的把物理存储卷来分配到某个容器上。传统的存储,都是通过虚拟机和操作系统来驱动存储的,对于容器来说则很不适用。因为容器通常被编排程序Orchestrator排程在多节点的环境下来运行。应用程序也不都是在单一的容器内运行。比如Cassandra, 通常是部署在一系列的容器上。一个Cassandra集群可能会有3个、10个、15个Cassandra容器,被部署在15个不同的虚拟机上,甚至可能在不同的物理数据中心里。所以当我们尝试把某个卷添加到这样一个分布式系统里的时候,就会出现非常多的问题。这些问题需要运维工程师花大量的时间来做调整,让卷与这样的分布式系统产生映射。假如说一个5节点的Cassandra集群,这些节点都运行在哪些虚拟机上呢?又是在哪个存储上呢?于是我们不得不把应用跟虚拟机对应起来,因为我们在使用虚拟机对应的存储资源。如果虚拟机停机了,我们就不得不去手动寻找相对应的存储,然后把它和新的虚拟机对应起来。这跟云原生的思想和容器排程器Orchestrator的定位并不对路。同时新的问题又会产生,如何在这样的分布式系统里为存储设定密码?如何做快照?这些问题都将留给我们的用户,这就更有问题了。

 

作为GE,我们并不想把这样的复杂的基础架构爬坑工作留给用户。

 

Portworx本身是一种基于容器的超融合架构,将计算资源与存储有机结合在一起。同时Portworx与K8S的调度软件scheduler无缝集成。

 

像数据库这样的有状态型容器化应用需要在分布式节点上的永久数据。Portworx使用有状态的Stateful Fabric来管理数据卷,即container-SLA-aware,来做到这一点。复制卷数据确保其状态,同时满足容器化应用的性能和可用性。更重要的是,Portworx可在每个容器级别中管理其快照、克隆副本和复制操作,使DevOps能够单独管理微服务,而不是像LUNs那用做传统存储系统的绑定组。使用Portworx管理有状态容器Stateful Containers很方便,每个容器级别的数据的可用性和管理也很简单,且高度自动化。

 

如果需要部署一个Cassandra集群,而又并不想让所有的节点在同一个环网上,在同一个Availability Zone或者Failure domain,Portworx可以帮助用户更好的来架构这些分布式的应用。另外通常我们希望物理资源能够有80%以上的利用率。我们需要让不同的应用在同一个硬件内共存,而不产生IO的冲突。Portworx并不是直接把存储或者物理的LUNs跟应用连接起来,我们提供一个虚拟的存储卷层来避免IO的冲突,并实现容器的加密或者是快照。尤其是当一个容器宕机,然后又从另外一个位置恢复后,我们就能够快速找到原来的存储,并且在新的容器中恢复。同时Portworx的安全与合规管理功能,帮助GE满足公司内部对于平台架构的安全合规要求,也满足了用户和客户的存储加密,存储快照这样的需求。

Service Mesh 是新瓶装旧酒吗?

alicloudnative阅读(300)评论(0)

本文节选自《不一样的 双11 技术:阿里巴巴经济体云原生实践》一书。

作者 | 李云(花名:至简) 阿里云高级技术专家

导读:在即将过去的 2019 年,Service Mesh 开源产品的成熟度虽在全球范围内没有发生质的变化,但在国内仍出现了一些值得特别关注的事件。比如:阿里巴巴在 双11 的部分电商核心应用上落地了完整的 Service Mesh 解决方案,借助 双11 的严苛业务场景完成了规模化落地前的初步技术验证。本文作者将结合自己在阿里巴巴落地实践 Service Mesh 过程中的观察与思考,来和大家进行分享。

Service Mesh 是新瓶装旧酒吗?

新技术出现时所主张的价值一定会引发相应的探讨,Service Mesh 也不例外。

以往,怀疑?Service Mesh 价值的观点主要有两大类。

  • 第一类是应用的数量并没有达到一定的规模,在?Service Mesh 增加运维和部署复杂度的情形下,认为所带来的成本和复杂度高于所获得的收益。

从根本上来看,这一类并非真正怀疑?Service Mesh 的价值,而是主张在?Service Mesh 还没有完全成熟和普及的情形下,在未来合适的时机再考虑采纳。当然,我在与外部客户交流时也碰到一些特例,他们即便在应用数很少的情形下,仍希望通过?Service
Mesh 去解决非?Java 编程语言(比方说?Go)的分布式链路追踪等服务治理问题,虽说这些能力在?Java 领域有相对成熟的解决方案,但在非?Java 领域确实偏少,所以很自然地想到了采用?Service Mesh。

  • 第二类怀疑?Service Mesh 价值的,是应用的数量具有相当的规模且对分布式应用的规模问题也有很好的认知,但由于在发展的过程中已经积累了与?Service Mesh 能力相当的那些(非体系化的)技术,造成初识?Service Mesh 时有“老酒换新瓶”的感觉而不认可其价值。阿里巴巴过去也曾属于这一阵营。

阿里巴巴在分布式应用的开发和治理方面的整体解决方案的探索有超过十年的历程,且探索过程持续地通过 双11 这样的严苛场景做检验和孵化,采用单一的?Java 语言打造了一整套的技术。即便如此,应对分布式应用的规模问题依然不轻松,体现于因为缺乏顶层设计而面临体系性不足,加之对技术产品自身的用户体验缺乏重视,最终导致运维成本和技术门槛都偏高。在面临这些阵痛之际,云原生的概念逐渐清晰地浮出了水面。

云原生主张技术产品在最为严苛的场景下仍能提供一定质量的服务而体现良好弹性,同时也强调技术产品本身应当具有良好的易用性,以及将来为企业需要多云和混合云的?IT?基础设施提供支撑(即:帮助实现分布式应用的可移植性)。

云原生的概念不仅很好地契合了阿里巴巴集团在技术发展上亟待解决的阵痛,也迎合了阿里巴巴将云计算作为集团战略、让云计算普惠社会的初衷。在这一背景下,阿里巴巴做出了全面云原生化的决定,Service Mesh 作为云原生概念中的关键技术之一,当然也包含在其中。

Service Mesh 给阿里巴巴带来的价值

Service Mesh 所带来的第一个变化体现于:服务治理手段从过去的框架思维向平台思维转变。

这种转变并非后者否定前者,而是前后者相结合去更好地发挥各自的优势。两种思维的最大区别在于,平台思维不仅能实现应用与技术基础设施更好的解耦,也能通过平台的聚集效应让体系化的顶层设计有生发之地。

框架思维向平台思维转变在执行上集中体现于“轻量化”和“下沉”两个动作。

  • 轻量化是指将那些易变的功能从框架的?SDK 中移出,结果是使用了?SDK 的应用变得更轻,免除了因易变功能持续升级所带来的低效;也彻底让应用的开发者无需关心这些功能,让他们能更好地聚焦于业务逻辑本身;
  • 从框架中移出的功能放到了?Service Mesh 的 Sidecar 中实现了功能下沉。

Service Mesh 作为平台性技术,将由云厂商去运维和提供相应的产品,通过开源所构建的全球事实标准一旦被所有云厂商采纳并实现产品化输出,那时应用的可移植性问题就能水到渠成地解决。

功能下沉在阿里巴巴落地?Service Mesh 的过程中也看到了相应的价值。阿里巴巴的电商核心应用基本上都是用?Java 构建的,在 Mesh 化之前,RPC 的服务发现与路由是在?SDK 中完成的,为了保证 双11 这样的流量洪峰场景下的消费者用户体验,会通过预案对服务地址的变更推送做降级,避免因为频繁推送而造成应用进程出现?Full GC。Mesh 化之后,SDK 的那些功能被放到了 Sidecar(开发语言是?C++)这一独立进程中,这使得?Java 应用进程完全不会出现类似场景下的?Full GC 问题。

软件设计的质量主要体现在“概念”和“关系”两个词上。

同样功能的一个系统,不同的概念塑造与切分将产生完全不同的设计成果,甚至影响到最终软件产品的工程质量与效率。当概念确定后,关系也随之确立,而关系的质量水平体现在解耦的程度上。Service Mesh 使得应用与技术基础设施之间的关系变得更松且稳定,通过流量无损的热升级方案,使得应用与技术基础设施的演进变得独立,从而加速各自的演进效率。软件不成熟、不完善并不可怕,可怕的是演进起来太慢、包袱太重。

阿里巴巴在落地?Service Mesh 的过程中,体会到了松耦合所带来的巨大工程价值。当应用被 Mesh 化后,接下来的技术基础设施的升级对之就透明了,之前因为升级工作所需的人力配合问题可以通过技术产品化的手段完全释放。另外,以往应用进程中包含了业务逻辑和基础技术的功能,不容易讲清楚各自对计算资源的消耗,Service Mesh 通过独立进程的方式让这一问题得以更好地隔离而实现量化,有了量化结果才能更好地对技术做优化。

Service Mesh 所带来的第二个变化在于:技术平台的建设从面向单一编程语言向面向多编程语言转变。

对于初创或小规模企业来说,业务应用的开发采用单一的编程语言具有明显优势,体现于因为个体掌握的技术栈相同而能带来良好的协作效率,但当企业的发展进入了多元化、跨领域、规模更大的更高阶段时,多编程语言的诉求就随之产生,对于阿里巴巴这样的云厂商来说更是如此(所提供的云产品不可能过度约束客户所使用的编程语言)。多编程语言诉求的背后是每种编程语言都有自己的优势和适用范围,需要发挥各自的优势去加速探索与创新。

从技术层面,这一转变意味着:

  • 第一,技术平台的能力需要尽可能地服务化,避免因为服务化不彻底而需要引入?SDK,进而带来多编程语言问题(即因为没有相应编程语言的?SDK 而无法使用该编程语言);
  • 第二,在无法规避?SDK 的情形下,让?SDK 变得足够的轻且功能稳定,降低平台化和多编程语言化的工程成本,支持多编程语言?SDK 最好的手段是采用?IDL。

从组织层面,这一转变意味着平台技术团队的人员技能需要多编程语言化。一个只有单一编程语言的团队是很难做好面向多编程语言的技术平台的,不只是因为视角单一,还因为无法“吃自己的狗食”而对多编程语言问题有切肤之痛。

Service Mesh 带来的发展机遇

在这两个变化之下,我们来聊一聊?Service Mesh?所带来的发展机遇。

  • 首先,Service Mesh?创造了一次以开发者为中心去打造面向未来的分布式应用开发平台的机会。

在?Service Mesh 出现之前,各种分布式服务治理技术产品的发展,缺乏强有力的抓手去横向拉通做体系化设计和完成能力复用,因而难免出现概念抽象不一致和重新造轮子的局面,最终每个技术产品有自己的一套概念和独立的运维控制台。当多个运维控制台交到开发者手上时,他们需要做大量的学习,去理解每个运维控制台的概念以及它们之间的关系,背后所带来的困难和低效是很容易被人忽视的。

本质上,Service Mesh 的出现是解决微服务软件架构之下那些藏在应用与应用之间的复杂度的。它的出现使得所有的分布式应用的治理问题被放到了一起去考虑。换句话说,因为?Service Mesh 的出现,我们有机会就分布式应用的治理做一次全局的设计,也有机会将各种技术产品整合到一起而避免重复建设的问题。

未来的分布式应用开发平台一定是基于?Service Mesh 这一基础技术的。为此,需要借这个契机从易用性的角度重新梳理应给开发者塑造的心智。易用性心智的确立,将使得开发者能在一个运维控制台上做最少的操作,通过为他们屏蔽背后的技术实现细节,而减轻他们在使用时的脑力负担,以及降低操作失误带来安全生产事故的可能性。

理论上,没有?Service Mesh 之前这些工作也能做,但因为没有具体的横向技术做抓手而无法落地。

  • 其次,Service Mesh?给其他技术产品创造了重新思考云原生时代的发展机会。

有了?Service Mesh 后,以前很多独立的技术产品(比如,服务注册中心、消息系统、配置中心)将变成?BaaS(Backend as a Service)服务,由?Service Mesh 的?Sidecar 负责与它们对接,应用对这些服务的访问通过?Sidecar 去完成,甚至有些?BaaS 服务被?Sidecar 终结而完全对应用无感。

这些变化并非弱化了那些?BaaS 服务的重要性。相反,因为其重要性而需要与?Service Mesh 做更好的整合去为应用提供服务,与此同时探索做一定的能力增强。比方说,Service Mesh 所支持的应用版本发布的灰度功能(包括蓝绿发布、金丝雀发布、A/B 测试),并非每一个?BaaS 服务在 Mesh 化后就能很好地支持这一功能,而是需要做相应的技术改造才行。请注意,这里主要讲的是应用的灰度能力,而非?BaaS?服务自身的灰度能力。当然,并不妨碍探索通过?Service Mesh 让?BaaS 服务自身的灰度工作变得简单且低风险。

未来很多技术产品的竞争优势将体现于它能否与?Service Mesh 形成无缝整合。

无缝整合的核心驱动力,源于用户对技术产品的易用性和应用可移植性的需要。基于这一认识,阿里巴巴正在将?RocketMQ/MetaQ 消息系统的客户端中的重逻辑剥离到?Envoy 这一?Sidecar 中(思路依然是“下沉”),同时基于?Service Mesh 所提供的能力做一定的技术改造,以便?RocketMQ/MetaQ 能很好地支撑应用的灰度发布。类似这样的思考与行动,相信未来会在更多的技术产品上出现。

  • 再次,Service Mesh?给技术基础设施如何与业务基础技术更好地协同提供了一次探索机会。

每一种业务(比如电商)都会构建基于所在领域的基础技术,这类技术我们称之为业务基础技术。当阿里巴巴希望将某一业务的基础技术搬到外部去服务客户时,面临业务基础技术如何通过服务化去满足客户已选择的、与业务基础技术不同的编程语言的问题,否则会出现基于 Java 构建的业务基础技术很难与 Go 所编写的应用协同。

在?Service Mesh 致力于解决服务化问题的过程中,能否通过一定的技术手段,让业务基础技术的能力通过插件的形式“长”在?Service Mesh 之上是一个很值得探索的点。当业务基础技术以插件的形式存在时,业务基础技术无需以独立的进程存在而取得更好的性能,且这一机制也能被不同的业务复用。阿里巴巴的?Service
Mesh 技术方案所采用的 Sidecar?开源软件 Envoy 正在积极地探索通过?Wasm 技术去实现流量处理的插件机制,将该机制进一步演变成为业务基础技术插件机制是值得探索的内容。

下图示例说明了业务基础技术的插件机制。

图中两个彩色分别代表了不同的业务(比如一个代表电商,另一个代表物流),两个业务的基础技术并非开发了两个独立的应用(进程)然后做发布和运维管理,而是基于 Wasm 所支持的编程语言实现了业务技术插件,这一点可以理解为用多编程语言的方式解决业务服务化问题,而非强制要求采用与 Sidecar 一样的编程语言。插件通过 Service Mesh 的运维平台进行管理,包含安装、灰度、升级、监控等能力。

至简.png

由于插件是“长”在 Service Mesh 之上的,插件化的过程就是业务技术服务化的过程。

另外,Service Mesh 需要提供一种选择能力,让业务的应用开发者或运维者选择自己的机器上需要哪些插件(可以理解为插件市场)。另一个值得关注的点是:插件的运维和管理能力以及一定的质量保证手段由 Service Mesh 平台提供,但运维、管理和质量保证的责任由各插件的提供者承担。这种划分将有效地杜绝所有插件的质量由 Service Mesh 平台去承担而带来的低效,分而治之仍是改善很多工程效率的良方。

  • 最后,Service Mesh 给探索面向未来的异地多活、应用永远在线的整体技术解决方案打开了一扇大门。

服务之间的互联互通,服务流量的控制、观测和安全加固是微服务软件架构下所要解决的关键问题,这些问题与规模化下的服务可用性和安全性紧密相关。未来,通过 Service Mesh 的流量控制能力能做很多改善应用发布和运维效率的文章,那时才能真正看到一个灵动、称手的云平台。

Service Mesh 的“三位一体”发展思路

阿里巴巴作为云计算技术的供应商,在探索 Service Mesh 技术的道路上,不只是考虑如何让云原生技术红利在阿里巴巴内部兑现,同时还思考着如何将技术红利带给更多的阿里云客户。基于此,阿里巴巴就 Service Mesh 的整体发展思路遵循“三位一体”,即阿里巴巴内部、阿里云上的相应商业产品和开源软件将采用同一套代码。

就我们与阿里云客户交流的经验来看,他们乐于尽最大可能采用非云厂商所特有的技术方案,以免被技术锁定而在未来的发展上出现掣肘。另外,他们只有采纳开源的事实标准软件才有可能达成企业的多云和混合云战略。基于客户的这一诉求,我们在 Service Mesh 的技术发展上特别重视参与开源事实标准的共建。在 Istio 和 Envoy 两个开源项目上,我们都会致力于将内部所做的那些优化反哺给开源社区。

未来,我们将在 Service Mesh 领域坚定而扎实地探索,也一定会将探索成果和思考持续地分享给大家。

点击下载《不一样的 双11 技术:阿里巴巴经济体云原生实践》

ban.jpg

本书亮点

  • 双11 超大规模 K8s 集群实践中,遇到的问题及解决方法详述
  • 云原生化最佳组合:Kubernetes+容器+神龙,实现核心系统 100% 上云的技术细节
  • 双 11 Service Mesh 超大规模落地解决方案

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

如何跨不同版本K8S,为有状态工作负载做蓝绿部署

Portworx阅读(465)评论(0)

容器的生态正在爆发!不仅仅应用层在快速变化,还有用于管理应用程序的平台:Kubernetes,也在快速变化。这就为Ops团队带来了一个必须要解决的难题。IT团队如何才能保证一款应用程序能够在各种不同版本的Kubernetes上都能良好运行呢?

PX-Motion演示:如何跨不同版本Kubernetes,为有状态的工作负载做蓝绿部署

蓝-绿部署是一种专门用于解决这一问题的技术,并能够降低生产环境部署的过程中的停机或错误风险。在蓝绿部署场景下,用户需要构建两个完全相同的生产环境(分别称为蓝与绿),这两个环境之间仅在需要部署的新的变更方面存在差异。每一次仅激活一个环境,两个环境之间的数据传输也是部署过程的一部分。该技术对于不含任何数据的无状态应用非常有效,但对于数据库这类有状态应用则存在一定的困难,因为用户不得不保留两份生产数据副本。这种情况下可能会需要使用Postgres、MySQL以及其他数据库备份和恢复脚本,或定制化操作手册或自动脚本等将数据从一个数据源人工移动到另一个数据源,这个过程将会非常复杂并且会耗费大量的时间。

Portworx采用PX-Motion解决了有状态应用程序的蓝绿部署过程中的数据管理问题。PX-Motion使IT团队能够很方便地在各种环境之间进行数据和应用配置的迁移,极大地简化了有状态应用的蓝绿部署。

本篇博文将对PX-Motion的功能与能力进行探讨。具体地说,笔者将展示如何对两个不同版本的Kubernetes上运行的有状态LAMP堆栈进行蓝绿部署。

总结来说,我们会:

1. ? 将两个Kubernetes集群(分别称为来源集群和目标集群)配对,从而使数据、配置和Pods能够这两个集群之间进行转移,这是蓝绿部署的一部分。

2. ? 使用Kubernetes将一个LAMP堆栈部署到来源集群上,并验证应用程序能够运行。

3. ? 使用PX-Motion可以将Kubernetes的部署、加密文件、副本集、服务、持久卷、持久卷连接以及数据等,从来源集群迁移到目标集群上进行测试和验证。在迁移完成之后,所有的Pods都能够在来源集群上继续运行。现在我们已经有了两个集群在运行,分别是蓝色和绿色。

4. ? 使用Kubernetes验证我们的应用以及自身数据是否正在目标集群上正常运行。

5. ? 在新集群上的部署验证完成之后,我们就可以更新我们的负载平衡设置,从而使所有的流量指向新集群。此时蓝绿部署就完成了。

我们开始吧!

安装PX-Motion

前提条件

如果你正在尝试PX-Migration,请确认已经满足所有的前提条件(https://docs.portworx.com/cloud-references/migration/migration-stork/#overview)。

配对Kubernetes集群为数据迁移做准备

从来源集群(Kubernetes 1.10.3)向目标集群(Kubernetes 1.12.0)进行工作载荷迁移之前,我们需要将这两个集群配对起来。配对的概念相当于将手机和蓝牙播放器进行配对,使两种不同的设备结合起来工作。

集群配对首先要做的是对目标集群进行配置。首先,建立对于pxctl?(“pixie-cuttle”)的访问,即Portworx CLI。下面将介绍如何在可被kubectl访问的工作站上使用pxctl。

$ kubectl config? use-context <destination-cluster>
$ PX_POD_DEST_CLUSTER=$(kubectl get pods --context
   <DESTINATION_CLUSTER_CONTEXT> -l name=portworx -n kube-system?
   -o jsonpath='{.items[0].metadata.name}')
$ alias pxctl_dst="kubectl exec $PX_POD_DEST_CLUSTER \
   --context <DESTINATION_CLUSTER_CONTEXT>
   -n kube-system /opt/pwx/bin/pxctl"

下一步,对目标集群对象存储进行设置,使其准备好与来源集群进行配对。我们需要在目标集群上设置一个对象存储端点,作为数据在迁移过程中进行分级的位置。

$ pxctl_dst -- volume create --size 100 objectstore
$?pxctl_dst -- objectstore create -v objectstore
$ pxctl_dst -- cluster token show
Token is <UUID>

下一步,创建一个集群配对YAML配置文档,从而对应到来源Kubernetes集群上。这个clusterpair.yaml(https://docs.portworx.com/cloud-references/migration/migration-stork/#overview)文档将包含如何与目标集群调度程序和Portworx存储进行验证的信息。运行如下命令并编辑YAML文档即可建立配对:

$ storkctl generate clusterpair --context <destination-cluster> > clusterpair.yaml

1.???说明:你可以用你自己的名称替换“metadata.name”。

2.???说明:在如下示例中,options.token可以使用通过上述“cluster tokenshow”命令生成的令牌。

3.???说明:在如下示例中,对于options.ip,将需要负载均衡器或Portworx节点的IP或者DNS,这样我们才能够访问9001和9010端口。

下一步,使用kubectl,将这个集群配对应用到来源集群上。

$ kubectl config use-context <source-cluster>
$ kubectl create -f clusterpair.yaml

在这种架构下,集群配对通过互联网(VPC至VPC)进行连接。这就需要确保我们的目标存储能够良好地与来源集群连接。?请参照如下说明。(https://docs.portworx.com/cloud-references/migration/)

1.???说明:这些步骤均是暂用措施,后续新版本的发布后将由自动化过程取代。

2.???说明:?? 云到云、本地环境到云、云到本地环境,都需要类似的步骤。

如果所有步骤均操作成功,则请使用storkctl列出集群配对,程序将显示存储调度程序Ready状态。如果显示Error,则请使用kubectl describe clusterpair,以获取更多信息。

$ storkctl get clusterpair
NAME????? STORAGE-STATUS?? SCHEDULER-STATUS?? CREATED
green???? Ready??????????? Ready????????????? 19 Nov 18 11:43 EST
$ kubectl describe clusterpair new-cluster | grep paired
? Normal? Ready?? 2m??? stork? Storage successfully paired
? Normal? Ready?? 2m??? stork? Scheduler successfully paired

pxctl也可以用于列出集群配对。

$ pxctl_src cluster pair list
CLUSTER-ID? NAME?????????????? ENDPOINT????????????????????? CREDENTIAL-ID
c604c669??? px-cluster-testing http://portworx-api.com:9001? a821b2e2-788f

我们的集群现在已经配对成功了。

在Kubernetes 1.12.0上测试工作负载

目前Kubernetes 1.10.3来源集群已经和1.12.0目标集群完成了配对,我们可以将运行的工作负载、配置以及数据从一个集群迁移到另一个集群上,来测试目标集群1.12.0Kubernetes上的应用程序是否能够正常运行。在迁移过程中及完成后,所有的Pods都将继续在来源集群上运行。我们现在有了两个集群,即蓝色和绿色,只在其运行的Kubernetes版本上存在差异。

$ kubectl config? use-context <1.10.3 source cluster context>

如果想要检查当前使用的Kubernetes版本,请运行kubectl version命令。这个命令能够输出当前的客户端和服务器版本。如下所示,服务器版本为1.10.3。

$ kubectl version --short | awk -Fv '/Server Version: / {print "Kubernetes Version: " $3}'
Kubernetes Version: 1.10.3-eks

在1.10.3上部署应用程序

在迁移工作负载时,我们需要一个来源集群上已经存在的工作负载。在演示中,我们将使用Heptio的示例LAMP堆栈在来源集群上创建一个LAMP堆栈(http://docs.heptio.com/content/tutorials/lamp.html),从而在MySQL卷上使用Portworx。这个堆栈包含了一个存储分类,包括Portworx、加密文件、HPH网页前端,以及一个具备Porworx卷副本的mySQL数据库。

$ kubectl create ns lamp???
??????????????????????????????????????????????????????????????????????????????????????????????
$ kubectl create -f . -n lamp
job.batch "mysql-data-loader-with-timeout" created
storageclass.storage.k8s.io "portworx-sc-repl3" created
persistentvolumeclaim "database" created
deployment.extensions "mysql" created
service "mysql" created
deployment.extensions "php-dbconnect" created
service "web" created
secret "mysql-credentials" created

使用kubectl对Pods进行检索,确保其处于Running状态下。

$ kubectl get po -n lamp
NAME?????????????????????????????????? READY???? STATUS??? RESTARTS?? AGE
mysql-6f95f464b8-2sq4v???????????????? 1/1?????? Running?? 0????????? 1m
mysql-data-loader-with-timeout-f2nwg?? 1/1?????? Running?? 0????????? 1m
php-dbconnect-6599c648-8wnvf??????? ???1/1?????? Running?? 0????????? 1m
php-dbconnect-6599c648-ckjqb?????????? 1/1?????? Running?? 0????????? 1m
php-dbconnect-6599c648-qv2dj?????????? 1/1?????? Running?? 0????????? 1m

提取Web服务。记录服务的CLUSTER-IP和EXTERNAL-IP。迁移完成后,这两个数据将会因为处于新的集群上而发生变化。

$ kubectl get svc web -n lamp -o wide
NAME????? TYPE?????????? CLUSTER-IP?????? EXTERNAL-IP??           PORT(S)??????AGE???SELECTOR
web?????? LoadBalancer?? 172.20.219.134?? abe7c37c.amazonaws.com??80:31958/TCP?15m???app=php-dbconnect

访问端点或使用curl确认WordPress已安装、运行正常且已连接至MySQL。

MySQL连接

$ curl -s abe7c37c.amazonaws.com/mysql-connect.php | jq
{
? "outcome": true
}

验证是否也为MySQL容器创建了PVC。如下我们将看到PVC、数据库,各有三个副本用于部署。这个卷是MySQL的ReadWriteOnce卷块。

$ kubectl get pvc -n lamp
NAME?????? STATUS??? VOLUME???????????????????????????????????? CAPACITY?? ACCESS MODES?? STORAGECLASS??????? AGE
database?? Bound???? pvc-c572277d-ec15-11e8-9f4d-12563b3068d4?? 2Gi??????? RWO??????????? portworx-sc-repl3?? 28m

卷信息也可以使用pxctl进行展示。Volume list命令的输出如下。

$ pxctl_src -- volume list
ID????????? ?????  NAME???????????????????????????????       SIZE? HA STATUS???????????????????????
618216855805459265?pvc-c572277d-ec15-11e8-9f4d-12563b3068d4? 2 GiB 3??attached on 10.0.3.145

将应用程序迁移至Kubernetes 1.12.0

对本地kubectl客户端进行配置,使其使用正在运行1.12.0的目标集群。

$ kubectl config use-context <1.12.0 destination cluster context>

运行kubectl Version命令,这个命令将输出当前的客户端和服务器版本,如下看到运行的1.12.0。

$ kubectl version --short | awk -Fv '/Server Version: / {print "Kubernetes Version: " $3}'
Kubernetes Version: 1.12.0

验证LAMP堆栈Pods是否正在运行中。如下所示,该集群的Namespace没有资源,即表示迁移还未发生。

$ kubectl get po
No resources found.

下一步,使用Stork客户端storkctl,创建一次迁移,将LAMP堆栈资源和卷从1.10.3集群迁移到1.12.0集群上。向storkctl create migration的命令的输入包括clusterPairnamespaces以及可选的includeResourcesstartApplications,从而将相关资源纳入并在迁移完成后启动应用程序。该命令的更多信息请点击这里(https://docs.portworx.com/cloud-references/migration/migration-stork/)。

$ storkctl --context <source-cluster-context> \
?? create migration test-app-on-1-12 \
?? --clusterPair green \
?? --namespaces lamp \
?? --includeResources \
?? --startApplications
Migration test-app-on-1-12 created successfully

迁移创建后,使用storkctl获取迁移状态。

$? storkctl --context <source-cluster-context> get migration
NAME?????????????? CLUSTERPAIR?? STAGE???? STATUS?????? VOLUMES?? RESOURCES?? CREATED
test-app-on-1-12?? green??? ?????Volumes?? InProgress?? 0/1?????? 0/7???????? 19 Nov 18 13:47 EST

pxctl也可以用于查看迁移状态。卷将显示出与迁移有关的STAGESTATUS

$ pxctl_src cloudmigrate status

CLUSTER UUID: 33293033-063c-4512-8394-d85d834b3716
TASK-ID????????????VOLUME-ID?? ?????       VOLUME-NAME?????? ??? ?????????????       STAGE     STATUS?????
85d3-lamp-database?618216855805459265????? pvc-c572277d-ec15-11e8-9f4d-12563b3068d4? Done????? Initialized

完成后,迁移将显示STAGE?→?Final和?STATUS?→?Successful

$ storkctl --context? <source-cluster-context> get migration

NAME?????????????? CLUSTERPAIR?? STAGE???? STATUS?????? VOLUMES?? RESOURCES?? CREATED
test-app-on-1-12?? green???????? Final???? Successful?? 1/1?????? 7/7???????? 19 Nov 18 13:47 EST

现在从目标集群中获得Pods。如下所示,PHP与MySQL现在都在目的集群上运行。

$ kubectl get po -n lamp
NAME??????????????????????????? READY???? STATUS??? RESTARTS?? AGE
mysql-66d895ff69-z49jl????????? 1/1 ??????Running?? 0????????? 11m
php-dbconnect-f756c7854-2fc2l?? 1/1?????? Running?? 0????????? 11m
php-dbconnect-f756c7854-c48x8?? 1/1?????? Running?? 0????????? 11m
php-dbconnect-f756c7854-h8tgh?? 1/1?????? Running?? 0????????? 11m

注意CLUSTER-IPEXTERNAL-IP现在已经发生了变化。这表示服务现在在新的Kubernetes 1.12集群上运行,并且因此包含了与此前不同的子网。

$? kubectl get svc web -n lamp -o wide
NAME????? TYPE?????????? CLUSTER-IP???? EXTERNAL-IP????????????PORT(S)???????AGE? SELECTOR
web?????? LoadBalancer?? 10.100.0.195?? aacdee.amazonaws.com?? 80:31958/TCP??12m ?app=php-dbconnect

如果网站能够在1.12.0集群上被访问、运行正常并且数据已经正确迁移到了1.12.0集群,则将会返回相同的输出内容。

Web网页前端

MySQL连接

$ curl -s http://aacdee.amazonaws.com//mysql-connect.php | jq
{
? "outcome": true
}

如下我们可以看到来源(下)和目标(上)集群上,kubectl get po -n lamp的输出。注意Pods的AGE,目的集群(上)中有最近迁移进来的LAMP堆栈。

两个集群在迁移后运行的是相同的程序和数据。

回顾整个过程:

1.???第一步,1.10.3 EKS集群与1.12.0集群配对。

2.???LAMP堆栈(Linux, Apache, MySQL, PHP)部署到1.10.3集群上。

3.???使用PX-Motion将Kubernetes部署、加密文件、副本集、服务、持久卷、持久卷连接,以及LAMP堆栈数据迁移到1.12.0集群上。

4.???应用程序在1.12.0集群上被访问,并验证其是否正确运行。

持久卷和连接都使用PX-Motion(https://docs.portworx.com/cloud-references/migration)在各个集群之间进行迁移,Kubernetes资源和副本都使用Portworx?Stork在目标集群上进行启动。

现在我们拥有了两个完全可运行的Kubernetes集群和两个环境,即蓝色和绿色部署环境。在实际操作中,你需要在绿色集群上进行所有测试,从而确保应用程序不会在新的集群上发生预期之外的问题。确认测试完成之后,将负载均衡从蓝色集群切换至新的绿色集群,此时部署就完成了!

结论

PX-Motion具有将Portworx卷和Kubernetes资源在集群之间进行迁移的能力。上述样例就是使用PX-Motion帮助团队实现蓝绿部署的过程:对其工作负载和数据在新版本的Kubernetes上进行测试,并帮助团队在新的绿色集群上运行应用程序。在不同版本的Kubernetes上进行真实负载和数据测试,使得运营团队能够在发布新版本的Kubernetes之前获得充足的信心。蓝绿部署并不是PX-Motion唯一的功能,请查看我们其他的PX-Motion博文了解更多。

K8S数据迁移方法

Portworx阅读(724)评论(0)

Kubernetes改变了我们所有人对计算平台的看法。我们同样也需要改变现代应用程序存储数据的方式。企业越来越多地依赖数字服务来接触客户,传统企业正在Kubernetes上重新部署它们的IT应用和服务。容器的可移植性和Kubernetes自动化的好处意味着在整个IT开发/测试和生产生命周期中我们可以更快、更可靠地交付应用程序。与此同时,企业必须认识到多云部署不仅仅是一种供应策略,而且还是一种对客户最合理的应用程序交付方式。

传统的存储行业还没有做好足够的工作来解决K8S的问题:容器可移植性、K8S自动化和多云交付。Portworx企业版首先为K8S中大数据量的工作负载提供无缝的高可用性,无论这些工作负载是在本地系统还是在公共云中运行,都将提供无缝的高可用性。通过Portworx,开发团队可以获得集成调度程序、完整的数据生命周期管理,以及核心生产功能,如BYOK加密和云备份。

通过与那些已经把应用部署在主要的公有云平台或自有硬件平台上的优秀客户合作,Portworx已经掌握了完整的数据可迁移性、操作自动化、以及将含有大量数据的应用交付到多云部署中的真正能力。

可迁移性和易操作性

通过控制与K8S的集成方式,PX-Motion为大量数据型工作负载带来了充分的可迁移性。现在,类似Kubernetes为无状态工作负载带来的方便一样,我们在有状态工作负载上为客户的数据库、分析堆栈、机器学习和其他类型的应用提供数据服务。只需一个命令,PX-Motion就可以跨集群和跨云移动K8S应用程序、Kubernetes配置和Portworx数据卷。
PX-Motion的功能有:
  • 扩展容量:将较低优先级的应用程序转移到次要集群,为关键集群释放容量。
  • 蓝绿部署:通过应用程序和数据来测试新版本的Kubernetes和Portworx。这一方法同云原生应用程序团队使用蓝绿部署法相同——现在你也可以将它用于您的容器基础架构。
  • 清洁安装:从Kubernetes到Portworx的每一个基础架构安装都是全新安装,而不是就地升级。无论是本地部署还是在公有云中,全新安装提供了一种更稳定的基础架构。
  • Dev/test:以自动化的方式将工作负荷从dev升级到分段集群。因此,它消除了人工准备数据的过程(这些步骤会影响测试准确性)。
  • 迁移:将应用程序和数据从本地部署集群迁移到AWS、谷歌、Azure、IBM或其他地方的云托管Kubernetes集群。同时反过来也支持。
  • 维护:它可在几分钟内迁移整个集群的应用程序和数据,以方便执行硬件的维护服务。

PX-Motion支持跨集群和云迁移,而PX-Central提供了必要的可视性操作界面来管理和控制数据的迁移。管理员和应用程序团队可以在每个应用程序级别上可视化的调度、控制正在进行的迁移的应用状态。

不仅如此,PX-Central还从根本上简化了对量数据工作负荷的管理。通过使用PX-Central,客户可以跨越多个集群或云,来管理、监视和元数据服务。

PX-Central的主要功能有:

  • 多集群管理GUI:为您的所有容器数据需求(包括跟踪容量、配置和监视)提供统一的管理界面。
  • 集中配置和调度:简单设置即可完成关键数据保护机制,包括使用PX-企业版 CloudSnap?完成快照和云中备份。
  • 内置元数据服务:在使用PX-企业版时,消除了客户自己处理etcd服务的繁琐,并使集群更加易于管理。
  • 主动监控:已经为跟踪和分析指标、警报和异常进行了配置,让团队在规模化配置上更有效地操作。

点击鼠标即可完成的K8S企业级备份: PX-Backup & PX-Autopilot

Portworx阅读(1112)评论(0)

Portworx,容器存储与数据管理专业解决方案提供商,对其行业领先的容器原生存储解决方案Portworx Enterprise进行了更新,使其企业用户能够在Kubernetes上对关键应用程序进行扩展、备份和恢复。PX-Backup和PX-Autopilot均用于实现存储容量管理。Portworx通过PX-Backup进入企业级备份市场,使企业用户能够方便而安全地对其所有的Kubernetes应用备份进行云原生方式的管理。PX-Backup在容器领域内的独特性在于它支持使用单个命令进行单个Pod、多个Pod以及整个Kubernetes NameSpace的备份,即便企业使用的是Microsoft Azure、AWS或谷歌存储。
此外,用于进行存储容量管理的PX-Autopilot还使企业能够采用智能化的方式管理存储,仅在需要时扩充容量,从而削减50%的云端存储成本,消除长期以来的云端存储在配置时即收费,而非使用时才收费的问题。
在企业认识到云原生技术对于其数字化转型的巨大作用之后,容器技术被更加广泛的使用。Gartner预测认为,到2022年,超过20%的企业存储容量都将用于支持容器工作负载,而这一数字现在还未达到1%。这样一来,企业就需要容器原生存储平台来解决Kubernetes上运行容器应用中的各种问题。此次更新奠定了Portworx的行业领先地位:唯一的容器原生存储与数据管理全面能力供应商:为Kubernetes上运行的容器应用程序提供快速、可扩展的容器存储,自动化容量管理,备份与恢复,容灾,多云迁移,以及数据安全服务
“企业的数字化转型是由容器和Kubernetes等技术不断推动的。这些技术能够帮助团队快速向用户和客户提供更好的服务,”Portworx首席技术官Gou Rao说,“利用这些新功能,我们正在不断努力实现全栈支持,使用户能够在Kubernetes上运行含有大量数据的应用程序,从而帮助企业实现其转型目标,同时节省成本并满足合规要求。”
PX-Backup

今年早些时候Portworx发布了PX-DR,行业内第一款针对Kubernetes应用的容灾恢复服务。虽然并不是每一个应用程序都需要容灾恢复(DR),但基于市场调查机构451 Research的研究表明,即便对于非关键应用和数据,53%的公司都设定了24小时内恢复数据的RPO目标,因此数据备份对于所有企业的应用程序至关重要。为解决这个问题,Portworx发布了PX-Backup,这是一款针对Kubernetes应用程序的点击式备份与恢复服务。在得到了PX-Backup的扩充之后,Portworx Enterprise的企业用户已经能够对Kubernetes上运行的所有含有大量数据的应用程序进行管理、保障以及备份。
PX-Backup能够捕捉应用程序数据、配置以及Kubernetes对象并将其作为一个单元,使用户能够将关键性的数据存储在任意的S3-兼容的对象存储器中。备份完成后,Kubernetes应用程序就可以通过重新运行Kubernetes部署文件的方式进行恢复和重新部署。此外,PX-Backup还能够对备份中的大量数据进行捕捉,使企业能够回答备份负责人、备份内容、备份时间、备份地点、备份时长等规定与管理方面的重要问题。
其他功能还包括:
  • 这是首次,正在使用云端存储的企业,虽然尚未使用Portworx Enterprise,也可以使用这款为Kubernetes应用程序打造的备份服务PX-Backup。比如企业正在使用类似Microsoft Azure ? ? ?Managed Disks、Amazon Web Services EBS以及 Google Persistent Disks。
  • Portworx的备份服务甚至可以为Cassandra、Kafka、Elasticsearch以及MongoDB等多节点分布式数据库进行备份,而其他备份服务方式,要达到这样的目标,则需要面临数据损坏的风险
  • 备份的数据可以发送至任何S3-兼容的对象存储器,使备份能够在单独的云或数据中心进行存储和恢复,也可以进行跨云和数据中心的存储和恢复。
PX-Autopilot?实现存储容量管理

Kubernetes能够实现应用程序部署的自动化,但企业也必须能够使其下层基础架构实现自动化,才能确保有足够的计算力和存储来扩展应用。虽然企业在云端获得了按使用量付费的模式,但实际上,企业都是通过过度部署存储空间的方式(通常超出2-3倍),来应对难以衡量Kubernetes上运行的数据服务的存储容量的问题。这意味着他们要为未被使用的存储付费。PX-Autopilot使企业能够通过自动检测存储容量,并在需要的时候才扩充容量的方式节省空间,降低存储费用。PX-Autopilot能够按用户定义的规则,对单个容器的容量或整个存储集群的容量进行扩充。如果不使用PX-Autopilot,则在通常客户使用的企业环境下,采用多步操作过程扩充存储空间将需要花费平台管理员将近20小时的时间。