k8s学习-存储

4.6、存储

4.6.1、ConfigMap

创建方式

文件夹/文件创建

mkdir dir
cd dir
cat > c1.properties <<EOF
c1.name=c1
EOF
cat > c2.properties <<EOF
c2.name=c2
EOF

cd ..
cat > c3.properties <<EOF
c3.name=c3
EOF

# configmap 简写为 cm
# 根据目录创建
kubectl create configmap cm-c1 --from-file=dir
# 根据文件创建
kubectl create configmap cm-c2 --from-file=c3.properties

# 查看
[root@k8s-master configmap]# kubectl get cm
NAME    DATA   AGE
cm-c1   2      12s
cm-c2   1      7s

# 查看内容
[root@k8s-master configmap]# kubectl get cm cm-c2 -o yaml
apiVersion: v1
data:
  c3.properties: |
    c3.name=c3
kind: ConfigMap
metadata:
  creationTimestamp: "2020-03-08T02:55:45Z"
  name: cm-c2
  namespace: default
  resourceVersion: "280079"
  selfLink: /api/v1/namespaces/default/configmaps/cm-c2
  uid: d35bfd4e-42bc-491f-b30a-488633d36653

字面量创建

# 使用 --from-literal=KEY=VALUE 
kubectl create cm cm-literal --from-literal=lt.name=bart --from-literal=lt.age=16
# 查看
[root@k8s-master configmap]# kubectl get cm cm-literal -o yaml
apiVersion: v1
data:
  lt.age: "16"
  lt.name: bart
kind: ConfigMap
metadata:
  creationTimestamp: "2020-03-08T02:59:41Z"
  name: cm-literal
  namespace: default
  resourceVersion: "280454"
  selfLink: /api/v1/namespaces/default/configmaps/cm-literal
  uid: 5bd18816-bfd9-4f5d-abd8-5fc20d4ead92

配置文件创建

vim cm.yml

apiVersion: v1
kind: ConfigMap
metadata:
  name: cm-special-config
data:
  special.how: very
  special.type: charm
---
apiVersion: v1
kind: ConfigMap
metadata:
  name: cm-env-config
data:
  log_level: INFO

kubectl create -f cm.yml
[root@k8s-master configmap]# kubectl get cm
NAME                DATA   AGE
cm-c1               2      46m
cm-c2               1      45m
cm-env-config       1      13s # 刚创建的
cm-literal          2      41m
cm-special-config   2      13s # 刚创建的

Pod中使用ConfigMap

env使用

vim env.yml

apiVersion: v1
kind: Pod
metadata:
  name: cm-test-pod
spec:
  containers:
  - name: nginx
    image: habor-repo.com/library/nginx:v1
    command: ["/bin/sh", "-c", "env; echo -e $(SPECIAL_HOW)"] # 打印env和指定key
    env: # 容器添加环境变量
    - name: SPECIAL_HOW
      valueFrom: # 引用 configmap 的值
        configMapKeyRef:
          name: cm-special-config # configmap 的 name
          key: special.how # configmap 中的 key
    envFrom: # 环境变量导入
    - configMapRef:
        name: cm-env-config # configmap 的 name
  restartPolicy: Never # 不重启

kubectl create -f env.yaml
kubectl get pod
# 查看日志 
[root@k8s-master configmap]# kubectl logs cm-test-pod
KUBERNETES_SERVICE_PORT=443
KUBERNETES_PORT=tcp://10.96.0.1:443
HOSTNAME=cm-test-pod
HOME=/root
PKG_RELEASE=1~buster
KUBERNETES_PORT_443_TCP_ADDR=10.96.0.1
NGINX_VERSION=1.17.9
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
KUBERNETES_PORT_443_TCP_PORT=443
NJS_VERSION=0.3.9
KUBERNETES_PORT_443_TCP_PROTO=tcp
log_level=INFO # fromEnv 中的值
SPECIAL_HOW=very
KUBERNETES_SERVICE_PORT_HTTPS=443
KUBERNETES_PORT_443_TCP=tcp://10.96.0.1:443
KUBERNETES_SERVICE_HOST=10.96.0.1
PWD=/
nvery # 打印的 env的value

挂载使用

vim volume.yaml

apiVersion: v1
kind: Pod
metadata:
  name: cm-test-pod2
