[系统运维]k8s（七）ConfigMap，Secret，Volumes（StorageClass），StatefulSet

提示：文章写完后，目录可以自动生成，如何生成可参考右边的帮助文档

一、ConfigMap

• Configmap用于保存配置数据，以键值对形式存储。

• configMap 资源提供了向 Pod 注入配置数据的方法。

• 旨在让镜像和配置文件解耦，以便实现镜像的可移植性和可复用性。

  • 典型的使用场景：

  • 填充环境变量的值

  • 设置容器内的命令行参数

  • 填充卷的配置文件

1. 创建ConfigMap的方式

1.1 使用字面值创建

创建字为my-config的configmap，key-value方式定义，key1的值是config1，key2的值是config2。
查看，产生了新的cm为my-config，并且键值已写进去。

1.2 使用文件创建

key的名称是文件名称，value的值是这个文件的内容

1.3 使用目录创建

目录中的文件名为key，文件内容是value

1.4 编写configmap的yaml文件创建

查看名为cm1-config的configmap的详细信息

2.configmap使用

• 通过环境变量的方式直接传递给pod

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

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

2.1 环境变量的方式直接传递给pod

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		%把cm1-config中的db_host这个key改名为key1
              key: db_host
        - name: key2
          valueFrom:
            configMapKeyRef:
              name: cm1-config		%把cm1-config中的db_port这个key改名为key2
              key: db_port
  restartPolicy: Never

创建pod后查看pod1日志，key1和key2已写入

2.2 使用conigmap设置命令行参数

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

查看pod的日志

2.3 通过数据卷使用configmap

piVersion: v1
kind: Pod
metadata:
  name: pod2
spec:
  containers:
    - name: pod2
      image: nginx
      #command: ["/bin/sh", "-c", "cat /config/db_host"]	%查看/config/db_host
      volumeMounts:
      - name: config-volume
        mountPath: /config		%把cm1-config的数据卷挂载到pod2容器内的/config
  volumes:
    - name: config-volume		%变量来源于cm1-config
      configMap:
        name: cm1-config

信息来源cm1-config

3. configmap热更新

cat nginx.conf

文件方式创建名为nginxconf的configmap

查看名为nginxconf的configmap的详细信息

,编写清单 nginx.yaml文件, 挂载覆盖nginx配置文件
cat nginx.yaml

创建名为my-nginx的pod

更新nginx的配置文件nginx.conf，修改端口为8080

测试：

查看分配端口并访问

修改端口8080为8000

访问，发现未更改，此时还是访问的8080端口

可以看出configmap热更新以生效,但访问Pod的8000端口是无效的：

configmap热更新后，并不会触发相关Pod的滚动更新，需要手动触发, 这样才能再次加载nginx.conf配置文件：

• 每次通过修改“version/config”来触发Pod滚动更新。

• 使用configmap挂载的env环境变量是不会更新的。

刷新副本

访问8000端口成功，ip由10.244.22.35变化为10.244.22.36，访问重新分配的IP

二、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的认证信息。

每个namespace下有一个名为default的默认的ServiceAccount对象

ServiceAccount里有一个名为Tokens的可以作为Volume一样被Mount到Pod里的Secret，当Pod启动时这个Secret会被自动Mount到Pod的指定目录下，用来协助完成Pod中的进程访问API Server时的身份鉴权过程。

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

1 从文件中创建Secret

创建认证文本文件

echo -n 'admin' > ./username.txt
echo -n 'westos' > ./password.txt
kubectl create secret generic db-user-pass --from-file=./username.txt --from-file=./password.txt
kubectl get secrets

查看名为db-user-pass的secret的认证信息

默认情况下 kubectl get和kubectl describe 为了安全是不会显示密码的内容

Opaque Secret 其value为base64编码后的值。
如果密码具有特殊字符，则需要使用 \ 字符对其进行转义

可以通过以下方式查看密码的内容
查看yaml格式的secret ，可以看到base64格式的认证信息

2 编写一个 secret 对象

cat secret.yaml

3 将Secret挂载到Volume中

cat secret.yaml

apiVersion: v1
kind: Pod
metadata:
  name: mysecret
spec:
  containers:
  - name: nginx
    image: nginx
    volumeMounts:
    - name: secrets
      mountPath: "/secret"
      readOnly: true
  volumes:
  - name: secrets
    secret:
      secretName: mysecret

进入mysecret pod节点，查看挂载情况，文件挂载在根目录下的/secret/中

4 向指定路径映射 secret 密钥

cat secret.yaml

apiVersion: v1
kind: Pod
metadata:
  name: mysecret
