Using Istio across private and public clusters

Summary

If you decided to go the hybrid cloud route, you know it isn’t easy to manage all your different workloads. In this pattern, we’ll take a look at an app that consists of a web front end, a Redis leader for storage, and replicated set of Redis followers, and finally Kubernetes replication controllers, pods, and services. In the case of this sample application where users submit comments and Watson Tone Analyzer enhances the comment with an emoticon, we wanted to configure our multi-cluster so that the different microservices run on a Kubernetes cluster and a private cloud cluster. We establish communication between the clusters as the sample app calls the remote Tone Analyzer service, which itself calls the Watson Tone Analyzer service from the cloud.

Description

In this pattern, we create a hybrid cloud by connecting services between IBM Cloud Private and the IBM Cloud Kubernetes Service (IKS) clusters by using Istio. We assume that the IBM Cloud Private is not accessible from outside of the organization network but it can still access the IKS cluster. This allows us to set up bi-directional communications between the services running on IBM Cloud Private and IKS through a VPN tunnel initiated by the IBM Cloud Private cluster.

While the example application used within this pattern requires an IBM Cloud for its Watson Tone Analyzer, the pattern presented here can be used to integrate most of the private and public clusters.

• Connect a private and a public cloud by using a VPN tunnel.
• Distribute microservices between the private and public clusters, yet maintain bi-directional connectivity.
• Use Istio to conduct the multi-cluster traffic routing.

Flow

1. Users of the guestbook app use their browser to access the Guestbook web page served by the guestbook service from the public cloud.
2. When a guest submits a comment, the guestbook service needs to enrich it with an emoticon that’s based on the submitted text tone. The guestbook service calls the analyzer service with the submitted text for the tone analysis. The guestbook service calls the analyzer service as if it was a local service (the service/app hasn’t been modified to support remote services).
3. The analyzer service is running on the remote private cloud, therefore the call is routed by Istio through the VPN tunnel into the Ingress gateway of the private cloud.
4. The analyzer service calls the Watson Tone Analyzer service with the received text payload and gets back the tone analysis result from the public service.
5. Once the response from the analyzer service arrives, the guestbook app adds the matching emoticon to the submitted text in the web page.

Instructions

Ready to put this pattern to use? Complete details on how to get started running and using this application are in the README.