企业运维实战--k8s学习笔记 k8s存储之configMap配置管理、Secret配置管理和Volumes配置管理及持久卷的静动态PersistentVolume、statefulset的使用

1.ConfigMap简介

Configmap用于保存配置数据，以键值对形式存储。
configMap 资源提供了向 Pod 注入配置数据的方法。
让镜像和配置文件解耦，以便实现镜像的可移植性和可复用性。

典型的使用场景：

填充环境变量的值
设置容器内的命令行参数
填充卷的配置文件

2.创建configmap

创建ConfigMap的方式有4种：

使用字面值创建
使用文件创建
使用目录创建
编写configmap的yaml文件创建

2.1.使用字面值创建

创建cm，并查看信息

kubectl create configmap my-config --from-literal=key1=config1 --from-literal=key2=config2
kubectl  get cm
kubectl  describe  cm my-config 

2.2文件创建

kubectl create configmap my-config-2 --from-file=/etc/resolv.conf
kubectl describe cm my-config-2

2.3使用目录创建

mkdir configmap
cd configmap/
mkdir test
cp /etc/passwd test/
cp /etc/fstab test/

kubectl create configmap my-config-3 --from-file=test
kubectl describe cm my-config-3

2.4.编写configmap的yaml文件

vi config.yaml

apiVersion: v1
kind: ConfigMap
metadata:
  name: cm1-config
data:
  db_host: "172.25.76.250"
  db_port: "3306"

kubectl apply -f config.yaml
kubectl describe cm cm1-config

3.ConfigMap使用

如何使用configmap：

通过环境变量的方式直接传递给pod
通过在pod的命令行下运行的方式
作为volume的方式挂载到pod内

3.1.设置环境变量的方式

vi pod.yaml

apiVersion: v1
kind: Pod
metadata:
  name: pod1
spec:
  containers:
    - name: pod1
      image: busyboxplus
      command: ["/bin/sh", "-c", "env"]
      env:
        - name: key1
          valueFrom:
            configMapKeyRef:
              name: cm1-config
              key: db_host
        - name: key2
          valueFrom:
            configMapKeyRef:
              name: cm1-config
              key: db_port
  restartPolicy: Never

执行pod.yaml文件，查看pod
查看pod的信息之后可以删掉pod1

kubectl apply -f pod.yaml
kubectl get pod

我们可以看到创建节点完成之后就自动退出了

容器执行已完成，在pod日志中查看结果

kubectl logs pod1

使用默认名称
vi pod1.yaml

apiVersion: v1
kind: Pod
metadata:
  name: pod2
spec:
  containers:
    - name: pod2
      image: busyboxplus
      command: ["/bin/sh", "-c", "env"]
      envFrom:
        - configMapRef:
            name: cm1-config
  restartPolicy: Never

执行文件pod1.yml ，并查看

kubectl apply -f pod1.yaml
kubectl logs pod2

3.2.通过在pod的命令行下运行的方式

vi pod2.yaml

apiVersion: v1
kind: Pod
metadata:
  name: pod3
spec:
  containers:
    - name: pod3
      image: busybox
      command: ["/bin/sh", "-c", "cat /config/db_host"]
      volumeMounts:
      - name: config-volume
        mountPath: /config
  volumes:
    - name: config-volume
      configMap:
        name: cm1-config

  restartPolicy: Never

kubectl apply -f pod2.yaml
kubectl logs pod3

将前面实验的cm删掉：

kubectl get cm
kubectl delete cm my-config
kubectl delete cm my-config-2
kubectl delete cm my-config-3

3.3作为volume的方式挂载到pod内

先写入nginx的配置文件nginx.conf，然后创建cm
vi nginx.conf

server {
    listen       8000;
    server_name  _;

    location / {
        root /usr/share/nginx/html;
        index  index.html index.htm;
    }
}

kubectl create configmap nginxconf --from-file=nginx.conf

