微服务/kubernetes环境下的配置管理

文章内容

1.问题分析
2.解决办法
3.总结分析

和以前单体应用不同，在微服务的架构下，多环境，多版本，多实例的特点更加明显，特别是添加了CI/CD流程之后，服务配置文件的管理显得额外重要；目前，也有一些已有的实现，比如kubernetes中的configMap以及CRD。

注：以下所说的配置不包括服务发布的配置（比如，yaml文件），这些应该集成在CI/CD流程中；

1.问题分析

问题列表

1.为了保证服务的高可用性，一般会创建多个服务的实例(比如，Docker容器)，如何保证这些实例获取到的配置是一致的？

2.一般服务的更新并不一定需要更新配置，服务版本发布如何和配置版本分离？

3.同一个服务，可能需要在不同的环境中运行，如何保证他们获取到的配置和环境相匹配？

4.如何分别对待敏感配置和一般配置？

2.解决办法

下面以常见的第三方接口调用信息为例（API入口，授权Token信息）

2.1 基于configMap和secret的解决办法

Kubernetes的configMap和secret天生就是用来这样的事的。下面简单介绍一下如何使用configMap和secret保存服务配置；

官方参考

简单的key-value形式

配置定义

kind: ConfigMap
apiVersion: v1
metadata:
  name: example-config
  namespace: default
data:
  code_authorization_url: https://www....

对于如何使用配置，建议通过环境变量传递到服务进程中，具体使用如下：

env:
  # Define the environment variable
  - name: CODE_AUTHORIZATION_URL
    valueFrom:
      configMapKeyRef:
        # The ConfigMap containing the value you want to assign to SPECIAL_LEVEL_KEY
        name: example-config
        # Specify the key associated with the value
        key: code_authorization_url

通过文件批量定义

通过文件定义的场景一般是直接在configMap中保存程序的配置文件，然后在挂载在容器特定目录；

从单个文件创建

kubectl create configmap example-config-file --from-file=my.conf=<path-to-file>

configMap挂载

volumeMounts:
  - name: "example-config-file"
    mountPath: "/etc/mysql/conf/"
    readOnly: true

容器启动后可以看到/etc/mysql/conf/目录下有一个名为my.conf的文件；

通过secret保存敏感信息

对于用户名和密码等信息，保存在configMap和文件中都是不安全的；于是，kubernetes提供了secret资源类型来解决集群敏感信息的保存；

默认的secret只是对数据进行base64编码

apiVersion: v1
kind: Secret
metadata:
  name: mysecret
type: Opaque
data:
  username: YWRtaW4=
  password: MWYyZDFlMmU2N2Rm

通过环境变量使用

env:
  - name: SECRET_USERNAME
     valueFrom:
       secretKeyRef:
         name: mysecret
         key: username
   - name: SECRET_PASSWORD
     valueFrom:
       secretKeyRef:
         name: mysecret
         key: password

通过数据库配置

除了以上提到的和程序运行有关的配置，还有一类信息他是业务相关的，可配置的，甚至有专门的后台系统进行配置，比如，消息提醒的模板；这类配置信息，一般存放在数据库中；

配置的获取

当然是查询专门的配置数据库获取配置，但是这样对于数据库来说是没有价值的开销，在并发量大的时候对于数据库也是不小的开销；解决方案是通过客户端（服务实例）缓存来减少数据库查询次数，甚至是直接持久化到文件中，定期进行刷新；

3.总结分析

通过configMap和secret是一种比较完善的服务配置解决方案，但是对于一些变更频繁的配置，可能还是需要保存数据库中，通过数据库维护相对简单，并且通过缓存刷新，可以在不重启服务的情况下更新配置信息；