1. 基本存储
1.1 EmptyDir
EmptyDir是最基础的Volume类型，一个EmptyDir就是Host上的一个空目录。
EmptyDir是在Pod被分配到Node时创建的，它的初始内容为空，并且无须指定宿主机上对应的目录文件，因为kubernetes会自动分配一个目录，当Pod销毁时， EmptyDir中的数据也会被永久删除。 EmptyDir用途如下：
临时空间，例如用于某些应用程序运行时所需的临时目录，且无须永久保留
一个容器需要从另一个容器中获取数据的目录（多容器共享目录）
接下来，通过一个容器之间文件共享的案例来使用一下EmptyDir。
在一个Pod中准备两个容器nginx和busybox，然后声明一个Volume分别挂在到两个容器的目录中，然后nginx容器负责向Volume中写日志，busybox中通过命令将日志内容读到控制台。
创建一个volume-emptydir.yaml：
apiVersion: v1
kind: Pod
metadata:
name: volume-emptydir
namespace: dev
spec:
containers:
- name: nginx
image: nginx:1.14-alpine
ports:
- containerPort: 80
volumeMounts: # 将logs-volume挂在到nginx容器中，对应的目录为 /var/log/nginx
- name: logs-volume
mountPath: /var/log/nginx
- name: busybox
image: busybox:1.30
command: ["/bin/sh","-c","tail -f /logs/access.log"] # 初始命令，动态读取指定文件中内容
volumeMounts: # 将logs-volume 挂在到busybox容器中，对应的目录为 /logs
- name: logs-volume
mountPath: /logs
volumes: # 声明volume， name为logs-volume，类型为emptyDir
- name: logs-volume
emptyDir: {}# 创建Pod
[root@master ~]# kubectl create -f volume-emptydir.yaml
pod/volume-emptydir created
# 查看pod
[root@master ~]# kubectl get pods volume-emptydir -n dev -o wide
NAME READY STATUS RESTARTS AGE IP NODE ......
volume-emptydir 2/2 Running 0 97s 10.244.1.100 node1 ......
# 通过podIp访问nginx
[root@master ~]# curl 10.244.1.100
......
# 通过kubectl logs命令查看指定容器的标准输出
[root@master ~]# kubectl logs -f volume-emptydir -n dev -c busybox
10.244.0.0 - - [13/Apr/2020:10:58:47 +0000] "GET / HTTP/1.1" 200 612 "-" "curl/7.29.0" "-"1.2 HostPath
上节课提到，EmptyDir中数据不会被持久化，它会随着Pod的结束而销毁，如果想简单的将数据持久化到主机中，可以选择HostPath。
HostPath就是将Node主机中一个实际目录挂在到Pod中，以供容器使用，这样的设计就可以保证Pod销毁了，但是数据依据可以存在于Node主机上。
创建一个volume-hostpath.yaml：
apiVersion: v1
kind: Pod
metadata:
name: volume-hostpath
namespace: dev
spec:
containers:
- name: nginx
image: nginx:1.17.1
ports:
- containerPort: 80
volumeMounts:
- name: logs-volume
mountPath: /var/log/nginx
- name: busybox
image: busybox:1.30
command: ["/bin/sh","-c","tail -f /logs/access.log"]
volumeMounts:
- name: logs-volume
mountPath: /logs
volumes:
- name: logs-volume
hostPath:
path: /root/logs
type: DirectoryOrCreate # 目录存在就使用，不存在就先创建后使用关于type的值的一点说明：
DirectoryOrCreate 目录存在就使用，不存在就先创建后使用
Directory 目录必须存在
FileOrCreate 文件存在就使用，不存在就先创建后使用
File 文件必须存在
Socket unix套接字必须存在
CharDevice 字符设备必须存在
BlockDevice 块设备必须存在
# 创建Pod
[root@master ~]# kubectl create -f volume-hostpath.yaml
pod/volume-hostpath created
# 查看Pod
[root@master ~]# kubectl get pods volume-hostpath -n dev -o wide
NAME READY STATUS RESTARTS AGE IP NODE ......
pod-volume-hostpath 2/2 Running 0 16s 10.244.1.104 node1 ......
#访问nginx
[root@master ~]# curl 10.244.1.104
# 接下来就可以去host的/root/logs目录下查看存储的文件了
### 注意: 下面的操作需要到Pod所在的节点运行（案例中是node1）
[root@node1 ~]# ls /root/logs/
access.log error.log
# 同样的道理，如果在此目录下创建一个文件，到容器中也是可以看到的1.3 NFS
HostPath可以解决数据持久化的问题，但是一旦Node节点故障了，Pod如果转移到了别的节点，又会出现问题了，此时需要准备单独的网络存储系统，比较常用的用NFS、CIFS。
NFS是一个网络文件存储系统，可以搭建一台NFS服务器，然后将Pod中的存储直接连接到NFS系统上，这样的话，无论Pod在节点上怎么转移，只要Node跟NFS的对接没问题，数据就可以成功访问。
1）首先要准备nfs的服务器，这里为了简单，直接是master节点做nfs服务器
# 在master上安装nfs服务
[root@master ~]# yum install nfs-utils -y
# 准备一个共享目录
[root@master ~]# mkdir /root/data/nfs -pv
# 将共享目录以读写权限暴露给192.168.109.0/24网段中的所有主机
[root@master ~]# vim /etc/exports
[root@master ~]# more /etc/exports
/root/data/nfs 172.16.90.0/24(rw,no_root_squash)
# 启动nfs服务
[root@master ~]# systemctl start nfs2）接下来，要在的每个node节点上都安装下nfs，这样的目的是为了node节点可以驱动nfs设备
# 在node上安装nfs服务，注意不需要启动
[root@master ~]# yum install nfs-utils -y3）接下来，就可以编写pod的配置文件了，创建volume-nfs.yaml
apiVersion: v1
kind: Pod
metadata:
name: volume-nfs
namespace: dev
spec:
containers:
- name: nginx
image: nginx:1.17.1
ports:
- containerPort: 80
volumeMounts:
- name: logs-volume
mountPath: /var/log/nginx
- name: busybox
image: busybox:1.30
command: ["/bin/sh","-c","tail -f /logs/access.log"]
volumeMounts:
- name: logs-volume
mountPath: /logs
volumes:
- name: logs-volume
nfs:
server: master #nfs服务器地址
path: /root/data/nfs #共享文件路径4）最后，运行下pod，观察结果
# 创建pod
[root@master ~]# kubectl create -f volume-nfs.yaml
pod/volume-nfs created
# 查看pod
[root@master ~]# kubectl get pods volume-nfs -n dev
NAME READY STATUS RESTARTS AGE
volume-nfs 2/2 Running 0 2m9s
# 查看nfs服务器上的共享目录，发现已经有文件了
[root@master ~]# ls /root/data/
access.log error.log2. 高级存储
2.1 PV和PVC
前面已经学习了使用NFS提供存储，此时就要求用户会搭建NFS系统，并且会在yaml配置nfs。由于kubernetes支持的存储系统有很多，要求客户全都掌握，显然不现实。为了能够屏蔽底层存储实现的细节，方便用户使用， kubernetes引入PV和PVC两种资源对象。
PV（Persistent Volume）是持久化卷的意思，是对底层的共享存储的一种抽象。一般情况下PV由kubernetes管理员进行创建和配置，它与底层具体的共享存储技术有关，并通过插件完成与共享存储的对接。
PVC（Persistent Volume Claim）是持久卷声明的意思，是用户对于存储需求的一种声明。换句话说，PVC其实就是用户向kubernetes系统发出的一种资源需求申请。
使用了PV和PVC之后，工作可以得到进一步的细分：
存储：存储工程师维护
PV： kubernetes管理员维护
PVC：kubernetes用户维护
2.2 PV
PV是存储资源的抽象，下面是资源清单文件:
apiVersion: v1
kind: PersistentVolume
metadata:
name: pv2
spec:
nfs: # 存储类型，与底层真正存储对应
capacity: # 存储能力，目前只支持存储空间的设置
storage: 2Gi
accessModes: # 访问模式
storageClassName: # 存储类别
persistentVolumeReclaimPolicy: # 回收策略PV 的关键配置参数说明：
-
存储类型
底层实际存储的类型，kubernetes支持多种存储类型，每种存储类型的配置都有所差异
-
存储能力（capacity）
目前只支持存储空间的设置( storage=1Gi )，不过未来可能会加入IOPS、吞吐量等指标的配置
-
访问模式（accessModes）
用于描述用户应用对存储资源的访问权限，访问权限包括下面几种方式：
-
ReadWriteOnce（RWO）：读写权限，但是只能被单个节点挂载
-
ReadOnlyMany（ROX）： 只读权限，可以被多个节点挂载
-
ReadWriteMany（RWX）：读写权限，可以被多个节点挂载
需要注意的是，底层不同的存储类型可能支持的访问模式不同 -
-
回收策略（persistentVolumeReclaimPolicy）
当PV不再被使用了之后，对其的处理方式。目前支持三种策略：
-
Retain （保留） 保留数据，需要管理员手工清理数据
-
Recycle（回收） 清除 PV 中的数据，效果相当于执行 rm -rf /thevolume/*
-
Delete （删除） 与 PV 相连的后端存储完成 volume 的删除操作，当然这常见于云服务商的存储服务
需要注意的是，底层不同的存储类型可能支持的回收策略不同 -
-
存储类别
PV可以通过storageClassName参数指定一个存储类别
-
具有特定类别的PV只能与请求了该类别的PVC进行绑定
-
未设定类别的PV则只能与不请求任何类别的PVC进行绑定
-
-
状态（status）
一个 PV 的生命周期中，可能会处于4中不同的阶段：
-
Available（可用）： 表示可用状态，还未被任何 PVC 绑定
-
Bound（已绑定）： 表示 PV 已经被 PVC 绑定
-
Released（已释放）： 表示 PVC 被删除，但是资源还未被集群重新声明
-
Failed（失败）： 表示该 PV 的自动回收失败
-
实验
使用NFS作为存储，来演示PV的使用，创建3个PV，对应NFS中的3个暴露的路径。
1. 创建NFS环境
# 创建目录
[root@master ~]# mkdir /root/data/{pv1,pv2,pv3} -pv
# 暴露服务
[root@master ~]# more /etc/exports
/root/data/pv1 172.16.90.0/24(rw,no_root_squash)
/root/data/pv2 172.16.90.0/24(rw,no_root_squash)
/root/data/pv3 172.16.90.0/24(rw,no_root_squash)
# 重启服务
[root@master ~]# systemctl restart nfs2. 创建pv.yaml
# 创建目录
[root@master ~]# mkdir /root/data/{pv1,pv2,pv3} -pv
# 暴露服务
[root@master ~]# more /etc/exports
/root/data/pv1 172.16.90.0/24(rw,no_root_squash)
/root/data/pv2 172.16.90.0/24(rw,no_root_squash)
/root/data/pv3 172.16.90.0/24(rw,no_root_squash)
# 重启服务
[root@master ~]# systemctl restart nfs# 创建 pv
[root@master ~]# kubectl create -f pv.yaml
persistentvolume/pv1 created
persistentvolume/pv2 created
persistentvolume/pv3 created
# 查看pv
[root@master ~]# kubectl get pv -o wide
NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS AGE VOLUMEMODE
pv1 1Gi RWX Retain Available 10s Filesystem
pv2 2Gi RWX Retain Available 10s Filesystem
pv3 3Gi RWX Retain Available 9s Filesystem2.3 PVC
PVC是资源的申请，用来声明对存储空间、访问模式、存储类别需求信息。下面是资源清单文件:
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: pvc
namespace: dev
spec:
accessModes: # 访问模式
selector: # 采用标签对PV选择
storageClassName: # 存储类别
resources: # 请求空间
requests:
storage: 5GiPVC 的关键配置参数说明：
访问模式（accessModes）
用于描述用户应用对存储资源的访问权限
选择条件（selector）
通过Label Selector的设置，可使PVC对于系统中己存在的PV进行筛选
存储类别（storageClassName）
PVC在定义时可以设定需要的后端存储的类别，只有设置了该class的pv才能被系统选出
资源请求（Resources ）
描述对存储资源的请求
实验
1. 创建pvc.yaml, 申请pv
PVC 的关键配置参数说明：
- **访问模式（accessModes）**
用于描述用户应用对存储资源的访问权限
- **选择条件（selector）**
通过Label Selector的设置，可使PVC对于系统中己存在的PV进行筛选
- **存储类别（storageClassName）**
PVC在定义时可以设定需要的后端存储的类别，只有设置了该class的pv才能被系统选出
- **资源请求（Resources ）**
描述对存储资源的请求
**实验**
1) 创建pvc.yaml，申请pv# 创建pvc
[root@master ~]# kubectl create -f pvc.yaml
persistentvolumeclaim/pvc1 created
persistentvolumeclaim/pvc2 created
persistentvolumeclaim/pvc3 created
# 查看pvc
[root@master ~]# kubectl get pvc -n dev -o wide
NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE VOLUMEMODE
pvc1 Bound pv1 1Gi RWX 15s Filesystem
pvc2 Bound pv2 2Gi RWX 15s Filesystem
pvc3 Bound pv3 3Gi RWX 15s Filesystem
# 查看pv
[root@master ~]# kubectl get pv -o wide
NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM AGE VOLUMEMODE
pv1 1Gi RWx Retain Bound dev/pvc1 3h37m Filesystem
pv2 2Gi RWX Retain Bound dev/pvc2 3h37m Filesystem
pv3 3Gi RWX Retain Bound dev/pvc3 3h37m Filesystem 2. 创建pods.yaml,使用pv
apiVersion: v1
kind: Pod
metadata:
name: pod1
namespace: dev
spec:
containers:
- name: busybox
image: busybox:1.30
command: ["/bin/sh","-c","while true;do echo pod1 >> /root/out.txt; sleep 10; done;"]
volumeMounts:
- name: volume
mountPath: /root/
volumes:
- name: volume
persistentVolumeClaim:
claimName: pvc1
readOnly: false
---
apiVersion: v1
kind: Pod
metadata:
name: pod2
namespace: dev
spec:
containers:
- name: busybox
image: busybox:1.30
command: ["/bin/sh","-c","while true;do echo pod2 >> /root/out.txt; sleep 10; done;"]
volumeMounts:
- name: volume
mountPath: /root/
volumes:
- name: volume
persistentVolumeClaim:
claimName: pvc2
readOnly: false # 创建pod
[root@master ~]# kubectl create -f pods.yaml
pod/pod1 created
pod/pod2 created
# 查看pod
[root@master ~]# kubectl get pods -n dev -o wide
NAME READY STATUS RESTARTS AGE IP NODE
pod1 1/1 Running 0 14s 10.244.1.69 node1
pod2 1/1 Running 0 14s 10.244.1.70 node1
# 查看pvc
[root@master ~]# kubectl get pvc -n dev -o wide
NAME STATUS VOLUME CAPACITY ACCESS MODES AGE VOLUMEMODE
pvc1 Bound pv1 1Gi RWX 94m Filesystem
pvc2 Bound pv2 2Gi RWX 94m Filesystem
pvc3 Bound pv3 3Gi RWX 94m Filesystem
# 查看pv
[root@master ~]# kubectl get pv -n dev -o wide
NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM AGE VOLUMEMODE
pv1 1Gi RWX Retain Bound dev/pvc1 5h11m Filesystem
pv2 2Gi RWX Retain Bound dev/pvc2 5h11m Filesystem
pv3 3Gi RWX Retain Bound dev/pvc3 5h11m Filesystem
# 查看nfs中的文件存储
[root@master ~]# more /root/data/pv1/out.txt
node1
node1
[root@master ~]# more /root/data/pv2/out.txt
node2
node22.4 生命周期
PVC和PV是一一对应的，PV和PVC之间的相互作用遵循以下生命周期：
资源供应：管理员手动创建底层存储和PV
资源绑定：用户创建PVC，kubernetes负责根据PVC的声明去寻找PV，并绑定
在用户定义好PVC之后，系统将根据PVC对存储资源的请求在已存在的PV中选择一个满足条件的
一旦找到，就将该PV与用户定义的PVC进行绑定，用户的应用就可以使用这个PVC了
如果找不到，PVC则会无限期处于Pending状态，直到等到系统管理员创建了一个符合其要求的PV
PV一旦绑定到某个PVC上，就会被这个PVC独占，不能再与其他PVC进行绑定了
资源使用：用户可在pod中像volume一样使用pvc
Pod使用Volume的定义，将PVC挂载到容器内的某个路径进行使用。
资源释放：用户删除pvc来释放pv
当存储资源使用完毕后，用户可以删除PVC，与该PVC绑定的PV将会被标记为“已释放”，但还不能立刻与其他PVC进行绑定。通过之前PVC写入的数据可能还被留在存储设备上，只有在清除之后该PV才能再次使用。
资源回收：kubernetes根据pv设置的回收策略进行资源的回收
对于PV，管理员可以设定回收策略，用于设置与之绑定的PVC释放资源之后如何处理遗留数据的问题。只有PV的存储空间完成回收，才能供新的PVC绑定和使用
3. StorageClass
在一个大规模的Kubernetes集群里,可能有成千上万个PVC,这就意味着运维人员必须实现创建出这个多个PV,此外,随着项目的需要,会有新的PVC不断被提交,那么运维人员就需要不断的添加新的,满足要求的PV,否则新的Pod就会因为PVC绑定不到PV而导致创建失败。而且通过 PVC 请求到一定的存储空间也很有可能不足以满足应用对于存储设备的各种需求，而且不同的应用程序对于存储性能的要求可能也不尽相同，比如读写速度、并发性能等，为了解决这一问题，Kubernetes 又为我们引入了一个新的资源对象：StorageClass，通过 StorageClass 的定义，管理员可以将存储资源定义为某种类型的资源，比如快速存储、慢速存储等，kubernetes根据 StorageClass 的描述就可以非常直观的知道各种存储资源的具体特性了，这样就可以根据应用的特性去申请合适的存储资源了。
3.1 什么是StorageClass
Kubernetes提供了一套可以自动创建PV的机制,即:Dynamic Provisioning.而这个机制的核心在于:StorageClass这个API对象.
StorageClass对象会定义下面两部分内容:
1,PV的属性.比如,存储类型,Volume的大小等.
2,创建这种PV需要用到的存储插件
有了这两个信息之后,Kubernetes就能够根据用户提交的PVC,找到一个对应的StorageClass,之后Kubernetes就会调用该StorageClass声明的存储插件,进而创建出需要的PV.
但是其实使用起来是一件很简单的事情,你只需要根据自己的需求,编写YAML文件即可,然后使用kubectl create命令执行即可
3.2 为什么需要StorageClass
在一个大规模的Kubernetes集群里,可能有成千上万个PVC,这就意味着运维人员必须实现创建出这个多个PV,此外,随着项目的需要,会有新的PVC不断被提交,那么运维人员就需要不断的添加新的,满足要求的PV,否则新的Pod就会因为PVC绑定不到PV而导致创建失败.而且通过 PVC 请求到一定的存储空间也很有可能不足以满足应用对于存储设备的各种需求
而且不同的应用程序对于存储性能的要求可能也不尽相同，比如读写速度、并发性能等，为了解决这一问题，Kubernetes 又为我们引入了一个新的资源对象：StorageClass，通过 StorageClass 的定义，管理员可以将存储资源定义为某种类型的资源，比如快速存储、慢速存储等，用户根据 StorageClass 的描述就可以非常直观的知道各种存储资源的具体特性了，这样就可以根据应用的特性去申请合适的存储资源了。
3.3 StorageClass运行原理及部署流程
要使用 StorageClass，我们就得安装对应的自动配置程序，比如我们这里存储后端使用的是 nfs，那么我们就需要使用到一个 nfs-client 的自动配置程序，我们也叫它 Provisioner，这个程序使用我们已经配置好的 nfs 服务器，来自动创建持久卷，也就是自动帮我们创建 PV。
1.自动创建的 PV 以${namespace}-${pvcName}-${pvName}这样的命名格式创建在 NFS 服务器上的共享数据目录中
2.而当这个 PV 被回收后会以archieved-${namespace}-${pvcName}-${pvName}这样的命名格式存在 NFS 服务器上。（1）详细的运作流程参考下图：
（2）搭建StorageClass+NFS步骤
1.创建一个可用的NFS Serve
2.创建Service Account.这是用来管控NFS provisioner在k8s集群中运行的权限
3.创建StorageClass.负责建立PVC并调用NFS provisioner进行预定的工作,并让PV与PVC建立管理
4.创建NFS provisioner.有两个功能,一个是在NFS共享目录下创建挂载点(volume),另一个则是建了PV并将PV与NFS的挂载点建立关联
3.4 创建StorageClass
3.4.1 创建NFS共享服务
该步骤比较简单不在赘述,大家可以自行百度搭建，当前环境NFS server及共享目录信息
IP: 172.16.90.111
Export PATH: /nfs/kubernetes
# nfs-server设置开机自启3.4.2 使用以下文档配置account及相关权限
1）rbac.yaml: #唯一需要修改的地方只有namespace,根据实际情况定义
[root@master p9]# mkdir storageclass
[root@master p9]# cd storageclass
[root@master storageclass]# pwd
/p9/storageclass
[root@k8s-master storageclass]# cat rbac.yaml
apiVersion: v1
kind: ServiceAccount
metadata:
name: nfs-client-provisioner
namespace: default #根据实际环境设定namespace,下面类同
---
kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name: nfs-client-provisioner-runner
rules:
- 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
namespace: default
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
namespace: default
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
subjects:
- kind: ServiceAccount
name: nfs-client-provisioner
namespace: default
roleRef:
kind: Role
name: leader-locking-nfs-client-provisioner
apiGroup: rbac.authorization.k8s.io2）创建rbac
[root@master storageclass]# kubectl apply -f rbac.yaml
serviceaccount/nfs-client-provisioner created
clusterrole.rbac.authorization.k8s.io/nfs-client-provisioner-runner created
clusterrolebinding.rbac.authorization.k8s.io/run-nfs-client-provisioner created
role.rbac.authorization.k8s.io/leader-locking-nfs-client-provisioner created
rolebinding.rbac.authorization.k8s.io/leader-locking-nfs-client-provisioner created
[root@master storageclass]# kubectl get role,rolebinding
NAME CREATED AT
role.rbac.authorization.k8s.io/leader-locking-nfs-client-provisioner 2022-12-05T04:53:25Z
NAME ROLE AGE
rolebinding.rbac.authorization.k8s.io/leader-locking-nfs-client-provisioner Role/leader-locking-nfs-client-provisioner 58s3.4.3 创建NFS资源的StorageClass
1）nfs-StorageClass.yaml
[root@master storageclass]# cat nfs-StorageClass.yaml
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
name: managed-nfs-storage
provisioner: nfs-storage #这里的名称要和provisioner配置文件中的环境变量PROVISIONER_NAME保持一致
parameters:
archiveOnDelete: "false"2）创建nfs-StorageClass
[root@master storageclass]# kubectl apply -f nfs-StorageClass.yaml
storageclass.storage.k8s.io/managed-nfs-storage created
[root@master storageclass]# kubectl get sc
NAME PROVISIONER RECLAIMPOLICY VOLUMEBINDINGMODE ALLOWVOLUMEEXPANSION AGE
managed-nfs-storage nfs-storage Delete Immediate false 12s3.4.4 创建NFS provisioner
1）nfs-provisioner.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: nfs-client-provisioner
labels:
app: nfs-client-provisioner
namespace: default #与RBAC文件中的namespace保持一致
spec:
replicas: 1
selector:
matchLabels:
app: nfs-client-provisioner
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: registry.cn-beijing.aliyuncs.com/mydlq/nfs-subdir-external-provisioner:v4.0.0
volumeMounts:
- name: nfs-client-root
mountPath: /persistentvolumes
env:
- name: PROVISIONER_NAME
value: nfs-storage #provisioner名称,请确保该名称与 nfs-StorageClass.yaml文件中的provisioner名称保持一致
- name: NFS_SERVER
value: 172.16.90.111 #NFS Server IP地址
- name: NFS_PATH
value: /nfs/kubernetes #NFS挂载卷
volumes:
- name: nfs-client-root
nfs:
server: 172.16.90.111 #NFS Server IP地址
path: /nfs/kubernetes #NFS 挂载卷2）创建nfs-provisioner
[root@master storageclass]# kubectl apply -f nfs-provisioner.yaml
deployment.apps/nfs-client-provisioner created
[root@master storageclass]# kubectl get deploy
NAME READY UP-TO-DATE AVAILABLE AGE
nfs-client-provisioner 1/1 1 1 6m10s
[root@master storageclass]# kubectl get pod
NAME READY STATUS RESTARTS AGE
nfs-client-provisioner-69c9d4db97-snfb5 1/1 Running 0 6m14s4. 创建测试pod，检查是否部署成功
4.1 创建pod+PVC
1）test-claim.yaml
[root@master storageclass]# cat test-claim.yaml
kind: PersistentVolumeClaim
apiVersion: v1
metadata:
name: test-claim
annotations:
volume.beta.kubernetes.io/storage-class: "managed-nfs-storage" #与nfs-StorageClass.yaml metadata.name保持一致，关联storageclass进行后续动态撞见PV
spec:
accessModes:
- ReadWriteMany
resources:
requests:
storage: 1Mi
[root@master storageclass]# kubectl apply -f test-claim.yaml
persistentvolumeclaim/test-claim created2）确保PVC状态为Bound（默认自动创建PV且Bound状态）
[root@master storageclass]# kubectl get pvc
NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE
test-claim Bound pvc-67cd5863-6472-4368-a40f-ab78c80f03fc 1Mi RWX managed-nfs-storage 2m9s
[root@master storageclass]# kubectl get pv
NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE
pvc-67cd5863-6472-4368-a40f-ab78c80f03fc 1Mi RWX Delete Bound default/test-claim managed-nfs-storage 4m19s3）创建测试pod,查看是否可以正常挂载
test-pod.yaml
[root@master storageclass]# cat test-pod.yml
kind: Pod
apiVersion: v1
metadata:
name: test-pod
spec:
containers:
- name: test-pod
image: busybox:1.24
command:
- "/bin/sh"
args:
- "-c"
- "touch /mnt/SUCCESS && exit 0 || exit 1" #创建一个SUCCESS文件后退出
volumeMounts:
- name: nfs-pvc
mountPath: "/mnt"
restartPolicy: "Never"
volumes:
- name: nfs-pvc
persistentVolumeClaim:
claimName: test-claim #与PVC名称保持一致
[root@master storageclass]# kubectl apply -f test-pod.yml
pod/test-pod created#文件规则是按照${namespace}-${pvcName}-${pvName}创建的
[root@master storageclass]# ll /nfs/kubernetes/default-test-claim-pvc-67cd5863-6472-4368-a40f-ab78c80f03fc/
total 0
-rw-r--r-- 1 root root 0 Dec 5 15:51 SUCCESS4）检查结果
#文件规则是按照${namespace}-${pvcName}-${pvName}创建的
[root@master storageclass]# ll /nfs/kubernetes/default-test-claim-pvc-67cd5863-6472-4368-a40f-ab78c80f03fc/
total 0
-rw-r--r-- 1 root root 0 Dec 5 15:51 SUCCESS4.2 StateFulDet+volumeClaimTemplates自动创建PV
1）创建无头服务及statefulset
nginx-statefulset.yaml
[root@master storageclass]# cat nginx-statefulset.yaml
apiVersion: v1
kind: Service
metadata:
name: nginx-headless
labels:
app: nginx
spec:
ports:
- port: 80
name: web
clusterIP: None #注意此处的值,None表示无头服务
selector:
app: nginx
---
apiVersion: apps/v1
kind: StatefulSet
metadata:
name: web
spec:
selector:
matchLabels:
app: nginx
serviceName: "nginx-headless" #与service名称保持一致
replicas: 2 #两个副本
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:1.17.1
ports:
- containerPort: 80
name: web
volumeMounts:
- name: www
mountPath: /usr/share/nginx/html
volumeClaimTemplates:
- metadata:
name: www
annotations:
volume.beta.kubernetes.io/storage-class: "managed-nfs-storage" #managed-nfs-storage为我们创建的storage-class名称
spec:
accessModes: [ "ReadWriteOnce" ]
resources:
requests:
storage: 1Gi
[root@master storageclass]# kubectl apply -f nginx-statefulset.yaml 2）检查结果
集群节点上
[root@master storageclass]# kubectl get pod -l app=nginx
NAME READY STATUS RESTARTS AGE
web-0 1/1 Running 0 22s
web-1 1/1 Running 0 18s
[root@master storageclass]# kubectl get pvc
NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE
test-claim Bound pvc-67cd5863-6472-4368-a40f-ab78c80f03fc 1Mi RWX managed-nfs-storage 24m
www-web-0 Bound pvc-6026ba34-729c-44af-a5c0-57f1c9dc5df7 1Gi RWO managed-nfs-storage 36s
www-web-1 Bound pvc-845c4d72-1854-430d-bea7-aef417f30592 1Gi RWO managed-nfs-storage 32s
[root@master storageclass]# kubectl get pv
NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE
pvc-6026ba34-729c-44af-a5c0-57f1c9dc5df7 1Gi RWO Delete Bound default/www-web-0 managed-nfs-storage 50s
pvc-67cd5863-6472-4368-a40f-ab78c80f03fc 1Mi RWX Delete Bound default/test-claim managed-nfs-storage 25m
pvc-845c4d72-1854-430d-bea7-aef417f30592 1Gi RWO Delete Bound default/www-web-1 managed-nfs-storage 47s3）NFS Server上:
[root@master storageclass]# ll /nfs/kubernetes/
total 0
drwxrwxrwx 2 root root 21 Dec 5 15:51 default-test-claim-pvc-67cd5863-6472-4368-a40f-ab78c80f03fc
drwxrwxrwx 2 root root 6 Dec 5 16:08 default-www-web-0-pvc-6026ba34-729c-44af-a5c0-57f1c9dc5df7
drwxrwxrwx 2 root root 6 Dec 5 16:08 default-www-web-1-pvc-845c4d72-1854-430d-bea7-aef417f30592
[root@master storageclass]# echo "web-00" > /nfs/kubernetes/default-www-web-0-pvc-6026ba34-729c-44af-a5c0-57f1c9dc5df7/index.html[root@master storageclass]# echo "web-01" > /nfs/kubernetes/default-www-web-1-pvc-845c4d72-1854-430d-bea7-aef417f30592/index.html4）集群任意节点上:
[root@master storageclass]# kubectl get pod -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
nfs-client-provisioner-b65cf79b8-slcw6 1/1 Running 0 32m 10.224.166.151 node1 <none> <none>
test-pod 0/1 Completed 0 24m 10.224.104.37 node2 <none> <none>
web-0 1/1 Running 0 7m31s 10.224.104.38 node2 <none> <none>
web-1 1/1 Running 0 7m27s 10.224.166.152 node1 <none> <none>
[root@master storageclass]# curl 10.224.104.38
web-00
[root@master storageclass]# curl 10.224.166.152
web-01
[root@master storageclass]# kubectl get svc -o wide
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE SELECTOR
kubernetes ClusterIP 10.96.0.1 <none> 443/TCP 4d2h <none>
nginx-headless ClusterIP None <none> 80/TCP 19m app=nginx
[root@master storageclass]# kubectl exec -it web-0 -- /bin/bash
root@web-0:/# apt update
root@web-0:/# apt install dnsutils -y
root@web-0:/# nslookup nginx-headless
Server: 10.96.0.10
Address: 10.96.0.10#53
Name: nginx-headless.default.svc.cluster.local
Address: 10.224.166.152
Name: nginx-headless.default.svc.cluster.local
Address: 10.224.104.385. 配置存储
5.1 ConfigMap
ConfigMap是一种比较特殊的存储卷，它的主要作用是用来存储配置信息的。
创建configmap.yaml，内容如下：
apiVersion: v1
kind: ConfigMap
metadata:
name: configmap
namespace: dev
data:
info: |
username:admin
password:123456接下来，使用此配置文件创建configmap
# 创建configmap
[root@master ~]# kubectl create -f configmap.yaml
configmap/configmap created
# 查看configmap详情
[root@master ~]# kubectl describe cm configmap -n dev
Name: configmap
Namespace: dev
Labels: <none>
Annotations: <none>
Data
====
info:
----
username:admin
password:123456
Events: <none>接下来创建一个pod-configmap.yaml，将上面创建的configmap挂载进去
apiVersion: v1
kind: Pod
metadata:
name: pod-configmap
namespace: dev
spec:
containers:
- name: nginx
image: nginx:1.17.1
volumeMounts: # 将configmap挂载到目录
- name: config
mountPath: /configmap/config
volumes: # 引用configmap
- name: config
configMap:
name: configmap# 创建pod
[root@master ~]# kubectl create -f pod-configmap.yaml
pod/pod-configmap created
# 查看pod
[root@master ~]# kubectl get pod pod-configmap -n dev
NAME READY STATUS RESTARTS AGE
pod-configmap 1/1 Running 0 6s
#进入容器
[root@master ~]# kubectl exec -it pod-configmap -n dev /bin/sh
# cd /configmap/config/
# ls
info
# more info
username:admin
password:123456
# 可以看到映射已经成功，每个configmap都映射成了一个目录
# key--->文件 value---->文件中的内容
# 此时如果更新configmap的内容, 容器中的值也会动态更新（1）使用目录创建
--from-file 指定在目录下的所有文件都会被用在 ConfigMap 里面创建一个键值对，键的名字就是文件名，值就是文件的内容。
$ ls docs/user-guide/config-map/kubectl/
game.properties
ui.properties
# game.properties
$ cat docs/user-guide/config-map/kubectl/game.properties
enemies=aliens
lives= 3
enemies.cheat=true
enemies.cheat.level=noGoodRotten
secret.code.passphrase=UUDDLRLRBABAS
secret.code.allowed=true
secret.code.lives= 30
# ui.properties
$ cat docs/user-guide/config-map/kubectl/ui.properties
color.good=purple
color.bad=yellow
allow.textmode=true
how.nice.to.look=fairlyNice
# 创建名称为game-config的ConfigMap配置
$ kubectl create configmap game-config \
--from-file=docs/user-guide/config-map/kubectl
# 查看存储的ConfigMap列表
$ kubectl get configmap
NAME DATA AGE
game-config 2 22s
# 查看对应内容
$ kubectl describe configmap game-config
$ kubectl get configmap game-config -o yaml（2）使用文件创建
只要指定为一个文件就可以从单个文件中创建
ConfigMap。--from-file这个参数可以使用多次，你可以使用两次分别指定上个实例中的那两个配置文件，效果就跟指定整个目录是一样的。
# 创建名称为game-config-2的ConfigMap配置
$ kubectl create configmap game-config-2 \
--from-file=docs/user-guide/config-map/kubectl/game.properties
# 查看存储的ConfigMap列表
$ kubectl get configmap
NAME DATA AGE
game-config 2 34s
game-config-2 1 2s
# 查看对应内容
$ kubectl describe configmap game-config-2
$ kubectl get configmap game-config-2 -o yaml（3）使用字面值创建
使用文字值创建，利用 --from-literal 参数传递配置信息，该参数可以使用多次，格式如下。
# 创建名称为special-config的ConfigMap配置
$ kubectl create configmap special-config \
--from-literal=special.how=very \
--from-literal=special.type=charm
# 查看对应内容
$ kubectl get configmaps special-config -o yaml1.1 ConifgMap的使用
（1）使用ConfigMap来代替环境变量
apiVersion: v1
kind: ConfigMap
metadata:
name: special-config
namespace: default
data:
special.how: very
special.type: charmapiVersion: v1
kind: ConfigMap
metadata:
name: env-config
namespace: default
data:
log_level: INFOapiVersion: v1
kind: Pod
metadata:
name: myapp-test-pod
spec:
restartPolicy: Never
containers:
- name: test-container
image: hub.escape.com/library/myapp:v1
command: ["/bin/sh", "-c", "env"]
env:
- name: SPECIAL_LEVEL_KEY
valueFrom:
configMapKeyRef:
name: special-config
key: special.how
- name: SPECIAL_TYPE_KEY
valueFrom:
configMapKeyRef:
name: special-config
key: special.type
envFrom:
- configMapRef:
name: env-config（2）使用ConfigMap设置命令行参数
apiVersion: v1
kind: ConfigMap
metadata:
name: special-config
namespace: default
data:
special.how: very
special.type: charmapiVersion: v1
kind: Pod
metadata:
name: myapp-test-pod
spec:
restartPolicy: Never
containers:
- name: test-container
image: hub.escape.com/library/myapp:v1
command: ["/bin/sh", "-c", "echo $(SPECIAL_LEVEL_KEY) $(SPECIAL_TYPE_KEY)"]
env:
- name: SPECIAL_LEVEL_KEY
valueFrom:
configMapKeyRef:
name: special-config
key: special.how
- name: SPECIAL_TYPE_KEY
valueFrom:
configMapKeyRef:
name: special-config
key: special.type（3）通过数据卷插件使用 ConfigMap
在数据卷里面使用这个 ConfigMap，有不同的选项。最基本的就是将文件填入数据卷，在这个文件中，键就是文件名，键值就是文件内容。
apiVersion: v1
kind: ConfigMap
metadata:
name: special-config
namespace: default
data:
special.how: very
special.type: charmapiVersion: v1
kind: Pod
metadata:
name: myapp-test-pod
spec:
restartPolicy: Never
containers:
- name: test-container
image: hub.escape.com/library/myapp:v1
command: ["/bin/sh", "-c", "cat /etc/config/special.how"]
volumeMounts:
- name: config-volume
mountPath: /etc/config
volumes:
- name: config-volume
configMap:
name: special-config1.2 ConfigMap热更新
正常情况下，我们可以通过如下配置，在启动的 Pod 容器里面获取到 ConfigMap 中配置的信息。
apiVersion: v1
kind: ConfigMap
metadata:
name: log-config
namespace: default
data:
log_level: INFO
---
apiVersion: extensions/v1beta
kind: Deployment
metadata:
name: my-nginx
spec:
replicas: 1
template:
metadata:
labels:
run: my-nginx
spec:
containers:
- name: my-nginx
image: hub.escape.com/library/myapp:v1
ports:
- containerPort: 80
volumeMounts:
- name: config-volume
mountPath: /etc/config
volumes:
- name: config-volume
configMap:
name: log-config# 查找对应信息
$ kubectl exec \
`kubectl get pods -l run=my-nginx -o=name | cut -d "/" -f2` \
cat /etc/config/log_level
INFO修改 ConfigMap 配置，修改 log_level 的值为 DEBUG 等待大概 10 秒钟时间，再次查看环境变量的值。
# 修改ConfigMap配置
$ kubectl edit configmap log-config
# 查找对应信息
$ kubectl exec \
`kubectl get pods -l run=my-nginx -o=name|cut -d "/" -f2` \
cat /etc/config/log_level
DEBUGConfigMap 更新后滚动更新 Pod，更新 ConfigMap 目前并不会触发相关 Pod 的滚动更新，可以通过修改 pod annotations 的方式强制触发滚动更新。这个例子里我们在 .spec.template.metadata.annotations 中添加 version/config，每次通过修改 version/config 来触发滚动更新。
$ kubectl patch deployment my-nginx \
--patch '{"spec": {"template": {"metadata": {"annotations": \
{"version/config": "20190411" }}}}}'更新
ConfigMap
后：
- 使用该
ConfigMap挂载的Env不会同步更新- 使用该
ConfigMap挂载的Volume中的数据需要一段时间（实测大概10秒）才能同步更新
5.2 Secrt
在kubernetes中，还存在一种和ConfigMap非常类似的对象，称为Secret对象。它主要用于存储敏感信息，例如密码、秘钥、证书等等。
5.2.1 Secret有三种类型
Opaque：base64 编码格式的 Secret，用来存储密码、密钥等；但数据也可以通过base64 –decode解码得到原始数据，所有加密性很弱。
Service Account：用来访问Kubernetes API，由Kubernetes自动创建，并且会自动挂载到Pod的 /run/secrets/kubernetes.io/serviceaccount 目录中。
kubernetes.io/dockerconfigjson ： 用来存储私有docker registry的认证信息。
-
Opaque类型
Opaque 类型的数据是一个 map 类型，要求value是base64编码。
手动创建base64加密
$ echo -n 'admin' | base64
YWRtaW4=
$ echo -n '1f2d1e2e67df' | base64
MWYyZDFlMmU2N2Rm解密
$ echo 'MWYyZDFlMmU2N2Rm' | base64 --decode
1f2d1e2e67df这里需要注意的是，像这样创建的 Secret 对象，它里面的内容仅仅是经过了转码，而并没有被加密。在真正的生产环境中，你需要在 Kubernetes 中开启 Secret 的加密插件，增强数据的安全性。
Service Account类型
Service Account 对象的作用，就是 Kubernetes 系统内置的一种“服务账户”，它是 Kubernetes 进行权限分配的对象。比如， Service Account A，可以只被允许对 Kubernetes API 进行 GET 操作，而 Service Account B，则可以有 Kubernetes API 的所有操作权限。
kubernetes.io/dockerconfigjson类型
用来创建用户docker registry认证的Secret，直接使用kubectl create命令创建即可，如下：
kubectl create secret docker-registry myregistry --docker-server=DOCKER_SERVER --docker-username=DOCKER_USER --docker-password=DOCKER_PASSWORD --docker-email=DOCKER_EMAIL
5.2.2 secret创建及使用方式
1.secret创建方式
（1）kubectl create secret命令
[root@master yaml]# kubectl create secret --help
Create a secret using specified subcommand.
Available Commands:
docker-registry Create a secret for use with a Docker registry
generic Create a secret from a local file, directory, or literal value
tls Create a TLS secret
Usage:
kubectl create secret [flags] [options]
Use "kubectl <command> --help" for more information about a given command.
Use "kubectl options" for a list of global command-line options (applies to all commands).username.txt和password.txt文件内容如下：
$ cat ./username.txt
admin
$ cat ./password.txt
1f2d1e2e67dfgeneric子命令可以通过本地文件、目录或者literal(键值对)
$ kubectl create secret generic user --from-file=./username.txt
$ kubectl create secret generic pass --from-file=./password.txt
[root@master yaml]# kubectl get secrets | grep Opaque
pass Opaque 1 147m
user Opaque 1 148m默认情况下key为文件名
或者直接通过键值对创建
$ kubectl create secret generic user --from-literal=username=admin
$ kubectl create secret generic pass --from-literal=password=1f2d1e2e67df（2）通过yaml文件创建
#secret.yaml
apiVersion: v1
kind: Secret
metadata:
name: mysecret
type: Opaque
data:
user: YWRtaW4=
pass: MWYyZDFlMmU2N2Rm
注：通过yaml创建Opaque类型的Secret值需要base64编码创建secret
kubectl create -f secret.yaml2. secret的使用
（1）通过Volume挂载方式
#test-projected-volume.yaml
apiVersion: v1
kind: Pod
metadata:
name: test-projected-volume
spec:
containers:
- name: test-secret-volume
image: busybox
args:
- sleep
- "86400"
volumeMounts:
- name: mysql-cred
mountPath: "/projected-volume"
readOnly: true
volumes:
- name: mysql-cred
projected:
sources:
- secret:
name: user
- secret:
name: pass
创建pod对象
$ kubectl create -f test-projected-volume.yaml当 Pod 变成 Running 状态之后，我们再验证一下这些 Secret 对象是不是已经在容器里了：
$ kubectl exec -it test-projected-volume -- /bin/sh
$ ls /projected-volume/
user
pass
$ cat /projected-volume/user
admin
$ cat /projected-volume/pass
1f2d1e2e67df（2）通过环境变量
[root@master ~]# kubectl create secret generic mysecret --from-file=user=./username.txt --from-file=pass=./password.txt
#pod-secret-env.yaml
apiVersion: v1
kind: Pod
metadata:
name: pod-secret-env
spec:
containers:
- name: myapp
image: busybox
args:
- sleep
- "86400"
env:
- name: SECRET_USERNAME
valueFrom:
secretKeyRef:
name: mysecret
key: user
- name: SECRET_PASSWORD
valueFrom:
secretKeyRef:
name: mysecret
key: pass
restartPolicy: Never
创建pod
$kubectl create -f pod-secret-env.yamlpod运行成功后：
$ kubectl exec -it pod-secret-env -- /bin/sh进入容器中查看环境变量通过volume挂载和环境变量的区别
通过Volume挂载到容器内部时，当该Secret的值发生变化时，容器内部具备自动更新的能力，但是通过环境变量设置到容器内部该值不具备自动更新的能力。所以一般推荐使用Volume挂载的方式使用Secret。
1.首先使用base64对数据进行编码
[root@master ~]# echo -n 'admin' | base64 #准备username
YWRtaW4=
[root@master ~]# echo -n '123456' | base64 #准备password
MTIzNDU22.接下来编写secret.yaml，并创建Secret
apiVersion: v1
kind: Secret
metadata:
name: secret
namespace: dev
type: Opaque
data:
username: YWRtaW4=
password: MTIzNDU2# 创建secret
[root@master ~]# kubectl create -f secret.yaml
secret/secret created
# 查看secret详情
[root@master ~]# kubectl describe secret secret -n dev
Name: secret
Namespace: dev
Labels: <none>
Annotations: <none>
Type: Opaque
Data
====
password: 6 bytes
username: 5 bytes3. 创建pod-secret.yaml，将上面创建的secret挂载进去：
apiVersion: v1
kind: Pod
metadata:
name: pod-secret
namespace: dev
spec:
containers:
- name: nginx
image: nginx:1.17.1
volumeMounts: # 将secret挂载到目录
- name: config
mountPath: /secret/config
volumes:
- name: config
secret:
secretName: secret# 创建pod
[root@master ~]# kubectl create -f pod-secret.yaml
pod/pod-secret created
# 查看pod
[root@master ~]# kubectl get pod pod-secret -n dev
NAME READY STATUS RESTARTS AGE
pod-secret 1/1 Running 0 2m28s
# 进入容器，查看secret信息，发现已经自动解码了
[root@master ~]# kubectl exec -it pod-secret /bin/sh -n dev
/ # ls /secret/config/
password username
/ # more /secret/config/username
admin
/ # more /secret/config/password
123456至此，已经实现了利用secret实现了信息的编码。
5.3 dockers config json
5.3.1 使用 Kuberctl 创建 docker registry 认证的 secret。
# 创建格式
$ kubectl create secret docker-registry myregistrykey \
--docker-server=DOCKER_REGISTRY_SERVER \
--docker-username=DOCKER_USER \
--docker-password=DOCKER_PASSWORD \
--docker-email=DOCKER_EMAIL
# 示例演示
$ kubectl create secret docker-registry myregistrykey \
--docker-server=hub.escape.com \
--docker-username=admin \
--docker-password=harbor123456 \
--docker-email=harbor@escape.com5.3.2 在创建 Pod 的时候，通过 imagePullSecrets 来引用刚创建的 myregistrykey。
apiVersion: v1
kind: Pod
metadata:
name: registry-test
spec:
containers:
- name: registry-test
image: hub.escape.com/library/myapp:v1
imagePullSecrets:
name: myregistrykey
扫一扫
998
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
