首页 文章 精选 留言 我的

精选列表

搜索[运维],共10000篇文章
优秀的个人博客,低调大师

从传统运维到云运维演进历程之软件定义存储(四)

前面系列已经讲完了硬件选型、部署、调优,在上线之前呢需要进行性能存储测试,本章主要讲述下测试Ceph的几种常用工具,以及测试方法。 关卡四:性能测试关卡 难度:四颗星 说起存储性能永远是第一重要的问题。关于性能有以下几个指标:带宽(Bandwidth)、IOPS、顺序(Sequential)读写、随机(Random)读写、延迟(latency)、持续吞吐(Sustained Throughput)、突发处理能力(Burst I/O)等等。 1、iops&latency 这是两个衡量存储性能最基本的概念。IOPS (Input/Output Per Second)即每秒的输入输出量(或读写次数),是衡量存储性能的主要指标之一。IOPS是指单位时间内系统能处理的I/O请求数量,一般以每秒处理的I/O请求数量为单位,I/O请求通常为读或写数据操作请求。另一个重要的性能指标是延迟(等待时间),延迟度量系统运行状况及系统资源可用性,延迟取决于队列。存储系统类似于杂货店收银台排队,每个组件都有确定的性能最大值,系统趋近最大性能会增加延迟。延迟小于10毫秒的目标并非偶然,很多应用系统甚至对延迟更敏感。 2、影响性能的因素 传统存储的封闭特性带来的优势是从存储操作系统软件到专用硬件的深度优化,而软件定义存储、Server SAN的目的是软件和硬件的解耦合,它们带来了灵活性,免除了硬件厂商锁定,但很多时候却不能充分发挥硬件的潜力,给客户造成投资浪费。在分布式Server SAN的环境下,用户不能直接的把部件的性能做简单的加法,就得到整个存储的性能,其原因来自于集群和网络带来的复杂性,也来自于通用操作系统内核(如Linux)对NVMe SSD和万兆以上网络的处理机制不够优化,导致超强的硬件部件性能无法“吐出去”,或者“吐出去”对CPU等核心部件的资源消耗太大,要求过高。同时,由于网络交互在分布式存储中的引入,给存储的整体“时延(latency)”特性带来了挑战,很多分布式存储系统因没有恒定的低时延无法满足高实时性数据库等应用的需求。 利用FIO测试Ceph 硬盘的性能是可以估算出来的,但是怎么才能让应用获得这些性能呢?对于测试工具来说,就是如何得到IOPS、吞吐量和延迟。 FIO简介: fio 是一个 I/O 工具用来对硬件进行压力测试和验证,支持13种不同的I/O引擎,包括:sync, mmap, libaio, posixaio, SG v3, splice, null, network, syslet, guasi, solarisaio 等等, I/O priorities (for newer Linux kernels), rate I/O, forked or threaded jobs, 等等。它可以对块设备以及文件系统进行性能测试,通过接收一份简单的文本文件来理解工作描述来,结果会显示各种I/O性能信息。该工具在很多地方广泛使用,用来测试性能基准,稳定性验证。它支持Linux,FreeBSD,NetBSD,OS X,OpenSolaris,AIX和Windows。 FIO安装: 1、确保libaio引擎已安装,yum install libaio-devel 2、https://pkgs.org/download/fio 下载fio工具RPM包 3、安装 rpm -ivhfio-2.2.8-2.el7.x86_64.rpm 常用参数说明: filename:指定文件(设备)的名称。可以通过冒号分割同时指定多个文件,如filename=/dev/sda:/dev/sdb。 directory:设置filename的路径前缀。在后面的基准测试中,采用这种方式来指定设备。 name:指定job的名字,在命令行中表示新启动一个job。 direct: bool类型,如果设置成true (1),表示不使用io buffer。 ioengine: I/O引擎,现在fio支持19种ioengine。默认值是sync同步阻塞I/O,libaio是Linux的native异步I/O。关于同步异步,阻塞和非阻塞模型。可以参考文章“使用异步I/O大大提高应用程序的性能”。http://www.ibm.com/developerworks/cn/linux/l-async/ iodepth:如果ioengine采用异步方式,该参数表示一批提交保持的io单元数。该参数可参考文章“Fio压测工具和io队列深度理解和误区”。http://blog.yufeng.info/archives/2104 rw: I/O模式,随机读写,顺序读写等等。 bs: I/O block大小,默认是4k。 size:指定job处理的文件的大小。 numjobs:指定job的克隆数(线程)。 time_based:如果在runtime指定的时间还没到时文件就被读写完成,将继续重复知道runtime时间结束。 runtime:指定在多少秒后停止进程。如果未指定该参数,fio将执行至指定的文件读写完全完成。 group_reporting:当同时指定了numjobs了时,输出结果按组显示。 测试方式: 有两种测试方式1.配置文件、2.命令行,这里是讲述下命令行操作。 # fio -filename=/dev/sdx -iodepth=1 -numjobs=1 -thread -rw=randwrite -bs=4k -ioengine=libaio -group_reporting -name=mytest -randrepeat=0 -time_based -runtime=300 -direct=1 上面这种是基于挂载块设备进行测试的,下面讲述下如何使用fio直接测试RBD块。 # fio -direct=1 -iodepth=12 -rw=rw – ioengine=rbd -bs=4k -group_reporting -name=test -numjobs=4 -runtime=600 -clientname=admin -pool=pool-f61ba147fd61441ab272ae96b09e4ee0 -rbdname=volume-fd8f04986a33465d9908f3f97500961b 注意: 其中ioengine更换为rbdI/O引擎,需要在pool参数中指定卷设备所在的存储池ID,rbdname参数需要指定rbd设备的ID 以上命令均为举例,现实测试中可以根据实际情况调整iodepth、numjobs、bs大小参数来增加I/O压力,以获得更加性能。 测试指标: 顺序读写(吞吐量,常用单位为MB/s):文件在硬盘上存储位置是连续的。 适用场景:大文件拷贝(比如视频音乐)。速度即使很高,对数据库性能也没有参考价值。 4K随机读写(IOPS,常用单位为次):在硬盘上随机位置读写数据,每次4KB。 适用场景:操作系统运行、软件运行、数据库。 测试结果关注点: 对于一些新手来说不知道FIO测试出来之后应该关注哪些结果是有价值的,最基本的关注是带宽(bw)和iops,其次关注响应时间(clat)和磁盘利用率(util)。详细介绍可参考荣泽的博客。http://way4ever.com/?p=465 利用Cosbench来测试Ceph Cosbench是Intel的开源云存储性能测试软件,Cosbench目前已经广泛使用与云存储测试,并作为云存储的基准测试工具使用,Cosbench可在windows和linux两种系统中运行,而为了更好的发挥硬件和系统的能力,建议在使用Cosbench进行测试时,选择linux系统。 Cosbench是一个分布式的基准测试工具,测试云对象存储系统,目前为止它支持一些云对象存储系统的测试,Cosbench也允许用户创建额外的存储系统适配器。 1.cosbench安装: 安装Java SDK # yum install java-1.7.0-openjdk # yum install -y nc java-1.7.0-openjdk 安装curl软件 # yum install curl #yum install nmap-ncat 安装COSBench软件 从https://github.com/intel-cloud/cosbench/releases下载安装文件 # cd 0.4.2.c3 给予权限执行权限 # chmod a+x *.sh 启动COSbench # ./start-all.sh 出现如下证明安装成功 Successfully started cosbench controller! Listening on port 0.0.0.0/0.0.0.0:19089 … Persistence bundle starting… Persistence bundle started. ———————————————- !!! Service will listen on web port: 19088 !!! ———————————————- 2.使用Cosbench进行测试 注意:该测试说明基于ceph对象存储测试 编辑wokload 文件 可以参照0.4.2.c3/conf目录下的s3-config-sample.xml配置文件,在这里注意将之前在CEPH中分配的RGW用户的AK,SK,已经RGW启用的cvitweb域名端口设置正确:<storage type=”s3″ config=”accesskey=HX1XZCKWT6RDC8GA96AI;secretkey=j0RR17r0yx5jsszstHCTl8bY1usJ4fs1mUJNw8BC;proxyhost=;proxyport=;endpoint=http://192.168.182.128:80” />提交workload执行测试 通过以下链接访问COSBench–Controller Web Console http://:19088/controller/index.html 界面显示 点击submit new workloads 提交workloads文件; 选择文件后,点击提交; 提交成功后,点击view details ,查看详细信息。 workloads xml文件示例:2个节点的3个网关write.xml 说明: 1、该文件中可以更改<work>: name:名字 不能重复,重复会产生重复数据 works:进程 totalOps:对象总个数 cprefix:桶名的前缀 oprefix:对象名前缀 containers:桶的个数 objects:每个work写入的对象个数 sizes:写入对象的大小 endpoint:存储网关 2、若read,则需要改operation里的type为read,即可; 3、多个work,size大小同时写的话,压力会大。 注意:1. xml配置文件中网关地址格式为http://<网关IP>:<端口号> 2.小于64K的文件会往索引池中写 3.在Cosbench 上换算是按照1000算的。例如:若你写4096KB就是4096X1000=4096000,这个就算小文件。正常4M=4194304B 至此Ceph的硬件选型、部署、调优、性能测试等关卡已经讲述完毕,希望本关卡能够给予Ceph新手参考。想要知道葡萄酸不酸,最好的办法就是亲自尝一尝,俗话说:适合自己的才是最好的。对于存储也一样,只有在用户需要的配置方式下,在实际的生产应用系统中,实实在在的运行之后,用户才能真正清楚的感知存储设备的真实性能表现。请读者见仁见智,预知后事如何,请期待《 架构灾备设计》。 本文转自Devin 51CTO博客,原文链接:http://blog.51cto.com/devingeng/1863344

