Using Istio with Red Hat OpenShift and Kubernetes makes life with microservices easier. Tucked away inside of Kubernetes pods, using the Istio service mesh, your code can run (mostly) in isolation. Performance, ease-of-changes, tracing, and so on are made available by simply using the Istio sidecar container model. But what if you want your microservice to talk to another service that is outside of your OpenShift/Kubernetes/pods environment?
Enter Istio Egress.
[This is part nine of my ten-part Introduction to Istio Service Mesh series. My previous article was Part 8: Istio Smart Canary Launch: Easing into Production.]
Bin There, Done That
Istio Egress, put simply, allows you to access resources (read: services) outside of your Kubernetes pods. In an out-of-the-box Istio-enabled environment, traffic is routed within and between the clusters of pods based on internal IP tables. This walled-off approach is fine...until you need to access a service elsewhere.
Egress gives you the power to bypass those IP tables, either based on Egress rules or for a range of IP addresses.
As an example, we'll use a Java program that makes a GET request to httpbin.org/headers.
(If you're not familiar with httpbin.org, it's a great resource for testing outgoing service requests.)
If I simply run curl http://httpbin.org/headers from the command line, I'll see the following:
If I point my browser to the URL, I see this:
Clearly, the test is doing its job and returning the headers passed into it.
Thinking Inside the Box
Next, I'll take some Java code that uses this URL and run that code inside of Istio. (You can do this yourself by visiting our Istio tutorial.) After building the image and running it in OpenShift, I can invoke it using curl egresshttpbin-istioegress.$(minishift ip).nip.io, which gives me this:
Wait. What just happened? It was working a few minutes ago. What do you mean "Not Found"?? It's right there! I just curl-ed it.
Bring the Web to the (IP) Tables
Blame (or thank) Istio. Remember: Istio is a sidecar container that is handling your discovery and routing (and a bunch of other stuff, as the past eight weeks' blog posts have pointed out). Because of this, the IP tables are limited to your internal services. Since httpbin.org is outside of our cluster, it's not available. That's where Istio Egress comes to the rescue.
Again.
Without changing your source code.
Again.
By implementing the following Egress rule, we can direct Istio to look out (across the vast world wide web, if you will) to find a service—in this case, httpbin.org. As you can see from this file (egress_httpbin.yml), the functionality is rather obvious:
Implementing this rule is as simple as a one-liner:
istioctl create -f egress_httpbin.yml -n istioegress
I can then see the Egress rule by using the command istioctl get egressrules:
Finally, I can run the curl command again and see the correct results:
Thinking Outside the Box
As you can see, Istio works well with others. While you can create OpenShift services, managed by Kubernetes, and keep everything in pods and scale up and down as necessary, you still have the ability to reach outside of your environment to use services—without changing your source code...have I ever mentioned that?
All articles in the “Introduction to Istio” series:
- Part 1: Introduction to Istio Service Mesh
- Part 2: Istio Route Rules: Telling Service Requests Where to Go
- Part 3: Istio Circuit Breaker: How to Handle (Pool) Ejection
- Part 4: Istio Circuit Breaker: When Failure Is an Option
- Part 5: Istio Tracing & Monitoring: Where Are You and How Fast Are You Going?
- Part 6: Istio Chaos Engineering: I Meant to Do That
- Part 7: Istio Dark Launch: Secret Services
- Part 8: Istio Smart Canary Launch: Easing into Production
- Part 9: Istio Egress: Exit Through the Gift Shop
- Part 10: Istio Service Mesh Blog Series Recap