【提问】Operator开发中，如何解决资源对象太大，导致数据过多的时候拉胯ETCD

[xue8]

问题描述

请教一下，Operator开发中，资源对象过大，如果历史数据较多的情况下，势必会拉胯 etcd。

按照平均每个资源对象3000个字符，假设都是中文字符且在UTF-8编码中，那么每个字符占3个字节的，这样一换算，每个资源大约 9KB，如果这个资源是个被周期性任务创建产生的，每个小时创建 1000 个，那么一天数据量为：9KB * 1000 * 24 = 211MB， 这么大的数据量，如果又要将这些历史数据保存 1 个月以上，etcd 势必会被压垮。

我先抛砖引玉，分享一下我想到的解决方案：

1. 起一个 watchService，将资源对象从 etcd 中卸载到 db 上（如 mysql）

不知道各位大佬有没有其他更好的实践分享一下，感谢！

[gasxia]

k8s event 就不会长期保留，一般都会读出来存到其它持久化存储中，可以参考下

[xue8]

k8s event 就不会长期保留，一般都会读出来存到其它持久化存储中，可以参考下

感谢大佬的建议

[xue8]

最终方案：参考 CronJob 的实现，successfulJobsHistoryLimit、failedJobsHistoryLimit 对历史记录数量继续限制。

[stevensu1977]

/archive

[mjolnir-bot]

@mjolnir-bot 完成归档操作,你可以通过 【提问】Operator开发中，如何解决资源对象太大，导致数据过多的时候拉胯ETCD进行访问

[Jeffwan]

@xue8 cronjob这种方式理论上就是缩短etcd数据存储天数，你那历史30天的需求如果是定下来的就没办法改变吧?

[wujunwei]

可以换种operator实现的方式：通过将你的crd的增删改查接口注册apiserver 聚合层上 这样crd就不会存在etcd里，而是你自己的数据库里。详见k8s 文档

[callmevincent]

这是来自QQ邮箱的假期自动回复邮件。   您好，我最近正在休假中，无法亲自回复您的邮件。我将在假期结束后，尽快给您回复。