F5SPKEgress

The BIG-IP Next for Kubernetes F5SPKEgress Custom Resource (CR) enables egress connectivity for internal pods that need access to external networks.

Important

All the Egress CRs should be applied to the namespace where TMM pod is configured.

The F5SPKEgress CR supports the following features:

  • Egress CR with SNAT: SNATs modify the source IP address of outgoing packets leaving the cluster. Using the F5SPKEgress CR, you can configure SNAT in 3 ways: SNAT none, SNAT pools or SNAT automap. For more information, see Egress SNAT

  • Egress CR with Shared SNAT Address and Flow-Forwarding: Multiple TMM pods use the same SNAT addresses to save resources. If response traffic is sent to a different pod, it forwards the traffic to the original pod to handle it correctly. For more information, see Shared SNAT Address with Flow-Forwarding.

  • Egress CR with Shared SNAT Address and Security Protection: The security protection configuration is added to the F5SPKEgress CR to enhance the shared SNAT address with additional security. For more information, see Shared SNAT Address with Security Protection.

  • Egress CR with PseudoCNI: Whole Cluster BIG-IP Next for Kubernetes uses the F5SPKEgress CR to manage egress traffic from apps through TMM pods. The CSRC daemonset sets up routes on worker nodes to direct traffic to the correct TMM. For more information, see PseudoCNI.

  • Egress CR with VXLAN: Users now have the option to create an VXLAN directly when they are creating an F5SPKEgress CR. This streamlines the process as it eliminates the need to create a separate F5SPKVXLAN CR and then refer to it within the F5SPKEgress CR. For more information, see VXLAN with F5SPKEgress CR.

CR Parameters

This section provides a description and default value of the parameters in the F5SPKEgress CR.

metadata

Parameter

Description

name

The unique name identifying the resource. For example, egress-cr

namespace

The namespace of Kubernetes in which the policy is applied.

spec

Parameter

Description

Default value

snatType
string (enum)

Specifies the type of SNAT address to use when forwarding requests that match the specified static route: SRC_TRANS_NONE, SRC_TRANS_SNATPOOL, or SRC_TRANS_AUTOMAP. For more information, see Egress SNAT

SRC_TRANS_AUTOMAP

dualStackEnabled
boolean

Enables creating both IPv4 and IPv6 wildcard virtual servers for egress connections.

false

egressSnatpool
string

Specifies SNAT Pool name. It is used when SNAT Type is configured with SRC_TRANS_SNATPOOL type.

maxTmmReplicas
integer

Not supported. The maximum number of allowed operational TMM pods. This must be equal to the number of SelfIps.

1

dnsNat46Enabled
boolean

Not supported. Enables DNS46/NAT46 feature.

false

dnsEnabled
boolean

Not supported. Enables the dns functionality. By default, this feature is enabled if dnsNat46Enabled or nat64Enabled is set to true. Note: This parameter is applicable only for v2 and v3 API version.

false

dnsNat46PoolIps
array

Not supported. Specifies a pool of IP addresses representing external DNS servers, or gateways to reach the DNS servers.

dnsNat46Ipv4Subnet
string

Not supported. Specifies the pool of private IPv4 addresses used to create DNS A records for the internal Pods. Use cidr format.

“10.2.2.0/24”

dnsNat46SorryIp
string

Not supported. Specifies IP address for Oops Page if the NAT pool becomes exhausted. Use IPv4 format.

“192.168.1.1”

nat64Enabled
boolean

Not supported. Enables DNS64/NAT64 translations for egress connections.

false

nat64Ipv6Subnet
string

Not supported. Specifies the IPv6 subnet address in cidr format.

“64:ff9b::/96”

debugLogEnabled
boolean

Not supported. Enables debug logging for DNS46 translations.

false

dnsCacheName
string

Not supported. Specifies the required F5SPKDnscache CR by concatenating the CR’s metadata.namespace and metadata.name parameters with a hyphen (-) character. For example, dnsCacheName: dnscache-cr

“”

maxReservedStaticIps
integer

Not supported. The maximum IPv4 addresses reserved from the given CIDR Block “dnsNat46Ipv4Subnet” for static IPv4<–>IPv6 mapping.

0

dnsRateLimit
integer

Not supported. Rate Limit is for DNS Virtual Server on a per pod basis. The minimum value is 0 and maximum value is 4294967295.

0

maxDNS46TTL
integer

Not supported. The ceiling for DNS46 translation TTL, AAAA TTLs greater than max is set to max. The minimum value is 1 and maximum value is 2147483647.

120

egressSnatpoolMode
string

Specifies the type of SNAT address for TMM pods. Available options: UNIQUE_SNAT_ADDRESS and SHARED_SNAT_ADDRESS_FLOW_FORWARD.

“UNIQUE_SNAT_ADDRESS”

egressSnatpoolFlowForwardVlan
string

Specifies the Vlan to be used for packets flow-forwarding between TMM pods.

“”

egressSnatpoolProtectionEnabled
boolean

Enables the shared SNAT address with security protection for packet forwarding between TMM pods.

false

egressSnatpool

Specifies the SNAT Pool name.

pseudoCNIConfig.namespaces

Specifies the namespaces of the application pods to which this egress configuration applies.
The pseudoCNIConfig.namespaces configuration ensures that each egress CR is restricted to only one application namespace at a time. This restriction prevents multiple namespaces from sharing the same egress CR, ensuring that egress traffic management remains isolated and controlled within a single namespace.

pseudoCNIConfig.appPodInterface
string

Specifies the application pod’s network interface name from which egress traffic is originated. For example, “eth0”.

pseudoCNIConfig.appNodeInterface
string

Specifies the network interface name on the worker node. This network interface represents the internal network and has connectivity to TMM. The egress traffic is directed towards the TMM through this interface on the node, where the application pod is deployed. In a DPU environment, this is the VF representing internal traffic.
Note: The pseudoCNIConfig.appNodeInterface should be empty when pseudoCNIConfig.vxlan.create is set to true, and it should be populated when pseudoCNIConfig.vxlan.create is set to false. For more information, see Configuring VXLAN with F5SPKEgress CR.

pseudoCNIConfig.secureSPKIngressPort
integer

Specifies the port number to be listened by the ingress virtual. This is required when PseudoCNI is configured and SNAT is configured to SRC_TRANS_NONE. The minimum value is 1025 and maximum value is 65535.

pseudoCNIConfig.vxlan
object

For the parameters description of pseudoCNIConfig.vxlan, see VXLAN Configuration Parameters table.

vxlan.create
boolean

Enables to create a VXLAN tunnel.

false

vxlan.tmmInterfaceName
string

Specifies the TMM VLAN interface on which the VXLAN is to be created. It must match the metadata.name of the VLAN Custom Resource (CR). This field is mandatory.

vxlan.nodeInterfaceName
string

This parameter is populated automatically and should not be manually configured.

vxlan.mtu
integer

Specifies the Maximum Transmission Unit (MTU) to be set for the VXLAN tunnel. The minimum value is 68 and maximum value is 65515.

1430

vxlan.port
integer

Specifies the port to be used for the VXLAN creation. The minimum value is 1024 and maximum value is 65535.

4789

vxlan.key
integer

Specifies the Virtual Network Identifier (VNI) to be used for the VXLAN tunnel. The minimum value is 0 and maximum value is 16777215.

0

vxlan.ipv4Subnet
string

Specifies IPv4 subnet from which addresses would be assigned to vxlan tunnel endpoints in TMM and on worker nodes. Subnet should be unique across all the f5-spk-egresses.f5net.com CRs. For example “192.168.0.0”

vxlan.ipv4PrefixLen
integer

Specifies the prefix length for the IPv4 subnet assigned to the self IP. The minimum value is 8 and maximum value is 18.

vxlan.ipv6Subnet
string

Specifies IPv6 subnet from which addresses would be assigned to vxlan tunnel endpoints in TMM and on worker nodes. Subnet should be unique across all the f5-spk-egresses.f5net.com crs. For example “fd50::”

vxlan.ipv6PrefixLen
integer

Specifies the prefix length for the IPv6 subnet assigned to the self IP. The minimum value is 104 and maximum value is 114.

pvaAccelerationMode
string

Specifies the preferred acceleration mode for the Packet Velocity ASIC (PVA). Full/Assisted specifies that the system applies partial PVA acceleration when possible, and idle flows can be evicted to software. Available options: full/assisted or disabled. The maximum length is 13.

full/assisted

firewallEnforcedPolicy
string

Specifies the name of the security firewall enforced policy. The maximum length is 255.

“”

logProfile
string

