Kubernetes 的配置资源 ConfigMap（01部分）

于 2024-08-12 08:45:00 发布
阅读量621 收藏 13
点赞数 15
分类专栏： Docker与kubernetes 文章标签： kubernetes 容器 linux 运维
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/weixin_44047596/article/details/140973126
版权

作者设置：由于当前各个常用镜像站无法正常代理下载镜像，这篇实验中所用到的镜像建议先从网络下载获取再导入到私仓使用，

或私信后台回复：9521 获取~ ~

目录描述

  • Kubernetes 常见的配置资源介绍

  • ConfigMap 介绍说明

  • ConfigMap 创建方式

  • ConfigMap 使用方式

  • ConfigMap实践案例

一. Kubernetes 常见的配置资源介绍

1.1 配置介绍

生产中所有的应用程序中，都涉及到配置文件，而配置文件经常会有变更，比如: 数据库连接,代码版本号,证书更新等

典型场景：项目经历开发环境、测试环境、预发布环境、线上环境才能完成发布，而每个环境都有定义其独立的各种配置，这些配置手工操作很繁杂，有一些流行的开源项目,比如: Apollo,Nacos,Consul等可以实现配置管理, 还有大公司专门开发了专用配置管理中心，如百度的disconf等。

为容器化应用提供配置信息方法

  • 制作镜像时，提前将定义好的配置文件拷贝进镜像之中

  • 制作镜像时，内置环境变量，在启动容器时通过环境变量向容器传递配置数据

  • 启动容器时，基于存储卷向容器传递配置文件,但需要提前准备外部的存储

注意：对于运行容器中的配置改变，还需要通过应用程序重载相关配置才能生效

kubernetes作为分布式容器调度平台，同样会遇到同样配置变更的问题，这时不可能把资源删除后，重新修改然后再启动生成，这种方法就太繁琐。

kubernetes提供了对pod中容器应用的集中配置管理组件：ConfigMap、Secret、downwardAPI。通过这些组件来实现向pod中的容器注入配置信息的机制。

1.2 配置组件简介

官方的配置组件简介说明 https://kubernetes.io/zh-cn/docs/concepts/configuration/

https://kubernetes.io/zh-cn/docs/concepts/configuration/

1.2.1 Configmap

Configmap是Kubernetes集群中非常重要的一种配置管理资源对象。借助于ConfigMap API向pod中的容器注入配置信息的机制。

ConfigMap不仅仅可以保存环境变量或命令行参数等属性，也可以用来保存整个配置文件或者JSON格式的文件。

各种配置属性和数据以 k/v或嵌套k/v 样式 存在到Configmap中

注意：所有的配置信息都是以明文的方式来进行传递，实现资源配置的快速获取或者更新。

1.2.2 Secret

在Kubernetes集群中，有一些配置属性信息非常敏感，这些信息在传递的过程中，不希望外界能够接触的。所以，Kubernetes提供了一种加密场景中的配置管理资源对象Secret。

它在进行数据传输之前，会对数据进行编码，在数据获取时，会对数据进行解码，从而保证整个数据传输过程的安全。

注意：这些数据是根据不同的应用场景，采用不同的加密机制。

1.2.3 downwardAPI

downwardAPI 为运行在pod中的应用容器提供了一种反向引用。让容器中的应用程序了解所处pod或node的一些基础属性信息。

从严格意义上来说，downwardAPI不是存储卷，它自身就存在。相较于configmap、secret等资源对象需要创建后才能使用，而downwardAPI引用的是Pod自身的运行环境，这些信息在Pod启动的时候就存在了

二、ConfigMap 介绍说明

Kubernetes提供了对pod中容器应用的集中配置管理组件：ConfigMap。通过ConfigMap来实现、借助于ConfigMap API向pod中容器中注入配置信息的机制。

可以把configmap理解为Linux系统中的/etc目录，专门用来存储配置文件的目录。

Kubernetes借助于ConfigMap对象实现了将配置信息从容器镜像中解耦，从而增强了工作负载的可移樟性、使其配置更易于更改和管理并避免了将配置数据硬编码到Pod配置清单中

注：ConfigMap不仅仅可以保存单个属性，也可以用来保存整个配置文件。

