Kubernetes配置和存储

K8S

发布日期: 2023-08-15

一、概述

1、简介

容器的生命周期可能很短，会被频繁的创建和销毁。那么容器在销毁的时候，保存在容器中的数据也会被清除。这种结果对用户来说，在某些情况下是不乐意看到的。为了持久化保存容器中的数据，Kubernetes 引入了 Volume 的概念。和 Docker 中的卷管理（匿名卷、具名卷、自定义挂载目录，都是挂载在本机，功能非常有限）不同的是，Kubernetes 天生就是集群，所以为了方便管理，Kubernetes 将卷抽取为一个对象资源，这样可以更方便的管理和存储数据。

Volume 是 Pod 中能够被多个容器访问的共享目录，它被定义在 Pod 上，然后被一个 Pod 里面的多个容器挂载到具体的文件目录下，Kubernetes 通过 Volume 实现同一个 Pod 中不同容器之间的数据共享以及数据的持久化存储。Volume 的生命周期不和 Pod 中的单个容器的生命周期有关，当容器终止或者重启的时候，Volume 中的数据也不会丢失。

2、支持的 Volume 类型

Kubernetes 目前支持多达 28 种数据卷类型（其中大部分特定于具体的云环境如 GCE/AWS/Azure 等）

非持久性存储：

emptyDir
HostPath

网络连接性存储：

SAN：iSCSI、ScaleIO Volumes、FC (Fibre Channel)
NFS：nfs，cfs

分布式存储

Glusterfs
RBD (Ceph Block Device)
CephFS
Portworx Volumes
Quobyte Volumes

云端存储

GCEPersistentDisk
AWSElasticBlockStore
AzureFile
AzureDisk
Cinder (OpenStack block storage)
VsphereVolume
StorageOS

自定义存储

FlexVolume

二、配置

1、Secret

（1）概述

Secret 对象类型用来保存敏感信息，如：密码、OAuth2 令牌以及 SSH 密钥等。将这些信息放到 Secret 中比放在 Pod 的定义或者容器镜像中更加安全和灵活。
由于创建 Secret 可以独立于使用它们的 Pod，因此在创建、查看和编辑 Pod 的工作流程中暴露 Secret（及其数据）的风险较小。 Kubernetes 和在集群中运行的应用程序也可以对 Secret 采取额外的预防措施，如：避免将机密数据写入非易失性存储。
Secret 类似于 ConfigMap 但专门用于保存机密数据。

注意：Secret 和 ConfigMap 是保存在 etcd 中。

（2）Secret 的种类

内置类型	用法
`Opaque`	用户定义的任意数据
`kubernetes.io/service-account-token`	服务账号令牌
`kubernetes.io/dockercfg`	`~/.dockercfg` 文件的序列化形式
`kubernetes.io/dockerconfigjson`	`~/.docker/config.json` 文件的序列化形式
`kubernetes.io/basic-auth`	用于基本身份认证的凭据
`kubernetes.io/ssh-auth`	用于 SSH 身份认证的凭据
`kubernetes.io/tls`	用于 TLS 客户端或者服务器端的数据
`bootstrap.kubernetes.io/token`	启动引导令牌数据

（3）Pod 如何引用

要使用 Secret，Pod 需要引用 Secret。 Pod 可以用三种方式之一来使用 Secret ：

作为挂载到一个或多个容器上的卷中的文件。（volume进行挂载）
作为容器的环境变量（envFrom字段引用）
由 kubelet 在为 Pod 拉取镜像时使用（此时Secret是docker-registry类型的）

Secret 对象的名称必须是合法的 DNS 子域名。在为创建 Secret 编写配置文件时，你可以设置 data 与/或 stringData 字段。 data 和 stringData 字段都是可选的。data 字段中所有键值都必须是 base64 编码的字符串。如果不希望执行这种 base64 字符串的转换操作，你可以选择设置 stringData 字段，其中可以使用任何字符串作为其取值。

（4）创建 Secret

命令行创建 Secret

kubectl create secret generic secret-1 \
   --from-literal=username=admin \
   --from-literal=password=123456

以 yaml 形式提取 secret ，可以看到数据使用了 base64 进行了编码

kubectl get secret secret-1  -o yaml

可通过以下命令验证数据

# 准备username YWRtaW4=
echo -n "admin" | base64
# MTIzNDU2
echo -n "123456" | base64

yaml 创建 Secret

vi k8s-secret.yaml

apiVersion: v1
kind: Secret
metadata:
  name: k8s-secret
  namespace: default
type: Opaque
# data: 编码后的数据,注意：如果同时使用 data 和 stringData ，那么 data 会被忽略。
data:
  username: YWRtaW4=
  password: MTIzNDU2
# stringData: 未编码的数据  
stringData: 
  username: admin
  password: "123456"

kubectl apply -f k8s-secret.yaml

根据文件创建 Secret

echo -n 'admin' > username.txt
echo -n '123456' > password.txt

kubectl create secret generic k8s-secret-file \
  --from-file=username.txt \
  --from-file=password.txt

注意：密钥的 Key 默认是文件名的名称。

根据文件创建 Secret（自定义密钥的 Key ）

kubectl create secret generic k8s-secret-file \
  --from-file=username=username.txt \
  --from-file=password=password.txt

（5）查看 Secret

查看所有Secret

kubectl get secret

JSON形式提取Secret

kubectl get secret k8s-secret-file  -o jsonpath='{.data}'

yaml形式提取Secret

kubectl get secret k8s-secret-file  -o yaml

（6）Secret 之环境变量引用

vi k8s-secret.yaml

apiVersion: v1
kind: Secret
metadata:
  name: my-secret
  namespace: default
type: Opaque
stringData: 
  username: admin
  password: "1234556"
---
apiVersion: v1
kind: Pod
metadata:
  name: pod-secret
  namespace: default
  labels:
    app: pod-secret
spec:
  containers:
  - name: alpine
    image: alpine
    command: ["/bin/sh","-c","sleep 3600"]
    resources:
      limits:
        cpu: 200m
        memory: 500Mi
      requests:
        cpu: 100m
        memory: 200Mi
    env:
    - name: SECRET_USERNAME # 容器中的环境变量名称
      valueFrom:
        secretKeyRef: 
          name: my-secret #  指定 secret 的名称
          key: username # secret 中 key 的名称，会自动 base64 解码
    - name: SECRET_PASSWORD # 容器中的环境变量名称
      valueFrom:
        secretKeyRef:
          name: my-secret #  指定 secret 的名称
          key: password # secret 中 key 的名称   
    - name: POD_NAME
      valueFrom: 
        fieldRef:  # 属性引用
          fieldPath: metadata.name
    - name: POD_LIMITS_MEMORY
      valueFrom:
        resourceFieldRef:  # 资源限制引用 
          containerName: alpine  
          resource: limits.memory       
    ports:
    - containerPort:  80
      name:  http
    volumeMounts:
    - name: localtime
      mountPath: /etc/localtime
  volumes:
    - name: localtime
      hostPath:
        path: /usr/share/zoneinfo/Asia/Shanghai
  restartPolicy: Always

注意：环境变量引用的方式不会被自动更新。

（7）Secret 之卷挂载

会在指定的目录下生成 secret 对应的文件，key 为文件名，value 为文件内容

vi k8s-secret.yaml

apiVersion: v1
kind: Secret
metadata:
  name: my-secret
  namespace: default
type: Opaque
stringData: 
  username: admin
  password: "1234556"
---
apiVersion: v1
kind: Pod
metadata:
  name: pod-secret
  namespace: default
  labels:
    app: pod-secret
spec:
  containers:
  - name: alpine
    image: alpine
    command: ["/bin/sh","-c","sleep 3600"]
    resources:
      limits:
        cpu: 200m
        memory: 500Mi
      requests:
        cpu: 100m
        memory: 200Mi     
    ports:
    - containerPort:  80
      name:  http
    volumeMounts:
    - name: app
      mountPath: /app  
  volumes:
    - name: app
      secret:
        secretName: my-secret # secret 的名称，Secret 中的所有 key 全部挂载出来
  restartPolicy: Always

注意：

如果 Secret 以卷挂载的方式，Secret 里面的所有 key 都是文件名，内容就是 key 对应的值。
如果 Secret 以卷挂载的方式，Secret 的内容更新，那么容器对应的值也会被更新（subPath 引用除外）。
如果 Secret 以卷挂载的方式，默认情况下，挂载出来的文件是只读的。

指定挂载文件名

apiVersion: v1
kind: Secret
metadata:
  name: my-secret
  namespace: default
type: Opaque
stringData: 
  username: admin
  password: "1234556"
---
apiVersion: v1
kind: Pod
metadata:
  name: pod-secret
  namespace: default
  labels:
    app: pod-secret
spec:
  containers:
  - name: alpine
    image: alpine
    command: ["/bin/sh","-c","sleep 3600"]
    resources:
      limits:
        cpu: 200m
        memory: 500Mi
      requests:
        cpu: 100m
        memory: 200Mi     
    ports:
    - containerPort:  80
      name:  http
    volumeMounts:
    - name: app
      mountPath: /app  
  volumes:
    - name: app
      secret:
        secretName: my-secret # secret 的名称，Secret 中的所有 key 全部挂载出来
        items:
          - key: username # secret 中 key 的名称，Secret 中的 username 的内容挂载出来
            path: username.md # 在容器内挂载出来的文件的路径
  restartPolicy: Always

2、ConfigMap

（1）概述

ConfigMap 和 Secret 非常类似，只不过 Secret 会将信息进行 base64 编码和解码，而 ConfigMap 却不会。

（2）创建 ConfigMap、环境变量引用、卷挂载

kind: ConfigMap
apiVersion: v1
metadata:
  name: cm
  namespace: default
data:
  # 类属性键；每一个键都映射到一个简单的值
  player_initial_lives: "3"
  ui_properties_file_name: "user-interface.properties"
  # 类文件键
  game.properties: |
    enemy.types=aliens,monsters
    player.maximum-lives=5    
  user-interface.properties: |
    color.good=purple
    color.bad=yellow
    allow.textmode=true 
---
apiVersion: v1
kind: Pod
metadata:
  name: "pod-cm"
  namespace: default
  labels:
    app: "pod-cm"
spec:
  containers:
  - name: alpine
    image: "alpine"
    command: ["/bin/sh","-c","sleep 3600"]
    resources:
      limits:
        cpu: 200m
        memory: 500Mi
      requests:
        cpu: 100m
        memory: 200Mi
    env:
    - name: PLAYER_INITIAL_LIVES
      valueFrom:
        configMapKeyRef:
          name: cm
          key: player_initial_lives
    ports:
    - containerPort:  80
      name:  http
    volumeMounts:
    - name: app
      mountPath: /app  
  volumes:
    - name: app
      configMap:
        name: cm # secret 的名称，Secret 中的所有 key 全部挂载出来
        items:
          - key: ui_properties_file_name # secret 中 key 的名称，Secret 中的 ui_properties_file_name 的内容挂载出来
            path: ui_properties_file_name.md # 在容器内挂载出来的文件的路径
  restartPolicy: Always

注意：

ConfigMap 和 Secret 一样，环境变量引用不会热更新，而卷挂载是可以热更新的。
最新版本的 ConfigMap 和 Secret 提供了不可更改的功能，即禁止热更新，只需要在 Secret 或 ConfigMap 中设置 immutable = true 。

（3）结合 SpringBoot 做到生产配置无感知

三、临时存储

Kubernetes 为了不同的目的，支持几种不同类型的临时卷：

emptyDir： Pod 启动时为空，存储空间来自本地的 kubelet 根目录（通常是根磁盘）或内存
configMap、 downwardAPI、 secret：将不同类型的 Kubernetes 数据注入到 Pod 中
CSI 临时卷：类似于前面的卷类型，但由专门支持此特性的指定 CSI 驱动程序提供
通用临时卷：它可以由所有支持持久卷的存储驱动程序提供

emptyDir、configMap、downwardAPI、secret 是作为本地临时存储提供的。它们由各个节点上的 kubelet 管理。

CSI 临时卷 必须 由第三方 CSI 存储驱动程序提供。

通用临时卷 可以 由第三方 CSI 存储驱动程序提供，也可以由支持动态配置的任何其他存储驱动程序提供。一些专门为 CSI 临时卷编写的 CSI 驱动程序，不支持动态供应：因此这些驱动程序不能用于通用临时卷。

使用第三方驱动程序的优势在于，它们可以提供 Kubernetes 本身不支持的功能，例如，与 kubelet 管理的磁盘具有不同运行特征的存储，或者用来注入不同的数据。

1、emptyDir

EmptyDir是最基础的Volume类型，一个EmptyDir就是Host上的一个空目录。
EmptyDir是在Pod被分配到Node时创建的，它的初始内容为空，并且无须指定宿主机上对应的目录文件，因为kubernetes会自动分配一个目录，当Pod销毁时，EmptyDir中的数据也会被永久删除。
尽管 Pod 中的容器挂载 emptyDir 卷的路径可能相同也可能不同，这些容器都可以读写 emptyDir 卷中相同的文件。
emptyDir 卷存储在该节点的磁盘或内存中，如果设置 emptyDir.medium = Memory ，那么就告诉 Kubernetes 将数据保存在内存中，并且在 Pod 被重启或删除前，所写入的所有文件都会计入容器的内存消耗，受到容器内存限制约束。
EmptyDir的用途如下：
- 临时空间，例如用于某些应用程序运行时所需的临时目录，且无须永久保留。
- 一个容器需要从另一个容器中获取数据的目录（多容器共享目录）。

接下来，通过一个容器之间的共享案例来使用描述一个EmptyDir。

在一个Pod中准备两个容器nginx和busybox，然后声明一个volume分别挂载到两个容器的目录中，然后nginx容器负责向volume中写日志，busybox中通过命令将日志内容读到控制台。

（1）创建 Pod

apiVersion: v1
kind: Pod
metadata:
  name: volume-emptydir
  namespace: dev
spec:
  containers:
    - name: nginx
      image: nginx:1.17.1
      imagePullPolicy: IfNotPresent
      ports:
        - containerPort: 80
      volumeMounts: # 将logs-volume挂载到nginx容器中对应的目录，该目录为/var/log/nginx
        - name: logs-volume
          mountPath: /var/log/nginx
    - name: busybox
      image: busybox:1.30
      imagePullPolicy: IfNotPresent
      command: ["/bin/sh","-c","tail -f /logs/access.log"] # 初始命令，动态读取指定文件
      volumeMounts: # 将logs-volume挂载到busybox容器中的对应目录，该目录为/logs
        - name: logs-volume
          mountPath: /logs
  volumes: # 声明volume，name为logs-volume，类型为emptyDir
    - name: logs-volume
      emptyDir: {}

（2）查看Pod

kubectl get pod volume-emptydir -n dev -o wide

（3）测试

访问完，Nginx 后查看 busybox 输出

kubectl logs -f volume-emptydir -n dev -c busybox

2、HostPath

（1）概述

EmptyDir中的数据不会被持久化，它会随着Pod的结束而销毁，如果想要简单的将数据持久化到主机中，可以选择HostPath。

HostPath就是将Node主机中的一个实际目录挂载到Pod中，以供容器使用，这样的设计就可以保证Pod销毁了，但是数据依旧可以保存在Node主机上。

（2）创建 Pod

apiVersion: v1
kind: Pod
metadata:
  name: volume-hostpath
  namespace: dev
spec:
  containers:
    - name: nginx
      image: nginx:1.17.1
      imagePullPolicy: IfNotPresent
      ports:
        - containerPort: 80
      volumeMounts: # 将logs-volume挂载到nginx容器中对应的目录，该目录为/var/log/nginx
        - name: logs-volume
          mountPath: /var/log/nginx
    - name: busybox
      image: busybox:1.30
      imagePullPolicy: IfNotPresent
      command: ["/bin/sh","-c","tail -f /logs/access.log"] # 初始命令，动态读取指定文件
      volumeMounts: # 将logs-volume挂载到busybox容器中的对应目录，该目录为/logs
        - name: logs-volume
          mountPath: /logs
  volumes: # 声明volume，name为logs-volume，类型为hostPath
    - name: logs-volume
      hostPath:
        path: /root/logs
        type: DirectoryOrCreate # 目录存在就使用，不存在就先创建再使用

type的值的说明：

DirectoryOrCreate：目录存在就使用，不存在就先创建后使用。
Directory：目录必须存在。
FileOrCreate：文件存在就使用，不存在就先创建后使用。
File：文件必须存在。
Socket：unix套接字必须存在。
CharDevice：字符设备必须存在。
BlockDevice：块设备必须存在。

3、NFS

（1）概述

HostPath虽然可以解决数据持久化的问题，但是一旦Node节点故障了，Pod如果转移到别的Node节点上，又会出现问题，此时需要准备单独的网络存储系统，比较常用的是NFS和CIFS。

NFS是一个网络文件存储系统，可以搭建一台NFS服务器，然后将Pod中的存储直接连接到NFS系统上，这样，无论Pod在节点上怎么转移，只要Node和NFS的对接没有问题，数据就可以成功访问。

（2）Master节点搭建NFS服务器

首先需要准备NFS服务器，这里为了简单，直接在Master节点做NFS服务器。

在Master节点上安装NFS服务器：

yum install -y nfs-utils rpcbind

准备一个共享目录：

