istio
/
istio.io
mirror of https://github.com/istio/istio.io.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Add traffic requirements documentation (#8349) 

* Add traffic requirements documentation

* Move things around

* Apply suggestions from code review

Co-authored-by: Frank Budinsky <frankb@ca.ibm.com>

* Apply suggestions from code review

Co-authored-by: Frank Budinsky <frankb@ca.ibm.com>

* Update content/en/docs/ops/deployment/requirements/index.md

Co-authored-by: Frank Budinsky <frankb@ca.ibm.com>

Co-authored-by: Frank Budinsky <frankb@ca.ibm.com>
This commit is contained in:
John Howard 2020-11-03 11:56:50 -08:00 committed by GitHub
parent d237f976c3
commit 16963f9bbd
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
2 changed files with 47 additions and 17 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

18
content/en/docs/ops/configuration/traffic-management/protocol-selection/index.md
View File

@ -22,24 +22,8 @@ any interception by the Istio proxy but cannot be used in proxy-only components
Istio can automatically detect HTTP and HTTP/2 traffic. If the protocol cannot automatically be determined, traffic will be treated as plain TCP traffic.
The following protocols are known to be incompatible with automatic protocol selection, and must be
[explicitly declared](#explicit-protocol-selection) or they will be treated as TCP:
|Protocol|Port|
|--------|----|
| SMTP |25 |
| DNS |53 |
| MySQL |3306|
| MongoDB|27017|
### Server first protocols
Some protocols are "Server First" protocols, which means the server will send the first bytes. In these cases, automatic protocol detection
will not function correctly, as Istio will determine the protocol based on the initial bytes. If you are using a server first protocol, you should
follow the explicit protocol selection instructions, below, to declare the protocol.
{{< tip >}}
Since TLS communication is not server first, any TLS based traffic will support protocol detection, even if it is wrapping a protocol that does not support detection, such as MySQL.
Server First protocols, such as MySQL, are incompatible with automatic protocol selection. See [Server first protocols](/docs/ops/deployment/requirements#server-first-protocols) for more information.
{{< /tip >}}
## Explicit protocol selection

46
content/en/docs/ops/deployment/requirements/index.md
View File

@ -106,3 +106,49 @@ The following ports and protocols are used by Istio.
| 15014 | HTTP | Istiod | Control plane monitoring |
To avoid port conflicts with sidecars, applications should not use any of the ports used by Envoy.
## Server First Protocols
Some protocols are "Server First" protocols, which means the server will send the first bytes. This may have an impact on
[`PERMISSIVE`](/docs/reference/config/security/peer_authentication/#PeerAuthentication-MutualTLS-Mode) mTLS and [Automatic protocol selection](/docs/ops/configuration/traffic-management/protocol-selection/#automatic-protocol-selection).
Both of these features work by inspecting the initial bytes of a connection to determine the protocol, which is incompatible with server first protocols.
In order to support these cases, follow the [Explicit protocol selection](/docs/ops/configuration/traffic-management/protocol-selection/#explicit-protocol-selection) steps to declare the protocol of the application as `TCP`.
The following ports are known to commonly carry server first protocols, and are automatically assumed to be `TCP`:
|Protocol|Port|
|--------|----|
| SMTP |25 |
| DNS |53 |
| MySQL |3306|
| MongoDB|27017|
Because TLS communication is not server first, TLS encrypted server first traffic will work with automatic protocol detection as long as you make sure that all traffic subjected to TLS sniffing is encrypted:
1. Configure `mTLS` mode `STRICT` for the server. This will enforce TLS encryption for all requests.
1. Configure `mTLS` mode `DISABLE` for the server. This will disable the TLS sniffing, allowing server first protocols to be used.
1. Configure all clients to send `TLS` traffic, generally through a [`DestinationRule`](/docs/reference/config/networking/destination-rule/#ClientTLSSettings) or by relying on auto mTLS.
1. Configure your application to send TLS traffic directly.
## Application Bind Address
When Istio captures inbound traffic, it will redirect it to the `localhost` address. As a result, applications should bind to either
`localhost` (`127.0.0.1` for IPv4 or `::1` for IPv6) or wildcard (`0.0.0.0` for IPv4 or `::` for IPv6). Applications listening on their
pod IP will need to be modified.
## Outbound traffic
In order to support Istio's traffic routing capabilities, traffic leaving a pod may be routed differently than
when a sidecar is not deployed.
For HTTP based traffic, traffic is routed based on the `Host` header. This may lead to unexpected behavior if the destination IP
and `Host` header are not aligned. For example, a request like `curl 1.2.3.4 -H "Host: httpbin.default"` will be routed to the `httpbin` service,
rather than `1.2.3.4`.
For Non-HTTP based traffic (including HTTPS), Istio does not have access to an `Host` header, so routing decisions are based on the Service IP address.
One implication of this is that direct calls to pods (for example, `curl <POD_IP>`), rather than Services, will not be matched. While the traffic may
be [passed through](/docs/tasks/traffic-management/egress/egress-control/#envoy-passthrough-to-external-services), it will not get the full Istio functionality
including mTLS encryption, traffic routing, and telemetry.