虽然configmap可以对各种应用程序提供定制配置服务，但是一般不用它来替代专门的配置文件，从Kubernetes v1.19版本开始，ConfigMap和Secret支持使用immutable字段创建不可变实例。

Configmap 属于名称空间级别

基本属性：

root@master1ha1:~# kubectl explain cm
   binaryData #二进制数据
   data   #文本数据，支持变量和文件
   immutable <boolean>  #设为true，不能被修改只能删除，默认为nil可以随时被修改
#注意：基于data的方式传递信息的话，会在pod的容器内部生成一个单独的数据文件

数据的表现样式：

#简单数据：
属性名称key: 属性值value   #单行配置内容，一般保存变量，参数等
文件名：单行内容           #配置文件如果有一行，也使用此方式，key为文件名，value为文件内容
#多行文件数据格式1：     
文件名称1: |     #注意：| 是"多行键值"的标识符
 文件内容行1    #内容大小不能超过1M
 文件内容行2
 ......
文件名称2: |     #注意：| 是"多行键值"的标识符
 文件内容行1    #内容大小不能超过1M
 文件内容行2
 ......

对于configmap这种资源类型的创建，与Kubernetes的其他资源对象的创建方式一样，主要涉及到两种方式：

  • 命令行工具：配置中有大量简单的键值对时建议使用

  • 资源定义文件：配置为大量文本内容时建议使用，此方式需要事先准备在资源清单元文件中加入配置文件内容

注意:

  • 如果Pod是以subPath 的形式挂载ConfigMap和Secret,那么Pod是不会感知到ConfigMap和Secret的更新。

  • 如果Pod 的变量来自于ConfigMap和Secret中定义的内容,那么ConfigMap和Secret更新后，也不会更新Pod中的变量。

三、ConfigMap 创建和更新

3.1 命令行创建方式

3.1.1 命令行创建方式说明

命令参数

#查看创建命令帮助
root@master1ha1:~# kubectl create configmap -h
#参数详解:
--from-literal=key1=value1        #以命令行设置键值对的方式配置数据
--from-env-file=/PATH/TO/FILE       #以环境变量专用文件的方式配置数据
--from-file=[key=]/PATH/TO/FILE #以配置文件的方式创建配置数据，如不指定key，FILE名称
为key名
--from-file=/PATH/TO/DIR        #以配置文件所在目录的方式创建配置数据
--dry-run=client -o yaml            #测试运行并显示cm内容

#查看configmap
kubectl create configmap <cm_name> -n <namespace> [-o yaml] --dry-run=client
kubectl get configmap <cm_name> -n <namespace>
kubectl describe configmap <cm_name> -n <namespace>

#删除configmap
kubectl delete configmap <cm_name> [-n <namespace>]
3.1.2 命令行创建方式案例

范例：命令行创建基于key:value形式的CM

#在使用kubectl创建的时候，通过在命令行直接传递键值对创建
root@master1ha1:~# kubectl create configmap cm-test1 --from-literal=key1='value1' --from-literal=key2='value2'
configmap/cm-test1 created
root@master1ha1:~# kubectl get cm
NAME               DATA   AGE
cm-test1           2      11s
kube-root-ca.crt   1      25d

root@master1ha1:~# kubectl get cm cm-test1 -o yaml
apiVersion: v1
data:
  key1: value1
  key2: value2
kind: ConfigMap
metadata:
  creationTimestamp: "2024-07-22T11:48:27Z"
  name: cm-test1
  namespace: default
  resourceVersion: "139551"
  uid: fce0ffc0-2ad5-4b99-bdf5-a0f95882f19d

root@master1ha1:~# kubectl describe cm cm-test1 
Name:         cm-test1
Namespace:    default
Labels:       <none>
Annotations:  <none>

Data
====
key1:
----
value1
key2:
----
value2

BinaryData
====

Events:  <none>

#删除CM
root@master1ha1:~# kubectl delete cm cm-test1 
configmap "cm-test1" deleted

范例: 命令行创建基于key/value形式的CM

#创建CM
root@master1ha1:~# kubectl create configmap pod-test-config --from-literal=host="127.0.0.1" --from-literal=port="8888"
configmap/pod-test-config created

#验证创建成功
root@master1ha1:~# kubectl get cm
NAME               DATA   AGE
kube-root-ca.crt   1      34d
pod-test-config    2      18s