Specifies the name of the security log profile. The maximum length is 255.

“”

CR Modifications

Because the F5SPKEgress CR references a number of additional CRs, F5 recommends that you always delete and reapply the CR, rather than using kubectl apply to modify the running CR configuration.

Note

Egress CR Modification is not supported. It is recommended to delete and reapply the Egress CR for any modifications.

Requirements

Make sure you have:

  • Installed BNK (DPU).

  • Configured F5SPKVlan CR.

Egress SNAT

SNATs are used to modify the source IP address of egress packets leaving the cluster. When the BIG-IP Next for Kubernetes Traffic Management Microkernel (TMM) receives an internal packet from an internal Pod, the external (egress) packet source IP address will translate using a configured SNAT IP address. Using the F5SPKEgress CR, you can apply SNAT IP addresses using either SNAT pools, or SNAT automap.

snatType

There are three types of SNAT:

Note

Currently, the Egress use case with SNAT none type is not supported for GA.

SNAT none

When snatType is configured with SRC_TRANS_NONE, TMM uses application pod’s IP address to communicate with an external server.

SNAT pools

When snatType is configured with SRC_TRANS_SNATPOOL, TMM uses the configured MBIP server-side SNAT pools to communicate with an external server.

SNAT pools are lists of routable IP addresses, used by TMM to translate the source IP address of egress packets. SNAT pools provide a greater number of available IP addresses, and offer more flexibility for defining the SNAT IP addresses used for translation. If snatType is configured with the SRC_TRANS_SNATPOOL type, egressSnatpool will be used as a pool of addresses for source address translation for traffic that matches this F5SPKEgress CR. For more information to enable SNAT pools, see F5SPKSnatpool.

SNAT automap

When snatType is configured with SRC_TRANS_AUTOMAP, TMM uses the configured MBIP server side self IPs to communicate with an external server.

SNAT automap uses TMM’s external F5SPKVlan IP address as the source IP for egress packets. SNAT automap is easier to implement, and conserves IP address allocations. To use SNAT automap, do not include spec.egressSnatpool parameter. Use the installation procedure below to enable egress connectivity using SNAT automap.

Note

  • In clusters with multiple BIG-IP Next for Kubernetes Controller instances, ensure the IP addresses defined in each F5SPKSnatpool CR do not overlap.

  • Configuration dependencies based on snatType:

    • SRC_TRANS_SNATPOOL requires egressSnatpool; pseudoCNIConfig.secureSPKIngressPort must be omitted.

    • SRC_TRANS_NONE requires pseudoCNIConfig.secureSPKIngressPort; egressSnatpool must be omitted.

    • SRC_TRANS_AUTOMAP requires neither field; both must be omitted.

Configure SNAT Automap

Follow the instructions below to set up the SNAT automap configuration using the F5SPKEgress CR:

  1. Copy the below example F5SPKEgress CR to a YAML file, then set the namespace parameter to the Controller’s Project and save.

    apiVersion: "k8s.f5net.com/v3"
kind: F5SPKEgress
metadata:
  name: egress-cr
  namespace: f5-bnk
spec:
  dualStackEnabled: <true|false>
  snatType: SRC_TRANS_AUTOMAP

  2. Apply the F5SPKEgress CR that you have created.

    kubectl apply -f <file name>

    In this example, the CR file is named egress-cr.yaml:

    kubectl apply -f egress-cr.yaml

    Sample Output:

    f5spkegress.k8s.f5net.com/egress-cr created

Internal Pods can now connect to external resources using the external F5SPKVlan self IP address.

Connection Statistics

Connect to the Debug Sidecar in the BIG-IP Next for Kubernetes to view the traffic processing statistics.

  1. Log in to the BIG-IP Next for Kubernetes Debug container.

    kubectl exec -it f5-tmm-wgrvm -c debug -n f5-bnk

  2. View the traffic processing statistics.

    tmctl -d blade virtual_server_stat -s name,serverside.tot_conns

    In this example, 3 IPv4 connections, and 2 IPv6 connections have been initiated by internal Pods:

    name                              serverside.tot_conns
-----------------                 --------------------
f5-bnk-egress-crd-egress-ipv6                2
f5-bnk-egress-crd-egress-ipv4                3

Shared SNAT Address and Security Protection

