聊聊springcloud如何与k8s configMap整合实现配置动态刷新

前言

配置中心在微服务的服务治理场景基本上是属于标配,常见可以用来做配置中心有nacos、apollo、zookeeper、springcloud config、consul、etcd、redis、disconf、dimond、xxl-conf等。这些组件的特点都是需要安装,如果大家的部署环境中有用到k8s,且不需要用到太多配置中心的特殊功能,比如灰度发布、权限管理、发布审核、操作审计啥的,仅仅只是用来统一配置,以及实现配置的热更新,那今天讲主角configMap会是一个挺不错的选择

configMap简介

ConfigMap 是一种 API 对象,用来将非机密性的数据保存到键值对中。使用时,Pods 可以将其用作环境变量、命令行参数或者存储卷中的配置文件。ConfigMap 的主要作用就是为了让镜像和配置文件解耦,以便实现镜像的可移植性和可复用性。

具体详细介绍可以查看官网

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

configMap如何实现热更新

注: 假设大家对configMap已经有一定了解,如果对configMap,可以去了解一下,再来看本文

1、k8s configmap在哪些场景会自动实现热更新

a、 以挂载Volume 方式使用的 ConfigMap 数据会自动更新。更新时间大约10s左右

2、k8s configmap在哪些场景不会自动实现热更新

a、 以环境变量(ENV)方式使用的 ConfigMap ,Kubernetes不会做自动热更新:

b、 如果使用ConfigMap的subPath挂载为Container的Volume,Kubernetes不会做自动热更新

3、热更新验证示例

https://jimmysong.io/kubernetes-handbook/concepts/configmap-hot-update.html

上面讲的是configmap自带的热更新,算是一个小科普,跟本文的主线关系不大,接下来上主菜

springcloud如何与configmap整合实现动态刷新

注: 本示例springcloud版本为Hoxton.SR3

示例前置准备

1、示例configMap

apiVersion: v1
kind: ConfigMap
metadata:
  name: lybgeek-properties
  namespace: lybgeek
data:
  lybgeek.properties: |
    test = k8s-config-666

2、准备示例需要的controller

    @RestController
    @RequestMapping("config")
    @RefreshScope
    class ConfigTestController{

        @Value("${test:local}")
        private String test;

        @GetMapping("test")
        public String test(){
            return test;
        }
    }

正文

1、在项目中pom中引入相关GAV

<dependency>
 <groupId>org.springframework.cloud</groupId>
 <artifactId>spring-cloud-starter-kubernetes-config</artifactId>
</dependency>

<dependency>
 <groupId>org.springframework.boot</groupId>
 <artifactId>spring-boot-actuator</artifactId>
</dependency>

2、在项目中src/main/resource创建bootstrap.yml或者application.yml文件,填入如下内容

spring:
  cloud:
    kubernetes:
      config:
        name: ${LYBGEEK_CONFIG_MAP:lybgeek-properties}
        namespace: ${LYBGEEK_CONFIG_MAP_NAMESPACE:nisbos}
      reload:
        # 打开刷新功能
        enabled: ${LYBGEEK_CONFIG_MAP_RELOAD_ENABLED:true}
        # 监控configMap变化
        monitoring-config-maps: ${LYBGEEK_CONFIG_MONITOR:true}
        # 监控secrets变化
        monitoring-secrets: ${LYBGEEK_SECRETS_MONITOR:true}
        # 加载策略,有三种,
        # refresh:只重新加载用@ConfigurationProperties或@RefreshScope注释的配置bean。此重新加载级别利用了Spring Cloud Context的刷新功能。
        # restart_context:整个Spring ApplicationContext被优雅地重新启动。使用新配置重新创建bean。为了使重启上下文功能正常工作,您必须启用并公开restart端点
        # shutdown:关闭Spring ApplicationContext以激活容器的重新启动。使用此级别时,请确保所有非守护进程线程的生命周期都绑定到ApplicationContext,并且已配置复制控制器或副本集以重新启动pod。
        strategy: ${LYBGEEK_CONFIG_RELOAD_STRATEGY:restart_context}
        # 模式:event(默认):通过使用Kubernetes API(web套接字)来监视configMap或secrets中的更改。任何事件都会对配置进行重新检查,如果发生更改,还会重新加载。需要服务帐户上的视图角色才能侦听配置映射更改。secrets需要更高级别的角色(如编辑)(默认情况下,不监控secrets)。
       # 轮询:定期根据configMap和secrets重新创建配置,以查看其是否已更改。您可以使用spring.cloud.kubernetes.reload.period属性配置轮询周期,默认为15秒。它需要与受监控的属性源具有相同的角色。这意味着,例如,对文件装载的秘密源使用轮询不需要特定的权限。
        mode: ${LYBGEEK_CONFIG_RELOAD_MODE:polling}
        # 调成500毫秒
        period: ${LYBGEEK_CONFIG_POLLING:500}



