kubernetes--配置管理和持久化存储

ConfigMap

在 Kubernetes 中，ConfigMap 是一种用于存储非机密配置信息的资源对象，它允许将配置信息从应用程序代码中分离出来，从而实现更灵活的配置管理。在 Kubernetes 集群中，应用可以通过 ConfigMap 来注入配置信息，而不需要将配置信息硬编码在容器镜像中。

ConfigMap作用

ConfigMap 的主要作用是提供一种在 Kubernetes 集群中管理配置数据的方式。它支持将配置信息以键值对的形式存储

ConfigMap可以用于：
  1.配置文件
  2.环境变量
  3.命令行参数
  4.配置内容注入到容器内的文件系统

ConfigMap 的特点：
  1.非机密数据：ConfigMap 只存储非机密的数据。如果需要存储机密信息，如密码、密钥等，应使用 Secret。
  2.键值对：ConfigMap 存储的配置信息是键值对格式，可以是简单的字符串，也可以是整个文件内容。
  3.分离配置与代码：将配置信息与应用程序代码分开，使得应用更加灵活和可移植。

ConfigMap 的几种用法
  1.将 ConfigMap 数据作为 环境变量 注入容器。
  2.将 ConfigMap 数据作为 命令行参数 提供给容器启动命令。
  3.将 ConfigMap 数据 挂载为文件 到容器文件系统中。

创建ConfigMap

帮助命令

kubectl create configmap --help  

指定文件夹创建

指定具体的文件创建（使用最多）

使用ConfigMap

ConfigMap 创建好后，可以通过多种方式将其应用到 Pod 中，如环境变量、文件挂载等。

使用方式 1：将 ConfigMap 数据作为环境变量

可以将 ConfigMap 中的键值对直接注入为 Pod 中的环境变量。例如，在以下 Pod 配置中，APP_ENV 和 LOG_LEVEL 是从 ConfigMap 中提取的。

apiVersion: v1
kind: Pod
metadata:
  name: my-app-pod
spec:
  containers:
  - name: my-app-container
    image: nginx
    env:
    - name: APP_ENV
      valueFrom:
        configMapKeyRef:
          name: my-config
          key: APP_ENV
    - name: LOG_LEVEL
      valueFrom:
        configMapKeyRef:
          name: my-config
          key: LOG_LEVEL

在该 Pod 中：
  APP_ENV 环境变量将使用 ConfigMap 中的 APP_ENV 值（即 "production"）。
  LOG_LEVEL 环境变量将使用 ConfigMap 中的 LOG_LEVEL 值（即 "info"）。

使用方式 2：将 ConfigMap 挂载为文件

另一种常见的使用方式是将 ConfigMap 的数据作为文件挂载到容器内。下面的示例展示了如何将 ConfigMap 中的配置信息挂载到容器内的 /etc/config/ 目录中。

apiVersion: v1
kind: Pod
metadata:
  name: my-app-pod
spec:
  containers:
  - name: my-app-container
    image: nginx
    volumeMounts:
    - name: config-volume
      mountPath: /etc/config
  volumes:
  - name: config-volume
    configMap:
      name: my-config

在这个配置中：
my-config 中的每个键值对都会在容器内的 /etc/config 目录下生成一个文件。
  文件名为 APP_ENV 和 LOG_LEVEL，文件内容为各自的值。
  /etc/config/APP_ENV 文件的内容是 "production"。
  /etc/config/LOG_LEVEL 文件的内容是 "info"。

Secret

在 Kubernetes 中，Secret 是一种用于存储和管理敏感信息的资源对象。Secret 允许用户安全地存储和传递诸如密码、OAuth 令牌、SSH 密钥等机密数据，而不会将这些信息直接暴露在应用代码或容器配置中。

Secret 的作用

与 ConfigMap 类似，Secret 也用于将配置信息与应用程序分离，但 Secret 专门用于存储机密数据。Kubernetes 对 Secret 进行了额外的保护措施，确保其安全性。

Secret 的作用如：
  1.以 base64 编码存储数据。
  2.可以限制 Secret 的访问权限，只允许特定 Pod 使用。
  3.Kubernetes 提供了加密存储选项，确保 Secret 在持久化时是加密的。