#显示CM内容
root@master1ha1:~# kubectl get cm pod-test-config -o yaml
apiVersion: v1
data:
  host: 127.0.0.1
  port: "8888"
kind: ConfigMap
metadata:
  creationTimestamp: "2024-07-31T09:56:35Z"
  name: pod-test-config
  namespace: default
  resourceVersion: "161838"
  uid: 7b49ae67-4d64-4f2d-8c47-882c314f5ec7
 
 #删除CM
root@master1ha1:~# kubectl delete cm pod-test-config 
configmap "pod-test-config" deleted

范例: 命令行创建基于环境变量文件的CM

#如果变量较多，使用上面方式一个个的设定环境变量太繁琐，可以全部添加到环境变量文件中然后基于它来创建CM。
#定制环境变量文件
root@master1ha1:~# cat > env
key1=value1
key2=value2
^C
root@master1ha1:~# cat env 
key1=value1
key2=value2
#注意：env文件中所有的配置项以 "属性名=属性值" 格式定制
#将所有环境变量添加到到configmap中

root@master1ha1:~# kubectl create configmap cm-test2 --from-env-file=env
configmap/cm-test2 created
root@master1ha1:~# kubectl get cm cm-test2 -o yaml
apiVersion: v1
data:
  key1: value1
  key2: value2
kind: ConfigMap
metadata:
  creationTimestamp: "2024-07-31T10:06:01Z"
  name: cm-test2
  namespace: default
  resourceVersion: "162597"
  uid: 6ae54301-d753-4949-9e06-bdfba7c87cf9

root@master1ha1:~# kubectl describe cm cm-test2 
Name:         cm-test2
Namespace:    default
Labels:       <none>
Annotations:  <none>

Data
====
key1:
----
value1
key2:
----
value2

BinaryData
====

Events:  <none>

#删除CM
root@master1ha1:~# kubectl delete cm cm-test2 
configmap "cm-test2" deleted

范例：命令行创建基于配置文件的CM

#直接将多个配置文件创建为一个ConfigMap
root@master1ha1:~# cat conf.d/*
[app1]
config1
[app2]
config2
[app3]
config3
root@master1ha1:~# ls conf.d/
app1.conf  app2.conf  app3.conf

root@master1ha1:~# kubectl create configmap cm-test3 --from-file=./conf.d/app1.conf --from-file=./conf.d/app2.conf 
configmap/cm-test3 created
root@master1ha1:~# kubectl get cm cm-test3 -o yaml
apiVersion: v1
data:
  app1.conf: |
    [app1]
    config1
  app2.conf: |
    [app2]
    config2
kind: ConfigMap
metadata:
  creationTimestamp: "2024-07-31T10:16:21Z"
  name: cm-test3
  namespace: default
  resourceVersion: "163407"
  uid: bf4dc865-70ef-443a-883b-c1df3af54022
root@master1ha1:~# kubectl describe cm cm-test3 
Name:         cm-test3
Namespace:    default
Labels:       <none>
Annotations:  <none>

Data
====
app1.conf:
----
[app1]
config1

app2.conf:
----
[app2]
config2


BinaryData
====

Events:  <none>

#删除CM
root@master1ha1:~# kubectl delete cm cm-test3 
configmap "cm-test3" deleted

范例: 命令行创建基于目录的CM

root@master1ha1:~# cat conf.d/*
[app1]
config1
[app2]
config2
[app3]
config3
root@master1ha1:~# ls conf.d/
app1.conf  app2.conf  app3.conf

#直接将一个目录下的所有配置文件创建为一个ConfigMap
root@master1ha1:~# kubectl create configmap cm-test4 --from-file=./conf.d/
configmap/cm-test4 created

#结果显示：多个文件之间，属性名是文件名，属性值是文件内容
root@master1ha1:~# kubectl get cm cm-test4 -o yaml
apiVersion: v1
data:
  app1.conf: |
    [app1]
    config1
  app2.conf: |
    [app2]
    config2
  app3.conf: |
    [app3]
    config3
kind: ConfigMap
metadata:
  creationTimestamp: "2024-07-31T10:19:42Z"
  name: cm-test4
  namespace: default
  resourceVersion: "163668"
  uid: a32a06f3-2b62-453b-9580-c62831bd97a3

