OSPP2024 | 为Apollo的java、golang客户端缓存支持Kubernetes ConfigMap

[dyx1234]

Apollo客户端原有的文件持久化方式将配置信息存储在本地文件中，在k8s环境下存在一些局限性，特别是在Apollo服务端宕机的情况下：如果Pod重启，本地文件可能会丢失，导致配置信息不可用。为了提高配置信息的可靠性和容错性，我们提出了一种新的持久化方案，即通过Kubernetes的ConfigMap来存储配置信息。

1. 目标

● 确保在Apollo服务端宕机且Pod重启时，应用能够从ConfigMap恢复配置信息。
● 用户通过客户端配置控制是否启用ConfigMap持久化功能。
● 同时支持configMap和文件两种持久化方式，构造链式恢复，进一步提升可用性

2.用户配置要求

● 所在Pod的Service Account需具备读写ConfigMap的权限。
● java客户端：通过设置环境变量apollo.cache.kubernetes.enable=true启用持久化功能，并可通过apollo.configmap-namespace指定ConfigMap的namespace。
● go客户端：在AppConfig中将IsBackupConfigToConfigMap字段设为 true 以启用ConfigMap持久化，并通过 ConfigMapNamespace字段设置ConfigMap的namespace。

3.技术实现概览

Go语言实现

1. 配置：在AppConfig中将IsBackupConfigToConfigMap字段设为 true 以启用ConfigMap持久化，并通过 ConfigMapNamespace字段设置ConfigMap的namespace。
2. 客户端初始化：根据环境变量初始化ConfigMapStore插件。
3. ConfigMap操作：使用client-go库操作ConfigMap，实现配置的读写。
4. 配置同步：在同步过程中加载ConfigMap数据，并在配置变更时更新ConfigMap。
5. 容错处理：在Apollo服务不可用时，从ConfigMap读取配置信息，确保应用可用性。
6. ConfigMap映射视图：configMap名称为appId，其中每个键值对的key为cluster+namespace，value为配置信息的 JSON 串
   

Java语言实现

1. 环境配置：配置信息中设置apollo.cache.kubernetes.enable和apollo.configmap-namespace字段以启用ConfigMap持久化功能。
2. 客户端初始化：检查环境变量并尝试从ConfigMap加载配置信息，根据文件缓存启用情况构造存储链。
3. ConfigMap配置Repository：新增基于ConfigMap的配置存储实现类，包括事件监听和数据更新。
4. 容错处理：定义配置信息的读取顺序（远程 -> 文件 -> ConfigMap），并提供兜底机制。
5. ConfigMap映射视图：configMap名称为appId，其中每个键值对的key为cluster+namespace，value为配置信息的 JSON 串
   

4.容错与灰度发布处理

● 配置信息读取的优先级：远程server>文件缓存>configMap缓存
● 灰度发布时ConfigMap的局限性及解决方案： 客户端无法知道哪些是灰度数据，且多个pod会共享同⼀个configMap，导致冲突，所以 configMap无法支持灰度数据的持久化。 不过这些灰度数据仍可以通过本地文件或服务端拉取获得，因此设计为远程-文件-configMap三层的链式拉取
● 提供兜底机制：宕机恢复时，先访问服务端能否正常返回数据，如果不行，去本地文件加载数据。如果文件也未找到，返回用户设置的cluster+namespace对应的configmap的数据，如果再找不到，去idc数据中心请求，如果都不能找到，返回default+namespace的configmap数据，作为兜底
（推荐开启configmap的同时开启文件缓存，configmap不支持灰度数据的存储）

5.配置映射关系

● 明确AppId、Cluster、Namespace在java、go客户端中的映射方式。
● appId做configMap名，cluster+namespace做key，配置值为value。

使用json存储真实配置文件信息，并定义统一的configMapName，key，value。使k8s中使用java、go两种客户端的不同pod中的应用程序能同时使用同一个configMap，提高了兼容性

[hezhangjian]

go apollo SDK支持备份到cm的能力测试场景(Java类似)

预置条件

• 微服务A使用了go apollo SDK
• 微服务A启动时，需要从apollo获取配置项B。配置项B的取值为：value1.而且是强依赖该配置。如果获取不到，则启动失败。

测试步骤和预期结果：

• 正常场景下，对接apollo成功，微服务A能够启动成功。
• 执行k8s命令：kubectl describe cm -n{namespace} {configmap-name}，查看configmap是否包含了数据。
• 将apollo服务停止掉（可以将apollo微服务缩容成0，或者将所在的虚拟机关机）。然后重启微服务A。微服务A，能够启动成功。微服务A此时从cm中获取该apollo配置，能够启动成功。

[wcp1231]

终于有了进展 🎉

看设计是每个 APP 一个 configmap，每个 namespace 为一个 key-value，那是否可以测试一下对 ETCD 和 apiserver 的负载影响？
如果服务数量多且每个服务用的配置也多的话，会产生大量的大 configmap，不知道是否会给 ETCD 和 k8s 增加过多负担