企业运维实战--k8s学习笔记 k8s存储之configMap配置管理、Secret配置管理和Volumes配置管理及持久卷的静动态PersistentVolume、statefulset的使用
1.ConfigMap简介Configmap用于保存配置数据，以键值对形式存储。configMap 资源提供了向 Pod 注入配置数据的方法。让镜像和配置文件解耦，以便实现镜像的可移植性和可复用性。典型的使用场景：填充环境变量的值设置容器内的命令行参数填充卷的配置文件2.创建configmap创建ConfigMap的方式有4种：使用字面值创建使用文件创建使用目录创建编写configmap的yaml
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就可以实现清除数据
进入容器测试后依旧可以实现负载均衡。
K8S/Kubernetes社区为您提供最前沿的新闻资讯和知识内容
更多推荐
0
0- 0
已为社区贡献8条内容
所有评论(0)