spec:
  containers:
  - name: nginx
    image: nginx
    volumeMounts:
    - name: secrets
      mountPath: "/secret"
      readOnly: true
  volumes:
  - name: secrets
    secret:
      secretName: mysecret
      items:
      - key: username
        path: my-group/my-username

进入mysecret pod节点，查看文件挂载在指定路径my-group/my-username下

5 将Secret设置为环境变量

cat secret.yaml

查看pod状态

进入secret-env 的pod节点，env 查看环境变量中是否有认证文件信息

环境变量读取Secret很方便，无法支撑Secret动态更新。
修改密码为redhat

发现未变

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

secret的格式为docker-registry

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



查看pod节点详细信息，发现拉取成功

三、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
  • https://kubernetes.io/zh/docs/concepts/storage/volumes/

1 emptyDir卷

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

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

• 默认情况下， emptyDir 卷存储在支持该节点所使用的介质上；这里的介质可以是磁盘或 SSD 或网络存储，这取决于您的环境。 但是，您可以将 emptyDir.medium 字段设置为 “Memory”，以告诉 Kubernetes 为您安装 tmpfs（基于内存的文件系统）。 虽然 tmpfs 速度非常快，但是要注意它与磁盘不同。 tmpfs 在节点重启时会被清除，并且您所写入的所有文件都会计入容?的内存消耗，受容?内存限制约束。

3.1 同一个pod下的两个容器共享volumes

一个卷挂在pod内两个容器的不同路径下，同一个pod内共享volumes

实验环境：

新建目录volumes

创建pod：两个容器nginx+busyboxplus

执行清单

访问节点，报错403，无默认页面

进入容器，创建默认发布文件

再次访问，成功

进入pod内的第二个容器，追加内容至默认发布页

进入pod内的第一个容器，访问，内容与第二个容器访问的内容相同，说明：
busyboxplus与nginx共享volumes

3.2 sizeLimit

看到文件超过sizeLimit，则一段时间后（1-2分钟）会被kubelet evict掉。之所以不是“立即”被evict，是因为kubelet是定期进行检查的，这里会有一个时间差。

• emptydir缺点：
  • 不能及时禁止用户使用内存。虽然过1-2分钟kubelet会将Pod挤出，但是这个时间内，其实对node还是有风险的；
  • 影响kubernetes调度，因为empty dir并不涉及node的resources，这样会造成Pod“偷偷”使用了node的内存，但是调度器并不知晓；
  • 用户不能及时感知到内存不可用

创建大于设定100M大小的文件，节点会坏掉

pod不running！！！

查看pod的详细信息，发现有报错

2 hostPath卷

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

• hostPath 的一些用法有：

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

• 除了必需的 path 属性之外，用户可以选择性地为 hostPath 卷指定 type
  

• 当使用这种类型的卷时要小心，因为：

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

2.1 查看pod调度节点是否创建相关目录

cat host.yaml

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

执行清单，创建名为test-pd的pod

访问

pod被调度到server4上

server4查看pod调度节点是否创建相关目录

server2 上进入容器，测试挂载是否成功：
/test-pd目录已经创建，可以看到目录内已存在内容

在容器挂载目录中创建一个文件，受控node主机的相应目录也会自动生成相应文件

2.2 NFS

共享文件系统nfs使用

首先在所有结点上安装nfs，在仓库结点上配置nfs
server1仓库节点：

共享/mnt/nfs

server2：
cat nfs.yaml，在k8s集群利用nfs部署nginx

验证nfs配置是否有误

pod不running！！！server4未安装nfs，调度到那里需要安装，

pod此时running！！！

测试：
server1：

cd /mnt/nfs
echo www.westos.org > index.html

server2：
进入容器，测试挂载是否成功

[root@server1 volumes]# kubectl exec -it  test-pd -- sh
/# ls
bin  boot  dev	docker-entrypoint.d  docker-entrypoint.sh  etc	home  lib  lib64  media  mnt  opt  proc  root  run  sbin  srv  sys  tmp  usr  var
/# cd /usr/share/nginx/html/
/# ls
index.html
/# cat index.html
www.westos.org
/# 

3 PersistentVolume（持久卷PV）

3.1 PVC简介

• 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未绑定状态。

3.2 PersistentVolume原理

• 使用
  Pod使用PVC就像使用volume一样。集群检查PVC，查找绑定的PV，并映射PV给Pod。对于支持多种访问模式的PV，用户可以指定想用的模式。一旦用户拥有了一个PVC，并且PVC被绑定，那么只要用户还需要，PV就一直属于这个用户。用户调度Pod，通过在Pod的volume块中包含PVC来访问PV。

