一、PV/PVC/StorageClass简介

管理存储是管理计算的一个明显问题。该PersistentVolume子系统为用户和管理员提供了一个API，用于抽象如何根据消费方式提供存储的详细信息。为此，我们引入了两个新的API资源：PersistentVolume和PersistentVolumeClaim

PersistentVolume（PV）是集群中由管理员配置的一段网络存储。它是集群中的资源，就像节点是集群资源一样。 PV是容量插件，如Volumes，但其生命周期独立于使用PV的任何单个pod。此API对象捕获存储实现的详细信息，包括NFS，iSCSI或特定于云提供程序的存储系统。
PersistentVolumeClaim（PVC）是由用户进行存储的请求。它类似于pod。 Pod消耗节点资源，PVC消耗PV资源。Pod可以请求特定级别的资源（CPU和内存）。声明可以请求特定的大小和访问模式（例如，可以一次读/写或多次只读）。

虽然PersistentVolumeClaims允许用户使用抽象存储资源，但是PersistentVolumes对于不同的问题，用户通常需要具有不同属性（例如性能）。群集管理员需要能够提供各种PersistentVolumes不同的方式，而不仅仅是大小和访问模式，而不会让用户了解这些卷的实现方式。对于这些需求，有StorageClass 资源。

StorageClass为管理员提供了一种描述他们提供的存储的“类”的方法。不同的类可能映射到服务质量级别，或备份策略，或者由群集管理员确定的任意策略。 Kubernetes本身对于什么类别代表是不言而喻的。这个概念有时在其他存储系统中称为“配置文件”。

PVC和PV是一一对应的。

二、生命周期

PV是群集中的资源。PVC是对这些资源的请求，并且还充当对资源的检查。PV和PVC之间的相互作用遵循以下生命周期：

Provisioning => Binding =>Using=>Releasing=>Recycling

供应准备Provisioning—通过集群外的存储系统或者云平台来提供存储持久化支持。

静态提供Static：集群管理员创建多个PV。它们携带可供集群用户使用的真实存储的详细信息。它们存在于Kubernetes API中，可用于消费
动态提供Dynamic：当管理员创建的静态PV都不匹配用户的PersistentVolumeClaim时，集群可能会尝试为PVC动态配置卷。此配置基于StorageClasses：PVC必须请求一个类，并且管理员必须已创建并配置该类才能进行动态配置。要求该类的声明有效地为自己禁用动态配置。
绑定Binding—用户创建pvc并指定需要的资源和访问模式。在找到可用pv之前，pvc会保持未绑定状态。
使用Using—用户可在pod中像volume一样使用pvc。
释放Releasing—用户删除pvc来回收存储资源，pv将变成“released”状态。由于还保留着之前的数据，这些数据需要根据不同的策略来处理，否则这些存储资源无法被其他pvc使用。
回收Recycling—pv可以设置三种回收策略：保留（Retain），回收（Recycle）和删除（Delete）。
保留策略：允许人工处理保留的数据。
删除策略：将删除pv和外部关联的存储资源，需要插件支持。
回收策略：将执行清除操作，之后可以被新的pvc使用，需要插件支持。
注：目前只有NFS和HostPath类型卷支持回收策略，AWS EBS,GCE PD,Azure Disk和Cinder支持删除(Delete)策略。

三、pv的主要类型

GCEPersistentDisk
AWSElasticBlockStore
AzureFile
AzureDisk
FC (Fibre Channel)
Flexvolume
Flocker
NFS
iSCSI
RBD (Ceph Block Device)
CephFS
Cinder (OpenStack block storage)
Glusterfs
VsphereVolume
Quobyte Volumes
HostPath (Single node testing only – local storage is not supported in any way and WILL NOT WORK in a multi-node cluster)
Portworx Volumes
ScaleIO Volumes
StorageOS

四、pv卷阶段状态

Available – 资源尚未被claim使用
Bound – 卷已经被绑定到claim了
Released – claim被删除，卷处于释放状态，但未被集群回收。
Failed – 卷自动回收失败

案例1

