Use global.proxy.includeIPRanges instead of --includeIPRanges (#1450)

This commit is contained in:
Vadim Eisenberg 2018-06-06 15:03:27 +03:00 committed by Martin Taillefer
parent 4ca6239d85
commit bfb88620a7
2 changed files with 47 additions and 27 deletions

View File

@ -95,6 +95,7 @@ following table:
| `global.hub` | Specifies the HUB for most images used by Istio | registry/namespace | `docker.io/istionightly` |
| `global.tag` | Specifies the TAG for most images used by Istio | valid image tag | `circleci-nightly` |
| `global.proxy.image` | Specifies the proxy image name | valid proxy name | `proxyv2` |
| `global.proxy.includeIPRanges` | Specifies the IP ranges for which outbound traffic is redirected to Envoy | List of IP ranges in CIDR notation separated by the escaped comma `\,` . Use `*` to redirect all outbound traffic to Envoy | `*` |
| `global.imagePullPolicy` | Specifies the image pull policy | valid image pull policy | `IfNotPresent` |
| `global.controlPlaneSecurityEnabled` | Specifies whether control plane mTLS is enabled | true/false | `false` |
| `global.mtls.enabled` | Specifies whether mTLS is enabled by default between services | true/false | `false` |

View File

@ -23,6 +23,13 @@ or alternatively, to simply bypass the Istio proxy for a specific range of IPs.
* Start the [sleep](https://github.com/istio/istio/tree/master/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)
```
@ -155,23 +162,31 @@ to set a timeout rule on calls to the httpbin.org service.
## Calling external services directly
If you want to completely bypass Istio for a specific IP range,
you can configure the source service's Envoy sidecar to prevent it from
you can configure the Envoy sidecars to prevent them from
[intercepting](/docs/concepts/traffic-management/request-routing/#communication-between-services)
the external requests. This can be done using the `--includeIPRanges` option of
[istioctl kube-inject](/docs/reference/commands/istioctl/#istioctl kube-inject)
when starting the service.
the external requests. This can be done by setting the `global.proxy.includeIPRanges` variable of
[Helm](/docs/setup/kubernetes/helm-install/#customization-with-helm) and updating the `ConfigMap` _istio-sidecar-injector_ by `kubectl apply`. After _istio-sidecar-injector_ is updated, the value of `global.proxy.includeIPRanges` will affect all the future deployments of the application pods.
The simplest way to use the `--includeIPRanges` option is to pass it the IP range(s)
The simplest way to use the `global.proxy.includeIPRanges` variable is to pass it the IP range(s)
used for internal cluster services, thereby excluding external IPs from being redirected
to the sidecar proxy.
The values used for internal IP range(s), however, depends on where your cluster is running.
For example, with Minikube the range is 10.0.0.1&#47;24, so you would start the sleep service like this:
For example, with Minikube the range is 10.0.0.1&#47;24, so you would update your `ConfigMap` _istio-sidecar-injector_ like this:
```command
$ kubectl apply -f <(istioctl kube-inject -f samples/sleep/sleep.yaml --includeIPRanges=10.0.0.1/24)
```plain
$ helm template install/kubernetes/helm/istio <the flags you used to install Istio> --set global.proxy.includeIPRanges="10.0.0.1/24" -x templates/sidecar-injector-configmap.yaml | kubectl apply -f -
```
On IBM Cloud Private, use:
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`.
@ -185,37 +200,36 @@ On IBM Cloud Private, use:
service_cluster_ip_range: 10.0.0.1/24
```
1. Inject the `service_cluster_ip_range` to your application profile via `--includeIPRanges` to limit Istio's traffic interception to the service cluster IP range.
1. Use `--set global.proxy.includeIPRanges="10.0.0.1/24"`
```command
$ kubectl apply -f <(istioctl kube-inject -f samples/sleep/sleep.yaml --includeIPRanges=10.0.0.1/24)
```
#### IBM Cloud Kubernetes Service
On IBM Cloud Kubernetes Service, use:
Use `--set global.proxy.includeIPRanges="172.30.0.0/16\,172.20.0.0/16\,10.10.10.0/24"`
```command
$ kubectl apply -f <(istioctl kube-inject -f samples/sleep/sleep.yaml --includeIPRanges=172.30.0.0/16,172.20.0.0/16,10.10.10.0/24)
```
#### Google Container Engine (GKE)
On 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:
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
```
```command
$ kubectl apply -f <(istioctl kube-inject -f samples/sleep/sleep.yaml --includeIPRanges=10.4.0.0/14,10.7.240.0/20)
```
On Azure Container Service(ACS), use:
Use `--set global.proxy.includeIPRanges="10.4.0.0/14\,10.7.240.0/20"`
```command
$ kubectl apply -f <(istioctl kube-inject -f samples/sleep/sleep.yaml --includeIPRanges=10.244.0.0/16,10.240.0.0/16)
```
#### Azure Container Service(ACS)
After starting your service this way, the Istio sidecar will only intercept and manage internal requests
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.
@ -255,6 +269,11 @@ cloud provider specific knowledge and configuration.
$ kubectl delete -f samples/sleep/sleep.yaml
```
1. Update the `ConfigMap` _istio-sidecar-injector_ to redirect all outbound traffic to the sidecar proxies:
```plain
$ helm template install/kubernetes/helm/istio <the flags you used to install 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).