k8s挂载storageclass

发布时间 2023-03-23 22:52:08作者: lzjasd

k8s挂载storageclass

概念定义

pv pvc storageclass

PV 是群集中的资源。 PVC 是对这些资源的请求

pv 的供应方式 可以通过两种方式配置 PV:静态或动态。

绑定 用户创建 pvc 并指定需要的资源和访问模式。在找到可用 pv 之前,pvc 会保持未绑定状态

回收策略 当我们创建 pod 时如果使用 pvc 做为存储卷,那么它会和 pv 绑定,当删除 pod,pvc 和 pv 绑定 就会解除,解除之后和 pvc 绑定的 pv 卷里的数据需要怎么处理,目前,卷可以保留,回收或删除: Retain Recycle (不推荐使用,1.15 可能被废弃了) Delete 1、Retain 当删除 pvc 的时候,pv 仍然存在,处于 released 状态,但是它不能被其他 pvc 绑定使用,里面的 数据还是存在的,当我们下次再使用的时候,数据还是存在的,这个是默认的回收策略 Delete 删除 pvc 时即会从 Kubernetes 中移除 PV,也会从相关的外部设施中删除存储资产

创建静态pv

Kubernetes 提供一种自动创建 PV 的机制,叫 StorageClass,它的作用就是创建 PV 的模板。k8s 集 群管理员通过创建 storageclass 可以动态生成一个存储卷 pv 供 k8s pvc 使用

每个 StorageClass 都包含字段 provisioner,parameters 和 reclaimPolicy。

provisioner:供应商,storageclass 需要有一个供应者,用来确定我们使用什么样的存储来创 建 pv,常见的 provisioner 如下 https://kubernetes.io/zh/docs/concepts/storage/storage-classes/):

provisioner 既可以由内部供应商提供,也可以由外部供应商提供,如果是外部供应商可以参考 https://github.com/kubernetes-incubator/external-storage/下提供的方法创建。

以 NFS 为例,要想使用 NFS,我们需要一个 nfs-client 的自动装载程序,称之为 provisioner,这 个程序会使用我们已经配置好的 NFS 服务器自动创建持久卷,也就是自动帮我们创建 PV。

StorageClass 会定义以下两部分: 1、PV 的属性 ,比如存储的大小、类型等; 2、创建这种 PV 需要使用到的存储插件,比如 Ceph、NFS 等

有了这两部分信息,Kubernetes 就能够根据用户提交的 PVC,找到对应的 StorageClass,然后 Kubernetes 就会调用 StorageClass 声明的存储插件,创建出需要的 PV。

reclaimPolicy:回收策略 allowVolumeExpansion:允许卷扩展,PersistentVolume 可以配置成可扩展。将此功能设置为 true 时,允许用户通过编辑相应的 PVC 对象来调整卷大小。当基础存储类的 allowVolumeExpansion 字段设置为 true 时,以下类型的卷支持卷扩展

storageclass

外部驱动 https://github.com/kubernetes-retired/external-storage

https://github.com/kubernetes-sigs/sig-storage-lib-external-provisioner

sudo docker login --username=13691430187 registry.cn-hangzhou.aliyuncs.com

archiveOnDelete: "false" storageclass 定义的字段,value=false当删除pod的时候,pv的数据也会删除,value=true 当删除pod的时候,pv的数据不会删除,也就是nfs上的数据不会删除。

在apply -f storageclass pvc 之后,发现数据卷没有被绑定的时候

 /etc/kubernetes/manifests/kube-apiserver.yaml
这个是k8s 2.0之前需要设置的
- --feature-gates=RemoveSelfLink=false
当前的是k8s 1.26.2版本
不需要设置,selflink字段已经被弃用,所以上面的设置会导致服务启动不了,服务关闭,执行
kubectl get nodes 命令,会因为访问不到6443端口的api报错。

docker pull 相关参数

-a :拉取所有 tagged 镜像

--disable-content-trust :忽略镜像的校验,默认开启

imagePullPolicy: IfNotPresent 镜像下载策略,先从本地找,本地没有从镜像仓库下载

CrashLoopBackOff:

Back-off restarting failed container nfs-client-provisioner