存储对象以nfs为例，所以需要先配置好nfs，部署及配置过程此处就省略了

首先，nfs创建共享挂载目录
#mkdir -p /data/volumes/v{1,2,3,4,5}
echo “

NFS stor 01

” > v1/index.html
echo “

NFS stor 02

” > v2/index.html
echo “

NFS stor 03

” > v3/index.html
echo “

NFS stor 04

” > v4/index.html
echo “

NFS stor 05

” > v5/index.html

#exportfs -arv
#showmount -e

Export list for zeng-dptool:
/data/k8sdata        *
/data/volumes02      *
/data/volumes/v5     *
/data/volumes/v4     *
/data/volumes/v3     *
/data/volumes/v2     *
/data/volumes/v1     *
/data/k8s/prometheus *

编写资源文件，创建5个pv，存储大小各不相同，是否可读也不相同
#cat pv-damo.yaml

apiVersion: v1
kind: PersistentVolume
metadata:name: pv00001labels:name: pv00001
spec:nfs:path: /data/volumes/v1server: 192.168.1.77accessModes: ["ReadWriteMany","ReadWriteOnce"]capacity:storage: 2Gi
---
apiVersion: v1
kind: PersistentVolume
metadata:name: pv00002labels:name: pv00002
spec:nfs:path: /data/volumes/v2server: 192.168.1.77accessModes: ["ReadWriteOnce"]capacity:storage: 5Gi
---
apiVersion: v1
kind: PersistentVolume
metadata:name: pv00003labels:name: pv00003
spec:nfs:path: /data/volumes/v3server: 192.168.1.77accessModes: ["ReadWriteMany","ReadWriteOnce"]capacity:storage: 20Gi
---
apiVersion: v1
kind: PersistentVolume
metadata:name: pv00004labels:name: pv00004
spec:nfs:path: /data/volumes/v4server: 192.168.1.77accessModes: ["ReadWriteMany","ReadWriteOnce"]capacity:storage: 10Gi
---
apiVersion: v1
kind: PersistentVolume
metadata:name: pv00005labels:name: pv00005
spec:nfs:path: /data/volumes/v5server: 192.168.1.77accessModes: ["ReadWriteMany","ReadWriteOnce"]capacity:storage: 15Gi

#kubectl apply -f pv-damo.yaml
#kubectl get pv

NAME                                       CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS        CLAIM                          STORAGECLASS          REASON   AGE
grafana-pv01                               2Gi        RWO            Recycle          Bound         default/www-web-0              managed-nfs-storage            6d8h
pv00001                                    2Gi        RWO,RWX        Retain           Available                                                                   3d23h
pv00002                                    5Gi        RWO            Retain           Available                                                                   3d23h
pv00003                                    20Gi       RWO,RWX        Retain           Available                                                                   3d23h
pv00004                                    10Gi       RWO,RWX        Retain           Bound         default/mypvc                                                 3d23h
pv00005                                    15Gi       RWO,RWX        Retain           Available                                                                   3d23h

编写资源文件，创建一个pvc，需要6G存储；所以不会匹配pv00001、pv00002
#cat vol-pvc-demo.yaml

apiVersion: v1
kind: PersistentVolumeClaim
metadata:name: mypvcnamespace: default
spec:accessModes: ["ReadWriteMany"]resources:requests:storage: 6Gi
---
apiVersion: v1
kind: Pod
metadata:name: vol-pvcnamespace: default
spec:volumes:- name: htmlpersistentVolumeClaim:claimName: mypvccontainers:- name: myappimage: ikubernetes/myapp:v1volumeMounts:- name: htmlmountPath: /usr/share/nginx/html/

查询验证：pvc已经绑定到pv00004上
#kubectl get pvc

NAME                   STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS          AGE
grafana-pvc01          Bound    pv004                                      10Gi       RWO,RWX                              6d6h
mypvc                  Bound    pv00004                                    10Gi       RWO,RWX                              3d23h

获取服务pod的IP地址
#kubectl get pods -owide |grep vol-pvc

vol-pvc                                   1/1     Running     0          4d3h    192.168.124.73   zeng-k8s-nd03   <none>           <none>