编写nginx.yaml
vi nginx.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-nginx
spec:
  replicas: 1
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
        - name: nginx
          image: nginx
          volumeMounts:
          - name: config-volume
            mountPath: /etc/nginx/conf.d
      volumes:
        - name: config-volume
          configMap:
            name: nginxconf

编辑nginxconf的内容修改端口为8080(若执行yaml后编辑则conf会有延迟更新在下面会详细讲解)

kubectl edit cm nginxconf

执行清单nginx.yaml
查看pod信息

kubectl apply -f nginx.yaml
kubectl get pod -o wide

测试访问：
curl 10.244.179.78:8080

再次修改端口为8000

kubectl edit cm nginxconf

listen 8000;

再次访问失败
是因为我们需要刷新一下
刷新有两种办法：
1.
删除pod

kubectl delete  pod my-nginx-b9b58dbdf-hvsn4

因为是deployment所以会再次生成一个pod再次生成一个pod即可通过get pod查找新的ip后访问
2.

 kubectl patch deployments.apps my-nginx --patch '{"spec": {"template": {"metadata": {"annotations": {"version/config": "20200219"}}}}}'

kubectl get all后发现重新生成rs 说明刷新成功
此时会刷新ip则

kubectl get pod -o wide #查看新ip

curl 10.244.141.198:8000 #访问成功

4.Secret概述

Secret 对象类型用来保存敏感信息，例如密码、OAuth 令牌和 ssh key。
敏感信息放在 secret 中比放在 Pod 的定义或者容器镜像中来说更加安全和灵活。

Pod 可以用两种方式使用 secret：

作为 volume 中的文件被挂载到 pod 中的一个或者多个容器里
当 kubelet 为 pod 拉取镜像时使用

Secret的类型：

Service Account：Kubernetes 自动创建包含访问 API 凭据的 secret，并自动修改 pod 以使用此类型的 secret。
Opaque：使用base64编码存储信息，可以通过base64 --decode解码获得原始数据，因此安全性弱。
kubernetes.io/dockerconfigjson：用于存储docker registry的认证信息。

4.1Service Account

serviceaccout 创建时 Kubernetes 会默认创建对应的 secret。对应的 secret 会自动挂载到 Pod 的 /run/secrets/kubernetes.io/serviceaccount 目录中。

kubectl  run nginx --image=nginx
kubectl  exec -it   nginx  -- bash
cd /var/run/secrets/kubernetes.io/serviceaccount/
ls

查看secrets

kubectl get secrets

查看secrets的信息

kubectl describe secrets default-token-9lq8n

4.2 secret应用

4.2.1docker registry

kubernetes.io/dockerconfigjson用于存储docker registry的认证信息。

kubectl create secret docker-registry myregistrykey --docker-server=reg.westos.org --docker-username=admin --docker-password=westos --docker-email=lcf@westos.org  

编写资源清单，拉取私密仓库中的镜像

vi docker.conf

apiVersion: v1
kind: Pod
metadata:
  name: mypod
spec:
  containers:
    - name: game2048
      image: reg.westos.org/westos/game2048
  imagePullSecrets:
    - name: myregistrykey

执行registry.yaml文件。

kubectl apply -f registry.yaml
kubectl get pod
kubectl describe pod 

还有一种方法为

apiVersion: v1
kind: Pod
metadata:
  name: mypod
spec:
  containers:
    - name: game2048
      image: reg.westos.org/westos/game2048
  #imagePullSecrets:
  #  - name: myregistrykey

先注释掉后

kubectl patch serviceaccount default -p '{"imagePullSecrets": [{"name": "myregistrykey"}]}'

kubectl apply -f docker.conf
查看pod同样运行成功

5.Volumes配置管理

容器中的文件在磁盘上是临时存放的，这给容器中运行的特殊应用程序带来一些问题。首先，当容器崩溃时，kubelet 将重新启动容器，容器中的文件将会丢失,因为容器会以干净的状态重建。其次，当在一个 Pod 中同时运行多个容器时，常常需要在这些容器之间共享文件。 Kubernetes 抽象出 Volume 对象来解决这两个问题。

