K8s学习九（配置与存储_存储）

存储管理

Volumes

HostPath

将节点上的文件或目录挂载到 Pod 上，此时该目录会变成持久化存储目录，即使 Pod 被删除后重启，也可以重新加载到该目录，该目录下的文件不会丢失
效果就是容器里的数据和主机里的数据进行共享
配置文件：

apiVersion: v1
kind: Pod
metadata:
  name: test-volume-pd 
spec:
  containers:
  - image: nginx
    name: nginx-volume
    volumeMounts: #相当于选择磁盘放入
    - mountPath: /test-pd # 挂载到容器的哪个目录
      name: test-volume # 挂载哪个 volume
  volumes: #相当于准备磁盘
  - name: test-volume
    hostPath: #与主机共享路径
      path: /data # 节点中的目录
      type: DirectoryOrCreate # 检查类型，在挂载前对挂载目录做什么检查操作，有多种选项，默认为空字符串，不做任何检查


# 类型：
# 空字符串：默认类型，不做任何检查
# DirectoryOrCreate：如果给定的 path 不存在，就创建一个 755 的空目录
# Directory：这个目录必须存在
# FileOrCreate：如果给定的文件不存在，则创建一个空文件，权限为 644
# File：这个文件必须存在
# Socket：UNIX 套接字，必须存在
# CharDevice：字符设备，必须存在
# BlockDevice：块设备，必须存在

EmptyDir

EmptyDir 主要用于一个 Pod 中不同的 Container 共享数据使用的，由于只是在 Pod 内部使用，因此与其他 volume 比较大的区别是，当 Pod 如果被删除了，那么 emptyDir 也会被删除。
存储介质可以是任意类型，如 SSD、磁盘或网络存储。可以将 emptyDir.medium 设置为 Memory 让 k8s 使用 tmpfs（内存支持文件系统），速度比较快，但是重启 tmpfs 节点时，数据会被清除，且设置的大小会计入到 Container 的内存限制中。
配置如下：

apiVersion: v1
kind: Pod
metadata:
  name: empty-dir-pd
spec:
  containers:
  - image: alpine
    name: alpine-emptydir1
    command: ["/bin/sh","-c","sleep 3600;"]
    volumeMounts:
    - mountPath: /cache
      name: cache-volume
  - image: alpine
    name: alpine-emptydir2
    command: ["/bin/sh","-c","sleep 3600;"]
    volumeMounts:
    - mountPath: /cache
      name: cache-volume
  volumes:
  - name: cache-volume
    emptyDir: {}
~                                                                                             
~                                                                                             
~

这里再进入容器的时候，需要指定进入到哪一个容器，如：kubectl exec -it empty-dir-pd -c alpine-emptydir1 -- sh
这里可以监听一下试试tail -f a.txt，发现确实有更改。

NFS挂载

nfs 卷能将 NFS (网络文件系统) 挂载到你的 Pod 中。不像 emptyDir 那样会在删除 Pod 的同时也会被删除，nfs 卷的内容在删除 Pod 时会被保存，卷只是被卸载。这意味着 nfs 卷可以被预先填充数据，并且这些数据可以在 Pod 之间共享。
这里是其他主机上的，可以实现不同节点上的不同pod共享数据
因为不仅跨了主机还跨了网络，所以很慢，

安装NFS

#下面是在想安装的服务端和客户端的代码
#服务端
#下载
 apt update
 apt install nfs-kernel-server

#然后启动
 systemctl start nfs-kernel-server

#创建共享目录
 mkdir -p /home/nfs
 cd /home/nfs
 mkdir rw #读写
 mkdir ro #只读

#设置共享目录，这个是专门设置共享目录的地方
vim /etc/exports
#加入下面两行，意思是在192.168.2.这个网段的所有主机都可以共享
/home/nfs/rw 192.168.2.0/24(rw,sync,no_subtree_check,no_root_squash)
/home/nfs/ro 192.168.2.0/24(ro,sync,no_subtree_check,no_root_squash)

#重新导出共享目录并更改，重启服务
exportfs -ra
systemctl restart nfs-kernel-server


#客户端
#下载
 apt update
 apt install nfs-common

# 创建挂载点并挂在nfs共享目录,这里填的是服务端的ip地址
 mkdir -p /mnt/nfs/rw
 mkdir -p /mnt/nfs/ro
 mount -t nfs 192.168.2.135:/home/nfs/rw /mnt/nfs/rw
 mount -t nfs 192.168.2.135:/home/nfs/ro /mnt/nfs/ro

NFS文件系统挂载

配置如下：

apiVersion: v1
kind: Pod
metadata:
  name: nfs-test-pd
spec:
  containers:
  - image: nginx
    name: test-container
    volumeMounts:
    - mountPath: /usr/share/nginx/html #在 Nginx web 服务器中，/usr/share/nginx/html 是 Nginx 的默认文档根目录，这意味着当用户请求你的网站时，Nginx 会从这个目录中查找静态文件（如 HTML、CSS、JavaScript 文件等）来响应请求。
      name: test-volume
  volumes:
  - name: test-volume
    nfs:
      server: 192.168.2.135 # 网络存储服务地址
      path: /home/nfs/rw/www/index # 网络存储路径
      readOnly: false # 是否只读

创建之后，在网络存储相应的地方加入index.html，也就是/home/nfs/rw/www/index/index.html，然后直接kubectl get po -o wide找到相应pod的ip，然后直接curl就可以看到内容，删了pod之后还会保存。

PV和PVC（最重要的存储）

问题：可能用到存储方式不一样

在这里插入图片描述

持久卷（PersistentVolume，PV）是集群中的一块存储，可以由管理员事先制备，或者使用存储类（Storage Class）来动态制备。持久卷是集群资源，就像节点也是集群资源一样。PV 持久卷和普通的 Volume 一样，也是使用卷插件来实现的，只是它们拥有独立于任何使用 PV 的 Pod 的生命周期。此 API 对象中记述了存储的实现细节，无论其背后是 NFS、iSCSI 还是特定于云平台的存储系统。
这里PV是一个抽象的概念，起到了一个规范的作用，不管背后使用的什么存储系统，操作PV就是操作背后的存储系统。
持久卷申领（PersistentVolumeClaim，PVC）表达的是用户对存储的请求。概念上与 Pod 类似。 Pod 会耗用节点资源，而 PVC 申领会耗用 PV 资源。Pod 可以请求特定数量的资源（CPU 和内存）；同样 PVC 申领也可以请求特定的大小和访问模式（例如，可以要求 PV 卷能够以 ReadWriteOnce、ReadOnlyMany 或 ReadWriteMany 模式之一来挂载，参见访问模式）。
下图是具体的流程

在这里插入图片描述

生命周期

构建

静态构建

集群管理员创建若干 PV 卷。这些卷对象带有真实存储的细节信息，并且对集群用户可用（可见）。PV 卷对象存在于 Kubernetes API 中，可供用户消费（使用）。

动态构建

如果集群中已经有的 PV 无法满足 PVC 的需求，那么集群会根据 PVC 自动构建一个 PV，该操作是通过 StorageClass 实现的。
想要实现这个操作，前提是 PVC 必须设置 StorageClass，否则会无法动态构建该 PV，可以通过启用 DefaultStorageClass 来实现 PV 的构建。

绑定

当用户创建一个 PVC 对象后，主节点会监测新的 PVC 对象，并且寻找与之匹配的 PV 卷，找到 PV 卷后将二者绑定在一起。
如果找不到对应的 PV，则需要看 PVC 是否设置 StorageClass 来决定是否动态创建 PV，若没有配置，PVC 就会一致处于未绑定状态，直到有与之匹配的 PV 后才会申领绑定关系。

使用