默认情况下,pod 的重启策略是 Always,这意味着它应该总是在失败时重启(其他选项是 Never 或 OnFailure)。根据 pod 模板中定义的重启策略,Kubernetes 可能会多次尝试重启 pod。

每次 pod 重新启动时,Kubernetes 等待的时间越来越长,称为“退避延迟”。在此过程中,Kubernetes 会显示 CrashLoopBackOff 错误

Kubernetes 集群中的 pod 显示 CrashLoopBackOff 消息的一个常见原因是 Kubernetes 出现了不推荐使用的 Docker 版本。您可以使用 -v 检查容器化工具来显示 Docker 版本。

修复此错误的最佳做法是确保您拥有最新的 Docker 版本和其他插件的最稳定版本。因此,您可以防止使容器陷入启动失败循环的弃用命令和不一致。

将项目迁移到 Kubernetes 集群时,您可能需要回滚多个 Docker 版本以满足传入项目的版本。

NFS subdir external provisioner 是一个自动配置器,它使用您现有的和已配置的 NFS 服务器来支持通过 Persistent Volume Claims 动态配置 Kubernetes Persistent Volumes。持久卷配置为 ${namespace}-${pvcName}-${pvName}。

注意:此存储库是从 https://github.com/kubernetes-incubator/external-storage/tree/master/nfs-client 迁移过来的。作为迁移的一部分:

容器镜像名称和存储库已分别更改为 registry.k8s.io/sig-storage 和 nfs-subdir-external-provisioner。 为了保持与早期部署文件的向后兼容性,NFS Client Provisioner 的命名在部署 YAML 中保留为 nfs-client-provisioner。 此存储库的待开发领域之一是添加自动化 e2e 测试。如果您想做出贡献,请提出问题或通过 Kubernetes slack #sig-storage 频道联系我们。

查找到出问题的apiservice

kubectl get apiservice 可以看到其中有出现false状态的apiservice,删除出问题的apiservice故障即可解决。

2、删除出问题的apiservice

kubectl delete apiservce <service-name>

要试用kubectl top,这个命令需要有对应的metrics接口,如果不安装metrics-server,使用top命令查看Pod的CPU、内存使用过程中,会遇到以下问题

error: Metrics API not available https://www.huweihuang.com/kubernetes-notes/code-analysis/kubelet/syncPod.html https://github.com/kubernetes-sigs/metrics-server

wget https://github.com/kubernetes-sigs/metrics-server/releases/latest/download/components.yaml -O metrics-server-components.yaml

sed -i 's/k8s.gcr.io\/metrics-server/registry.cn-hangzhou.aliyuncs.com\/google_containers/g' metrics-server-components.yaml

etcdserver: request timed out

etcd 是要进行大量读写操作的,磁盘io一定要跟得上,否则etcd不稳定,进而会引起kubernetes集群不稳定,进而引发业务不稳定一系列的问题。所以将电脑直接关机,重新启动程序

强制删除pod

--force --grace-period=0 --namespace=default

kubectl get all -A 查看所有的资源

驱逐节点操作

drain 驱逐node3 上的pod 设置节点为不可用

kubectl get pods 查看运行的pod 通过yaml 删除pod (这些pod是有问题的) uncordon 恢复node节点 kubectl uncordon node3

kubectl explain StorageClass.metadata.selfLink

selfLink是一个遗留的只读字段,不再是由系统填充。

selfLink:通过API访问资源自身的URL,例如一个Pod的link可能是/api/v1/namespaces/ns36aa8455/pods/sc-cluster-test-1-6bc58d44d6-r8hld

DefaultStorageClass PVC和PV的绑定是通过StorageClassName进行的。然而如果定义PVC时没有指定StorageClassName呢?这取决与admission插件是否开启了DefaultDefaultStorageClass功能:

如果DefaultDefaultStorageClass功能开启,那么此PVC的StorageClassName就会被指定为DefaultStorageClass。DefaultStorageClass从何处而来呢?原来在定义StorageClass时,可以在Annotation中添加一个键值对:storageclass.kubernetes.io/is-default-class: true,那么此StorageClass就变成默认的StorageClass了。 如果DefaultDefaultStorageClass功能没有开启,那么没有指定StorageClassName的PVC只能被绑定到同样没有指定StorageClassName的PV。 查看了我们环境中的storageclass 定义,发现没有开启DefaultDefaultStorageClass功能

