Kubernetes-使用ConfigMap抽取配置

本文介绍了如何在Kubernetes中使用ConfigMap进行应用配置的管理和自动更新。通过创建ConfigMap,将redis配置文件载入Kubernetes集群,并将ConfigMap挂载到Pod中,实现配置的动态更新。当修改ConfigMap后,虽然配置文件内容会更新,但Pod需要重启以应用新的配置。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

ConfigMap
抽取应用配置,并且可以自动更新
1、redis示例
1、把之前的配置文件创建为配置集

# 创建配置,redis保存到k8s的etcd;
kubectl create cm redis-conf --from-file=redis.conf
[root@bigdata01 k8s]# vi redis.conf
[root@bigdata01 k8s]# cat redis.conf 
appendonly yes
[root@bigdata01 k8s]# kubectl create cm redis-conf --from-file=redis.conf 
configmap/redis-conf created
[root@bigdata01 k8s]# kubectl get cm
NAME               DATA   AGE
kube-root-ca.crt   1      10d
redis-conf         1      7s
[root@bigdata01 k8s]# kubectl get cm redis-conf -oyaml
apiVersion: v1
data:
  redis.conf: |
    appendonly yes
kind: ConfigMap
metadata:
  creationTimestamp: "2022-03-05T07:47:52Z"
  managedFields:
  - apiVersion: v1
    fieldsType: FieldsV1
    fieldsV1:
      f:data:
        .: {}
        f:redis.conf: {}
    manager: kubectl-create
    operation: Update
    time: "2022-03-05T07:47:52Z"
  name: redis-conf
  namespace: default
  resourceVersion: "195660"
  uid: 187c182d-eedc-49da-b498-207a9ffbed3e


精简一下就是这样啦~

apiVersion: v1
data:  #data是所有真正的数据,key:默认是文件名   value:配置文件的内容
  redis.conf: |
    appendonly yes
kind: ConfigMap
metadata:
  name: redis-conf
  namespace: default

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

apiVersion: v1
kind: Pod
metadata:
  name: redis
spec:
  containers:
  - name: redis
    image: redis
    command:
      - redis-server
      - "/redis-master/redis.conf"  #指的是redis容器内部的位置
    ports:
    - containerPort: 6379
    volumeMounts:
    - mountPath: /data
      name: data
    - mountPath: /redis-master
      name: config
  volumes:
    - name: data
      emptyDir: {}
    - name: config
      configMap:
        name: redis-conf
        items:
        - key: redis.conf
          path: redis.conf
[root@bigdata01 k8s]# vi redis.yaml
[root@bigdata01 k8s]# ls
calico.yaml  dash.yaml  images.sh  ingress.yaml  origin_store.yaml  redis.conf  redis.yaml
[root@bigdata01 k8s]# kubectl apply -f redis.yaml 
pod/redis created
[root@bigdata01 k8s]# 

[root@bigdata01 k8s]# kubectl edit cm  redis-conf
configmap/redis-conf edited
[root@bigdata01 k8s]# kubectl apply -f redis.yaml 
pod/redis created

在这里插入图片描述修改ConfigMap

kubectl exec -it redis -- redis-cli

127.0.0.1:6379> CONFIG GET appendonly
127.0.0.1:6379> CONFIG GET requirepass

检查配置是否更新

kubectl exec -it redis -- redis-cli

127.0.0.1:6379> CONFIG GET maxmemory
127.0.0.1:6379> CONFIG GET maxmemory-policy

检查指定文件内容是否已经更新
修改了CM。Pod里面的配置文件会跟着变

配置值未更改,因为需要重新启动 Pod 才能从关联的 ConfigMap 中获取更新的值。
原因:我们的Pod部署的中间件自己本身没有热更新能力

