Add missing sidecar doc (#3709)

* Add missing sidecar doc

* review comment
This commit is contained in:
Frank Budinsky 2019-03-15 23:57:38 -04:00 committed by istio-bot
parent 9ae7c675e7
commit e40fe17c2d
1 changed files with 43 additions and 7 deletions

View File

@ -342,8 +342,8 @@ and retries, as well as set up common continuous deployment tasks such as
canary rollouts, A/B testing, staged rollouts with %-based traffic splits,
etc.
There are four traffic management configuration resources in Istio:
`VirtualService`, `DestinationRule`, `ServiceEntry`, and `Gateway`:
There are five traffic management configuration resources in Istio:
`VirtualService`, `DestinationRule`, `ServiceEntry`, `Gateway`, and `Sidecar`:
- A [`VirtualService`](/docs/reference/config/networking/v1alpha3/virtual-service/)
defines the rules that control how requests for a service are routed within an Istio service mesh.
@ -354,7 +354,10 @@ configures the set of policies to be applied to a request after `VirtualService`
- A [`ServiceEntry`](/docs/reference/config/networking/v1alpha3/service-entry/) is commonly used to enable requests to services outside of an Istio service mesh.
- A [`Gateway`](/docs/reference/config/networking/v1alpha3/gateway/)
configures a load balancer for HTTP/TCP traffic, most commonly operating at the edge of the mesh to enable ingress traffic for an application.
configures a load balancer for HTTP/TCP traffic operating at the edge of the mesh, most commonly to enable ingress traffic for an application.
- A [`Sidecar`](/docs/reference/config/networking/v1alpha3/sidecar/)
configures one or more sidecar proxies attached to application workloads running inside the mesh.
For example, you can implement a simple rule to send 100% of incoming traffic for a *reviews* service to version "v1" by using a `VirtualService` configuration as follows:
@ -1023,8 +1026,8 @@ about accessing external services.
### Gateways
A [Gateway](/docs/reference/config/networking/v1alpha3/gateway/)
configures a load balancer for HTTP/TCP traffic, most commonly operating at the edge of the
mesh to enable ingress traffic for an application.
configures a load balancer for HTTP/TCP traffic operating at the edge of the
mesh, most commonly to enable ingress traffic for an application.
Unlike Kubernetes Ingress, Istio `Gateway` only configures the L4-L6 functions
(for example, ports to expose, TLS configuration). Users can then use standard Istio rules
@ -1080,8 +1083,41 @@ spec:
See the [ingress task](/docs/tasks/traffic-management/ingress/) for a
complete ingress gateway example.
Although primarily used to manage ingress traffic, a `Gateway` can also be used to model
a purely internal or egress proxy. Irrespective of the location, all gateways
Although most often used to manage ingress traffic, a `Gateway` can also be used to model
an egress proxy. Irrespective of the location, all gateways
can be configured and controlled in the same way. See
[gateway reference](/docs/reference/config/networking/v1alpha3/gateway/)
for details.
### Sidecars
By default, Istio configures every sidecar proxy
to accept traffic on all the ports of its associated workload and to reach
every workload in the mesh when forwarding traffic.
A [Sidecar](/docs/reference/config/networking/v1alpha3/sidecar/) configuration
can be used to fine tune the set of ports and protocols that a proxy will accept
and to limit the set of services that the proxy can reach.
A `Sidecar` resource can be used to configure one or more sidecar proxies selected using
workload labels, or to configure all sidecars in a particular namespace. For example,
the following `Sidecar` configures all services in the `bookinfo` namespace
to only reach services running in the same namespace:
{{< text yaml >}}
apiVersion: networking.istio.io/v1alpha3
kind: Sidecar
metadata:
name: default
namespace: bookinfo
spec:
egress:
- hosts:
- "./*"
{{< /text >}}
Limiting sidecar reachability this way can be used to significantly reduce memory
usage, which by default can become a major problem for large applications where every sidecar
is provided with the configuration necessary to reach every other service in the mesh.
A `Sidecar` resource can also be used in many more ways.
Refer to the [sidecar reference](/docs/reference/config/networking/v1alpha3/sidecar/) for details.