OpenShift Serverless 1.5.0 will stop using Service Mesh

[bbrowning]

This is a heads-up that the next planned release of OpenShift Serverless - 1.5.0 - will stop depending on or using Service Mesh out of the box. This is the last big change we plan to make around ingress/istio/service mesh integration before our GA release. This means two things for Kabanero.

First, it means unless you explicitly need Service Mesh for other reasons, once you update to OpenShift Serverless 1.5.0 you will no longer need Service Mesh and its dependencies as a prerequisite.

Secondly, it means that Knative Services will no longer be part of or integrated with any Service Mesh by default. If you rely on this to enable specific user scenarios, we should discuss what those are and how or if those use cases can continue to be satisfied.

[kaczyns]

@bbrowning Thanks for the heads up!

@stephenkinder @ralanlittle You have both mentioned previously that Service Mesh / Istio will be required for application use. It would be good to discuss those with @bbrowning to be sure that everything is copacetic.

[dacleyra]

Discovery to-do

1. is there an upgrade path for the operator itself, from 1.4.0 to 1.5.0? Maybe just observe what happens, starting with a system that has 1.4.0 installed, then moving to 1.5.0. Does the service mesh stuff get cleaned up automatically, and replaced with Kourier stuff?

• The upgrade via OLM seems clean, no issues
• the smmr and mscp instances are gone, following the upgrade
• kourier is present as the ingress function in namespace knative-serving-ingress

2. If someone has Knative Services created from 1.4.0, and we update to 1.5.0, what happens to them? do they continue to work on 1.5.0?

• Yes, looks good. Tried it with an appsody app that deployed as ksvc

3. If our install script continues to deploy service mesh, even though serverless is not using it, does the service mesh get in the way of anything? can a customer continue to use it for their own purposes? I don't think we need to go overboard testing this, but if you see anything that seems like it would cause a problem right off the bat, it would be good to know.

• The operator itself is existing ok side by side. They would deploy an smcp and smmr in whatever other namespace they want.
• Via knative documentation, the switch for ingress class is in this object kubectl get configmap/config-network -n knative-serving -o=yaml
• Granted, I don't know what configurations will be blessed & supported

[bbrowning]

For 3. above, you can continue to use Service Mesh in the cluster with our OpenShift Serverless 1.5.0 release without any inherent conflicts. We do not intend to support changing the ingress class from Kourier to Istio and we no longer ship the Knative networking-istio plugin so changing to the Istio ingress class would not work out of the box.

With that said, I have successfully tested creating my own ServiceMeshControlPlane, enrolling specific namespaces containing Knative Services into that SMCP (but NOT the knative-serving or knative-serving-ingress namespaces), and enabling mesh sidecars for those Knative Services using the sidecar.istio.io/inject: true annotation on the container template. The only extra thing required is creating a NetworkPolicy in any namespace using Knative Services to allow ingress/egress traffic from the knative-serving and knative-serving-ingress namespaces since Service Mesh locks down all network traffic outside the mesh with NetworkPolicy by default. We don't yet have documentation outlining how to do this, but it's something we'll work on.

The summary is with our switch to Kourier you can integrate with Service Mesh / Istio just like you'd do for any other application running under Service Mesh or Istio that needs to speak with services outside the mesh. Theoretically, it should be possible to put all of the Knative control and data planes inside the mesh as well using standard Istio methods but I haven't tested that.

[kaczyns]

I am closing this issue, as we've migrated to Serverless 1.5.0 in Kabanero 0.8.0.