Tag Archives: Tanzu Service Mesh

vRA GKE Header

vRealize Automation – Deploying a GKE Cluster with Code Stream, add to Tanzu Mission Control & Tanzu Service Mesh

This walk-through will detail the technical configurations for using vRA Code Stream to deploy Google Kubernetes Clusters (GKE), register them as:

  • Kubernetes endpoints in vRA Cloud Assembly and Code Stream
  • An attached in Tanzu Mission Control
  • Onboard in Tanzu Service Mesh

This post mirrors my other blog posts following similar concepts:


After covering EKS and AKS, I thought it was worthwhile to finish off the gang and deploy GKE clusters using Code Stream.

Building on my previous work, I also added in the extra steps to onboard this cluster into Tanzu Service Mesh as well.

High Level Steps
  • Create a Code Stream Pipeline
    • Create a Google GKE Cluster
    • Create GKE cluster as endpoint in both vRA Code Stream and Cloud Assembly
    • Register GKE cluster in Tanzu Mission Control
    • Onboard the cluster to Tanzu Service Mesh
Creating a Code Stream Pipeline to deploy a Azure AKS Cluster and register the endpoints with vRA and Tanzu Mission Control
Create the variables to be used

Continue reading vRealize Automation – Deploying a GKE Cluster with Code Stream, add to Tanzu Mission Control & Tanzu Service Mesh

Tanzu Blog Logo Header

Tanzu Service Mesh – Monitor Service Level Objectives and Configure Service Autoscaling

Continuing from the First Look blog post, where we created a distributed application between different public cloud Kubernetes deployments and connected them via Tanzu Service Mesh. We will move onto some of the more advanced capabilities of Tanzu Service Mesh.

In this blog post, we’ll look at how we can setup monitoring of our application components and performance against a Service Level Objective, and then how Tanzu Mission Control and action against violations of the SLO using auto-scaling capabilities.

What is a Service Level Objective and how do we monitor our app?

Service level objectives (SLO/s) provide a structured way to describe, measure, and monitor the performance, quality, and reliability of micro-service apps.

A SLO is used to describe the high-level objective for acceptable operation and health of one or more services over a length of time (for example, a week or a month).

  • For example, Service X should be healthy 99.1% of the time.

In the provided example, Service X can be “unhealthy” 1% of the time, which is considered an “Error Budget”. This allows for downtime for errors that are acceptable (keeping an app up 100% of the time is hard and expensive to achieve), or for the likes of planned routine maintenance.

The key is the specification of which metrics or characteristics, and associated thresholds are used to define the health of the micro-service/application.

  • For example:
    • Error rate is less than 2%
    • CPU Average is Less than 80%

This specification makes up the Service Level Indicator (SLI/s), of which one or multiple can be used to define an overall SLO.

Tanzu Service Mesh SLOs options

Before we configure, let’s quickly discuss what is available to be configured.

Tanzu Service Mesh (TSM) offers two SLO configurations:

  • Monitored SLOs
    • These provide alerting/indicators on performance of your services and if they meet your target SLO conditions based on the configured SLIs for each specified service.
    • This kind of SLO can be configured for Services that are part of a Global Namespace (GNS-scoped SLOs) or services that are part of a direct cluster (org-scoped SLOs).
  • Actionable SLOs
    • These extend the capabilities of Monitored SLOs by providing capabilities such as auto-scaling for services based on the SLIs.
    • This kind of SLO can only be configured for services inside a Global Namespace (GNS-scoped SLO).
    • Each actionable SLO can have only have one service, and a service can only have one actionable SLO.

The official documentation also takes you through some use-cases for SLOs. Alternatively, you can continue to follow this blog post for an example.

Quick overview of the demo environment
  • Tanzu Service Mesh (of course)
    • Global Namespace configured for default namespace in clusters with domain “app.sample.com”
  • Three Kubernetes Clusters with a scaled-out application deployed
    • AWS EKS Cluster
      • Running web front end (shopping) and cart instances
    • Azure AKS Cluster
      • Running Catalog Service that holds all the images for the Web front end
    • GCP GKE
      • Running full copy of the application

In this environment, I’m going to configure a SLO which is focused on the Front-End Service – Shopping, and will scale up the number of pods when the SLIs are breached.

Configure a SLO Policy and Autoscaler
  • Under the Policies header, expand
  • Select “SLOs”
  • Select either New Policy options

Continue reading Tanzu Service Mesh – Monitor Service Level Objectives and Configure Service Autoscaling

Tanzu Blog Logo Header

Tanzu Service Mesh – First look at deploy, configure and managing an app between clusters

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:

Tanzu Service Mesh - Logical Overview

Encryption for Data in Flight

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.

VMware Cloud Services - Tanzu Service Mesh

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