• 释放
  当用户使用PV完毕后，他们可以通过API来删除PVC对象。当PVC被删除后，对应的PV就被认为是已经是“released”了，但还不能再给另外一个PVC使用。前一个PVC的属于还存在于该PV中，必须根据策略来处理掉。

• 回收
  PV的回收策略告诉集群，在PV被释放之后集群应该如何处理该PV。当前，PV可以被Retained（保留）、 Recycled（再利用）或者Deleted（删除）。保留允许手动地再次声明资源。对于支持删除操作的PV卷，删除操作会从Kubernetes中移除PV对象，还有对应的外部存储（如AWS
  EBS，GCE PD，Azure Disk，或者Cinder volume）。动态供给的卷总是会被删除。

• 访问模式
  ReadWriteOnce – 该volume只能被单个节点以读写的方式映射
  ReadOnlyMany – 该volume可以被多个节点以只读方式映射
  ReadWriteMany – 该volume可以被多个节点以读写的方式映射

  在命令行中，访问模式可以简写为：
  RWO - ReadWriteOnce
  ROX - ReadOnlyMany
  RWX -
  ReadWriteMany

• 回收策略
  Retain：保留，需要手动回收
  Recycle：回收，自动删除卷中数据
  Delete：删除，相关联的存储资产，如AWS EBS，GCE PD，Azure Disk，or OpenStack Cinder卷都会被删除

  –——当前，只有NFS和HostPath支持回收利用，AWS EBS，GCE PD，Azure Disk，or OpenStack Cinder卷支持删除操作。

• 状态：
  Available：空闲的资源，未绑定给PVC
  Bound：绑定给了某个PVC
  Released：PVC已经删除了，但是PV还没有被集群回收
  Failed：PV在自动回收中失败了
  ------命令行可以显示PV绑定的PVC名称。

3.1 静态PV（创建NFS 静态PV卷）

之前实验已经安装配置了nfs

[root@server1 volumes]# yum install -y nfs-utils
[root@server1 volumes]# vim /etc/exports
[root@server1 volumes]# systemctl  start nfs
[root@server1 volumes]# showmount  -e
Export list for server1:
/mnt/nfs *

在共享目录pv1 pv2下设置发布内容不同的index.html

vim pv.yaml，创建pv脚本pv.yml，指定位置为/mnt/nfs/pv1和 /mnt/nfs/pv2


vim pvc.yaml，创建pvc的脚本pvc.yml ，volume分别为pv1和pv2

查看pvc，pvc与pv已经绑定
查看pv，CLAIM 中为default/pvc1和default/pvc2，说明已经链接

vim pod.yaml，创建pod，使用持久化存储方式

查看pod的状态

查看pod的分配到的ip

测试：
访问pod不同，发布内容不同


删除pod再次建立，pvc依旧存在，依旧可以使用，注意ip需要重新获取

删除pvc，查看pv状态

pv状态为Available，自动回收！！！

nfs的server端pv1和pv2目录都消失

3.2 NFS动态分配PV

实验环境：

删除静态pv的pvc和pv

• 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。

• 更多属性查看：https://kubernetes.io/zh/docs/concepts/storage/storage-classes/

• NFS Client Provisioner是一个automatic provisioner，使用NFS作为存储，自动创建PV和对应的PVC，本身不提供NFS存储，需要外部先有一套NFS存储服务。

  • PV以 ${namespace}-${pvcName}-${pvName}的命名格式提供（在NFS服务器上）
  • PV回收的时候以 archieved-${namespace}-${pvcName}-${pvName} 的命名格式（在NFS服务器上）
  • nfs-client-provisioner源码地址：https://github.com/kubernetes-incubator/external-storage/tree/master/nfs-client

准备好镜像,上传至私有仓库

systemctl restart nfs

创建操作目录并进入，将文件移入

编写生成脚本 nfs-client-provisioner.yaml ,内容包含配置授权，部署NFS Client Provisioner，创建 NFS SotageClass
参考官网：https://github.com/kubernetes-incubator/external-storage/tree/master/nfs-client

apiVersion: v1
kind: ServiceAccount
metadata:
  name: nfs-client-provisioner

  # replace with namespace where provisioner is deployed
  namespace: nfs-client-provisioner