spec:
  containers:
  - name: nginx
    image: habor-repo.com/library/nginx:v1
    command: ["/bin/sh", "-c", "cat /etc/config/special.how"] # 文件名就是key，内容就是value
    volumeMounts:
    - name: config-volume # 挂载位置绑定挂在卷名字
      mountPath: /etc/config
  volumes:
  - name: config-volume # 定义一个挂载卷为configmap的内容
    configMap: 
      name: cm-special-config
  restartPolicy: Never # 不重启

kubectl create -f volume.yml
kubectl get pod
# 查看日志 
[root@k8s-master configmap]# kubectl logs cm-test-pod2
very

热更新

vim hot.yml

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: cm-test-pod3
spec:
  replicas: 1
  template:
    metadata:
      labels:
        app: cm-test-pod3
    spec:
      containers:
      - name: nginx
        image: habor-repo.com/library/nginx:v1
        volumeMounts:
        - name: config-volume # 挂载位置绑定挂在卷名字
          mountPath: /etc/config
      volumes:
      - name: config-volume # 定义一个挂载卷为configmap的内容
        configMap: 
          name: cm-special-config
      restartPolicy: Always # 不支持Never

kubectl create -f hot.yml
[root@k8s-master configmap]# kubectl get pod
NAME                            READY   STATUS      RESTARTS   AGE
cm-test-pod                     0/1     Completed   0          36m
cm-test-pod2                    0/1     Completed   0          22m
cm-test-pod3-75fbd58f94-v7rph   1/1     Running     0          5s
# 查看内容
kubectl exec cm-test-pod3-75fbd58f94-v7rph -it -- cat /etc/config/special.type

# 修改 cm-special-config 的值 
kubectl edit cm cm-special-config
# 再次查看 （大概10秒钟左右值会自动改变）
kubectl exec cm-test-pod3 -it -- cat /etc/config/special.type

# 修改pod内容强制触发滚动更新，适用于Env环境变量引用的configMap的情况
kubectl patch deployment cm-test-pod3 --patch '{"spec": {"template": {"metadata": {"annotations": {"version/config": "20200309"}}}}}'

[root@k8s-master configmap]# kubectl get pod
NAME                          READY   STATUS      RESTARTS   AGE
cm-test-pod                   0/1     Completed   0          38m
cm-test-pod2                  0/1     Completed   0          24m
cm-test-pod3-59688486-xd5zs   1/1     Running     0          23s # pod 已经重启了

主意：！！！

• 使用ConfigMap挂载的Env不会同步更新（除非Pod重新加载）
• 使用ConfigMap挂载的Volume会更新（大概10秒）

4.6.2、Secret

Service Account

用来访问Kubernetes API，由Kubernetes自动创建，并会自动挂载到Pod的/run/secrets/kubernetes.io/serviceaccount

# 假如有个pod为nginx
kubectl exec nignx -it -- ls /run/secrets/kubernetes.io/serviceaccount
ca.crt
namespace
token

OpqueSecret

使用base64来加密一些配置项

echo "admin" | base64 # YWRtaW4K
echo "YWRtaW4K" | base64 -d # admin

echo "123456" | base64 # MTIzNDU2Cg==
echo "MTIzNDU2Cg==" | base64 -d # 123456

vim secret.yml

apiVersion: v1
kind: Secret
metadata:
  name: mysecret
data:
  name: YWRtaW4K
  password: MTIzNDU2Cg==

kubectl create -f secret.yml
# 查看内容
kubectl get secret mysecret -o yaml

vim pod.yml

apiVersion: v1
kind: Pod
metadata:
  name: secret-test-pod
spec:
  containers:
  - name: nginx
    image: habor-repo.com/library/nginx:v1
    env: # 容器添加环境变量
    - name: SEC_USER_NAME
      valueFrom: # 引用 secret 的值
        secretKeyRef:
          name: mysecret # mysecret 的 name
          key: name # mysecret 中的 key
    - name: SEC_USER_PASSWORD
      valueFrom: 
        secretKeyRef:
          name: mysecret 
          key: password 
    volumeMounts:
    - name: secret-volume # 挂载位置绑定挂在卷名字
      mountPath: /etc/config
  volumes:
  - name: secret-volume # 定义一个挂载卷为configmap的内容
    secret: 
      secretName: mysecret
  restartPolicy: Never # 不重启