mkdir -pv /root/data/nfs

将共享目录以读写权限暴露给192.168.18.0/24网段中的所有主机：

vim /etc/exports

/root/data/nfs1 192.168.18.0/24(rw,no_root_squash)
/root/data/nfs2 192.168.245.0/24(ro)
/root/data/nfs3 192.168.245.0/24（rw）

参数	作用
ro	只读
rw	读写
root_squash	当NFS客户端以root管理员访问时，映射为NFS服务器的匿名用户
no_root_squash	当NFS客户端以root管理员访问时，映射为NFS服务器的root管理员
all_squash	无论NFS客户端使用什么账户访问，均映射为NFS服务器的匿名用户
sync	同时将数据写入到内存与硬盘中，保证不丢失数据
async	优先将数据保存到内存，然后再写入硬盘；这样效率更高，但可能会丢失数据

修改权限：

chmod 777 -R /root/data/nfs

加载配置：

exportfs -r

启动nfs服务：

systemctl start rpcbind
systemctl enable rpcbind
systemctl start nfs
systemctl enable nfs

# 修改配置后重新加载
systemctl reload nfs

在Master节点测试是否挂载成功：

showmount -e 192.168.18.100

（3）Node节点安装NFS

在Node节点上都安装NFS服务器，目的是为了Node节点可以驱动NFS设备。

# 在Node节点上安装NFS服务，不需要启动
yum -y install nfs-utils

在Node节点测试是否挂载成功：

showmount -e 192.168.18.100

高可用备份方式，在所有节点执行如下的命令：

mount -t  nfs 192.168.18.100:/root/data/nfs /mnt

（4）创建 Pod

apiVersion: v1
kind: Pod
metadata:
  name: volume-nfs
  namespace: dev
spec:
  containers:
    - name: nginx
      image: nginx:1.17.1
      imagePullPolicy: IfNotPresent
      ports:
        - containerPort: 80
      volumeMounts: # 将logs-volume挂载到nginx容器中对应的目录，该目录为/var/log/nginx
        - name: logs-volume
          mountPath: /var/log/nginx
    - name: busybox
      image: busybox:1.30
      imagePullPolicy: IfNotPresent
      command: ["/bin/sh","-c","tail -f /logs/access.log"] # 初始命令，动态读取指定文件
      volumeMounts: # 将logs-volume挂载到busybox容器中的对应目录，该目录为/logs
        - name: logs-volume
          mountPath: /logs
  volumes: # 声明volume
    - name: logs-volume
      nfs:
        server: 192.168.18.100 # NFS服务器地址
        path: /root/data/nfs # 共享文件路径

四、持久化存储

1、PV和PVC概述

由于kubernetes支持的存储系统有很多，要求客户全部掌握，显然不现实。为了能够屏蔽底层存储实现的细节，方便用户使用，kubernetes引入了PV和PVC两种资源对象。
PV（Persistent Volume）持久卷，是对底层的共享存储的一种抽象。一般情况下PV由kubernetes管理员进行创建和配置，它和底层具体的共享存储技术有关，并通过插件完成和共享存储的对接。
PVC（Persistent Volume Claim）持久卷声明，是用户对于存储需求的一种声明。换言之，PVC其实就是用户向kubernetes系统发出的一种资源需求申请。

使用了PV和PVC之后，工作可以得到进一步的提升：

存储：存储工程师维护。
PV：kubernetes管理员维护。
PVC：kubernetes用户维护。

PV 的缺点：

① 需要运维事先准备好 PV 池。
② 资源浪费：没有办法预估合适的 PV，假设运维向 k8s 申请了 20m 、50m、10G 的 PV，而开发人员申请 2G 的 PVC ，那么就会匹配到 10G 的PV ，这样会造成 8G 的空间浪费。

也有人称 PV 为静态供应。

2、PV

（1）资源清单

PV是存储资源的抽象，下面是PV的资源清单文件：

apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv2
spec:
  nfs: # 存储类型，和底层正则的存储对应
    path:
    server:
  capacity: # 存储能力，目前只支持存储空间的设置
    storage: 2Gi
  accessModes: # 访问模式
    -
  storageClassName: # 存储类别
  persistentVolumeReclaimPolicy: # 回收策略

pv的关键配置参数说明：