查看是否是确实使用了nfs共享出来的挂载目录，正常情况如下：
#curl 192.168.124.73

<h1>NFS stor 04</h1>

**********************上面讲的案例属于静态手动创建及配置pv/pvc的情况

**********************下面讲的案例属于动态自动创建及配置pv/pvc的情况

五、StorageClass

1、什么是StorageClass

Kubernetes提供了一套可以自动创建PV的机制,即:Dynamic Provisioning.而这个机制的核心在于:StorageClass这个API对象.

StorageClass对象会定义下面两部分内容:

PV的属性.比如,存储类型,Volume的大小等.
创建这种PV需要用到的存储插件
有了这两个信息之后,Kubernetes就能够根据用户提交的PVC,找到一个对应的StorageClass,之后Kubernetes就会调用该StorageClass声明的存储插件,进而创建出需要的PV.
但是其实使用起来是一件很简单的事情,你只需要根据自己的需求,编写YAML文件即可,然后使用kubectl create命令执行即可
复制代码
2、为什么需要StorageClass
在一个大规模的Kubernetes集群里,可能有成千上万个PVC,这就意味着运维人员必须实现创建出这个多个PV,此外,随着项目的需要,会有新的PVC不断被提交,那么运维人员就需要不断的添加新的,满足要求的PV,否则新的Pod就会因为PVC绑定不到PV而导致创建失败.而且通过 PVC 请求到一定的存储空间也很有可能不足以满足应用对于存储设备的各种需求。
而且，不同的应用程序对于存储性能的要求可能也不尽相同，比如读写速度、并发性能等，为了解决这一问题，Kubernetes 又为我们引入了一个新的资源对象：StorageClass，通过 StorageClass 的定义，管理员可以将存储资源定义为某种类型的资源，比如快速存储、慢速存储等，用户根据 StorageClass 的描述就可以非常直观的知道各种存储资源的具体特性了，这样就可以根据应用的特性去申请合适的存储资源了。
3、StorageClass运行原理及部署流程
要使用 StorageClass，我们就得安装对应的自动配置程序，比如我们这里存储后端使用的是 nfs，那么我们就需要使用到一个 nfs-client 的自动配置程序，我们也叫它 Provisioner，这个程序使用我们已经配置好的 nfs 服务器，来自动创建持久卷，也就是自动帮我们创建 PV。
StorageClass是通过存储分配器（provisioner）来动态分配PV的，但是Kubernetes官方内置的存储分配器并不支持NFS，所以需要额外安装NFS存储分配器。
动创建的 PV 以namespace−{namespace}-namespace−{pvcName}-${pvName}这样的命名格式创建在 NFS 服务器上的共享数据目录中
而当这个 PV 被回收后会以archieved-namespace−{namespace}-namespace−{pvcName}-${pvName}这样的命名格式存在 NFS 服务器上。

搭建StorageClass+NFS,大致有以下几个步骤:
创建一个可用的NFS Serve
创建Service Account.这是用来管控NFS provisioner在k8s集群中运行的权限
创建StorageClass.负责建立PVC并调用NFS provisioner进行预定的工作,并让PV与PVC建立管理
创建NFS provisioner.有两个功能,一个是在NFS共享目录下创建挂载点(volume),另一个则是建了PV并将PV与NFS的挂载点建立关联

案例1：

环境：k8s v1.20.0
部署

首先，创建一个文件夹，用了统一存放相关的资源文件
mkdir -p /data/nfs-storage
创建rbac
#cat rbac.yaml

apiVersion: v1
kind: ServiceAccount
metadata:name: nfs-client-provisioner
---
kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:name: nfs-client-provisioner-runner
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: ["create", "update", "patch"]- apiGroups: [""]resources: ["endpoints"]verbs: ["get", "list", "watch", "create", "update", "patch"]
---
kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:name: run-nfs-client-provisioner
subjects:- kind: ServiceAccountname: nfs-client-provisionernamespace: default               #根据实际环境设定namespace,下面类同
roleRef:kind: ClusterRolename: nfs-client-provisioner-runnerapiGroup: rbac.authorization.k8s.io