In the default SNAT pool mode, each TMM pod is assigned a unique SNAT address. However, to optimize resource usage and minimize the number of SNAT addresses in large-scale deployments, TMM can be configured to share an SNAT address. Hence, in shared SNAT address mode, multiple TMM pods can use the same set of SNAT addresses to handle egress traffic. In this scenario, there may be instances where response traffic from the router is directed to an alternate TMM pod than the one that originally handled the outgoing traffic. To address this situation, the alternate TMM pod forwards the valid response traffic to original TMM pod so it can be processed properly.

Note

Response Traffic Handling: Only traffic that is valid and belongs to an active TMM pod, or matches an existing outgoing connection, will be forwarded and processed. It is important to follow these rules to ensure smooth traffic management.

Shared SNAT Address with Flow-Forwarding

Flow-Forwarding Architecture: Egress Traffic

../_images/flow-forwarding-egresssnataddress.png

Note

ACL and Flow-Forwarding Compatibility: Access Control List (ACL) and Flow-Forwarding cannot be applied simultaneously to the same IP address. In the case of Flow-Forwarding, IP address specifically refers to the Source Network Address Translation (SNAT) address. This means that if Flow-Forwarding is enabled, ACL configurations for the SNAT address are not applicable.

Flow-Forwarding Architecture: Egress Traffic

The above diagram describes how egress traffic from a (Cloud-Native Function) CNF Node is sent to an External Client through TMM with Shared SNAT applied.

Egress Traffic Flow Description:

  1. Initiating Egress Traffic:

    • The CNF Node (X:x) initiates egress traffic, sending packets to the external client (Y:y) via the TMM.

  2. Applying SNAT (Source Network Address Translation):

    • To send packets to the external client (Y:y), the TMM changes the CNF node’s (X:x) source address to the egress SNAT address (S:s).

    • The packet is then forwarded from the TMM to the router with the SNAT address (S:s).

  3. Routing the egress traffic to the External Client:

    • The router forwards the packet to the external client (Y:y).

  4. Return Traffic from the External Client:

    • The external client (Y:y) sends a response packet back to the router.

    • Since the SNAT address (S:s) is shared across all TMMs, the router may return the packet to any available TMM (e.g., TMM 1), without knowing which specific TMM handled the initial outgoing packet.

  5. Identifying the Original TMM:

    • Upon receiving the packet, the TMM checks which TMM initiated the original packet flow.

    • The packet is then forwarded to the correct TMM (e.g., TMM 2) that originally handled the outgoing traffic.

  6. Returning the Packet to the CNF Node:

    • The identified TMM (e.g., TMM 2) sends the packet back to the originating CNF node (X:x), completing the egress traffic flow.

Configuring Shared SNAT Address with Flow-Forwarding

Follow the instructions below to set up the shared SNAT address configuration using the F5SPKEgress and F5SPKSnatpool CRs:

  1. Copy the below example F5SPKEgress CR to a YAML file, then modify shared SNAT Address settings as required and save.

    apiVersion: "k8s.f5net.com/v3"
kind: F5SPKEgress
metadata:
  name: egress-cr
  namespace: f5-bnk
spec:
  dualStackEnabled: true
  snatType: SRC_TRANS_SNATPOOL
  egressSnatpool: egress-snatpool
  egressSnatpoolMode: SHARED_SNAT_ADDRESS_FLOW_FORWARD
  egressSnatpoolFlowForwardVlan: vlan-external
  vlans:
    vlanList:
      - vlan-internal
    disableListedVlans: false
  pseudoCNIConfig:
    namespaces:
      - app-ns-1
    appPodInterface: "eth0"
    appNodeInterface: "spk-ms.3001"

    Note

    The same egressSnatpool should not be configured across multiple F5SPKEgress CRs.

  2. Apply the F5SPKEgress CR that you have created.

    kubectl apply -f egress-cr.yaml

    Sample Output

    f5spkegress.k8s.f5net.com/egress-cr created

  3. Copy the below F5SPKSnatpool CR to a YAML file, then modify shared SNAT Address settings as required and save.

    apiVersion: "k8s.f5net.com/v1"
kind: F5SPKSnatpool
metadata:
   name: egress-snatpool
   namespace: f5-bnk
spec:
   name: egress-snatpool
   sharedSnatAddressEnabled: true
   addressList:
    - - 44.44.44.4
      - 2002::44:44:44:4

  4. Apply the F5SPKSnatpool CR that you have created.

    kubectl apply -f snatpool-cr.yaml

    Sample Output

    f5spksnatpool.k8s.f5net.com/egress-snatpool created

