Managing egress traffic using a static route¶
One of the standard Service Proxy for Kubernetes (SPK) Custom Resource Definitions (CRD) is the ingressroutestaticroutes.k8s.f5net.com 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.
Custom egress routing¶
However the administrator requires that egress traffic be routed to the 10.10.0.0/16 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.
Sample Static Route CR¶
The following is an example of the SPK configuration object that will meet these requirements for the illustrated environment.
apiVersion: "k8s.f5net.com/v1"
kind: IngressRouteStaticRoute
metadata:
name: "event1-static-route-10-10-20.0"
namespace: event1
spec:
destination: 10.20.0.0
prefixLen: 16
gateway: 10.10.255.252
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 1.2.3.3
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