创建存储分配器（provisioner）
#cat nfs-client-provisioner.yaml

apiVersion: apps/v1
kind: Deployment
metadata:name: nfs-client-provisionerlabels:app: nfs-client-provisionernamespace: default           #与RBAC文件中的namespace保持一致
spec:replicas: 1strategy:type: Recreateselector:matchLabels:app: nfs-client-provisionertemplate:metadata:labels:app: nfs-client-provisionerspec:serviceAccountName: nfs-client-provisionercontainers:- name: nfs-client-provisionerimage: quay.io/external_storage/nfs-client-provisioner:latestvolumeMounts:- name: nfs-client-rootmountPath: /persistentvolumesenv:- name: PROVISIONER_NAMEvalue: fuseim.pri/ifs      #provisioner名称,请确保该名称与 nfs-StorageClass.yaml文件中的provisioner名称保持一致- name: NFS_SERVERvalue: 192.168.1.77          #nfs server地址- name: NFS_PATHvalue: /data/k8sdata           #nfs server共享的挂载卷volumes:- name: nfs-client-rootnfs:server: 192.168.1.77            #nfs server地址path: /data/k8sdata            #nfs server共享的挂载卷

创建存储类(storageclass)
#cat storage-class.yaml

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:name: managed-nfs-storage
provisioner: fuseim.pri/ifs     #这里的名称要和provisioner配置文件中的环境变量PROVISIONER_NAME保持一致
parameters:archiveOnDelete: "false"

创建pvc和storageclass绑定
#cat pvc-for-storage-class.yaml

apiVersion: v1
kind: PersistentVolumeClaim
metadata:name: pvc-for-storageclass
spec:accessModes:- ReadWriteManystorageClassName: managed-nfs-storage       #和storage-class.yaml中的provisioner保持一致resources:requests:storage: 500Mi

#cd /data/nfs-storage && kubectl apply -f ./
#kubectl get pods |grep prov

nfs-client-provisioner-7887874b64-5fnzt   1/1     Running   2          3h34m

#kubectl get sc

NAME                  PROVISIONER      RECLAIMPOLICY   VOLUMEBINDINGMODE   ALLOWVOLUMEEXPANSION   AGE
managed-nfs-storage   fuseim.pri/ifs   Delete          Immediate           false                  3h33m
[root@zeng-k8s-ms01 nfs-storage03]# kubectl get pv
NAME                                       CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS        CLAIM                          STORAGECLASS          REASON   AGE
.....
pvc-0410ff17-5d36-42e9-8f5d-1c28e759a3c7   200Mi      RWO            Delete           Bound         default/www-web-1              managed-nfs-storage            52m
pvc-f39e0e49-465e-46dc-af30-6e27eec1acc1   10Mi       RWX            Delete           Bound         default/test-claim             managed-nfs-storage            3h33m
pvc-fdaa748b-f66d-4ca2-8540-9ddbaac0a936   500Mi      RWX            Delete           Bound         default/pvc-for-storageclass   managed-nfs-storage            3h33m
.....

#kubectl get pvc

.....
NAME                   STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS          AGE
pvc-for-storageclass   Bound    pvc-fdaa748b-f66d-4ca2-8540-9ddbaac0a936   500Mi      RWX            managed-nfs-storage   3h37m
www-web-0              Bound    grafana-pv01                               2Gi        RWO            managed-nfs-storage   53m
www-web-1              Bound    pvc-0410ff17-5d36-42e9-8f5d-1c28e759a3c7   200Mi      RWO            managed-nfs-storage   53m
.......

使用验证

方式一：直接调用storageclass

#cat nginx-statefulset.yaml

apiVersion: apps/v1
kind: StatefulSet
metadata:name: web
spec:selector:matchLabels:app: nginxserviceName: "nginx"replicas: 2template:metadata:labels:app: nginxspec:terminationGracePeriodSeconds: 10containers:- name: nginximage: hub.c.163.com/library/nginx:latestports:- containerPort: 80name: webvolumeMounts:- name: wwwmountPath: /usr/share/nginx/htmlvolumeClaimTemplates:- metadata:name: wwwspec:accessModes: [ "ReadWriteOnce" ]storageClassName: "managed-nfs-storage"          #和storage-class.yaml中的provisioner保持一致resources:requests:storage: 200Mi

