目录
一、引言
容器的生命周期可能很短，会被频繁地创建和烧毁。容器在烧毁时，保存在容器中的数据也会被扫除。这种结果对用户来说，在某些环境下是不乐意看到的。为了持久化保存容器的数据，kubernetes引入了Volume的概念。
Volume是Pod中能够被多个container访问的共享目录。它被定义在Pod上，然后被一个Pod里的多个容器挂载到具体的文件目录下。Kubernetes通过Volume实现：
- 同一个Pod中差别容器之间的数据共享
- 数据的持久化存储。
Volume的生命周期不与Pod中单个container的生命周期相关联。当container停止或重启时，Volume中的数据也不会丢失。
Kubernetes的Volume支持多种类型，常见的有：
- 简单存储：EmptyDir、HostPath、NFS
- 高级存储：PV、PVC
- 配置存储：ConfigMap、Secret
二、基本存储
1、EmptyDir
最基础的Volume类型，一个EmptyDir就是Host上的一个空目录。
EmptyDir是在Pod分配到Node时创建的，它的初始内容为空，并且无需指定宿主机上对应的目录文件，由于kubernetes会主动分配一个目录。当Pod烧毁时，EmptyDir中的数据也会被永久删除。EmptyDir用途为：
- 临时空间，比方用于某些应用步伐运行时所需的临时目录，且无需永久保留
- 一个容器需要从另一个容器中获取数据的目录（多容器共享目录）
- 缓存空间，比方基于磁盘的归并排序。
- 为耗时较长的盘算任务提供检查点，以便任务能方便地从崩溃前状态恢复执行。
- 在 Web 服务器容器服务数据时，保存内容管理器容器获取的文件。
1.1、示例
下面演示一个示例：在一个Pod中准备2个容器：nginx和busybox，然后声明一个Volume分别挂在2个容器的目录中。Nginx负责向Volume中写日志，busybox中通过命令将日志内容读到控制台。
如下图所示：
1.2、创建资源清单
volume-emptydir.yaml
- apiVersion: v1
- kind: Pod
- metadata:
- name: volume-emptydir
- namespace: default
- 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
- emptyDir: {}
- kubectl apply -f volume-emptydir.yaml
1.4、查看Pod
1.5、通过PodIP访问nginx
1.6、查看容器的标准输出
- kubectl logs -f volume-emptydir -n default -c busybox
2、HostPath
上面EmptyDir提到，EmptyDir中数据不会被持久化，它会随着Pod的竣事而烧毁，假如想简单的将数据持久化到主机中，可以选择HostPath。
HostPath就是将Node主机中一个实际目录挂在到Pod中，以供容器利用，如许的计划就可以保证Pod烧毁了，但是数据依据可以存在于Node主机上。
2.1、创建资源清单
volume-hostpath.yaml
- apiVersion: v1
- kind: Pod
- metadata:
- name: volume-hostpath
- namespace: default
- 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 # 目录存在就使用，不存在就先创建后使用
.hostPath.type
关于type类型的说明：
类型说明DirectoryOrCreate目录存在就利用，不存在就先创建Directory目录必须存在FileOrCreate文件存在就利用，不存在就先创建File文件必须存在Socketunix套接字必须存在CharDevice字符装备必须存在BlockDevice块装备必须存在2.3、创建Pod
- kubectl apply -f volume-hostpath.yaml
2.4、查看Pod
- kubectl get pods -n default -o wide
2.5、通过PodIP访问nginx
2.6、到host的/root/logs目录下查看存储的文件
下面的操纵需要到Pod所在的节点运行（案例中是k8s-node1）
- tail -f /root/logs/access.log
2.7、host下创建文件观察容器内部变化
- echo "hello HostPath" > test
- kubectl delete pods volume-hostpath -n default
3、NFS
HostPath可以解决数据持久化的问题，但是一旦Node节点故障了，Pod假如转移到了别的节点，又会出现问题了（会有新的hostpath volume在别的Node创建，但是原来的数据丢失了），此时需要准备单独的网络存储系统，比力常用的用NFS、CIFS。
NFS是一个网络文件存储系统，可以搭建一台NFS服务器，然后将Pod中的存储直接连接到NFS系统上，如许的话，无论Pod在节点上怎么转移，只要Node跟NFS的对接没问题，数据就可以成功访问。
3.1、准备NFS服务器
3.1.1、master节点安装nfs服务
master节点做nfs服务器
3.1.2、准备一个共享目录
3.1.3、将共享目录以读写权限袒露给同一网段中的所有主机
- echo "/root/data/nfs 192.168.112.0/24(rw,sync,no_subtree_check)" >> /etc/exports
- systemctl start nfs && systemctl enable nfs
不需要启动
3.3、编写资源清单
volume-nfs.yaml
- apiVersion: v1
- kind: Pod
- metadata:
- name: volume-nfs
- namespace: default
- 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: 192.168.112.10 #nfs服务器地址
- path: /root/data/nfs #共享文件路径
- kubectl apply -f volume-nfs.yaml
3.5、查看Pod
3.6、通过PodIP访问nginx
3.7、查看nfs服务器的共享目录
- cd /root/data/nfs && ls
- cat access.log
三、高级存储
1、引言
为了能够屏蔽底层存储实现的细节，方便用户利用，kubernetes引入了PV和PVC两种资源对象。
持久卷（PersistentVolume，PV）是集群中由管理员配置的一段网络存储。它是集群中的资源，就像节点是集群资源一样。一样平常环境下PV由kubernetes管理员举行创建和配置，它与底层具体的共享存储技能有关。PV持久卷和普通的Volume一样，也是利用卷插件来实现的，只是它们拥有独立于任何利用PV的Pod的生命周期。此API对象捕获存储实现的详细信息，包罗NFS，iSCSI或特定于云提供步伐的存储系统。
持久卷申领（PersistentVolumeClaim，PVC）表达的是用户对存储的请求。概念上与Pod类似。Pod会耗用节点资源，而PVC申了解耗用PV资源。Pod可以请求特定命量的资源（CPU 和内存）；同样 PVC 申领也可以请求特定的大小和访问模式 。
对于用户来说，只提存储需求（PVC），专业的具体存储配置细节（PV）由管理员完成。
利用了PV和PVC后，工作可以进一步细分：
- 存储：存储工程师维护
- PV：kubernetes管理员维护
- PVC：kubernetes用户维护
2、PV
PV是存储资源的抽象
2.1、资源清单
- apiVersion: v1
- kind: PersistentVolume
- metadata:
- name: nfs-pv
- spec:
- capacity:
- storage: 10Gi
- volumeMode: Filesystem
- accessModes:
- - ReadWriteMany
- persistentVolumeReclaimPolicy: Retain
- storageClassName: nfs-storage
- mountOptions:
- - hard
- - nfsvers=4.1
- nfs:
- path: /nfs/data
- server: nfs-server.example.com
- apiVersion: Kubernetes API 版本，这里是 v1。
- kind: 资源类型，这里是 PersistentVolume。
- metadata: PV 的元数据，包罗名称。
- spec: PV 的具体规格。
- capacity: PV 的容量大小。
- volumeMode: PV 的模式，这里为 Filesystem 表示这是一个文件系统类型的 PV。
- accessModes: PV 的访问模式列表。
- persistentVolumeReclaimPolicy: 当 PV 不再被任何 PVC 利用时的回收策略。
- storageClassName: PV 所属的存储类名称，可以为空表示无类。
- mountOptions: NFS 挂载选项。
- nfs: NFS 具体配置。
- path: 在 NFS 服务器上的路径。
- server: NFS 服务器的地点
2.3、核心概念
2.3.1、访问模式（accessModes）
用于描述用户应用对存储资源的访问权限，访问权限包罗
- ReadWriteOnce（RWO）：只仅允许单个节点以读写方式挂载
- ReadOnlyMany（ROX）：可以被很多节点以只读方式挂载
- ReadWriteMany（RWX）：可以被很多节点以只读方式挂载
- ReadWriteOncePod（RWOP k8s v1.29）：卷可以被单个 Pod 以读写方式挂载。
2.3.2、回收策略（persistentVolumeReclaimPolicy）
- Retain：保留，该策略允许手动回收资源，当删除PVC时，PV仍旧存在，PV被视为已释放，管理员可以手动回收卷。
- Delete：删除，假如Volume插件支持，删除PVC时会同时删除PV，动态卷默认为Delete，目前支持Delete的存储后端包罗AWS EBS，GCE PD，Azure Disk，OpenStack Cinder等。
- Recycle：回收，假如Volume插件支持，Recycle策略会对卷执行rm -rf清理该PV，并使其可用于下一个新的PVC，但是本策略将来会被弃用，目前只有NFS和HostPath支持该策略。
2.3.3、状态
- Available，表示pv已经创建正常，处于可用状态；
- Bound，表示pv已经被某个pvc绑定，留意，一个pv一旦被某个pvc绑定，那么该pvc就独占该pv，其他pvc不能再与该pv绑定；
- Released，表示pvc被删除了，pv状态就会酿成已释放；
- Failed，表示pv的主动回收失败；
2.4、利用NFS作为存储，演示PV的利用
2.4.1、准备NFS环境
- mkdir -pv /root/data/pv{1..3}
- echo -e "/root/data/pv1\t192.168.112.0/24(rw,no_root_squash)\n/root/data/pv2\t192.168.112.0/24(rw,no_root_squash)\n/root/data/pv3\t192.168.112.0/24(rw,no_root_squash)" > /root/data/nfs_exports
2.4.2、编写资源清单
pv.yaml
- apiVersion: v1
- kind: PersistentVolume
- metadata:
- name: pv1
- spec:
- capacity:
- storage: 1Gi
- accessModes:
- - ReadWriteMany
- persistentVolumeReclaimPolicy: Retain
- nfs:
- path: /root/data/pv1
- server: 192.168.112.10
- ---
- apiVersion: v1
- kind: PersistentVolume
- metadata:
- name: pv2
- spec:
- capacity:
- storage: 2Gi
- accessModes:
- - ReadWriteMany
- persistentVolumeReclaimPolicy: Retain
- nfs:
- path: /root/data/pv2
- server: 192.168.112.10
- ---
- apiVersion: v1
- kind: PersistentVolume
- metadata:
- name: pv3
- spec:
- capacity:
- storage: 3Gi
- accessModes:
- - ReadWriteMany
- persistentVolumeReclaimPolicy: Retain
- nfs:
- path: /root/data/pv3
- server: 192.168.112.10
2.4.4、查看PV
3、PVC
PVC作为用户对存储资源的需求申请,主要包罗存储空间请求、访问模式、PV选择条件和存储类别等信息的设置。
3.1、资源清单
- apiVersion: v1
- kind: PersistentVolumeClaim
- metadata:
- name: myclaim
- spec:
- accessModes:
- - ReadWriteOnce
- volumeMode: Filesystem
- resources:
- requests:
- storage: 8Gi
- storageClassName: slow
- selector:
- matchLabels:
- release: "stable"
- matchExpressions:
- - {key: environment, operator: In, values: [dev]}
- apiVersion: Kubernetes API 版本，这里是 v1。
- kind: 资源类型，这里是 PersistentVolumeClaim。
- metadata:
- name: PVC 的名称，这里是 myclaim。
- spec: PVC 的具体规格。
- accessModes: PVC 请求的访问模式列表。这里请求的是 ReadWriteOnce，意味着 PVC 只能被单个节点以读写方式挂
- volumeMode: PVC 请求的 PV 的模式，这里为 Filesystem 表示这是一个文件系统类型的 PV。
- resources:
- requests: PVC 请求的资源量，这里是 storage: 8Gi，即请求 8GiB 的存储空间。
- storageClassName: PVC 请求的存储类名称，这里是 slow。假如未指定，则利用默认存储类。
- selector: PVC 可以选择特定的 PV。假如指定，PVC 只能绑定到符合这些选择器条件的 PV。
- matchLabels: 标签选择器。这里的 PVC 将仅绑定到带有标签 release: stable 的 PV。
- matchExpressions: 表达式选择器。这里的 PVC 将仅绑定到带有标签 environment 并且值为 dev 的 PV。
3.3、示例
3.3.1、编写PVC资源清单，申请PV
pvc.yaml
- apiVersion: v1
- kind: PersistentVolumeClaim
- metadata:
- name: pvc1
- namespace: default
- spec:
- accessModes:
- - ReadWriteMany
- resources:
- requests:
- storage: 1Gi
- ---
- apiVersion: v1
- kind: PersistentVolumeClaim
- metadata:
- name: pvc2
- namespace: default
- spec:
- accessModes:
- - ReadWriteMany
- resources:
- requests:
- storage: 3Gi
- ---
- apiVersion: v1
- kind: PersistentVolumeClaim
- metadata:
- name: pvc3
- namespace: default
- spec:
- accessModes:
- - ReadWriteMany
- resources:
- requests:
- storage: 5Gi
- kubectl applpy -f pvc.yaml
3.3.3、查看PVC
3.3.4、查看PV
3.3.5、编写Pod资源清单，利用PVC
pods.yaml
- apiVersion: v1
- kind: Pod
- metadata:
- name: pod1
- namespace: default
- 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: default
- 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
- kubectl apply -f pods.yaml
3.3.7、查看Pod，PVC，PV
- kubectl get pods，pvc,pv -o wide
3.3.8、查看nfs中的文件存储
- cat /root/data/pv1/out.txt
- cat /root/data/pv2/out.txt
- cat /root/data/pv3/out.txt
Pod1 利用了 PVC1，PVC1 绑定了 PV1。因此，Pod1 写入的文件位于 /root/data/pv1/out.txt。
Pod2 利用了 PVC2，PVC2 绑定了 PV3。因此，Pod2 写入的文件位于 /root/data/pv3/out.txt。
PV2 未被利用，因此 /root/data/pv2/out.txt 文件不存在。
3.3.9、删除pod和pvc，查看pv状态
- kubectl delete -f pods.yaml
- kubectl delete -f pvc.yaml
- kubectl get pv -o wide
3.4、生命周期
PVC和PV是一一对应的，PV和PVC之间的相互作用遵循以下生命周期
1、资源供应：管理员手动创建底层存储和PV
2、资源绑定：用户创建PVC，kubernetes负责根据PVC的声明去探求PV，并绑定在用户定义好PVC之后，系统将根据PVC对存储资源的请求在已存在的PV中选择一个满足条件的
- 一旦找到，就将该PV与用户定义的PVC举行绑定，用户的应用就可以利用这个PVC了。PV一旦绑定到某个PVC上，就会被这个PVC独占，不能再与其他PVC举行绑定了
- 假如找不到，PVC则会无穷期处于Pending状态，直到等到系统管理员创建了一个符合其要求的PV
3、资源利用：用户可在pod中像volume一样利用pvc
Pod利用Volume的定义，将PVC挂载到容器内的某个路径举行利用。
4、资源释放：用户删除pvc来释放pv
当存储资源利用完毕后，用户可以删除PVC，与该PVC绑定的PV将会被标志为“已释放”，但还不能立即与其他PVC举行绑定。通过之前PVC写入的数据可能还被留在存储装备上，只有在扫除之后该PV才能再次利用。
5、资源回收：kubernetes根据pv设置的回收策略举行资源的回收
对于PV，管理员可以设定回收策略，用于设置与之绑定的PVC释放资源之后如那边置惩罚遗留数据的问题。只有PV的存储空间完成回收，才能供新的PVC绑定和利用
四、配置存储
1、ConfigMap
ConfigMap 是 Kubernetes 中的一种 API 对象，用于存储非敏感的配置数据。它允许开辟者将配置数据与应用步伐容器分离，从而使得配置可以在不重新构建容器镜像的环境下举行更改。ConfigMap 可以存储简单的键值对大概一组文件，并且可以通过多种方式被应用步伐容器访问。
1.1、资源清单
- apiVersion: v1
- kind: ConfigMap
- metadata:
- name: game-demo
- data:
- # 类属性键；每一个键都映射到一个简单的值
- player_initial_lives: "3"
- ui_properties_file_name: "user-interface.properties"
- # 类文件键
- game.properties: |
- enemy.types=aliens,monsters
- player.maximum-lives=5
- user-interface.properties: |
- color.good=purple
- color.bad=yellow
- allow.textmode=true
apiVersion: v1
- 说明: 指定 ConfigMap 的 API 版本。在这个例子中，我们利用的是 Kubernetes API 的第一个版本。
kind: ConfigMap
metadata:
- 说明: 包含元数据信息，比如名称。
- name: game-demo
- 说明: ConfigMap 的名称。在同一个命名空间内必须唯一。
data:
- 说明: 存储配置数据的部分，支持键值对的情势。
- player_initial_lives: "3"
- 说明: 一个键值对，键为 player_initial_lives，值为 "3"。这个键值对表示玩家初始的生命值为 3。
- ui_properties_file_name: "user-interface.properties"
- 说明: 一个键值对，键为 ui_properties_file_name，值为 "user-interface.properties"。这个键值对表示 UI 属性文件的名称。
- game.properties: |
- 说明: 一个多行配置文件的示例。这里利用了 YAML 的|符号来表示一个块文本（block text），允许你直接嵌入多行文本而不必利用换行符。
- enemy.types=aliens,monsters
- player.maximum-lives=5
- user-interface.properties: |
- 说明: 另一个多行配置文件的示例。
- color.good=purple
- color.bad=yellow
- allow.textmode=true
1.3、利用场景
官方示例的 ConfigMap 可以通过多种方式被 Pod 利用
1.3.1、作为环境变量
- apiVersion: v1
- kind: Pod
- metadata:
- name: my-pod
- spec:
- containers:
- - name: my-container
- image: my-image
- env:
- - name: PLAYER_INITIAL_LIVES
- valueFrom:
- configMapKeyRef:
- name: game-demo
- key: player_initial_lives
- - name: UI_PROPERTIES_FILE_NAME
- valueFrom:
- configMapKeyRef:
- name: game-demo
- key: ui_properties_file_name
- apiVersion: v1
- kind: Pod
- metadata:
- name: my-pod
- spec:
- containers:
- - name: my-container
- image: my-image
- volumeMounts:
- - name: config-volume
- mountPath: /etc/game-demo
- volumes:
- - name: config-volume
- configMap:
- name: game-demo
- apiVersion: v1
- kind: Pod
- metadata:
- name: my-pod
- spec:
- containers:
- - name: my-container
- image: my-image
- volumeMounts:
- - name: config-volume
- mountPath: /etc/game-demo
- volumes:
- - name: config-volume
- configMap:
- name: game-demo items: - key: player_initial_lives path: player_initial_lives.properties - key: ui_properties_file_name path: ui_properties_file_name.properties - key: game.properties path: game.properties - key: user-interface.properties path: user-interface.properties
1.4.1、编写configmap资源清单
- apiVersion: v1
- kind: ConfigMap
- metadata:
- name: configmap
- namespace: default
- data: # info是key，后面的都是value
- info: | # | 代表保留换行符
- username:admin
- password:123456
- kubectl apply -f configmap.yaml
1.4.3、查看ConfigMap详细信息
- kubectl describe configmap configmap
1.4.4、编写pod-configmap.yaml，将创建的configmap挂载进去
- apiVersion: v1
- kind: Pod
- metadata:
- name: pod-configmap
- namespace: default
- spec:
- containers:
- - name: nginx
- image: nginx:1.17.1
- volumeMounts: # 将configmap挂载到目录
- - name: config
- mountPath: /configmap/config
- volumes: # 引用configmap
- - name: config
- configMap:
- name: configmap # 注意这里的name就是上面创建好的configmap
- kubectl apply -f pod-configmap.yaml
- kubectl exec -it pod-configmap -c nginx /bin/bash
- cd configmap/config/ && ls && cat info
可以看到映射已经成功，每个configmap都映射成了一个目录
key--->文件 value---->文件中的内容
1.4.6、在线修改configmap的内容，查看容器中变化
- kubectl edit configmap configmap
- kubectl exec -it pod-configmap -c nginx /bin/bash
- cd configmap/config/ && ls && cat change info
在kubernetes中，还存在一种和ConfigMap非常类似的对象，称为Secret对象。用于存储敏感信息，如密码、密钥和其他秘密数据。Secret 的计划目的是为了安全地管理这些敏感信息，避免它们被硬编码到配置文件或源代码中。
2.1、Secret的类型
创建 Secret 时，你可以利用 Secret 资源的 type 字段，大概与其等价的 kubectl 命令行参数（假如有的话）为其设置类型。 Secret 类型有助于对 Secret 数据举行编程处置惩罚。
Kubernetes 提供若干种内置的类型，用于一些常见的利用场景。 针对这些类型，Kubernetes 所执行的合法性检查操纵以及对其所实行的限制各不相同。
内置类型用法Opaque用户定义的任意数据kubernetes.io/service-account-token服务账命令牌kubernetes.io/dockercfg~/.dockercfg 文件的序列化情势kubernetes.io/dockerconfigjson~/.docker/config.json 文件的序列化情势kubernetes.io/basic-auth用于基本身份认证的根据kubernetes.io/ssh-auth用于 SSH 身份认证的根据kubernetes.io/tls用于 TLS 客户端大概服务器端的数据bootstrap.kubernetes.io/token启动引导令牌数据通过为 Secret 对象的 type 字段设置一个非空的字符串值，你也可以定义并利用本身 Secret 类型（假如 type 值为空字符串，则被视为 Opaque 类型）。
Kubernetes 并不对类型的名称作任何限制。不外，假如你要利用内置类型之一， 则你必须满足为该类型所定义的所有要求。
假如你要定义一种公开利用的 Secret 类型，请遵守 Secret 类型的约定和结构， 在类型名前面添加域名，并用 / 隔开。 比方：cloud-hosting.example.net/cloud-api-credentials。
2.2、示例
2.2.1、利用base64对数据举行编码
- echo -n 'root' | base64
- echo -n 'zhangsan' | base64
在创建 Kubernetes Secret 时，利用 -n 参数可以确保 base64 编码的字符串不会包含不必要的换行符，由于换行符可能会导致 base64 编码的结果不精确。
2.2.2、编写Secret资源清单并创建Secret
secret.yaml
- apiVersion: v1
- kind: Secret
- metadata:
- name: secret
- namespace: default
- type: Opaque
- data:
- username: cm9vdA==
- password: emhhbmdzYW4=
- kubectl apply -f secret.yaml
2.2.3、查看secret详情
- kubectl get secret secret -o yaml
2.2.4、创建Pod，将上面创建的Secret挂载上去
pod-secret.yaml
- apiVersion: v1
- kind: Pod
- metadata:
- name: pod-secret
- namespace: default
- spec:
- containers:
- - name: nginx
- image: nginx:1.17.1
- volumeMounts: # 将secret挂载到目录
- - name: config
- mountPath: /secret/config
- volumes:
- - name: config
- secret:
- secretName: secret
- kubectl apply -f pod-secret.yaml
- kubectl get pods -o wide
2.2.5、进入容器查看Secret信息
- kubectl exec -it pod-secret -- bash
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。 |