存储类型：底层实际存储的类型，kubernetes支持多种存储类型，每种存储类型的配置有所不同。
存储能力（capacity）：目前只支持存储空间的设置（storage=1Gi），不过未来可能会加入IOPS、吞吐量等指标的配置。
访问模式（accessModes）：
- 用来描述用户应用对存储资源的访问权限，访问权限包括下面几种方式：
- - ReadWriteOnce（RWO）：读写权限，但是只能被单个节点挂载。
  - ReadOnlyMany（ROX）：只读权限，可以被多个节点挂载。
  - ReadWriteMany（RWX）：读写权限，可以被多个节点挂载。
- 需要注意的是，底层不同的存储类型可能支持的访问模式不同。
回收策略（ persistentVolumeReclaimPolicy）：
- 当PV不再被使用之后，对其的处理方式，目前支持三种策略：
- - Retain（保留）：保留数据，需要管理员手动清理数据。
- - Recycle（回收）：清除PV中的数据，效果相当于rm -rf /volume/*。
- - Delete（删除）：和PV相连的后端存储完成volume的删除操作，常见于云服务器厂商的存储服务。
- 需要注意的是，底层不同的存储类型可能支持的回收策略不同。
存储类别（storageClassName）：PV可以通过storageClassName参数指定一个存储类别。
- 具有特定类型的PV只能和请求了该类别的PVC进行绑定。
- 未设定类别的PV只能和不请求任何类别的PVC进行绑定。
状态（status）：一个PV的生命周期，可能会处于4种不同的阶段。
- Available（可用）：表示可用状态，还未被任何PVC绑定。
- Bound（已绑定）：表示PV已经被PVC绑定。
- Released（已释放）：表示PVC被删除，但是资源还没有被集群重新释放。
- Failed（失败）：表示该PV的自动回收失败。

（2）准备NFS环境

mkdir -pv /root/data/{pv1,pv2,pv3}
chmod 777 -R /root/data

修改 /etc/exports

vim /etc/exports

/root/data/pv1     192.168.18.0/24(rw,no_root_squash) 
/root/data/pv2     192.168.18.0/24(rw,no_root_squash) 
/root/data/pv3     192.168.18.0/24(rw,no_root_squash)

重启 nfs

systemctl restart nfs

（3）创建 PV (池)

apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv1
spec:
  nfs: # 存储类型吗，和底层正则的存储对应
    path: /root/data/pv1
    server: 192.168.18.100
  capacity: # 存储能力，目前只支持存储空间的设置
    storage: 1Gi
  accessModes: # 访问模式
    - ReadWriteMany
  persistentVolumeReclaimPolicy: Retain # 回收策略

---
apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv2
spec:
  nfs: # 存储类型吗，和底层正则的存储对应
    path: /root/data/pv2
    server: 192.168.18.100
  capacity: # 存储能力，目前只支持存储空间的设置
    storage: 2Gi
  accessModes: # 访问模式
    - ReadWriteMany
  persistentVolumeReclaimPolicy: Retain # 回收策略

---
apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv3
spec:
  nfs: # 存储类型吗，和底层正则的存储对应
    path: /root/data/pv3
    server: 192.168.18.100
  capacity: # 存储能力，目前只支持存储空间的设置
    storage: 3Gi
  accessModes: # 访问模式
    - ReadWriteMany
  persistentVolumeReclaimPolicy: Retain # 回收策略

（4）查看PV

kubectl get pv -o wide

3、PVC

（1）资源清单

PVC是资源的申请，用来声明对存储空间、访问模式、存储类别需求信息，下面是PVC的资源清单文件：

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: pvc
  namespace: dev
spec:
  accessModes: # 访客模式
    - 
  selector: # 采用标签对PV选择
  storageClassName: # 存储类别
  resources: # 请求空间
    requests:
      storage: 5Gi

PVC的关键配置参数说明：

访客模式（accessModes）：用于描述用户应用对存储资源的访问权限。
用于描述用户应用对存储资源的访问权限：
- 选择条件（selector）：通过Label Selector的设置，可使PVC对于系统中已存在的PV进行筛选。
- 存储类别（storageClassName）：PVC在定义时可以设定需要的后端存储的类别，只有设置了该class的pv才能被系统选出。
- 资源请求（resources）：描述对存储资源的请求。

（2）创建 PVC

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: pvc1
  namespace: dev
spec:
  accessModes: # 访客模式
    - ReadWriteMany
  resources: # 请求空间
    requests:
      storage: 1Gi

---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: pvc2
  namespace: dev
spec:
  accessModes: # 访客模式
    - ReadWriteMany
  resources: # 请求空间
    requests:
      storage: 1Gi

---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: pvc3
  namespace: dev
spec:
  accessModes: # 访客模式
    - ReadWriteMany
  resources: # 请求空间
    requests:
      storage: 5Gi

（3）查看 PVC

kubectl get pvc -n dev -o wide

（4）创建Pod绑定PVC

apiVersion: v1
kind: Pod
metadata:
  name: pod1
  namespace: dev
spec:
  containers:
  - name: busybox
    image: busybox:1.30
    command: ["/bin/sh","-c","while true;do echo pod1 >> /root/out.txt; sleep 10; done;"]
    volumeMounts:
    - name: volume
      mountPath: /root/
  volumes:
    - name: volume
      persistentVolumeClaim:
        claimName: pvc1
        readOnly: false

---
apiVersion: v1
kind: Pod
metadata:
  name: pod2
  namespace: dev
spec:
  containers:
    - name: busybox
      image: busybox:1.30
      command: ["/bin/sh","-c","while true;do echo pod1 >> /root/out.txt; sleep 10; done;"]
      volumeMounts:
        - name: volume
          mountPath: /root/
  volumes:
    - name: volume
      persistentVolumeClaim:
        claimName: pvc2
        readOnly: false

注意：

pv 和 pvc 的 accessModes 和 storageClassName 必须一致。
pvc 申请的空间大小不大于 pv 的空间大小。
storageClassName 就相当于分组的组名，通过 storageClassName 可以区分不同类型的存储驱动，主要是为了方便管理。

注意：

Pod 的删除，并不会影响 PVC；换言之，PVC 可以独立于 Pod 存在，PVC 也是 K8s 的系统资源。不过，推荐将 PVC 和 Pod 也在一个 yaml 文件中。
PVC 删除会不会影响到 PV，要根据 PV 的回收策略决定。

4、PV 回收策略

目前的回收策略有：

Retain：手动回收（默认）。
Recycle：基本擦除 (rm -rf /thevolume/*)。
Delete：诸如 AWS EBS、GCE PD、Azure Disk 或 OpenStack Cinder 卷这类关联存储资产也被删除。

目前，仅 NFS 和 HostPath 支持回收（Recycle）。 AWS EBS、GCE PD、Azure Disk 和 Cinder 卷都支持删除（Delete）。

Retain 演示

（1）创建 PV 池

mkdir -pv /nfs/data/10m
mkdir -pv /nfs/data/20m
mkdir -pv /nfs/data/500m
mkdir -pv /nfs/data/1Gi

apiVersion: v1
kind: PersistentVolume
metadata:
  name: nfs-pv-10m
spec:
  storageClassName: nfs-storage # 用于分组
  capacity:
    storage: 10m
  accessModes:
    - ReadWriteOnce
  nfs: # 使用 nfs 存储驱动
    path: /nfs/data/10m # nfs 共享的目录，mkdir -pv /nfs/data/10m
    server: 192.168.65.100 # nfs 服务端的 IP 地址或 hostname
---
apiVersion: v1
kind: PersistentVolume
metadata:
  name: nfs-pv-20m
spec:
  storageClassName: nfs-storage # 用于分组
  capacity:
    storage: 20m
  accessModes:
    - ReadWriteOnce
  nfs: # 使用 nfs 存储驱动
    path: /nfs/data/20m # nfs 共享的目录，mkdir -pv /nfs/data/20m
    server: 192.168.65.100 # nfs 服务端的 IP 地址或 hostname
--- 
apiVersion: v1
kind: PersistentVolume
metadata:
  name: nfs-pv-500m
spec:
  storageClassName: nfs-storage # 用于分组
  capacity:
    storage: 500m
  accessModes:
    - ReadWriteOnce
  nfs: # 使用 nfs 存储驱动
    path: /nfs/data/500m # nfs 共享的目录，mkdir -pv /nfs/data/500m
    server: 192.168.65.100 # nfs 服务端的 IP 地址或 hostname
---
apiVersion: v1
kind: PersistentVolume
metadata:
  name: nfs-pv-1g
spec:
  storageClassName: nfs-storage # 用于分组
  capacity:
    storage: 1Gi
  accessModes:
    - ReadWriteOnce
  nfs: # 使用 nfs 存储驱动
    path: /nfs/data/1Gi # nfs 共享的目录，mkdir -pv /nfs/data/1Gi
    server: 192.168.65.100 # nfs 服务端的 IP 地址或 hostname

（2）创建PVC并删除

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: nginx-pvc-500m
  namespace: default
  labels:
    app: nginx-pvc-500m
spec:
  storageClassName: nfs-storage
  accessModes:
  - ReadWriteOnce
  resources:
    requests:
      storage: 500m

创建PVC绑定PV后删除

kubectl apply -f k8s-pvc.yaml
kubectl delete -f k8s-pvc.yaml

（3）结果

可观察到 PV 状态变化：

Available -> Bound：创建 PVC 绑定 PV
Bound -> Released：删除 PVC 解绑 PV，但资源还没被释放
Released -> Available ：等待一会，资源释放完成

5、PV生命周期

一个 PV 的生命周期，可能会处于 4 种不同的阶段：

Available（可用）：表示可用状态，还未被任何 PVC 绑定。
Bound（已绑定）：表示 PV 已经被 PVC 绑定。
Released（已释放）：表示 PVC 被删除，但是资源还没有被集群重新释放。
Failed（失败）：表示该 PV 的自动回收失败。

PVC和PV是一一对应的，PV和PVC之间的相互作用遵循如下的生命周期。

资源供应：管理员手动创建底层存储和PV。

资源绑定：

用户创建PVC，kubernetes负责根据PVC声明去寻找PV，并绑定在用户定义好PVC之后，系统将根据PVC对存储资源的请求在以存在的PV中选择一个满足条件的。
- 一旦找到，就将该PV和用户定义的PVC进行绑定，用户的应用就可以使用这个PVC了。
- 如果找不到，PVC就会无限期的处于Pending状态，直到系统管理员创建一个符合其要求的PV。
PV一旦绑定到某个PVC上，就会被这个PVC独占，不能再和其他的PVC进行绑定了。

资源使用：用户可以在Pod中像volume一样使用PVC，Pod使用Volume的定义，将PVC挂载到容器内的某个路径进行使用。

资源释放：

用户删除PVC来释放PV。
当存储资源使用完毕后，用户可以删除PVC，和该PVC绑定的PV将会标记为“已释放”，但是还不能立刻和其他的PVC进行绑定。通过之前PVC写入的数据可能还留在存储设备上，只有在清除之后该PV才能再次使用。

资源回收：

kubernetes根据PV设置的回收策略进行资源的回收。
对于PV，管理员可以设定回收策略，用于设置与之绑定的PVC释放资源之后如何处理遗留数据的问题。只有PV的存储空间完成回收，才能供新的PVC绑定和使用。

6、PV 的访问模式

访问模式（accessModes）：用来描述用户应用对存储资源的访问权限，访问权限包括下面几种方式：

ReadWriteOnce（RWO）：读写权限，但是只能被单个节点挂载。
ReadOnlyMany（ROX）：只读权限，可以被多个节点挂载。
ReadWriteMany（RWX）：读写权限，可以被多个节点挂载。

7、动态供应

K8S

Kubesphere

2023-08-17 K8S

K8S

Kubernetes服务网络

2023-08-08 K8S

K8S

Kubernetes配置和存储

一、概述

1、简介

2、支持的 Volume 类型

二、配置

1、Secret

（1）概述

（2）Secret 的种类

（3）Pod 如何引用

（4）创建 Secret

命令行创建 Secret

yaml 创建 Secret

根据文件创建 Secret

（5）查看 Secret

查看所有Secret

JSON形式提取Secret

yaml形式提取Secret

（6）Secret 之环境变量引用

（7）Secret 之 卷挂载

指定挂载文件名

2、ConfigMap

（1）概述

（2）创建 ConfigMap、环境变量引用、卷挂载

（3）结合 SpringBoot 做到生产配置无感知

三、临时存储

1、emptyDir

（1）创建 Pod

（2）查看Pod

（3）测试

2、HostPath

（1）概述

（2）创建 Pod

3、NFS

（1）概述

（2）Master节点搭建NFS服务器

（3）Node节点安装NFS

（4）创建 Pod

四、持久化存储

1、PV和PVC概述

2、PV

（1）资源清单

（2）准备NFS环境

（3）创建 PV (池)

（4）查看PV

3、PVC

（1）资源清单

（2）创建 PVC

（3）查看 PVC

（4）创建Pod绑定PVC

4、PV 回收策略

（1）创建 PV 池

（2）创建PVC并删除

（3）结果

5、PV生命周期

6、PV 的访问模式

7、动态供应

（7）Secret 之卷挂载