SPK CRs¶
Overview¶
SPK Custom Resource Definitions (CRDs) extend the Kubernetes API, enabling Service Proxy TMM to be configured using SPK’s Custom Resources (CRs). SPK CRs configure TMM to support low-latency 5G application traffic, and apply networking configurations such as interface IP addresses and static routes.
This document describes the available SPK CRs, and offers two installation strategies.
Application traffic CRs¶
Application traffic CRs configure Service Proxy TMM to proxy and load balance application traffic using protocols such as TCP, UDP, SCTP, DIAMETER, and NGAP. When you install an application traffic CR, Service Proxy TMM receives the following application traffic management objects:
| Object | Description |
|---|---|
| Virtual Server | An IP address and service port that receives and processes ingress application traffic. |
| Network Virtual Server | An IP address subnet representing a range of destination IP addresses to receive and process ingress application traffic. |
| Wildcard Virtual Server | Receive and process all destination application traffic. Specified using IPv4 address 0.0.0.0/0 or IPv6 address ::/0. |
| Protocol Profile | Provide application traffic intelligence, and options to adapt how connections are handled. |
| Load Balancing Pool | The Service object Endpoints that TMM distributes traffic to using round robin load balancing. |
Available traffic management CRs:
- F5SPKIngressTCP - Ingress layer 4 TCP application traffic management.
- F5SPKIngressUDP - Ingress layer 4 UDP application traffic management.
- F5SPKIngressGTP - Ingress GTP application traffic management.
- F5SPKIngressSip - Ingress SIP application traffic management.
- F5SPKIngressNGAP - Ingress datagram load balancing for SCTP or NGAP signaling.
- F5SPKIngressHTTP2 - Ingress HTTP/2 application traffic management.
- F5SPKIngressEgressUDP - Ingress UDP application traffic, enabling response packets to use a virtual IP address.
- F5SPKIngressDiameter - Ingress Diameter traffic management using TCP or SCTP.
- F5SPKServiceTypeLBIpPool - Ingress traffic management based on K8S
LoadBalancertype Service objects. - F5SPKEgress - Egress application traffic for Pods using SNAT or DNS/NAT46.
- F5SPKSnatpool - Allocate IP addresses for egress Pod connections.
- F5BigContextGlobal - Modifies the F5BigFwPolicy CR’s default firewall action.
Networking CRs¶
Networking CRs configure TMM’s networking components such as network interfaces and static routes.
Available network management CRs:
- F5SPKVlan - TMM interface configuration: VLANs, Self IP addresses, MTU sizes, etc.
- F5SPKStaticRoute - TMM static routing table management.
SPK Firewall CRDs: Secure SPK¶
Note: We support these CNFs CRDs for Secure SPK.
There is one CRD used to define the Firewall policy logic, and would be changed most frequently by operations:
- F5BigFwPolicy - Granular stateful-flow filtering based on access control list (ACL) policies.
There is one CRD used to match traffic that the Firewall policy applies to, and would be created/modified when applications are created/changed:
- F5BigContextGlobal - Modifies the F5BigFwPolicy CR’s default firewall action.
There are two CRDs used for SPK Firewall Logging:
- F5BigLogProfile - Specifies subscriber connection information sent to remote logging servers.
- F5BigLogHslpub - Defines remote logging server endpoints for the F5BigLogProfile.
CR installation strategies¶
There are two methods for installing SPK CRs into the container platform:
- Helm - Helm enables the installation of 5G applications with the appropriate SPK CR, simplifying application management tasks such as upgrades, rollbacks and configuration modifications. For a simple Helm installation example, review the Helm CR Integration guide.
- Kubectl - 5G Applications and their Kubernetes Service object can be deployed first, and the appropriate SPK CR can then be installed using Kubectl. This method is used in the various SPK CR overview guides for simplicity, however, it does not support modifying complex 5G applications and is more error-prone.
Finalizers¶
- Finalizers are namespaced keys that instruct Kubernetes to wait until specific conditions are met before fully deleting resources marked for deletion. The SPK controller utilizes Kubernetes finalizers to maintain consistency between Custom Resources (CRs) and backend configurations.
- When a CR is created, the SPK controller adds a finalizer to it.
- Upon CR deletion, the SPK controller first removes the respective configuration from the backends and then eliminates the finalizer, allowing Kubernetes to complete the deletion process. As long as the finalizer is present in the CR, it will not be completely deleted.
- In the event that a CR is deleted while the SPK controller is offline, finalizers prevent it from being deleted. When the controller comes back online, it removes the configuration from the backend and subsequently eliminates the finalizer. This ensures that CRs are deleted only after the corresponding configuration is removed from the backends.
Feedback¶
Provide feedback to improve this document by emailing spkdocs@f5.com.