Closed MrYourM closed 4 years ago
https://github.com/QingCloudAppcenter/QKE/blob/master/ansible/roles/app-role-k8s/files/opt/app/current/bin/node/k8s.sh#L510
可以暴露两个参数: spec.multicluster spec.authentication.jwtSecret
为防止该情况的发生,我想到的相对来说较好的方案
可以防止「配置参数」的修改覆盖掉人为通过 kubectl edit 做的修改 每次修改完 ks 配置后都对现有的 ks-installer pod 的yaml 文件做一次保存,再次 apply 的时候使用保存的 yaml 文件替换掉默认的 cluster-configuration-stable.yml 文件
缺点:有些人为的修改不会被自动保存,会因为「配置参数」项的修改而刷掉
可以防止人为修改覆盖掉「配置参数」项中的固定配置项 每次涉及到「配置参数」被修改前,先对现有的 ks-installer 配置项做一次保存,之后使用保存的 yaml 文件替换掉默认的 cluster-configuration-stable.yml 文件
最终的结果:当出现人为修改和「配置参数」的配置项一样的时候,「配置参数」会覆盖掉人为修改的
这个应该跟 redis 一样,有的参数是通过 AppCenter 管理,有的允许用户管理,但如果用户修改了本来应该 AppCenter 管理的部分,那就以 AppCenter 为准,覆盖用户的改动。
可以参考一下 kubectl patch 命令,只修改一部分,可能比 kubectl apply 更合适。
kubectl patch
kubectl apply
代码已提
https://github.com/QingCloudAppcenter/QKE/blob/master/ansible/roles/app-role-k8s/files/opt/app/current/bin/node/k8s.sh#L510
可以暴露两个参数: spec.multicluster spec.authentication.jwtSecret
为防止该情况的发生,我想到的相对来说较好的方案
方案一
可以防止「配置参数」的修改覆盖掉人为通过 kubectl edit 做的修改 每次修改完 ks 配置后都对现有的 ks-installer pod 的yaml 文件做一次保存,再次 apply 的时候使用保存的 yaml 文件替换掉默认的 cluster-configuration-stable.yml 文件
缺点:有些人为的修改不会被自动保存,会因为「配置参数」项的修改而刷掉
方案二
可以防止人为修改覆盖掉「配置参数」项中的固定配置项 每次涉及到「配置参数」被修改前,先对现有的 ks-installer 配置项做一次保存,之后使用保存的 yaml 文件替换掉默认的 cluster-configuration-stable.yml 文件
最终的结果:当出现人为修改和「配置参数」的配置项一样的时候,「配置参数」会覆盖掉人为修改的