---
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: nfs-subdir-external-provisioner:v4.0.0
          volumeMounts:
            - name: nfs-client-root
              mountPath: /persistentvolumes
          env:
            - name: PROVISIONER_NAME
              value: westos.org/nfs
            - name: NFS_SERVER
              value: 172.25.28.1
            - name: NFS_PATH
              value: /mnt/nfs
      volumes:
        - name: nfs-client-root
          nfs:
            server: 172.25.28.1
            path: /mnt/nfs
---
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: managed-nfs-storage
provisioner: westos.org/nfs
parameters:
  archiveOnDelete: "true" ###删除是否需要打包：默认为true

执行清单前，先创建namespace： nfs-client-provisioner，以下实验皆在此环境下运行

执行清单，查看sc

创建pvc
cat test-pvc.yaml

查看pv

查看pvc

创建pod

测试：
进入共享目录，可以查看到default-test-claim-******，该目录为动态pv自动创建，用于存放卷数据，在目录内创建index.html

删除pvc，pvc和pv都消失

/mnt/nfs目录下会生成一个archived-****目录

删除是否需要打包：默认为true

删除archived-****目录

修改清单，将删除是否需要打包：修改为false

重新创建pvc

重新创建pod

测试：
访问

删除pvc后

不会在 /mnt/nfs目录下会生成一个archived-****目录！！！

4 StorageClass存储类

默认的 StorageClass 将被用于动态的为没有特定 storage class 需求的PersistentVolumeClaims 配置存储

设定默认存储类

不指定存储类，也不添加存储类时，pod处于pending状态！！！

将managed-nfs-storage设定为默认的存储类

kubectl patch storageclass <your-class-name> -p '{"metadata": {"annotations":{"storageclass.kubernetes.io/is-default-class":"true"}}}'

即使不添加存储类，也会到默认的存储类，pvc不会pending！！！

当添加没有的存储类时

pvc会处于pending！！！

不指定到默认存储类

查看pvc状态，正常

四、 StatefulSet控制器(有序+持久化)

有序的稳定的网络标识和持久化存储pvc

• StatefulSet将应用状态抽象成了两种情况：

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

• StatefulSet给所有的Pod进行了编号，编号规则是：$(statefulset名称)-$(序号)，从0开始。

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

实验环境：
删除其他svc

删除pvc，pv

删除ingress

删除deployment的pod

4.1 通过Headless Service维持Pod的拓扑状态

需要先配置Headless Service

创建工作目录并进入
编辑资源清单，创建服务nginx-svc服务

查看nginx-svc服务的详细信息，发现没有后端！！！

编辑资源清单创建StatefulSet控制器的pod，设定初始副本数为2个

发现pod的名称是从0开始递增！！！有先后顺序的建立pod

此时查看nginx-svc的服务，发现有后端，由2个pod提供

有序

扩容pod至6个

发现从web0开始建立，有顺序！！！

statefulset控制器创建的pod使用修改清单中的副本数，即可删除pod

查看pod

删除也是有顺序，先建立的后删除！！！

无头服务的解析与访问
修改副本数到3个

-w查看建立过程

查看pod

创建交互式pod，查看nginx-svc解析，测试域名访问curl nginx-svc，得到访问内容

4.2 StatefulSet+持久化存储pvc

PV和PVC的设计，使得StatefulSet对存储状态的管理成为了可能:
StatefulSet还会为每一个Pod分配并创建一个同样编号的PVC。这样，kubernetes就可以通过Persistent Volume机制为这个PVC绑定对应的PV，从而保证每一个Pod都拥有一个独立的Volume。

cat statefulset.yml

apiVersion: apps/v1
kind: StatefulSet
metadata:
 name: web
spec:
 serviceName: "nginx-svc"
 replicas: 3
 selector:
  matchLabels:
   app: nginx
 template:
  metadata:
   labels:
    app: nginx
  spec:
   containers:

   - name: nginx
     image: myapp:v1
     ports:
     - containerPort: 80
       name: web
       volumeMounts:
       - name: www
         mountPath: /usr/share/nginx/html
          volumeClaimTemplates:
  - metadata:
    name: www
    spec:
     #storageClassName: nfs
     accessModes:
     - ReadWriteOnce
       resources:
         requests:
       storage: 1Gi

运行清单，查看pod

查看pv、pvc

/mnt/nfs目录下会生成三个目录

分别查看三个pod的详细信息，发现已经写入



编写不同的发布页内容

进入交互界面，查看解析，测试负载均衡
访问格式：web-*.nginx-svc‘
负载测试： nginx-svc

修改副本数量为0，来删除statefulset控制器创建的pod

重新创建三个pod

再次访问时候发现继续保留之前的内容！！！

真实路径下存储,删减节点不影响存储，新建立节点内容依旧存在