Istio Sidecar - doc description vs. live cluster behavior

1

my question is related to the Istio Sidecar

First : In the description of the Sidecar the following is stated:

When determining the Sidecar configuration to be applied to a workload instance, preference will be given to the resource with a workloadSelector that selects this workload instance, over a Sidecar configuration without any workloadSelector.

Second: In the spec table, in the description of egress, following is written:

If not specified, inherits the system detected defaults from the namespace-wide or the global default Sidecar.

So, I’ve tried to apply two sidecars on the “default” namespace, for the bookinfo example.

1.first sidecar is default (selector-less) in the default namespace with an egress field restricting the connections

apiVersion: networking.istio.io/v1beta1
kind: Sidecar
metadata:
  name: default-sidecar
  namespace: default
spec:
  egress:
    - hosts:
      - "./details.default.svc.cluster.local"
      - "./ratings.default.svc.cluster.local"
  1. second sidecar, is with a selector selecting the ratings app, but without an egress field:
    apiVersion: networking.istio.io/v1beta1
    kind: Sidecar
    metadata:
      name: ratings-selected
      namespace: default
    spec:
      workloadSelector:
        labels:
          app: ratings
      ingress:
      - port:
          number: 9080
          protocol: TCP
          name: somename
        defaultEndpoint: unix:///var/run/someuds.sock

So, From the egress description above, I expect that the ratings app may connect only with the details and ratings apps (the egress of the default sidecar) But on live cluster the behavior I get is that it can connect with all other services in my mesh (including productpage and reviews from bookinfo - default namespace) which means that the second sidecar overrides the first one - and cancels the “egress” connections specified in it even if the second sidecar does not include an egress field.

Can anyone , please, help me understand why this happens?

2

Because when Istio applies sidecar, it picks the sidecar with workload selector and applies. So the second one takes precendence.

3

I understand that the second sidecar takes precedence since it has a workloadSelector.
But, it doesn’t have an “egress” field in its spec, and the doc says that if this field is missing in the sidecar, it will be inherited from the first one . but this is not hapenning on live cluster

4

It is system detected defaults. Not the user provided. Istio does not merge sidecars.

1 Like