-
Notifications
You must be signed in to change notification settings - Fork 193
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
RFE: Target discrete Pool_Member entities with ConfigMap #3374
Labels
Comments
sectoreleven
changed the title
Target discrete Pool_Member entities with ConfigMap
RFE: Target discrete Pool_Member entities with ConfigMap
Apr 12, 2024
Created [CONTCNTR-4698] for internal tracking. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Title
Target discrete Pool_Member entities with ConfigMap
Description
Allow CIS to target discrete
Pool_Member
entities in a given AS3Pool
when using ConfigMap.Actual Problem
AS3 and BIG-IP LTM allow application flow designers to treat subsets of pool members differently by setting member-level properties such as
adminState
,priorityGroup
,ratio
,connectionLimit
, et cetera. This lets the BIG-IP have a single pool with dynamic traffic characteristics based on the availability and capacity of the various backend members.CIS, however, currently targets a single pool, and replaces the entire pool contents with all members of a given K8s
Service
. This prevents us from doing the above fine-grained control. When using ConfigMap, if multiplePool_Members
are defined in the AS3 declaration, they are not respected and only one is used. (It is unclear if it is order-based or randomly selected.)Solution Proposed
Enhance the pool-targeting capabilities for ConfigMap to allow the selection of a given
Pool_Member
, allowing us to define multiple Services targeting the same pool but different member groups; when the resultant AS3 declaration is composed by CIS, respect the properties defined on eachPool_Member
.A field would need to be selected in (or a new field added to) the AS3
Pool_Member
schema to identify a given member; for the purposes of this RFE, we utilize the existingremark
field. It may be better to add aname
field instead.For example - suppose an application that is running on a cluster where the nodes are geographically separated into availability zones. Imagine also that the secondary zone does not have the same compute capability as the primary.
To ensure maximum availability, the application team runs two Deployments of their product in the cluster; pods from these Deployments are scheduled to their respective nodes (and thus availability zones) via
nodeSelector
. The failsafe group should not activate unless the primary is down. They choose to implement this using Priority Activation Groups on the BIG-IP.Given this scenario, we propose the following resources:
Pool
that looks as follows:This would build a single Pool on the BIG-IP with members dynamically populated from the Services, where the primary priority group on the BIG-IP routes to the Service in the primary zone, and likewise for the failsafe.
Alternatives
We have built an alternative prototype that would utilize discrete BIG-IP pools, but that pushes selection logic to request-time via iRule or LTM Policy. Using the platform-native capabilities to build pools is significantly preferred, and allows highly-customizable scenarios where apps can be up continually in the Kubernetes cluster, having the BIG-IP device provide advanced traffic-routing capabilities.
Additional context
This relates to #3277 and expands on discussion from that bug report.
While the scenario above uses Priority Group Activation, this would be beneficial for any scenario where a single BIG-IP pool is desired containing members with different characteristics, represented by different Services in the Kubernetes cluster.
The text was updated successfully, but these errors were encountered: