mirror of
https://github.com/openshift/openshift-docs.git
synced 2026-02-05 12:46:18 +01:00
64 lines
2.9 KiB
Plaintext
64 lines
2.9 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: CONCEPT
|
||
[id="ossm-gateways_{context}"]
|
||
= Using gateways
|
||
|
||
You can use a gateway to manage inbound and outbound traffic for your mesh to specify which traffic you want to enter or leave the mesh. Gateway configurations are applied to standalone Envoy proxies that are running at the edge of the mesh, rather than sidecar Envoy proxies running alongside your service workloads.
|
||
|
||
Unlike other mechanisms for controlling traffic entering your systems, such as the Kubernetes Ingress APIs, {SMProductName} gateways use the full power and flexibility of traffic routing.
|
||
|
||
The {SMProductName} gateway resource can use layer 4-6 load balancing properties, such as ports, to expose and configure {SMProductName} TLS settings. Instead of adding application-layer traffic routing (L7) to the same API resource, you can bind a regular {SMProductName} virtual service to the gateway and manage gateway traffic like any other data plane traffic in a service mesh.
|
||
|
||
Gateways are primarily used to manage ingress traffic, but you can also configure egress gateways. An egress gateway lets you configure a dedicated exit node for the traffic leaving the mesh. This enables you to limit which services have access to external networks, which adds security control to your service mesh. You can also use a gateway to configure a purely internal proxy.
|
||
|
||
.Gateway example
|
||
|
||
A gateway resource describes a load balancer operating at the edge of the mesh receiving incoming or outgoing HTTP/TCP connections. The specification describes a set of ports that should be exposed, the type of protocol to use, SNI configuration for the load balancer, and so on.
|
||
|
||
The following example shows a sample gateway configuration for external HTTPS ingress traffic:
|
||
|
||
[source,yaml]
|
||
----
|
||
apiVersion: networking.istio.io/v1alpha3
|
||
kind: Gateway
|
||
metadata:
|
||
name: ext-host-gwy
|
||
spec:
|
||
selector:
|
||
istio: ingressgateway # use istio default controller
|
||
servers:
|
||
- port:
|
||
number: 443
|
||
name: https
|
||
protocol: HTTPS
|
||
hosts:
|
||
- ext-host.example.com
|
||
tls:
|
||
mode: SIMPLE
|
||
serverCertificate: /tmp/tls.crt
|
||
privateKey: /tmp/tls.key
|
||
----
|
||
|
||
This gateway configuration lets HTTPS traffic from `ext-host.example.com` into the mesh on port 443, but doesn’t specify any routing for the traffic.
|
||
|
||
To specify routing and for the gateway to work as intended, you must also bind the gateway to a virtual service. You do this using the virtual service's gateways field, as shown in the following example:
|
||
|
||
[source,yaml]
|
||
----
|
||
apiVersion: networking.istio.io/v1alpha3
|
||
kind: VirtualService
|
||
metadata:
|
||
name: virtual-svc
|
||
spec:
|
||
hosts:
|
||
- ext-host.example.com
|
||
gateways:
|
||
- ext-host-gwy
|
||
----
|
||
|
||
You can then configure the virtual service with routing rules for the external traffic.
|