Chapter 2. Getting traffic into a mesh


Route external traffic to mesh services by configuring Istio gateway proxies and exposing them through LoadBalancer services or OpenShift routes.

Red Hat OpenShift Service Mesh offers two approaches to configure ingress traffic routing to services in the mesh. The approach depends on the service mesh deployment mode and traffic management requirements.

In the following example an Istio Gateway resource configures a gateway proxy to act as an entry point for external traffic. This configuration exposes port 443 (HTTPS) for the host, bookinfo.com. The example configuration applies to pods with the istio: ingressgateway label. The tls mode is configured as SIMPLE, which terminates the incoming HTTPS traffic using the certificate and private key the example provides.

Sample configuration

apiVersion: networking.istio.io/v1
kind: Gateway
metadata:
  name: bookinfo-gateway
  namespace: bookinfo
spec:
  selector:
    istio: ingressgateway
  servers:
  - port:
      number: 443
      name: https-443
      protocol: HTTPS
    hosts:
    - bookinfo.com
    tls:
      mode: SIMPLE
      serverCertificate: /etc/certs/servercert.pem
      privateKey: /etc/certs/privatekey.pem

The following VirtualService is bound to the Istio Gateway resource shown in the previous example configuration. The specification defines rules to route traffic with the /reviews/ path prefix to the reviews service in the bookinfo namespace. The VirtualService explicitly references the Gateway resource shown previously. This ensures that the routing rules are only applied to the traffic that enters through the specified gateway.

Sample configuration

kind: VirtualService
metadata:
  name: bookinfo-rule
  namespace: bookinfo
spec:
  hosts:
  - bookinfo.com
  gateways:
  - bookinfo/bookinfo-gateway
  http:
  - match:
    - uri:
        prefix: /reviews/
    route:
    - destination:
        port:
          number: 9080
        host: reviews.bookinfo.svc.cluster.local

While Istio Gateway and VirtualService resources support certain ingress use cases in ambient mode, the recommended approach is to use the Kubernetes Gateway API, which provides full support and integration with ambient. You can also use the Gateway API with sidecar-based deployments.

Expose mesh services to external traffic by configuring injected gateways with Istio Gateway and VirtualService resources to route traffic from outside the cluster.

Note

You can set the gateway Service type to LoadBalancer to allow traffic from outside the cluster.

Prerequisites

  • You have installed an Istio gateway using gateway injection.

