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就可以实现清除数据
进入容器测试后依旧可以实现负载均衡。

Logo

K8S/Kubernetes社区为您提供最前沿的新闻资讯和知识内容

更多推荐