Introduction to F5 Container Ingress Services¶
F5 Container Ingress Services (CIS) integrates with container orchestration environments to dynamically create L4/L7 services on F5 BIG-IP systems, and load balance network traffic across the services. Monitoring the orchstration API server, CIS is able to modify the BIG-IP system configuration based on changes made to containerized applications.
|Container Ingress Service||Orchestration environment|
|cf-bigip-ctlr||Cloud Foundry and Pivotal Cloud Foundry|
|k8s-bigip-ctlr||Kubernetes and Red Hat OpenShift|
|marathon-bigip-ctlr||Apache Mesos Marathon, DC/OS and DC/OS Enterprise|
|||See Introduction to F5 Common Controller Core Library on DevCentral for more information.|
When an applicaion developer modifies an application, CIS discovers the change event, and dynamically modifies the BIG-IP system configuration by translating orchestration commands into F5 SDK/iControl REST calls.
Migrating CIS is as easy as destroying it in one orchestration environment, and deploying it in a new environment. Wherever CIS runs, it watches the orchestration API, and updates the BIG-IP system’s configuration.
Working with BIG-IP HA pairs or device groups¶
You can use the F5 Container Ingress Services to manage a BIG-IP HA active-standby pair or device group. The deployment details vary depending on the platform. For most, the basic principle is the same: You should run one BIG-IP Controller instance for each BIG-IP device.
You have one active and one standby BIG-IP device. You want to manage a Kubernetes Cluster using a single BIG-IP partition. For your HA setup, you’d deploy two BIG-IP Controller instances - one for each BIG-IP device. To help ensure Controller HA, you can deploy each Controller instance on a separate Node in the cluster.
BIG-IP config sync¶
Each Container Connector monitors the BIG-IP partition it manages for configuration changes. If it discovers changes, the Connector reapplies its own configuration to the BIG-IP system.
F5 does not recommend making configuration changes to objects in any partition managed by a BIG-IP Controller via any other means (for example, the configuration utility, TMOS, or by syncing configuration from another device or service group). Doing so may result in disruption of service or unexpected behavior.
Notice for Kubernetes and OpenShift users¶
CIS uses FDB entries and ARP records to identify the Cluster resources associated with BIG-IP Nodes. Because BIG-IP config-sync doesn’t include FDB entries or ARP records, F5 does not recommend using automatic configuration sync when managing a BIG-IP HA pair or cluster with the BIG-IP Controller.
If you use automatic config-sync on devices managed by the BIG-IP Controller, there will be a service interruption window when failover occurs. This window will occur between the standby device activating and the BIG-IP Controller updating the FDB and ARP records on the device.
The length of time for the service interruption will be the default –node-poll-interval setting; 30 seconds. The –node-poll-interval setting is not currently configurable.
To experience shorter shorter service interruption when failover events occurs, deploy one CIS instance per BIG-IP device.
If you choose to deploy one BIG-IP Controller instance and manually sync configurations to the standby device, be sure to always sync from the BIG-IP device managed by the BIG-IP Controller to the other device(s) in the group.
BIG-IP SNATs and SNAT automap¶
All virtual servers created by the Container Connectors use BIG-IP Automap SNAT by default. This feature lets you map origin IP addresses – for example, the flannel or OpenShift SDN
public-ip for each Pod – to a pool of translation addresses on the BIG-IP system.
When the BIG-IP system processes connections from inside the Cluster network, it chooses a translation address from the pool of available self IP addresses. SNAT automap prefers floating self IP addresses to static ones, to support seamless failover between paired or clustered devices.
If the SNAT automap feature can’t find an available floating self IP in the VXLAN tunnel, it may use a floating self IP from another VLAN as the translation address. If the BIG-IP selects a floating IP from another VLAN as the translation address, you will not be able to pass traffic to your Cluster.
Container Ingress Services¶
- Reference documentation
- BIG-IP and flannel VXLAN Integration
- Add BIG-IP device to flannel VXLAN
- Install the BIG-IP Controller: Kubernetes
- Managed BIG-IP objects
- Attaching Virtual Servers to Services
- Using the BIG-IP Controller as an Ingress controller
- CIS and AS3 Extension integration
- Manage your BIG-IP virtual servers
- F5 Resources Explained
- Deploy iApps with the BIG-IP Controller
- BIG-IP Controller Modes
- Use the BIG-IP Controller as a Kubernetes Ingress Controller
- Using AS3 for BIG-IP Orchestration in Kubernetes