Procedure

  1. Create namespace called httpbin by running the following command:

    $ oc create namespace httpbin
  2. Enable sidecar injection in the namespace. If you are using the InPlace upgrade strategy, run the following command:

    $ oc label namespace httpbin istio-injection=enabled
    Note

    If you are using the RevisionBased upgrade strategy, run the following commands:

    1. To find your <revision-name>, run the following command:

      $ oc get istiorevisions.sailoperator.io

      You should see output similar to the following example:

      NAME      TYPE    READY   STATUS    IN USE   VERSION   AGE
      default   Local   True    Healthy   True    v1.24.3   3m33s
    2. Label the namespace with the revision name to enable sidecar injection:

      $ oc label namespace httpbin istio.io/rev=default
  3. Deploy a sample service named httpbin by running the following command:

    $ oc apply -n httpbin -f https://raw.githubusercontent.com/openshift-service-mesh/istio/refs/heads/master/samples/httpbin/httpbin.yaml
  4. Create a YAML file named httpbin-gw.yaml that defines an Istio Gateway resource. This resource configures gateway proxies to expose port 80 (HTTP) for the host, httpbin.example.com.

    You can see the following example configuration for reference:

    apiVersion: networking.istio.io/v1
    kind: Gateway
    metadata:
      name: httpbin-gateway
      namespace: httpbin
    spec:
      selector:
        istio: <gateway_name>
      servers:
      - port:
          number: 80
          name: http
          protocol: HTTP
        hosts:
        - httpbin.example.com
    • spec.selector specifies the unique label or set of labels in the pod template of the gateway proxy Deployment. By default, the Istio Gateway resource configuration will apply to matching gateway pods in all namespaces.
    • spec.servers.hosts specifies a list of addresses that the clients use when attempting to access a mesh service at the associated port.
  5. Apply the YAML file by running the following command:

    $ oc apply -f httpbin-gw.yaml
  6. Create a YAML file named httpbin-vs.yaml for a VirtualService. The VirtualService defines the rules that route traffic from the gateway proxy to the httpbin service.

    You can see the following example configuration for reference:

    apiVersion: networking.istio.io/v1
    kind: VirtualService
    metadata:
      name: httpbin
      namespace: httpbin
    spec:
      hosts:
      - httpbin.example.com
      gateways:
      - httpbin-gateway
      http:
      - match:
        - uri:
            prefix: /status
        - uri:
            prefix: /headers
        route:
        - destination:
            port:
              number: 8000
            host: httpbin
    • spec.hosts the destination hosts for the VirtualService routing rules. The Istio Gateway resource must expose the hosts that you bind to the VirtualService.
    • spec.gateways binds the VirtualService to the Istio Gateway resource created in the previous step by adding the Gateway name to the list of gateways.
    • spec.http.route route matching traffic to the httpbin service deployed earlier by defining a destination that includes the host and port of the httpbin Service.
  7. Apply the YAML file by running the following command:

    $ oc apply -f httpbin-vs.yaml
  8. For verification purposes, create a namespace for a curl client by running the following command:

    $ oc create namespace curl
  9. Deploy the curl client by running the following command:

    $ oc apply -n curl -f https://raw.githubusercontent.com/openshift-service-mesh/istio/refs/heads/master/samples/curl/curl.yaml
  10. Set a CURL_POD variable with the name of the curl pod by running the following command:

    $ CURL_POD=$(oc get pods -n curl -l app=curl -o jsonpath='{.items[*].metadata.name}')
  11. Using the curl client, send a request to the /headers endpoint of the httpbin application through the ingress gateway Service resource. Set the Host header of the request to httpbin.example.com to match the host that the Istio Gateway and VirtualService resources specify. Run the following curl command to send the request:

    $ oc exec $CURL_POD -n curl -- \
      curl -s -I \
        -H Host:httpbin.example.com \
        <gateway_name>.<gateway_namespace>.svc.cluster.local/headers
  12. The response should have a 200 OK HTTP status indicating that the request was successful.

    Example output

    HTTP/1.1 200 OK
    server: istio-envoy
    ...

  13. Send a curl request to an endpoint that does not have a corresponding URI prefix match defined in the httpbin VirtualService by running the following command:

    $ oc exec $CURL_POD -n curl -- \
      curl -s -I \
        -H Host:httpbin.example.com \
        <gateway_name>.<gateway_namespace>.svc.cluster.local/get

    The response should return a 404 Not Found status as the httpbin VirtualService resource lacks a matching URI prefix for the /get endpoint.

    Example output

    HTTP/1.1 404 Not Found
    server: istio-envoy
    ...

  14. Expose the gateway proxy to traffic outside the cluster by setting the Service type to LoadBalancer:

    $ oc patch service <gateway_name> -n <gateway_namespace> -p '{"spec": {"type": "LoadBalancer"}}'
    Note

    OpenShift Routes can also expose a gateway to traffic outside the cluster. For more information, see "Exposing a gateway to traffic outside the cluster using OpenShift Routes".

  15. Verify that you can access the httpbin service from outside the cluster when using the external hostname or IP address of the gateway Service resource. Ensure that you set the INGRESS_HOST variable appropriately for the environment that your cluster is running in.

    1. If the cluster runs on AWS, set the INGRESS_HOST variable by running the following command:

      $ INGRESS_HOST=$(oc get service <gateway_name> -n <gateway_namespace> -o jsonpath='{.status.loadBalancer.ingress[0].hostname}')
    2. If the cluster runs on GCP or Azure, set the INGRESS_HOST variable by running the following command:

      $ INGRESS_HOST=$(oc get service <gateway_name> -n <gateway_namespace> -o jsonpath='{.status.loadBalancer.ingress[0].ip}')
    3. Send a curl request to the httpbin service using the host of the gateway by running the following command:

      $ curl -s -I -H Host:httpbin.example.com http://$INGRESS_HOST/headers
  16. Verify that the response has the HTTP/1.1 200 OK status, which indicates that the request was successful.

To enable traffic from outside an OpenShift cluster to access services in a mesh, you must expose a gateway proxy by either setting its Service type to LoadBalancer or by using the OpenShift Router.

Using Kubernetes load balancing to handle incoming traffic directly through the inbound gateway can reduce latency associated with data encryption. By managing encryption at the inbound gateway, you avoid the intermediate decryption and re-encryption steps within the mesh that often add latency. This approach encrypts and decrypts mesh traffic only once, which is generally more efficient.