Kubernetes 卷具有明确的生命周期,与包裹它的 Pod 相同。 因此，卷比 Pod 中运行的任何容器的存活期都长，在容器重新启动时数据也会得到保留。 当然，当一个 Pod 不再存在时，卷也将不再存在。也许更重要的是，Kubernetes 可以支持许多类型的卷，Pod 也能同时使用任意数量的卷。

卷不能挂载到其他卷，也不能与其他卷有硬链接。 Pod 中的每个容器必须独立地指定每个卷的挂载位置。

Kubernetes 支持下列类型的卷：

awsElasticBlockStore 、azureDisk、azureFile、cephfs、cinder、configMap、csi
downwardAPI、emptyDir、fc (fibre channel)、flexVolume、flocker
gcePersistentDisk、gitRepo (deprecated)、glusterfs、hostPath、iscsi、local、
nfs、persistentVolumeClaim、projected、portworxVolume、quobyte、rbd
scaleIO、secret、storageos、vsphereVolume

5.1 emptyDir卷

当 Pod 指定到某个节点上时，首先创建的是一个 emptyDir 卷，并且只要 Pod 在该节点上运行，卷就一直存在。 就像它的名称表示的那样，卷最初是空的。 尽管 Pod 中的容器挂载 emptyDir 卷的路径可能相同也可能不同，但是这些容器都可以读写 emptyDir 卷中相同的文件。 当 Pod 因为某些原因被从节点上删除时，emptyDir 卷中的数据也会永久删除。

emptyDir 的使用场景：

缓存空间，例如基于磁盘的归并排序。
为耗时较长的计算任务提供检查点，以便任务能方便地从崩溃前状态恢复执行。
在 Web 服务器容器服务数据时，保存内容管理器容器获取的文件。

5.1.1emptyDir卷创建

mkdir volumes
cd volumes/
vi pod.yaml

apiVersion: v1
kind: Pod
metadata:
  name: vol1
spec:
  containers:
  - image: busyboxplus
    name: vm1
    command: ["sleep", "300"]
    volumeMounts:
    - mountPath: /cache
      name: cache-volume
  - name: vm2
    image: nginx
    volumeMounts:
    - mountPath: /usr/share/nginx/html
      name: cache-volume
  volumes:
  - name: cache-volume
    emptyDir:
      medium: Memory
      sizeLimit: 100Mi

执行pod.yaml文件

kubectl apply -f pod.yaml
kubectl exec -it vol1 -c vm1 -- bash
OCI runtime exec failed: exec failed: container_linux.go:380: starting container process caused: exec: "bash": executable file not found in $PATH: unknown
command terminated with exit code 126
[root@server1 volumes]# kubectl exec -it vol1 -c vm1 -- sh
/ # cd /cache/
/cache # ls
/cache # echo www.westos.org > index.html
/cache # curl localhost
www.westos.org

说明资源共享

/cache # dd if=/dev/zero of=bigfile bs=1M count=200
dd: writing 'bigfile': No space left on device
101+0 records in
99+1 records out

可以看到文件超过sizeLimit，则一段时间后（1-2分钟）会被kubelet evict掉。之所以不是“立即”被evict，是因为kubelet是定期进行检查的，这里会有一个时间差。
emptydir缺点：
不能及时禁止用户使用内存。虽然过1-2分钟kubelet会将Pod挤出，但是这个时间内，其实对node还是有风险的；影响kubernetes调度，因为empty dir并不涉及node的resources，这样会造成Pod“偷偷”使用了node的内存，但是调度器并不知晓；用户不能及时感知到内存不可用

5.2hostPath 卷

hostPath 卷能将主机节点文件系统上的文件或目录挂载到您的 Pod 中。 虽然这不是大多数 Pod 需要的，但是它为一些应用程序提供了强大的逃生舱。