controller

包含 Provisioner 接口和 ProvisionController,一个监视 PersistentVolumes 和 PersistentVolumeClaims 的自定义 Kubernetes 控制器。实现 Provisioner 接口,将实现传递给 ProvisionController,然后运行控制器,然后根据需要调用 Provisioner 的 Provision 或 Delete。

特性门是一组描述 Kubernetes 特性的键=值对。您可以使用每个 Kubernetes 组件上的 --feature-gates 命令行标志打开或关闭这些功能。

每个 Kubernetes 组件都允许您启用或禁用一组与该组件相关的功能门控。使用 -h 标志查看所有组件的全套功能门控。要为组件(例如 kubelet)设置功能门控,请使用分配给功能对列表的 --feature-gates 标志:

--feature-gates=...,GracefulNodeShutdown=true

CrossNamespaceVolumeDataSource:启用跨名字空间卷数据源,以允许你在 PersistentVolumeClaim 的 dataSourceRef 字段中指定一个源名字空间

persistentVolumeClaim---简称pvc persistentVolumeClaim 卷用来将持久卷(PersistentVolume)挂载到 Pod 中。 持久卷申领(PersistentVolumeClaim)是用户在不知道特定云环境细节的情况下“申领”持久存储(例如 GCE PersistentDisk 或者 iSCSI 卷)的一种方法。

只有当 PVC 的存储类中将 allowVolumeExpansion 设置为 true 时,你才可以扩充该 PVC 申领。

如果要为某 PVC 请求较大的存储卷,可以编辑 PVC 对象,设置一个更大的尺寸值。 这一编辑操作会触发为下层 PersistentVolume 提供存储的卷的扩充。 Kubernetes 不会创建新的 PV 卷来满足此申领的请求。 与之相反,现有的卷会被调整大小

kube apiserver 相关接口文档 https://kubernetes.io/zh-cn/docs/reference/command-line-tools-reference/kube-apiserver/

动态制备 如果管理员所创建的所有静态 PV 卷都无法与用户的 PersistentVolumeClaim 匹配, 集群可以尝试为该 PVC 申领动态制备一个存储卷。 这一制备操作是基于 StorageClass 来实现的:PVC 申领必须请求某个 存储类, 同时集群管理员必须已经创建并配置了该类,这样动态制备卷的动作才会发生。 如果 PVC 申领指定存储类为 "",则相当于为自身禁止使用动态制备的卷。

为了基于存储类完成动态的存储制备,集群管理员需要在 API 服务器上启用 DefaultStorageClass 准入控制器。 举例而言,可以通过保证 DefaultStorageClass 出现在 API 服务器组件的 --enable-admission-plugins 标志值中实现这点;该标志的值可以是逗号分隔的有序列表。 关于 API 服务器标志的更多信息,可以参考 kube-apiserver 文档。

卷绑定模式 volumeBindingMode 字段控制了卷绑定和动态制备应该发生在什么时候。 当未设置时,默认使用 Immediate 模式。

Immediate 模式表示一旦创建了 PersistentVolumeClaim 也就完成了卷绑定和动态制备。 对于由于拓扑限制而非集群所有节点可达的存储后端,PersistentVolume 会在不知道 Pod 调度要求的情况下绑定或者制备。

集群管理员可以通过指定 WaitForFirstConsumer 模式来解决此问题。 该模式将延迟 PersistentVolume 的绑定和制备,直到使用该 PersistentVolumeClaim 的 Pod 被创建。 PersistentVolume 会根据 Pod 调度约束指定的拓扑来选择或制备。 这些包括但不限于资源需求、 节点筛选器、 Pod 亲和性和互斥性、 以及污点和容忍度。

annotations: volume.beta.kubernetes.io/storage-class: managed-nfs-storage pvc挂载storageclass annotations: storageclass.kubernetes.io/is-default-class: "true" 设置为默认存储类

 

 

操作

nfs外部驱动器

https://github.com/kubernetes-sigs/nfs-subdir-external-provisioner/tree/v4.0.2/deploy

需要下载deployment.yaml中的镜像

