To manage the microservices in your application with Tanzu Service Mesh, you must onboard the clusters where the microservices are deployed. Onboarding involves registering the cluster with Tanzu Service Mesh and installing the necessary software on the cluster.
Some companies whose internal systems don't have direct access to the Internet, use a proxy server to connect outside. If a proxy server is configured in your corporate environment, when onboarding your cluster, specify that it will connect to Tanzu Service Mesh through a proxy server. All traffic between the cluster and Tanzu Service Mesh will be routed through the proxy server and will be encrypted using Transport Layer Security (TLS). All requests that are sent from the cluster to Tanzu Service Mesh will be authorized using access tokens.
During onboarding, you need to provide the settings of the proxy configuration in your environment. The Tanzu Service Mesh client software installed on the cluster, called Tanzu Service Mesh agent, uses the proxy configuration that you provide to connect to the proxy server.
If you attached a cluster that is running behind a proxy server to Tanzu Mission Control and enabled Tanzu Service Mesh on that cluster, Tanzu Mission Control automatically forwards the proxy configuration to Tanzu Service Mesh. The Tanzu Service Mesh agent on the cluster uses the proxy configuration to connect the cluster to Tanzu Service Mesh through the proxy server. You don't need to provide proxy configuration settings for clusters managed by Tanzu Mission Control in Tanzu Service Mesh.
If you want to first use Tanzu Service Mesh in your testing environment, you can onboard a clean cluster without microservices and namespaces and then deploy a sample application on the cluster. Connect Services Across Clusters with a Global Namespace in Using VMware Tanzu Service Mesh includes steps on how to deploy the services of a sample application on two clusters.
To secure the communications between the services in the service mesh, you can use self-signed Transport Layer Security (TLS) certificates issued by the Tanzu Service Mesh internal certificate authority or certificates issued by an external CA. Tanzu Service Mesh supports Venafi and Vault as external CAs.
To specify that the Tanzu Service Mesh internal CA is used to secure the service mesh, select the default CA label for a cluster during onboarding.
To specify that an external CA is used to secure the service mesh, select a label associated with that external CA's integration account for the cluster during onboarding. For example, to specify that Venafi is used as an external CA, select the CA label associated with a Venafi integration account for the cluster. As a result, the CA configuration from the integration account will be pushed to the services in the cluster during onboarding. You can get a CA label when you create an integration account for the external CA. For more information, see Create a Venafi Integration Account and Create a Vault CA Integration Account.
During onboarding, you can select which namespaces on your cluster are included. Including a namespace enables automatic Istio sidecar injection in the pods of that namespace. Include a namespace if you want the pods in that namespace to be part of the mesh. If you enable automatic Istio sidecar injection for a namespace, all new pods that are created in that namespace will automatically have a sidecar proxy added to them. For information about this feature called Namespace Onboarding Worklow, see Namespace Onboarding Workflow. For more information about sidecar proxy injection, also see the Istio documentation.
You can select a Cluster admin owned option to specify that you manage the labeling of namespaces for Istio sidecar injection in the cluster, and that Tanzu Service Mesh does not own namespace labeling. As a result, a cluster administrator will be able to create and manually label namespaces in the cluster as needed, without Tanzu Service Mesh overriding the manual labeling changes.
When you select the Cluster admin owned option, you delegate all responsibility for namespace labeling, including selection for inclusion, to the cluster administrator who operates the cluster. This means that the labeling of namespaces for inclusion with istio-injection=enabled
is delegated to the person that manages the cluster itself. This is useful when the person operating Tanzu Service Mesh and the person on the cluster are two different people. The options for selecting namespaces for inclusion and for creating namespace inclusion rules will not be visible or available in the Tanzu Service Mesh UI if Cluster admin owned is selected. For more information about the Cluster admin owned setting and how it affects namespace labeling, see Namespace Onboarding Workflow.
When the Cluster admin owned option is selected for a cluster, Tanzu Service Meshdelegates namespace labeling to the cluster administrator, so labeling for sidecar injection will be performed with kubectl. In this case, Tanzu Service Mesh no longer owns namespace labeling on the cluster and does not have visibility into the actual namespace labeling state.
If the Cluster admin owned option is deselected at a later stage, Tanzu Service Mesh may not have the most up-to-date state of labels on the namespaces. Consider the following example:
A user selects the Cluster admin owned option for a cluster to delegate all responsibility for namespace labeling to the cluster administrator.
The cluster administrator performs labeling on the cluster and sets
istio-injection=enabled
for a namespace on the cluster or removes a label that was previously set.If at a later stage the Tanzu Service Mesh administrator deselects the Cluster admin owned option for the cluster to return control over namespace labeling to Tanzu Service Mesh, the namespace inclusions list in the Edit Cluster dialog box for the cluster may not show the most up-to-date namespace inclusion state for Istio injection.
If the Cluster admin owned option is deselected, it is up to the Tanzu Service Meshadministrator to make sure that the namespaces that need to be injected with sidecars are selected and that no labels have been accidentally removed by Tanzu Service Mesh due to lack of constant visibility of the labeling state.
In a later release, a mechanism will be provided to reconcile the inclusions list when the ownership of namespace labeling is switched back and forth between Tanzu Service Meshand the cluster administrator.
Prerequisites
Verify that your environment meets the requirements listed in Tanzu Service Mesh Environment Requirements and Supported Platforms.
If you want to install Tanzu Service Mesh only in some of the namespaces of the cluster, decide beforehand which namespaces you want to exclude from Tanzu Service Mesh.
If you want the cluster to connect to Tanzu Service Mesh through your organization's web proxy server, make sure that you know the details of the proxy configuration, such as the type of proxy in use (transparent or explicit), the protocol (HTTP or HTTPS), the host name or IP address of the proxy server, and the port number.
If your corporate proxy server is configured to use a certificate for secure TLS connections, make sure that you know the location of the certificate file. The Tanzu Service Mesh agent on the cluster will use the certificate to connect to the proxy server and trust the connection.
If you want to use an external certificate authority (CA), for example, Venafi or Vault, to secure the service mesh, create an integration account for the external CA. For more information, see Create a Venafi Integration Account and Create a Vault CA Integration Account.
Procedure
Results
The Tanzu Service Mesh Console UI displays information about the infrastructure of the onboarded cluster and the microservices deployed there. Tanzu Service Mesh also starts monitoring and collecting infrastructure and service metrics from the cluster (such as number of nodes and services, requests per second, latency, and CPU usage). The Home page of the Tanzu Service Mesh Console provides summary information about the cluster's infrastructure, a topology view of the services in the cluster, and key metrics. For more information, see View the Summary Infrastructure and Service Information.
If you specified that the cluster connects to Tanzu Service Mesh through a corporate proxy server, you can view the provided proxy configuration settings in the Tanzu Service MeshConsole UI. For more information, see View the Proxy Configuration Settings in Using VMware Tanzu Service Mesh.
Currently, the proxy configuration that you provide in Tanzu Service Mesh cannot be edited. If the configuration of your proxy changes after the cluster is onboarded, you need to re-onboard the cluster and provide the updated configuration in the Onboard Clusters panel.
What to do next
If you have a multicluster or hybrid-cloud application, you can connect, secure, and manage the services in the application across the clusters with a global namespace. For more information, see Connect Services with a Global Namespace.
After you onboard a cluster, you may need to change the namespace exclusions that you have defined for it. For example, you have deployed a third-party service in a namespace on the cluster, and you don't want Tanzu Service Mesh to manage that service. In this example, you would edit the configuration for the cluster to add an exclusion for the namespace where the third-party service is deployed. For information about editing the configuration of a cluster, see Edit a Cluster.
You can monitor the connectivity between the cluster and Tanzu Service Mesh Software as a Service (SaaS) or, if a proxy server is used, between the cluster and the proxy server.