优秀的个人博客,低调大师

从传统运维到云运维演进历程之软件定义存储(五)上

数据资料是整个系统运作的核心,而人为或非人为引起的数据丢失将对的企业造成无法估量的影响。因此系统管理员都会考虑通过数据备份手段对业务数据进行保护。但在现在云数据中心的兴起带来的是海量数据被集中起来。相较于传统备份行业常见的小容量(小于500GB)RTO、RPO敏感型场景,在云数据中心带来的挑战下完全无法作到有效保护。 关卡五:PB级数据中心灾备设计关卡上 画难度:四颗星 传统的备份方式通常面向应用来做保护,依靠代理来调用应用端的接口。数据一致性能得到完全的保证。但传统备份由于要建立索引表,面对海量小文件时或者是云计算中心的PB级数据量时无论是备份速度还是存储效率都及其有限。而且从安全性的角度来说,仅仅通过在数据的生产端做到数据的备份尚无法为客户也提供有效保护。对于一些关键业务系统(比如:网上交易系统、医疗数据)而言,数据资料是整个系统运作的核心。一旦由于系统硬件的功能失效,存储介质的老化损坏,人为的错误操作,以及各种难以预料的外界因素导致数据意外丢失或损坏,那么将会对于业务造成无法估量的影响。为避免这种情况,一般通过在本地异地都一份完全副本来做到数据的有效恢复或数据的实时可用。 本文简单的讲述下常见的数据保护方式,具体详情可以在网上查询了解,这里不再赘述。下篇文章中会主要讲到在存储底层Ceph端常见的灾备架构设计。 常见的保护方式方式有以下几种: 1、基于存储级的数据保护。 传统存储的数据保护,一般有两种方式:一、异步复制,通过快照传递快照间数据的变量。这种方式的好处在于能有效节约带宽,且不需要在上层业务平台安装额外软件或对上层的业务系统照成任何压力。二、实时复制,利用存储自身功能对写入数据做到分流。相对于异步复制来说除了对带宽的要求较高,无论RPO或RTO都大大提高。 不过一般来说,传统存储厂家大部分都将这种存储功能类软件作为利润池单独售卖,且各存储品牌间甚至是同一家存储品牌不同代间完全无法做到存储级的远程保护。 2、基于应用的数据保护。 除了存储级的复制,一些厂家另辟蹊径通过在主机层面在驱动层之上做到写数据的分流。依照这种方法,有效避免了存储端的兼容性问题且大大节约了部署成本。但是这种方式需要在主机层面安装一套数据分离软件,所以对操作系统的兼容性有一定限制(暂时市场上此类软件仅仅兼容Windows和少数Linux版本)。而采用基于主机的数据分离,对主机的CPU、内存都会造成较大压力,在极端业务负载下,会照成业务平台死锁。从安全性上看还有一定隐患。 3、基于存储网关的数据保护。 现在最流行的存储双活方式有两家的数据保护方案最为有名,分别是IBM公司的SVC解决方案以及EMC公司的Vplex解决方案(具体的方案特点在此不做详述)。这种方案的好处就是利用存储虚拟化网关,将不同品牌的存储作为池化,利用存储网关做到数据分离。可以在多地间依据企业需求做到数据的实时或者异步的保护。 但是缺点同样显而易见,及存储网关作为一个总的数据流量出入口本身就可能成为一个瓶颈!且受限于商业策略和技术路线,从成本上(基本上都是几十万级)或者从设备的广泛兼容上看(虽说各家虚拟化网关厂家都说可以做到节点平滑扩展,但最大节点数一直都在16节点以内;且都需要保持同型同代产品)都有很大限制。 4、基于备份软件的远程复制。 部分备份软件利用自身私有协议,将在本地的备份数据远程同步到远端的备份节点上。 这种方式有效做到了带宽的有效利用和数据的高一至性。但是缺点也非常明显,既无法做到业务的实时可用。 综上所述,没有任何一种类型的数据灾备能适用于所有业务场景。 系统管理员还是需要依据自身业务特点来选择最适合于自己的数据保护方案。 本文简单的讲述下常见的数据保护方式,在下篇文章中会讲到在存储底层Ceph端常见的灾备架构设计,希望本文能够给予新手参考和了解。请读者见仁见智,预知后事如何,请期待《 架构灾备设计 下》。 本文转自Devin 51CTO博客,原文链接:http://blog.51cto.com/devingeng/1884394

