From 289a64f17362d1d39df295c2c0c45982d1e4407c Mon Sep 17 00:00:00 2001 From: Frank Budinsky Date: Mon, 17 Jun 2019 17:22:05 -0400 Subject: [PATCH] Traffic managment concepts fixes (#4449) * traffic managment routing fixes * spelling * one more fix --- .../routing/virtual-services/index.md | 61 +++++++++---------- 1 file changed, 28 insertions(+), 33 deletions(-) diff --git a/content/docs/concepts/traffic-management/routing/virtual-services/index.md b/content/docs/concepts/traffic-management/routing/virtual-services/index.md index 1035038dd9..de3225e1d0 100644 --- a/content/docs/concepts/traffic-management/routing/virtual-services/index.md +++ b/content/docs/concepts/traffic-management/routing/virtual-services/index.md @@ -93,7 +93,7 @@ metadata: name: my-vtl-svc spec: hosts: - - *.my-co.org + - "*.my-co.org" http: - route: - destination: @@ -101,7 +101,7 @@ spec: subset: v1 {{< /text >}} -In the example, note that under `spec,` which lists the specifications of the +In the example, note that under `spec`, which lists the specifications of the network resource, `hosts` lists the virtual service's hosts. In this case, the hosts are `*.my-co.org`, where `*` is a wildcard prefix indicating that this virtual service handles routing for any DNS name ending with `.my-co.org`. @@ -111,7 +111,7 @@ mesh service name as long as the name resolves, implicitly or explicitly, to one or more fully qualified domain names (FQDN). To specify multiple hosts, you can use wildcards. -Also, note that under `route:`, which specifies the routing rule's +Also, note that under `route`, which specifies the routing rule's configuration, and `destination:`, which specifies the routing rule's destination, `host: my-svc` specifies the destination's host. If you are running on Kubernetes, then `my-svc` is the name of a Kubernetes service. @@ -189,11 +189,11 @@ To learn more about the actions available, visit the [virtual service reference ### Routing rule for HTTP traffic -The following example shows a virtual service that specifies a specific routing -rule for HTTP traffic in the `http:` section. The rule includes a `match:` +The following example shows a virtual service that specifies +two HTTP traffic routing rules. The first rule includes a `match` condition with a regular expression to check if the username "jason" is in the -request's cookie. If the request matches this condition, the routing rule sends -traffic to the `v2` subset of the `my-svc` service. Otherwise, the routing rule +request's cookie. If the request matches this condition, the rule sends +traffic to the `v2` subset of the `my-svc` service. Otherwise, the second rule sends traffic to the `v1` subset of the `my-svc` service. {{< text yaml >}} @@ -203,7 +203,7 @@ metadata: name: my-vtl-svc spec: hosts: - -* + - "*" http: - match: - headers: @@ -219,43 +219,40 @@ spec: subset: v1 {{< /text >}} -In the preceding example, there are two routing rules. The configuration of the -first routing rule in the virtual service begins with the `http:` field: +In the preceding example, there are two routing rules in the `http` section, +indicated by a leading `-` in front of the first field of each rule. -- `http:` Specifies the type of traffic that follows the the routing rule. In - this case, the routing rule applies to HTTP traffic. +The first routing rule begins with the `match` field: -- `- match:` Lists the routing rule's matching conditions. +- `match` Lists the routing rule's matching conditions. -- `- headers:` Specifies to look for a match in the header of the request. +- `headers` Specifies to look for a match in the header of the request. -- `cookie:` Specifies to look for a match in the header's cookie. +- `cookie` Specifies to look for a match in the header's cookie. -- `regex:` Specifies the regular expression used to determine a match. +- `regex` Specifies the regular expression used to determine a match. -- `route:` Specifies the routing rule's configurations for the traffic +- `route` Specifies where to route the traffic matching the condition. In this case, that traffic is HTTP traffic with the username `jason` in the cookie of the request's header. -- `- destination:` Specifies the destination for the traffic matching the - conditions. +- `destination` Specifies the route destination for the traffic matching the rule conditions. -- `host: my-svc` Specifies the destination's host. +- `host` Specifies the destination's host, `my-svc`. -- `subset: v2` Specifies the destination’s subset for the traffic matching the conditions. +- `subset` Specifies the destination’s subset for the traffic matching the conditions, `v2` in this case. -The configuration of the second routing rule in the example begins with the `- -route:` field. This rule applies to all traffic that doesn't match the +The configuration of the second routing rule in the example begins with the +`route` field with a leading `-`. This rule applies to all traffic that doesn't match the conditions specified in the first routing rule. -- `- route:` Specifies the routing rule's configurations for all traffic - except for HTTP traffic matching the condition of the previous rule. +- `route` Specifies where to route all traffic except for HTTP traffic matching the condition of the previous rule. -- `- destination:` Specifies the routing rule's destination. +- `destination` Specifies the routing rule's destination. -- `host: my-svc` Specifies the destination's host. +- `host` Specifies the destination's host, `my-svc`. -- `subset: v1` Specifies the destination’s subset. +- `subset` Specifies the destination’s subset, `v1` in this case. The following diagram shows the configured traffic routes for the matched traffic and for all other traffic: @@ -264,8 +261,6 @@ The following diagram shows the configured traffic routes for the matched traffi caption="Configurable traffic route based on the namespace of two application services" >}} -Configurable traffic rules for traffic with and without a matched cookie - Routing rules are evaluated in a specific order. For details, refer to [Precedence](/docs/concepts/traffic-management/routing/virtual-services/#precedence). @@ -294,7 +289,7 @@ spec: … {{< /text >}} -The value of the `sourceLabels:` key depends on the implementation of the +The value of the `sourceLabels` key depends on the implementation of the service. In Kubernetes, the value corresponds to the same labels you use in the pod selector of the corresponding Kubernetes service. @@ -322,7 +317,7 @@ spec: You can also base conditions on HTTP headers. The following configuration sets up a rule that only applies to an incoming request that includes a custom -`end-user:` header containing the exact `jason` string: +`end-user` header containing the exact `jason` string: {{< text yaml >}} apiVersion: networking.istio.io/v1alpha3 @@ -374,7 +369,7 @@ single section of `match.` For example, the following rule applies only to requests that come from an instance of the `reviews` service in the `v2` subset AND only if the requests -include the custom `end-user:` header that contains the exact `jason` string: +include the custom `end-user` header that contains the exact `jason` string: {{< text yaml >}} apiVersion: networking.istio.io/v1alpha3