management:
  endpoint:
    restart:
      enabled: true
  endpoints:
    web:
      exposure:
        include: restart

核心配置属性介绍

a、spring.cloud.kubernetes.config.name configMap名字,默认是spring.application.name
b、spring.cloud.kubernetes.config.namespace k8s命名空间
c、spring.cloud.kubernetes.reload.enabled=true 开启加载
d、spring.cloud.kubernetes.reload.strategy 加载支持的策略

  • refresh:只重新加载用@ConfigurationProperties或@RefreshScope注释的配置bean。此重新加载级别利用了Spring
    Cloud Context的刷新功能。
  • restart_context:整个Spring ApplicationContext被优雅地重新启动。使用新配置重新创建bean。为了使重启上下文功能正常工作,您必须启用并公开restart端点
  • shutdown:关闭Spring ApplicationContext以激活容器的重新启动。使用此级别时,请确保所有非守护进程线程的生命周期都绑定到ApplicationContext,并且已配置复制控制器或副本集以重新启动pod。

e、spring.cloud.kubernetes.reload.mode 加载支持的模式

  • event(默认):通过使用Kubernetes
    API(web套接字)来监视configMap或secrets中的更改。任何事件都会对配置进行重新检查,如果发生更改,还会重新加载。需要服务帐户上的视图角色才能侦听配置映射更改。secrets需要更高级别的角色(如编辑)(默认情况下,不监控secrets)。
  • 轮询:定期根据configMap和secrets重新创建配置,以查看其是否已更改。您可以使用spring.cloud.kubernetes.reload.period属性配置轮询周期,默认为15秒。它需要与受监控的属性源具有相同的角色。这意味着,例如,对文件装载的秘密源使用轮询不需要特定的权限。

3、测试

先浏览器访问我们准备好的controller


将configmap的内容改为

apiVersion: v1
kind: ConfigMap
metadata:
  name: lybgeek-properties
  namespace: lybgeek
data:
  lybgeek.properties: |
    test = k8s-config-999

我们观察下业务打印出来的日志


出现restarted,然后我们再访问我们controller

原先的k8s-config-666已经改成k8s-config-999,说明配置热更新生效

在实验的过程中可能会出现

User “system:serviceaccount:lybgeek:default” cannot get resource “configmaps” in API group “” in the namespace “lybgeek”.

那是因为system:serviceaccount:lybgeek:default没有拉取configMap的权限,因此我们将相应的权限给补上即可。

a、 创建ClusterRole

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  namespace: lybgeek
  name: configmap-test
rules:
- apiGroups:
  - ""
  resources:
  - configmaps
  verbs:
  - get

b、 system:serviceaccount:lybgeek:default与创建好的ClusterRole(configmap-test)绑定

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata
  name: configmap-test-clusterrolebinding
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: configmap-test
subjects:
- kind: ServiceAccount
  name: default
  namespace: lybgeek

总结

本文介绍springcloud如何与k8s configMap整合实现配置动态刷新,其实是借助spring-cloud-kubernetes的能力,详细介绍可以查看官网
https://docs.spring.io/spring-cloud-kubernetes/docs/current/reference/html/#propertysource-reload
官网也有提供了示例
https://github.com/spring-cloud/spring-cloud-kubernetes/tree/main/spring-cloud-kubernetes-examples/kubernetes-reload-example

在官网有一个警告

就是该功能在2020.0版本之后,该功能已经被弃用了,改为使用Spring Cloud Kubernates Configuration Watcher。如果大家项目的k8s版本是 >= 1.9,使用Reloader来做配置热更新也是一个不错选择,对这个组件感兴趣的朋友可以查看官网
https://github.com/stakater/Reloader

有网友也提供configMap热更新的其他方案,详情可以查看如下链接
https://cctoctofx.netlify.app/post/cloud-computing/k8s-config-update/

posted @ 2023-08-08 10:11  Linyb极客之路  阅读(469)  评论(0编辑  收藏  举报