创建服务：
#kubectl apply -f nginx-statefulset.yaml
服务运行正常，说明调用storegeclass进行数据持久化ok
#kubectl get pods

......
NAME                                      READY   STATUS    RESTARTS   AGE
nfs-client-provisioner-7887874b64-5fnzt   1/1     Running   2          3h44m
web-0                                     1/1     Running   0          57m
web-1                                     1/1     Running   0          57m
.....

方式二：调用pvc，通过pvc间接调用storageclass

#cat test-pod.yaml

kind: Pod
apiVersion: v1
metadata:name: test-pod
spec:containers:- name: test-podimage: busybox:1.24command:- "/bin/sh"args:- "-c"- "touch /mnt/SUCCESS && exit 0 || exit 1"   #创建一个SUCCESS文件后退出volumeMounts:- name: nfs-pvcmountPath: "/mnt"restartPolicy: "Never"volumes:- name: nfs-pvcpersistentVolumeClaim:claimName: pvc-for-storageclass    #与pvc-for-storage-class.yaml中的metadata.name名称保持一致

验证结果：
去对应文件里面去查看是否有“SUCCESS”这个文件，文件上级目录名称是按照namespace−{namespace}-namespace−{pvcName}-${pvName}规则创建的。
#ls /data/k8sdata/default-pvc-for-storageclass-pvc-fdaa748b-f66d-4ca2-8540-9ddbaac0a936/

SUCCESS

里面有一个 SUCCESS 的文件，证明我们上面的验证是成功

六、关于StorageClass回收策略对数据的影响

1、第一种配置

   #archiveOnDelete: "false"  #这个配置暂时没发现有什么作用，后期继续探究reclaimPolicy: Delete   #默认没有配置,默认值为Delete

测试结果:

pod删除重建后数据依然存在,旧pod名称及数据依然保留给新pod使用
sc删除重建后数据依然存在,旧pod名称及数据依然保留给新pod使用
删除PVC后,PV被删除且NFS Server对应数据被删除

2、第二种配置

   reclaimPolicy: Retain

测试结果:

pod删除重建后数据依然存在,旧pod名称及数据依然保留给新pod使用
sc删除重建后数据依然存在,旧pod名称及数据依然保留给新pod使用
删除PVC后,PV不会被删除,且状态由Bound变为Released,NFS Server对应数据被保留
重建sc后,新建PVC会绑定新的pv,旧数据可以通过拷贝到新的PV中

3、第三种配置

   #archiveOnDelete: "true"reclaimPolicy: Retain

结果:

pod删除重建后数据依然存在,旧pod名称及数据依然保留给新pod使用
sc删除重建后数据依然存在,旧pod名称及数据依然保留给新pod使用
删除PVC后,PV不会被删除,且状态由Bound变为Released,NFS Server对应数据被保留
重建sc后,新建PVC会绑定新的pv,旧数据可以通过拷贝到新的PV中

七、默认storageclass设置及使用

1、storageclass默认设置

方式一：命令行(patch)
#kubectl get sc

NAME                            PROVISIONER      RECLAIMPOLICY   VOLUMEBINDINGMODE   ALLOWVOLUMEEXPANSION   AGE
managed-nfs-storage   fuseim.pri/ifs   Delete          Immediate           false                  10m

#kubectl patch storageclass managed-nfs-storage -p ‘{“metadata”: {“annotations”:{“storageclass.kubernetes.io/is-default-class”:“true”}}}’ #设置managed-nfs-storage为默认后端存储

再次查看sc，发现多了个default标识
#kubectl get sc

NAME                            PROVISIONER      RECLAIMPOLICY   VOLUMEBINDINGMODE   ALLOWVOLUMEEXPANSION   AGE
managed-nfs-storage (default)   fuseim.pri/ifs   Delete          Immediate           false                  10m