hostPath 的一些用法有

运行一个需要访问 Docker 引擎内部机制的容器,挂载 /var/lib/docker 路径。 在容器中运行 cAdvisor 时，以
hostPath 方式挂载 /sys。 允许 Pod 指定给定的 hostPath 在运行 Pod之前是否应该存在，是否应该创建以及应该以什么方式存在。
查看pod调度节点是否创建相关目录

vi pod2.yaml

apiVersion: v1
kind: Pod
metadata:
  name: test-pd
spec:
  containers:
  - image: nginx
    name: test-container
    volumeMounts:
    - mountPath: /usr/share/nginx/html
      name: test-volume
  volumes:
  - name: test-volume
    hostPath:
      path: /data
      type: DirectoryOrCreate

执行host.yaml文件，并查看pod节点

kubectl apply -f pod2.yaml 
kubectl get pod -o wide

我们在node节点server2上可以看到文件目录自动创建了

5.2.1.结合nfs

共享文件系统nfs使用，首先在所有结点上安装nfs，在仓库结点上配置nfs
在server123安装:

yum install -y nfs-utils

在server5上：

yum install -y nfs-utils
vim /etc/exports
/nfsdata        *(rw,no_root_squash)
systemctl start nfs
showmount -e
mkdir /nfsdata

在server1上
编写清单文件：

vi nfs.yaml

apiVersion: v1
kind: Pod
metadata:
  name: test-pd
spec:
  containers:
  - image: nginx
    name: test-container
    volumeMounts:
    - mountPath: /usr/share/nginx/html
      name: test-volume
  volumes:
  - name: test-volume
    nfs:
      server: 172.25.76.5
      path: /nfsdata

验证nfs配置是否有误
showmount -e 172.25.76.5
删除之前创建的pod后执行
kubectl apply -f nfs.yaml
kubectl get pod

成功运行

在/nfsdata下面写发布文件：

vi index.html
server1

测试访问ip

6.PersistentVolume持久卷介绍

PersistentVolume（持久卷，简称PV）是集群内，由管理员提供的网络存储的一部分。就像集群中的节点一样，PV也是集群中的一种资源。它也像Volume一样，是一种volume插件，但是它的生命周期却是和使用它的Pod相互独立的。PV这个API对象，捕获了诸如NFS、ISCSI、或其他云存储系统的实现细节。
PersistentVolumeClaim（持久卷声明，简称PVC）是用户的一种存储请求。它和Pod类似，Pod消耗Node资源，而PVC消耗PV资源。Pod能够请求特定的资源（如CPU和内存）。PVC能够请求指定的大小和访问的模式（可以被映射为一次读写或者多次只读）。

有两种PV提供的方式：静态和动态。

静态PV：集群管理员创建多个PV，它们携带着真实存储的详细信息，这些存储对于集群用户是可用的。它们存在于Kubernetes API中，并可用于存储使用。
动态PV：当管理员创建的静态PV都不匹配用户的PVC时，集群可能会尝试专门地供给volume给PVC。这种供给基于StorageClass。

PVC与PV的绑定是一对一的映射。没找到匹配的PV，那么PVC会无限期得处于unbound未绑定状态。

6.1.持久卷PV --静态

首先在server5创建目录

[root@server5 ~]# cd /nfsdata/
[root@server5 nfsdata]# mkdir pv1
[root@server5 nfsdata]# mkdir pv2

创建NFS 静态PV PVC卷

vi pv1.yaml

apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv1
spec:
  capacity:
    storage: 1Gi
  volumeMode: Filesystem
  accessModes:
    - ReadWriteOnce    #ReadWriteMany 多点读写
  persistentVolumeReclaimPolicy: Recycle
  storageClassName: nfs
  nfs:
    path: /nfsdata/pv1
    server: 172.25.76.5
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: pvc1
spec:
  storageClassName: nfs
  accessModes:
    - ReadWriteOnce   
  resources:
    requests:
      storage: 1Gi   ##要小于等于PV的大小

