Overview of network infrastructure CRDs

Introduction

F5 BIG-IP Next for Kubernetes (BNK) allows you to manage network infrastructure using a set of Custom Resource Definitions (CRDs).

The CRDs align with the Kubernetes Gateway API model, introduce role-based access for different infrastructure personas, and simplify the configuration experience by consolidating multiple resources into fewer, more intuitive definitions.

Important

If you adopt the Gateway API model, you must define your network infrastructure using the new CRDs.

The three new CRDs:

CRD

What it does

Infra

Centralizes underlay network configuration, including IP Address Management (IPAM) pools, VLANs, VXLANs, Virtual Routing and Forwarding (VRF) definitions, and static routes

GatewaySettings

Configures tenant-specific traffic settings, including Source NAT (SNAT) pools and ingress and egress behavior

EgressGateway

Defines how application pods send outbound traffic through a specific egress gateway, with support for multi-tenancy and namespace selection

In addition, SecPolicy now supports targeting the EgressGateway CRD, which applies firewall policies to egress traffic.

The Custom Resource (CR) status fields in all three CRDs follow the structure of Gateway API CRDs and provide more descriptive feedback than the legacy resources.

How the CRDs work together

The three CRDs form a layered configuration model. Each CRD serves a distinct role and references the one above it. This diagram shows the resource relationship from infrastructure, through GatewaySettings, to the Gateway or EgressGateway.

Network reference

Typical deployment flow

Follow these steps, in order, to deploy network infrastructure with the new CRDs:

  1. Install the product: Deploy the BNKGatewayClass (CNEInstance) to bring up the CNE controller and TMM with the appropriate network attachments.

  2. Install GatewayClass: Create a GatewayClass resource to tell the CNE controller which Gateways it manages.

  3. Deploy the Infra CR: Configure VLANs, VXLANs, static routes, IPAM pools, and VRFs for the default and any additional routing domains.

  4. Deploy GatewaySettings (optional): Configure tenant-specific settings such as SNAT pools, ingress listener networks, and egress paths. This step is required only if you need tenant isolation or custom traffic settings.

  5. Deploy Gateway or EgressGateway: Enable ingress or egress functionality. If you created a GatewaySettings CR, reference it in the Gateway or EgressGateway using the infrastructure.parametersRef field.

Reconciliation

When you apply or update an Infra CR, the controller sends the updated configuration to TMM and cascades a reconcile to any GatewaySettings resources that reference it. GatewaySettings then cascades to the associated Gateway or EgressGateway resources. This chain ensures that changes to the underlay network propagate through to the traffic-handling layer without requiring you to manually update each resource.

When you update the Infra CR, only the changed configuration is sent to TMM. The controller does not treat updates as a full redeployment.

Persona-based deployment model

The new CRDs separate network configuration responsibilities by persona. This separation ensures that infrastructure concerns are managed independently from tenant-specific and application-level settings.

Persona

Responsibility

CRD

Infrastructure provider / network operator

Defines the underlay network: IPAM pools, VLANs, VXLANs, VRFs, static routes, and network attachments

Infra

Cluster operator / tenant network administrator

Configures tenant-specific traffic settings: SNAT pools, ingress listener networks, and egress paths

GatewaySettings

Application developer / tenant administrator

Deploys Gateways and EgressGateways to enable ingress and egress for application workloads; deploys HTTPRoutes and other route resources

Gateway, EgressGateway

CRD details

Infra

The Infra CRD defines the underlay network settings for your BNK installation. It is a single resource that consolidates what previously required multiple CRDs and a ConfigMap.

  • Scope: Must be deployed in the BNK namespace

  • API version: gateway.k8s.f5.com/v1alpha1

  • Kind: Infra

  • Short name: infra

The Infra CR includes the following configuration sections:

Section

Description

ipams

Manages IP address allocation pools for VLANs, SNAT pools, and Gateway listener addresses

networkAttachments

References Kubernetes NetworkAttachmentDefinition resources used by networks

vrfs

Defines Virtual Routing and Forwarding (VRF) instances for network isolation

networks

Configures VLAN and VXLAN network definitions

staticRoutes

Defines static routes for specific destination prefixes

The Infra CR also provides the default network configuration for any Gateway that does not explicitly reference a GatewaySettings resource.

Note

Infra is a singleton CR. Only one Infra CR can be deployed in the BNK namespace. Deploying multiple Infra CRs is not supported.

For the complete field reference, see /docs/custom-resource-definitions/bnk-infra.md.

GatewaySettings

The GatewaySettings CRD configures tenant-specific network and traffic settings. It references infrastructure elements defined in the Infra CR, such as IPAM pools and networks, to enable modular and reusable network design.

  • Scope: Must be deployed in the same namespace as the Gateway or EgressGateway that references it

  • API version: gateway.k8s.f5.com/v1alpha1

  • Kind: GatewaySettings

  • Short name: gws

The GatewaySettings CR includes the following configuration sections:

Section

Description

sourceNATPools

Defines SNAT pools for ingress and egress traffic, referencing IPAM pools from the Infra CR

ingressConfig

Specifies the network and IPAM pools for handling incoming traffic, including listener address allocation and SNAT mode

egressConfigs

Specifies one or more named egress configurations, each with a network reference, SNAT settings, and optional hardware acceleration

You can deploy GatewaySettings in three modes:

  • Ingress only — configure only ingressConfig

  • Egress only — configure only egressConfigs

  • Combined — configure both for a single tenant that handles ingress and egress traffic

For the complete field reference, see /docs/custom-resource-definitions/bnk-GatewaySettings.md.

EgressGateway

The EgressGateway CRD enables you to define how application pods in selected namespaces send outbound traffic through TMM.

  • Scope: Can be deployed in any namespace. The referenced GatewaySettings must be in the same namespace.

  • API version: gateway.k8s.f5.com/v1alpha1

  • Kind: EgressGateway

  • Short name: egw

Key features of the EgressGateway CRD:

  • Source selection modes: Choose how to select which pods use the egress gateway:

    • NamespaceSelector — all pods in matched namespaces

    • PodSelector — specific pods matched by label

    • Combined — pods that satisfy both namespace and pod selection criteria

  • Infrastructure reference: Uses the infrastructure.parametersRef field to reference a specific egressConfigs section in a GatewaySettings CR

  • VLAN and VXLAN support: Supports egress through both VLAN and VXLAN encapsulation

  • Firewall policy support: SecPolicy can target the EgressGateway to apply firewall policies to egress virtual servers

Note

Like the legacy F5SPKEgress, the EgressGateway CRD does not create services, pools, or monitors.

For the complete field reference, see /docs/custom-resource-definitions/bnk-EgressGateway.md.