The OpenShift Router provides a standard approach for managing ingress traffic, and you can use the router to manage certificates for all cluster ingress traffic by using the same methods. However, the OpenShift Router introduces an additional hop between the inbound traffic and the mesh applications. Typically, you route the traffic by decrypting it at the router and then re-encrypting it at the service mesh ingress gateway, which introduces latency.

You can expose a gateway to traffic outside the cluster by using OpenShift Routes. This approach provides an alternative to using Kubernetes LoadBalancer service when you have to expose gateways to traffic outside the cluster.

Prerequisites

  • You have completed the procedure, "Exposing a Service by using the Istio Gateway and VirtualService resources".

Procedure

  1. Ensure that you set the Service type to ClusterIP by running the following command:

    $ oc patch service <gateway_name> -n <gateway_namespace> -p '{"spec": {"type": "ClusterIP"}}'
  2. Create a YAML file named httpbin-route.yaml that defines a Route for the httpbin service similar to the following example:

    apiVersion: route.openshift.io/v1
    kind: Route
    metadata:
      name: httpbin
      namespace: <gateway_namespace>
    spec:
      host: httpbin.example.com
      port:
        targetPort: http2
      to:
        kind: Service
        name: <gateway_name>
        weight: 100
      wildcardPolicy: None
  3. Apply the YAML file by running the following command:

    $ oc apply -f httpbin-route.yaml
  4. Verify that you can access the httpbin service from outside the cluster through the ingress router. Ensure that you set the INGRESS_HOST variable appropriately for the environment that your cluster is running in.

    1. If the cluster runs on AWS, set the INGRESS_HOST variable by running the following command:

      $ INGRESS_HOST=$(oc get service router-default -n openshift-ingress -o jsonpath='{.status.loadBalancer.ingress[0].hostname}')
    2. If the cluster runs on GCP or Azure, set the INGRESS_HOST variable by running the following command:

      $ INGRESS_HOST=$(oc get service router-default -n openshift-ingress -o jsonpath='{.status.loadBalancer.ingress[0].ip}')
    3. Send a curl request to the httpbin service using the host of the ingress router by running the following command:

      $ curl -s -I -H Host:httpbin.example.com http://$INGRESS_HOST/headers
  5. Verify that the response has the HTTP/1.1 200 OK status, which indicates that the request was successful.

You can use the Kubernetes Gateway API to create Gateway and HTTPRoute resources and deploy a gateway. The resources configure the gateway to expose a service in the mesh to traffic outside the mesh.

Prerequisites

  • You have logged in to the OpenShift Container Platform web console as a user with the cluster-admin role.
  • You installed the Red Hat OpenShift Service Mesh Operator.
  • You deployed the Istio resource.

Procedure

  1. Create a namespace called httpbin by running the following command:

    $ oc create namespace httpbin
  2. Deploy a sample service named httpbin by running the following command:

    $ oc apply -n httpbin -f https://raw.githubusercontent.com/openshift-service-mesh/istio/refs/heads/master/samples/httpbin/httpbin.yaml
  3. Create a YAML file named httpbin-gw.yaml that defines a Kubernetes Gateway resource. This resource configures gateway proxies to expose port 80 (HTTP) for the host, httpbin.example.com.

    Example gateway resource file:

    apiVersion: gateway.networking.k8s.io/v1
    kind: Gateway
    metadata:
      name: httpbin-gateway
      namespace: httpbin
    spec:
      gatewayClassName: istio
      listeners:
      - name: default
        hostname: "httpbin.example.com"
        port: 80
        protocol: HTTP
        allowedRoutes:
          namespaces:
            from: All
    • spec.listeners.hostname: "httpbin.example.com" specifies the virtual hostname that clients use when attempting to access a mesh service on the associated port.
  4. Apply the YAML file by running the following command:

    $ oc apply -f httpbin-gw.yaml
  5. Create a YAML file named httpbin-hr.yaml that defines an HTTPRoute resource. The HTTPRoute resource specifies the rules that route traffic from the gateway proxy to the httpbin service.

    Example HTTPRoute file:

    apiVersion: gateway.networking.k8s.io/v1
    kind: HTTPRoute
    metadata:
      name: httpbin
      namespace: httpbin
    spec:
      parentRefs:
      - name: httpbin-gateway
        namespace: httpbin
      rules:
      - matches:
        - path:
            type: PathPrefix
            value: /status
        - path:
            type: PathPrefix
            value: /headers
        backendRefs:
        - name: httpbin
          port: 8000
    • spec.parentRefs binds the HTTPROUTE resource to the Kubernetes Gateway resource you created in the previous step.
    • spec.rules.backendRefs routes the matching traffic to the httpbin service by defining a backendRefs that includes the name and port of the httpbin service.

    The HTTPRoute resource specifies the rules that route traffic from the gateway proxy to the httpbin service.

  6. Apply the YAML file by running the following command:

    $ oc apply -f httpbin-hr.yaml
  7. Ensure that the Gateway API service is ready and has an allocated address by running the following command:

    $ oc wait --for=condition=programmed gtw httpbin-gateway -n httpbin