Pod 将 PVC 当作存储卷来使用，集群会通过 PVC 找到绑定的 PV，并为 Pod 挂载该卷。
Pod 一旦使用 PVC 绑定 PV 后，为了保护数据，避免数据丢失问题，PV 对象会受到保护，在系统中无法被删除。

回收策略

保留

回收策略 Retain 使得用户可以手动回收资源。当 PersistentVolumeClaim 对象被删除时，PersistentVolume 卷仍然存在，对应的数据卷被视为"已释放（released）"。 由于卷上仍然存在这前一申领人的数据，该卷还不能用于其他申领。 管理员可以通过下面的步骤来手动回收该卷：
1. 删除 PersistentVolume 对象。与之相关的、位于外部基础设施中的存储资产 （例如 AWS EBS、GCE PD、Azure Disk 或 Cinder 卷）在 PV 删除之后仍然存在。
2. 根据情况，手动清除所关联的存储资产上的数据。
3. 手动删除所关联的存储资产。
如果你希望重用该存储资产，可以基于存储资产的定义创建新的 PersistentVolume 卷对象。

删除

对于支持 Delete 回收策略的卷插件，删除动作会将 PersistentVolume 对象从 Kubernetes 中移除，同时也会从外部基础设施（如 AWS EBS、GCE PD、Azure Disk 或 Cinder 卷）中移除所关联的存储资产。动态制备的卷会继承其 StorageClass 中设置的回收策略，该策略默认为 Delete。管理员需要根据用户的期望来配置 StorageClass；否则 PV 卷被创建之后必须要被编辑或者修补。

回收

