Redis阻止GKE按比例缩小的原因是:no.scale.down.node.pod.has.local.storage

Question

我有一个GKE集群，目前扩展到多个节点，由于DDOS对我们的服务的攻击，在高负载期间进行了扩展，但现在由于redis master和redis slave，集群无法缩小规模，这最终导致了大量的开销，这已经成为我们现在的一个问题。

自动缩小显示错误：no.scale.down.node.pod.has.local.storage。我在多个答案中看到，将选项cluster-autoscaler.kubernetes.io/safe-to-evict设置为true应该可以解决问题(GCP建议相同(，但在此之前，我想知道这样做和缩减redis从属实例是否会导致任何数据丢失？任何建议都是理想的，因为目前我们支付的费用是所需费用的两倍多。

我也检查了配置，我看到卷下有redis master和redis slave两个卷，配置yaml也有：

volumeClaimTemplates:
- apiVersion: v1
kind: PersistentVolumeClaim
metadata:
creationTimestamp: null
labels:
app: redis
component: master
heritage: Tiller
release: prod-redis
name: redis-data
spec:
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 20Gi
volumeMode: Filesystem

Answer 1

Redis master或slave大多将数据保存到内存中，用于备份和恢复目的——根据配置，每隔一分钟或一秒就会拍一次快照。

如果有任何快照选项正在运行或未运行，则可以签出部署配置或配置映射。在Redis术语中，称为AOF和RDB备份。

当在K8s中发现任何Redis POD崩溃时，它会启动并恢复上面文件中的数据(如果存在(。

因此，请确保exec进入POD并检查文件是否存在。

image: redislabs/redis
args: ["--requirepass", "admin", "--appendonly", "yes", "--save", "900", "1", "--save", "30", "2"]

检查配置或部署的YAML可能有一些类似上面的选项。

参考文件：https://redis.io/topics/persistence

如果没有文件，您可以手动进行备份，因此如果POD崩溃，它将从旧数据开始。

后台生成备份的命令：BG SAVE

如果POD中有大量数据，事情可能会出错，BG SAVE将启动将数据保存到PVC中的filesystem的过程，这可能会导致更高的资源需求，并且如果设置了资源，POD将被杀死。

一旦使用后台命令保存了数据，就可以开始删除具有各自PVC的从属设备。

因此，如果禁用了AOF和RDB，则会出现数据丢失。

仅仅RDB也不是一个好的选择，因为它需要定期备份，而AOF是一个即时选项。

如果只有RDB，它可能在晚上拍摄了快照并且您在早上删除了POD，因此快照后的最新数据在内存中，您可能无法在快照中获得。