Verification

  1. Create a namespace for a curl client by running the following command:

    $ oc create namespace curl
  2. Deploy a curl client by running the following command:

    $ oc apply -n curl -f https://raw.githubusercontent.com/openshift-service-mesh/istio/refs/heads/master/samples/curl/curl.yaml
  3. Set a CURL_POD variable with the name of the curl pod by running the following command:

    $ CURL_POD=$(oc get pods -n curl -l app=curl -o jsonpath='{.items[*].metadata.name}')
  4. Using the curl client, send a request to the /headers endpoint of the httpbin application through the ingress gateway Service resource. Set the Host header of the request to httpbin.example.com to match the host that the Kubernetes Gateway and HTTPROUTE resources specify. Send the curl request by running the following command:

    $ oc exec $CURL_POD -n curl -- \
      curl -s -I \
        -H Host:httpbin.example.com \
        <gateway_name>-istio.<gateway_namespace>.svc.cluster.local/headers

    The response should return a 200 OK HTTP status, which indicates that the request was successful.

    Example output:

    HTTP/1.1 200 OK
    server: istio-envoy
    ...
  5. Send a curl request to an endpoint that does not have a corresponding Uniform Resource Identifier (URI) prefix match defined in the httpbin HTTPROUTE by running the following command:

    $ oc exec $CURL_POD -n curl -- \
      curl -s -I \
        -H Host:httpbin.example.com \
        <gateway_name>-istio.<gateway_namespace>.svc.cluster.local/get

    The response returns a 404 Not Found status. This is expected because the /get endpoint does not have a matching URI prefix in the httpbin HTTPROUTE resource.

    Example output:

    HTTP/1.1 404 Not Found
    server: istio-envoy
    ...
  6. Expose the gateway proxy to traffic outside the cluster by setting the Service type to LoadBalancer. Run the following command:

    $ oc patch service <gateway_name>-istio -n <gateway_namespace> -p '{"spec": {"type": "LoadBalancer"}}'
    Note

    OpenShift Routes can also expose a gateway to traffic outside the cluster. For more information, see "Exposing a gateway to traffic outside the cluster using OpenShift Routes".

  7. Verify that you can access the httpbin service from outside the cluster when using the external hostname or IP address of the gateway Service resource. Ensure that you set the INGRESS_HOST variable appropriately for the environment in which your cluster is running.

    1. Set the INGRESS_HOST variable by running the following command:

      $ export INGRESS_HOST=$(oc get gtw <gateway_name> -n <gateway_namespace> -o jsonpath='{.status.addresses[0].value}')
    2. Set the INGRESS_PORT variable by running the following command:

      $ INGRESS_PORT=$(oc get gtw <gateway_name> -n <gateway_namespace> -o jsonpath='{.spec.listeners[?(@.name=="http")].port}')
    3. Using the gateway host, send a curl request to the httpbin service by running the following command:

      $ curl -s -I -H Host:httpbin.example.com http://$INGRESS_HOST:$INGRESS_PORT/headers
  8. Verify that the response has the HTTP/1.1 200 OK status, which indicates that the request was successful.
Red Hat logoGithubredditYoutubeTwitter

Learn

Try, buy, & sell

Communities

About Red Hat

We deliver hardened solutions that make it easier for enterprises to work across platforms and environments, from the core datacenter to the network edge.

Making open source more inclusive

Red Hat is committed to replacing problematic language in our code, documentation, and web properties. For more details, see the Red Hat Blog.

About Red Hat Documentation

Legal Notice

Theme

© 2026 Red Hat
Back to top