istio: helm stable/redis does not work with istio sidecar

Here’s the yaml i generated from helm install stable/redis.

# Source: redis/templates/redis-master-svc.yaml
apiVersion: v1
kind: Service
metadata:
  name: rune-redis-master
  labels:
    app: redis
    chart: redis-3.2.0
    release: "rune-redis"
    heritage: "Tiller"
  annotations:
spec:
  type: ClusterIP
  ports:
  - name: redis
    port: 6379
    targetPort: redis
  selector:
    app: redis
    release: "rune-redis"
    role: master
---
# Source: redis/templates/redis-slave-svc.yaml
apiVersion: v1
kind: Service
metadata:
  name: rune-redis-slave
  labels:
    app: redis
    chart: redis-3.2.0
    release: "rune-redis"
    heritage: "Tiller"
  annotations:
spec:
  type: ClusterIP
  ports:
  - name: redis
    port: 6379
    targetPort: redis
  selector:
    app: redis
    release: "rune-redis"
    role: slave
---
# Source: redis/templates/redis-slave-deployment.yaml
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: rune-redis-slave
  labels:
    app: redis
    chart: redis-3.2.0
    release: "rune-redis"
    heritage: "Tiller"
spec:
  replicas: 3
  template:
    metadata:
      labels:
        release: "rune-redis"
        role: slave
        app: redis
      annotations:
        sidecar.istio.io/inject: "false"
        
    spec:      
      securityContext:
        fsGroup: 1001
        runAsUser: 1001
      containers:
      - name: rune-redis
        image: docker.io/bitnami/redis:4.0.9
        imagePullPolicy: "Always"
        env:
        - name: REDIS_REPLICATION_MODE
          value: slave
        - name: REDIS_MASTER_HOST
          value: rune-redis-master
        - name: REDIS_PORT
          value: "6379"
        - name: REDIS_MASTER_PORT_NUMBER
          value: "6379"
        - name: ALLOW_EMPTY_PASSWORD
          value: "yes"
        - name: REDIS_DISABLE_COMMANDS
          value: 
        ports:
        - name: redis
          containerPort: 6379        
        livenessProbe:
          initialDelaySeconds: 30
          periodSeconds: 10
          timeoutSeconds: 5
          successThreshold: 1
          failureThreshold: 5
          exec:
            command:
            - redis-cli
            - ping        
        readinessProbe:
          initialDelaySeconds: 5
          periodSeconds: 10
          timeoutSeconds: 1
          successThreshold: 1
          failureThreshold: 5
          exec:
            command:
            - redis-cli
            - ping
        resources:
          null
---
# Source: redis/templates/redis-master-statefulset.yaml
apiVersion: apps/v1beta2
kind: StatefulSet
metadata:
  name: rune-redis-master
  labels:
    app: redis
    chart: redis-3.2.0
    release: "rune-redis"
    heritage: "Tiller"
spec:
  selector:
    matchLabels:
      release: "rune-redis"
      role: master
      app: redis
  serviceName: "redis-master"  
  template:
    metadata:
      labels:
        release: "rune-redis"
        role: master
        app: redis
      annotations:
        sidecar.istio.io/inject: "false"
        
    spec:
      securityContext:
        fsGroup: 1001
        runAsUser: 1001
      containers:
      - name: rune-redis
        image: "docker.io/bitnami/redis:4.0.9"
        imagePullPolicy: "Always"
        env:
        - name: REDIS_REPLICATION_MODE
          value: master
        - name: ALLOW_EMPTY_PASSWORD
          value: "yes"
        - name: REDIS_PORT
          value: "6379"
        - name: REDIS_DISABLE_COMMANDS
          value: 
        ports:
        - name: redis
          containerPort: 6379
        livenessProbe:
          initialDelaySeconds: 30
          periodSeconds: 10
          timeoutSeconds: 5
          successThreshold: 1
          failureThreshold: 5
          exec:
            command:
            - redis-cli
            - ping
        readinessProbe:
          initialDelaySeconds: 5
          periodSeconds: 10
          timeoutSeconds: 1
          successThreshold: 1
          failureThreshold: 5
          exec:
            command:
            - redis-cli
            - ping
        resources:
          null
          
        volumeMounts:
        - name: redis-data
          mountPath: /bitnami/redis/data
          subPath: 
  volumeClaimTemplates:
    - metadata:
        name: redis-data
        labels:
          app: "redis"
          chart: redis-3.2.0
          component: "master"
          release: "rune-redis"
          heritage: "Tiller"
      spec:
        accessModes:
          - "ReadWriteOnce"
        resources:
          requests:
            storage: "8Gi"

Most of it is pretty irrelevant but what you’d expect to be there is there:

  1. The pods do not have the istio sidecar on them.
  2. The service ports are named:
  ports:
  - name: redis
    port: 6379
    targetPort: redis

Istio version: 7.0.1

I thought this was fixed in 5.0.0?

Istio auto-injector version: 7.0.1

About this issue

  • Original URL
  • State: closed
  • Created 6 years ago
  • Reactions: 1
  • Comments: 21 (6 by maintainers)

Commits related to this issue

Most upvoted comments

Commenting out securityContext from deployment.yaml works for me.

    spec:
#      securityContext:
#        runAsUser: 1001
#        fsGroup: 1001

Confirming what previously has been mentioned: this not a sidecar/traffic management issue. The problem is that the securityContext.runAsUser = 1001 directive is on a Pod level hence affecting all containers in the Pod including istio-init. istio-init has to be run as root in order to configure iptables.

Commenting out runAsUser field (or moving it to the container level) resolves the issue and Redis Cluster works fine with sidecars enabled. Replicas are able to establish connections to master just fine and I’m able to execute commands via redis-cli on both master and replicas.

I suspect many charts may not work because of similar issue, one thing we could do is explicitly adding securityContext.runAsUser = 0 to the istio-init container (by default, with an option to disable that via a Helm option) so that this setting takes precedence over the pod-level one. istio-init currently requires running as root anyways.