fix: apply different network policies based on current target #97

letian · 2025-08-06T16:24:29Z

letian commented

2025-08-06 16:24:29 +00:00

Currently, the k3d-harmony server IP range is hardcoded in the K8sTenantManager network policy.

Possible fixes

1. Separate implementation of TenantManager for K8s (generic) VS for K3d/s

Introduce an entirely different implementation for K3d/s of the TenantManager.

Pros:

we already have a trait for TenantManager, it's fairly simple to create a new implementation and let K8sAnywhere pick one or the other based on the client source (e.g. LocalK3d)
more flexible in the future if we have other point of changes within the tenant manager (e.g. custom resource quota, limit range, etc.)

Cons:

entire rewrite of the network manager implementation, lot of common things between the K8sTenantManager and the K3dTenantManager -> lot of duplication

2. Strategies to generate the network policy config

Instead of having 2 entirely different implementations for the TenantManager, introduce a strategy to generate only the network policy.

struct K8sTenantConfig {
  network_policy_strategy: NetworkPolicyStrategy;
}

provision_tenant(config) {
  let network_policy = self.network_policy_strategy.build_policy(config);
}

Pros:

more granular approach, allowing only to change 1 specific part of the TenantManager implementation

Cons:

less flexible than 1: have to introduce new strategies in the future for other point of changes if needed
still some duplication as most of the network policy config will be the same

3. Strategy to apply changes to the network policy config

Let the K8sTenantManager work as it currently does, but allow for changes of the base config that was generated:

struct K8sTenantConfig {
  network_policy_strategy: NetworkPolicyStrategy;
}

provision_tenant(config) {
  let network_policy = self.build_network_policy(config);
  let network_policy = self.network_policy_strategy.adjust_policy(network_policy, config);
}

Pros:

very specific approach: only change what's needed, avoid all duplication

Cons:

"merging" strategy a bit more complicated if we need to change something that was already present in the base config
less flexible than 1 as well

Decision

For now, option (3) seem the best approach: minimal changes to the existing code, no duplication. As we don't know yet how all of this will evolve, it will be easier to change in the future if we were wrong than the other approaches.

Fixes #94

Currently, the k3d-harmony server IP range is hardcoded in the K8sTenantManager network policy. ## Possible fixes ### 1. Separate implementation of TenantManager for K8s (generic) VS for K3d/s Introduce an entirely different implementation for K3d/s of the `TenantManager`. **Pros:** - we already have a trait for `TenantManager`, it's fairly simple to create a new implementation and let `K8sAnywhere` pick one or the other based on the client source (e.g. `LocalK3d`) - more flexible in the future if we have other point of changes within the tenant manager (e.g. custom resource quota, limit range, etc.) **Cons:** - entire rewrite of the network manager implementation, lot of common things between the `K8sTenantManager` and the `K3dTenantManager` -> lot of duplication ### 2. Strategies to generate the network policy config Instead of having 2 entirely different implementations for the `TenantManager`, introduce a _strategy_ to generate only the network policy. ```rs struct K8sTenantConfig { network_policy_strategy: NetworkPolicyStrategy; } provision_tenant(config) { let network_policy = self.network_policy_strategy.build_policy(config); } ``` **Pros:** - more granular approach, allowing only to change 1 specific part of the TenantManager implementation **Cons:** - less flexible than 1: have to introduce new strategies in the future for other point of changes if needed - still some duplication as most of the network policy config will be the same ### 3. Strategy to apply changes to the network policy config Let the `K8sTenantManager` work as it currently does, but allow for changes of the base config that was generated: ```rs struct K8sTenantConfig { network_policy_strategy: NetworkPolicyStrategy; } provision_tenant(config) { let network_policy = self.build_network_policy(config); let network_policy = self.network_policy_strategy.adjust_policy(network_policy, config); } ``` **Pros:** - very specific approach: only change what's needed, avoid all duplication **Cons:** - "merging" strategy a bit more complicated if we need to change something that was already present in the base config - less flexible than 1 as well ## Decision For now, option (3) seem the best approach: minimal changes to the existing code, no duplication. As we don't know yet how all of this will evolve, it will be easier to change in the future if we were wrong than the other approaches. --- Fixes #94

letian added 1 commit 2025-08-06 20:13:05 +00:00

add strategy to adjust k8s tenant network policy

Run Check Script / check (pull_request) Has been cancelled

Details

044aab13f5

johnride approved these changes 2025-08-08 17:21:42 +00:00

johnride left a comment

This feels entirely correct. As we discussed, the complexity comes from the Anywhere part of K8sAnywhere module, so it should be solved within the logical boundaries of K8sAnywhere. And all that K8sAnywhere has to do is decide which implementation to delegate to, which a Strategy seems perfectly suited for here.

This feels entirely correct. As we discussed, the complexity comes from the `Anywhere` part of `K8sAnywhere` module, so it should be solved within the logical boundaries of K8sAnywhere. And all that K8sAnywhere has to do is decide which implementation to delegate to, which a Strategy seems perfectly suited for here.

letian added 1 commit 2025-08-14 19:27:28 +00:00

add issue ref to remove hardcoded value

Run Check Script / check (pull_request) Has been cancelled

Details

d207ca6c3d

letian changed title from ~~WIP: fix: autodetect k3d-harmony server IP~~ to fix: apply different network policies based on current target

2025-08-14 19:28:31 +00:00

letian force-pushed autodetect-k3d-server-ip from 113c1b0f9e to 51214daf72

2025-08-14 19:34:35 +00:00

Compare

letian force-pushed autodetect-k3d-server-ip from f7b0b1e0c9 to 5c8799f6d1

2025-08-14 20:21:22 +00:00