优秀的个人博客,低调大师

OpenKruise:解放 DaemonSet 运维之路

简介: 我们希望 OpenKruise 让每一位 Kubernetes 开发者和阿里云上的用户都能便捷地使用上阿里巴巴内部云原生应用所统一使用的部署发布能力! 作者| 王思宇(酒祝) 前言 OpenKruise是阿里云开源的大规模应用自动化管理引擎,在功能上对标了 Kubernetes 原生的 Deployment/StatefulSet 等控制器,但 OpenKruise 提供了更多的增强功能,如:优雅原地升级、发布优先级/打散策略、多可用区 workload 抽象管理、统一 sidecar 容器注入管理等,都是经历了阿里巴巴超大规模应用场景打磨出的核心能力。这些 feature 帮助我们应对更加多样化的部署环境和需求、为集群维护者和应用开发者带来更加灵活的部署发布组合策略。 目前在阿里巴巴内部云原生环境中,应用全部统一使用 OpenKruise 的能力做 Pod 部署、发布管理,而不少业界公司和阿里云上的客户由于 K8s 原生 Deployment 等负载不能完全满足需求,也转而采用 OpenKruise 作为应用部署载体。我们希望 OpenKruise 让每一位 Kubernetes 开发者和阿里云上的用户都能便捷地使用上阿里巴巴内部云原生应用所统一使用的部署发布能力! 背景 如何在 Kubernetes 集群中部署节点组件呢?相信大家对 DaemonSet 并不陌生,它能够帮助我们将定义好的 Pod 部署到所有符合条件的 Node 上,这大大减轻了过去我们维护节点上各类守护进程的痛苦。 在阿里巴巴内部的云原生环境中,存在不少网络、存储、GPU、监控等等相关的节点组件都是通过 DaemonSet 部署管理的。但是随着近两年 Kubernetes 集群规模越来越大,所有核心业务逐渐全量上云原生之后,我们越发感受到原生 DaemonSet 很难满足大规模、高可用的复杂场景需求。 大家可以理解为原生的 DaemonSet 确实解决了 0 -> 1 的问题,避免了直接管理 Node 上各类软件包和守护进程的难题,能做到用一致化的 Pod 来部署节点组件。但是在部署之后呢?我们面临的是 1 -> N 的不断迭代升级的问题了,而在升级能力方面,原生 DaemonSet 做的实在有些敷衍了事的感觉。 apiVersion: apps/v1 kind: DaemonSet spec: updateStrategy: type: RollingUpdate rollingUpdate: maxUnavailable: 2 # ... apiVersion: apps/v1 kind: DaemonSet spec: updateStrategy: type: OnDelete # ... 以上是原生 DaemonSet 支持的两种升级方式。相信多数人使用 DaemonSet 基本都是默认的 RollingUpdate 滚动升级,这本身是没问题的,问题就在于滚动升级时只支持了 maxUnavailable 一个策略,这就让我们很难接受了。目前阿里巴巴内的 Kubernetes 不少已经做到单集群上万节点,这些节点可能有不同的机型、拓扑、核心程度、内核版本等等,而 DaemonSet 升级也覆盖到这上万节点上的 daemon Pod、涉及所有节点上的应用 Pod。 面对如此复杂和规模化的环境,原生 DaemonSet 没有灰度、没有分批、没有暂停、没有优先级,仅仅用一个 maxUnavailable 策略显然是无法满足的。要知道 daemon Pod 即使配置了 readinessProbe 往往也只能检查容器内进程是否启动运行,而对于进程的运行情况很难考量。 因此,即使 DaemonSet 发布了一个代码有 bug 的版本,只要进程能正常启动则 maxUnavailable 策略就无法保护,DaemonSet 会一直发布下去;如果升级开始了一段时间后才发现问题,那此时很可能故障范围就已经覆盖到整个集群了。 为了避免这个问题,我们曾经一度改为使用 OnDelete 策略、在发布平台上控制发布顺序和分批,但终态上我们还是希望将 workload 的能力下沉归还到 workload,形成闭环,避免将完整的能力分散到多个模块。因此随着 OpenKruise 的成熟和在阿里内外的铺开,我们总结了内部对 DaemonSet 的通用化发布需求、将其沉淀到 OpenKruise 中,称之为 Advanced DaemonSet。 目前阿里巴巴和蚂蚁集团内部的大部分 DaemonSet 都已经统一到 Advanced DaemonSet 部署管理,并且随着 OpenKruise v0.6.0 版本的推出之后,外部一些公司如位于以色列的 Bringg 都已经开始对接使用。 能力解析 Advanced DaemonSet 中主要增加的 API 字段如下: const ( + // StandardRollingUpdateType replace the old daemons by new ones using rolling update i.e replace them on each node one after the other. + // this is the default type for RollingUpdate. + StandardRollingUpdateType RollingUpdateType = "Standard" + // SurgingRollingUpdateType replaces the old daemons by new ones using rolling update i.e replace them on each node one + // after the other, creating the new pod and then killing the old one. + SurgingRollingUpdateType RollingUpdateType = "Surging" ) // Spec to control the desired behavior of daemon set rolling update. type RollingUpdateDaemonSet struct { + // Type is to specify which kind of rollingUpdate. + Type RollingUpdateType `json:"rollingUpdateType,omitempty" protobuf:"bytes,1,opt,name=rollingUpdateType"` // ... MaxUnavailable *intstr.IntOrString `json:"maxUnavailable,omitempty" protobuf:"bytes,2,opt,name=maxUnavailable"` + // A label query over nodes that are managed by the daemon set RollingUpdate. + // Must match in order to be controlled. + // It must match the node's labels. + Selector *metav1.LabelSelector `json:"selector,omitempty" protobuf:"bytes,3,opt,name=selector"` + // The number of DaemonSet pods remained to be old version. + // Default value is 0. + // Maximum value is status.DesiredNumberScheduled, which means no pod will be updated. + // +optional + Partition *int32 `json:"partition,omitempty" protobuf:"varint,4,opt,name=partition"` + // Indicates that the daemon set is paused and will not be processed by the + // daemon set controller. + // +optional + Paused *bool `json:"paused,omitempty" protobuf:"varint,5,opt,name=paused"` + // Only when type=SurgingRollingUpdateType, it works. + // The maximum number of DaemonSet pods that can be scheduled above the desired number of pods + // during the update. Value can be an absolute number (ex: 5) or a percentage of the total number + // of DaemonSet pods at the start of the update (ex: 10%). The absolute number is calculated from + // the percentage by rounding up. This cannot be 0. The default value is 1. Example: when this is + // set to 30%, at most 30% of the total number of nodes that should be running the daemon pod + // (i.e. status.desiredNumberScheduled) can have 2 pods running at any given time. The update + // starts by starting replacements for at most 30% of those DaemonSet pods. Once the new pods are + // available it then stops the existing pods before proceeding onto other DaemonSet pods, thus + // ensuring that at most 130% of the desired final number of DaemonSet pods are running at all + // times during the update. + // +optional + MaxSurge *intstr.IntOrString `json:"maxSurge,omitempty" protobuf:"bytes,7,opt,name=maxSurge"` } type DaemonSetSpec struct { // ... + // BurstReplicas is a rate limiter for booting pods on a lot of pods. + // The default value is 250 + BurstReplicas *intstr.IntOrString `json:"burstReplicas,omitempty" protobuf:"bytes,5,opt,name=burstReplicas"` } 按节点灰度 在一个大规模 Kubernetes 集群中往往存在很多种差异化的节点类型,比如机型、拓扑、核心程度、内核版本等,因此在 DaemonSet 发布的时候我们支持根据 Node 的标签来匹配发布哪些 Node 上的 Pod。 apiVersion: apps.kruise.io/v1alpha1 kind: DaemonSet spec: # ... updateStrategy: type: RollingUpdate rollingUpdate: selector: matchLabels: nodeType: canary 比如上述配置了滚动升级下的 selector 策略,则 DaemonSet 只会在符合 selector 条件的 Node 上把 Pod 做滚动升级。如果 selector 改变,则 DaemonSet 会按照新的 selector 做升级,对已经是最新版本的 Pod 不会做变动。 因此,用户可以通过多次修改 selector,来实现不同类型 Node 的前后发布顺序。这个优先顺序可以是特定一批用于灰度的非核心节点,也可以是一些逻辑资源池等。 按数量灰度 如果说你不关心节点类型,Advanced DaemonSet 同样提供了按数量灰度的能力: apiVersion: apps.kruise.io/v1alpha1 kind: DaemonSet spec: # ... updateStrategy: type: RollingUpdate rollingUpdate: partition: 100 这里的 partition 和 OpenKruise 中其他 CloneSet、Advanced StatefulSet 类似,都表示了维持旧版本的数量,也就是说 Kruise 控制器会选择status.DesiredNumberScheduled - partition数量的 Pod 滚动升级为新版本。 比如当前集群中 DaemonSet 部署的节点数量是 120 个,当滚动升级时如果设置了 partition 为 100,则 DaemonSet 只会选择 20 个 Pod 滚动到新版本。只有当用户再次下调 partition,DaemonSet 才会继续按要求数量来继续升级。 多维度灰度 上述两种灰度策略相信都不难理解,那么如果同时配置了按节点和按数量两种灰度策略,会怎么样呢? apiVersion: apps.kruise.io/v1alpha1 kind: DaemonSet spec: # ... updateStrategy: type: RollingUpdate rollingUpdate: maxUnavailable: 5 partition: 100 selector: matchLabels: nodeType: canary 想搞清楚这个问题,其实看懂 Advanced DaemonSet 的发布策略计算逻辑就很好理解了,有兴趣的同学可以跳去看一下:https://github.com/openkruise/kruise/blob/master/pkg/controller/daemonset/update.go#L459 参考上面这个 YAML,如果用户同时配置了 partition 和 selector,那么控制器在发布的时候会先按照 selector 匹配符合条件的 Node,再按照 partition 计算其中能够发布的数量。当然,如果你还配置了原生 DaemonSet 就支持的 maxUnavailable,那么最后还会按照 unavailable 的数量再次限制实际能滚动升级的数量。 简单来说,最终真正执行滚动升级的 Pod,一定是要同时满足所有配置的灰度策略。 热升级 标准的 DaemonSet 滚动升级过程,是通过先删除旧 Pod、再创建新 Pod 的方式来做的。在绝大部分场景下这样的方式都是可以满足的,然而如果这个 daemon Pod 的作用还需要对外提供服务,那么滚动的时候可能对应 Node 上的服务就不可用了。 为了提供高可用能力,我们对 DaemonSet 也提供了 surging 发布策略。(回顾一下原生 Deployment 或者 OpenKruise 的 CloneSet,在这些面向无状态服务的 workload 中如果配置了 maxSurging,则发布时会先多扩出来 maxSurging 数量的 Pod,再逐渐删掉旧版本的 Pod。) apiVersion: apps.kruise.io/v1alpha1 kind: DaemonSet spec: # ... updateStrategy: rollingUpdate: type: Surging # defaults to Standard maxSurge: 30% 首先,在滚动升级中配置type: Surging,这个类型默认是 Standard -- 也就是先删再扩,而一旦设置为 Surging 则变为先扩再缩。也就是在滚动升级时,DaemonSet 会先在要发布的 Node 上新建一个 Pod,等这个新版本 Pod 变为 ready 之后再把旧版本 Pod 删除掉。 另外在流式的策略上,maxUnavailable 是用于 Standard 类型的,对应了在滚动升级时最多在多少个 Node 上删除 Pod。而 maxSurge 策略是用于 Surging 类型的,对应了在滚动升级时最多在多少个 Node 上多扩出一个 Pod。 发布暂停 此外,Advanced DaemonSet 还支持了 paused 一键暂停发布。这个比较好理解,就不细表述了。 apiVersion: apps.kruise.io/v1alpha1 kind: DaemonSet spec: # ... updateStrategy: rollingUpdate: paused: true 总结 总的来看,OpenKruise 在原生 DaemonSet 基础上增加了一系列面向生产场景的发布策略,让 DaemonSet 的升级过程更加安全、可控、自动化。 后续 OpenKruise 还会持续在应用部署/发布能力上做出更深的优化,我们也欢迎每一位云原生爱好者来共同参与 OpenKruise 的建设。与其他一些开源项目不同,OpenKruise 并不是阿里内部代码的复刻;恰恰相反,OpenKruise Github 仓库是阿里内部代码库的 upstream。因此,每一行你贡献的代码,都将运行在阿里内部的所有 Kubernetes 集群中、都将共同支撑了阿里巴巴全球顶尖规模的云原生应用场景! 原文链接 本文为阿里云原创内容,未经允许不得转载。

