关于configmap的差异化
duiniwukenaihe opened this issue · comments
很早之前就关注了openkruise,最近看了一眼OpenKruiseGame,关于部署游戏服这里我有些疑问：https://openkruise.io/zh/kruisegame/user-manuals/deploy-gameservers，对于game-1 game-2 game-3这样的单体游戏服务，我是要加载不同的配置文件configmap的，比如一些自定义的环境变量，数据库的链接，这里应该如何好的实现呢？
一般是通过配置文件来做的，下面是一个比较典型的游戏案例。
每一个游戏服务可以挂在独立的配置文件，配置文件可以放在NAS/OSS等共享存储内，这样就可以实现单个游戏服独立的配置管理。
这种方式是否是比较low了？为何是oss配置中心。我要配置一个私有的对象存储？我还要接入sdk去获取？或者是挂载oss存储？game-1 game-2能自动 根据标签扩容。大部分人的应用场景肯定是数据库-1 数据库-2这样的差异化数据库配置？如果还去挂载对象存储生成配置文件....这跟传统部署方式没有太大改变。
可以看下这篇文档
无需接入sdk获取文件内容，通过DownwardAPI + 持久化存储挂载的方式即可自动化拿到本身的配置信息
为何是oss配置中心。我要配置一个私有的对象存储？我还要接入sdk去获取？或者是挂载oss存储？game-1 game-2能自动 根据标签扩容。大部分人的应用场景肯定是数据库-1 数据库-2这样的差异化数据库配置？如果还去挂载对象存储生成配置文件....这跟传统部署方式没有太大改变。
OSS是用来举一个例子，也可是独立的configmap，也可以是NAS。核心的逻辑是需要一种约定大于配置的策略，让配置文件能够跟随游戏服来管理，在OKG里面可以通过配置文件、独立存储盘、共享存储盘的策略来实现，OSS的方式是共享存储盘的一种方式，是大部分游戏当前的架构形态。
传统运维确实是配置文件......都玩自动了我如果使用openkruise我肯定希望的是根据一个模板去自动化生成配置文件。都用上了kubernetes了用户还需要独立配置文件.... 我没有看到用他的优势...那我个人看来没有自己搞一个operator去自动生成configmap更能减少工作量了。因为配置文件也无非就是数据库连接 端口映射这一些。基本规范化命名 db1 db2这样的数据库也大部分是跟game的序号对应的把？以上只是个人见解......
传统运维确实是配置文件......都玩自动了我如果使用openkruise我肯定希望的是根据一个模板去自动化生成配置文件。都用上了kubernetes了用户还需要独立配置文件.... 我没有看到用他的优势...那我个人看来没有自己搞一个operator去自动生成configmap更能减少工作量了。因为配置文件也无非就是数据库连接 端口映射这一些。基本规范化命名 db1 db2这样的数据库也大部分是跟game的序号对应的把？以上只是个人见解......
可以把您希望<根据模版自动生成配置文件>的模式细化一下，我们可以一起看下您的具体需求。最好的话举个例子会更清晰
比如我有这样的一个confgimap模板：
apiVersion: v1 data: DATABASE_HOST: 10.0.1.165 DATABASE_PASSWD: xxxx DATABASE_PORT: "3306" DATABASE_NAME: pvpgame DATABASE_USER: xxxx GAME_CLIENT_PATH: /app/main.js GATEWAY_ADDR: xxxxx GATEWAY_PORT: "xxxx" REDIS_ADDRESS: xxxx REDIS_PASSWORD: xxxx REDIS_PORT: "6379" kind: ConfigMap metadata: name: pvpgame namespace: develop
基本配置都是常量。但是DATABASE_NAME数据库的数据库名会递增pvpgame-1.... pvpgame-10,GATEWAY_PORT的端口会是9000-9010。我这个应用但是会有20个，前10个的配置是这样的。11-20会是另外一个DATABASE的配置。数据库名的递增规则。这种应该是常见的游戏配置文件的配置。希望能实现这样的功能。
这个应用但是会有20个，前10个的配置是这样的。11-20会是另外一个DATABASE的配置。数据库名的递增规则。这种应该是常见的游戏配置文件的配置。希望能实现这样的功能。
我理解是希望一些定制化的渲染能力，默认OKG里面提供一些原子的策略，例如：序号、名称这类的是支持的，至于区段，其实只需要业务根据环境变量进行条件渲染就可以了。类似的功能OKG之前有过设计，但是最终还是暂时先不支持，核心原因在于，基于规则渲染的方式存在一定管理和推测的复杂度，与其在框架上支持，不如下沉在启动脚本层支持。
那我个人看来没有自己搞一个operator去自动生成configmap更能减少工作量了。因为配置文件也无非就是数据库连接 端口映射这一些。基本规范化命名 db1 db2这样的数据库也大部分是跟game的序号对应的把？以上只是个人见解......
单纯从k8s的视角来看，确实如此，抛离独立管理配置文件确实可以提升自动化的程度。但是与此同时，可能会牺牲的是定向管理的自由度，比如：运维人员/发行平台的运维修改配置的时候，这个策略的感知就会带来更多沟通的成本。
对的。但是这样也确实可以减少运维的介入，规范化会更好一些。上云都要改变，去接受kubernetes。否则技术债务也会越来越多，或者是个假的上kubernetes....