F5 BIG-IP Container Ingress Services (CIS)

The NextGenController extends native Kubernetes/OpenShift routes using an extendedConfigMap. This allows for centralized management of BIG-IP resources like Virtual Servers (VIPs) and partitions.

RouteGroups

Routes are organized into RouteGroups based on either a namespace or a namespaceLabel.

• Mutual Exclusivity: You must use either namespace or namespaceLabel for all RouteGroups in a single extendedConfigMap; you cannot mix them.
• Shared Resources: All routes within a single RouteGroup share the same vserverAddr (VIP address), vserverName, bigIpPartition, and policyCR defined in the extendedRouteSpec.

Multiple VIP and Partition Support

• CIS creates one VIP per RouteGroup.
• To enable multiple VIP support, the controller mode must be set to openshift.
• CIS sends a unified AS3 declaration to BIG-IP to avoid multiple posts, using the format: mgmt/shared/appsvcs/declare/tenant1,tenant2.

extendedRouteSpec:
- namespace: foo
  vserverAddr: 10.8.0.4
  vserverName: nextgenroutes
  allowOverride: true
  bigIpPartition: MultiTenant
  policyCR: default/sample-policy
- namespace: bar
  vserverAddr: 10.8.0.5
  allowOverride: false

Multi-Cluster support in CIS allows you to expose applications spread across multiple OpenShift or Kubernetes clusters using a single BIG-IP Virtual Server. This is achieved by deploying CIS in either a Standalone or High Availability (HA) topology.

Key Capabilities

• Single Virtual Server: One BIG-IP VS can represent apps in different clusters.
• Supported Modes: CIS supports nodePort mode. Cluster mode is available with static route configuration on BIG-IP (no tunnels required).
• Resource Types: Apps can be exposed using ServiceTypeLB, Route, VS (Virtual Server), or TS (Transport Server) CR resources.

Prerequisites

• The cluster node where CIS is deployed must have network reachability to the API servers of all managed OpenShift/Kubernetes clusters.
• An ExtendedConfigMap must be created to enable multi-cluster functionality.
• Kube-config files for every cluster must be available to CIS so it can access Pods, Services, Endpoints, and Nodes.

When configuring security and SSL settings, NextGenController follows specific precedence rules depending on whether settings are defined in the Route, the Policy CR, or the Extended ConfigMap.

WAF (Web Application Firewall)

1. Policy CR: Highest precedence (configures WAF at the VirtualServer/VIP level).
2. Route Annotation: Second precedence (configures WAF at the LTM Policy level).
   • Exception: If allowOverride: true is set in the RouteGroup's extendedConfigMap, the Route Annotation takes precedence over the Policy CR.

Allow Source Range

1. Policy CR: Highest precedence.
2. Route Annotation: Second precedence.
   • Exception: If allowOverride: true is set in the RouteGroup's extendedConfigMap, the Route Annotation takes precedence over the Policy CR.

SSL Profiles

1. Route Annotation (BIG-IP reference/secret): Highest precedence.
2. Route Certificate (spec.certs): Second precedence.
3. Extended ConfigMap (defaultTLS): Lowest precedence.

CIS supports two primary modes for multi-cluster traffic distribution:

1. Active-Active Mode: Distributes traffic equally across all participating clusters. When CIS is running on the Primary cluster, it updates pool members for Virtual Servers using members from both the HA clusters (Primary and Secondary) and all other remotely monitored clusters. If the Primary cluster fails and the Secondary cluster takes control, it will populate pool members from the Secondary cluster and all other remotely monitored clusters regardless of the HA mode.

2. Ratio Mode: Distributes traffic across multiple clusters based on a specific ratio defined for each cluster.

Critical Requirement for Fail-over: To ensure successful fail-over, CIS monitored resource manifests (such as routes, CRDs, and extendedConfigmaps) must be identical and available in both the Primary and Secondary clusters. If the manifests are missing from the Secondary cluster, CIS on the Secondary cluster will not be able to take control and process them.

Pools define how traffic is distributed to backend services. You can use a defaultPool within a VirtualServer or define explicit pools.

Default Pool Configuration

A defaultPool links a Kubernetes service to the BIG-IP.

• Required: service (the K8s service name) and servicePort (port, port name, or targetPort).
• Reference: Set reference to service to use K8s service discovery, or bigip to reference an existing pool on the BIG-IP.
• Load Balancing: Use loadBalancingMethod (e.g., round-robin).

Pool Components

When defining a pool, you can specify:

• Service Mapping: service, servicePort, and serviceNamespace.
• Path/Host Rewriting: path (required) and hostRewrite to modify headers before reaching backends.
• Health Monitoring: Use monitor (for a single existing BIG-IP monitor) or monitors (for multiple monitors). Note that monitors takes priority if both are provided.
• A/B Deployment: Use alternateBackends to define a list of secondary services with specific weight values.
• NodePort Mode: Use nodeMemberLabel to specify which Nodes to consider as members.

# Example Pool within a VirtualServer
- pools:
    - name: my-pool
      path: /app
      service: my-service
      servicePort: 8080
      loadBalancingMethod: least-connections
      monitors:
        - type: http
          name: my-custom-monitor
          reference: bigip