Secret 通常用于存储以下类型的敏感信息：
  1.密码：数据库、应用的登录密码。
  2.API 密钥：访问外部服务的密钥。
  3.证书：SSL/TLS 证书和私钥。
  4.Token：OAuth 令牌等身份验证令牌。

这种加密方式安全性不高

Secret 的几种类型

Secret 有不同的类型，最常见的类型包括：
  1.Opaque：这是默认的类型，可以存储任意的键值对。
  2.docker-registry：用于存储 Docker 镜像仓库的登录信息。
  3.tls：用于存储 TLS 证书和私钥。

创建 Secret

方式 1：通过 YAML 文件创建

可以使用如下命令手动进行 base64 编码：

echo -n "password123" | base64
# 输出: cGFzc3dvcmQxMjM=

我们可以通过 YAML 文件定义一个 Secret，比如下面的例子用于存储数据库密码和 API 密钥。

apiVersion: v1
kind: Secret
metadata:
  name: my-secret
type: Opaque
data:
  password: cGFzc3dvcmQxMjM=  # base64编码的"password123"
  api-key: YXBpLWtleS1leGFtcGxl  # base64编码的"api-key-example"

password 和 api-key 是 Secret 中的两个键，其值使用了 base64 编码。
在这个例子中，password 实际值为 password123，api-key 实际值为 api-key-example。

方式 2：通过命令行创建

我们也可以通过 kubectl 命令行工具直接创建 Secret。

kubectl create secret generic my-secret --from-literal=password=password123 --from-literal=api-key=api-key-example

这会创建一个名为 my-secret 的 Secret，其中包含两个键值对：password 和 api-key。

使用 Secret

使用方式 1：作为环境变量注入

可以将 Secret 中的值直接注入为容器的环境变量。

apiVersion: v1
kind: Pod
metadata:
  name: my-app-pod
spec:
  containers:
  - name: my-app-container
    image: nginx
    env:
    - name: DB_PASSWORD
      valueFrom:
        secretKeyRef:
          name: my-secret
          key: password
    - name: API_KEY
      valueFrom:
        secretKeyRef:
          name: my-secret
          key: api-key

在这个示例中，DB_PASSWORD 和 API_KEY 环境变量会分别使用 Secret 中的 password 和 api-key 的值。

使用方式 2：挂载 Secret 为文件

Secret 还可以被挂载为容器内部的文件。

apiVersion: v1
kind: Pod
metadata:
  name: my-app-pod
spec:
  containers:
  - name: my-app-container
    image: nginx
    volumeMounts:
    - name: secret-volume
      mountPath: /etc/secret
  volumes:
  - name: secret-volume
    secret:
      secretName: my-secret

在这个配置中，my-secret 中的每个键都会作为一个文件挂载到 /etc/secret 目录下。password 和 api-key 键的内容将会成为 /etc/secret/password 和 /etc/secret/api-key 文件的内容。

使用方式 3：作为 Docker 镜像拉取凭证

如果你需要从私有的 Docker 镜像仓库中拉取镜像，可以创建 docker-registry 类型的 Secret，并将其作为拉取凭证。

创建 Docker 注册表凭证的 Secret：

kubectl create secret docker-registry my-registry-secret \
--docker-server=my-registry.example.com \
--docker-username=my-username \
--docker-password=my-password \
--docker-email=my-email@example.com

然后在 Pod 中使用这个 Secret 作为拉取镜像的凭证：

apiVersion: v1
kind: Pod
metadata:
  name: my-app-pod
spec:
  containers:
  - name: my-app-container
    image: my-registry.example.com/my-image:latest
  imagePullSecrets:
  - name: my-registry-secret

这样 Kubernetes 就会使用 my-registry-secret 中的凭证来从私有镜像仓库拉取镜像。

存储卷

Kubernetes 存储卷(Volumes)为容器提供独立于容器生命周期的数据存取能力。它将容器中的存储数据与容器生命周期解耦，确保即使容器重启或重新调度，数据仍然得以保存。存储卷在Kubernetes中有多种类型，每种适用于不同的存储需求和场景。

存储卷类型

1.临时存储卷

emptyDir

emptyDir:
  用途: 容器存储临时数据。
  特点: 当Pod被删除时，emptyDir中的数据也会被删除。适合临时文件的存储。
  示例: 一个Pod包含一个或多个容器，这些容器都可以共享同一个emptyDir。

