Introduction to Service Proxy for Kubernetes (SPK) Use Cases¶
Service Proxy for Kubernetes (SPK) is a cloud-native application traffic management solution, designed for communication service provider (CoSP) 5G networks. SPK integrates F5’s containerized Traffic Management Microkernel (TMM) and Custom Resource Definitions (CRDs) into the OpenShift container platform, to proxy and load balance low-latency 5G workloads.
At least 5 different types of Pod are involved in building a SPK use case
Controller: The SPK Controller reads the appropriate Custom Resource Definitions (CRDs) for the cluster, namespace and Cloud-Native Network Functions (CNFs) and configures the Service Proxy Pod’s accordingly. It also subscribes to the appropriate Kubernetes APIs that look for changes in the set of PODs comprising the CNF or the set of service proxy Pod’s, so that the service proxy’s configuration can be appropriately modified.
Service Proxy: The service proxy PODs contain the BIG-IP data plane (TMM). The TMM implements the ingress, egress and transformation operations as requested by the CRDs.
dSSM: The Distributed Session State Management Pods which hold a Redis database used to hold session state for all service proxy Pod’s.
CWC: The Cluster Wide Controller Pods support the software licensing and billing capabilities of every SPK Controller operating in that SPK cluster
Telemetry: The telemetry POD contains Fluentd which aggregates logs and stats from all SPK Pods and allows plugins to be configured designating which streams should be forwarded to which telemetry destination.
We will be describing a number of use cases based on these Pods in the following documentation.