Managing egress traffic using a static route

One of the standard Service Proxy for Kubernetes (SPK) Custom Resource Definitions (CRD) is the This CRD allows the SPK administrator to manage the TMM static routing table. As a result of using the Static Route Custom Resource (CR) the SPK administrator is able to direct traffic by defining the next hop. Deploying SPK to your cluster provides the ability to define a unique egress and ingress service proxy per project(namespace).

What is egress and Ingress traffic

The term ingress and egress refers to the direction of the traffic flow. Generally when working with OpenShift and Kubernetes this traffic originates or terminates at the pod. Egress traffic can be defined as packets that originate from a pod inside the OpenShift or Kubernetes network and travel out through switches and routers to an external destination. Ingress is simply the opposite; traffic that originates outside of a given network and travels to a pod inside the network.

Default egress routing

In the OpenShift cluster we have deployed a Pod called web-tier1 into the event1 namespace. Egress traffic from this pod will leave the OpenShift cluster via the external interface of the TMM pod. Egress traffic from this Pod will then be routed by to the default gateway.

Egress default path

Custom egress routing

However the administrator requires that egress traffic be routed to the network when sourced from the event1 namespace. This requires that we add a static route to the TMM pod forcing traffic to the alternative router and the preferred network. The ingressroutestaticroutes CR provides the ability to define a static route in the F5 TMM pod. The object must define the destination network, subnet prefix and gateway IP address.

Egress modified path

Sample Static Route CR

The following is an example of the SPK configuration object that will meet these requirements for the illustrated environment.

apiVersion: ""
kind: IngressRouteStaticRoute
  name: "event1-static-route-10-10-20.0"
  namespace: event1
  prefixLen: 16
  type: gateway

Environment assumptions

This use case makes some assumptions about the environment where this configuration would be applied.

  • You have access to an existing healthy OpenShift environment

  • You have deployed SPK version

  • You have an network available that is reachable by a gateway other than the default

  • You have deployed an application to your watched namespace

End of use case