示例

apiVersion: v1
kind: Pod
metadata:
  name: emptydir-example
spec:
  containers:
  - name: busybox
    image: busybox
    command: ['sh', '-c', 'sleep 3600']
    volumeMounts:
    - mountPath: /data
      name: mydir
  volumes:
  - name: mydir
    emptyDir: {}

2.节点本地存储卷

hostPath:

hostPath:
  用途: 允许容器访问节点上的文件系统。将Pod所在节点上的文件系统的某目录用作存储卷
  特点: 容器访问的文件或目录直接映射到Kubernetes节点的主机文件系统。常用于调试或日志访问。数据的生命周期与节点相同。
  示例: 将节点上的特定目录挂载到容器内。

配置参数
  path：指定工作节点上的目录路径，必选字段
  type：指定节点之上存储类型

示例

apiVersion: v1
kind: Pod
metadata:
  name: hostpath-example
spec:
  containers:
  - name: busybox
    image: busybox
    command: ['sh', '-c', 'sleep 3600']
    volumeMounts:
    - mountPath: /data
      name: mydir
  volumes:
  - name: mydir
    hostPath:
      path: /mnt/data
      type: DirectoryOrCreate

3.网络存储卷

NFS (Network File System):

NFS(Network File System):
  用途: 允许多个节点共享存储，适合需要多读写的分布式存储场景。
  特点: NFS提供网络共享存储，允许多个Pod挂载相同的共享存储目录。
  示例: 通过挂载NFS共享目录，跨多个Pod共享数据。

配置参数
  server <string>：NFS服务器的IP地址或主机名，必选字段
  path <string>：NFS服务器导出（共享）的文件系统路径，必选字段
  readOnly <boolean>：是否以只读方式挂载，默认为false

示例

apiVersion: v1
kind: PersistentVolume
metadata:
  name: nfs-pv
spec:
  capacity:
    storage: 1Gi
  accessModes:
    - ReadWriteMany
  nfs:
    path: /nfs/data
    server: nfs-server.example.com
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: nfs-pvc
spec:
  accessModes:
    - ReadWriteMany
  resources:
    requests:
      storage: 1Gi
---
apiVersion: v1
kind: Pod
metadata:
  name: nfs-pod
spec:
  containers:
  - name: busybox
    image: busybox
    command: ['sh', '-c', 'sleep 3600']
    volumeMounts:
    - mountPath: /data
      name: nfs-volume
  volumes:
  - name: nfs-volume
    persistentVolumeClaim:
      claimName: nfs-pvc

4.特殊存储卷

configMap和secret

configMap和secret:
  用途: 用于存储配置文件或敏感数据（如密码、令牌等），并挂载到Pod中。
  特点: configMap用于存储非机密数据，secret用于存储机密数据。两者都可以以文件或环境变量的形式挂载到容器中。
  示例: 使用configMap将配置文件挂载到容器。

存储卷规范

定义存储卷

定义存储卷
  ◼ 存储卷对象并非Kubernetes系统一等公民，它需要定义在Pod上
  ◼ 卷本身的生命周期同Pod，但其后端的存储及相关数据的生命周期通常要取决于存储介质

存储卷的配置由两部分组成
  ◼ 通过.spec.volumes字段定义在Pod之上的存储卷列表，它经由特定的存储卷插件并结合特定的存储供给方的访问接口进行定义
  ◼ 嵌套定义在容器的volumeMounts字段上的存储卷挂载列表，它只能挂载当前Pod对象中定义的存储卷

spec:
  volumes:
  - name <string>
    #卷名称标识，仅可使用DNS标签格式的字符，在当前Pod中必须惟一;
    VOL_TYPE <Object>
    #存储卷插件及具体的目标存储供给方的相关配置;
containers:
- name: …
  image: …
  volumeMounts:
  - name <string>
     #要挂载的存储卷的名称，必须匹配存储卷列表中某项的定义;
    mountPath <string>
     #容器文件系统上的挂载点路径;
    readOnly <boolean>
     #是否挂载为只读模式,默认为否;
    subPath <string>
     #挂载存储卷上的一个子目录至指定的挂载点;
    subPathExpr <string>
     #挂载由指定的模式匹配到的存储卷的文件或目录至挂载点;
    mountPropagation <string>
     #挂载卷的传播模式;