kubectl create -f pod.yml
kubectl get pod
# 查看挂载文件
[root@k8s-master secret]# kubectl exec secret-test-pod -it -- ls /etc/config
name  password
# 查看环境变量（进入容器内部查看）
[root@k8s-master secret]# kubectl exec secret-test-pod -it -- /bin/bash
root@secret-test-pod:/# echo $SEC_USER_NAME $SEC_USER_PASSWORD
admin 123456

kubernetes.io/dockerconfigjson

使用kubectl创建docker registry认证的secret

kubectl create secret docker-registry <registrykey名字> --docker-server=<docker仓库域名> --docker-username=<仓库登录名> --docker-password=<登录密码> --docker-emai=<邮箱（随便给）>

# 使用 docker login登录也可以
docker login <docker仓库域名>

在创建Pod的时候指定imagePullSecrets参数

apiVersion: v1
kind: Pod
metadata:  
name: foo
spec:  
  containers:    
  - name: foo      
    image: roc/awangyang:v1  
  imagePullSecrets:     
  - name: myregistrykey # 对应上面创建的 <registrykey名字>

4.6.3、Volume

emptyDir

当 Pod 被分配给节点时，首先创建emptyDir卷，并且只要该 Pod 在该节点上运行，该卷就会存在。正如卷的名字所述，它最初是空的。Pod 中的容器可以读取和写入emptyDir卷中的相同文件，尽管该卷可以挂载到每个容器中的相同或不同路径上。当出于任何原因从节点中删除 Pod 时，emptyDir中的数据将被永久删除

emptyDir的用法有：

• 暂存空间，例如用于基于磁盘的合并排序
• 用作长时间计算崩溃恢复时的检查点
• Web服务器容器提供数据时，保存内容管理器容器提取的文件

vim emptydir.yml

apiVersion: v1
kind: Pod
metadata:  
  name: test-pd
spec: 
  containers:
  - image: habor-repo.com/library/nginx:v1
    name: nginx
    volumeMounts:    
    - mountPath: /cache      
      name: cache-volume  
  - image: habor-repo.com/library/busybox:v1
    command: ["/bin/sh", "-c", "sleep 3600s;"]
    name: busybox    
    volumeMounts:    
    - mountPath: /cache      
      name: cache-volume  
  volumes:  
  - name: cache-volume 
    emptyDir: {}

kubectl create -f emptydir.yml
kubectl get pod 
kubectl describe pod test-pd
kubectl exec test-pd -c nginx -it -- /bin/bash
# date > /cache/a.txt 
kubectl exec test-pd -c nginx -it -- cat /cache/a.txt
# 查看另外一个 
kubectl exec test-pd -c busybox -it -- cat /cache/a.txt

hostPath

hostPath卷将主机节点的文件系统中的文件或目录挂载到集群中

• hostPath的用途如下：运行需要访问 Docker 内部的容器；使用/var/lib/docker的hostPath
• 在容器中运行 cAdvisor；使用/dev/cgroups的hostPath允许 pod 指定给定的 hostPath 是否应该在 pod
• 运行之前存在，是否应该创建，以及它应该以什么形式存在

除了所需的path属性之外，用户还可以为hostPath卷指定type

值	行为
	空字符串（默认）用于向后兼容，这意味着在挂载 hostPath 卷之前不会执行任何检查。
DirectoryOrCreate	如果在给定的路径上没有任何东西存在，那么将根据需要在那里创建一个空目录，权限设置为 0755，与 Kubelet 具有相同的组和所有权。
Directory	给定的路径下必须存在目录
FileOrCreate	如果在给定的路径上没有任何东西存在，那么会根据需要创建一个空文件，权限设置为 0644，与 Kubelet 具有相同的组和所有权。
File	给定的路径下必须存在文件
Socket	给定的路径下必须存在 UNIX 套接字
CharDevice	给定的路径下必须存在字符设备
BlockDevice	给定的路径下必须存在块设备

使用这种卷类型是请注意，因为：

• 由于每个节点上的文件都不同，具有相同配置（例如从 podTemplate 创建的）的 pod 在不同节点上的行为可能会有所不同
• 当 Kubernetes 按照计划添加资源感知调度时，将无法考虑hostPath使用的资源
• 在底层主机上创建的文件或目录只能由 root 写入。您需要在特权容器中以 root 身份运行进程，或修改主机上的文件权限以便写入hostPath卷