修改nfs的serverIP ,以及path路径

参考的资料

https://www.youtube.com/watch?v=DF3v2P8ENEg


从外部驱动器下载的文件
ls
class.yaml deployment.yaml export.sh nfs-subdir-external-provisioner_v4.0.1.tar rbac.yaml test-claim.yaml test-pod.yaml


nfs-subdir-external-provisioner_v4.0.1.tar 这个是需要的镜像,打包后的

[root@master ~]# kubectl get sa
NAME                     SECRETS   AGE
default                 0         6h34m
nfs-client-provisioner   0         172m
[root@master ~]# kubectl get sc
NAME                 PROVISIONER                                   RECLAIMPOLICY   VOLUMEBINDINGMODE   ALLOWVOLUMEEXPANSION   AGE
managed-nfs-storage   k8s-sigs.io/nfs-subdir-external-provisioner   Delete         Immediate           false                 172m
[root@master ~]# kubectl get pv
NAME                                       CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS   CLAIM               STORAGECLASS         REASON   AGE
pvc-51d59209-8900-41c0-84db-0217217761f1   1Mi       RWX           Delete           Bound   default/test-claim   managed-nfs-storage           172m
[root@master ~]# kubectl get pvc
NAME         STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS         AGE
test-claim   Bound   pvc-51d59209-8900-41c0-84db-0217217761f1   1Mi       RWX           managed-nfs-storage   172m
[root@master ~]# kubectl get pods
NAME                                     READY   STATUS     RESTARTS       AGE
nfs-client-provisioner-6b76d84db7-h4cws   1/1     Running     3 (109m ago)   172m
test-pod                                 0/1     Completed   0             171m


 

导出镜像

img_list=`docker images|grep -v "REPOSITORY"|wc -l`
for tmp in $(seq $img_list);do
echo $tmp
#image_name="docker images|grep -v \"REPOSITORY\"|awk 'NR==$tmp {print $1} ' "
image_name=`docker images|grep -v "REPOSITORY"|awk -v var=$tmp 'NR==var {print $1} ' `
image_version=`docker images|grep -v "REPOSITORY"|awk -v var=$tmp 'NR==var {print $2} ' `

#echo $image_name":"$image_version
imge_tmp=$image_name":"$image_version
#cd /data/img/
# docker export  
echo $imge_tmp
# registry.aliyuncs.com/google_containers/kube-proxy
img_tar=`echo $image_name|awk -F"/" '{print $NF}'`_$image_version.tar
echo $img_tar
cd /data/img/
docker save -o $img_tar $imge_tmp
done

 

相关

 kubectl get apiservice
NAME                                   SERVICE                       AVAILABLE   AGE
v1.                                   Local                         True       6h23m
v1.admissionregistration.k8s.io       Local                         True       6h23m
v1.apiextensions.k8s.io               Local                         True       6h23m
v1.apps                               Local                         True       6h23m
v1.authentication.k8s.io               Local                         True       6h23m
v1.authorization.k8s.io               Local                         True       6h23m
v1.autoscaling                         Local                         True       6h23m
v1.batch                               Local                         True       6h23m
v1.certificates.k8s.io                 Local                         True       6h23m
v1.coordination.k8s.io                 Local                         True       6h23m
v1.crd.projectcalico.org               Local                         True       4h37m
v1.discovery.k8s.io                   Local                         True       6h23m
v1.events.k8s.io                       Local                         True       6h23m
v1.networking.k8s.io                   Local                         True       6h23m
v1.node.k8s.io                         Local                         True       6h23m
v1.operator.tigera.io                 Local                         True       4h37m
v1.policy                             Local                         True       6h23m
v1.rbac.authorization.k8s.io           Local                         True       6h23m
v1.scheduling.k8s.io                   Local                         True       6h23m
v1.storage.k8s.io                     Local                         True       6h23m
v1beta1.storage.k8s.io                 Local                         True       6h23m
v1beta2.flowcontrol.apiserver.k8s.io   Local                         True       6h23m
v1beta3.flowcontrol.apiserver.k8s.io   Local                         True       6h23m
v2.autoscaling                         Local                         True       6h23m
v3.projectcalico.org                   calico-apiserver/calico-api   True       6h12m