资源下载

更多资源
Mario

Mario

马里奥是站在游戏界顶峰的超人气多面角色。马里奥靠吃蘑菇成长,特征是大鼻子、头戴帽子、身穿背带裤,还留着胡子。与他的双胞胎兄弟路易基一起,长年担任任天堂的招牌角色。

腾讯云软件源

腾讯云软件源

为解决软件依赖安装时官方源访问速度慢的问题,腾讯云为一些软件搭建了缓存服务。您可以通过使用腾讯云软件源站来提升依赖包的安装速度。为了方便用户自由搭建服务架构,目前腾讯云软件源站支持公网访问和内网访问。

Sublime Text

Sublime Text

Sublime Text具有漂亮的用户界面和强大的功能,例如代码缩略图,Python的插件,代码段等。还可自定义键绑定,菜单和工具栏。Sublime Text 的主要功能包括:拼写检查,书签,完整的 Python API , Goto 功能,即时项目切换,多选择,多窗口等等。Sublime Text 是一个跨平台的编辑器,同时支持Windows、Linux、Mac OS X等操作系统。

WebStorm

WebStorm

WebStorm 是jetbrains公司旗下一款JavaScript 开发工具。目前已经被广大中国JS开发者誉为“Web前端开发神器”、“最强大的HTML5编辑器”、“最智能的JavaScript IDE”等。与IntelliJ IDEA同源,继承了IntelliJ IDEA强大的JS部分的功能。

用户登录
用户注册