vim hostpath.yml

apiVersion: v1
kind: Pod
metadata:  
  name: test-pd2
spec: 
  containers:
  - image: habor-repo.com/library/nginx:v1
    name: nginx
    volumeMounts:    
    - mountPath: /cache      
      name: cache-volume  
  - image: habor-repo.com/library/busybox:v1
    command: ["/bin/sh", "-c", "sleep 3600s;"]
    name: busybox    
    volumeMounts:    
    - mountPath: /cache      
      name: cache-volume  
  volumes:  
  - name: cache-volume 
    hostPath: 
      path: /data # 本地路径
      type: Directory # 目录

# 在所有节点上创建 /data 目录
mkdir /data
kubectl create -f hostpath.yml
kubectl get pod -o wide 
# 假设在 k8s-node2 节点上
# date >/data/a.txt

kubectl exec test-pd2 -c nginx -it -- cat /cache/a.txt
# 查看另外一个 
kubectl exec test-pd2 -c busybox -it -- cat /cache/a.txt

# 发现有内容

4.6.4、PV&PVC

概念

PersistentVolume（PV）

是由管理员设置的存储，它是群集的一部分。就像节点是集群中的资源一样，PV 也是集群中的资源。 PV 是Volume 之类的卷插件，但具有独立于使用 PV 的 Pod 的生命周期。此 API 对象包含存储实现的细节，即 NFS、iSCSI 或特定于云供应商的存储系统

PersistentVolumeClaim（PVC）

是用户存储的请求。它与 Pod 相似。Pod 消耗节点资源，PVC 消耗 PV 资源。Pod 可以请求特定级别的资源（CPU 和内存）。声明可以请求特定的大小和访问模式（例如，可以以读/写一次或只读多次模式挂载）

• 静态 pv：

  • 集群管理员创建一些 PV。它们带有可供群集用户使用的实际存储的细节。它们存在于 Kubernetes API 中，可用于消费

• 动态：

  • 当管理员创建的静态 PV 都不匹配用户的PersistentVolumeClaim时，集群可能会尝试动态地为 PVC 创建卷。此配置基于StorageClasses：PVC 必须请求 [存储类]，并且管理员必须创建并配置该类才能进行动态创建。声明该类为""可以有效地禁用其动态配置
  • 要启用基于存储级别的动态存储配置，集群管理员需要启用 API server 上的DefaultStorageClass[准入控制器]。例如，通过确保DefaultStorageClass位于 API server 组件的--admission-control标志，使用逗号分隔的有序值列表中，可以完成此操作

• 绑定：

  • master 中的控制环路监视新的 PVC，寻找匹配的 PV（如果可能），并将它们绑定在一起。如果为新的 PVC 动态调配 PV，则该环路将始终将该 PV 绑定到 PVC。否则，用户总会得到他们所请求的存储，但是容量可能超出要求的数量。一旦 PV 和 PVC 绑定后，PersistentVolumeClaim绑定是排他性的，不管它们是如何绑定的。 PVC 跟PV 绑定是一对一的映射

持久化卷声明的保护

PVC 保护的目的是确保由 pod 正在使用的 PVC 不会从系统中移除，因为如果被移除的话可能会导致数据丢失当启用PVC 保护 alpha 功能时，如果用户删除了一个 pod 正在使用的 PVC，则该 PVC 不会被立即删除。PVC 的删除将被推迟，直到 PVC 不再被任何 pod 使用

PersistentVolume类型以插件形式实现。Kubernetes 目前支持以下插件类型：

• 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、 VMware Photon、Portworx Volumes、ScaleIO Volumes、StorageOS

PV 访问模式

PersistentVolume可以以资源提供者支持的任何方式挂载到主机上。如下表所示，供应商具有不同的功能，每个PV 的访问模式都将被设置为该卷支持的特定模式。例如，NFS 可以支持多个读/写客户端，但特定的 NFS PV 可能以只读方式导出到服务器上。每个 PV 都有一套自己的用来描述特定功能的访问模式：

• ReadWriteOnce——该卷可以被单个节点以读/写模式挂载
• ReadOnlyMany——该卷可以被多个节点以只读模式挂载
• ReadWriteMany——该卷可以被多个节点以读/写模式挂载