执行并查看

kubectl apply -f  pv1.yaml 
kubectl get pvc
kubectl get pv

Pod挂载PV

vi pod1.yaml

apiVersion: v1
kind: Pod
metadata:
  name: test-pd
spec:
  containers:
  - image: nginx
    name: nginx
    volumeMounts:
    - mountPath: /usr/share/nginx/html
      name: vol1
  volumes:
  - name: vol1
    persistentVolumeClaim:
      claimName: pvc1

执行并查看ip

kubectl apply -f pod1.yaml 
kubectl get pod -o wide

在server5中编辑nginx发布文件
server5：

[root@server5 nfsdata]# cd pv1
[root@server5 pv1]# echo pv1 > index.html
[root@server5 pv1]# cd ..
[root@server5 nfsdata]# cd pv2
[root@server5 pv2]# echo pv2 > index.html

回到server1测试访问
curl 10.244.141.210
删除pod,pvc时pv会报错并且pod会增加一个报错pod

kubectl delete pod test-pd 
kubectl delete pvc pvc1 
kubectl get pv
kubectl get pod

寻找报错原因

kubectl describe pod recycler-for-pv1 

显示仓库内缺少busyboxL1.27版本

docker pull busybox:1.27
docker tag busybox:1.27 reg.westos.org/library/busybox:1.27
docker push reg.westos.org/library/busybox:1.27

添加后查看pv

kubectl get pv

成功并且server5中的pv1目录被自动清空

6.2.持久卷pv-动态

6.2.1 介绍

动态PV：当管理员创建的静态PV都不匹配用户的PVC时，集群可能会尝试专门地供给volume给PVC。这种供给基于StorageClass。

StorageClass提供了一种描述存储类（class）的方法，不同的class可能会映射到不同的服务质量等级和备份策略或其他策略等。

每个 StorageClass 都包含 provisioner、parameters 和 reclaimPolicy 字段， 这些字段会在StorageClass需要动态分配 PersistentVolume 时会使用到。

StorageClass的属性

Provisioner（存储分配器）：用来决定使用哪个卷插件分配
PV，该字段必须指定。可以指定内部分配器，也可以指定外部分配器。外部分配器的代码地址为：kubernetes-incubator/external-storage，其中包括NFS和Ceph等。
Reclaim Policy（回收策略）：通过reclaimPolicy字段指定创建的Persistent Volume的回收策略，回收策略包括：Delete 或者 Retain，没有指定默认为Delete。

自动创建PV和对应的PVC，本身不提供NFS存储，需要外部先有一套NFS存储服务。所以本章操作是基于实验环境中nfs已部署完成才进行的。

6.2.2 部署

详情：

https://github.com/kubernetes-sigs/nfs-subdir-external-provisioner

最好将server5的nfs服务设置开机自启：

systemctl enable --now nfs

下载镜像，并上传到仓库
在server1上：

docker load -i nfs-provisioner-v4.0.2.tar
docker push reg.westos.org/sig-storage/nfs-subdir-external-provisioner:v4.0.2 

创建操作目录,用于存放动态部署的文件
mkdir nfs
cd nfs
vi nfs-client-provisioner.yaml

apiVersion: v1
kind: ServiceAccount
metadata:
  name: nfs-client-provisioner
  # replace with namespace where provisioner is deployed
  namespace: nfs-client-provisioner  #需手动创建ns
---
kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: nfs-client-provisioner-runner
rules:
  - apiGroups: [""]
    resources: ["nodes"]
    verbs: ["get", "list", "watch"]
  - 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
subjects:
  - kind: ServiceAccount
    name: nfs-client-provisioner
    # replace with namespace where provisioner is deployed
    namespace: nfs-client-provisioner
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
  # replace with namespace where provisioner is deployed
  namespace: nfs-client-provisioner
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
  # replace with namespace where provisioner is deployed
  namespace: nfs-client-provisioner
