mirror of
https://github.com/openshift/openshift-docs.git
synced 2026-02-05 12:46:18 +01:00
83 lines
3.8 KiB
Plaintext
83 lines
3.8 KiB
Plaintext
// Module included in the following assemblies:
|
|
//
|
|
// * service_mesh/v1x/ossm-traffic-manage.adoc
|
|
// * service_mesh/v2x/ossm-traffic-manage.adoc
|
|
|
|
:_mod-docs-content-type: PROCEDURE
|
|
|
|
[id="ossm-routing-virtual-services_{context}"]
|
|
= Using VirtualServices
|
|
|
|
You can route requests dynamically to multiple versions of a microservice through {SMProductName} with a virtual service. With virtual services, you can:
|
|
|
|
* Address multiple application services through a single virtual service. If your mesh uses Kubernetes, for example, you can configure a virtual service to handle all services in a specific namespace. A virtual service enables you to turn a monolithic application into a service consisting of distinct microservices with a seamless consumer experience.
|
|
* Configure traffic rules in combination with gateways to control ingress and egress traffic.
|
|
|
|
[id="ossm-routing-vs_{context}"]
|
|
== Configuring VirtualServices
|
|
|
|
Requests are routed to services within a service mesh with virtual services. Each virtual service consists of a set of routing rules that are evaluated in order. {SMProductName} matches each given request to the virtual service to a specific real destination within the mesh.
|
|
|
|
Without virtual services, {SMProductName} distributes traffic using least requests load balancing between all service instances. With a virtual service, you can specify traffic behavior for one or more hostnames. Routing rules in the virtual service tell {SMProductName} how to send the traffic for the virtual service to appropriate destinations. Route destinations can be versions of the same service or entirely different services.
|
|
|
|
.Procedure
|
|
|
|
. Create a YAML file using the following example to route requests to different versions of the Bookinfo sample application service depending on which user connects to the application.
|
|
+
|
|
.Example VirtualService.yaml
|
|
[source,yaml]
|
|
----
|
|
apiVersion: networking.istio.io/v1alpha3
|
|
kind: VirtualService
|
|
metadata:
|
|
name: reviews
|
|
spec:
|
|
hosts:
|
|
- reviews
|
|
http:
|
|
- match:
|
|
- headers:
|
|
end-user:
|
|
exact: jason
|
|
route:
|
|
- destination:
|
|
host: reviews
|
|
subset: v2
|
|
- route:
|
|
- destination:
|
|
host: reviews
|
|
subset: v3
|
|
----
|
|
|
|
. Run the following command to apply `VirtualService.yaml`, where `VirtualService.yaml` is the path to the file.
|
|
+
|
|
[source,terminal]
|
|
----
|
|
$ oc apply -f <VirtualService.yaml>
|
|
----
|
|
|
|
== VirtualService configuration reference
|
|
|
|
//Need a sentence or two here
|
|
|
|
[options="header"]
|
|
[cols="l, a"]
|
|
|===
|
|
|Parameter |Description
|
|
|spec:
|
|
hosts:
|
|
|The `hosts` field lists the virtual service's destination address to which the routing rules apply. This is the address(es) that are used to send requests to the service. The virtual service hostname can be an IP address, a DNS name, or a short name that resolves to a fully qualified domain name.
|
|
|
|
|spec:
|
|
http:
|
|
- match:
|
|
|The `http` section contains the virtual service's routing rules which describe match conditions and actions for routing HTTP/1.1, HTTP2, and gRPC traffic sent to the destination as specified in the hosts field. A routing rule consists of the destination where you want the traffic to go and any specified match conditions.
|
|
The first routing rule in the example has a condition that begins with the match field. In this example, this routing applies to all requests from the user `jason`. Add the `headers`, `end-user`, and `exact` fields to select the appropriate requests.
|
|
|
|
|spec:
|
|
http:
|
|
- match:
|
|
- destination:
|
|
|The `destination` field in the route section specifies the actual destination for traffic that matches this condition. Unlike the virtual service's host, the destination's host must be a real destination that exists in the {SMProductName} service registry. This can be a mesh service with proxies or a non-mesh service added using a service entry. In this example, the hostname is a Kubernetes service name:
|
|
|===
|