在命令行中，访问模式缩写为：

• RWO - ReadWriteOnce

• ROX - ReadOnlyMany

• RWX - ReadWriteMany

Volume 插件	ReadWriteOnce	ReadOnlyMany	ReadWriteMany
AWSElasticBlockStoreAWSElasticBlockStore	✓	-	-
AzureFile	✓	✓	✓
AzureDisk	✓	-	-
CephFS	✓	✓	✓
Cinder	✓	-	-
FC	✓	✓	-
FlexVolume	✓	✓	-
Flocker	✓	-	-
GCEPersistentDisk	✓	✓	-
Glusterfs	✓	✓	✓
HostPath	✓	-	-
iSCSI	✓	✓	-
PhotonPersistentDisk	✓	-	-
Quobyte	✓	✓	✓
NFS	✓	✓	✓
RBD	✓	✓	-
VsphereVolume	✓	-	- （pod 并列时有效）
PortworxVolume	✓	-	✓
ScaleIO	✓	✓	-
StorageOS	✓	-	-

回收策略

• Retain（保留）——手动回收
• Recycle（回收）——基本擦除（rm -rf /thevolume/*）
• Delete（删除）——关联的存储资产（例如 AWS EBS、GCE PD、Azure Disk 和 OpenStack Cinder 卷）将被删除

当前，只有 NFS 和 HostPath 支持回收策略。AWS EBS、GCE PD、Azure Disk 和 Cinder 卷支持删除策略

状态

卷可以处于以下的某种状态：

• Available（可用）：一块空闲资源还没有被任何声明绑定
• Bound（已绑定）：卷已经被声明绑定
• Released（已释放）：声明被删除，但是资源还未被集群重新声明
• Failed（失败）：该卷的自动回收失败

命令行会显示绑定到 PV 的 PVC 的名称

例子

安装nfs

1）NFS 服务主要进程：

• rpc.nfsd：最主要的 NFS 进程，管理客户端是否可登录
• rpc.mountd：挂载和卸载 NFS 文件系统，包括权限管理
• rpc.lockd：非必要，管理文件锁，避免同时写出错
• rpc.statd：非必要，检查文件一致性，可修复文件

2）关键工具

• 主要配置文件：/etc/exports
• NFS 文件系统维护命令：/usr/bin/exportfs
• 共享资源的日志文件：/var/lib/nfs/*tab
• 客户端查询共享资源命令：/usr/sbin/showmount
• 端口配置：/etc/sysconfig/nfs

3）NFS 服务端配置

在 NFS 服务器端的主要配置文件为 /etc/exports 时，通过此配置文件可以设置共享文件目录。每条配置记录由 NFS 共享目录、NFS 客户端地址和参数这 3 部分组成，格式如下：

[NFS 共享目录] [NFS 客户端地址 1 (参数 1, 参数 2, 参数 3……)] [客户端地址 2 (参数 1, 参数 2, 参数 3……)]

• NFS 共享目录：服务器上共享出去的文件目录
• NFS 客户端地址：允许其访问的 NFS 服务器的客户端地址，可以是客户端 IP 地址，也可以是一个网段 (192.168.141.0/24)
• 访问参数：括号中逗号分隔项，主要是一些权限选项

3.1）访问权限参数：

• ro：客户端对于共享文件目录为只读权限。默认
• rw：客户端对于共享文件目录具有读写权限

3.2）用户映射参数

• root_squash：使客户端使用 root 账户访冋时，服务器映射为服务器本地的匿名账号
• no_root_squash：客户端连接服务端时如果使用的是 root，那么也拥有对服务端分享的目录的 root 权限
• all_squash：将所有客户端用户请求映射到匿名用户或用户组（nfsnobody)
• no_all_squash：与上相反。默认
• anonuid=xxx：将远程访问的所有用户都映射为匿名用户，并指定该用户为本地用户(UID=xxx)
• anongid=xxx：将远程访问的所有用户组都映射为匿名用户组账户，并指定该匿名用户组账户为本地用户组账户(GUI=xxx)

3.3）其它配置参数

• sync：同步写操作，数据写入存储设备后返回成功信息。默认
• async：异步写提作，数据在未完全写入存储设备前就返回成功信息，实际还在内存
• wdelay：延迟写入选项，将多个写提请求合并后写入硬盘，减少 I/O 次数， NFS 非正常关闭数据可能丢失。默认
• no_wdelay：与上相反，不与 async 同时生效，如果 NFS 服务器主要收到小且不相关的请求，该选项实际会降低性能
• subtree：若输出目录是一个子目录，则 NFS 服务器将检查其父目录的权限。默认
• no_subtree：即使输出目录是一个子目录， NFS 服务器也不检查其父目录的权限，这样可以提高效率
• secure：限制客户端只能从小于 1024 的 TCP/IP 端口连接 NFS 服务器。默认
• insecure：允许客户端从大于 1024 的 TCP/IP 端口连接服务器

4）安装：

#创建一个目录作为共享文件目录
mkdir -p /usr/local/kubernetes/volumes

#给目录增加读写权限
chmod a+rw /usr/local/kubernetes/volumes

#**************** 安装 NFS 服务端 *******************
rpm -qa nfs-utils rpcbind
yum install -y nfs-utils rpcbind
systemctl start rpcbind #启动rpc服务 
systemctl status rpcbind #查看rpc服务状态 
systemctl start nfs #启动nfs服务 
systemctl status nfs #查看nfs服务状态 
# 注意：必须要先启动rpc服务，然后再启动NFS服务，如果先启动NFS服务，启动服务时会失败
# 检查开机是否自启动
# 1）. chkconfig 配置开机自启动
chkconfig nfs on 
chkconfig rpcbind on 
chkconfig --list nfs 
#nfs  0:关闭  1:关闭  2:启用  3:启用  4:启用  5:启用  6:关闭 
chkconfig --list rpcbind 
#rpcbind 0:关闭  1:关闭  2:启用  3:启用  4:启用  5:启用  6:关闭 
# 2）. /etc/rc.local 配置开机自启动
vim /etc/rc.local # 添加下面两行
systemctl start rpcbind
systemctl start nfs

#**************** 安装 NFS 客户端 *******************
# 安装客户端，实际上和服务端一样的
rpm -qa nfs-utils rpcbind
yum install -y nfs-utils rpcbind
systemctl start rpcbind #启动rpc服务 
systemctl status rpcbind #查看rpc服务状态 
systemctl start nfs #启动nfs服务 
systemctl status nfs #查看nfs服务状态

#**************** 分享目录 *******************
mkdir -p /usr/local/kubernetes/volumes
vi /etc/exports
/usr/local/kubernetes/volumes *(rw,sync,no_subtree_check)
# 说明：
# /usr/local/kubernetes/volumes：作为服务目录向客户端开放
# *：表示任何 IP 都可以访问
# rw：读写权限
# sync：同步权限
# no_subtree_check：表示如果输出目录是一个子目录，NFS 服务器不检查其父目录的权限 /usr/local/kubernetes/volumes *(rw,sync,no_subtree_check)
# 重启服务，使配置生效：
systemctl restart nfs

#**************** 客户端挂载分享目录 *******************
# 创建挂载目录
mkdir -p /usr/local/kubernetes/volumes-mount
# 将服务端的目录挂载到本地
mount 192.168.0.130:/usr/local/kubernetes/volumes /usr/local/kubernetes/volumes-mount
#使用 df 查看挂载
# 取消挂载
umount /usr/local/kubernetes/volumes-mount

测试

创建PV

vim pv.yml

apiVersion: v1
kind: PersistentVolume
metadata:
  name: nfs-pv-test
spec:
  # 设置容量
  capacity:
    storage: 1Gi
  # 访问模式
  accessModes:
    # 该卷能够以读写模式被多个节点同时加载
    - ReadWriteMany
  # 回收策略，这里是基础擦除 `rm-rf/thevolume/*`
  persistentVolumeReclaimPolicy: Recycle
  storageClassName: nfs
  nfs:
    # NFS 服务端配置的路径
    path: "/usr/local/kubernetes/volumes"
    # NFS 服务端地址
    server: 192.168.0.130
    readOnly: false

# 部署
kubectl create -f pv.yml

# 查看
[root@k8s-master pv]# kubectl get pv
NAME          CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS      CLAIM   STORAGECLASS   REASON   AGE
nfs-pv-test   1Gi        RWX            Recycle          Available           nfs                     2s
# 删除
kubectl delete pv --all

# 释放资源，删除对应的claimRef保存退出即可
kubectl edit pv nfs-pv-test

创建服务和PVC

1）使用spec.template.volumeClaimTemplates定义pvc

vim pvc.yml

apiVersion: v1
kind: Service
metadata:
  name: svc-pvc-nginx
  labels:
    app: svc-pvc-nginx
spec:
  selector:
    app: nginx
  ports:
  - name: web
    port: 8090
    targetPort: 80
  clusterIP: None # headless
---
apiVersion: apps/v1
kind: StatefulSet
metadata:  
  name: web
spec:
  selector:
    matchLabels:
      app: nginx
  serviceName: svc-pvc-nginx
  replicas: 1 # 为什么给1因为上面创建了一个pv，但是pvc和是一一对应的关系，如果多了就会出问题
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: habor-repo.com/library/nginx:v1
        ports:
        - name: web
          containerPort: 80
        volumeMounts:
        - name: www
          mountPath: /usr/share/nginx/html
  volumeClaimTemplates:
  - metadata:
      name: www
    spec:
      #必须和要使用的pv的accessModes一致，根据accessModes和storageClassName去请求
      accessModes: ["ReadWriteMany"] 
      storageClassName: nfs
      resources:
        requests: # 请求使用资源
          #Ki、Mi、Gi、Ti、Pi、Ei(International System of units)
          #http://physics.nist.gov/cuu/Units/binary.html
          storage: 500Mi       

kubectl apply -f pvc.yml
kubectl get statefulset
kubectl get pvc
kubectl get pod

# 测试
# 进入 nfs 服务端的分享目录
cd /usr/local/kubernetes/volumes
date >index.html

# 请求测试
kubectl get pod -o wide
[root@k8s-master pv]# kubectl get pod -o wide
NAME    READY   STATUS    RESTARTS   AGE   IP             NODE        NOMINATED NODE   READINESS GATES
web-0   1/1     Running   0          33s   10.244.2.155   k8s-node2   <none>           <none>
[root@k8s-master pv]# curl 10.244.2.155
2020年 03月 08日 星期日 19:31:19 CST

# 删除
kubectl delete statefulset --all
kubectl delete pvc --all
kubectl delete pod --all

2）使用PersistentVolume定义pvc

vim pvc2.yml

apiVersion: v1
kind: Service
metadata:
  name: svc-pvc-nginx
  labels:
    app: svc-pvc-nginx
spec:
  selector:
    app: nginx
  ports:
  - name: web
    port: 8090
    targetPort: 80
  clusterIP: None # headless
---
apiVersion: apps/v1
kind: StatefulSet
metadata:  
  name: web
spec:
  selector:
    matchLabels:
      app: nginx
  serviceName: svc-pvc-nginx
  replicas: 1 # 为什么给1因为上面创建了一个pv，但是pvc和是一一对应的关系，如果多了就会出问题
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: habor-repo.com/library/nginx:v1
        ports:
        - name: web
          containerPort: 80
        volumeMounts:
        - name: mypd
          mountPath: /usr/share/nginx/html
      volumes:
      - name: mypd
        persistentVolumeClaim:
          claimName: www
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: www
spec:
  #必须和要使用的pv的accessModes一致，根据accessModes和storageClassName去请求
  accessModes: ["ReadWriteMany"] 
  storageClassName: nfs
  resources:
    requests:
      storage: 100Mi

kubectl apply -f pvc2.yml
kubectl get statefulset
kubectl get pvc
kubectl get pod

# 测试
# 进入 nfs 服务端的分享目录
cd /usr/local/kubernetes/volumes
date >>index.html

# 请求测试
kubectl get pod -o wide
[root@k8s-master pv]# kubectl get pod -o wide
NAME    READY   STATUS    RESTARTS   AGE   IP             NODE        NOMINATED NODE   READINESS GATES
web-0   1/1     Running   0          33s   10.244.2.155   k8s-node2   <none>           <none>
[root@k8s-master pv]# curl 10.244.2.155
2020年 03月 08日 星期日 19:31:19 CST
2020年 03月 08日 星期日 20:00:38 CST

# 删除
kubectl delete statefulset --all
kubectl delete pvc --all
kubectl delete pod --all