subjects:
  - kind: ServiceAccount
    name: nfs-client-provisioner
    # replace with namespace where provisioner is deployed
    namespace: nfs-client-provisioner
roleRef:
  kind: Role
  name: leader-locking-nfs-client-provisioner
  apiGroup: rbac.authorization.k8s.io
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nfs-client-provisioner
  labels:
    app: nfs-client-provisioner
  # replace with namespace where provisioner is deployed
  namespace: 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
      containers:
        - name: nfs-client-provisioner
          image: sig-storage/nfs-subdir-external-provisioner:v4.0.2 #与仓库名字一致
          volumeMounts:
            - name: nfs-client-root
              mountPath: /persistentvolumes
          env:
            - name: PROVISIONER_NAME
              value: westos.org/nfs  #指定nfs共享路径
            - name: NFS_SERVER
              value: 172.25.76.5  #指定nfs server主机
            - name: NFS_PATH
              value: /nfsdata
      volumes:
        - name: nfs-client-root
          nfs:
            server: 172.25.76.5
            path: /nfsdata
---
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: managed-nfs-storage
provisioner: westos.org/nfs
parameters:
  archiveOnDelete: "false"  #true为删除后自动打包备份，false为删除后不打包

源清单nfs-client-provisioner.yaml最后一行为flase 其中的意义就是关闭删除后打包，即删除pvc后目录会消失
想要文件更新修改内容，必须删除sc后再次生成

