K8S 进阶部分
1. Deployment 部署
1.1 自愈能力
1.2 多副本
1.3 扩容、缩容
1.4 滚动更新
1.5 版本回退
1.6 工作负载
2. Service 网络
2.1 ClusterIP 模式
2.2 NodePort 模式
3. Ingress 网关
3.1 安装
3.2 实战
3.2.1 apply一个yaml文件
3.2.2 解析yaml为架构图
3.2.3 域名访问
3.3 Ingress的高级功能
3.3.1 路径重写
3.3.2 流量限制
4. 存储抽象
4.1 环境准备
4.2 PV 和 PVC
4.2.1 创建 PV 池
4.2.2 PVC 创建与绑定
4.3 配置 ConfigMap（推荐）
4.3.1 配置文件准备
4.3.2 yaml文件创建Pod
4.3.3 进入容器查看效果
4.3.4 图解
4.4 Secret
5. 总结
5.1 工作负载
5.2 服务
5.3 配置和存储
1. Deployment 部署
1.1 自愈能力
强大的自愈能力
# 1、先删除之前的pod
[root@cluster-master /]# kubectl get pod
NAME READY STATUS RESTARTS AGE
myapp 2/2 Running 3 3d9h
[root@cluster-master /]# kubectl delete pod myapp
pod "myapp" deleted
# 2、创建一个Pod
kubectl create deployment mytomcat --image=tomcat:9.0
[root@cluster-master /]# kubectl get pod
NAME READY STATUS RESTARTS AGE
mytomcat-77bcdc77bf-kd6qm 1/1 Running 0 2m38s
1
2
3
4
5
6
7
8
9
10
11
12
测试delete掉这个pod：
左边的是使用watch -n 1 kubectl get pod 一秒自动执行一次这个命令，我们发现，我们欲删除的这个这个后缀为kd6qm的mytomcat，确实是被删掉了，但Deployment又帮我们重新启动了一个，后缀不同的pod。强大的自愈能力。
image-20220722204010786
如果我们真想删除这个Pod，其实是要把这个Deployment删除
[root@cluster-master /]# kubectl get deploy
NAME READY UP-TO-DATE AVAILABLE AGE
mytomcat 1/1 1 1 11m
[root@cluster-master /]# kubectl delete deploy mytomcat
deployment.apps "mytomcat" deleted
[root@cluster-master /]# kubectl get pod
No resources found in default namespace.
1
2
3
4
5
6
7
8
9
1.2 多副本
通过Deployment创建五个tdengine副本（因为我在学TDengine）
1、键入kubectl create deployment my-deptd01 --image=tdengine/tdengine --replicas=5
image-20220722210810857
2、键入kubectl get pod -owide可以查看各个节点上assigned的任务
image-20220722210858043
3、当node2节点宕机，deployemnt会自动的在其它节点再启动对应的个数服务，又是极好的自愈能力。故障转移。
当一个节点宕机，K8S不会立即重新在新的节点部署，会有一个阈值，监测五分钟或者多久没有脸上，就认定为下线。
4、reboot和shutdown都测试了，只展示shutdown的，reboot的很容易理解
看到node2在集群里已经不是ready了
image-20220722212544366
同时，deployemnt在其他节点创建新的pod
image-20220722212507000
查看到已经都OK了，宕机的三个几点都在node1上重新创建了。
image-20220722212758921
下面这个展示的是reboot的效果图
image-20220722211407707
1.3 扩容、缩容
# 扩缩容
kubectl scale deploy/my-deptd01 --replicas=6
kubectl scale deploy/my-deptd01 --replicas=2
# yaml方式实现
kubectl edit deploy my-deptd01 # 会给我们展示yaml文件，找replicas进行修改来实现
# 可视化的也比较简单
1
2
3
4
5
6
7
8
1.4 滚动更新
图解：
需要更新为V2版本，但是不可以停机，会一直有流量进来，先启动一个V2的Pod，把流量接到V2上，这个Pod接受之后，再把V1的对应的Pod下掉（具体是删除还是隐藏？因为后面还要回滚）
“启动一个杀一个”
image-20220722221652391
命令实现：
# 版本更新
kubectl set image deploy/my-dep01 nginx=nginx:1.16.1 --record
# 我们可以通过两种方式来查看这个滚动更新的状态
kubectl get pod -w
watch -n 1 kubectl get pod
1
2
3
4
5
6
1.5 版本回退
# 查看过去的版本
kubectl rollout history deploy/my-dep01
#查看某个历史详情
kubectl rollout history deploy/my-dep01 --revision=2
#回滚(回到上次)
kubectl rollout undo deploy/my-dep01
#回滚(回到指定版本)
kubectl rollout undo deploy/my-dep01 --to-revision=2
1
2
3
4
5
6
7
8
9
10
11
image-20220723092108951
1.6 工作负载
官网介绍工作负载资源
Deployment：无状态应用部署，比如微服务、提供多副本。
StateFulSet：有状态应用部署，比如数据库之类的，redis、mysql。可以固定IP，可以保证一个Pod宕掉，重启之后还是之前的IP地址，提供稳定的存储、网络等功能。
DaemonSet：守护型应用部署，比如日志收集组件，每一个机器都只能运行一份。
Job/CronJob：定时任务部署，比如垃圾清理组件，可以在指定的时间运行，比如每晚两点清理垃圾。
image-20220722222909658
2. Service 网络
问题和需求：
我们创建启动了三个nginx副本，三个Pod，有各自的IP，当我们前端部署的时候，需要配置一个API的地址，只能配置一个IP地址，但是，如果我们配置的这个IP地址所在的Pod宕机了，我们是不是还要去修改这个API地址，很麻烦。
为此我们使用Serivce，它可以配置某次Deployment部署的一个总IP，对外暴露一个IP，将一组Pod公开。
图解：
image-20220723090843169
2.1 ClusterIP 模式
命令：
# 针对我们这个deploy，我们对外暴露8000端口，对应源Pod的80端口
[root@cluster-master ~]# kubectl expose deploy my-dep01 --port=8000 --target-port=80
service/my-dep01 exposed
[root@cluster-master ~]# kubectl get service
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
kubernetes ClusterIP 10.96.0.1 <none> 443/TCP 4d14h
my-dep01 ClusterIP 10.96.32.173 <none> 8000/TCP 8s # 暴露的8000端口
[root@cluster-master ~]# curl 10.96.32.173:8000
# 这样子，访问到这个IP，Service会自动分配到这三个Pod，自动实现负载均衡。
# 这个IP集群内部可以任意使用
1
2
3
4
5
6
7
8
9
10
11
12
13
yaml方式：
# 我们查看一下创建这个service的yaml文件
[root@cluster-master ~]# kubectl edit service my-dep01
# Please edit the object below. Lines beginning with a '#' will be ignored,
# and an empty file will abort the edit. If an error occurs while saving this file will be
# reopened with the relevant failures.
#
apiVersion: v1
kind: Service # 类型是service
metadata:
creationTimestamp: "2022-07-23T09:23:55Z"
labels:
app: my-dep01
name: my-dep01 # 这个service的名字
namespace: default
resourceVersion: "77046"
uid: 0dc7adf5-ebd2-4355-8fb1-cb04f5e00605
spec:
clusterIP: 10.96.32.173 # 这个service暴露的统一Pod的IP
clusterIPs:
- 10.96.32.173
ports:
- port: 8000 # 对外暴露的端口
protocol: TCP
targetPort: 80 # 源Pod的端口
selector:
app: my-dep01 # 对应的是我们选择的哪一个deploy ，这很重要，我们每次通过deployment创建一个Pod都会有个标签，记录是哪一个deployment创建的Pod
sessionAffinity: None
type: ClusterIP # 集群内部可访问
status:
loadBalancer: {}
# 针对上面的selector里的app是哪里来的，下面做了解释
[root@cluster-master ~]# kubectl get pod --show-labels
NAME READY STATUS RESTARTS AGE LABELS
my-dep01-75c8465dbd-4h75m 1/1 Running 0 25m app=my-dep01,pod-template-hash=75c8465dbd
my-dep01-75c8465dbd-b58zm 1/1 Running 0 24m app=my-dep01,pod-template-hash=75c8465dbd
my-dep01-75c8465dbd-jpksr 1/1 Running 0 25m app=my-dep01,pod-template-hash=75c8465dbd
my-dep01-75c8465dbd-rnk2k 1/1 Running 0 24m app=my-dep01,pod-template-hash=75c8465dbd
# 除了IP访问的方式，我们还可以通过域名来访问（服务名.命名空间.svc）
root@my-tomcat-5987455b6b-8q4kx:/usr/local/tomcat# curl my-dep01.default.svc:8000
<head>
<title>Welcome to nginx!</title>
</head>
<h1>Welcome to nginx!</h1>
-------- 略 -----------
# 注意：这个方式只能在其他的Pod里面进行访问，而不能在宿主机节点访问。（--type=CLusterIp）
# 回顾：我们之前在基础部分创建dashboard的时候，就是把type: ClusterIP 改为 type: NodePort，之后就可以在公网下访问了
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
2.2 NodePort 模式
默认的暴露service方式是ClusterIP，只有集群内部可以访问。
我们使用NodePort方式，可以让集群外部也可以访问。
# 在暴露的时候使用这种方式
kubectl expose deploy my-dep01 --port=8000 --target-port=80 --type=NodePort
# 或者把之前的ClusterIP换成NodePort
[root@cluster-master ~]# kubectl get svc
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
kubernetes ClusterIP 10.96.0.1 <none> 443/TCP 4d14h
my-dep01 ClusterIP 10.96.32.173 <none> 8000/TCP 35m
[root@cluster-master ~]# kubectl edit svc my-dep01
service/my-dep01 edited
[root@cluster-master ~]# kubectl get svc
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
kubernetes ClusterIP 10.96.0.1 <none> 443/TCP 4d14h
my-dep01 NodePort 10.96.32.173 <none> 8000:32135/TCP 36m
# 可以看到，不仅有一个8000端口，是我们自己写的，还有一个32135端口，这个是K8S给我们配置的，每一个Pod都一样，随机生成的这个范围是 30000-32767
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
测试访问：
# 测试ClusterIP（集群内部访问）
[root@cluster-master ~]# curl 10.96.32.173:8000
<h1>Welcome to nginx!</h1>
<p>If you see this page, the nginx web server is successfully installed and
# 测试公网IP访问（集群外部访问）
C:\Users\whirl\Desktop>curl 192.76.116.202:32135
<h1>Welcome to nginx!</h1>
<p>If you see this page, the nginx web server is successfully installed and
1
2
3
4
5
6
7
8
9
10
11
PS：
我们注意到这些用于集群内部访问的IP都是10.96.0.0/16的，这是我们之前在初始化主节点的时候配置的**–service-cidr**=10.96.0.0/16 \
同时，这些Pod的网络都是192.168.0.0/16 这也是初始化主节点的时候配置的**–pod-network-cidr**=192.168.0.0/16
3. Ingress 网关
Ingress是Service的统一网关入口，Service是Pod的统一入口。
通常，会有很多个服务，service A、 service B、service C，他们都在同一层，用的IP就是10.96.0.0/16下面的子网，K8S统一管理，由ingress来决定不同的访问路径调用不同的服务，底层是一个nginx。
3.1 安装
wget https://raw.githubusercontent.com/kubernetes/ingress-nginx/controller-v0.47.0/deploy/static/provider/baremetal/deploy.yaml
# 修改镜像
vi deploy.yaml
# 将image的值改为如下值：（这是尚硅谷雷丰阳老师阿里云仓库里的ingress地址）
registry.cn-hangzhou.aliyuncs.com/lfy_k8s_images/ingress-nginx-controller:v0.46.0
[root@cluster-master ~]# kubectl apply -f deploy.yaml
namespace/ingress-nginx created
serviceaccount/ingress-nginx created
configmap/ingress-nginx-controller created
clusterrole.rbac.authorization.k8s.io/ingress-nginx created
clusterrolebinding.rbac.authorization.k8s.io/ingress-nginx created
role.rbac.authorization.k8s.io/ingress-nginx created
rolebinding.rbac.authorization.k8s.io/ingress-nginx created
service/ingress-nginx-controller-admission created
service/ingress-nginx-controller created
deployment.apps/ingress-nginx-controller created
validatingwebhookconfiguration.admissionregistration.k8s.io/ingress-nginx-admission created
serviceaccount/ingress-nginx-admission created
clusterrole.rbac.authorization.k8s.io/ingress-nginx-admission created
clusterrolebinding.rbac.authorization.k8s.io/ingress-nginx-admission created
role.rbac.authorization.k8s.io/ingress-nginx-admission created
rolebinding.rbac.authorization.k8s.io/ingress-nginx-admission created
job.batch/ingress-nginx-admission-create created
job.batch/ingress-nginx-admission-patch created
# 检查安装的结果
[root@cluster-master ~]# kubectl get pod,svc -n ingress-nginx
NAME READY STATUS RESTARTS AGE
pod/ingress-nginx-admission-create-b96tw 0/1 ContainerCreating 0 15s
pod/ingress-nginx-admission-patch-9725j 0/1 CrashLoopBackOff 1 15s
pod/ingress-nginx-controller-65bf56f7fc-ggndz 0/1 ContainerCreating 0 15s
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
service/ingress-nginx-controller NodePort 10.96.39.227 <none> 80:30278/TCP,443:32006/TCP 15s
service/ingress-nginx-controller-admission ClusterIP 10.96.62.203 <none> 443/TCP 15s
# 最后别忘记把svc暴露的端口要放行
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
测试集群外部访问 Success：
image-20220723111640774
问题：yaml文件下不下来？
解决：
# 排查一下创建过程发生了什么
[root@cluster-master ~]# kubectl get pod -n ingress-nginx
NAME READY STATUS RESTARTS AGE
ingress-nginx-admission-create-b96tw 0/1 Completed 0 8m50s
ingress-nginx-admission-patch-9725j 0/1 Completed 2 8m50s
ingress-nginx-controller-65bf56f7fc-ggndz 1/1 Running 0 8m50s
# 查看Event事件
kubectl describe pod ingress-nginx-controller-65bf56f7fc-ggndz -n ingress-nginx
# 如果那个镜像说pull 失败了，就自己去docker pull
1
2
3
4
5
6
7
8
9
10
自己也可以去更改镜像源，因为官方没有上传到Docker-hub，注意版本的对应关系
解决国内k8s的ingress-nginx镜像无法正常pull拉取问题_文杰@的博客-CSDN博客
image-20220723111427419
3.2 实战
3.2.1 apply一个yaml文件
（学习一下Deployment配置的格式）
apiVersion: apps/v1
kind: Deployment # 来一个deployment
metadata:
name: hello-server
spec:
replicas: 2 # 两个副本
selector:
matchLabels:
app: hello-server
template:
metadata:
labels:
app: hello-server
spec:
containers:
- name: hello-server
image: registry.cn-hangzhou.aliyuncs.com/lfy_k8s_images/hello-server
ports:
- containerPort: 9000
---
apiVersion: apps/v1
kind: Deployment # 来一个deployment
metadata:
labels:
app: nginx-demo
name: nginx-demo
spec:
replicas: 2 # 两个副本
selector:
matchLabels:
app: nginx-demo
template:
metadata:
labels:
app: nginx-demo
spec:
containers:
- image: nginx
name: nginx
---
apiVersion: v1
kind: Service # 来一个service服务
metadata:
labels:
app: nginx-demo
name: nginx-demo # 服务的名字
spec:
selector:
app: nginx-demo
ports:
- port: 8000
protocol: TCP
targetPort: 80
---
apiVersion: v1
kind: Service # 配置服务
metadata:
labels:
app: hello-server
name: hello-server # 服务的名字
spec:
selector:
app: hello-server
ports:
- port: 8000
protocol: TCP
targetPort: 9000
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
3.2.2 解析yaml为架构图
image-20220723112811040
展示刚才的部署效果：
image-20220723113414871
3.2.3 域名访问
apiVersion: networking.k8s.io/v1
kind: Ingress # 配置了一个转发的类型
metadata:
name: ingress-host-bar # 不重名即可
spec:
ingressClassName: nginx
rules:
- host: "hello.xw.com" # 多个rule多个这样的 - host
http:
paths:
- pathType: Prefix
path: "/"
backend:
service:
name: hello-server # 指定给哪个service来完成
port:
number: 8000
- host: "demo.xw.com"
http:
paths:
- pathType: Prefix
path: "/nginx" # 把请求会转给下面的服务，下面的服务一定要能够处理这个路径，不然就是404
backend:
service:
name: nginx-demo # 指定给哪个service来完成
port:
number: 8000
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
需要进入任意一个nginx的Pod里面，然后写入文件，命名就是nginx（上面path里面的目录名称），不然就是404
image-20220723115355154
测试访问：
# 查看端口
[root@cluster-master ~]# kubectl get svc -n ingress-nginx
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
ingress-nginx-controller NodePort 10.96.39.227 <none> 80:30278/TCP,443:32006/TCP 42m
ingress-nginx-controller-admission ClusterIP 10.96.62.203 <none> 443/TCP 42m
# 配置的是30278端口
# 接着我们在我们的Windows配置hosts映射
192.76.116.201 hello.xw.com demo.xw.com
1
2
3
4
5
6
7
8
9
10
image-20220723115738647
以下两个是ingress官网给的高级功能，加注解Annotations。
3.3 Ingress的高级功能
3.3.1 路径重写
刚才的配置demo.xw.com修改一下
主要是在metadata里面加了一个annotations，然后在path进行了修改
apiVersion: networking.k8s.io/v1
kind: Ingress # 配置了一个转发的类型
metadata:
name: ingress-host-bar # 不重名即可
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
annotations: # 高级部分，加注解
nginx.ingress.kubernetes.io/rewrite-target: /$2 # 你要重写的部分
name: ingress-host-bar
spec:
ingressClassName: nginx
rules:
- host: "hello.xw.com"
http:
paths:
- pathType: Prefix
path: "/"
backend:
service:
name: hello-server
port:
number: 8000
- host: "demo.xw.com"
http:
paths:
- pathType: Prefix
path: "/nginx(/|$)(.*)" # 把请求会转给下面的服务，下面的服务一定要能处理这个路径，不能处理就是404
backend:
service:
name: nginx-demo # java，比如使用路径重写，去掉前缀nginx
port:
number: 8000
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
进入任意一个nginx容器，输入nginx文件echo xiaowei > nginx
虽然输入的是/nginx，但是ingress自动给我们截掉了，就是相当于/了，这样转发到其他的Pod的时候，就是直接访问它们的根路径了。就会显示这个起始欢迎页面。
image-20220723131634265
3.3.2 流量限制
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: ingress-limit-rate # 这个ingress的名称
annotations:
nginx.ingress.kubernetes.io/limit-rps: "1" # 限制访问频率
spec:
ingressClassName: nginx
rules:
- host: "hh.xw.com" # 这里新的host，记得需要在Windows的hosts里面加一个哈
http:
paths:
- pathType: Exact #精确匹配，只有haha.xw.com的才会被限制，haha.xw.com:30278/sad都不会被限制
path: "/"
backend:
service:
name: nginx-demo
port:
number: 8000
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
如果浏览器访问频率过快：
image-20220723133216953
4. 存储抽象
之前，我们在Docker里面，文件挂载到宿主机上，但在K8S里面的话，挂载是挂载到当前的node里面，然后如果这个node节点宕机，那么由于K8S的故障转移能力，会自动的在其他node节点创建一个Pod，这个时候，会新起一个挂载的目录，这个目录是不包含之前宕掉的节点的目录里面的数据的。
所以有了新的方法，存储系统，可以选择很多种方式来存储，K8S是开放的，我们这里使用**NFS（网络文件系统）**来完成这个存储的任务，也可以选择其他的方式。
4.1 环境准备
大致步骤：安装工具，配置目录，主节点是服务节点，其他节点去同步这个主节点的数据
# 在所有节点安装
yum install -y nfs-utils
# 在主节点暴露一个nfs的目录
mkdir -p /nfs/data
# *表示目录下的所有文件，然后括号里的是可以让同步的目录也可以执行rw的操作
echo "/nfs/data/ *(insecure,rw,sync,no_root_squash)" > /etc/exports
systemctl enable rpcbind --now
systemctl enable nfs-server --now
# 使配置生效
exportfs -r
# 在从节点展示目标IP下可供同步的目录
[root@cluster-node1 ~]# showmount -e 192.76.116.201
Export list for 192.76.116.201:
/nfs/data *
# 同样的，创建目录，然后将服务器上的目录共享到本机
mkdir -p /nfs/data
mount -t nfs 192.76.116.201:/nfs/data /nfs/data
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
测试环境 Success：
# 在主节点
echo "hello nfs server" > /nfs/data/test.txt
# 在从节点查看
[root@cluster-node1 ~]# cd /nfs/data/
[root@cluster-node1 data]# ls
test.txt
[root@cluster-node1 data]# cat test.txt
hello nfs server
1
2
3
4
5
6
7
8
9
原生方式挂载：
apiVersion: apps/v1
kind: Deployment
metadata:
labels:
app: nginx-pv-demo
name: nginx-pv-demo
spec:
replicas: 2
selector:
matchLabels:
app: nginx-pv-demo
template:
metadata:
labels:
app: nginx-pv-demo
spec:
containers:
- image: nginx
name: nginx
volumeMounts:
- name: html
mountPath: /usr/share/nginx/html
volumes:
- name: html
nfs:
server: 192.76.116.201
path: /nfs/data/nginx-pv
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
测试访问 Success：
image-20220723144519842
PS：存在一个问题：
如果我们把这次部署deploy删掉了，但是数据挂载的目录并不会被删除，时间长了之后，会有很多的垃圾文件。怎么办呢？为此我们引入PV和PVC
4.2 PV 和 PVC
PV：Persistent Vloume 持久卷，将应用需要持久化的数据保存到指定位置
PVC：Persistent Volume Claim 持久卷声明，声明需要使用的持久卷规格
4.2.1 创建 PV 池
我们这里使用的是静态供应，后面还要学习动态供应。
# 先在主节点的/nfs/data下创建三个目录备用
mkdir 01 02 03
1
2
创建我们需要的 PV：
apiVersion: v1
kind: PersistentVolume # 创建持久卷
metadata:
name: pv01-10m
spec:
capacity:
storage: 10m # 静态创建10M的空间
accessModes:
- ReadWriteMany
storageClassName: nfs
nfs:
path: /nfs/data/01 # 挂载的目录
server: 192.76.116.201
---
apiVersion: v1
kind: PersistentVolume
metadata:
name: pv02-1gi
spec:
capacity:
storage: 1g # g要小写
accessModes:
- ReadWriteMany
storageClassName: nfs
nfs:
path: /nfs/data/02
server: 192.76.116.201
---
apiVersion: v1
kind: PersistentVolume
metadata:
name: pv03-3gi
spec:
capacity:
storage: 3g
accessModes:
- ReadWriteMany
storageClassName: nfs
nfs:
path: /nfs/data/03
server: 192.76.116.201
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
创建成功：
[root@cluster-master ~]# kubectl apply -f deploy-pv.yaml
persistentvolume/pv01-10m unchanged
persistentvolume/pv02-1gi created
persistentvolume/pv03-3gi created
[root@cluster-master ~]# kubectl get pv
NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE
pv01-10m 10m RWX Retain Available nfs 5m10s
pv02-1gi 8M RWX Retain Available nfs 54s
pv03-3gi 5M RWX Retain Available nfs 54s
# 可以看到目前都是“可用”的状态
# 注意在你申请的时候，首先要确保你当前的节点的空间足够，我虚拟机报错空间不足了，