0
0

k8s数据存储

文章目录

一、引言

容器的生命周期可能很短，会被频繁地创建和销毁。容器在销毁时，保存在容器中的数据也会被清除。这种结果对用户来说，在某些情况下是不乐意看到的。为了持久化保存容器的数据，kubernetes引入了Volume的概念。

Volume是Pod中能够被多个container访问的共享目录。它被定义在Pod上，然后被一个Pod里的多个容器挂载到具体的文件目录下。Kubernetes通过Volume实现：

  1. 同一个Pod中不同容器之间的数据共享
  2. 数据的持久化存储。

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中通过命令将日志内容读到控制台。

如下图所示：

image-20240801002333395

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:80volumeMounts:-name: logs-volume
       mountPath: /var/log/nginx
   -name: busybox
     image: busybox:1.30command:["/bin/sh","-c","tail -f /logs/access.log"]volumeMounts:-name: logs-volume
       mountPath: /logs
   volumes:-name: logs-volume
     emptyDir:{}

1.3、创建Pod

kubectl apply -f volume-emptydir.yaml

image-20240730154218490

1.4、查看Pod

kubectl get pods -o wide

image-20240730154423817

1.5、通过PodIP访问nginx

curl10.244.2.10

image-20240730154621781

1.6、查看容器的标准输出

kubectl logs -f volume-emptydir -n default -c busybox

image-20240730154756275

2、HostPath

上面EmptyDir提到，EmptyDir中数据不会被持久化，它会随着Pod的结束而销毁，如果想简单的将数据持久化到主机中，可以选择HostPath。

HostPath就是将Node主机中一个实际目录挂在到Pod中，以供容器使用，这样的设计就可以保证Pod销毁了，但是数据依据可以存在于Node主机上。

image-20240801234925204

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:80volumeMounts:-name: logs-volume
          mountPath: /var/log/nginx
    -name: busybox
      image: busybox:1.30command:["/bin/sh","-c","tail -f /logs/access.log"]volumeMounts:-name: logs-volume
          mountPath: /logs
  volumes:-name: logs-volume
      hostPath:path: /root/logs
        type: DirectoryOrCreate  # 目录存在就使用，不存在就先创建后使用

2.2、.spec.volumes[*].hostPath.type

关于type类型的说明：
类型说明DirectoryOrCreate目录存在就使用，不存在就先创建Directory目录必须存在FileOrCreate文件存在就使用，不存在就先创建File文件必须存在Socketunix套接字必须存在CharDevice字符设备必须存在BlockDevice块设备必须存在

2.3、创建Pod

kubectl apply -f volume-hostpath.yaml

image-20240730155231004

2.4、查看Pod

kubectl get pods -n default -o wide

image-20240730155605815

2.5、通过PodIP访问nginx

curl10.244.1.9

image-20240730155835120

2.6、到host的/root/logs目录下查看存储的文件

下面的操作需要到Pod所在的节点运行（案例中是k8s-node1）

tail-f /root/logs/access.log

image-20240730160208446

2.7、host下创建文件观察容器内部变化

echo"hello HostPath">test

在host本地创建文件验证同步image-20240730160540528分别进入nginx和busybox容器查看image-20240730161126477

2.8、删除Pod观察host本地文件是否存在

kubectl delete pods volume-hostpath -n default

image-20240730162352540

3、NFS

HostPath可以解决数据持久化的问题，但是一旦Node节点故障了，Pod如果转移到了别的节点，又会出现问题了（会有新的hostpath volume在别的Node创建，但是原来的数据丢失了），此时需要准备单独的网络存储系统，比较常用的用NFS、CIFS。
NFS是一个网络文件存储系统，可以搭建一台NFS服务器，然后将Pod中的存储直接连接到NFS系统上，这样的话，无论Pod在节点上怎么转移，只要Node跟NFS的对接没问题，数据就可以成功访问。

image-20240801235341867

3.1、准备NFS服务器

3.1.1、master节点安装nfs服务

master节点做nfs服务器

yum install-y nfs-utils
3.1.2、准备一个共享目录
mkdir-pv /root/data/nfs
3.1.3、将共享目录以读写权限暴露给同一网段中的所有主机
echo"/root/data/nfs 192.168.112.0/24(rw,sync,no_subtree_check)">> /etc/exports
3.1.4、启动nfs服务
systemctl start nfs && systemctl enable nfs

3.2、每个节点安装nfs

不需要启动

yum install-y nfs-utils

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 #共享文件路径

3.4、创建Pod

kubectl apply -f volume-nfs.yaml

image-20240730164943423

3.5、查看Pod

kubectl get pods -o wide

image-20240730173745582

3.6、通过PodIP访问nginx

curl10.244.2.3

image-20240730174005173

3.7、查看nfs服务器的共享目录

cd /root/data/nfs &&lscat access.log

image-20240730174137541