kubectl delete sc managed-nfs-storage 
kubectl apply -f nfs-client-provisioner.yaml 
kubectl get sc ```

创建namespace

kubectl create namespace nfs-client-provisioner

执行文件fs-client-provisioner.yaml，查看sc

kubectl apply -f nfs-client-provisioner.yaml
kubectl get sc

创建pvc

vi pvc.yaml

kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: pvc1
spec:
  storageClassName: managed-nfs-storage
  accessModes:
    - ReadWriteMany
  resources:
    requests:
      storage: 1Gi

或设置默认sc
原理：

默认的 StorageClass 将被用于动态的为没有特定 storage class 需求的PersistentVolumeClaims配置存储：（只能有一个默认StorageClass）
如果没有默认StorageClass，PVC 也没有指定storageClassName 的值，那么意味着它只能够跟 storageClassName 也是“”的 PV 进行绑定。

kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: pvc1
spec:
  #storageClassName: managed-nfs-storage  注释掉
  accessModes:
    - ReadWriteMany
  resources:
    requests:
      storage: 1Gi

kubectl patch storageclass managed-nfs-storage -p '{"metadata": {"annotations": {"storageclass.kubernetes.io/is-default-class":"true"}}}' #手动设定默认storageclass
kubectl get sc

执行文件并查看pvc状态

kubectl apply -f pvc.yaml
kubectl get pvc
kubectl get pv

pv显示Delete，表示删除pvc后 pv也会删除，同时文件会打包
我们到server5上/nfsdata下面查看目录
创建pod节点
vi pod.yaml

apiVersion: v1
kind: Pod
metadata:
  name: test-pod
spec:
  containers:
  - image: nginx
    name: test-pod
    volumeMounts:
    - mountPath: "/usr/share/nginx/html"
      name: nfs-pvc
  volumes:
  - name: nfs-pvc
    persistentVolumeClaim:
      claimName: pvc1

我们可以看到test-pod已经运行

kubectl get pod -o wide

测试访问IP

[root@server5 nfsdata]# cd default-pvc1-pvc-d4655afc-6858-4385-83f4-094f0b15e5cc/
[root@server5 default-pvc1-pvc-d4655afc-6858-4385-83f4-094f0b15e5cc]# ls
[root@server5 default-pvc1-pvc-d4655afc-6858-4385-83f4-094f0b15e5cc]# echo 1 > index.html

server1:
curl 10.244.141.213

删除pod.yaml 并删除pvc节点

kubectl delete -f pod.yaml
kubectl delete -f pvc.yaml
kubectl get pvc
kubectl get pv

在server5上查看共享目录

共享目录下的文件也自动回收

7.StatefulSet

7.1StatefulSet实现pod拓扑

StatefulSet将应用状态抽象成了两种情况：
拓扑状态：应用实例必须按照某种顺序启动。新创建的Pod必须和原来Pod的网络标识一样
存储状态：应用的多个实例分别绑定了不同存储数据。

Pod被删除后重建，重建Pod的网络标识也不会改变,Pod的拓扑状态按照Pod的“名字+编号”的方式固定下来,并且为每个Pod提供了一个固定且唯一的访问入口,即Pod对应的DNS记录。

创建目录statefulset并进入
mkdir statefulset
cd statefulset/
vi deploy.yaml

apiVersion: v1
kind: Service
metadata:
 name: nginx-svc
 labels:
  app: nginx
spec:
 ports:
 - port: 80
   name: web
 clusterIP: None
 selector:
  app: nginx
---
apiVersion: apps/v1
kind: StatefulSet
metadata:
 name: web
spec:
 serviceName: "nginx-svc"
 replicas: 2
 selector:
  matchLabels:
   app: nginx
 template:
  metadata:
   labels:
    app: nginx
  spec:
   containers:
   - name: nginx
     image: nginx

执行文件deploy.yaml并查看svc的信息：
会发现后端有endpoint出现

kubectl apply -f  deploy.yaml
kubectl describe svc nginx-svc

如果需要扩容pv，只需要将参数更改
replicas: 6 然后在执行
kubectl get pod -w查看动态的变化

更改清单，将节点数恢复三个
进入容器测试一下：

kubectl run demo -it --image=busyboxplus --restart=Never

访问其中任何一个域名：
curl web-0.nginx-svc 访问成功

7.2. 将pvc与pod节点结合

vi deploy.yaml
下面添加如下内容即可注意格式

volumeMounts:
       - name: www
         mountPath: /usr/share/nginx/html
 volumeClaimTemplates:
  - metadata:
     name: www
    spec:
     #storageClassName: nfs
     accessModes:
     - ReadWriteOnce
     resources:
      requests:
       storage: 1Gi

执行清单

kubectl apply -f statefulset.yaml

在server5上也看到创建贡献目录成功！

创建测试index.html，进入/mnt/nfs各目录中

[root@server5 nfsdata]# cd default-www-web-0-pvc-4c83debb-6143-4aed-84f6-6a5f53649244/
[root@server5 default-www-web-0-pvc-4c83debb-6143-4aed-84f6-6a5f53649244]# echo 0 >index.html
[root@server5 default-www-web-0-pvc-4c83debb-6143-4aed-84f6-6a5f53649244]# cd ..
[root@server5 nfsdata]# cd default-www-web-1-pvc-4b428dd1-ab98-42eb-8b96-5ac525ad3fa1/
[root@server5 default-www-web-1-pvc-4b428dd1-ab98-42eb-8b96-5ac525ad3fa1]# echo 1 >index.html
[root@server5 default-www-web-1-pvc-4b428dd1-ab98-42eb-8b96-5ac525ad3fa1]# cd ..
[root@server5 nfsdata]# cd default-www-web-2-pvc-653d934a-d593-421a-861a-af27eb6c6721/
[root@server5 default-www-web-2-pvc-653d934a-d593-421a-861a-af27eb6c6721]# echo 2 > index.html

进入容器访问测试
kubectl run demo -it --image=busyboxplus --restart=Never
curl nginx-svc

删除副本后重新拉起，可继续保留之前的内容
将参数replicas: 0就可以实现清除数据
进入容器测试后依旧可以实现负载均衡。