-
Notifications
You must be signed in to change notification settings - Fork 223
Create an Internal Load Balancer if configured #1222
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
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -85,6 +85,26 @@ type Network struct { | |
| // created for the API Server. | ||
| // +optional | ||
| APIServerForwardingRule *string `json:"apiServerForwardingRule,omitempty"` | ||
|
|
||
| // APIInternalAddress is the IPV4 regional address assigned to the | ||
| // internal Load Balancer. | ||
| // +optional | ||
| APIInternalAddress *string `json:"apiInternalIpAddress,omitempty"` | ||
|
|
||
| // APIInternalHealthCheck is the full reference to the health check | ||
| // created for the internal Load Balancer. | ||
| // +optional | ||
| APIInternalHealthCheck *string `json:"apiInternalHealthCheck,omitempty"` | ||
|
|
||
| // APIInternalBackendService is the full reference to the backend service | ||
| // created for the internal Load Balancer. | ||
| // +optional | ||
| APIInternalBackendService *string `json:"apiInternalBackendService,omitempty"` | ||
|
|
||
| // APIInternalForwardingRule is the full reference to the forwarding rule | ||
| // created for the internal Load Balancer. | ||
| // +optional | ||
| APIInternalForwardingRule *string `json:"apiInternalForwardingRule,omitempty"` | ||
|
Comment on lines
+88
to
+107
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Are these fields all required when the Internal Load Balancer is set?
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Similar to the fields for the External Load Balancer (APIServer fields) these will be set to the resources created for the Internal Load Balancer when it is created, including the cluster name.
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Got it thanks |
||
| } | ||
|
|
||
| // NetworkSpec encapsulates all things related to a GCP network. | ||
|
|
@@ -114,6 +134,24 @@ type NetworkSpec struct { | |
| LoadBalancerBackendPort *int32 `json:"loadBalancerBackendPort,omitempty"` | ||
| } | ||
|
|
||
| // LoadBalancerType defines the Load Balancer that should be created. | ||
| type LoadBalancerType string | ||
|
|
||
| var ( | ||
| // External creates a Global External Proxy Load Balancer | ||
| // to manage traffic to backends in multiple regions. This is the default Load | ||
| // Balancer and will be created if no LoadBalancerType is defined. | ||
| External = LoadBalancerType("External") | ||
|
|
||
| // Internal creates a Regional Internal Passthrough Load | ||
| // Balancer to manage traffic to backends in the configured region. | ||
| Internal = LoadBalancerType("Internal") | ||
|
|
||
| // InternalExternal creates both External and Internal Load Balancers to provide | ||
| // separate endpoints for managing both external and internal traffic. | ||
| InternalExternal = LoadBalancerType("InternalExternal") | ||
| ) | ||
|
|
||
| // LoadBalancerSpec contains configuration for one or more LoadBalancers. | ||
| type LoadBalancerSpec struct { | ||
| // APIServerInstanceGroupTagOverride overrides the default setting for the | ||
|
|
@@ -123,6 +161,15 @@ type LoadBalancerSpec struct { | |
| // +kubebuilder:validation:Pattern=`(^[1-9][0-9]{0,31}$)|(^[a-z][a-z0-9-]{4,28}[a-z0-9]$)` | ||
| // +optional | ||
| APIServerInstanceGroupTagOverride *string `json:"apiServerInstanceGroupTagOverride,omitempty"` | ||
|
|
||
| // LoadBalancerType defines the type of Load Balancer that should be created. | ||
| // If not set, a Global External Proxy Load Balancer will be created by default. | ||
| // +optional | ||
| LoadBalancerType *LoadBalancerType `json:"loadBalancerType,omitempty"` | ||
|
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I had thought about but felt that type of API presents too much ambiguity and potential for error. For example with that type of array you could have the following potential combinations, all of which are in error:
Explicitly defining the Load Balancer configuration options seems more useful. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I could envision a However, I'm not sure that such complexity is worth it right now, or if there's near-term a use case for extending to N number of load balancers for internal/external. In that regard, I personally prefer the solution presented here, since it's avoid ambiguity and doesn't impose too many more validations. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I think you can achieve those via kubebuilder validations : I know I had suggested making LoadBalancers of type []LoadBalancerType, with the array containing There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Are the 4 optional fields added to Network type allowed to be empty when LoadBalancerType is InternalLoadBalancerOnly/DualLoadBalancer ? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Also, can the value of LoadBalancerType change once set i.e is it immutable? If so, do we need a validateUpdate() webhook preventing an update for LoadBalancerType?
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Yes, these marked as
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
That's a good point, thanks for catching that. I will add a webhook check for it. Done, |
||
|
|
||
| // InternalLoadBalancer is the configuration for an Internal Passthrough Network Load Balancer. | ||
| // +optional | ||
| InternalLoadBalancer *LoadBalancer `json:"internalLoadBalancer,omitempty"` | ||
bfournie marked this conversation as resolved.
Show resolved
Hide resolved
|
||
| } | ||
|
|
||
| // SubnetSpec configures an GCP Subnet. | ||
|
|
@@ -278,3 +325,19 @@ type ObjectReference struct { | |
| // +kubebuilder:validation:Required | ||
| Name string `json:"name"` | ||
| } | ||
|
|
||
| // LoadBalancer specifies the configuration of a LoadBalancer. | ||
| type LoadBalancer struct { | ||
| // Name is the name of the Load Balancer. If not set a default name | ||
| // will be used. For an Internal Load Balancer service the default | ||
| // name is "api-internal". | ||
| // +kubebuilder:validation:Optional | ||
| // +kubebuilder:validation:Pattern=`(^[1-9][0-9]{0,31}$)|(^[a-z][a-z0-9-]{4,28}[a-z0-9]$)` | ||
| // +optional | ||
| Name *string `json:"name,omitempty"` | ||
|
|
||
| // Subnet is the name of the subnet to use for a regional Load Balancer. A subnet is | ||
| // required for the Load Balancer, if not defined the first configured subnet will be | ||
| // used. | ||
| Subnet *string `json:"subnet,omitempty"` | ||
bfournie marked this conversation as resolved.
Show resolved
Hide resolved
|
||
| } | ||
Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I understand that this is a breaking change, but should we consider a structure to hold these values? The added values are the same as those for the api server, so a lot of duplicated values appear.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The main reason I didn't do that was because it is a breaking change, I tried to keep the same API for consistency and just add the additional fields.
If the consensus is that its OK to change this API I can make it an array.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
make sense as we are adding this to add as a struct
wdyt @damdo
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
OK, how would we handle the API in this case though? Would the existing fields -
APIServerAddress,APIServerHealthChecketc need to be marked as deprecated but still handled for a few releases until the deprecation is complete? It seems like it will add a lot of complexity to this API.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I tend to agree with @bfournie here.
I'd probably stick with a non-breaking change, and then schedule a full API re-review for a new v1beta2 where we can improve the situation and plan the breaking changes we want to make to the API to clean it up.