三、高级存储

1、引言

为了能够屏蔽底层存储实现的细节，方便用户使用，kubernetes引入了PV和PVC两种资源对象。

持久卷（PersistentVolume，PV）是集群中由管理员配置的一段网络存储。它是集群中的资源，就像节点是集群资源一样。一般情况下PV由kubernetes管理员进行创建和配置，它与底层具体的共享存储技术有关。PV持久卷和普通的Volume一样，也是使用卷插件来实现的，只是它们拥有独立于任何使用PV的Pod的生命周期。此API对象捕获存储实现的详细信息，包括NFS，iSCSI或特定于云提供程序的存储系统。

持久卷申领（PersistentVolumeClaim，PVC）表达的是用户对存储的请求。概念上与Pod类似。Pod会耗用节点资源，而PVC申领会耗用PV资源。Pod可以请求特定数量的资源（CPU 和内存）；同样 PVC 申领也可以请求特定的大小和访问模式 。

img

对于用户来说，只提存储需求（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

2.2、字段解释

  • 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}

image-20240730192514329

  • 暴露服务
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

image-20240730193113143

  • 重启nfs服务
systemctl restart nfs
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.3、创建PV
kubectl apply -f pv.yaml

image-20240730193752934

2.4.4、查看PV
kubectl get pv-o wide

image-20240730193847790

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]}

3.2、字段解释

  • 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
3.3.2、创建PVC
kubectl applpy -f pvc.yaml

image-20240730200946288

3.3.3、查看PVC
kubectl get pvc -o wide

image-20240730201347410

3.3.4、查看PV
kubectl get pv-o wide

image-20240730201517699

3.3.5、编写Pod资源清单，使用PVC

pods.yaml

apiVersion: v1
kind: Pod
metadata:name: pod1
  namespace: default
spec:containers:-name: busybox
      image: busybox:1.30command:["/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.30command:["/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
3.3.6、创建Pod
kubectl apply -f pods.yaml

image-20240730202113136

3.3.7、查看Pod，PVC，PV
kubectl get pods，pvc,pv -o wide

image-20240730202510890

3.3.8、查看nfs中的文件存储
cat /root/data/pv1/out.txt
cat /root/data/pv2/out.txt
cat /root/data/pv3/out.txt

/root/data/pv1/out.txtimage-20240730203551447/root/data/pv2/out.txtimage-20240730203651579/root/data/pv3/out.txtimage-20240730203830479

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

image-20240730204255191

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绑定和使用

image-20240802001743014

四、配置存储

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

1.2、字段解释

**

apiVersion: v1

**

  • 说明: 指定 ConfigMap 的 API 版本。在这个例子中，我们使用的是 Kubernetes API 的第一个版本。

**

kind: ConfigMap

**

  • 说明: 指定此资源的类型为 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 - 说明: 表示玩家的最大生命值为 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
1.3.2、挂载为文件
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
1.3.3、挂载为 Volume 中的文件
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.4.1、编写configmap资源清单
apiVersion: v1
kind: ConfigMap
metadata:name: configmap
  namespace: default
data:# info是key，后面的都是valueinfo:|# | 代表保留换行符
    username:admin
    password:123456
1.4.2、创建ConfigMap
kubectl apply -f configmap.yaml

image-20240730234833147

1.4.3、查看ConfigMap详细信息
kubectl describe configmap configmap

image-20240730235135501

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
1.4.5、创建Pod，并进入容器查看
kubectl apply -f pod-configmap.yaml

kubectl exec-it pod-configmap -c nginx /bin/bash

cd configmap/config/ &&ls&&cat info

image-20240730235840604

可以看到映射已经成功，每个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

kubectl edit 在线修改ConfigMapimage-20240731000447888进入到容器查看内容变化image-20240731000647467

2、Secret

在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

image-20240731231850202

在创建 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

image-20240731232538345

2.2.3、查看secret详情
kubectl get secret secret -o yaml

image-20240731232749287

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

image-20240731233719383

2.2.5、进入容器查看Secret信息
kubectl exec-it pod-secret -- bash

image-20240731234835852

标签： kubernetes 容器 云原生
本文转载自: https://blog.csdn.net/misakivv/article/details/140860222
版权归原作者 misakivv 所有， 如有侵权，请联系我们删除。
登录后发布评论

“k8s数据存储”的评论:

还没有评论
关于作者
...
overfit同步小助手
文章同步
相关阅读

网络安全法-网络运行安全

使用selenium/drissionpage时如何阻止chrome自动跳转http到https

docker desktop 里部署的Open WebUI 管理员密码忘记了的处理方法

在ubuntu20.04中搭建onsite比赛运行环境

利用开源的低代码表单设计器FcDesigner高效管理和渲染复杂表单结构

Kafka学习笔记

【前端】浏览器输入url到页面呈现发生了什么？

文章导航