Kubernetes之数据存储

已于 2023-01-18 16:58:56 修改
阅读量823 收藏
点赞数 1
分类专栏： Kubernetes 文章标签： kubernetes 数据存储
于 2022-07-16 14:46:19 首次发布
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/qq_26709459/article/details/125817903
版权

文章目录


        pod中容器的销毁重建我们会发现一个问题，容器销毁时，保存在容器中的数据也会随之被清除，因此我们需要借助Volume来实现数据的持久化。
        在创建pod时，可以定义Volume，它是挂载到具体的文件目录下的，这个Volume可以被多个容器所共享。kubernetes通过Volume实现了同一个Pod中不同容器之间的数据共享以及数据的持久化存储。

Kubernetes的Volume有如下几种类型：

  • 简单存储：EmptyDir、HostPath、NFS
  • 高级存储：PV、PVC
  • 配置存储：ConfigMap、Secret

一、简单存储类型

1、EmptyDir

        该类型的Volume在Pod分配到Node上时被创建，并自动分配一个目录，因此无需指定宿主机Node上对应的目录文件。当Pod销毁时，EmptyDir中的数据也会被永久删除。
其用途如下说明:

  • 临时空间:例如用于某些应用程序运行时所需的临时目录，且无须永久保留
  • 一个容器需要从另一个容器中获取数据的目录（多容器共享目录）

如下我们通过busybox读取一个springboot项目中的log信息，来演示多容器共享目录：

emptydir-pod.yaml

apiVersion: v1
kind: Pod
metadata:
  name: volume-emptydir
  namespace: dev
spec:
  containers:
  - name: boot
    image: registry.cn-hangzhou.aliyuncs.com/button_dev/test:v1.4
    ports:
    - containerPort: 8082
    volumeMounts:  # 将name为：logs-volume的volume挂载到容器中，对应的目录为/var/tmp/logs
    - name: logs-volume
      mountPath: /var/tmp/logs
  - name: busybox
    image: busybox:1.30
    command: ["/bin/sh","-c","tail -f /logs/boot.info.log"] # 初始命令，动态读取指定文件中内容
    volumeMounts:  # 将logs-volume挂载到busybox容器中，对应的目录为 /logs
    - name: logs-volume
      mountPath: /logs
  volumes: # 声明volume，name为logs-volume，类型为emptyDir
  - name: logs-volume
    emptyDir: {}

然后我们查看busybox容器中的log信息，可以发现读取到了我们springboot项目的启动日志：

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

在这里插入图片描述

2、HostPath

        思考一个问题，EmptyDir在销毁时数据就丢失了，如果想长期保存这些数据，EmptyDir显然不能满足了。如果想简单的将数据持久化到主机中，可以选择HostPath。HostPath是将Node主机中一个实际目录挂载到Pod中，以供容器使用，就算pod销毁了，数据依然保存在node主机上。

vim hostpath-pod.yaml

apiVersion: v1
kind: Pod
metadata:
  name: volume-hostpath
  namespace: dev
spec:
  containers:
 - name: boot
    image: registry.cn-hangzhou.aliyuncs.com/button_dev/test:v1.4
    ports:
    - containerPort: 8082
    volumeMounts:  # 将name为logs-hostpath-volume的volume挂载到容器中，对应的目录为/var/tmp/logs
    - name: logs-hostpath-volume
      mountPath: /var/tmp/logs
 - name: busybox
    image: busybox:1.30
    command: ["/bin/sh","-c","tail -f /logs/boot.info.log"]
    volumeMounts:  # 将logs-hostpath-volume挂载到busybox容器中，对应的目录为/logs
    - name: logs-hostpath-volume
      mountPath: /logs
  volumes: # 声明volume，name为logs-hostpath-volume，类型为hostPath
 - name: logs-hostpath-volume
    hostPath:
      path: /mnt/logs
      type: DirectoryOrCreate  # 目录存在就使用，不存在就先创建后使用

type值的说明：

  • DirectoryOrCreate 目录存在就使用，不存在就先创建后使用
  • Directory 目录必须存在
  • FileOrCreate 文件存在就使用，不存在就先创建后使用
  • File 文件必须存在
  • Socket unix套接字必须存在
  • CharDevice 字符设备必须存在
  • BlockDevice 块设备必须存在
    在这里插入图片描述
    在node2中查看对应的文件目录：
    在这里插入图片描述