取消也很简单，将“true”改为“false”即可
#kubectl patch storageclass managed-nfs-storage -p ‘{“metadata”: {“annotations”:{“storageclass.kubernetes.io/is-default-class”:“false”}}}’ #取消默认存储后端

方式二：直接修改sc的资源文件，添加注解
cat storage-class.yaml

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:name: managed-nfs-storageannotations:"storageclass.kubernetes.io/is-default-class": "true"   #添加此注释
provisioner: fuseim.pri/ifs
parameters:#archiveOnDelete: "true"
reclaimPolicy: Retain   #只有NFS 和hostPth支持两种回收策略

2、默认storageclass使用

如果集群有一个默认的StorageClass能够满足我们的需求，那么剩下所有需要做的就是创建PersistentVolumeClaim(PVC)，剩下的都有默认的动态配置搞定，包括无需去指定storageClassName

例子1:
#cat test-default-pvc.yaml

apiVersion: v1
kind: PersistentVolumeClaim
metadata:name: testpvcnamespace: default
spec:accessModes:- ReadWriteOnceresources:requests:storage: 10Mi

#kubectl apply -f test-default-pvc.yaml
#kubectl get pvc |grep testpvc

testpvc                Bound    pvc-1462f59e-f3e4-43ec-8659-b6d8830ca51e   10Mi       RWO            managed-nfs-storage   151m

正常情况可以看到，pv通过默认的storageclass被动态配置了
#kubectl get pv |grep testpvc

pvc-1462f59e-f3e4-43ec-8659-b6d8830ca51e   10Mi       RWO            Delete           Bound         default/testpvc                managed-nfs-storage            153m

八、其他

如果没有默认的StorageClass对象，那么PersistentVolumeClaim对象（在不指定StorageClass情况下）将不会自动触发动态配置。
如果一个卷是动态配置的卷，且默认的回收策略为“删除”，这意味着，在默认的情况下，当PVC被删除时，基础的PV和对应的存储也会被删除。如果需要保留存储在卷上的数据，则必须在PV被设置之后将回收策略从“Delete”更改为“Retain”。
静态时，PVC与PV绑定时会根据storageClassName（存储类名称）和accessModes（访问模式）判断哪些PV符合绑定需求。然后再根据存储量大小判断，首先存PV储量必须大于或等于PVC声明量；其次就是PV存储量越接近PVC声明量，那么优先级就越高（PV量越小优先级越高）。
“使用中的存储对象保护” ：该功能的目的是确保在Pod活动时使用的PersistentVolumeClaims (PVC)和绑定到PVC的PersistentVolume (PV)不会从系统中删除，因为这可能会导致数据丢失。
如果用户删除了Pod正在使用的PVC，则不会立即删除该PVC；PVC的清除被推迟，直到任何Pod不再主动使用PVC。另外，如果管理员删除绑定到PVC的PV，则不会立即删除该PV；PV的去除被推迟，直到PV不再与PVC结合。表现形式就是命令一直卡住不动，如下图：

直到pvc(或pv)对应的pod不存在了或不活动了，命令才会结束。
===========================================================

问题汇总：

1、错误一

问题描述：通过storageclass自动创建pv不成功，pvc显示pending状态
#kubectl get pvc

.........
NAME                   STATUS    VOLUME    CAPACITY   ACCESS MODES   STORAGECLASS          AGE
pvc-for-storageclass   Pending                                       managed-nfs-storage   13s
test-claim             Pending                                       managed-nfs-storage   87m

查看处于pending状态的pvc详情
#kubectl describe pvc pvc-for-storageclass

.........
Events:Type    Reason                Age               From                         Message----    ------                ----              ----                         -------Normal  ExternalProvisioning  4s (x4 over 39s)  persistentvolume-controller  waiting for a volume to be created, either by external provisioner "fuseim.pri/ifs" or manually created by system administrator