警告：回收策略 Recycle 已被废弃。取而代之的建议方案是使用动态制备。
如果下层的卷插件支持，回收策略 Recycle 会在卷上执行一些基本的擦除（rm -rf /thevolume/*）操作，之后允许该卷用于新的 PVC 申领。

PV

状态

Available：空闲，未被绑定
Bound：已经被 PVC 绑定
Released：PVC 被删除，资源已回收，但是 PV 未被重新使用
Failed：自动回收失败
配置文件如下：

apiVersion: v1
kind: PersistentVolume #描述资源对象为PV
metadata:
  name: pv0001 #PV的名字
spec:
  capacity:
    storage: 5Gi # pv 的容量
  volumeMode: Filesystem # 存储类型为文件系统
  accessModes: # 访问模式：ReadWriteOnce（单词）、ReadWriteMany（可以被多个使用）、ReadOnlyMany
    - ReadWriteMany # 可被单节点独写
  persistentVolumeReclaimPolicy: Retain # 回收策略
  storageClassName: slow # 创建 PV 的存储类名，需要与 pvc 的相同
  mountOptions: # 加载配置
    - hard
    - nfsvers=4.1
  nfs: # 连接到 nfs
    path: /home/nfs/rw/test-pv # 存储路径
    server: 192.168.2.135 # nfs 服务地址

PVC

pvc绑定pv
配置文件如下：


# 这里是pvc绑定pv
apiVersion: v1
kind: PersistentVolumeClaim #资源类型为pvc
metadata:
  name: nfs-pvc
spec:
  accessModes:
    - ReadWriteMany # 权限需要与对应的 pv 相同
  volumeMode: Filesystem
  resources:
    requests:
      storage: 5Gi # 资源可以小于 pv 的，但是不能大于，如果大于就会匹配不到 pv
  storageClassName: slow # 名字需要与对应的 pv 相同
#  selector: # 使用选择器选择对应的 pv
#    matchLabels:
#      release: "stable"
#    matchExpressions:
#      - {key: environment, operator: In, values: [dev]}

pvc绑定pod


apiVersion: v1
kind: Pod
metadata:
  name: test-volume-pd
spec:
  containers:
  - image: nginx
    name: nginx-volume
    volumeMounts:
    - mountPath: /usr/share/nginx/html # 挂载到容器的哪个目录
      name: test-volume # 挂载哪个 volume
  volumes:
  - name: test-volume
    persistentVolumeClaim: #关联pvc
      claimName: nfs-pvc #要关联到哪个pvc

StorageClass存储类的概念与作用

每个 StorageClass 都有一个制备器（Provisioner），用来决定使用哪个卷插件制备 PV。
如下图：

在这里插入图片描述

实现动态创建NFS-PV案例

先配置nfs-provisioner，StorageClass和RBAC配置

#nfs-provisioner
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nfs-client-provisioner
  namespace: kube-system
  labels:
    app: nfs-client-provisioner
spec:
  replicas: 1
  strategy:
    type: Recreate #不进行滚动更新，直接重新创建
  selector:
    matchLabels:
      app: nfs-client-provisioner #选择器
  template:
    metadata:
      labels:
        app: nfs-client-provisioner
    spec:
      serviceAccountName: nfs-client-provisioner #pvc要调用k8s的api，所以要有账号
      containers:
        - name: nfs-client-provisioner
          image: quay.io/external_storage/nfs-client-provisioner:latest
          volumeMounts:
            - name: nfs-client-root
              mountPath: /persistentvolumes
          env:
            - name: PROVISIONER_NAME
              value: fuseim.pri/ifs #对应SC里的名字
            - name: NFS_SERVER
              value: 192.168.2.135
            - name: NFS_PATH
              value: /home/nfs/rw
      volumes:
        - name: nfs-client-root
          nfs:
            server: 192.168.2.135
            path: /home/nfs/rw


# StorageClass
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: -nfs-storage
  namespace: kube-system
provisioner: fuseim.pri/ifs # 外部制备器提供者，编写为提供者的名称
parameters:
  archiveOnDelete: "false" # 是否存档，false 表示不存档，会删除 oldPath 下面的数据，true 表示存档，会重命名路径
reclaimPolicy: Retain # 回收策略，默认为 Delete 可以配置为 Retain
volumeBindingMode: Immediate # 默认为 Immediate，表示创建 PVC 立即进行绑定，只有 azuredisk 和 AWSelasticblockstore 支持其他值


# RBAC配置
apiVersion: v1
kind: ServiceAccount
metadata:
  name: nfs-client-provisioner
  namespace: kube-system
---
kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: nfs-client-provisioner-runner
  namespace: kube-system
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"]
---
kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: run-nfs-client-provisioner
  namespace: kube-system
subjects:
  - kind: ServiceAccount
    name: nfs-client-provisioner
    namespace: kube-system
roleRef:
  kind: ClusterRole
  name: nfs-client-provisioner-runner
  apiGroup: rbac.authorization.k8s.io
---
kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: leader-locking-nfs-client-provisioner
  namespace: kube-system
rules:
  - apiGroups: [""]
    resources: ["endpoints"]
    verbs: ["get", "list", "watch", "create", "update", "patch"]
---
kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: leader-locking-nfs-client-provisioner
  namespace: kube-system
subjects:
  - kind: ServiceAccount
    name: nfs-client-provisioner
roleRef:
  kind: Role
  name: leader-locking-nfs-client-provisioner
  apiGroup: rbac.authorization.k8s.io

PVC处于pending状态有两个解决方法：


# 第一种
修改 apiserver 配置文件
vim /etc/kubernetes/manifests/kube-apiserver.yaml

spec:
  containers:
  - command:
    - kube-apiserver
    - --feature-gates=RemoveSelfLink=false # 新增该行
    ......

修改后重新应用该配置
kubectl apply -f /etc/kubernetes/manifests/kube-apiserver.yaml


#第二种
将 provisioner 修改为如下镜像之一即可

gcr.io/k8s-staging-sig-storage/nfs-subdir-external-provisioner:v4.0.0

registry.cn-beijing.aliyuncs.com/pylixm/nfs-subdir-external-provisioner:v4.0.0