mirror of https://github.com/istio/istio.io.git
Remove egress tcp task (#1548)
* remove egress TCP task the example can be implemented by HTTPS Service Entries * remove a reference to Egress TCP Task in Egress TCP blog * replace a reference to the Egress TCP task by the Egress TCP blog post in About -> Feature Status -> Istio features/Traffic management * add an alias from the removed task to Egress/TCP blog post
This commit is contained in:
Vadim Eisenberg
Martin Taillefer
parent
5e059b6f16
commit
5cbb89414e
|
|
@ -41,7 +41,7 @@ Below is our list of existing features and their current phases. This informatio
|
|||
| [Mirroring](/docs/tasks/traffic-management/mirroring/) | Alpha
|
||||
| [Ingress Traffic](/docs/tasks/traffic-management/ingress/) | Alpha
|
||||
| [Egress Traffic](/docs/tasks/traffic-management/egress/) | Alpha
|
||||
| [Egress TCP Traffic](/docs/tasks/traffic-management/egress-tcp/) | Alpha
|
||||
| [Egress TCP Traffic](/blog/2018/egress-tcp/) | Alpha
|
||||
| [Improved Routing Rules: Composite Service](/docs/reference/config/istio.networking.v1alpha3/) | Alpha
|
||||
| [Quota / Redis Rate Limiting (Adapter and Server)](/docs/tasks/policy-enforcement/rate-limiting/) | Alpha
|
||||
| [Memquota Implementation and Integration](/docs/tasks/telemetry/metrics-logs/) | Stable
|
||||
|
|
|
|||
|
|
@ -5,6 +5,8 @@ publishdate: 2018-02-06
|
|||
subtitle: Egress rules for TCP traffic
|
||||
attribution: Vadim Eisenberg
|
||||
weight: 92
|
||||
aliases:
|
||||
- /docs/tasks/traffic-management/egress-tcp/
|
||||
keywords: [traffic-management,egress,tcp]
|
||||
---
|
||||
|
||||
|
|
@ -251,7 +253,7 @@ To enable TCP traffic to an external service by its hostname, all the IPs of the
|
|||
|
||||
Note that all the IPs of an external service are not always known. To enable TCP traffic by IPs, as opposed to the traffic by a hostname, only the IPs that are used by the applications must be specified.
|
||||
|
||||
Also note that the IPs of an external service are not always static, for example in the case of [CDNs](https://en.wikipedia.org/wiki/Content_delivery_network). Sometimes the IPs are static most of the time, but can be changed from time to time, for example due to infrastructure changes. In these cases, if the range of the possible IPs is known, you should specify the range by CIDR blocks (even by multiple egress rules if needed). As an example, see the approach we used in the case of `wikipedia.org`, described in [Control Egress TCP Traffic Task](/docs/tasks/traffic-management/egress-tcp/). If the range of the possible IPs is not known, egress rules for TCP cannot be used and [the external services must be called directly](/docs/tasks/traffic-management/egress/#calling-external-services-directly), circumventing the sidecar proxies.
|
||||
Also note that the IPs of an external service are not always static, for example in the case of [CDNs](https://en.wikipedia.org/wiki/Content_delivery_network). Sometimes the IPs are static most of the time, but can be changed from time to time, for example due to infrastructure changes. In these cases, if the range of the possible IPs is known, you should specify the range by CIDR blocks (even by multiple egress rules if needed). If the range of the possible IPs is not known, egress rules for TCP cannot be used and [the external services must be called directly](/docs/tasks/traffic-management/egress/#calling-external-services-directly), circumventing the sidecar proxies.
|
||||
|
||||
## Relation to mesh expansion
|
||||
|
||||
|
|
@ -315,8 +317,4 @@ In this blog post, I demonstrated how the microservices in an Istio service mesh
|
|||
|
||||
## What's next
|
||||
|
||||
To read more about Istio egress traffic control:
|
||||
|
||||
* for TCP, see [Control Egress TCP Traffic Task](/docs/tasks/traffic-management/egress-tcp/)
|
||||
|
||||
* for HTTP/HTTPS, see [Control Egress Traffic Task](/docs/tasks/traffic-management/egress/)
|
||||
To read more about Istio egress traffic control, see [Control Egress Traffic Task](/docs/tasks/traffic-management/egress/).
|
||||
|
|
|
|||
|
|
@ -1,106 +0,0 @@
|
|||
---
|
||||
title: Control Egress TCP Traffic
|
||||
description: Describes how to configure Istio to route TCP traffic from services in the mesh to external services.
|
||||
weight: 41
|
||||
keywords: [traffic-management,egress,tcp]
|
||||
---
|
||||
|
||||
> 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/).
|
||||
|
||||
The [Control Egress Traffic](/docs/tasks/traffic-management/egress/) task demonstrates how external (outside the Kubernetes cluster) HTTP and HTTPS services can be accessed from applications inside the mesh. A quick reminder: by default, Istio-enabled applications are unable to access URLs outside the cluster. To enable such access, a [ServiceEntry](/docs/reference/config/istio.networking.v1alpha3/#ServiceEntry) for the external service must be defined, or, alternatively, [direct access to external services](/docs/tasks/traffic-management/egress/#calling-external-services-directly) must be configured.
|
||||
|
||||
This task describes how to configure Istio to expose external TCP services to applications inside the Istio service mesh.
|
||||
|
||||
## Before you begin
|
||||
|
||||
* Setup Istio by following the instructions in the
|
||||
[Installation guide](/docs/setup/).
|
||||
|
||||
* Start the [sleep](https://github.com/istio/istio/blob/{{<branch_name>}}/samples/sleep) sample application which will be used as a test source for external calls.
|
||||
|
||||
```command
|
||||
$ kubectl apply -f <(istioctl kube-inject -f @samples/sleep/sleep.yaml@)
|
||||
```
|
||||
|
||||
**Note**: any pod that you can execute `curl` from is good enough.
|
||||
|
||||
## Using Istio service entries to enable external TCP traffic
|
||||
|
||||
In this task we access `wikipedia.org` by HTTPS originated from the application. This task demonstrates the use case where an application cannot use HTTP with TLS origination by the sidecar proxy. Using HTTP with TLS origination by the sidecar proxy is described in the [Control Egress Traffic](/docs/tasks/traffic-management/egress/) task. In that task, `https://google.com` was accessed by issuing HTTP requests to `http://www.google.com:443`.
|
||||
|
||||
The HTTPS traffic originated from the application will be treated by Istio as _opaque_ TCP. To enable such traffic, we define a TCP `ServiceEntry` on port 443. In TCP service entries, as opposed to HTTP-based ones, the destinations are specified by IPs or by blocks of IPs in [CIDR notation](https://tools.ietf.org/html/rfc2317).
|
||||
|
||||
Let's assume for the sake of this example that we want to access `wikipedia.org` by the domain name. This means that we have to specify all the IPs of `wikipedia.org` in our TCP `ServiceEntry`. Fortunately, the IPs of `wikipedia.org` are published [here]( https://www.mediawiki.org/wiki/Wikipedia_Zero/IP_Addresses). It is a list of IP blocks in [CIDR notation](https://tools.ietf.org/html/rfc2317): `91.198.174.192/27`, `103.102.166.224/27`, and more.
|
||||
|
||||
## Creating a service entry
|
||||
|
||||
Let's create a `ServiceEntry` to enable TCP access to `wikipedia.org`:
|
||||
|
||||
```bash
|
||||
cat <<EOF | istioctl create -f -
|
||||
apiVersion: networking.istio.io/v1alpha3
|
||||
kind: ServiceEntry
|
||||
metadata:
|
||||
name: wikipedia-ext
|
||||
spec:
|
||||
hosts:
|
||||
- wikipedia.org
|
||||
addresses:
|
||||
- 91.198.174.192/27
|
||||
- 103.102.166.224/27
|
||||
- 198.35.26.96/27
|
||||
- 208.80.153.224/27
|
||||
- 208.80.154.224/27
|
||||
ports:
|
||||
- number: 443
|
||||
protocol: TCP
|
||||
name: tcp-port
|
||||
resolution: NONE
|
||||
EOF
|
||||
```
|
||||
|
||||
This command instructs the Istio proxy to forward requests on port 443 of any of the `wikipedia.org` IP addresses to the same IP address to which the connection was bound.
|
||||
|
||||
## Access wikipedia.org by HTTPS
|
||||
|
||||
1. `kubectl exec` into the pod to be used as the test source. If you are using the [sleep](https://github.com/istio/istio/blob/{{<branch_name>}}/samples/sleep) application, run the following command:
|
||||
|
||||
```command
|
||||
$ kubectl exec -it $(kubectl get pod -l app=sleep -o jsonpath={.items..metadata.name}) -c sleep bash
|
||||
```
|
||||
|
||||
1. Make a request and verify that we can access https://www.wikipedia.org successfully:
|
||||
|
||||
```command
|
||||
$ curl -o /dev/null -s -w "%{http_code}\n" https://www.wikipedia.org
|
||||
200
|
||||
```
|
||||
|
||||
We should see `200` printed as the output, which is the HTTP code _OK_.
|
||||
|
||||
1. Now let's fetch the current number of the articles available on Wikipedia in the English language:
|
||||
|
||||
```command
|
||||
$ curl -s https://en.wikipedia.org/wiki/Main_Page | grep articlecount | grep 'Special:Statistics'
|
||||
<div id="articlecount" style="font-size:85%;"><a href="/wiki/Special:Statistics" title="Special:Statistics">5,563,121</a> articles in <a href="/wiki/English_language" title="English language">English</a></div>
|
||||
```
|
||||
|
||||
This means there were 5,563,121 articles in Wikipedia in English when this task was written.
|
||||
|
||||
## Cleanup
|
||||
|
||||
1. Remove the `ServiceEntry` we created.
|
||||
|
||||
```command
|
||||
$ istioctl delete serviceentry wikipedia-ext
|
||||
```
|
||||
|
||||
1. Shutdown the [sleep](https://github.com/istio/istio/blob/{{<branch_name>}}/samples/sleep) application.
|
||||
|
||||
```command
|
||||
$ kubectl delete -f @samples/sleep/sleep.yaml@
|
||||
```
|
||||
|
||||
## What's next
|
||||
|
||||
* Learn more about [service entries](/docs/concepts/traffic-management/rules-configuration/#service-entries).
|
||||
Loading…
Reference in New Issue