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



我有一个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

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

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

当在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的从属设备。

因此,如果禁用了AOFRDB,则会出现数据丢失。

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

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

相关内容

  • 没有找到相关文章

最新更新