pkg/lb: Misc KPR subflags support #39767
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
59c3c89 to
b1cd8c2
Compare
|
/test |
brb
added a commit
that referenced
this pull request
Jun 13, 2025
This commit introduces kpr.Cell which provides kpr.KPRConfig. The latter is derived from KPR flags such as --kube-proxy-replacement, --enable-node-port and so on. The new cell allows pkg/loadbalancer to *not* depend on the DaemonConfigPromise when implementing the flags support (will be done in a separate PR). The promise dependence comes from the fact that previously initKubeProxyReplacement() could modify some of the flags (for example, if --kpr=true, then --enable-node-port will be set to true). The invocation of the helper function happened after the DaemonConfig has been constructed. Thus, any pkg must consume the DaemonConfig in a form of the promise to avoid the races. For now the cell contains only a few flags (required for #39767). In v1.19 we will move the rest of the flags. Afterwards, we can re-consider whether having the dedicated cell for the KPR config makes sense (for example, we could move it to pkg/loadbalancer). Signed-off-by: Martynas Pumputis <martynas@isovalent.com>
brb
added a commit
that referenced
this pull request
Jun 13, 2025
This commit introduces kpr.Cell which provides kpr.KPRConfig. The latter is derived from KPR flags such as --kube-proxy-replacement, --enable-node-port and so on. The new cell allows pkg/loadbalancer to *not* depend on the DaemonConfigPromise when implementing the flags support (will be done in a separate PR). The promise dependence comes from the fact that previously initKubeProxyReplacement() could modify some of the flags (for example, if --kpr=true, then --enable-node-port will be set to true). The invocation of the helper function happened after the DaemonConfig has been constructed. Thus, any pkg must consume the DaemonConfig in a form of the promise to avoid the races. For now the cell contains only a few flags (required for #39767). In v1.19 we will move the rest of the flags. Afterwards, we can re-consider whether having the dedicated cell for the KPR config makes sense (for example, we could move it to pkg/loadbalancer). Signed-off-by: Martynas Pumputis <martynas@isovalent.com>
brb
added a commit
that referenced
this pull request
Jun 13, 2025
This commit introduces kpr.Cell which provides kpr.KPRConfig. The latter is derived from KPR flags such as --kube-proxy-replacement, --enable-node-port and so on. The new cell allows pkg/loadbalancer to *not* depend on the DaemonConfigPromise when implementing the flags support (will be done in a separate PR). The promise dependence comes from the fact that previously initKubeProxyReplacement() could modify some of the flags (for example, if --kpr=true, then --enable-node-port will be set to true). The invocation of the helper function happened after the DaemonConfig has been constructed. Thus, any pkg must consume the DaemonConfig in a form of the promise to avoid the races. For now the cell contains only a few flags (required for #39767). In v1.19 we will move the rest of the flags. Afterwards, we can re-consider whether having the dedicated cell for the KPR config makes sense (for example, we could move it to pkg/loadbalancer). Signed-off-by: Martynas Pumputis <martynas@isovalent.com>
brb
added a commit
that referenced
this pull request
Jun 13, 2025
This commit introduces kpr.Cell which provides kpr.KPRConfig. The latter is derived from KPR flags such as --kube-proxy-replacement, --enable-node-port and so on. The new cell allows pkg/loadbalancer to *not* depend on the DaemonConfigPromise when implementing the flags support (will be done in a separate PR). The promise dependence comes from the fact that previously initKubeProxyReplacement() could modify some of the flags (for example, if --kpr=true, then --enable-node-port will be set to true). The invocation of the helper function happened after the DaemonConfig has been constructed. Thus, any pkg must consume the DaemonConfig in a form of the promise to avoid the races. For now the cell contains only a few flags (required for #39767). In v1.19 we will move the rest of the flags. Afterwards, we can re-consider whether having the dedicated cell for the KPR config makes sense (for example, we could move it to pkg/loadbalancer). Signed-off-by: Martynas Pumputis <martynas@isovalent.com>
brb
added a commit
that referenced
this pull request
Jun 13, 2025
This commit introduces kpr.Cell which provides kpr.KPRConfig. The latter is derived from KPR flags such as --kube-proxy-replacement, --enable-node-port and so on. The new cell allows pkg/loadbalancer to *not* depend on the DaemonConfigPromise when implementing the flags support (will be done in a separate PR). The promise dependence comes from the fact that previously initKubeProxyReplacement() could modify some of the flags (for example, if --kpr=true, then --enable-node-port will be set to true). The invocation of the helper function happened after the DaemonConfig has been constructed. Thus, any pkg must consume the DaemonConfig in a form of the promise to avoid the races. For now the cell contains only a few flags (required for #39767). In v1.19 we will move the rest of the flags. Afterwards, we can re-consider whether having the dedicated cell for the KPR config makes sense (for example, we could move it to pkg/loadbalancer). Signed-off-by: Martynas Pumputis <martynas@isovalent.com>
b1cd8c2 to
b942256
Compare
brb
added a commit
that referenced
this pull request
Jun 13, 2025
This commit introduces kpr.Cell which provides kpr.KPRConfig. The latter is derived from KPR flags such as --kube-proxy-replacement, --enable-node-port and so on. The new cell allows pkg/loadbalancer to *not* depend on the DaemonConfigPromise when implementing the flags support (will be done in a separate PR). The promise dependence comes from the fact that previously initKubeProxyReplacement() could modify some of the flags (for example, if --kpr=true, then --enable-node-port will be set to true). The invocation of the helper function happened after the DaemonConfig has been constructed. Thus, any pkg must consume the DaemonConfig in a form of the promise to avoid the races. For now the cell contains only a few flags (required for #39767). In v1.19 we will move the rest of the flags. Afterwards, we can re-consider whether having the dedicated cell for the KPR config makes sense (for example, we could move it to pkg/loadbalancer). Signed-off-by: Martynas Pumputis <martynas@isovalent.com>
|
/test |
brb
added a commit
that referenced
this pull request
Jun 13, 2025
This commit introduces kpr.Cell which provides kpr.KPRConfig. The latter is derived from KPR flags such as --kube-proxy-replacement, --enable-node-port and so on. The new cell allows pkg/loadbalancer to *not* depend on the DaemonConfigPromise when implementing the flags support (will be done in a separate PR). The promise dependence comes from the fact that previously initKubeProxyReplacement() could modify some of the flags (for example, if --kpr=true, then --enable-node-port will be set to true). The invocation of the helper function happened after the DaemonConfig has been constructed. Thus, any pkg must consume the DaemonConfig in a form of the promise to avoid the races. For now the cell contains only a few flags (required for #39767). In v1.19 we will move the rest of the flags. Afterwards, we can re-consider whether having the dedicated cell for the KPR config makes sense (for example, we could move it to pkg/loadbalancer). Signed-off-by: Martynas Pumputis <martynas@isovalent.com>
brb
added a commit
that referenced
this pull request
Jun 13, 2025
This commit introduces kpr.Cell which provides kpr.KPRConfig. The latter is derived from KPR flags such as --kube-proxy-replacement, --enable-node-port and so on. The new cell allows pkg/loadbalancer to *not* depend on the DaemonConfigPromise when implementing the flags support (will be done in a separate PR). The promise dependence comes from the fact that previously initKubeProxyReplacement() could modify some of the flags (for example, if --kpr=true, then --enable-node-port will be set to true). The invocation of the helper function happened after the DaemonConfig has been constructed. Thus, any pkg must consume the DaemonConfig in a form of the promise to avoid the races. For now the cell contains only a few flags (required for #39767). In v1.19 we will move the rest of the flags. Afterwards, we can re-consider whether having the dedicated cell for the KPR config makes sense (for example, we could move it to pkg/loadbalancer). Signed-off-by: Martynas Pumputis <martynas@isovalent.com>
brb
added a commit
that referenced
this pull request
Jun 13, 2025
This commit introduces kpr.Cell which provides kpr.KPRConfig. The latter is derived from KPR flags such as --kube-proxy-replacement, --enable-node-port and so on. The new cell allows pkg/loadbalancer to *not* depend on the DaemonConfigPromise when implementing the flags support (will be done in a separate PR). The promise dependence comes from the fact that previously initKubeProxyReplacement() could modify some of the flags (for example, if --kpr=true, then --enable-node-port will be set to true). The invocation of the helper function happened after the DaemonConfig has been constructed. Thus, any pkg must consume the DaemonConfig in a form of the promise to avoid the races. For now the cell contains only a few flags (required for #39767). In v1.19 we will move the rest of the flags. Afterwards, we can re-consider whether having the dedicated cell for the KPR config makes sense (for example, we could move it to pkg/loadbalancer). Signed-off-by: Martynas Pumputis <martynas@isovalent.com>
joestringer
reviewed
Jun 13, 2025
|
What's the goal for this PR and rationale for exception to feature freeze? |
@joestringer Unfortunately, this is needed by the new |
brb
added a commit
that referenced
this pull request
Jun 16, 2025
This commit introduces kpr.Cell which provides kpr.KPRConfig. The latter is derived from KPR flags such as --kube-proxy-replacement, --enable-node-port and so on. The new cell allows pkg/loadbalancer to *not* depend on the DaemonConfigPromise when implementing the flags support (will be done in a separate PR). The promise dependence comes from the fact that previously initKubeProxyReplacement() could modify some of the flags (for example, if --kpr=true, then --enable-node-port will be set to true). The invocation of the helper function happened after the DaemonConfig has been constructed. Thus, any pkg must consume the DaemonConfig in a form of the promise to avoid the races. For now the cell contains only a few flags (required for #39767). In v1.19 we will move the rest of the flags. Afterwards, we can re-consider whether having the dedicated cell for the KPR config makes sense (for example, we could move it to pkg/loadbalancer). Signed-off-by: Martynas Pumputis <martynas@isovalent.com>
github-merge-queue bot
pushed a commit
that referenced
this pull request
Jun 16, 2025
This commit introduces kpr.Cell which provides kpr.KPRConfig. The latter is derived from KPR flags such as --kube-proxy-replacement, --enable-node-port and so on. The new cell allows pkg/loadbalancer to *not* depend on the DaemonConfigPromise when implementing the flags support (will be done in a separate PR). The promise dependence comes from the fact that previously initKubeProxyReplacement() could modify some of the flags (for example, if --kpr=true, then --enable-node-port will be set to true). The invocation of the helper function happened after the DaemonConfig has been constructed. Thus, any pkg must consume the DaemonConfig in a form of the promise to avoid the races. For now the cell contains only a few flags (required for #39767). In v1.19 we will move the rest of the flags. Afterwards, we can re-consider whether having the dedicated cell for the KPR config makes sense (for example, we could move it to pkg/loadbalancer). Signed-off-by: Martynas Pumputis <martynas@isovalent.com>
b942256 to
8416a4e
Compare
|
/test |
joamaki
approved these changes
Jun 16, 2025
8416a4e to
15b9fa2
Compare
|
/test |
Do not provision HostPort services if !EnableHostPort. The check will go away in v1.19 - #39582. Signed-off-by: Martynas Pumputis <martynas@isovalent.com>
The check will go away in v1.19 - #39582. Signed-off-by: Martynas Pumputis <martynas@isovalent.com>
The flag is most likely to be removed in v1.19. Signed-off-by: Martynas Pumputis <martynas@isovalent.com>
The flag is going to be removed in v1.19 - #39851. Signed-off-by: Martynas Pumputis <martynas@isovalent.com>
Create a LoadBalancer service for HC only if EnableHealthCheckLoadBalancerIP is set. More ctx about the latter - #26728. Signed-off-by: Martynas Pumputis <martynas@isovalent.com>
15b9fa2 to
a637eff
Compare
|
/test |
|
I changed the release note category for this because there is no release note and the title of the PR is very cryptic. If this has user facing impact, feel free to switch it back but please also write a release note that users can understand (either through the |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
See commit msgs. TL;DR the following flag support has been added to the pkg/lb:
EnableHostPort(to-be removed in v1.19)EnableSessionAffinity(to-be removed in v1.19)EnableSVCSourceRangeCheck(to-be removed in v1.19)EnableInternalTrafficPolicy(to-be removed in v1.19)EnableHealthCheckLoadBalancerIP(need to ping Google folks whether their external LB HC can do HC using a node IP instead of LB IP. if yes, then we can remove the flag and the code)Blocked by #40026.