教育行业网站建设审批,seo公司优化方案,网站建设排名政务,公司网站建设佛山哪家专业这是一个目录标题 一、Kurbernetes中的存储卷1.1 为什么需要存储卷#xff1f;1.2 存储卷概述1.2.1 简介1.2.2 volume字段 1.3 常用的存储卷类型1.3.1 emptyDir#xff08;临时存储卷#xff09;1.3.2 hostPath#xff08;节点存储卷#xff09;1.3.3 nfs1.3.4 cephfs 二、… 这是一个目录标题 一、Kurbernetes中的存储卷1.1 为什么需要存储卷1.2 存储卷概述1.2.1 简介1.2.2 volume字段 1.3 常用的存储卷类型1.3.1 emptyDir临时存储卷1.3.2 hostPath节点存储卷1.3.3 nfs1.3.4 cephfs 二、持久数据卷——PV和PVC2.1 概念2.2 PV的生命周期和状态2.3 访问模式 (Access Modes) 和回收策略 (Reclaim Policy) 三、静态创建PV3.1 创建思路3.2 创建实例NFS使用PV和PVCStep1 配置nfs存储Step2 定义PVStep3 定义PVCStep4 访问测试 四、动态创建PV4.1 创建思路4.2 StorageClass的概念4.3 Provisioner的概念4.4 实例NFS 的动态 PV 创建Step1 在master01节点上安装nfs并配置nfs服务Step2 创建 Service AccountStep3 使用 Deployment 创建 NFS Provisioner补充报错解决方法 Step4 创建 StorageClassStep5 创建 PVC 进行Pod 测试 五、小结5.1 PV、PVC的概念和状态5.2 静态和动态创建PV的思路 一、Kurbernetes中的存储卷
1.1 为什么需要存储卷
容器部署过程中一般有以下三种数据
• 启动时需要的初始数据例如配置文件 init container
• 启动过程中产生的临时数据该临时数据需要多个容器间共享
• 启动过程中产生的持久化数据例如MySQL的data目录 (业务数据–很重要) 而容器中的文件在磁盘上是临时存放的这给容器中运行比较重要的应用程序带来一些问题
问题1 数据持久化问题当容器升级或者崩溃时kubelet会重建容器容器内文件会丢失。
问题2 数据共享问题一个Pod中运行多个容器并需要共享文件。
Kubernetes中的数据卷Volume也可以称为存储卷能够解决这两个问题。
1.2 存储卷概述
1.2.1 简介
存储卷是用于持久化存储容器中数据的一种机制可以提供容器内持久化存储的能力使容器可以在不同的生命周期中保留数据。
数据卷与容器相互独立并且具有自己的生命周期。
当容器被销毁或重启时数据卷的内容仍然保持不变从而确保了容器内数据的持久性解决了问题1。
数据卷可以与一个或多个容器进行绑定使它们可以共享数据解决了问题2。
1.2.2 volume字段
Kubernetes中的Volume提供了在容器中挂载外部存储的能力
Pod需要设置卷来源volume和挂载点volumeMounts两个信息后才可以使用相应的Volume。
kubectl explain pod.spec.volumes常用字段名描述name指定数据卷的名称用于标识该数据卷不同类型的数据卷Kubernetes 支持不同类型的数据卷如 NFS、GCE Persistent Disk、AWS EBS等用于满足特定的存储需求
kubectl explain pod.spec.containers.volumeMounts常用字段名描述name指定要挂载的数据卷的名称mountPath指定挂载点的路径即将数据卷挂载到容器内的哪个目录readOnly指定挂载点是否为只读模式。如果设置为 true则容器只能读取挂载的数据不能写入
1.3 常用的存储卷类型
1.3.1 emptyDir临时存储卷 简介 emptyDir 卷可实现Pod中的容器之间共享目录数据但没有持久化数据的能力存储卷会随着Pod生命周期结束而一起删除。 emptyDir的一些用途 缓存空间例如基于磁盘的归并排序。为耗时较长的计算任务提供检查点以便任务能方便地从崩溃前状态恢复执行。在 Web 服务器容器服务数据时保存内容管理器容器获取的文件。 字段 kubectl explain pod.spec.volumes.emptyDiremptyDir.medium 字段用于控制 emptyDir 卷的存储位置有两个值Memory和Default。
值描述Memory表示将 emptyDir 卷存储在主机的内存中数据只存在于 Pod 的生命周期内并且不会被持久化到磁盘上Default表示将 emptyDir 卷存储在主机的磁盘中数据会在 Pod 重新启动时保留但不会在节点之间持久化
emptyDir.sizeLimit字段用于来限制卷的容量大小但是不会自动调整底层存储的大小。
因此如果设置的大小限制超过节点上的可用磁盘空间可能会导致 Pod 失败启动或运行时出现错误。 emptyDir 配置示例 apiVersion: v1
kind: Pod
metadata:name: test-pd
spec:containers:- image: registry.k8s.io/test-webservername: test-containervolumeMounts:- mountPath: /cachename: cache-volumevolumes:- name: cache-volumeemptyDir:sizeLimit: 500Mi1.3.2 hostPath节点存储卷
hostPath 卷将node节点上的目录/文件挂载到Pod容器的指定目录上。
有持久化数据的能力但只能在单个node节点上持久化数据不能实现跨node节点的Pod共享数据 hostPath卷配置示例 apiVersion: v1
kind: Pod
metadata:name: test-pd
spec:containers:- image: registry.k8s.io/test-webservername: test-containervolumeMounts:- mountPath: /test-pdname: test-volumevolumes:- name: test-volumehostPath:# 宿主机上目录位置path: /data# 此字段为可选type: Directory支持的 type 值如下
取值行为空字符串默认用于向后兼容这意味着在安装 hostPath 卷之前不会执行任何检查。DirectoryOrCreate如果在给定路径上什么都不存在那么将根据需要创建空目录权限设置为 0755具有与 kubelet 相同的组和属主信息。Directory在给定路径上必须存在的目录。FileOrCreate如果在给定路径上什么都不存在那么将在那里根据需要创建空文件权限设置为 0644具有与 kubelet 相同的组和所有权。File在给定路径上必须存在的文件。Socket在给定路径上必须存在的 UNIX 套接字。CharDevice在给定路径上必须存在的字符设备。BlockDevice在给定路径上必须存在的块设备。 补充FileOrCreate模式 FileOrCreate 模式不会负责创建文件的父目录。
如果欲挂载的文件的父目录不存在Pod 启动会失败。
为了确保这种模式能够工作可以尝试把文件和它对应的目录分开挂载如 FileOrCreate 配置所示。
apiVersion: v1
kind: Pod
metadata:name: test-webserver
spec:containers:- name: test-webserverimage: registry.k8s.io/test-webserver:latestvolumeMounts:- mountPath: /var/local/aaaname: mydir- mountPath: /var/local/aaa/1.txtname: myfilevolumes:- name: mydirhostPath:# 确保文件所在目录成功创建。path: /var/local/aaatype: DirectoryOrCreate- name: myfilehostPath:path: /var/local/aaa/1.txttype: FileOrCreate1.3.3 nfs
nfs卷使用nfs服务将存储卷挂载到Pod容器的指定目录上。
有持久化数据的能力且也能实现跨node节点的Pod共享数据。 nfs卷的配置示例 apiVersion: v1
kind: Pod
metadata:name: test-pd
spec:containers:- image: registry.k8s.io/test-webservername: test-containervolumeMounts:- mountPath: /my-nfs-dataname: test-volumevolumes:- name: test-volumenfs:server: my-nfs-server.example.compath: /my-nfs-volumereadOnly: true注意不能在 Pod spec 中指定 NFS 挂载可选项。
可以选择设置服务端的挂载可选项或者使用 /etc/nfsmount.conf。
此外还可以通过允许设置挂载可选项的持久卷挂载 NFS 卷。
1.3.4 cephfs
cephfs 卷允许将现存的 CephFS 卷挂载到 Pod 中。
cephfs 卷可以被预先填充数据且这些数据可以在 Pod 之间共享同一 cephfs 卷可同时被多个挂载。
apiVersion: v1
kind: Pod
metadata:name: cephfs
spec:containers:- name: cephfs-rwimage: kubernetes/pausevolumeMounts:- mountPath: /mnt/cephfsname: cephfsvolumes:- name: cephfscephfs:monitors:- 10.16.154.78:6789- 10.16.154.82:6789- 10.16.154.83:6789# by default the path is /, but you can override and mount a specific path of the filesystem by using the path attribute# path: /some/path/in/side/cephfsuser: adminsecretFile: /etc/ceph/admin.secretreadOnly: true二、持久数据卷——PV和PVC
2.1 概念 持久卷PersistentVolumePVK8S在指定的存储设备空间中逻辑划分创建出来的可持久化的存储资源对象。
持久卷声明PersistentVolumeClaimPVC对PV存储资源对象的请求和绑定也是Pod能够挂载使用的一种存储卷类型。
2.2 PV的生命周期和状态 生命周期 #PV和PVC之间的相互作用遵循这个生命周期
Provisioning配置--- Binding绑定--- Using使用--- Releasing释放 --- Recycling回收生命周期描述ProvisioningPV 的创建可以直接创建 PV静态方式也可以使用StorageClass 动态创建Binding将 PV 分配给 PVCUsingPod 通过 PVC 使用该 Volume并可以通过准入控制StorageProtection1.9及以前版本为PVCProtection 阻止删除正在使用的 PVCReleasingPod 释放 Volume 并删除 PVCReclaiming回收 PV可以保留 PV 以便下次使用也可以直接从云存储中删除 状态 PV的状态描述Available可用表示为可用状态PV已经被创建出来了但是还未被PVC绑定Bound已绑定表示PV已经被PVC绑定了PV与PVC是一对一的绑定关系Released已释放表示PVC被删除了但是PV还没被回收Failed失败表示PV被自动回收失败
2.3 访问模式 (Access Modes) 和回收策略 (Reclaim Policy) 访问模式 存储卷在挂载到宿主机系统上时可以设置不同的访问模式 (Access Modes。
支持的访问模式描述ReadWriteOnce (RWO)读写权限并且只能被单个Node挂载ReadOnlyMany (ROX)只读权限允许被多个Node挂载ReadWriteMany(RWX)读写权限允许被多个Node挂载 回收策略 通过PV定义中的persistentVolumeReclaimPolicy字段进行设置。
回收策略描述Retain保留保留数据需要手工处理Recycle回收简单清除文件的操作例如运行rm -rf /thevolume/*命令只有 NFS 和 HostPath 两种类型的 PV支持 Recycle 策略Delete删除与PV相连的后端存储完成Volume的删除操作AWSElasticBlockStore、 GCEPersistentDis、 AzureDisk和Cinder类型的PV支持 Delete策略
三、静态创建PV
3.1 创建思路
1准备好存储设备和共享目录
2准备yaml配置文件创建PV资源设置 存储类型、访问模式(RWO RWX ROX RWOP)、 空间大小、回收策略(Retain Delete Recycle) 、storageClassName等
3准备yaml配置文件创建PVC资源设置 访问模式(必要条件必须是PV能支持的访问模式)、空间大小(默认就近选择大于等于指定大小的PV) 、storageClassName等来绑定PV
4创建Pod资源挂载PVC存储卷设置存储卷类型为 persistentVolumeClaim 并在容器配置中定义存储卷挂载点目录。
3.2 创建实例NFS使用PV和PVC
Step1 配置nfs存储
#创建共享目录
mkdir /opt/test
cd /opt/test
mkdir v{1,2,3,4,5}#定义多个共享目录和对应的访问权限
vim /etc/exports/opt/test/v1 192.168.2.0/24(rw,no_root_squash)
/opt/test/v2 192.168.2.0/24(rw,no_root_squash)
/opt/test/v3 192.168.2.0/24(rw,no_root_squash)
/opt/test/v4 192.168.2.0/24(rw,no_root_squash)
/opt/test/v5 192.168.2.0/24(rw,no_root_squash)#重新加载共享目录应用修改
exportfs -arvshowmount -eStep2 定义PV
#这里定义5个PV并且定义挂载的路径以及访问模式还有PV划分的大小。
vim pv-demo.yamlapiVersion: v1
kind: PersistentVolume
metadata:name: pv001labels:name: pv001
spec:nfs:path: /opt/test/v1server: master01accessModes: [ReadWriteMany,ReadWriteOnce]capacity:storage: 1Gi
---
apiVersion: v1
kind: PersistentVolume
metadata:name: pv002labels:name: pv002
spec:nfs:path: /opt/test/v2server: master01accessModes: [ReadWriteOnce]capacity:storage: 2Gi
---
apiVersion: v1
kind: PersistentVolume
metadata:name: pv003labels:name: pv003
spec:nfs:path: /opt/test/v3server: master01accessModes: [ReadWriteMany,ReadWriteOnce]capacity:storage: 2Gi
---
apiVersion: v1
kind: PersistentVolume
metadata:name: pv004labels:name: pv004
spec:nfs:path: /opt/test/v4server: master01accessModes: [ReadWriteMany,ReadWriteOnce]capacity:storage: 4Gi
---
apiVersion: v1
kind: PersistentVolume
metadata:name: pv005labels:name: pv005
spec:nfs:path: /opt/test/v5server: master01accessModes: [ReadWriteMany,ReadWriteOnce]capacity:storage: 5Gikubectl apply -f pv-demo.yaml -n my-ns
kubectl get pv -n my-nsStep3 定义PVC
这里定义了pvc的访问模式为多路读写该访问模式必须在前面pv定义的访问模式之中。
定义PVC申请的大小为2Gi此时PVC会自动去匹配多路读写且大小为2Gi的PV匹配成功获取PVC的状态即为Bound。
vim pod-vol-pvc.yamlapiVersion: v1
kind: PersistentVolumeClaim
metadata:name: mypvcnamespace: my-ns
spec:accessModes: [ReadWriteMany]resources:requests:storage: 2Gi
---
apiVersion: v1
kind: Pod
metadata:name: pod-vol-pvcnamespace: my-ns
spec:containers:- name: myappimage: nginxvolumeMounts:- name: htmlmountPath: /usr/share/nginx/htmlvolumes:- name: htmlpersistentVolumeClaim:claimName: mypvckubectl apply -f pod-vol-pvc.yamlkubectl get pvkubectl get pvcStep4 访问测试
在存储服务器上创建index.html并写入数据通过访问Pod进行查看可以获取到相应的页面。
#创建测试页面
cd /opt/test/v3/
echo welcome to use pv3 index.htmlkubectl get pods -o wide -n my-ns#访问测试
firefox http://10.244.2.82四、动态创建PV
4.1 创建思路
1准备好存储设备和共享目录
2如果是外置存储卷插件需要先创建serviceaccount账户(Pod使用的账户)和做RBAC授权(创建角色授予相关资源对象的操作权限再将账户与角色进行绑定)使sa账户具有对PV PVC StorageClass等资源的操作权限
3准备yaml配置文件创建外置存储卷插件的Pod设置sa账户作为Pod的用户并设置相关的环境变量(比如存储卷插件名称);
4创建StorageClass(简称SC)资源provisioner自动设置为存储卷插件名称
以上操作是一劳永逸的之后只需要创建PVC资源时引用StorageClass就可以自动调用存储卷插件动态创建PV资源了5准备yaml配置文件创建PVC资源设置 访问模式、空间大小 storageClassName指定SC资源名称等来动态创建PV资源并绑定PV
6创建Pod资源挂载PVC存储卷设置存储卷类型为 persistentVolumeClaim 并在容器配置中定义存储卷挂载点目录。
4.2 StorageClass的概念
官方文档存储类 | Kubernetes 简介 存储类Storage Class 是 Kubernetes 中用于定义持久卷Persistent Volume的类型和行为的对象。
它定义了动态分配的存储和卷的属性并指定如何创建和管理这些存储资源。 关于默认的StorageClass 当一个 PVC 没有指定 storageClassName 时会使用默认的 StorageClass。 集群中只能有一个默认的 StorageClass。
如果不小心设置了多个默认的 StorageClass 当 PVC 动态配置时将使用最新设置的默认 StorageClass。 关于字段 每个 StorageClass 都包含 provisioner、parameters 和 reclaimPolicy 字段 这些字段会在 StorageClass 需要动态制备 PersistentVolume 时会使用到。 功能 1提供动态卷配置存储类可以与动态卷配置程序比如 CSI 驱动程序集成以便在创建 PVCPersistent Volume Claim时自动创建相应的 PVPersistent Volume。
2指定卷的参数 存储类可以定义卷的各种参数和配置选项如访问模式、卷大小、复制策略等。
3支持动态卷生命周期管理 存储类可以定义如何动态创建、扩容和销毁卷以及何时回收 PV 等。
4.3 Provisioner的概念
Provisioner存储分配器 卷插件用于指定 Volume 插件的类型包括内置插件如 kubernetes.io/aws-ebs和外部插件如 external-storage 提供的 ceph.com/cephfs。
详见https://kubernetes.io/zh/docs/concepts/storage/storage-classes/
Kubernetes 本身支持的动态 PV 创建不包括 NFS所以需要使用外部存储卷插件分配PV。
4.4 实例NFS 的动态 PV 创建
搭建 StorageClass nfs-client-provisioner 实现 NFS 的动态 PV 创建
Step1 在master01节点上安装nfs并配置nfs服务
#创建共享目录
mkdir /opt/test2
chmod 777 /opt/test2/#添加权限
vim /etc/exports
/opt/test2 192.168.2.0/24(rw,no_root_squash,sync)#重启NFS服务
systemctl restart nfsexportfs -var
showmount -eStep2 创建 Service Account
Service Account 用来管理 NFS Provisioner 在 k8s 集群中运行的权限设置nfs-client 对 PV、PVC、StorageClass 等的规则。
#编写配置清单文件
vim nfs-client-rbac.yaml#创建 Service Account 账户用来管理 NFS Provisioner 在 k8s 集群中运行的权限
apiVersion: v1
kind: ServiceAccount
metadata:name: nfs-client-provisioner
---
#创建集群角色
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:name: nfs-client-provisioner-clusterrole
rules:- apiGroups: []resources: [persistentvolumes]verbs: [get, list, watch, create, delete]- apiGroups: []resources: [persistentvolumeclaims]verbs: [get, list, watch, update]- apiGroups: [storage.k8s.io]resources: [storageclasses]verbs: [get, list, watch]- apiGroups: []resources: [events]verbs: [list, watch, create, update, patch]- apiGroups: []resources: [endpoints]verbs: [create, delete, get, list, watch, patch, update]
---
#集群角色绑定
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:name: nfs-client-provisioner-clusterrolebinding
subjects:
- kind: ServiceAccountname: nfs-client-provisionernamespace: default
roleRef:kind: ClusterRolename: nfs-client-provisioner-clusterroleapiGroup: rbac.authorization.k8s.io##配置清单文件详解##
用于创建一个 Service Account 账户和相关的 Role、RoleBinding用于管理 NFS Provisioner 在 Kubernetes 集群中的权限。首先创建了一个 Service Account 账户命名为 nfs-client-provisioner然后创建了一个 Cluster Role命名为 nfs-client-provisioner-clusterrole。
该角色定义了一组权限规则包括对持久卷persistentvolume的获取、列表、监视、创建和删除操作对持久卷声明persistentvolumeclaim的获取、列表、监视和更新操作对存储类storageclass的获取、列表和监视操作对事件events和端点endpoints的获取、列表、监视、创建、更新等操作。最后创建了一个 Cluster Role Binding将上述角色与之前创建的 Service Account 进行绑定并将其绑定到默认命名空间namespace中。kubectl apply -f nfs-client-rbac.yaml
#Service Account nfs-client-provisioner 具备了管理 NFS Provisioner 所需的权限。Step3 使用 Deployment 创建 NFS Provisioner
NFS Provisioner(即 nfs-client)有两个功能
1在 NFS 共享目录下创建挂载点(volume)另一个则是将 PV 与 NFS 的挂载点建立关联。编写资源配置清单文件 #编写配置清单文件
vim nfs-client-provisioner.yamlkind: Deployment
apiVersion: apps/v1
metadata:name: nfs-client-provisioner
spec:replicas: 1selector:matchLabels:app: nfs-client-provisionerstrategy:type: Recreatetemplate:metadata:labels:app: nfs-client-provisionerspec:serviceAccountName: nfs-client-provisioner #指定Service Account账户containers:- name: nfs-client-provisionerimage: quay.io/external_storage/nfs-client-provisioner:latestimagePullPolicy: IfNotPresentvolumeMounts:- name: nfs-client-rootmountPath: /persistentvolumesenv:- name: PROVISIONER_NAMEvalue: nfs-storage #配置provisioner的Name确保该名称与StorageClass资源中的provisioner名称保持一致- name: NFS_SERVERvalue: master01 #配置绑定的nfs服务器- name: NFS_PATHvalue: /opt/test2/ #配置绑定的nfs服务器目录volumes: #申明nfs数据卷- name: nfs-client-rootnfs:server: master01path: /opt/test2/创建 kubectl apply -f nfs-client-provisioner.yaml kubectl get po 补充报错解决方法
#由于 1.20 版本启用了 selfLink所以 k8s 1.20 版本通过 nfs provisioner 动态生成pv会报错解决方法如下
vim /etc/kubernetes/manifests/kube-apiserver.yaml
spec:containers:- command:- kube-apiserver- --feature-gatesRemoveSelfLinkfalse #添加这一行- --advertise-address192.168.2.100
.....kubectl apply -f /etc/kubernetes/manifests/kube-apiserver.yamlkubectl delete pods kube-apiserver -n kube-systemkubectl get pods -n kube-system | grep apiserverStep4 创建 StorageClass
负责建立 PVC 并调用 NFS provisioner 进行预定的工作并让 PV 与 PVC 建立关联。
#编写配置清单文件
vim nfs-client-storageclass.yamlapiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:name: nfs-client-storageclass
provisioner: nfs-storage #这里的名称要和provisioner配置文件中的环境变量PROVISIONER_NAME保持一致
parameters:archiveOnDelete: false #false表示在删除PVC时不会对数据目录进行打包存档即删除数据为ture时就会自动对数据目录进行打包存档存档文件以archived开头#声明式创建
kubectl apply -f nfs-client-storageclass.yamlkubectl get storageclassStep5 创建 PVC 进行Pod 测试 创建PVC vim test-pvc-pod.yamlapiVersion: v1
kind: PersistentVolumeClaim
metadata:name: test-nfs-pvc#annotations: volume.beta.kubernetes.io/storage-class: nfs-client-storageclass #另一种SC配置方式
spec:accessModes:- ReadWriteManystorageClassName: nfs-client-storageclass #关联StorageClass对象resources:requests:storage: 1Gi
---
apiVersion: v1
kind: Pod
metadata:name: test-storageclass-pod
spec:containers:- name: busyboximage: busybox:latestimagePullPolicy: IfNotPresentcommand:- /bin/sh- -cargs:- sleep 3600volumeMounts:- name: nfs-pvcmountPath: /mntrestartPolicy: Nevervolumes:- name: nfs-pvcpersistentVolumeClaim:claimName: test-nfs-pvc #与PVC名称保持一致kubectl apply -f test-pvc-pod.yamlkubectl get pvc 查看 NFS 服务器上是否生成对应的目录 自动创建的 PV 会以 ${namespace}-${pvcName}-${pvName} 的目录格式放到 NFS 服务器上。
ls /opt/test2Pod测试 测试思路 进入 Pod 在挂载目录 /mnt 下写一个文件然后查看 NFS 服务器上是否存在该文件。
#进入Pod创建测试文件
kubectl exec -it test-storageclass-pod sh/ # cd /mnt/
/mnt # echo this is test file test.txt#进入到目录
cd /opt/test2/default-test-nfs-pvc-pvc-7a63142b-a4b4-4f07-966c-828ca60bbdcb五、小结
5.1 PV、PVC的概念和状态 概念 PV K8S在指定的存储设备空间中逻辑划分创建出来的可持久化的存储资源对象。
PVC 对PV存储资源对象的请求和绑定也是Pod能够挂载使用的一种存储卷类型。 创建方式简介 手动根据PV资源的yaml配置文件创建静态PV。
根据PVC的配置通过StorageClass(简称SC)资源调用存储卷插件创建动态PV。 PV的4种状态 PV的状态描述Available可用表示为可用状态PV已经被创建出来了但是还未被PVC绑定Bound已绑定表示PV已经被PVC绑定了PV与PVC是一对一的绑定关系Released已释放表示PVC被删除了但是PV还没被回收Failed失败表示PV被自动回收失败
5.2 静态和动态创建PV的思路 创建使用静态PV 1准备好存储设备和共享目录
2准备yaml配置文件创建PV资源设置 存储类型、访问模式(RWO RWX ROX RWOP)、 空间大小、回收策略(Retain Delete Recycle) 、storageClassName等
3准备yaml配置文件创建PVC资源设置 访问模式(必要条件必须是PV能支持的访问模式)、空间大小(默认就近选择大于等于指定大小的PV) 、storageClassName等来绑定PV
4创建Pod资源挂载PVC存储卷设置存储卷类型为 persistentVolumeClaim 并在容器配置中定义存储卷挂载点目录。 创建使用动态PV 1准备好存储设备和共享目录
2如果是外置存储卷插件需要先创建serviceaccount账户(Pod使用的账户)和做RBAC授权(创建角色授予相关资源对象的操作权限再将账户与角色进行绑定)使sa账户具有对PV PVC StorageClass等资源的操作权限
3准备yaml配置文件创建外置存储卷插件的Pod设置sa账户作为Pod的用户并设置相关的环境变量(比如存储卷插件名称);
4创建StorageClass(简称SC)资源provisioner自动设置为存储卷插件名称
以上操作是一劳永逸的之后只需要创建PVC资源时引用StorageClass就可以自动调用存储卷插件动态创建PV资源了5准备yaml配置文件创建PVC资源设置 访问模式、空间大小 storageClassName指定SC资源名称等来动态创建PV资源并绑定PV
6创建Pod资源挂载PVC存储卷设置存储卷类型为 persistentVolumeClaim 并在容器配置中定义存储卷挂载点目录。
通过陈述式管理资源配置的方式 修改或添加资源对象的配置
kubectl patch 资源类型 资源名称 -p {第一层字段: {第二层字段: {....}}}kubectl patch deployment deploy-test -p {spec: {replicas: 0}}
kubectl patch deployment deploy-test -p {spec: {template: {spec: {containers: [{name: myapp, image: soscscs/myapp:v1}]}}}}创建使用动态PV 1准备好存储设备和共享目录
2如果是外置存储卷插件需要先创建serviceaccount账户(Pod使用的账户)和做RBAC授权(创建角色授予相关资源对象的操作权限再将账户与角色进行绑定)使sa账户具有对PV PVC StorageClass等资源的操作权限
3准备yaml配置文件创建外置存储卷插件的Pod设置sa账户作为Pod的用户并设置相关的环境变量(比如存储卷插件名称);
4创建StorageClass(简称SC)资源provisioner自动设置为存储卷插件名称
以上操作是一劳永逸的之后只需要创建PVC资源时引用StorageClass就可以自动调用存储卷插件动态创建PV资源了5准备yaml配置文件创建PVC资源设置 访问模式、空间大小 storageClassName指定SC资源名称等来动态创建PV资源并绑定PV
6创建Pod资源挂载PVC存储卷设置存储卷类型为 persistentVolumeClaim 并在容器配置中定义存储卷挂载点目录。
通过陈述式管理资源配置的方式 修改或添加资源对象的配置
kubectl patch 资源类型 资源名称 -p {第一层字段: {第二层字段: {....}}}kubectl patch deployment deploy-test -p {spec: {replicas: 0}}
kubectl patch deployment deploy-test -p {spec: {template: {spec: {containers: [{name: myapp, image: soscscs/myapp:v1}]}}}}
