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:
- The pods do not have the istio sidecar on them.
- 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
- Specify istio-init user explicitly (#5453) Istio-init is supposed to be run as a superuser so it can configure iptables and this is the current default. However many popular Helm charts typically def... — committed to philrud/istio by deleted user 5 years ago
- Specify istio-init user explicitly (#5453) (#12708) Istio-init is supposed to be run as a superuser so it can configure iptables and this is the current default. However many popular Helm charts ty... — committed to istio/istio by philrud 5 years ago
- Merge master to collab-authn (#13254) * Testing: support retries in Structpath (#12539) * Testing: support retries in Structpath The current structpath library automatically fails the test as s... — committed to istio/istio by diemtvu 5 years ago
- Merge latest master branch into collab-authn (#13357) * add istio-init.yaml to .gitignore (#12542) * authz: add authorization policy CRD to helm-init (#12541) * Fix bug in locality LB normaliza... — committed to istio/istio by lei-tang 5 years ago
- Merge master branch 2619197 to collab authn (#13539) * Drop log level for missing service account for spiffe uri (#12239) * Don't require service account for spiffe Some kubernetes pods don't h... — committed to istio/istio by lei-tang 5 years ago
Commenting out securityContext from deployment.yaml works for me.
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 includingistio-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.