Currently, we recommend creating the knative-serving namespace and then installing the operator. If these operations are scripted the resulting Knative installation might end up with no Istio sidecars (even if sidecar injection is enabled in Istio and Knative). This is due to a race condition and the exact behavior was described here: https://issues.jboss.org/browse/MAISTRA-833?focusedCommentId=13774389&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-13774389

The problem is that Istio doesn't consider knative-serving namespace to be in the ServiceMeshMemberRoll at the moment the Knative Serving pods are being created. And thus it doesn't inject the sidecars.

In my case I could see that the istio-pilot logged knative-serving namespace as a member of the ServiceMeshMemberRoll one minute after the autoscaler pod was created:

autoscaler:startTime: "2019-08-28T06:46:41Z"

istio-pilot's first note about knative-serving namespace:

2019-08-28T06:47:34.659322Z info ServiceMeshMemberRoll default updated, namespaces now ["knative-serving" "istio-system"]  

Currently, it seems that the latest change we can wait for before creating Knative Serving pods is this status in ServiceMeshMemberRoll:

status:
  configuredMembers:
  - knative-serving