阚俊宝
TA的个人档案
云盘扩容方案文章列表： 基于Flexvolume插件的云盘动态存储卷扩容方案（本文）； 基于CSI插件的云盘动态存储卷扩容方案：参考； 不适合动态扩容的场景，可以使用手动扩容云盘存储卷方案：参考； 数据卷扩容说明： 符合以下要求的集群环境可以进行动态扩容操作： Kubernetes从1.13版本开始支持Flexvolume插件实现数据卷扩容；实现；阿里云ACK不支持1.13版本，所以需要您的Kubernetes集群版本大于等于1.14； Flexvolume要求版本不低于v1.14.6.15-8d3b7e7-aliyun； 普通云盘类型不支持动态扩容，请参考使用手动扩容云盘方案； 不支持InlineVolume类型（非PV、PVC方式）云盘数据卷扩容； 切记：做数据卷扩容前，先对云盘打快照备份，以防扩容过程异常导致数据出现问题； 数据卷扩容配置需求： 对集群的要求： 对云盘扩容操作需要调用云盘扩容相应API，所以需要集群具有此API的调用权限，可以参考集群权限文档为集群添加此权限；可参考附录。 对PV的要求： 只有动态存储卷才可以进行数据卷动态扩容，即配置了StorageClassName的PV； 对StorageClass的要求： PVC配置的StorageClass为阿里云云盘类型，provisioner为alicloud/disk； StorageClass需要配置：AllowVolumeExpansion: True，具体含义参考，如果当前pv使用的storageClass没有配置AllowVolumeExpansion为True，可以安装下面步骤更新； 数据卷扩容步骤： 云盘动态数据卷在满足上述要求的情况下，可以实现动态扩容： 步骤1：扩容存储卷，此步骤会调整PV的Size大小； 操作：# kubectl patch pvc pvc-disk -p '{"spec":{"resources":{"requests":{"storage":"30Gi"}}}}' 步骤2：扩容文件系统，此步骤会调整云盘、PVC、文件系统大小； 操作：重启Pod； 场景示例： 下面给出三个常见的扩容场景，并给出相应扩容步骤： 场景一：可扩容的动态卷，创建动态数据卷时StorageClass配置了AllowVolumeExpansion(true)； 场景二：不可扩容的动态卷，创建动态数据卷时StorageClass没有配置AllowVolumeExpansion(true)； 场景三：静态数据卷，使用已有云盘手动创建数据卷，并挂载使用； 场景一针对的是：在创建动态数据卷的时候就配置StorageClass的AllowVolumeExpansion为true，后续可以直接进行数据卷扩容。云盘数据卷的“使用方式”推荐使用这个方式； 场景二针对的是：之前版本不支持动态卷扩容时创建的动态数据卷，当时没有配置AllowVolumeExpansion为true。这个场景可以通过更新StorageClass配置来获取和场景一一致的效果。 场景三针对的是：一些用户已经手动创建了云盘，手动创建PV后挂载使用，这个场景也是通过改造PV、PVC来模拟场景一； 场景一：可扩容动态卷 此场景是说直接创建可扩容动态数据卷，并为数据卷扩容。这种使用方式为云盘推荐的使用方式； 此场景的云盘使用过程如下： 1. 确保StorageClass符合扩容条件 期望的StorageClass如下： # kubectl describe sc alicloud-disk-ssd Name: alicloud-disk-ssd IsDefaultClass: No Provisioner: alicloud/disk Parameters: type=cloud_ssd AllowVolumeExpansion: True MountOptions: <none> ReclaimPolicy: Delete VolumeBindingMode: Immediate Events: <none> 如果当前StorageClass中没有定义AllowVolumeExpansion，或者值为False，通过下面命令进行更新： # kubectl patch sc alicloud-disk-ssd -p '{"allowVolumeExpansion": true}' 2. 创建数据卷、应用 通过下面PVC模板创建动态数据卷： kind: PersistentVolumeClaim apiVersion: v1 metadata: name: pvc-disk spec: accessModes: - ReadWriteOnce storageClassName: alicloud-disk-ssd resources: requests: storage: 20Gi 创建应用挂载数据卷（模板略）； 查看应用和数据卷信息： # kubectl get pod NAME READY STATUS RESTARTS AGE web-0 1/1 Running 0 12m # kubectl get pvc NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE pvc-disk Bound d-wz955czz7lmobytaa0f1 20Gi RWO alicloud-disk-ssd 13m # kubectl get pv NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE d-wz955czz7lmobytaa0f1 20Gi RWO Delete Bound default/pvc-disk alicloud-disk-ssd 12m 原始挂载云盘大小为20G，创建测试文件： # kubectl exec -ti web-0 sh # df -h | grep data /dev/vdb 20G 45M 20G 1% /data # ls /data lost+found # touch /data/aliyun # ls /data aliyun lost+found 3. 扩容动态数据卷： 步骤一：扩容PVC，查看PVC、PV、文件系统大小： 执行扩容命令： # kubectl patch pvc pvc-disk -p '{"spec":{"resources":{"requests":{"storage":"30Gi"}}}}' persistentvolumeclaim/pvc-disk patched PV扩容完成，但PVC、云盘、文件系统大小尚未变化，即应用可用存储空间并没有变化； # kubectl get pvc NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE pvc-disk Bound d-wz955czz7lmobytaa0f1 20Gi RWO alicloud-disk-ssd 37m # kubectl get pv NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE d-wz955czz7lmobytaa0f1 30Gi RWO Delete Bound default/pvc-disk alicloud-disk-ssd 36m # kubectl exec -ti web-0 sh # df -h | grep data /dev/vdb 20G 45M 20G 1% /data 步骤二：重启Pod，扩容文件系统： 重启Pod： # kubectl delete pod web-0 pod "web-0" deleted 云盘、PVC、PV、文件系统都扩容到了30G： # kubectl get pvc NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE pvc-disk Bound d-wz955czz7lmobytaa0f1 30Gi RWO alicloud-disk-ssd 40m # kubectl get pv NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE d-wz955czz7lmobytaa0f1 30Gi RWO Delete Bound default/pvc-disk alicloud-disk-ssd 40m 测试文件依然存储，保证了数据的可用性： # kubectl exec -ti web-0 sh # df -h | grep data /dev/vdb 30G 44M 30G 1% /data # ls /data/ aliyun lost+found 通过上面两步完成了动态数据卷的扩容操作（卷扩容 + 文件系统扩容）； 场景二：不可扩容动态卷 不可扩容动态卷，是指动态数据卷对应的StorageClass没有配置allowVolumeExpansion为true； 这类数据卷的扩容主要思想是：改造对应的StorageClass，配置allowVolumeExpansion为true，然后使用与“场景一”相同的扩容步骤； 场景二与场景一的区别： 场景一是用配置了allowVolumeExpansion为True 的 StorageClass创建的PV； 场景二是用没有配置allowVolumeExpansion为True的 StorageClass创建的PV； 对于现存的正在使用的云盘动态数据卷，如果您创建动态卷的时候StorageClass没有配置allowVolumeExpansion为True（当时还不支持），可以考虑为符合这个场景； 此场景云盘事情过程： 更新StroageClass，添加allowVolumeExpansion(true)配置，参考“场景一”第1步； 扩容云盘动态数据卷；参考“场景一”第3步； 场景三：静态数据卷扩容 当用户先创建好了云盘，通过静态数据卷方式手动创建PV并挂载，这个场景的PV中一般没有配置StorageClassName或者配置的StorageClassName只为了标识作用（例如配置为disk）；这时即需要对静态存储卷进行扩容； 注：静态存储卷不支持动态扩容，所以需要暂停应用，重新创建PVC、PV； 这个场景的扩容原则是：将当前的静态数据卷改造成动态数据卷； 步骤： 删除应用、PVC、PV，业务需要暂停，注意：给云盘打快照，且不能删除云盘； 创建新PVC、PV，模板中添加stroageClassName（value值具体选择哪个storageClass需要根据云盘的类型，例如：SSD、ESSD），且确认配置的stroageClass具有allowVolumeExpansion(true)配置； 重新创建应用挂载数据卷； 扩容云盘动态数据卷；参考“场景一”第3步； 静态存储卷的另一个扩容方式是：业务停止后手动扩容云盘，但pvc、pv不修改的话，以后需要扩容的时候还是要手动扩容，所以上述步骤有其意义所在。 总结： 云盘数据卷扩容只支持动态存储卷，且StorageClass需要配置allowVolumeExpansion为True。不符合这个需求的场景进行数据卷扩容时，需要改造StorageClass、PVC、PV，使之符合动态扩容条件； 需要注意的是，“数据卷扩容说明”、“数据卷扩容配置”部分指出了动态数据卷扩容所需要的条件，必须满足上述条件才能进行扩容操作。 附录： 给云盘扩容需要为集群的”Worker RAM 角色“添加ResizeDisk权限： 在集群 --> 管理 --> 集群资源 点击”Worker RAM 角色“；编辑Ram权限，添加ResizeDisk如下图：
Flexvolume数据卷采集Metric说明 Flexvolume插件采集Metric数据依赖于Kubernetes的支持，有以下注意事项： Kubernetes从1.13版本开始支持Flexvolume数据卷的监控数据采集；实现详情；阿里云ACK不支持Kubernetes 1.13版本，所以需要您的Kubernetes集群版本大于等于1.14； Flexvolume要求版本大于等于v1.14.6.15-8d3b7e7-aliyun； 阿里云Flexvolume目前支持云盘、NAS两种卷的Metric采集，oss卷暂不支持； Metric采集只支持PV、PVC数据卷，通过InlineVolume配置的数据卷不支持采集； 数据卷Metric采集默认没有打开，需要按照下面方法进行配置： 查看云盘卷Metric 在集群、Flexvolume版本满足上述要求的情况下，通过下面命令启动云盘数据卷采集功能： # kubectl set env ds/flexvolume ENABLE_METRICS_DISK=true -nkube-system 在上述配置前挂载的云盘卷Metric采集不到，需要重新挂载（重启Pod）； 部署Pod挂载云盘数据卷，假设对应的PVC名为：pvc-disk；在节点上查看挂载情况： # mount | grep disk /dev/vdb on /var/lib/kubelet/plugins/kubernetes.io/flexvolume/alicloud/disk/mounts/d-wz97va7lc72bqxunllta type ext4 (rw,relatime,data=ordered) /dev/vdb on /var/lib/kubelet/pods/7c00167c-f612-11e9-9073-00163e087786/volumes/alicloud~disk/d-wz97va7lc72bqxunllta type ext4 (rw,relatime,data=ordered) 在云盘挂载节点上，通过下面命令可以获取Metric数据统计： # curl -s localhost:10255/metrics | grep pvc-disk kubelet_volume_stats_available_bytes{namespace="default",persistentvolumeclaim="pvc-disk"} 2.0940644352e+10 kubelet_volume_stats_capacity_bytes{namespace="default",persistentvolumeclaim="pvc-disk"} 2.1003583488e+10 kubelet_volume_stats_inodes{namespace="default",persistentvolumeclaim="pvc-disk"} 1.31072e+06 kubelet_volume_stats_inodes_free{namespace="default",persistentvolumeclaim="pvc-disk"} 1.310709e+06 kubelet_volume_stats_inodes_used{namespace="default",persistentvolumeclaim="pvc-disk"} 11 kubelet_volume_stats_used_bytes{namespace="default",persistentvolumeclaim="pvc-disk"} 4.616192e+07 查看NAS卷Metric 在集群、Flexvolume版本满足上述要求的情况下，通过下面命令启动NAS数据卷采集功能： # kubectl set env ds/flexvolume ENABLE_METRICS_NAS=true -nkube-system 在上述配置前挂载的NAS卷Metric采集不到，需要重新挂载（重启Pod）； 部署Pod挂载NAS数据卷，假设对应的PVC名为：pvc-nas；在节点上查看挂载情况： # mount | grep nfs 23a9649583-ukj18.cn-shenzhen.nas.aliyuncs.com:/k8s on /var/lib/kubelet/pods/32adb8f1-f61c-11e9-9073-00163e087786/volumes/alicloud~nas/pv-nas type nfs (rw,relatime,vers=3,rsize=1048576,wsize=1048576,namlen=255,hard,nolock,noresvport,proto=tcp,timeo=600,retrans=2,sec=sys,mountaddr=10.0.0.29,mountvers=3,mountport=4002,mountproto=tcp,local_lock=all,addr=10.0.0.29) 在NAS卷挂载节点上，通过下面命令可以获取Metric数据统计： # curl -s localhost:10255/metrics | grep pvc-nas kubelet_volume_stats_available_bytes{namespace="default",persistentvolumeclaim="pvc-nas"} 1.125899255676928e+15 kubelet_volume_stats_capacity_bytes{namespace="default",persistentvolumeclaim="pvc-nas"} 1.125899906842624e+15 kubelet_volume_stats_inodes{namespace="default",persistentvolumeclaim="pvc-nas"} 1e+09 kubelet_volume_stats_inodes_free{namespace="default",persistentvolumeclaim="pvc-nas"} 9.99999995e+08 kubelet_volume_stats_inodes_used{namespace="default",persistentvolumeclaim="pvc-nas"} 5 kubelet_volume_stats_used_bytes{namespace="default",persistentvolumeclaim="pvc-nas"} 6.51165696e+08 注意：取到的NAS卷统计数据是整个nas文件系统的数据，而不是某个文件目录的数据；
本文介绍了在多可用区Kubernetes集群中挂载云盘的实现方案，核心原理为： 通过StorageClass中的volumeBindingMode参数配置给出两种挂载云盘的方案：”Pod跟着云盘走“、”云盘跟着Pod走“； volumeBindingMode配置参考：卷绑定模式说明 多可用区集群 部署集群的时候使用多可用区方案来保证集群的高可用已得到大家的共识，这样集群在某个可用区出现异常时仍然可以保持集群对外提供正常服务，阿里云ACK服务提供了多可用区集群部署方案，可参考使用文档。 容器存储卷为用户数据持久化提供了实现方案，通过将外置存储挂载到容器内部的方式为应用提供存储空间，在容器被销毁后存储卷中的数据依然可以继续被其他的应用使用。常用的存储卷类型有块存储、文件存储、对象存储，其对可用区的敏感性如下： 块存储：如阿里云云盘；ECS和云盘需要在同一个可用区内联合使用； 文件存储：如阿里云NAS、CPFS服务；ECS和NAS可以跨可用区挂载，但要求在相同VPC内； 对象存储：如阿里云OSS；ECS和OSS可以跨可用区、跨Region挂载； 可见，只有云盘存储卷对可用区有强制要求，需要在集群内部根据数据卷可用区调度Pod，PV（云盘）的可用区和Pod被调度的可用区必须一致才可以挂载成功。k8s实现了针对数据卷的调度器，会根据Pod使用的PV信息把Pod调度到合适的可用区； 下面针对阿里云云盘讲述一下如何在多可用环境实现块存储数据卷的可用区调度。 云盘多可用区使用方案 使用StatefulSet在多可用区集群挂载云盘 关于应用负载，Pod中挂载云盘数据卷的场景有如下特点： 云盘作为块存储只能挂载到相同可用区的节点上，且云盘不是共享存储，只能被一个Pod挂载使用； 常用的应用编排模板中：Deployment和Daemonset都是具有相同Pod配置的多个副本模式，如果Pod挂载数据卷，则所有Pod的数据卷需要是一样的，而云盘只能挂载到一个Pod的限制，所以Deployment、DaemonSet不适合挂载云盘数据卷。 Statefulset类型应用提供了两种配置Volume的方式，一种和Deployment一样直接通过volumes定义persistentVolumeClaim，这种方式只能为StatefulSet应用配置一个特定的PVC（云盘），不能用在多副本场景中； 另一种是通过volumeClaimTemplates配置，这个方式为每个Pod配置一个具有一定规则名字的PVC，不通的PVC对应不同的云盘卷。这样的配置可以启动多个副本，且每个副本都挂载了独立的云盘。 即：在应用使用云盘的场景中，需要使用StatefulSet进行编排，并使用volumeClaimTemplates配置挂载云盘。多可用区场景亦是如此。 通过volumeClaimTemplates为每个Pod配置的PVC名字规则： PVC的名字 = {volumeClaimTemplates名字} + "-" + {StatefulSet名字} + "-" + 序号 例如如下配置的StatefulSet： apiVersion: apps/v1beta2 kind: StatefulSet metadata: name: web spec: replicas: 3 *** volumeClaimTemplates: - metadata: name: disk-ssd spec: *** 为3个Pod分别创建配置的pvc名字为：disk-ssd-web-0、disk-ssd-web-1、disk-ssd-web-2； 多可用区集群挂载云盘方案 没有挂载云盘数据卷的情况下，pod启动过程为： Pod创建好后进入调度流程； 检查Pod引用的pvc，如果pvc处于unbound状态，等待pvc变成bound；如果pvc处于bound状态，继续调度； 根据nodeSelector、Node状态等配置选择最合适的目标节点； 在目标节点启动Pod； 考虑挂载云盘卷调度方案1： Pod创建好后进入调度流程； 检查Pod引用的pvc，如果pvc处于unbound状态，等待pvc变成bound；如果pvc处于bound状态，继续调度； 根据PV中的调度信息选择满足条件的目标节点集合； 根据nodeSelector、Node状态等配置选择满足条件的目标节点； 在目标节点启动Pod； 考虑挂载云盘卷调度方案2： Pod创建好后进入调度流程； 检查Pod引用的pvc，如果pvc处于unbound状态； 根据nodeSelector、Node状态等配置选择满足条件的目标节点； 根据目标节点的可用区信息，动态创建云盘(PV)，这时PV的可用区和目标启动节点相同； 在目标节点启动Pod； 上面两种挂载云盘数据卷方案中： 方案1：先确定了PV（云盘）可用区信息，并将云盘可用区信息作为Pod调度的一个参量，即Pod随着云盘走； 方案2：先确定了Pod运行的目标节点，再动态创建PV（云盘）并绑定，即云盘跟着Pod走。 Pod跟着云盘走： 此方案的关键点是：Pod调度前确定创建好PV，并确定PV的可用区信息。在静态存储卷或动态存储卷中都可以实现此方案。 部署前需要规划好应用期望运行的可用区，并手动（静态卷）/自动（动态卷）创建好云盘、PV对象；如果一个应用期望运行在多个可用区，则需要在多个可用区申请云盘并创建多个PV。每个PV对象中需要添加相应的可用区调度信息。 调度信息可以通过在PV的Label中添加如下配置（由VolumeZonePredicate调度器进行调度）： labels: failure-domain.beta.kubernetes.io/zone: cn-hangzhou-b failure-domain.beta.kubernetes.io/region: cn-hangzhou 调度信息也可以通过在PV的nodeAffinity中添加如下配置（由VolumeBindingPredicate调度器进行调度）： nodeAffinity: required: nodeSelectorTerms: - matchExpressions: - key: topology.diskplugin.csi.alibabacloud.com/zone operator: In values: - cn-shenzhen-a 下面示例是在一个包含三可用区节点的集群进行： # kubectl describe node | grep failure-domain.beta.kubernetes.io/zone failure-domain.beta.kubernetes.io/zone=cn-beijing-a failure-domain.beta.kubernetes.io/zone=cn-beijing-a failure-domain.beta.kubernetes.io/zone=cn-beijing-b failure-domain.beta.kubernetes.io/zone=cn-beijing-b failure-domain.beta.kubernetes.io/zone=cn-beijing-c failure-domain.beta.kubernetes.io/zone=cn-beijing-c 静态数据卷 静态存储卷指PV对象、云盘实例需要管理员手动创建，并将可用区等信息配置到数据卷中。在使用静态存储卷前需要先创建好云盘、pv。 本示例在StatefulSet应用中启动三个Pod，每个pod挂载一个云盘数据卷，且分别运行在cn-beijing-a、cn-beijing-b、cn-beijing-c三个可用区；期望：StatefulSet名字为 web，volumeClaimTemplates名字为disk-ssd； 分别按照下面模板创建pvc、pv： apiVersion: v1 kind: PersistentVolumeClaim metadata: name: disk-ssd-web-0 spec: accessModes: - ReadWriteOnce resources: requests: storage: 25Gi selector: matchLabels: alicloud-pvname: pv-disk-ssd-web-0 --- apiVersion: v1 kind: PersistentVolume metadata: name: pv-disk-ssd-web-0 labels: alicloud-pvname: pv-disk-ssd-web-0 spec: capacity: storage: 25Gi accessModes: - ReadWriteOnce persistentVolumeReclaimPolicy: Retain csi: driver: diskplugin.csi.alibabacloud.com volumeHandle: d-2zeeujx1zexxkbc8ny4b nodeAffinity: required: nodeSelectorTerms: - matchExpressions: - key: topology.diskplugin.csi.alibabacloud.com/zone operator: In values: - cn-beijing-a 其中pvc、pv、可用区、云盘ID对应关系： disk-ssd-web-0 ==> pv-disk-ssd-web-0 ==> cn-beijing-a ==> d-2zeeujx1zexxkbc8ny4b disk-ssd-web-1 ==> pv-disk-ssd-web-1 ==> cn-beijing-b ==> d-2ze4n7co1x8w8xs95sqk disk-ssd-web-2 ==> pv-disk-ssd-web-2 ==> cn-beijing-c ==> d-2zeaed32ln6d8sbpichh # kubectl get pvc | grep disk-ssd-web disk-ssd-web-0 Bound pv-disk-ssd-web-0 25Gi RWO 59s disk-ssd-web-1 Bound pv-disk-ssd-web-1 25Gi RWO 56s disk-ssd-web-2 Bound pv-disk-ssd-web-2 25Gi RWO 54s # kubectl get pv | grep disk-ssd-web pv-disk-ssd-web-0 25Gi RWO Retain Bound default/disk-ssd-web-0 2m43s pv-disk-ssd-web-1 25Gi RWO Retain Bound default/disk-ssd-web-1 2m40s pv-disk-ssd-web-2 25Gi RWO Retain Bound default/disk-ssd-web-2 2m38s 部署下面StatefulSet模板： apiVersion: v1 kind: Service metadata: name: nginx labels: app: nginx spec: ports: - port: 80 name: web clusterIP: None selector: app: nginx --- apiVersion: apps/v1beta2 kind: StatefulSet metadata: name: web spec: selector: matchLabels: app: nginx serviceName: "nginx" replicas: 3 template: metadata: labels: app: nginx spec: containers: - name: nginx image: nginx ports: - containerPort: 80 name: web volumeMounts: - name: disk-ssd mountPath: /data volumeClaimTemplates: - metadata: name: disk-ssd spec: accessModes: [ "ReadWriteOnce" ] storageClassName: csi-disk-topology resources: requests: storage: 20Gi 执行下面命令获取Pod信息，上述模板启动的三个Pod分别运行在a、b、c三个可用区： # kubectl get pod NAME READY STATUS RESTARTS AGE web-0 1/1 Running 0 14m web-1 1/1 Running 0 13m web-2 1/1 Running 0 13m # kubectl describe pod | grep Node Node: cn-beijing.172.16.1.101/172.16.1.101 Node: cn-beijing.172.16.2.87/172.16.2.87 Node: cn-beijing.172.16.3.197/172.16.3.197 # kubectl describe node cn-beijing.172.16.1.101 | grep zone failure-domain.beta.kubernetes.io/zone=cn-beijing-a # kubectl describe node cn-beijing.172.16.2.87 | grep zone failure-domain.beta.kubernetes.io/zone=cn-beijing-b # kubectl describe node cn-beijing.172.16.3.197 | grep zone failure-domain.beta.kubernetes.io/zone=cn-beijing-c 分别删除三个pod，验证重启后的Pod依然落在相应可用区： # kubectl delete pod --all pod "web-0" deleted pod "web-1" deleted pod "web-2" deleted # kubectl get pod NAME READY STATUS RESTARTS AGE web-0 1/1 Running 0 61s web-1 1/1 Running 0 41s web-2 1/1 Running 0 21s # kubectl describe pod | grep Node Node: cn-beijing.172.16.1.101/172.16.1.101 Node: cn-beijing.172.16.2.87/172.16.2.87 Node: cn-beijing.172.16.3.197/172.16.3.197 # kubectl describe node cn-beijing.172.16.1.101 | grep zone failure-domain.beta.kubernetes.io/zone=cn-beijing-a # kubectl describe node cn-beijing.172.16.2.87 | grep zone failure-domain.beta.kubernetes.io/zone=cn-beijing-b # kubectl describe node cn-beijing.172.16.3.197 | grep zone failure-domain.beta.kubernetes.io/zone=cn-beijing-c 动态数据卷 创建支持多可用区的StorageClass，如下配置： apiVersion: storage.k8s.io/v1 kind: StorageClass metadata: name: csi-disk-multizone provisioner: diskplugin.csi.alibabacloud.com parameters: type: cloud_ssd zoneId: cn-beijing-a,cn-beijing-b,cn-beijing-c reclaimPolicy: Delete zoneId：配置多个可用区，生成多个云盘时会在多个可用区之间循环创建； 按照下面StatefulSet配置创建应用： apiVersion: v1 kind: Service metadata: name: nginx labels: app: nginx spec: ports: - port: 80 name: web clusterIP: None selector: app: nginx --- apiVersion: apps/v1beta2 kind: StatefulSet metadata: name: web spec: selector: matchLabels: app: nginx serviceName: "nginx" replicas: 3 template: metadata: labels: app: nginx spec: containers: - name: nginx image: nginx ports: - containerPort: 80 name: web volumeMounts: - name: disk-ssd mountPath: /data volumeClaimTemplates: - metadata: name: disk-ssd spec: accessModes: [ "ReadWriteOnce" ] storageClassName: csi-disk-topology resources: requests: storage: 20Gi 查看生成的Pod、PVC、PV信息： # kubectl get pod NAME READY STATUS RESTARTS AGE web-0 1/1 Running 0 2m2s web-1 1/1 Running 0 84s web-2 1/1 Running 0 52s # kubectl get pvc NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE disk-ssd-web-0 Bound disk-9e6a6f65-f3fc-11e9-a7a7-00163e165b60 20Gi RWO csi-disk-multizone 2m6s disk-ssd-web-1 Bound disk-b5071f37-f3fc-11e9-a7a7-00163e165b60 20Gi RWO csi-disk-multizone 88s disk-ssd-web-2 Bound disk-c81b6163-f3fc-11e9-a7a7-00163e165b60 20Gi RWO csi-disk-multizone 56s # kubectl get pv NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE disk-9e6a6f65-f3fc-11e9-a7a7-00163e165b60 20Gi RWO Delete Bound default/disk-ssd-web-0 csi-disk-multizone 116s disk-b5071f37-f3fc-11e9-a7a7-00163e165b60 20Gi RWO Delete Bound default/disk-ssd-web-1 csi-disk-multizone 85s disk-c81b6163-f3fc-11e9-a7a7-00163e165b60 20Gi RWO Delete Bound default/disk-ssd-web-2 csi-disk-multizone 39s 查看Pod、pv所在的可用区，分别落在3个可用区： # kubectl describe pod web-0 | grep Node Node: cn-beijing.172.16.1.101/172.16.1.101 # kubectl describe node cn-beijing.172.16.1.101 | grep zone failure-domain.beta.kubernetes.io/zone=cn-beijing-a # kubectl describe pod web-1 | grep Node Node: cn-beijing.172.16.2.87/172.16.2.87 # kubectl describe node cn-beijing.172.16.2.87 | grep zone failure-domain.beta.kubernetes.io/zone=cn-beijing-b # kubectl describe pod web-2 | grep Node Node: cn-beijing.172.16.3.197/172.16.3.197 # kubectl describe node cn-beijing.172.16.3.197 | grep zone failure-domain.beta.kubernetes.io/zone=cn-beijing-c # kubectl describe pv disk-9e6a6f65-f3fc-11e9-a7a7-00163e165b60 | grep zone Term 0: topology.diskplugin.csi.alibabacloud.com/zone in [cn-beijing-a] # kubectl describe pv disk-b5071f37-f3fc-11e9-a7a7-00163e165b60 | grep zone Term 0: topology.diskplugin.csi.alibabacloud.com/zone in [cn-beijing-b] # kubectl describe pv disk-c81b6163-f3fc-11e9-a7a7-00163e165b60 | grep zone Term 0: topology.diskplugin.csi.alibabacloud.com/zone in [cn-beijing-c] 云盘跟着Pod走： 云盘跟着Pod走是指在Pod完成调度，已经确定了运行节点所在可用区以后，再动态创建云盘、PV的方式。所以云盘跟着Pod走的方案只适用于动态数据卷。 创建WaitForFirstConsumer类型的StorageClass： apiVersion: storage.k8s.io/v1 kind: StorageClass metadata: name: csi-disk-topology provisioner: diskplugin.csi.alibabacloud.com parameters: type: cloud_ssd reclaimPolicy: Delete volumeBindingMode: WaitForFirstConsumer WaitForFirstConsumer：表示使用定义了这个storageClass的pvc，在pod启动的时候先进行pod调度，再触发pv、云盘的Provision操作。 创建下面StatefulSet应用： apiVersion: v1 kind: Service metadata: name: nginx labels: app: nginx spec: ports: - port: 80 name: web clusterIP: None selector: app: nginx --- apiVersion: apps/v1beta2 kind: StatefulSet metadata: name: web spec: selector: matchLabels: app: nginx serviceName: "nginx" replicas: 3 template: metadata: labels: app: nginx spec: containers: - name: nginx image: nginx ports: - containerPort: 80 name: web volumeMounts: - name: disk-ssd mountPath: /data volumeClaimTemplates: - metadata: name: disk-ssd spec: accessModes: [ "ReadWriteOnce" ] storageClassName: csi-disk-topology resources: requests: storage: 20Gi 获取Pod、PV的信息： # kubectl get pod NAME READY STATUS RESTARTS AGE web-0 1/1 Running 0 2m5s web-1 1/1 Running 0 100s web-2 1/1 Running 0 74s # kubectl describe pod web-0 | grep Node Node: cn-beijing.172.16.3.197/172.16.3.197 # kubectl describe node cn-beijing.172.16.3.197 | grep zone failure-domain.beta.kubernetes.io/zone=cn-beijing-c # kubectl describe pod web-1 | grep Node Node: cn-beijing.172.16.1.101/172.16.1.101 # kubectl describe node cn-beijing.172.16.1.101 | grep zone failure-domain.beta.kubernetes.io/zone=cn-beijing-a # kubectl describe pod web-2 | grep Node Node: cn-beijing.172.16.2.87/172.16.2.87 # kubectl describe node cn-beijing.172.16.2.87 | grep zone failure-domain.beta.kubernetes.io/zone=cn-beijing-b # kubectl describe pv disk-d4b08afa-f3fe-11e9-a7a7-00163e165b60 | grep zone Term 0: topology.diskplugin.csi.alibabacloud.com/zone in [cn-beijing-c] # kubectl describe pv disk-e32d5fcf-f3fe-11e9-a7a7-00163e165b60 | grep zone Term 0: topology.diskplugin.csi.alibabacloud.com/zone in [cn-beijing-a] # kubectl describe pv disk-f2cec31a-f3fe-11e9-a7a7-00163e165b60 | grep zone Term 0: topology.diskplugin.csi.alibabacloud.com/zone in [cn-beijing-b] ”云盘跟着Pod走“的方案需要澄清一下： 只有第一次启动pod的时候，且配置了”云盘跟着Pod走“策略，才会出现先调度pod再触发创建pv、云盘的场景。当pod重启的时候，这时走的流程是根据pv的zone信息进行调度，即”pod跟着云盘走“。 总结： 本文给出了2种多可用区集群使用云盘数据卷方案： Pod跟着云盘走：需要先创建好云盘、PV对象，根据云盘的可用区信息调度负载，这个场景更多适合挂载已有云盘的场景；且这个方案在调度层面更多的依赖云盘可用区的调度信息，而弱化了其他调度器的调度能力。 云盘跟着Pod走：先执行负载调度，再根据Pod所在可用区信息创建云盘、PV对象；这个方案充分考虑了所有调度器的调度策略，在调度完成后创建PV并挂载使用，这个过程云盘可用区信息不参与调度。 对于应用负载使用云盘数据卷的场景，更推荐使用”云盘跟着Pod走“的方案。
概要 LVM存储类型为本地存储，并非可随着Pod迁移的可插拔的分布式存储方案，如果Pod期望在多个节点上使用相同的lvm卷，则需要在每个节点上都创建相同名字的lvm卷，这样Pod调度的时候可以继续使用相同的lvm卷名进行挂载。然而这样势必会造成有些节点上的lvm卷空间浪费，解决浪费的问题，可以通过将pod固定在某个节点运行，减少调度，这样只会在这个节点上创建需要的lvm卷。 阿里云容器服务CSI插件支持LVM数据卷的挂载、管理功能，可以动态创建LVM卷并挂载使用。且在最新的版本中可以通过修改pvc的大小，动态扩容lvm卷的大小，在重启应用Pod时进行文件系统扩容。 LVM实现原则： Provision Lvm数据卷的过程中，只会创建lvm类型pv对象，不会真正在节点上创建lvm volume； 创建lvm卷需要在已有的vg基础上进行，即需要手动在集群中创建vg； Pod启动的时候，检查本地是否有相应的LVM卷，如果没有这个卷，则会创建lvm卷并挂载； 如果Pod启动时，lvm卷已经存在，则检查卷大小和需求是否一致，实际卷小于pv需求时，进行lvm扩容； 目前没有实现删除lvm卷的功能，需要手动到节点删除； 部署CSI LVM插件 1. 创建K8S集群 在阿里云ACK控制台创建1.14版本k8s集群，创建集群时选择使用csi类型插件； 2. 调整集群参数，使支持CSI扩容 更新kube-controller参数，在/etc/kubernetes/manifests/kube-controller-manager.yaml中添加： - --feature-gates=ExpandCSIVolumes=true 在所有负载节点更新kubelet参数，在/etc/systemd/system/kubelet.service.d/10-kubeadm.conf 添加： --feature-gates=ExpandCSIVolumes=true 重启kubelet： systemctl daemon-reload service kubelet restart 3. 部署CSI LVM插件 下载LVM Plugin、Provisioner模板： https://github.com/kubernetes-sigs/alibaba-cloud-csi-driver/blob/v1.14/deploy/lvm/lvm-plugin.yaml https://github.com/kubernetes-sigs/alibaba-cloud-csi-driver/blob/v1.14/deploy/lvm/lvm-provisioner.yaml https://github.com/kubernetes-sigs/alibaba-cloud-csi-driver/blob/v1.14/deploy/lvm/resizer/csi-resizer.yaml 创建CSI组件： # kubectl create -f lvm-plugin.yaml # kubectl create -f lvm-provisioner.yaml # kubectl create -f csi-resizer.yaml 检查插件部署完成： # kubectl get pod -nkube-system | grep lvm csi-lvm-plugin-6kx6z 2/2 Running 0 16h csi-lvm-plugin-cgd7j 2/2 Running 0 16h csi-lvm-plugin-kg5pn 2/2 Running 0 16h csi-lvm-plugin-ld7rz 2/2 Running 0 16h csi-lvm-plugin-xjmmr 2/2 Running 0 16h csi-lvm-provisioner-0 1/1 Running 1 16h csi-lvm-resizer-0 1/1 Running 0 16h # kubectl get csidriver | grep lvm lvmplugin.csi.alibabacloud.com 2019-10-09T07:51:14Z 部署应用使用LVM卷 1. 创建StorageClass： 下载StorageClass模板： https://github.com/kubernetes-sigs/alibaba-cloud-csi-driver/blob/v1.14/examples/lvm/resizer/storageclass.yaml apiVersion: storage.k8s.io/v1 kind: StorageClass metadata: name: csi-lvm provisioner: lvmplugin.csi.alibabacloud.com parameters: vgName: vgtest reclaimPolicy: Delete allowVolumeExpansion: true provisioner: 配置为lvmplugin.csi.alibabacloud.com 驱动； parameters：定义生成lvm卷参数；vgName定义lvm数据卷依赖的vg名字，vg需要预先在集群中创建； allowVolumeExpansion：配置为true时，允许数据卷实现扩容功能； # kubectl get sc | grep lvm csi-lvm lvmplugin.csi.alibabacloud.com 19h 2. 创建PVC 下载PVC模板： https://github.com/kubernetes-sigs/alibaba-cloud-csi-driver/blob/v1.14/examples/lvm/pvc.yaml # kubectl create -f pvc.yaml # kubectl get pvc NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE lvm-pvc Bound lvm-7726e77b-eb2b-11e9-a442-00163e07fb69 2Gi RWO csi-lvm 3s # kubectl get pv NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE lvm-7726e77b-eb2b-11e9-a442-00163e07fb69 2Gi RWO Delete Bound default/lvm-pvc csi-lvm 14s 3. 创建应用 下载应用模板： https://github.com/kubernetes-sigs/alibaba-cloud-csi-driver/blob/v1.14/examples/lvm/deploy.yaml 可以在模板中添加nodeSelector(nodeName)来限制pod启动的节点； # kubectl create -f deploy.yaml # kubectl get pod NAME READY STATUS RESTARTS AGE deployment-lvm-cddcd84fb-5rkrj 1/1 Running 0 12s // Pod内部挂载的lvm卷大小为2G； # kubectl exec deployment-lvm-cddcd84fb-5rkrj df | grep data /dev/mapper/vgtest-lvm--7726e77b--eb2b--11e9--a442--00163e07fb69 1998672 6144 1871288 1% /data 到pod所在节点检查lvm卷信息，大小为2G： # lvdisplay /dev/vgtest/lvm-7726e77b-eb2b-11e9-a442-00163e07fb69 --- Logical volume --- LV Path /dev/vgtest/lvm-7726e77b-eb2b-11e9-a442-00163e07fb69 LV Name lvm-7726e77b-eb2b-11e9-a442-00163e07fb69 VG Name vgtest LV UUID hKsRqO-oG1w-0uE1-6Unz-hpP9-le4N-pGVzDS LV Write Access read/write LV Creation host, time iZ8vb1wy4teeoa0ql4bjq3Z, 2019-10-10 14:59:23 +0800 LV Status available # open 1 LV Size 2.00 GiB Current LE 512 Segments 1 Allocation inherit Read ahead sectors auto - currently set to 256 Block device 252:3 原理：Pod启动时在其运行的节点上，自动创建lvm数据卷（vg下面）并挂载使用； 4. lvm卷扩容 扩容PVC，从2G变成3G，扩容后PV已经变成了3G，但pvc需要pod重启后（文件系统扩容）才可以变成3G； // expand pvc from 2G to 3G # kubectl patch pvc lvm-pvc -p '{"spec":{"resources":{"requests":{"storage":"3Gi"}}}}' persistentvolumeclaim/lvm-pvc patched # kubectl get pvc NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE lvm-pvc Bound lvm-7726e77b-eb2b-11e9-a442-00163e07fb69 2Gi RWO csi-lvm 9m33s # kubectl get pv NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE lvm-7726e77b-eb2b-11e9-a442-00163e07fb69 3Gi RWO Delete Bound default/lvm-pvc csi-lvm 9m34s 原理：此时lvm数据卷并没有变化，只是pv对象的size变化；lvm卷大小和文件系统大小都是在pod启动挂载卷的时候执行扩容的。 重启Pod，实现lvm卷扩容： # kubectl delete pod deployment-lvm-cddcd84fb-5rkrj # kubectl get pvc NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE lvm-pvc Bound lvm-7726e77b-eb2b-11e9-a442-00163e07fb69 3Gi RWO csi-lvm 5m24s // Pod内部挂载的lvm卷也已经扩容到3G； # kubectl exec deployment-lvm-cddcd84fb-dsmxx df | grep data /dev/mapper/vgtest-lvm--7726e77b--eb2b--11e9--a442--00163e07fb69 3030800 6144 2861476 1% /data 登陆pod所在节点，查看lvm卷信息： # lvdisplay /dev/vgtest/lvm-7726e77b-eb2b-11e9-a442-00163e07fb69 --- Logical volume --- LV Path /dev/vgtest/lvm-7726e77b-eb2b-11e9-a442-00163e07fb69 LV Name lvm-7726e77b-eb2b-11e9-a442-00163e07fb69 VG Name vgtest LV UUID hKsRqO-oG1w-0uE1-6Unz-hpP9-le4N-pGVzDS LV Write Access read/write LV Creation host, time iZ8vb1wy4teeoa0ql4bjq3Z, 2019-10-10 14:59:23 +0800 LV Status available # open 1 LV Size 3.00 GiB Current LE 768 Segments 1 Allocation inherit Read ahead sectors auto - currently set to 256 Block device 252:3 更多使用细节请参考：https://github.com/kubernetes-sigs/alibaba-cloud-csi-driver/blob/v1.14/docs/lvm-resizer.md 欢迎加入CSI技术交流钉钉群：
K8S中手动扩容云盘数据卷 介绍： 云盘数据卷扩容包括以下几个部分： 云盘物理空间扩容，需要在云盘控制台操作；文件系统扩容，需要挂载云盘到一个物理节点手动操作；PV、PVC Size更新，需要更新StorageClass、PVC； 注意：扩容云盘前需要为云盘打快照，以预防升级失败导致数据丢失； 云盘目前无法做到在线扩容，需要重启应用才可以实现，可以通过两种方法实现云盘扩容。下面以集群中部署Zookeeper为例介绍两种扩容方式，Zookeeper集群如下： # kubectl get pod NAME READY STATUS RESTARTS AGE zookeeper-default-zookeeper-0 1/1 Running 0 2m55s zookeeper-default-zookeeper-1 1/1 Running 0 2m14s zookeeper-default-zookeeper-2 1/1 Running 0 94s # kubectl get pvc| grep zoo datadir-zookeeper-default-zookeeper-0 Bound d-8vb5teafaoa80ia7affg 20Gi RWO alicloud-disk-efficiency 3m12s datadir-zookeeper-default-zookeeper-1 Bound d-8vb60faf6epslbctnzka 20Gi RWO alicloud-disk-efficiency 2m31s datadir-zookeeper-default-zookeeper-2 Bound d-8vbidmq57w4df6k84zem 20Gi RWO alicloud-disk-efficiency 111s # kubectl get pv| grep zoo d-8vb5teafaoa80ia7affg 20Gi RWO Delete Bound default/datadir-zookeeper-default-zookeeper-0 alicloud-disk-efficiency 3m17s d-8vb60faf6epslbctnzka 20Gi RWO Delete Bound default/datadir-zookeeper-default-zookeeper-1 alicloud-disk-efficiency 2m33s d-8vbidmq57w4df6k84zem 20Gi RWO Delete Bound default/datadir-zookeeper-default-zookeeper-2 alicloud-disk-efficiency 107s 暂停应用方式： 如果应用可以暂停服务，可以先停掉应用（删除），手动对每个依赖数据盘进行扩容，然后再启动应用。缺点是：应用会暂停一定时间； 上面应用使用了3个20Gi的云盘，分别挂载在3个pod上。目标为把三个云盘扩容到30Gi，主要步骤： 删除应用负载； 云盘控制台在线扩容云盘； 挂载云盘到某节点进行文件系统扩容； 更新PV、PVC的Size参数； 重启应用； 1. 删除应用： 删除zookeeper statefulset对象； # kubectl delete sts zookeeper-default-zookeeper # kubectl get pvc | grep zoo datadir-zookeeper-default-zookeeper-0 Bound d-8vb6ie0kwtyynpf4gu4l 20Gi RWO alicloud-disk-efficiency 22m datadir-zookeeper-default-zookeeper-1 Bound d-8vbhscszlr47rbot0boc 20Gi RWO alicloud-disk-efficiency 21m datadir-zookeeper-default-zookeeper-2 Bound d-8vb444t0f8xnicj9c2ov 20Gi RWO alicloud-disk-efficiency 21m # kubectl get pv | grep zoo d-8vb444t0f8xnicj9c2ov 20Gi RWO Delete Bound default/datadir-zookeeper-default-zookeeper-2 alicloud-disk-efficiency 21m d-8vb6ie0kwtyynpf4gu4l 20Gi RWO Delete Bound default/datadir-zookeeper-default-zookeeper-0 alicloud-disk-efficiency 22m d-8vbhscszlr47rbot0boc 20Gi RWO Delete Bound default/datadir-zookeeper-default-zookeeper-1 alicloud-disk-efficiency 21m 2.3. 云盘扩容： 根据云盘文档，分别对3块云盘进行扩容： https://help.aliyun.com/document_detail/113316.html https://help.aliyun.com/document_detail/25452.html 注意：扩容云盘的同时也要完成对文件系统的扩容。 4. 扩容PV、PVC 编辑pvc、pv所使用的StorageClass，配置allowVolumeExpansion: true标签； # kubectl edit sc alicloud-disk-efficiency # kubectl get sc alicloud-disk-efficiency -o yaml allowVolumeExpansion: true apiVersion: storage.k8s.io/v1 kind: StorageClass metadata: creationTimestamp: "2019-09-05T12:30:27Z" name: alicloud-disk-efficiency resourceVersion: "1675896" selfLink: /apis/storage.k8s.io/v1/storageclasses/alicloud-disk-efficiency uid: f1071bcc-cfd8-11e9-81cd-00163e0804c2 parameters: type: cloud_efficiency provisioner: alicloud/disk reclaimPolicy: Delete volumeBindingMode: Immediate 更新PVC的Size为30Gi： # kubectl patch pvc datadir-zookeeper-default-zookeeper-0 -p '{"spec":{"resources":{"requests":{"storage":"30Gi"}}}}' persistentvolumeclaim/datadir-zookeeper-default-zookeeper-0 patched # kubectl patch pvc datadir-zookeeper-default-zookeeper-1 -p '{"spec":{"resources":{"requests":{"storage":"30Gi"}}}}' persistentvolumeclaim/datadir-zookeeper-default-zookeeper-1 patched # kubectl patch pvc datadir-zookeeper-default-zookeeper-2 -p '{"spec":{"resources":{"requests":{"storage":"30Gi"}}}}' persistentvolumeclaim/datadir-zookeeper-default-zookeeper-2 patched # kubectl get pvc | grep zoo datadir-zookeeper-default-zookeeper-0 Bound d-8vb6ie0kwtyynpf4gu4l 20Gi RWO alicloud-disk-efficiency 51m datadir-zookeeper-default-zookeeper-1 Bound d-8vbhscszlr47rbot0boc 20Gi RWO alicloud-disk-efficiency 50m datadir-zookeeper-default-zookeeper-2 Bound d-8vb444t0f8xnicj9c2ov 20Gi RWO alicloud-disk-efficiency 49m # kubectl get pv | grep zoo d-8vb444t0f8xnicj9c2ov 30Gi RWO Delete Bound default/datadir-zookeeper-default-zookeeper-2 alicloud-disk-efficiency 49m d-8vb6ie0kwtyynpf4gu4l 30Gi RWO Delete Bound default/datadir-zookeeper-default-zookeeper-0 alicloud-disk-efficiency 51m d-8vbhscszlr47rbot0boc 30Gi RWO Delete Bound default/datadir-zookeeper-default-zookeeper-1 alicloud-disk-efficiency 50m 可见pv的大小已经更新为30Gi，pvc的大小会在Pod启动后自动更新； 5. 重新创建应用： # kubectl get pod NAME READY STATUS RESTARTS AGE zookeeper-default-zookeeper-0 1/1 Running 0 94s zookeeper-default-zookeeper-1 1/1 Running 0 64s zookeeper-default-zookeeper-2 1/1 Running 0 39s # kubectl exec -ti zookeeper-default-zookeeper-0 sh # df -h |grep zoo /dev/vdb 30G 45M 30G 1% /var/lib/zookeeper # kubectl get pvc | grep zoo datadir-zookeeper-default-zookeeper-0 Bound d-8vb6ie0kwtyynpf4gu4l 30Gi RWO alicloud-disk-efficiency 56m datadir-zookeeper-default-zookeeper-1 Bound d-8vbhscszlr47rbot0boc 30Gi RWO alicloud-disk-efficiency 56m datadir-zookeeper-default-zookeeper-2 Bound d-8vb444t0f8xnicj9c2ov 30Gi RWO alicloud-disk-efficiency 55m # kubectl get pv | grep zoo d-8vb444t0f8xnicj9c2ov 30Gi RWO Delete Bound default/datadir-zookeeper-default-zookeeper-2 alicloud-disk-efficiency 55m d-8vb6ie0kwtyynpf4gu4l 30Gi RWO Delete Bound default/datadir-zookeeper-default-zookeeper-0 alicloud-disk-efficiency 56m d-8vbhscszlr47rbot0boc 30Gi RWO Delete Bound default/datadir-zookeeper-default-zookeeper-1 alicloud-disk-efficiency 56m 上面输出日志可以看出，文件系统已经扩容到30G，pv pvc的size也扩容到30G； 逐个Pod升级方式： 由多个Pod运行的服务，可以通过一个一个pod升级的方式实现业务不中断，而只是Running pod数量暂时减少。 还是以zookeeper为例，使用3个20Gi的云盘，分别挂载在3个pod上。目标为把三个云盘扩容到40Gi： 主要步骤： 修改某个Pod所对应pv的Zoneid label，然后删除pod； 登陆云盘控制台在线扩容云盘（扩容前最好对云盘打快照，容灾）； 挂载云盘到某节点进行文件系统扩容； 更新PV、PVC 的Size参数，以及Pv的ZoneId Lable； 对其他Pod重复1-4步骤； 1. 修改PV的ZoneId # kubectl get pod zookeeper-default-zookeeper-0 -oyaml | grep pers -C 1 - name: datadir persistentVolumeClaim: claimName: datadir-zookeeper-default-zookeeper-0 # kubectl get pvc datadir-zookeeper-default-zookeeper-0 NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE datadir-zookeeper-default-zookeeper-0 Bound d-8vbhscszlr47tgn0eheb 20Gi RWO alicloud-disk-efficiency 21m 上述日志得出zookeeper-default-zookeeper-0 使用的pvc为：datadir-zookeeper-default-zookeeper-0，对应的PV为d-8vbhscszlr47tgn0eheb； 更新PV Label， 如果pv中已经有如下label，则把zone对应的值改为”原来value -none“，即配置一个不存在的zone，让pod无法调度成功；如果pv中没有如下label，则添加这些lables到pv； #kubectl edit pv d-8vbhscszlr47tgn0eheb labels: failure-domain.beta.kubernetes.io/region: cn-zhangjiakou failure-domain.beta.kubernetes.io/zone: cn-zhangjiakou-a-none 删除Pod：zookeeper-default-zookeeper-0 # kubectl delete pod zookeeper-default-zookeeper-0 这时删除的pod一直处于Pending状态： # kubectl get pod NAME READY STATUS RESTARTS AGE zookeeper-default-zookeeper-0 0/1 Pending 0 9s zookeeper-default-zookeeper-1 1/1 Running 0 24m zookeeper-default-zookeeper-2 1/1 Running 0 24m 2.3. 云盘扩容： 根据云盘文档，分别对3块云盘进行库容： https://help.aliyun.com/document_detail/113316.html https://help.aliyun.com/document_detail/25452.html 注意：扩容云盘的同时也要完成对文件系统的扩容。 4. 扩容PV、PVC 编辑pvc、pv所使用的StorageClass，配置allowVolumeExpansion: true标签； # kubectl edit sc alicloud-disk-efficiency # kubectl get sc alicloud-disk-efficiency -o yaml allowVolumeExpansion: true apiVersion: storage.k8s.io/v1 kind: StorageClass metadata: creationTimestamp: "2019-09-05T12:30:27Z" name: alicloud-disk-efficiency resourceVersion: "1675896" selfLink: /apis/storage.k8s.io/v1/storageclasses/alicloud-disk-efficiency uid: f1071bcc-cfd8-11e9-81cd-00163e0804c2 parameters: type: cloud_efficiency provisioner: alicloud/disk reclaimPolicy: Delete volumeBindingMode: Immediate 更新PVC的Size为40Gi： # kubectl patch pvc datadir-zookeeper-default-zookeeper-0 -p '{"spec":{"resources":{"requests":{"storage":"40Gi"}}}}' persistentvolumeclaim/datadir-zookeeper-default-zookeeper-0 patched # kubectl get pvc | grep datadir-zookeeper-default-zookeeper-0 datadir-zookeeper-default-zookeeper-0 Bound d-8vbhscszlr47tgn0eheb 20Gi RWO alicloud-disk-efficiency 29m # kubectl get pv | grep datadir-zookeeper-default-zookeeper-0 d-8vbhscszlr47tgn0eheb 40Gi RWO Delete Bound default/datadir-zookeeper-default-zookeeper-0 alicloud-disk-efficiency 29m 可见pv的大小已经更新为40Gi，pvc的大小会在Pod启动后自动更新； 恢复PV的Lable，把zoneId的值恢复之前的value，删除相应labels（若之前没有这些labels）： labels: failure-domain.beta.kubernetes.io/region: cn-zhangjiakou failure-domain.beta.kubernetes.io/zone: cn-zhangjiakou-a 检查容器挂载文件系统大小，pv、pvc大小： # kubectl exec -ti zookeeper-default-zookeeper-0 sh # df -h | grep zoo /dev/vdb 40G 48M 40G 1% /var/lib/zookeeper # kubectl get pvc | grep datadir-zookeeper-default-zookeeper-0 datadir-zookeeper-default-zookeeper-0 Bound d-8vbhscszlr47tgn0eheb 40Gi RWO alicloud-disk-efficiency 33m # kubectl get pv | grep datadir-zookeeper-default-zookeeper-0 d-8vbhscszlr47tgn0eheb 40Gi RWO Delete Bound default/datadir-zookeeper-default-zookeeper-0 alicloud-disk-efficiency 33m 可见文件系统、pv、pvc都已经实现了扩容； 5. 对其他pod所对应的pvc、pv、云盘进行上述扩容
2020年01月
2019年11月
2019年10月
发表了文章
2019-10-24 14:17:20
发表了文章
2019-10-22 15:26:10
发表了文章
2019-10-10 15:47:42
2019年09月
2019年08月
2019年07月
发表了文章
2019-07-23 17:30:42
发表了文章
2019-07-16 21:53:51
发表了文章
2019-07-13 12:09:11
发表了文章
2019-07-12 13:39:33
发表了文章
2019-07-12 11:56:55
发表了文章
2019-07-12 11:34:27
发表了文章
2019-07-11 21:14:54
发表了文章
2019-07-10 19:50:53
发表了文章
2019-07-02 17:03:32
发表了文章
2020-01-19
发表了文章
2019-11-01
发表了文章
2019-10-24
发表了文章
2019-10-22
发表了文章
2019-10-10
发表了文章
2019-09-18
发表了文章
2019-09-11
发表了文章
2019-08-09
发表了文章
2019-08-02
发表了文章
2019-07-23
发表了文章
2019-07-16
发表了文章
2019-07-13
发表了文章
2019-07-12
发表了文章
2019-07-12
发表了文章
2019-07-12
发表了文章
2019-07-11
发表了文章
2019-07-10
发表了文章
2019-07-02
发表了文章
2019-06-19
发表了文章
2019-06-19
回答了问题
2015-09-28
回答了问题
2015-09-28
提交了问题
2015-09-25
回答了问题
2015-09-25
-------------------------
功能依然在添加，实现依然在优化，欢迎大家体验、反馈~~~
-------------------------
-------------------------
提交了问题
2015-09-24
提交了问题
2015-09-17
回答了问题
2015-08-27
回答了问题
2015-08-27
提交了问题
2015-08-27
回答了问题
2015-08-27
提交了问题
2015-08-27
提交了问题
2015-08-27
回答了问题
2015-08-25
-------------------------
-------------------------
-------------------------
-------------------------
-------------------------
-------------------------
-------------------------
提交了问题
2015-08-25
回答了问题
2015-08-25
回答了问题
2015-08-25
回答了问题
2015-08-24
-------------------------
回答了问题
2015-08-12
提交了问题
2015-08-12
提交了问题
2015-08-12
