--- title: Control Egress Traffic description: Describes how to configure Istio to route traffic from services in the mesh to external services. weight: 40 aliases: - /docs/tasks/egress.html keywords: [traffic-management,egress] --- > This task uses the new [v1alpha3 traffic management API](/blog/2018/v1alpha3-routing/). The old API has been deprecated and will be removed in the next Istio release. If you need to use the old version, follow the docs [here](https://archive.istio.io/v0.7/docs/tasks/traffic-management/). By default, Istio-enabled services are unable to access URLs outside of the cluster because iptables is used in the pod to transparently redirect all outbound traffic to the sidecar proxy, which only handles intra-cluster destinations. This task describes how to configure Istio to expose external services to Istio-enabled clients. You'll learn how to enable access to external services by defining [ServiceEntry](/docs/reference/config/istio.networking.v1alpha3/#ServiceEntry) configurations, or alternatively, to simply bypass the Istio proxy for a specific range of IPs. ## Before you begin * Setup Istio by following the instructions in the [Installation guide](/docs/setup/). * Start the [sleep](https://github.com/istio/istio/tree/{{}}/samples/sleep) sample which will be used as a test source for external calls. If you have enabled [automatic sidecar injection](/docs/setup/kubernetes/sidecar-injection/#automatic-sidecar-injection), do ```command $ kubectl apply -f @samples/sleep/sleep.yaml@ ``` otherwise, you have to manually inject the sidecar before deploying the `sleep` application: ```command $ kubectl apply -f <(istioctl kube-inject -f @samples/sleep/sleep.yaml@) ``` Note that any pod that you can `exec` and `curl` from would do. ## Configuring Istio external services Using Istio `ServiceEntry` configurations, you can access any publicly accessible service from within your Istio cluster. In this task we will use [httpbin.org](http://httpbin.org) and [www.google.com](https://www.google.com) as examples. ### Configuring the external services 1. Create an `ServiceEntry` to allow access to an external HTTP service: ```bash cat < --set global.proxy.includeIPRanges="10.0.0.1/24" -x @templates/sidecar-injector-configmap.yaml@ | kubectl apply -f - ``` Note that you should use the same Helm command you used [to install Istio](/docs/setup/kubernetes/helm-install), in particular, the same value of the `--namespace` flag. In addition to the flags you used to install Istio, add `--set global.proxy.includeIPRanges="10.0.0.1/24" -x templates/sidecar-injector-configmap.yaml`. Redeploy the _sleep_ application as described in the [Before you begin](/docs/tasks/traffic-management/egress/#before-you-begin) section. ### Determine the value of `global.proxy.includeIPRanges` Set the value of `global.proxy.includeIPRanges` according to your cluster provider. #### IBM Cloud Private 1. Get your `service_cluster_ip_range` from IBM Cloud Private configuration file under `cluster/config.yaml`. ```command $ cat cluster/config.yaml | grep service_cluster_ip_range ``` A sample output is as following: ```plain service_cluster_ip_range: 10.0.0.1/24 ``` 1. Use `--set global.proxy.includeIPRanges="10.0.0.1/24"` #### IBM Cloud Kubernetes Service Use `--set global.proxy.includeIPRanges="172.30.0.0/16\,172.20.0.0/16\,10.10.10.0/24"` #### Google Container Engine (GKE) The ranges are not fixed, so you will need to run the `gcloud container clusters describe` command to determine the ranges to use. For example: ```command $ gcloud container clusters describe XXXXXXX --zone=XXXXXX | grep -e clusterIpv4Cidr -e servicesIpv4Cidr clusterIpv4Cidr: 10.4.0.0/14 servicesIpv4Cidr: 10.7.240.0/20 ``` Use `--set global.proxy.includeIPRanges="10.4.0.0/14\,10.7.240.0/20"` #### Azure Container Service(ACS) Use `--set global.proxy.includeIPRanges="10.244.0.0/16\,10.240.0.0/16` #### Minikube Use `--set global.proxy.includeIPRanges="10.0.0.1/24"` ### Access the external services After updating the `ConfigMap` _istio-sidecar-injector_ and redeploying the _sleep_ application, the Istio sidecar will only intercept and manage internal requests within the cluster. Any external request will simply bypass the sidecar and go straight to its intended destination. ```command $ export SOURCE_POD=$(kubectl get pod -l app=sleep -o jsonpath={.items..metadata.name}) $ kubectl exec -it $SOURCE_POD -c sleep curl http://httpbin.org/headers ``` ## Understanding what happened In this task we looked at two ways to call external services from an Istio mesh: 1. Using a `ServiceEntry` (recommended) 1. Configuring the Istio sidecar to exclude external IPs from its remapped IP table The first approach (`ServiceEntry`) allows you to use all of the same Istio service mesh features for calls to services within or outside of the cluster. We demonstrated this by setting a timeout rule for calls to an external service. The second approach bypasses the Istio sidecar proxy, giving your services direct access to any external URL. However, configuring the proxy this way does require cloud provider specific knowledge and configuration. ## Cleanup 1. Remove the rules. ```command $ istioctl delete serviceentry httpbin-ext google-ext $ istioctl delete virtualservice httpbin-ext ``` 1. Shutdown the [sleep](https://github.com/istio/istio/tree/{{}}/samples/sleep) service. ```command $ kubectl delete -f @samples/sleep/sleep.yaml@ ``` 1. Update the `ConfigMap` _istio-sidecar-injector_ to redirect all outbound traffic to the sidecar proxies: ```command $ helm template @install/kubernetes/helm/istio@ -x @templates/sidecar-injector-configmap.yaml@ | kubectl apply -f - ``` ## What's next * Learn more about [service entries](/docs/concepts/traffic-management/rules-configuration/#service-entries). * Learn how to setup [timeouts](/docs/reference/config/istio.networking.v1alpha3/#HTTPRoute-timeout), [retries](/docs/reference/config/istio.networking.v1alpha3/#HTTPRoute-retries), and [circuit breakers](/docs/reference/config/istio.networking.v1alpha3/#OutlierDetection) for egress traffic.