The following guide describes how to onboard a Kubernetes microservice to an OSM instance.
Refer to the application requirements guide before onboarding applications.
Configure and Install Service Mesh Interface (SMI) policies
OSM conforms to the SMI specification. By default, OSM denies all traffic communications between Kubernetes services unless explicitly allowed by SMI policies. This behavior can be overridden with the
--set=OpenServiceMesh.enablePermissiveTrafficPolicy=trueflag on the
osm installcommand, allowing SMI policies not to be enforced while allowing traffic and services to still take advantage of features such as mTLS-encrypted traffic, metrics, and tracing.
For example SMI policies, please see the following examples:
Onboard Kubernetes Namespaces to OSM
To onboard a namespace containing applications to be managed by OSM, run the
osm namespace addcommand, which does the equivalent of the following:
$ kubectl label namespace <namespace> openservicemesh.io/monitored-by=<mesh-name>
By default, the
osm namespace addcommand enables automatic sidecar injection for pods in the namespace. This does the equivalent of the following:
$ kubectl label namespace <namespace> openservicemesh.io/monitored-by=<mesh-name> $ kubectl annotate namespace <namespace> openservicemesh.io/sidecar-injection=enabled
To disable automatic sidecar injection as a part of enrolling a namespace into the mesh, use
osm namespace add <namespace> --disable-sidecar-injection. Once a namespace has been on-boarded, pods can be enrolled in the mesh by configuring automatic sidecar injection. See the Sidecar Injection document for more details.
Deploy new applications or redeploy existing applications
By default, new deployments in onboarded namespaces are enabled for automatic sidecar injection. This means that when a new Pod is created in a managed namespace, OSM will automatically inject the sidecar proxy to the Pod. Existing deployments need to be restarted so that OSM can automatically inject the sidecar proxy upon Pod re-creation. Pods managed by a Deployment can be restarted using the
kubectl rollout restart deploycommand.
In order to route protocol specific traffic correctly to service ports, configure the application protocol to use. Refer to the application protocol selection guide to learn more.
Note: Removing Namespaces
Namespaces can be removed from the OSM mesh with the
osm namespace remove command, which does the equivalent of the following:
$ kubectl label namespace <namespace> openservicemesh.io/monitored-by-
Please Note: The
osm namespace removecommand only tells OSM to stop applying updates to the sidecar proxy configurations in the namespace. It does not remove the proxy sidecars. This means the existing proxy configuration will continue to be used, but it will not be updated by the OSM control plane. If you wish to remove the proxies from all pods, remove the pods’ namespaces from the OSM mesh with the CLI and reinstall all the pod workloads.
This section describes how and why OSM monitors Kubernetes namespaces
This section describes the sidecar injection workflow in OSM.
Application Protocol Selection
Was this page helpful?
Glad to hear it! Please tell us how we can improve.
Sorry to hear that. Please tell us how we can improve.