I’ve finally found the time to dive into Tanzu Service Mesh (TSM), a product which has intrigued me greatly. In this blog post I cover setting up TSM, and configuring application connectivity between two clusters running in different public clouds.
What is a Service Mesh?
In software architecture, a service mesh is a dedicated infrastructure layer for facilitating service-to-service communications between services or micro-services, using a proxy. This then provides additional capability such as transit layer between platforms, observability, traffic management and more.
A service mesh provides the capability to secure and simplify your application communications between platforms/clusters/clouds without the need for introduction of lots of other software such as API Gateways.
A service mesh introduces a proxy component which sits side by side with any deployed service. And any inbound and outbound communication flows through the proxy to/from the service. This allows the proxy to provide all the functions needed to offer the capabilities discussed above and in the rest of this blog post.
What is Tanzu Service Mesh (TSM)?
TSM builds upon the principals mentioned above, offering consumers a full enterprise-class service mesh, designed to solve challenges across distributed micro-service applications by extending service mesh services outside Kubernetes clusters and providing a unified operational layer across platforms and technologies.
-
Extends the service mesh capability (discovery, connectivity, control, security, and observability) to users and data, and across clusters and clouds.
-
Facilitates the development and management of distributed applications across multiple clusters, multiple clouds, and in hybrid-cloud environments with Global Namespaces (discussed below), supporting federation across organizational boundaries, technologies, and service meshes.
-
Implements consistent application-layer traffic management and security policies across all your clusters and clouds.
Global Namespace – is a key concept introduced by TSM, that extends service mesh capabilities for resources in a distributed application by arranging these objects in a logical group. A global namespace is therefore not tied to a single cluster or cloud, connecting resources between two or more clusters/clouds. Each global namespace manages service discovery, observability, encryption, policies, and service-level objectives (SLOs) for its objects regardless of where they reside: in multiple clusters, sites, or clouds.
To learn more about the concepts introduced by TSM, please read the below document:
TSM provides the value of a transit between clusters and clouds. In doing so comes many challenges, one such is achieving end-to-end encryption for in-flight traffic. This can be mandatory to comply with regulatory and security governance measures.
Tanzu Service Mesh includes a top-level certificate authority (CA) to provide a trusted identity to each node on the network. In the case of microservices architecture, those nodes are the pods that run the services. Tanzu Service Mesh can set up end-to-end mutual transport layer security (mTLS) encryption using a CA function.
Activating Tanzu Service Mesh
TSM is a SaaS service only from VMware, meaning no on-premises deployment for the control plane aspect. To activate, you will click the link provided when you request a trial or purchase the product,and linking it to your VMware Cloud Services Organisation (or create a new org if necessary.)
You must belong to an organization before you can access Tanzu Service Mesh.
If you are an organization owner, you have access to all the resources of the organization. You can add cloud services to your organization and then invite users.
After you add Tanzu Service Mesh to your organization, you can add users to the organization to give them access to Tanzu Service Mesh.
For more information about organizations and adding users to an organization, see the VMware Cloud Services documentation.
Once you’ve activated the product, you will see it in your Cloud Services Portal as below.
Pre-requisites for Installation
This is something which caused me issues in the past, where I tried to deploy TSM to a cluster that did not have enough resources to begin with.
- Cluster with 6 nodes (though the documentation does say minimum of 3 lower down in the text)
> I've queried this
- Requires that every node in the cluster have at least 250 milliCPU and 650 MB of memory available
- Pod Limits - Requires a quota of at least 3 pods for each node on the cluster and additionally at least 30 pods for the whole cluster.
Basically, you need to make sure you have enough minimum nodes and resources.
Regarding supported Kubernetes distributions, the team validate against a number of Enterprise Kubernetes solutions as well as the upstream Kubernetes.
I deployed two new environments for my testing, an EKS and AKS cluster, with the following commands.
eksctl create cluster --name veducate-eks-tsm --region us-west-1 --nodegroup-name standard --node-type m5.xlarge --managed
az aks create -rg aks-tsm --name aks-tsm-cluster --node-count 4 --ssh-key $HOME/.ssh/id_rsa.pub -s standard_d4s_v5
Onboarding your Clusters into Tanzu Service Mesh
Onboarding involves registering the cluster with Tanzu Service Mesh and installing the necessary software on the cluster. Continue reading Tanzu Service Mesh – First look at deploy, configure and managing an app between clusters →
