Using Istio across private and public clusters
Construct a hybrid cloud by connecting services between private and public Kubernetes clusters
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 master for storage, and replicated set of Redis slaves, 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.
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.
- Users of the
guestbookapp use their browser to access the Guestbook web page served by the
guestbookservice from the public cloud.
- When a guest submits a comment, the
guestbookservice needs to enrich it with an emoticon that’s based on the submitted text tone. The
guestbookservice calls the
analyzerservice with the submitted text for the tone analysis. The
guestbookservice calls the
analyzerservice as if it was a local service (the service/app hasn’t been modified to support remote services).
analyzerservice 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.
analyzerservice calls the Watson Tone Analyzer service with the received text payload and gets back the tone analysis result from the public service.
- Once the response from the
analyzerservice arrives, the
guestbookapp adds the matching emoticon to the submitted text in the web page.
Ready to put this pattern to use? Complete details on how to get started running and using this application are in the README.