使用我的数据库,我们每小时都会进行一次mysql转储备份.然后,我们将该备份上传到AWS s3以确保安全性和冗余性.我们使用版本控制仅存储每个新备份的增量.我的问题是,我们是否真的通过首先压缩数据获得任何收益？是否会在gzip中对数据进行加扰,以便每个版本都必须重新存储所有数据？
如果我们改为存储未压缩的数据库版本,我们是否会因为更高效的版本控制而实际节省空间？
我应该补充说,我们已经使用版本控制在s3中存储了每小时gzipped备份几个月.但我无法在在线界面中找出如何找到每个新版本在存储中占用的数量.
我尝试在安装时使用以下命令设置每个 Pod 的最大节点数：
curl -sfL https://get.k3s.io | INSTALL_K3S_EXEC="--max-pods 250" sh -s -
但是，K3s 服务器将无法加载。根据kubernetes 文档，该标志似乎--max-pods已被弃用：
--max-pods int32 默认值：110
（已弃用：应通过 Kubelet 标志指定的配置文件设置此参数
--config。 有关更多信息，请参阅https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ 。）
那么对于 K3s，kubelet 配置文件在哪里？是否可以/应该使用上述方法来设置它？
对于Docker，存在讨论（共识？），通过运行时环境变量传递秘密不是一个好主意，因为秘密仍然可以作为系统变量使用，并且因为它们是通过docker inspect公开的。
在kubernetes中，有一个用于处理机密的系统，但是您要么将这些机密作为env vars传递（使用envFrom），要么将它们作为可在文件系统中访问的文件挂载。
有什么理由比将它们作为env vars传递来更喜欢将秘密安装为文件吗？
如今，我已经变得更加热情和模糊，以为事情变得更加安全了，以至于我正在用k8s处理我的秘密。但是后来我意识到，最终，“秘密”的处理方式与我自己启动容器时使用docker run -e传递它们的方式相同。