Configuring Shared SNAT Address with Security Protection

This section provides the configuration of shared SNAT address with security protection.

Security protection prevents packet forwarding of likely invalid flows. This can help reduce security risk and improve overall performance.

Follow the instructions below to set up the shared SNAT address with security protection using the F5SPKEgress CR:

  1. Copy the below example F5SPKEgress CR to a YAML file, then modify security protection settings as required and save.

apiVersion: "k8s.f5net.com/v3"
kind: F5SPKEgress
metadata:
  name: egress-cr
  namespace: f5-bnk
spec:
  dualStackEnabled: true
  snatType: SRC_TRANS_SNATPOOL
  egressSnatpool: egress-snatpool
  egressSnatpoolMode: SHARED_SNAT_ADDRESS_FLOW_FORWARD
  egressSnatpoolFlowForwardVlan: vlan-external
  egressSnatpoolProtectionEnabled: true
  vlans:
    vlanList:
      - vlan-internal
    disableListedVlans: false
  pseudoCNIConfig:
    namespaces:
      - app-ns-1
    appPodInterface: "eth0"
    appNodeInterface: "spk-ms.3001"

  1. Apply the F5SPKEgress CR that you have created.

kubectl apply -f egress-cr.yaml

Sample Output:

f5spkegress.k8s.f5net.com/egress-cr created

Connection Statistics

Connect to the Debug Sidecar in the BIG-IP Next for Kubernetes TMM to view the security protection stats.

  1. Log in to the BIG-IP Next for Kubernetes Debug container.

    kubectl exec -it f5-tmm-6cdbc6bb65-j2r7d -c debug -n f5-bnk -- bash

  2. View the security protection stats.

     tmctl -d blade profile_sharedscript_stat -P

    Sample Output:

     Name                             Value
 ---------------------------      --------
 cur_deny_listener                0
 tot_alternate_drop               0
 tot_origin_drop                  0
 tot_alternate_invalid_pkt        0
 tot_deny_listener                0

PseudoCNI

The Whole Cluster BIG-IP Next for Kubernetes utilises the F5SPKEgress CR to incorporate PseudoCNI configuration, which defines the necessary setting for egress traffic from application pods through TMM pods. The PseudoCNI Controller reads the PseudoCNI configuration from the F5SPKEgress CR and generates the necessary settings to designate TMMs as egress gateways. These mappings are shared with CSRC over GRPC. The CSRC daemonSet, running in privileged mode, configures rules and routes on nodes hosting application pods. The TMM running on the DPU local to the host node is given the highest priority compared to other TMMs.

Note

To ensure proper network communication and management, you must update the Felix configurations to include the TMM internal interface IPv4 Self-IPs. Use the kubectl patch felixconfiguration default --type='merge' -p='{"spec": {"externalNodesList": ["self-ip-address1", "self-ip-address2", "self-ip-address3"]}}' command to update the Felix configuration.

Configuring PseudoCNI

Prerequisites

Ensure you have:

  • A Linux-based workstation.

  • Installed F5SPKVlan.

Follow the instructions below to set up the PseudoCNI configuration using the F5SPKEgress CR:

  1. Copy the below example F5SPKEgress CR into a YAML file, then modify PseudoCNI settings, snatpool and External VLAN Interface Name as required and save.

    apiVersion: "k8s.f5net.com/v3"
kind: F5SPKEgress
metadata:
  name: egress-cr
  namespace: f5-bnk
spec:
  dualStackEnabled: true
  snatType: SRC_TRANS_SNATPOOL
  egressSnatpool: egress-snatpool
  vlans:
    disableListedVlans: false
    vlanList:
      - vlan-external
  pseudoCNIConfig:
    namespaces:
      - app-ns-1
    appPodInterface: "eth0"
    appNodeInterface: "spk-ms.3001"

  2. Apply the F5SPKEgress CR that you have created.

    kubectl apply -f egress-cr.yaml

Note


1. Using only VLAN in the egress CR (without VXLAN) is supported.
2. Make sure to configure one egress CR per namespace and one VLAN per egress CR. A single VLAN cannot be referred to in multiple egress CRs.

Configuring Dynamic Port Selection for CSRC-CNE Controller Communication