问题原因：Kubernetes v1.20 (opens new window)开始，默认删除了 metadata.selfLink 字段，然而，部分应用仍然依赖于这个字段，例如 nfs-client-provisioner
解决方案：
通过配置 apiserver 启动参数中的 –feature-gates 中的 RemoveSelfLink=false，可以重新启用 metadata.selfLink 字段。
修改/etc/kubernetes/manifests/kube-apiserver.yaml 文件，添加添加- --feature-gates=RemoveSelfLink=false
#grep -B 5 ‘feature-gates’ /etc/kubernetes/manifests/kube-apiserver.yaml

    - --service-account-key-file=/etc/kubernetes/pki/sa.pub- --service-account-signing-key-file=/etc/kubernetes/pki/sa.key- --service-cluster-ip-range=10.96.0.0/12- --tls-cert-file=/etc/kubernetes/pki/apiserver.crt- --tls-private-key-file=/etc/kubernetes/pki/apiserver.key- --feature-gates=RemoveSelfLink=false #添加内容

下面命令执行一次如果报错，就执行两次
#kubectl apply -f /etc/kubernetes/manifests/kube-apiserver.yaml
#kubectl apply -f /etc/kubernetes/manifests/kube-apiserver.yaml

认识PV/PVC/StorageClass相关推荐

[Kubernetes]PV,PVC,StorageClass实战----|||
第一篇: [Kubernetes]PV,PVC,StorageClass实战----| 第二篇: [Kubernetes]PV,PVC,StorageClass实战----|| 官网 Storage ...
资源利用率监控与存储卷（pv/pvc）
官网:https://kubernetes.io/zh/ 一.资源利用率的概述 k8s容器创建的时候是随机分配的,如果随机分配时,有一个节点分配得比较多时,则会出现卡顿等等的事情: 1.metrics ...
k8s mysql pv_k8s+mysql+pv+pvc+NFS实现mysql容器编排
k8s+mysql+pv+pvc+NFS实现mysql容器编排首先需要介绍概念:pv和pvc PV 是集群提供的一种存储资源,是实际可用的磁盘.和挂 PV 的 Pod 有着独立的生命周期,Pod 销 ...
k8s-----（| 三 |）存储Volume卷，PV / PVC,nfs持久化
文章目录一. 存储Volume 卷 1. emptyDir本地临时卷 2. hostPath 本地卷二 . PV/PVC 1. 概念 2. PV 一些概念 (1)PV 的类型(插件) (2)访问模 ...
Kubernetes PV/PVC/StroageClass 持久化存储简介
2019独角兽企业重金招聘Python工程师标准>>> PersistentVolume(简称PV)和PersistentVolumeClaim(简称PVC) PersistentV ...
Kubernetes Volume及其类型（NFS、SAN） - PV - PVC - PV与PVC与Pod的关系
目录 volume 卷官方文档:卷 | Kubernetes 一.emptyDir(临时卷) 二.hostPath卷 type字段参数 hostPath 实验: 三.第3方提供的存储卷(百度云.阿里 ...
PV PVC - 每天5分钟玩转 Docker 容器技术（150）
Volume 提供了非常好的数据持久化方案,不过在可管理性上还有不足. 拿前面 AWS EBS 的例子来说,要使用 Volume,Pod 必须事先知道如下信息: 当前 Volume 来自 AWS EB ...
Kubernetes-卷/存储卷（emptyDir/hostPath/pv/pvc）（十）
1 卷的介绍 1.1 卷的概念在搞容器的时候,我们在处理完应用如何起,如何运行,最终落实到数据的时候,我们又要考虑2个问题:容器是如何访问外部磁盘存储的?容器之间如何共享存储空间?在一些场景下, ...
【K8S】k8s pv,pvc无法删除问题
一般删除步骤为:先删pod再删pvc最后删pv. 遇到的问题但是遇到pv始终处于"Terminating"状态,而且删不掉.如下图: 解决方法直接删除k8s中的记录: kube ...
k8s pv pvc
综述持久化卷(Persistent Volume, PV)允许用户将外部存储映射到集群,而持久化卷申请(Persistent Volume Claim, PVC)则类似于许可证,使有授权的应用(Po ...

认识PV/PVC/StorageClass