#结果显示：多个文件之间，属性名是文件名，属性值是文件内容
root@master1ha1:~# kubectl describe cm cm-test4 
Name:         cm-test4
Namespace:    default
Labels:       <none>
Annotations:  <none>

Data
====
app1.conf:
----
[app1]
config1

app2.conf:
----
[app2]
config2

app3.conf:
----
[app3]
config3


BinaryData
====

Events:  <none>

#删除CM
root@master1ha1:~# kubectl delete cm cm-test4 
configmap "cm-test4" deleted

3.2 资源清单文件创建方式

3.2.1 资源清单文件格式说明

资源清单文件命令格式

#清单文件格式
apiVersion: v1
kind: ConfigMap
metadata:
 name: cm_name
  namespace: default
data:
 key: value   #配置信息如果只有一行，也使用此方式，使用卷挂载时，key即为文件名，value为文件
内容
 文件名: |     #配置文件有多行使用此方式
 文件内容行1
 文件内容行2
 .....
#注意：CM的清单文件没有spec信息，而是data
#命令式: 
kubectl create -f /path/file
#声明式
kubectl apply -f /path/file

注意：此方式将配置文件内容写入清单文件，很不方便，推荐如下方式解决

  • 先在命令行执行时指定配置文件的方式创建 CM

  • 通过 kubectl get cm <CM_NAME> -o yaml 方式导出资源清单文件，

  • 调整yaml资源清单文件，后续可重复使用

3.2.2 资源清单文件创建方式案例

操作示范

#资源定义文件
root@master1ha1:~# vim storage-configmap-test.yaml
apiVersion: v1
kind: ConfigMap
metadata:
        name: config-test
data:
        author: ddddhh
        file.conf: |
                [class]
                linux
                go
                java
#注释：data：部分内容是真正的配置项，有两种格式：
#author: 是Key/value格式
#file.conf: | 是文件格式

#创建资源对象
root@master1ha1:~# kubectl apply -f storage-configmap-test.yaml 
configmap/config-test created

#查看
root@master1ha1:~# kubectl get cm
NAME               DATA   AGE
config-test        2      32s
kube-root-ca.crt   1      35d

root@master1ha1:~# kubectl describe cm config-test 
Name:         config-test
Namespace:    default
Labels:       <none>
Annotations:  <none>

Data
====
author:
----
ddddhh
file.conf:
----
[class]
linux
go
java


BinaryData
====

Events:  <none>
#结果显示：里面定义了两种类型的配置属性：文件样式和数据样式，都是以kv样式展示，属性名key和属性值
value中间使用 "----" 来隔开
#可以在线修改
root@master1ha1:~# kubectl edit cm config-test 

# Please edit the object below. Lines beginning with a '#' will be ignored,
# and an empty file will abort the edit. If an error occurs while saving this file will be
# reopened with the relevant failures.
#
apiVersion: v1
data:
  author: ddddhh
  file.conf: |
    [class]
    linux
    go
    java
kind: ConfigMap
metadata:
  annotations:
    kubectl.kubernetes.io/last-applied-configuration: |
      {"apiVersion":"v1","data":{"author":"ddddhh","file.conf":"[class]\nlinux\ngo\njava\n"},"kind":"ConfigMap","metadata":{"annotations":{},"name":"config-test","namespace":"default"}}
  creationTimestamp: "2024-08-01T07:46:13Z"
  name: config-test
  namespace: default
  resourceVersion: "165890"
  uid: 7142f41e-6efc-47e0-ae65-d73907e5df4f

#删除
root@master1ha1:~# kubectl delete cm config-test 
configmap "config-test" deleted

操作示范：只读的configmap

root@master1ha1:~# vim storage-configmap-immutable-test.yaml 
apiVersion: v1
kind: ConfigMap
metadata:
        name: cm-immutable-test
data:
        author: ddddhh
        file.conf: |
                [class]
                linux
                go
                java
immutable: true
root@master1ha1:~# kubectl apply -f  storage-configmap-immutable-test.yaml 
configmap/cm-immutable-test created
root@master1ha1:~# kubectl get cm 
NAME                DATA   AGE
cm-immutable-test   2      62s
kube-root-ca.crt    1      35d

