Managing Egress traffic patterns

There are three ways in which external services can be accessed from Istio:

By configuring an Istio sidecar to allow access to any external service (not recommended for large file transfers)
By using ServiceEntry to register an accessible external service from inside the service mesh
By configuring an Istio sidecar to exclude external IPs from its remapped IP table

Using the first approach, we can't take advantage of Istio monitoring and traffic routing capabilities for external services. It is recommended to use the ServiceEntry primitive of Istio as that will allow us to use Istio monitoring and routing capabilities for external services. For example, using the ServiceEntry approach, we can set timeout rules for external services. The third approach bypasses the Istio sidecar and allows our services to access external services directly.

We will explore the second approach to control access to external services using the Istio ServiceEntry primitive.

We installed Istio using a demo profile, which allows access to any external service. Let's get started:

Run the following command to find out the current outbound traffic policy mode:

$ kubectl -n istio-system get cm istio -o yaml | grep -m1 -o "mode: ALLOW_ANY"
mode: ALLOW_ANY

ALLOW_ANY mode permits access to external services from microservices.

Find out the ratings pod's IP address to test connectivity to an external service through our service mesh:

$ export RATING_POD=$(kubectl -n istio-lab get pods -l app=ratings -o jsonpath='{.items..metadata.name}') ; echo $RATING_POD
ratings-v1-79b6d99979-k2j7t

Run curl from the ratings pod to test https://www.ibm.com and check the http code status. If the connection is successful, we should get 200:

$ kubectl -n istio-lab exec -it -c ratings $RATING_POD -- curl -LI https://www.ibm.com | grep "HTTP/"
HTTP/2 303 --> Note that this is the HTTP code for the redirection of the URL
HTTP/2 200

$ kubectl -n istio-lab exec -it -c ratings $RATING_POD -- curl -LI https://www.cnn.com | grep "HTTP/"
HTTP/2 200

If you receive an error stating command terminated with exit code 6 or 35, this is an indication that the curl command is unable to resolve the hostname from inside the container. This is likely due to nameserver not being defined properly in the VM's /etc/resolv.conf file. Check whether the container can get the external IP address by using the kubectl -n istio-lab exec -it -c ratings $RATING_POD -- curl ifconfig.me command.

If curl succeeds and you still get an error, you might want to recycle the core-dns pods by using the kubectl -n kube-system delete pod -l k8s-app=kube-dns command.

Table of Contents for Managing Egress traffic patterns

Create new playlist

Sign In

Sign Up

Table of Contents for
Managing Egress traffic patterns