赞
踩
Configmap用于保存配置数据,以键值对形式存储。
configMap 资源提供了向 Pod 注入配置数据的方法。
让镜像和配置文件解耦,以便实现镜像的可移植性和可复用性。
典型的使用场景:
填充环境变量的值
设置容器内的命令行参数
填充卷的配置文件
创建ConfigMap的方式有4种:
使用字面值创建
使用文件创建
使用目录创建
编写configmap的yaml文件创建
创建cm,并查看信息
kubectl create configmap my-config --from-literal=key1=config1 --from-literal=key2=config2
kubectl get cm
kubectl describe cm my-config
kubectl create configmap my-config-2 --from-file=/etc/resolv.conf
kubectl describe cm my-config-2
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
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
如何使用configmap:
通过环境变量的方式直接传递给pod
通过在pod的命令行下运行的方式
作为volume的方式挂载到pod内
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
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
先写入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 #访问成功
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的认证信息。
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
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同样运行成功
容器中的文件在磁盘上是临时存放的,这给容器中运行的特殊应用程序带来一些问题。首先,当容器崩溃时,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 服务器容器服务数据时,保存内容管理器容器获取的文件。
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的内存,但是调度器并不知晓;用户不能及时感知到内存不可用
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上可以看到文件目录自动创建了
共享文件系统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
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未绑定状态。
首先在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目录被自动清空
动态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已部署完成才进行的。
详情:
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 ```
- 1
- 2
- 3
创建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上查看共享目录
共享目录下的文件也自动回收
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 访问成功
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就可以实现清除数据
进入容器测试后依旧可以实现负载均衡。
Copyright © 2003-2013 www.wpsshop.cn 版权所有,并保留所有权利。