Port Conflict Issue from CSRC Logs:

ERROR: Failed to listen: listen tcp :8751: bind: address already in use

Cause:

As the CSRC daemonSet runs in the host network namespace, the CSRC gRPC port (default: 8751) may conflict with other applications using the same port in the host network.

FIX:

If a port conflict occurs during or after BIG-IP Next for Kubernetes installation, perform the following steps to fix this issue:

  1. Update the Service Resource.

    kubectl edit svc f5-csrc-grpc-svc

    In the csrc-grpc_service.yaml file, modify:

    ports:
  - name: f5-csrc-grpc
    port: 8751       # Change to a new port (e.g., 8875)
    protocol: TCP
    targetPort: 8751 # Update to match the new port (e.g., 8875)

  2. Update the DaemonSet Configuration.

    kubectl edit daemonset spk-csrc

    In the daemonset.yaml file, modify:

    - name: PSEUDOCNI_GRPC_PORT
  value: 8751     # Change to the new port (e.g., 8875)

The CSRC pods will automatically restart with the new port configuration, resolving the conflict.

VXLAN with F5SPKEgress CR

The setup process for the F5SPKVXLAN CR is automated to minimize the need for manual input and prevent errors. By using the specified tmmInterfaceName, the node interface is automatically identified and obtains the required underlay network information. It then chooses a unique Virtual Network Identifier (VNI) and subnet, and associates the VXLAN with the F5SPKEgress CR. These improvements simplify the configuration process, improve efficiency, and ensure accurate configurations with minimal user intervention.

Configuring VXLAN with F5SPKEgress CR

Prerequisites:

  • The underlying F5SPKVlan CR, referred to in the F5SPKEgress CR as tmmInterfaceName, must be created before creating the F5SPKEgress CR.

  • If pseudoCNIConfig is configured and vxlan.create is set to true.

    • vlans.vlanList should be empty.

    • pseudoCNIConfig.appNodeInterface should be empty.

  • If pseudoCNIConfig is configured and vxlan.create is set to false.

    • vlans.vlanList should be populated, containing only one element.

  • If vxlan.nodeInterfaceName is configured, the specified interface will be used to create the VXLAN interface. If vxlan.nodeInterfaceName is not configured or set to default, the appropriate interface on the node is automatically detected. This detected interface will be the one that can connect to the VLAN interface specified by tmmInterfaceName in the TMM.

  • When you configure a subnet for a VXLAN interface manually, ensure that unique VXLAN subnets are configured for all F5SPKEgress (VXLAN) CRs.

  • When you configure a VNI manually, ensure that the VNI is configured for all F5SPKEgress (VXLAN) CRs.

Follow the instructions below to set up the VXLAN configuration using the F5SPKEgress CR with default and specific configuration values:

  1. Using default values

    Copy the below example F5SPKEgress CR with default values into a YAML file, then modify VXLAN settings as required and save.

    apiVersion: "k8s.f5net.com/v3"
kind: F5SPKEgress
metadata:
  name: egress-cr
  namespace: f5-bnk
spec:
 dualStackEnabled: true
 snatType: SRC_TRANS_SNATPOOL
 egressSnatpool: egress-snatpool
 pseudoCNIConfig:
    namespaces:
      - app-ns-1
    appPodInterface: "eth0"
    vxlan:
      create: true
      tmmInterfaceName: "vlan-internal"

  2. Using Specific Configuration Values

    Copy the below example F5SPKEgress CR with specific configuration values into a YAML file, then modify VXLAN settings as needed and save.

    apiVersion: "k8s.f5net.com/v3"
kind: F5SPKEgress
metadata:
  name: egress-cr
  namespace: f5-bnk
spec:
 dualStackEnabled: true
 snatType: SRC_TRANS_SNATPOOL
 egressSnatpool: egress-snatpool
 pseudoCNIConfig:
    namespaces:
      - app-ns-1
    appPodInterface: "eth0"
    vxlan:
      create: true
      tmmInterfaceName: "vlan-internal"
      port: 4789
      mtu: 1460
      key: 100

  3. Apply the F5SPKEgress CR that you have created.

    kubectl apply -f egress-cr.yaml

    Sample Output

    f5spkegress.k8s.f5net.com/egress-cr created

Uninstallation F5SPKEgress CR

Use the below command to delete the F5SPKEgress CR.

kubectl delete -f egress-cr.yaml