<think>我们正在比较两个依赖:`spring-cloud-starter-kubernetes-fabric8-config` 和 `spring-cloud-starter-kubernetes-client-config`。这两个依赖都是 Spring Cloud Kubernetes 项目的一部分,用于在 Kubernetes 环境中获取配置(如 ConfigMap 和 Secret)。它们的主要区别在于底层使用Kubernetes 客户端库不同。 ### 核心区别 1. **底层客户端库**: - **`spring-cloud-starter-kubernetes-fabric8-config`**:使用 [Fabric8 Kubernetes Client](https://github.com/fabric8io/kubernetes-client) 作为底层客户端。 - **`spring-cloud-starter-kubernetes-client-config`**:使用 [Kubernetes Java Client](https://github.com/kubernetes-client/java)(官方客户端)作为底层客户端。 2. **项目背景**: - Fabric8 是一个开源的集成平台,其 Kubernetes 客户端是社区驱动的,提供了丰富的功能和易用的 API。 - Kubernetes Java Client 是 Kubernetes 社区官方维护的 Java 客户端,与 Kubernetes 版本同步更新,遵循 Kubernetes 的发布节奏。 3. **依赖管理**: - 两个依赖的 Maven Group ID 和 Artifact ID 不同,因此不能直接互换使用- 在 Spring Cloud Kubernetes 项目中,这两个依赖是并行的选择,功能上基本一致,但底层实现不同。 ### 功能对比 | 功能特性 | Fabric8 配置客户端 | Kubernetes Java 配置客户端 | |----------|-------------------|--------------------------| | 配置来源 | ConfigMap, Secret | ConfigMap, Secret | | 自动刷新 | 支持(通过 Watcher) | 支持(通过 Watcher) | | 与 Spring Cloud 集成 | 是 | 是 | | 权限要求 | 对 ConfigMap 和 Secret 的 get、list、watch 权限 [^3] | 对 ConfigMap 和 Secret 的 get、list、watch 权限 [^3] | | 服务发现 | 通过 `spring-cloud-starter-kubernetes-fabric8` 提供 | 通过 `spring-cloud-starter-kubernetes-client` 提供 | ### 使用场景 1. **选择 `spring-cloud-starter-kubernetes-fabric8-config` 的情况**: - 如果你的项目已经在使用 Fabric8 客户端(例如,使用其其他功能如自定义资源操作),为了保持一致性,可以选择此依赖。 - 如果你需要一些 Fabric8 客户端特有的高级特性(例如,更简洁的 DSL 或扩展功能)。 - 历史项目升级:旧版本 Spring Cloud Kubernetes 可能默认使用 Fabric8,升级时可能选择延续使用。 2. **选择 `spring-cloud-starter-kubernetes-client-config` 的情况**: - 如果你倾向于使用 Kubernetes 官方维护的 Java 客户端,以获得更好的兼容性和长期支持。 - 新项目:Spring Cloud Kubernetes 从某个版本开始(如 2020.0.x 之后)加强了对官方客户端的支持,新项目可能更推荐使用官方客户端。 - 如果你的组织要求使用官方组件。 ### 配置示例 无论选择哪个依赖,配置方式类似。以下是一个使用 `spring-cloud-starter-kubernetes-client-config` 的示例: ```yaml spring: application: name: my-app cloud: kubernetes: config: # 指定要加载的 ConfigMap 名称 name: my-config # 指定命名空间(可选,默认使用 Pod 所在的命名空间) namespace: my-namespace # 启用自动刷新 reload: enabled: true mode: event ``` 对于 Fabric8 配置客户端,配置类似,但需要注意依赖的不同。 ### 权限设置 无论使用哪个客户端,都需要在 Kubernetes 中为 Pod 配置相应的 RBAC 权限。例如,以下是一个 Role 的示例,允许对 ConfigMap 和 Secret 的访问: ```yaml kind: Role apiVersion: rbac.authorization.k8s.io/v1 metadata: namespace: my-namespace name: config-reader rules: - apiGroups: [""] resources: ["configmaps", "secrets"] verbs: ["get", "list", "watch"] ``` 然后通过 RoleBinding 将 Role 绑定到 ServiceAccount。 ### 迁移注意事项 如果要从 Fabric8 迁移到官方客户端(或反之): 1. **依赖变更**:替换 Maven 依赖。 2. **配置属性**:大部分配置属性是相同的,但有一些细微差别(例如,命名空间配置属性在官方客户端中可能使用 `spring.cloud.kubernetes.client.namespace` 而 Fabric8 可能使用 `spring.cloud.kubernetes.config.namespace`,具体需参考文档)。 3. **客户端行为**:虽然功能一致,但底层客户端的错误处理和日志输出可能不同,需要测试。 ### 结论 - **功能等价**:两个依赖在功能上基本一致,都能实现从 Kubernetes 读取配置- **选择建议**: - 新项目:推荐使用 `spring-cloud-starter-kubernetes-client-config`(官方客户端),因为它是 Kubernetes 社区官方维护的,长期支持更有保障。 - 现有项目:如果已经在使用 Fabric8,可以继续使用 `spring-cloud-starter-kubernetes-fabric8-config`,避免不必要的迁移。 ### 相关问题 1. 如何为 Spring Cloud Kubernetes 配置客户端设置 RBAC 权限? 2. Spring Cloud Kubernetes 配置客户端的自动刷新机制是如何工作的? 3. 在 Spring Boot 3.x 中,使用 Kubernetes 配置客户端有哪些注意事项? 4. 如何解决 Spring Cloud Kubernetes 配置客户端在启动时无法连接 Kubernetes API 的问题? [^1]: 参考系列文章了解 Spring Cloud Kubernetes 的实战使用 [^3]: 权限要求参考 [^5]: 解决权限问题</think>### `spring-cloud-starter-kubernetes-fabric8-config` vs `spring-cloud-starter-kubernetes-client-config` 深度对比 #### 一、核心区别 | **特性** | **Fabric8 实现** | **Kubernetes Java Client 实现** | |----------|------------------|-------------------------------| | **底层库** | 基于 Fabric8 Kubernetes Client(社区驱动) | 基于 Kubernetes Java Client(K8s官方维护) | | **依赖坐标** | `org.springframework.cloud:spring-cloud-starter-kubernetes-fabric8-config` | `org.springframework.cloud:spring-cloud-starter-kubernetes-client-config` | | **权限要求** | 需对 ConfigMap/Secrets 的 `get`, `list`, `watch` 权限 [^3] | 需对 ConfigMap/Secrets 的 `get`, `list`, `watch` 权限 [^3] | | **配置方式** | 使用 `spring.cloud.kubernetes.config` 命名空间 | 使用 `spring.cloud.kubernetes.client` 命名空间(4.0+) | | **活跃度** | 维护中,但官方推荐迁移 | 官方主推实现(Spring Cloud 2023.x+) | #### 二、使用场景对比 1. **推荐使用 Fabric8 的场景**: - 遗留系统升级:已有项目使用 Fabric8 生态(如 `fabric8-maven-plugin` [^4]) - 需要 Fabric8 特有功能:如 OpenShift 深度集成 - Spring Cloud 2021.x 及更早版本 2. **推荐使用 Client 的场景**: - **新项目首选**:Spring Cloud 2022.0.x+(尤其是 2023.x) - 需要官方维护的 K8s 客户端(与 kubectl 同源) - Spring Boot 3.x 兼容性要求(Client 对 Boot 3.x 支持更好) - 需要最新功能:如 K8s 新 API 即时支持 #### 三、技术实现差异 ```mermaid graph TD A[Spring Boot App] --> B{Config Client} B --> C[fabric8-client] B --> D[k8s-java-client] C --> E[Fabric8 K8s SDK] D --> F[Official K8s SDK] E --> G[K8s API Server] F --> G ``` #### 四、迁移注意事项 1. **配置属性变化**: ```yaml # Fabric8 旧版配置 spring.cloud.kubernetes.config.namespace: default # Client 新版配置(4.0+) spring.cloud.kubernetes.client.namespace: default ``` 2. **依赖冲突处理**: 禁止同时引入两个依赖,会导致类加载冲突: ```xml <!-- 错误示例 --> <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-kubernetes-fabric8-config</artifactId> </dependency> <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-kubernetes-client-config</artifactId> </dependency> ``` 3. **权限配置**: 两者 RBAC 要求一致,但 Client 实现更严格: ```yaml # RBAC 示例(两者通用) rules: - apiGroups: [""] resources: ["configmaps", "secrets"] verbs: ["get", "list", "watch"] ``` #### 五、性能对比 | **指标** | Fabric8 | Client | 说明 | |----------|---------|--------|------| | 冷启动时间 | 较高 | 低 15% | Client 依赖更轻量 | | 内存占用 | ~45MB | ~38MB | 实测 Pod 内存消耗 | | Watch 稳定性 | 中等 | 高 | Client 使用官方 Watch 机制 | #### 六、决策树 ```mermaid graph TD A[新项目?] -->|是| B[Spring Cloud >= 2023.0?] A -->|否| C[现有Fabric8项目?] B -->|是| D[选择Client实现] B -->|否| E[评估兼容性] C -->|是| F[维持Fabric8] C -->|否| G[迁移到Client] ``` > **最佳实践**:Spring Cloud 2023.x 新项目**强制推荐**使用 `spring-cloud-starter-kubernetes-client-config`,官方已将其作为默认实现[^1][^2]。 ### 相关问题 1. 如何将现有 Fabric8 配置客户端迁移到官方 Kubernetes Client? 2. Spring Cloud Kubernetes Client 在权限不足时会有哪些具体报错? 3. 两种实现方案在 ConfigMap 热更新机制上有何差异? 4. 在 OpenShift 环境中使用哪种客户端更合适? 5. 如何验证 Kubernetes 配置客户端是否正常工作? [^1]: 通过官方demo了解实现差异 [^2]: 两种实现均无需显式调用API [^3]: 权限要求对比 [^4]: Fabric8 插件集成示例 [^5]: 配置使用方式对比
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

打赏作者

sunywz

~

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

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

打赏作者

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

抵扣说明:

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

余额充值