3、NFS

        HostPath将pod的数据保存到了调度的node节点上，一旦node节点故障，pod被调度到了别的节点，此时相应的数据也就丢失了。所以需要单独的存储系统，我们只需要将相关数据保存至存储系统，就可以解决该问题。比较常见的存储系统有NFS、CIF等。

以nfs为例，找一台机器安装nfs(我这里直接安装到了master节点上):

#安装
yum install nfs-utils -y
#创建一个共享目录
mkdir /home/data/nfs -pv
#将共享目录的读写权限暴露给指定网段中的所有主机(根据自己网段配置)
vim /etc/exports
#配置内容如下
/home/data/nfs     192.168.242.0/24(rw,no_root_squash)
#启动nfs
systemctl restart nfs

接下来在每个kubernetes集群节点上都安装nfs，不需要配置和启动(只是为了node节点可以驱动nfs设备)：

yum install nfs-utils -y

将上面的案例做些改动：

vim nfs-pod.yaml

apiVersion: v1
kind: Pod
metadata:
  name: volume-nfs
  namespace: dev
spec:
  containers:
  - name: boot
    image: registry.cn-hangzhou.aliyuncs.com/button_dev/test:v1.4
    ports:
    - containerPort: 8082
    volumeMounts:
    - name: logs-nfs-volume
      mountPath: /var/tmp/logs
  - name: busybox
    image: busybox:1.30
    command: ["/bin/sh","-c","tail -f /logs/boot.info.log"]
    volumeMounts:
    - name: logs-nfs-volume
      mountPath: /logs
  volumes:
  - name: logs-nfs-volume
    nfs:
      server: 192.168.242.134 #nfs服务器地址
      path: /home/data/nfs #共享文件路径

创建完成后，我们可以查看nfs的文件目录：
在这里插入图片描述

一、高级存储

在kubernetes集群使用数据存储，由于所支持的存储服务众多，为了能够屏蔽底层存储的实现细节，方便我们的使用，k8s引入了PV和PVC两种资源对象。
PV（Persistent Volume）是持久化卷的意思，是对底层存储设备的一种抽象。一般该部分由管理员创建和配置。
PVC（Persistent Volume Claim）是持久化卷声明的意思，简单来说就是我们对应存储的需求声明。简而言之PVC就是用户向kubernetes系统发出的一种资源需求申请。
看到这里，简单概括一下分工：存储服务一般由存储负责的工程师维护，PV由kubernetes管理员维护，PVC由用户维护。

1、PV

资源清单如下：

apiVersion: v1  
kind: PersistentVolume
metadata:
  name: pv2
spec:
  nfs:       # 存储类型，与底层真正存储对应
  capacity:  # 存储能力
    storage: 2Gi
  accessModes:  # 访问模式
  storageClassName: # 存储类别
  persistentVolumeReclaimPolicy: # 回收策略

参数详细说明：
（1）存储类型：根据自己的需求，不同存储类型的配置都有所差异
（2）存储能力(capacity)：目前支持存储空间的设置( storage=1Gi )
（3）访问模式(accessModes)：底层存储类型不同，所支持的访问模式也不同

  • ReadWriteOnce（RWO）：读写权限，只能被单个节点挂载
  • ReadOnlyMany（ROX）： 只读权限，可以被多个节点挂载
  • ReadWriteMany（RWX）：读写权限，可以被多个节点挂载