#在线修改configmap提示出错
root@master1ha1:~# kubectl edit cm cm-immutable-test 
error: configmaps "cm-immutable-test" is invalid
A copy of your changes has been stored to "/tmp/kubectl-edit-3644066815.yaml"
error: Edit cancelled, no valid changes were saved.

#可以删除
root@master1ha1:~# kubectl delete cm cm-immutable-test 
configmap "cm-immutable-test" deleted
root@master1ha1:~# kubectl get cm
NAME               DATA   AGE
kube-root-ca.crt   1      35d
3.2.3 在线更新 configmap

操作示范

#创建 configmap
root@master1ha1:~# kubectl create cm cm-nginx-conf --from-file=nginx.conf

#修改configmap方法1 （主用方式推荐）
#早期版本中nginx.conf内容如果不大,多行内容显示在一行,不方便修改,但如果过大,此方式只能显示大小,而非内容,所以不能修改,新版无此问题
root@master1ha1:~# kubectl edit cm cm-nginx-conf

#修改configmap方法2
#通过将在线配置导出到一个yaml格式中修改后再apply
root@master1ha1:~# kubectl get cm cm-nginx-conf -o yaml > cm-config-conf.yaml
root@master1ha1:~# vim cm-config-conf.yaml
root@master1ha1:~# kubectl apply -f cm-config-conf.yaml

#修改configmap方法3
#修改配置
root@master1ha1:~# vim nginx.conf
root@master1ha1:~# kubectl create cm cm-nginx-conf --from-file=nginx.conf --dry-run=client -o yaml |kubectl apply -f -

四、 ConfigMap 使用

使用ConfigMap主要有两种方式：

  • 通过环境变量的方式直接传递pod

  • 使用volume的方式挂载入到pod内的文件中

注意：

  • ConfigMap必须在Pod之前创建

  • 与ConfigMap在同一个namespace内的pod才能使用ConfigMap，即ConfigMap不能跨命名空间

调用。

  • ConfigMap通常存放的数据不要超过1M

  • CM 支持实时更新，在原来的pod里面直接看到效果

4.1 通过环境变量的方式直接传递 Pod

引用ConfigMap对象上特定的key，以valueFrom赋值给Pod上指定的环境变量。

也可在Pod上使用envFrom一次性导入ConfigMap对象上的所有的key-value,key(可以统一附加特定前缀）即为环境变量,value自动成为相应的变量值。

环境变量是容器启动时注入的，不会随CM更改而发生变化,即一次性加载configmap。

通过环境变量脚本的方式，预处理这些配置信息。

注意：环境变量的名称如果要用横线的话，最好使用下划线 _环境变量格式

  1. 方式1：env 对指定的变量一个一个赋值

kubectl explain pod.spec.containers.env
 name  #手工定制环境变量时，设置环境变量的名称，必选字段
 value #手工定制环境变量时，直接设置环境变量的属性值，不通过CM获取配置，可选字段
 valueFrom  #手工定制环境变量时，设置环境变量的属性来源位置，可以支持从CM,Secret,downwordAPI获取

kubectl explain pod.spec.containers.env.valueFrom.configMapKeyRef
   name   #引用哪个configmap
   key    #引用哪个configmap中的key
   optional  #如果设置为false，标识该项是必选项，如果设置为true标识这个key是可选的。

#此方式实现过程
1）容器中自定义环境变量名
2）根据CM的名称和Key名，找到对应的value
3) 再将value赋值给容器的环境变量

  1. 方式2：envFrom 使用CM的所有变量实现对变量的批量赋值，此方式生产更为推荐

kubectl explain pod.spec.containers.envFrom
 configMapRef #ConfigMap对象中的特定Key
 secretKeyRef #Secret对象中的特定Key
 prefix #为ConfigMap中的每个属性都添加前缀标识

#此方实现过程
1）容器中自定义环境变量名，并且和CM的key同名
2）找到指定的CM中所有Key名，将值批量直接赋值给容器中相同名称的变量

4.2 使用volume的方式挂载入到pod内的文件中

在Pod上将 configMap对象引用为存储卷，而后整体由容器mount至某个目录下, key转为文件名,value即为相应的文件内容

在Pod上定义configMap卷时，仅引用其中的部分key，而后由容器mount至目录下

在容器上仅mount configMap卷上指定的key

