Forum Discussion
Altocumulusfeature request: container egress service
NimbostratusHello,
You've outlined a very interesting and valuable problem, along with a potential solution for managing egress traffic in OpenShift using F5 BIG-IP. Let's break down the concepts and explore the feasibility of a Container Egress Service (CES) as you've described.
Understanding the Problem:
Namespace-Specific Egress: You want to assign dedicated egress IP addresses to individual namespaces in OpenShift, rather than relying on node IPs or a single shared egress IP.
Scalability: The AdminPolicyBasedExternalRoute approach, while functional, doesn't scale well when dealing with numerous namespaces and their respective egress IP mappings.
Dynamic Pod IPs: Pod IPs are ephemeral, changing with pod restarts or scaling. Manual management of these IPs in F5 BIG-IP is impractical.
Egress Control: You need a dynamic and automated mechanism to manage the lifecycle of pod IPs and their corresponding egress configurations on the F5 BIG-IP.
Best Regards
AltocumulusHi Tomas
Exactly. Using a gateway device or F5 ltm interface per namespace is impractical. Using an address list for the source of a forwarding ip virtual server would give the desired functionality. A reverse CIS solution. An outline of the controller flow. Which will need some more refinement,
watch the configmap
if a tenant is removed from the configmap then
delete the external gateway definition
delete the forwarding ip virtual server
delete the address list
delete the snat pool
if egress ip is changed then
update snat pool with new ip address
only for the tenants listed in the configmap
watch the tenant labeled namespaces for AdminPolicyBasedExternalRoute definition
if AdminPolicyBasedExternalRoute not defined then
define AdminPolicyBasedExternalRoute
watch the tenant labeled namespaces for pods
if a pod is created
if address list does not exist yet then
create an address list with pod ip.
else
add the pod ip address to the address list of the tenant
if forwarding ip virtual server does not exist then
if snat pool does not exist then
create snat pool with tenant ip address from the configmap
else
if snat pool ip is not the egress ip then
update the snat pool ip with the egress ip
create forwarding ip virtual server with the previously defined snat and address list
if a pod is deleted then
delete the pod ip from the address list of the corresponding tenant
if tenant has no pods and no_tenant_vs = false then
if exists then delete the virtual server
if exists then delete the snat pool
if exists delete the address list
set no_tenant_vs = true
- PaulVogt
A pod could start making connections before the new pod ip is added to the forwarding ip virtual server. This can be solved with using an initcontainer that tests the network connectivity.