持久卷

Kubernetes中的持久卷（Persistent Volume，PV）和持久卷声明（Persistent Volume Claim，PVC）是用于持久化存储的机制，解决容器化应用中存储数据的持久性问题。

pv和pvc

在Pod级别定义存储卷有两个弊端
  1.卷对象的生命周期无法独立于Pod而存在
  2.用户必须要足够熟悉可用的存储及其详情才能在Pod上配置和使用卷

PV和PVC可用于降低这种耦合关系
  PV（Persistent Volume）是集群级别的资源，负责将存储空间引入到集群中，通常由管理员定义
  
  PVC（Persistent Volume Claim）是名称空间级别的资源，由用户定义，
    用于在空闲的PV中申请使用符合过滤条件的PV之一，与选定的PV是“一对一”的关系
    用户在Pod上通过pvc插件请求绑定使用定义好的PVC资源。

PV和PVC的工作流程
  管理员创建PV，并将其作为存储资源提供给集群。
  用户创建PVC，声明所需的存储大小和访问模式。
  K8s查找与PVC匹配的PV，如果找到符合条件的PV，就会将PVC与PV绑定。
  Pod通过挂载PVC来使用PV中的存储资源。

持久卷（Persistent Volume, PV）

持久卷是集群中的存储资源，它由管理员配置并提供给用户使用。PV独立于Pod的生命周期，Pod删除后，数据依然保留。

PV的特点：
  1.独立生命周期：PV的生命周期不受Pod影响，即使Pod被销毁，数据仍然保留在PV中。
  2.存储类型：PV可以对接多种存储后端，如本地磁盘、NFS、GlusterFS、Ceph、AWS EBS等。
  3.存储容量：PV会事先定义存储容量，Pod通过PVC申请相应的存储空间。
  4.访问模式：
      ReadWriteOnce (RWO)：一次只能被一个节点挂载读写。
      ReadOnlyMany (ROX)：可被多个节点挂载为只读。
      ReadWriteMany (RWX)：可被多个节点同时挂载为读写。

定义PV

apiVersion: v1
kind: PersistentVolume
metadata:
  name: my-pv
spec:
  capacity:
    storage: 1Gi
  accessModes:
    - ReadWriteOnce
  persistentVolumeReclaimPolicy: Retain
  hostPath:
    path: "/mnt/data"

这个PV定义了一个大小为1Gi的存储卷，挂载在集群节点的/mnt/data路径，访问模式为ReadWriteOnce，意味着只能被一个节点挂载读写。

持久卷声明（Persistent Volume Claim, PVC）

PVC是用户请求持久存储的方式，PVC可以向集群请求特定大小和访问模式的PV。当用户的PVC与一个符合要求的PV匹配后，PVC就绑定到该PV上。

PVC的特点：
  1.用户级别：PVC由用户创建，表示他们需要的存储需求。
  2.绑定模式：PVC和PV通过匹配容量、访问模式等条件进行绑定。
  3.动态供应：如果没有可用的PV，K8s可以通过StorageClass动态创建PV。

定义PVC

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: my-pvc
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 1Gi

这个PVC请求了1Gi的存储资源，访问模式是ReadWriteOnce，与上面的PV匹配。

在Pod中使用PVC

apiVersion: v1
kind: Pod
metadata:
  name: my-pod
spec:
  containers:
  - name: my-container
    image: nginx
    volumeMounts:
    - mountPath: "/usr/share/nginx/html"
      name: my-storage
  volumes:
  - name: my-storage
    persistentVolumeClaim:
      claimName: my-pvc

这个Pod通过PVC将PV挂载到容器的/usr/share/nginx/html路径上，使用的是前面申请的持久存储。

总结
   1.PV是管理员定义的集群级存储资源，PVC是用户申请存储的方式。
   2.通过PVC与PV的绑定，Pod可以使用持久存储卷，保证即使Pod被删除，数据仍然保留在PV上。
   3.Kubernetes提供的持久卷机制可以很好地满足无状态容器应用对持久数据存储的需求。

原文地址：https://blog.csdn.net/flytalei/article/details/142912750

免责声明：本站文章内容转载自网络资源，如本站内容侵犯了原著者的合法权益，可联系本站删除。更多内容请关注自学内容网（zxcms.com）！