Configure an egress gateway for outbound pod traffic¶

Overview¶

The EgressGateway Custom Resource (CR) defines how application pods in selected namespaces send outbound traffic through TMM. Each EgressGateway CR creates a wildcard virtual server on TMM (0.0.0.0:0 for IPv4, [::]:0 for IPv6) and uses the SNAT, network, and VRF settings from a referenced GatewaySettings CR.

Use the EgressGateway CRD when you need to:

Direct outbound traffic from pods through a specific egress path
Apply SNAT policies to egress traffic
Isolate egress paths for different tenants in a multi-tenancy environment
Apply firewall policies to outbound pod traffic

Before you begin¶

Make sure you have the following:

An Infra CR is deployed and shows Programmed: True.
A GatewaySettings CR is deployed in the target namespace with at least one entry in egressConfigs. Confirm the GatewaySettings shows Accepted: True and ResolvedRefs: True.
You know the name of the egress configuration in the GatewaySettings CR that you want to use (the egressConfigs[].name value).
You know the GatewayClass name that binds to the CNE controller.
You know which pods should use this egress gateway, and you can identify them by namespace labels, namespace names, pod labels, or a combination.

Create the EgressGateway CR¶

Set the GatewayClass name.

Specify the GatewayClass that binds this EgressGateway to the CNE controller. This value is immutable — you cannot change it after creating the CR.
```
spec:
  gatewayClassName: f5-bnk-gateways
```
Reference the GatewaySettings.

Use the infrastructure.parametersRef field to point to a GatewaySettings CR in the same namespace. The sectionName field identifies which egressConfigs entry to use. Both name and sectionName are immutable.
```
spec:
  infrastructure:
    parametersRef:
      name: my-gateway-settings
      sectionName: default-egress
```
The sectionName must match the name field of an entry in the GatewaySettings egressConfigs array. For example, if the GatewaySettings contains:
```
egressConfigs:
  - name: default-egress
    sourceNATConfig:
      type: Automap
```
Then set sectionName: default-egress.

Configure the source selector.

The sourceSelector field determines which pods use this egress gateway. Choose a selection mode based on your requirements:

NamespaceSelector — select all pods in matching namespaces:

spec:
  sourceSelector:
    selectionMode: NamespaceSelector
    namespaces:
      matchLabels:
        tier: production

You can also select namespaces by name:

spec:
  sourceSelector:
    selectionMode: NamespaceSelector
    namespaces:
      matchNames:
        - my-tenant-ns
        - my-other-ns

When you specify both matchLabels and matchNames, only namespaces that satisfy both criteria are selected (intersection).

PodSelector — select specific pods by label:

spec:
  sourceSelector:
    selectionMode: PodSelector
    pods:
      matchLabels:
        app: web-app

You can use matchExpressions for more complex selection:

spec:
  sourceSelector:
    selectionMode: PodSelector
    pods:
      matchExpressions:
        - key: app
          operator: In
          values:
            - web-app
            - api-server

Combined — select pods that match both namespace and pod criteria:

spec:
  sourceSelector:
    selectionMode: Combined
    namespaces:
      matchLabels:
        tier: production
      matchNames:
        - my-tenant-ns
    pods:
      matchLabels:
        app: web-app
        version: v1

In Combined mode, both namespaces and pods are required. Only pods that exist in matching namespaces and match the pod selection criteria are selected.

Apply the EgressGateway CR

Save the complete EgressGateway CR to a YAML file and apply it:
```
kubectl apply -f egressgateway.yaml -n f5-gateways
```
Important

The EgressGateway must be in the same namespace as the GatewaySettings CR it references.

Verify the configuration¶

Check that the controller accepted and programmed the EgressGateway:

kubectl get egressgateways -n f5-gateways

The output should show Programmed as True:

NAME         PROGRAMMED   AGE
bnk-egress   True         10s

For detailed status, inspect the CR:

kubectl describe egressgateway bnk-egress -n f5-gateways

Review the following status conditions:

Condition	Expected status	What it means
`Accepted`	`True`	The CR is syntactically valid and admitted by the controller.
`ResolvedRefs`	`True`	The referenced GatewaySettings CR exists and is valid.
`Programmed`	`True`	The egress virtual server has been programmed on TMM.

If a condition shows False or Unknown, check the reason field:

Reason	What to do
`DependencyMissing`	The referenced GatewaySettings CR does not exist, or the `sectionName` does not match any `egressConfigs` entry. Verify the names and namespace.
`UserError` / `InvalidParameters`	The spec is invalid. Check required fields and immutability constraints.
`Programming`	Reconciliation is in progress. Wait and check again.
`InfraTransient`	A temporary infrastructure issue occurred. The controller will retry automatically.

Multi-tenancy¶

In a multi-tenant environment, deploy a separate EgressGateway CR for each tenant. Each CR references a different egressConfigs entry in the GatewaySettings, which specifies the tenant’s network, SNAT pool, and VRF settings.

For example, for two tenants:

Tenant A:

apiVersion: gateway.k8s.f5.com/v1alpha1
kind: EgressGateway
metadata:
  name: tenant-a-egress
  namespace: f5-gateways
spec:
  gatewayClassName: f5-bnk-gateways
  infrastructure:
    parametersRef:
      name: my-gateway-settings
      sectionName: tenant-a-egress
  sourceSelector:
    selectionMode: NamespaceSelector
    namespaces:
      matchLabels:
        tenant: a

Tenant B:

apiVersion: gateway.k8s.f5.com/v1alpha1
kind: EgressGateway
metadata:
  name: tenant-b-egress
  namespace: f5-gateways
spec:
  gatewayClassName: f5-bnk-gateways
  infrastructure:
    parametersRef:
      name: my-gateway-settings
      sectionName: tenant-b-egress
  sourceSelector:
    selectionMode: NamespaceSelector
    namespaces:
      matchLabels:
        tenant: b

Each EgressGateway CR creates its own wildcard virtual server on TMM, with the source IPs in the traffic matching criteria determined by the source selector configuration. This keeps each tenant’s egress traffic isolated.

Complete example¶

apiVersion: gateway.k8s.f5.com/v1alpha1
kind: EgressGateway
metadata:
  name: bnk-egress
  namespace: f5-gateways
spec:
  gatewayClassName: f5-bnk-gateways
  infrastructure:
    parametersRef:
      name: my-gateway-settings
      sectionName: default-egress
  sourceSelector:
    selectionMode: Combined
    namespaces:
      matchLabels:
        tier: production
      matchNames:
        - my-tenant-ns
    pods:
      matchLabels:
        app: web-app
        version: v1