使用helm部署bitnami redis集群

Question

我在kubernetes中使用helm图表完成了bitnami redis集群部署。https://github.com/bitnami/charts/tree/master/bitnami/redis-cluster

但在豆荚运行一段时间后，它会给出以下许可问题。

1:M 12 Feb 2022 16:49:58.886 * Starting automatic rewriting of AOF on 157422% growth
1:M 12 Feb 2022 16:49:58.887 * Background append only file rewriting started by pid 6625
6625:C 12 Feb 2022 16:49:58.887 # Opening the temp file for AOF rewrite in rewriteAppendOnlyFile(): Permission denied
1:M 12 Feb 2022 16:49:58.987 # Background AOF rewrite terminated with error
1:M 12 Feb 2022 16:49:59.088 * Starting automatic rewriting of AOF on 157422% growth
1:M 12 Feb 2022 16:49:59.089 * Background append only file rewriting started by pid 6626
6626:C 12 Feb 2022 16:49:59.089 # Opening the temp file for AOF rewrite in rewriteAppendOnlyFile(): Permission denied

下面是由helm生成的状态集模板。

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: redis-master
  namespace: "redis"
  labels:
    app.kubernetes.io/name: redis
    helm.sh/chart: redis-15.6.3
    app.kubernetes.io/instance: redis
    app.kubernetes.io/managed-by: Helm
    app.kubernetes.io/component: master
spec:
  replicas: 1
  selector:
    matchLabels:
      app.kubernetes.io/name: redis
      app.kubernetes.io/instance: redis
      app.kubernetes.io/component: master
  serviceName: redis-headless
  updateStrategy:
    rollingUpdate: {}
    type: RollingUpdate
  template:
    metadata:
      labels:
        app.kubernetes.io/name: redis
        helm.sh/chart: redis-15.6.3
        app.kubernetes.io/instance: redis
        app.kubernetes.io/managed-by: Helm
        app.kubernetes.io/component: master
      annotations:
        checksum/configmap:
        checksum/health: 
        checksum/scripts:
        checksum/secret: 
    spec:
      securityContext:
        fsGroup: 1001
      serviceAccountName: redis
      affinity:
        podAffinity:
          
        podAntiAffinity:
          preferredDuringSchedulingIgnoredDuringExecution:
            - podAffinityTerm:
                labelSelector:
                  matchLabels:
                    app.kubernetes.io/name: redis
                    app.kubernetes.io/instance: redis
                    app.kubernetes.io/component: master
                namespaces:
                  - "redis"
                topologyKey: kubernetes.io/hostname
              weight: 1
        nodeAffinity:
          
      terminationGracePeriodSeconds: 30
      containers:
        - name: redis
          image: docker.io/bitnami/redis:6.2.6-debian-10-r53
          imagePullPolicy: "IfNotPresent"
          securityContext:
            runAsUser: 1001
          command:
            - /bin/bash
          args:
            - -c
            - /opt/bitnami/scripts/start-scripts/start-master.sh
          env:
            - name: BITNAMI_DEBUG
              value: "false"
            - name: REDIS_REPLICATION_MODE
              value: master
            - name: ALLOW_EMPTY_PASSWORD
              value: "yes"
            - name: REDIS_TLS_ENABLED
              value: "no"
            - name: REDIS_PORT
              value: "6379"
          ports:
            - name: redis
              containerPort: 6379
          livenessProbe:
            initialDelaySeconds: 20
            periodSeconds: 5
            # One second longer than command timeout should prevent generation of zombie processes.
            timeoutSeconds: 6
            successThreshold: 1
            failureThreshold: 5
            exec:
              command:
                - sh
                - -c
                - /health/ping_liveness_local.sh 5
          readinessProbe:
            initialDelaySeconds: 20
            periodSeconds: 5
            timeoutSeconds: 2
            successThreshold: 1
            failureThreshold: 5
            exec:
              command:
                - sh
                - -c
                - /health/ping_readiness_local.sh 1
          resources:
            limits: {}
            requests: {}
          volumeMounts:
            - name: start-scripts
              mountPath: /opt/bitnami/scripts/start-scripts
            - name: health
              mountPath: /health
            - name: redis-data
              mountPath: /data
              subPath: 
            - name: config
              mountPath: /opt/bitnami/redis/mounted-etc
            - name: redis-tmp-conf
              mountPath: /opt/bitnami/redis/etc/
            - name: tmp
              mountPath: /tmp
      volumes:
        - name: start-scripts
          configMap:
            name: redis-scripts
            defaultMode: 0755
        - name: health
          configMap:
            name: redis-health
            defaultMode: 0755
        - name: config
          configMap:
            name: redis-configuration
        - name: redis-tmp-conf
          emptyDir: {}
        - name: tmp
          emptyDir: {}
  volumeClaimTemplates:
    - metadata:
        name: redis-data
        labels:
          app.kubernetes.io/name: redis
          app.kubernetes.io/instance: redis
          app.kubernetes.io/component: master
      spec:
        accessModes:
          - "ReadWriteOnce"
        resources:
          requests:
            storage: "8Gi"

显然，他们已经给予了数据文件夹的权限。

Answer 1

更新-2:我发现了一个线索，这个问题与config dir get的结果有关，但不知道这是怎么回事。

正常: redis-cli config get dir

1) "dir"
2) "/bitnami/redis/data"

异常: redis-cli config get dir

1) "dir"
2) "/etc"

由于dir已从/bitnami/redis/data更改为/etc，因此拒绝该权限是合理的。

此外，当发生这种情况时，主从之间的同步命令可能也会被此日志失败：(主日志) Failed opening the RDB file crontab (in server root dir /etc) for saving: Permission denied

使用此命令将修复权限问题：

redis-cli config set dir /bitnami/redis/data

然后一切都恢复正常..。

我还没找到根本原因。但我已经为此开了一个问题。

更新:对不起，我的解决方案没有起作用。运行了几天之后，这个问题又出现了。

今天早上我也在为这个问题苦苦挣扎。然后我发现有人在这个VolumePermissions中提到了设置问题评论。

我确实错过了图表中的配置。因此，我很快比较了启用或不启用VolumePermissions之间的状态集yaml，然后发现了以下不同之处：

      enableServiceLinks: false
# ------------------ diff starts from here ------------------
      initContainers:
      - command:
        - /bin/chown
        - -R
        - 1001:1001
        - /bitnami/redis/data
        image: docker.io/bitnami/minideb:buster
        imagePullPolicy: Always
        name: volume-permissions
        resources: {}
        securityContext:
          runAsUser: 0
        terminationMessagePath: /dev/termination-log
        terminationMessagePolicy: File
        volumeMounts:
        - mountPath: /bitnami/redis/data
          name: redis-data
# ----------------------------------------------
      restartPolicy: Always

我将diff块复制到我的旧状态集中，红星集群的荚开始一个接一个地重新启动。

到目前为止，这个问题已经解决了。我不确定我做的是正确的，但至少这使我的BGREWRITEAOF再次工作。