容器中挂载的Volume数据可以根据时间戳机制,和ConfigMap 同步更新,即configmap变更后会自动加载

推荐滚动升级pod的方式来让ConfigMap内容变化生效

volume 格式

#指定卷信息，引用CM
kubectl explain pod.spec.volumes
 name: volume_name  #指定volume名
 configMap：
   name: CM_name    #指定CM的名称
   
#挂载卷到容器内的目录
kubectl explain pod.spec.containers.volumeMounts
 volumeMounts:
  - name: CM_name    #指定CM的名称
   mountPath; /path #容器内的挂载点

最后：

下章ConfigMap实践案例部分

最后~欢迎关注我！ @Linux学习的那些事儿

我的个人资源整理，满满都是干货： → 可按需访问领取

200T免费资料，持续发布中... icon-default.png?t=N7T8https://vlink.cc/route

如果本文对你有帮助，欢迎点赞、收藏、转发给朋友，让我有持续创作的动力！

Linux学习的那些事儿
关注
  • 15
    点赞
  • 踩
  • 13
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 0
    评论
专栏目录
Kubernetes ConfigMap
01-07
ConfigMap 是用来存储配置文件的 Kubernetes 资源对象，所有的配置内容都存储在 etcd 中。它可以被用来保存单个属性，也可以用来保存整个配置文件或者 JSON 二进制对象。ConfigMap API 资源提供了将配置数据注入容器...
k8s-config：Kubernetes配置清单
02-19
在Kubernetes中，这个文件可能包含了多个资源定义，如Deployment、Service、PersistentVolume、ConfigMap、Secret等，这些资源定义了应用的容器镜像、副本数量、服务端口、数据持久化策略以及环境变量等关键信息。...
kubernetes-ConfigMap配置管理详解
m0_71163619的博客
07-17 952
ConfigMap是API对象，用于存放明文(非机密性)数据保存到键值对中，可以使用环境变量、命令行参数或者存储卷方式应用到Pod中，ConfigMap相当于Pod中程序的配置文件，通过修改ConfigMap内容来修改程序的配置。
配置Kubernetes资源管理Secret与ConfigMap
qq_64612585的博客
06-03 1130
在 K8s 中，Secret 是用于存储敏感信息的对象，如密码、token 令牌和 SSH 密钥。这类数据虽然也可以存放在 Pod 或者镜像中，但是放在 Secret 中是为了更方便的控制如何使用数据，并减少暴露的风险；这些信息以加密形式存储，并且只能被授权的 Pod 访问。通过使用 Secret，可以更安全地管理应用程序所需的敏感数据。也就是说 K8s 解决了我们和 Docker 使用的一些弊端，比如：环境变量、存储问题都要去重新编辑 Dockerfile，而且密码还是明文的。
【Kubernetes资源篇】ConfigMap配置管理中心详解
热门推荐
秦子腾
07-01 1万+
ConfigMap是API对象，用于存放明文(非机密性)数据保存到键值对中，可以使用环境变量、命令行参数或者存储卷方式应用到Pod中，ConfigMap相当于Pod中程序的配置文件，通过修改ConfigMap内容来修改程序的配置。
11. kubernetes资源——configmap配置映射
u010198709的博客
07-29 346
【代码】11. kubernetes资源——configmap配置映射。
Kubernetes配置管理 ConfigMap
zhangshenglu1的博客
05-19 1913
通过指定文件创建，即将一个配置文件创建为一个ConfigMap，通过直接在命令行中指定configmap参数创建，即。如果修改了value, 那么容器内部会不会更新?2.验证对应的pod里的变化,一段时间后会改变(1.编辑修改对应的configmap。通过一个文件内多个键值对，
Kubernetes配置与密钥管理 ConfigMap&Secret
weixin_44093727的博客
02-08 684
介绍了configmap和secret是什么并如何使用
Kubernetes 杂谈之 configmap \n的问题
wzj_110的博客
03-02 803
【代码】Kubernetes 杂谈之 configmap \n的问题。
Kubernetes配置资源管理 Secret与ConfigMap
wys_jj的博客
06-03 848
在 K8s 中，Secret 是用于存储敏感信息的对象，如密码、token 令牌和 SSH 密钥。这类数据虽然也可以存放在 Pod 或者镜像中，但是放在 Secret 中是为了更方便的控制如何使用数据，并减少暴露的风险；这些信息以加密形式存储，并且只能被授权的 Pod 访问。通过使用 Secret，可以更安全地管理应用程序所需的敏感数据。也就是说 K8s 解决了我们和 Docker 使用的一些弊端，比如：环境变量、存储问题都要去重新编辑 Dockerfile，而且密码还是明文的。
Kubernetes—配置管理ConfigMap
whyrookie的博客
01-26 696
1 ConfigMap介绍 1.1 概述   在部署应用程序时，我们都会涉及到应用的配置，在容器中，如Docker容器中，如果将配置文件打入容器镜像，这种行为等同于写死配置，每次修改完配置，镜像就得重新构建。当然，我们也可以通过挂载包含该文件的卷进行配置管理和修改。而在k8s中，我们要讲一种更好的方式，即ConfigMap，这种资源对象的出现，更是极大的方便了应用程序的配置管理。   ConfigMap是一个或多个key/value的形式保存在k8s中，内部可以管理变量也可以管理完整的配置文件内容...
【K8s】专题五（1）：Kubernetes 配置之 ConfigMap
行者Sun1989的博客
06-12 711
Kubernetes 专题 - 配置之 ConfigMap
Kubernetes资源清单模板
11-19
Kubernetes支持多种资源类型，如工作负载类（Pod、ReplicaSet、ReplicationController、Deployment、StatefulSet、DaemonSet）、服务发现和负载均衡（Service、Ingress）、配置和存储（Volume、Persistent Volume、...
ConfigMap、Secret
01-20
在Kubernetes中，ConfigMap和Secret是两种关键的资源对象，它们主要被设计用来管理和传递应用程序所需的配置信息和敏感数据。这两个概念的出现主要是为了解决在容器化环境中配置管理和安全性的挑战。 首先，让我们...
zeebe-kubernetes：Zeebe Kubernetes配置
02-05
总结，Zeebe-Kubernetes配置涉及到Kubernetes的多种核心组件和概念，如Deployment、StatefulSet、Service、PV/PVC、ConfigMap和Secret。通过合理的配置，可以在Kubernetes上构建一个高可用、可扩展的Zeebe集群，实现...
K8S Operator
mqiqe的专栏
08-07 856
定义：K8S Operator是一种基于Kubernetes自定义资源（CR）和控制器概念的扩展软件，用于管理特定应用的生命周期和配置。功能自动化管理：通过定义自定义资源和Operator来自动管理应用程序的生命周期和配置。与K8S原生组件集成：Operator可与K8S原生的Controller、Scheduler等组件进行协同工作，提供更加灵活和可靠的管理方式。扩展K8S：借助Operator，可以在K8S集群上扩展新的资源类型，满足更多定制化的需求。
k8s环境使用cronjob对mysql8进行备份
最新发布
tingting0119的博客
08-09 178
在k8s环境通过cronjob对mysql进行定时备份，mysql是部署在k8s环境中
【从问题中去学习k8s】k8s中的常见面试题（夯实理论基础）（二）
zerotoall的博客
08-09 231
思考一下问题： 6、简述Kubernetes常见的部署方式？ 7、简述Kubernetes如何实现集群管理？ 8、简述Kubernetes的优势、适应场景及其特点？ 9、简述Kubernetes的缺点或当前的不足之处？ 10、简述Kubernetes相关基础概念？ 参考答案：
Kubernetes之pod的基本概念
qq_63627848的博客
08-08 995
Pod 是可以在 Kubernetes 中创建和管理的、最小的可部署的计算单元。Pod（就像豌豆荚中）是一组（一个或多个） 容器；这些容器共享存储、网络、以及怎样运行这些容器的规约。Pod 中的内容总是并置（colocated）的并且一同调度，在共享的上下文中运行。Pod 所建模的是特定于应用的 “逻辑主机”，其中包含一个或多个应用容器， 这些容器相对紧密地耦合在一起。在非云环境中，在相同的物理机或虚拟机上运行的应用类似于在同一逻辑主机上运行的云应用。运行单个容器的 Pod。
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

Linux学习的那些事儿

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付：¥1
获取中
扫码支付

您的余额不足，请更换扫码支付或充值

打赏作者

实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

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

余额充值