（4）存储类别

  • 具有特定类别的PV只能与请求了该类别的PVC进行绑定
  • 未设定类别的PV则只能与不请求任何类别的PVC进行绑定
    （5）回收策略(persistentVolumeReclaimPolicy)：底层不同的存储类型可能支持的回收策略不同
    当PV不再被使用了之后，对其的处理方式:
  • Retain （保留）：保留数据，需要管理员手工清理在这里插入代码片数据
  • Recycle（回收）：清除 PV 中的数据，效果相当于执行 rm -rf /data/*
  • Delete （删除）：当对应PVC删除后，动态配置的volume将自动删除

PVC的生命周期有如下几个阶段：

  • Available（可用）： 表示可用状态，还未被任何 PVC 绑定
  • Bound（已绑定）： 表示 PV 已经被 PVC 绑定
  • Released（已释放）： 表示 PVC 被删除，但是资源还未被集群重新声明
  • Failed（失败）： 表示该 PV 的自动回收失败

创建PVC：
前提准备：nfs我们暴露三个目录出来：

vim /etc/exports
```.

```bash
/home/data/pv1     192.168.242.0/24(rw,async,no_root_squash)
/home/data/pv2     192.168.242.0/24(rw,async,no_root_squash)
/home/data/pv3     192.168.242.0/24(rw,async,no_root_squash)

systemctl restart nfs

创建3个PV：

vim pv.yaml

apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv1-dev
spec:
  capacity:
    storage: 1Gi
  accessModes:
  - ReadWriteMany
  persistentVolumeReclaimPolicy: Retain
  nfs:
    path: /home/data/pv1
    server: 192.168.242.134

---

apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv2-dev
spec:
  capacity:
    storage: 2Gi
  accessModes:
  - ReadWriteMany
  persistentVolumeReclaimPolicy: Retain
  nfs:
    path: /home/data/pv2
    server: 192.168.242.134

---

apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv3-dev
spec:
  capacity:
    storage: 3Gi
  accessModes:
  - ReadWriteMany
  persistentVolumeReclaimPolicy: Retain
  nfs:
    path: /home/data/pv3
    server: 192.168.242.134

在这里插入图片描述

2、PVC

资源清单如下：

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: pvc
  namespace: dev
spec:
  accessModes:      # 访问模式
  selector:         # 采用标签对PV选择
  storageClassName: # 存储类别
  resources:        # 请求空间
    requests:
      storage: 2Gi

参数说明如下：
（1）访问模式（accessModes）
描述用户应用对存储资源的访问权限
（2）选择条件（selector）
通过对Label Selector的设置，PVC可以对系统中己存在的PV进行筛选
（3）存储类别（storageClassName）
PVC在定义时可以设定需要的后端存储的类别，只有设置了该class的pv才能被系统选出
（4）资源请求（Resources）
描述对存储资源的需求

创建PVC：

vim pvc.yaml

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: pvc1-dev
  namespace: dev
spec:
  accessModes:
  - ReadWriteMany
  resources:
    requests:
      storage: 1Gi
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: pvc2-dev
  namespace: dev
spec:
  accessModes:
  - ReadWriteMany
  resources:
    requests:
      storage: 1.6Gi
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: pvc3-dev
  namespace: dev
spec:
  accessModes:
  - ReadWriteMany
  resources:
    requests:
      storage: 2Gi

在这里插入图片描述
创建完成PV与PVC后接着创建Pod：

vim pvc-pod.yaml

apiVersion: v1
kind: Pod
metadata:
  name: pod1-dev
  namespace: dev
spec:
  containers:
  - name: boot
    image: registry.cn-hangzhou.aliyuncs.com/button_dev/test:v1.4
    ports:
    - containerPort: 8082
    volumeMounts:
    - name: logs-volume
      mountPath: /var/tmp/logs
  volumes:
    - name: logs-volume
      persistentVolumeClaim:
        claimName: pvc1-dev
---
apiVersion: v1
kind: Pod
metadata:
  name: pod2-dev
  namespace: dev
spec:
  containers:
  - name: boot
    image: registry.cn-hangzhou.aliyuncs.com/button_dev/test:v1.4
    ports:
    - containerPort: 8082
    volumeMounts:
    - name: logs-volume
      mountPath: /var/tmp/logs
  volumes:
    - name: logs-volume
      persistentVolumeClaim:
        claimName: pvc2-dev

---
apiVersion: v1
kind: Pod
metadata:
  name: pod3-dev
  namespace: dev
spec:
  containers:
  - name: boot
    image: registry.cn-hangzhou.aliyuncs.com/button_dev/test:v1.4
    ports:
    - containerPort: 8083
    volumeMounts:
    - name: logs-volume
      mountPath: /var/tmp/logs
  volumes:
    - name: logs-volume
      persistentVolumeClaim:
        claimName: pvc3-dev

在这里插入图片描述
这时我们去查看nfs中不同存储文件中的内容：
在这里插入图片描述

一、配置存储

1、ConfigMap

如果需要存储配置信息，可以使用ConfigMap，它是一种比较特殊的存储卷。

首先定义configmap

vim configmap.yaml

只保存了“loginname”和“password”两项配置

apiVersion: v1
kind: ConfigMap
metadata:
  name: configmap-dev
  namespace: dev
data:
  info: |
    loginname: admin
    password: 123456

创建configmap

kubectl create -f configmap.yaml

在这里插入图片描述
查看其详情：
在这里插入图片描述
创建pod

vim configmap-pod.yaml

apiVersion: v1
kind: Pod
metadata:
  name: pod-configmap
  namespace: dev
spec:
  containers:
  - name: nginx
    image: nginx:1.17.1
    volumeMounts: # 将configmap挂载到目录
    - name: config
      mountPath: /data/configmap/config
  volumes: # 引用configmap
  - name: config
    configMap:
      name: configmap-dev

创建：

kubectl create -f configmap-pod.yaml

在这里插入图片描述
我们进入到容器中，查看挂载目录中的信息：

kubectl exec -it pod-configmap -n dev /bin/bash

可以发现configmap中配置的key映射成文件，value是文件中内容。
在这里插入图片描述

这时我们修改configmap中的内容，并重新创建configmap：
在这里插入图片描述
这时再进入pod中查看，内容也修改过来了：
在这里插入图片描述

2、Secret

对于敏感信息，可以使用Secret对象进行存储。
（1）对敏感信息进行base64编码

echo -n 'admin' | base64 
echo -n '987654' | base64

在这里插入图片描述
（2）创建secret

vim secret.yaml

apiVersion: v1
kind: Secret
metadata:
  name: secret-dev
  namespace: dev
type: Opaque  
data:
  username: YWRtaW4=
  password: OTg3NjU0

在这里插入图片描述
(3)创建pod

vim secret-pod.yaml

apiVersion: v1
kind: Pod
metadata:
  name: pod-secret
  namespace: dev
spec:
  containers:
  - name: nginx
    image: nginx:1.17.1
    volumeMounts: # 将secret挂载到目录
    - name: config
      mountPath: /data/secret/config
  volumes:
  - name: config
    secret:
      secretName: secret-dev

创建好后进入容器中，查看对应的加密信息，已经被自动解密了：
在这里插入图片描述

GreaterBuilder
关注
专栏目录
kubernetes存储
m0_59749940的博客
11-10 1946
Configmap配置管理 Configmap用于保存配置数据，以键值对形式存储；ConfigMap资源提供了向Pod注入配置数据的方法，旨在让镜像和配置文件解耦，以便实现镜像的可移植性和可复用性；典型的使用场景有：填充环境变量的值、设置容器内的命令行参数、填充卷的配置文件 创建ConfigMap的方式有4种：使用字面值创建、使用文件创建、使用目录创建、编写configmap的yaml文件创建 ##使用字面值创建，键值对的方式 ##使用文件创建，文件名为key，文件内容为值 ##使
Kubernetes 系列之 Kubernetes 数据卷
csdn_welearn的博客
09-21 1030
一、Kubernetes 数据卷准备阶段 1 概述 在 Docker 中就有数据卷的概念，当容器删除时，数据也一起会被删除，想要持久化使用数据，需要把主机上的目录挂载到 Docker 中去，在 K8S 中，数据卷是通过 Pod 实现持久化的，如果 Pod 删除，数据卷也会一起删除，k8s 的数据卷是 docker 数据卷的扩展，K8S 适配各种存储系统，包括本地存储 EmptyDir，HostPa...
k8s从入门到放弃-第八章 数据存储
一起学习吧
05-11 504
文章目录8.1基本存储8.1.1 EmptyDir8.1.2 HostPath8.1.3 NFS8.2.1 PV和PVC8.2.2 PV8.2.3 PVC8.2.4生命周期8.3.1 ConfigMap8.3.2 Secret 在前面已经提到，容器的生命周期可能很短，会被频繁地创建和销毁。那么容器在销毁时，保存在容器中的数 据也会被清除。这种结果对用户来说，在某些情况下是不乐意看到的。为了持久化保存容器的数据，kubernetes 引入了Volume的概念。 Volume是Pod中能够被多个容器访问的共享目
【k8s】8、数据存储
努力充实，远方可期
06-20 822
第八章 数据存储 ​ 在前面已经提到，容器的生命周期可能很短，会被频繁地创建和销毁。那么容器在销毁时，保存在容器中的数据也会被清除。这种结果对用户来说，在某些情况下是不乐意看到的。为了持久化保存容器的数据，kubernetes引入了Volume的概念。 ​ Volume是Pod中能够被多个容器访问的共享目录，它被定义在Pod上，然后被一个Pod里的多个容器挂载到具体的文件目录下，kubernetes通过Volume实现同一个Pod中不同容器之间的数据共享以及数据的持久化存储。Volume的生命容
Kubernetes存储
ysf465639310的专栏
03-16 616
Kubernetes存储 在Docker的设计实现中，容器数据是临时性的，当容器销毁或重启时存储在容器内部数据将全部丢失 但实际上很多容器化应用是需要持久化保存数据，K8S的POD和容器一样，重建销毁数据就会丢失， K8S也通过挂载数据卷的方式为POD数据持久能力，这些数据卷以Pod为最小单位进行存储， 通过共享存储或分布式存储在POD之间实现共享。 存储使用场景 K8S是由Master节点以及N...
kubernetes数据存储
weixin_73882207的博客
08-03 193
在kubernetes中，因为容器的生命周期可能很短，会被频繁地创建和销毁。那么容器在销毁时，保存在容器中的数据也会被清除。这种结果对用户来说，在某些情况下是不乐意看到的。为了持久化保存容器的数据，kubernetes引入了Volume的概念。Volume是Pod中能够被多个容器访问的共享目录，它被定义在Pod上，然后被一个Pod里的多个容器挂载到具体的文件目录下，kubernetes通过Volume实现同一个Pod中不同容器之间的数据共享以及数据的持久化存储。
高性能Kubernetes元数据存储KubeBrain的设
11-09
【标题】：“高性能Kubernetes元数据存储KubeBrain的设计思路与落地效果” 【内容详解】： Kubernetes（简称K8s）是当前广泛使用的容器编排系统，它管理着大量集群资源，包括容器、服务、配置等元数据。随着集群...
kubefs:将kubernetes元数据存储挂载为文件系统
03-08
将kubernetes的元数据对象存储挂载为文件系统 正在下载 有几种下载kubefs的选项： 下载 使用go get直接从源代码构建它： go get github.com/configurator/kubefs 注意：这经常被破坏，因为它不仅获取此存储库的...
八、kubernetes 数据存储.pdf
07-22
在探讨Kubernetes数据存储时，首先要明白容器的生命周期具有短暂性，这意味着容器创建和销毁都非常频繁。容器内的数据存储如果不进行特殊处理，通常会在容器销毁时丢失，这对于需要持久化数据的应用场景是无法接受的...
Kubernetes-数据存储-PV和PVC实例
咸鱼很闲
12-12 605
PV和PVC 使用NFS提供存储，此时就要求用户会搭建NFS系统，并且会在yaml配置nfs。由于kubernetes支持的存储系统有很多，要求客户全都掌握，显然不现实。为了能够屏蔽底层存储实现的细节，方便用户使用，kubernetes引入PV和PVC两种资源对象。I PV(Persistent Volume)是持久化卷的意思，是对底层的共享存储的一种抽象。一般情况下PV由kubernetes管理员进行创建和配置，它与底层具体的共享存储技术有关，并通过插件完成与共享存储的对接。 PVC (Persisten
Kubernetes存储系统介绍及机制实现
01-25
主要内容： Kubernetes中存储的应用场景 Kubernetes中几种常见的存储系统 Kubernetes存储的设计与基本架构 Persistent Volume与Persistent Volume Claim v1.9中对存储做了哪些更改
Kubernetes数据存储
最新发布
weixin_72583321的博客
05-27 888
Kubernetes数据存储通过Persistent Volumes (PV)和Persistent Volume Claims (PVC)提供持久化存储解决方案，允许用户根据需求动态申请和管理存储资源，同时利用StorageClasses实现存储类型的动态供应，并结合StatefulSets确保有状态服务的数据一致性和高可用性，支持多种存储类型以满足不同的应用场景和需求。
Kubernetes 数据存储
axibazZ的博客
08-30 398
容器生命周期可能很短，会被频繁的创建和销毁。销毁时，保存在容器中的数据也会被清除。为了持久化容器的数据，kubernetes引入了Volume的概念。 Volume是Pod中能够被多个容器访问的共享目录，它被定义在Pod上，然后被一个Pod里的多个容器挂载到具体的文件目录下，kubernetes通过Volume实现同一个Pod中不同容器之间的数据共享以及数据的持久化存储。Volume的生命容器不与Pod中的单个容器的生命周期相关，当容器终止挥着重启时，Volume中的数据也不会丢失。 kubernete
Kubernetes--数据存储
Hud的博客
05-01 338
1、基础概念 在前面已经提到，容器的生命周期可能很短，会被频繁地创建和销毁。那么容器在销毁时，保存在容器中的数据也会被清除。这种结果对用户来说，在某些情况下是不乐意看到的。为了持久化保存容器的数据，kubernetes引入了Volume的概念。 Volume是Pod中能够被多个容器访问的共享目录，它被定义在Pod上，然后被一个Pod里的多个容器挂载到具体的文件目录下，kubernetes通过Volume实现同一个Pod中不同容器之间的数据共享以及数据的持久化存储。Volu...
Kubernetes笔记(六) Kubernetes 存储
艾希射日
02-14 903
文章目录1. Volumes2. PV & PVC3. Storage Class4. PV 挂载过程5. CSI 插件 操作系统中有 Volume 和 Mount 的概念。 Volume: 表示物理存储的逻辑抽象 Mount：将外部存储挂载到系统、容器中。 为了解决容器的数据存储，Kubernetes 也引入 Volume 的概念。Kubernetes 将 Volume 存储分为了普通的非持久化 Volume 和持久化的 PersistentVolume 两类。 1. Volumes 普通非持
Kubernetes 存储架构体系
小楼一夜听春雨，深巷明朝卖杏花
06-21 408
本文将主要分享以下三方面的内容： Kubernetes 存储体系架构； Flexvolume 介绍及使用； CSI 介绍及使用。
kubernetes存储详解
全栈工程师开发手册（原创）https://github.com/tencentmusic/cube-studio
04-18 1145
1. Volumes 1.1. volume概述 容器上的文件生命周期同容器的生命周期一致，即容器挂掉之后，容器将会以最初镜像中的文件系统内容启动，之前容器运行时产生的文件将会丢失。 Pod的volume的生命周期同Pod的生命周期一致，当Pod被删除的时候，对应的volume才会被删除。即Pod中的容器重启时，之前的文件仍可以保存。 容器中的进程看到的是由其 Docker 镜像和卷...
Kubernetes 存储类型
qq_43164571的博客
02-03 1366
-----------------------------------------------------------------ConfigMap（存储配置文件）ConfigMap 的创建Secret（存储加密信息，例如密码）vloume（共享存储会议）Persistent Volume（PV、PVC） ConfigMap（存储配置文件） ConfigMap 功能在 Kubernetes1.2 版本中引入，许多应用程序会从配置文件、命令行参数或环境变量中读取配置信息。ConfigMap API 给我们提
kubernetes 核心数据结构
01-19
Kubernetes核心数据结构是指在Kubernetes中用于管理和操作资源的基本数据结构。它们是通过GVR（Group, Version, Resource）来标识和访问的。GVR是一个三元组，用于唯一标识一个资源的组、版本和资源类型。 Kubernetes核心数据结构包括但不限于以下几种： 1. Pod（容器组）：Pod是Kubernetes中最小的可调度和可管理的单位，它可以包含一个或多个容器，并共享网络和存储资源。 2. Service（服务）：Service定义了一组Pod的访问方式，它为Pod提供了一个稳定的网络地址和DNS名称。 3. Deployment（部署）：Deployment用于定义Pod的副本数量和更新策略，它可以实现应用的水平扩展和滚动更新。 4. Namespace（命名空间）：Namespace用于将集群中的资源进行逻辑隔离，不同的Namespace之间资源的名称可以重复。 5. ConfigMap（配置映射）：ConfigMap用于存储应用程序的配置信息，可以通过挂载到Pod中的Volume来访问。 6. Secret（密钥）：Secret用于存储敏感信息，如密码、证书等，它也可以通过挂载到Pod中的Volume来访问。 这些核心数据结构可以通过Kubernetes API进行创建、更新和删除操作，通过kubectl命令行工具或Kubernetes客户端库进行访问和管理。
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值