In this blog I demonstrate how easy it is to connect services securely across Kubernetes clusters and clouds, any cloud. But before I start, check this out, this is one of the coolest things and it was easy to create (images are clickable)
What I have got here is a single application running in all 3 major clouds and across regions as well. This application called “Acme Fitness” is a fully distributed micro-services application used for testing. You can check it out in the link above and use it as you wish. here is a view of the front page
I have it running in the following configuration:
- Two frontend services (the ones called shopping) one in GKE and one in AKS. These clusters are managed by our Tanzu Mission Control service.
- The backend services of the application, called Catalog, Users, Order and Cart, each one with it’s own DB, are running in two AWS zones: aws-west and aws-east
- All connection between the services are mTLS encrypted, no specialized gateways were deployed, this is service to service encryption.
- All services are configured to find each other by using a single service discovery domain which I called acme.local. This is part of the TSM Global namespace configuration (GNS)
- There are zero smoke and mirrors here. ZERO.
Small disclaimer. As cool as it is, this configuration that I created is one that no customer has yet to asked me to create. Even the most advanced customers are looking to have either a multi-kubernetes app in the same site, across sites, or between cloud and on-prem. But, why did I build this?
Because I can 😀
And to show the power of TSM and GNS (Global Namespaces). The layout of the services is a more real scenario, many customers would like to be able to have the freedom of placing their services where ever they wish and as they wish without physical or cluster boundaries considerations. Separating you application services to multpile places has many benefits, among them, reducing the blast radius, for tenancy purposes (team A on cluster A and team B on cluster B), operational purposes (separate stateless from stateful), for HA purposes, economic purposes and so on and so on. Also, there are many reasons why I would want to be able to move my stuff around as I wish, if for upgrading infra, kubernetes, new versions and so on. GNS in TSM allows me to place my services anywhere I want.
Ok, here is how this was created, step by step:
- At first I deployed the clusters of course in all 3 major clouds and attached them to Tanzu mission control (TMC). Actually the AWS clusters were created by TMC while Azure and GKE were only attached. TMC makes it super easy for me to operate clusters across clouds and switch them out if I need too by attcheing and detaching them from my TMC policies. here’s how it looks in my TMC console. (note – TMC is super cool and I urge you to check it out)
- Once the clusters were deployed in all clouds and managed by TMC (separate blog) , I moved on to onboard them in Tanzu Service Mesh (i’ll stick to calling it TSM from now, ok?). The onboarding process is fairly quick and painless. There are multiple ways to do it, through TMC, API but for this I used the dashboard as it is more visual. In the dashboard I Just clicked “Add New” and then “Onboard new cluster” as seen below:
- Then I provided a name for teh cluster and ran the Kubectl commands the system generates for me to connect it to the TSM service . TSM will automatically set all namespaces to be injected with the Envoy Proxies so this was all easy peasy
After all four cluster has been on-boarded, I installed on each the relevant part of the app and this is how my clusters view looks like on the dashboard:
Now to the fun part! How did I make all these pieces of my application to talk with each other?
- Did I code into the services themselves the endpoint information of each cloud , the clusters + namespaces they are running on? NO
- Did I setup sophisticated shared control planes that need to talk with each other from cloud to cloud so that it creates a cohesive mesh? NO
- Did I setup VPNs and gateways and CAs and DNSs so that all communications are encrypted? NO NO NO
All I did was add these clusters to a GNS and specify an environment variable in the app that tells the services to find each other by a domain name and boom! that’s is all you nee to do. Like this:
- Add new > Global Namespace
- Gave it a name (for this app it’s Acme) and gave it a domain name, this domain name is how the services will find each other
- I told GNS which services in each cluster are part of this app, in this case the “selector” was that they are in the default namespace
You can see the “service preview” of each to make sure these are the right ones
And lastly selected the mTLS policy for the GNS, which is of course Mandatory mTLS (no unecrypted traffic allowed!)
There are a few more screens I skipped, e.g for publishing the app through GSLB and for connecting to external services, but that for another blog post (I promise!)
- lastly I configured the frontend services in Azure and GKE to use the domain acme.local when contacting the backend services, this is done in teh deployment manifest like this (this is just one way to take advantage of the Service Discovery domain in TSM , it’s up to you and the developer how to call out services using this domain name)
The services now contact each other using a unified service discovery domain and with mTLS without regards to where they are running. I can just move them from cloud to cloud or cluster to cluster and I wouldn’t need to change a single line of code or configuration it’ll just work!
Just for the curious folks out there, this is what happened in the backend:
- In each cluster we automatically populated the “service Entries” for each service, which is basically DNS entries, for the domain acme.local
If I edit the service entry of the catalog service for example you will see that it has records for both aws-east and aws-west. This way the service knows where to get to without me needing to do configure anything in it and it get;’s updated dynamically if I add or delete or move stuff to other places
And it established mTLS based on trust we create between the cluster in the GNS.
There you have it. The easiest way ever to connect services across cluster and clouds, and the sexiest multi-cloud I have ever seen 😁
As usual, If you have ANY comments or remarks just place here, and
be social and share!
Leave a Reply