You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I’m currently using the F5 BIG-IP Controller for Kubernetes to manage virtual servers directly from Kubernetes. However, I’ve encountered a challenge in my setup due to the following configuration:
1. We have two data centers, each with one BIG-IP device.
2. These two BIG-IPs are configured as an Active-Active pair via ConfigSync (GBP), so any changes made on one device are synchronized to the other.
3. The k8s-bigip-ctlr is configured to communicate with only one BIG-IP device as its API endpoint.
Problem:
When performing maintenance on one of the BIG-IP devices, I would need to manually reconfigure the k8s-bigip-ctlr to point to the other device, as it only allows specifying one endpoint at a time.
Deploying two k8s-bigip-ctlr instances (one for each BIG-IP device) is not ideal, as this could lead to conflicts. Both instances would attempt to create and manage the same resources, while the BIG-IP pair itself also synchronizes changes, potentially causing race conditions or duplicate configurations.
Additionally, floating IPs are not an option for the API endpoint in this setup, as they are typically designed for the Data Plane and not the Control Plane. In an Active-Active configuration, there is no native failover mechanism for the API endpoints.
Considerations:
I have also considered deploying an external Load Balancer (e.g., HAProxy or NGINX) in front of the BIG-IP devices to act as a virtual API endpoint. This could potentially provide failover for the k8s-bigip-ctlr without requiring manual reconfiguration. However, I’ve encountered the following challenge:
• There doesn’t seem to be a reliable Health Check mechanism to determine if a BIG-IP device’s API endpoint is currently “active” or “deactivated” (e.g., in maintenance mode). Without such a health check, the Load Balancer cannot safely route traffic to the correct BIG-IP device.
Question:
What is the recommended approach for handling this scenario with the k8s-bigip-ctlr?
• Is there a way to configure the k8s-bigip-ctlr to support automatic failover between multiple BIG-IP devices?
• Would a Load Balancer in front of the API endpoints be a viable solution? If so, is there a recommended Health Check for this purpose?
• Are there plans to support specifying multiple BIG-IP endpoints in future versions of the k8s-bigip-ctlr?
Any guidance or best practices for managing an Active-Active BIG-IP pair with k8s-bigip-ctlr would be greatly appreciated.
Thank you for your time and support!
Best regards,
Jan
The text was updated successfully, but these errors were encountered:
Hello F5 Team,
I’m currently using the F5 BIG-IP Controller for Kubernetes to manage virtual servers directly from Kubernetes. However, I’ve encountered a challenge in my setup due to the following configuration:
1. We have two data centers, each with one BIG-IP device.
2. These two BIG-IPs are configured as an Active-Active pair via ConfigSync (GBP), so any changes made on one device are synchronized to the other.
3. The k8s-bigip-ctlr is configured to communicate with only one BIG-IP device as its API endpoint.
Problem:
When performing maintenance on one of the BIG-IP devices, I would need to manually reconfigure the k8s-bigip-ctlr to point to the other device, as it only allows specifying one endpoint at a time.
Deploying two k8s-bigip-ctlr instances (one for each BIG-IP device) is not ideal, as this could lead to conflicts. Both instances would attempt to create and manage the same resources, while the BIG-IP pair itself also synchronizes changes, potentially causing race conditions or duplicate configurations.
Additionally, floating IPs are not an option for the API endpoint in this setup, as they are typically designed for the Data Plane and not the Control Plane. In an Active-Active configuration, there is no native failover mechanism for the API endpoints.
Considerations:
I have also considered deploying an external Load Balancer (e.g., HAProxy or NGINX) in front of the BIG-IP devices to act as a virtual API endpoint. This could potentially provide failover for the k8s-bigip-ctlr without requiring manual reconfiguration. However, I’ve encountered the following challenge:
• There doesn’t seem to be a reliable Health Check mechanism to determine if a BIG-IP device’s API endpoint is currently “active” or “deactivated” (e.g., in maintenance mode). Without such a health check, the Load Balancer cannot safely route traffic to the correct BIG-IP device.
Question:
What is the recommended approach for handling this scenario with the k8s-bigip-ctlr?
• Is there a way to configure the k8s-bigip-ctlr to support automatic failover between multiple BIG-IP devices?
• Would a Load Balancer in front of the API endpoints be a viable solution? If so, is there a recommended Health Check for this purpose?
• Are there plans to support specifying multiple BIG-IP endpoints in future versions of the k8s-bigip-ctlr?
Any guidance or best practices for managing an Active-Active BIG-IP pair with k8s-bigip-ctlr would be greatly appreciated.
Thank you for your time and support!
Best regards,
Jan
The text was updated successfully, but these errors were encountered: