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
Feature Request: add a new proxy strategy for k8s "failure zone" or similar.
Currently, konnectivity-server supports 3 --proxy-strategy flag cases: default, destHost, and defaultRoute (code), and agent supports 6 --agent-identifiers cases: ipv4, ipv6, host, cidr, uid, default-route. (code).
I see discussion of "failure zone" in the original PR adding proxy stragies (#144), but the reference implementation does not fully support it.
The rough task list as I imagine it:
API decisions
how does apiserver specify the hint (likely needs a dial protocol update)
how does konnectivity-agent specify zone
konnectivity-server changes (new proxy strategy)
konnectivity-agent changes (support new identifier)
apiserver changes (pass the dial hint)
In our specific use case, in a given cluster we run a single Deployment of agents across GCE zones, with topologySpreadConstraints that includes well-known labeltopologyKey: topology.kubernetes.io/zone. Supporting that same value would be ideal; but I see that the Downward API does not currently support providing Node labels to Pods (kubernetes/kubernetes#40610).
UPDATES:
There is lots of ambiguity here, the above task list might not be the right approach. It may be difficult to make apiserver support the hint, since it's dialers are often created far away from the associated resource(s). It may be more feasible to
calculate "failure zone" from the dial IP address. Another question is whether to build all the logic into Konnectivity components, or put some responsibility on the cloud provider.
The text was updated successfully, but these errors were encountered:
Feature Request: add a new proxy strategy for k8s "failure zone" or similar.
Currently,
konnectivity-server
supports 3--proxy-strategy
flag cases: default, destHost, and defaultRoute (code), andagent
supports 6--agent-identifiers
cases: ipv4, ipv6, host, cidr, uid, default-route. (code).I see discussion of "failure zone" in the original PR adding proxy stragies (#144), but the reference implementation does not fully support it.
The rough task list as I imagine it:
konnectivity-agent
specify zonekonnectivity-server
changes (new proxy strategy)konnectivity-agent
changes (support new identifier)In our specific use case, in a given cluster we run a single Deployment of agents across GCE zones, with
topologySpreadConstraints
that includes well-known labeltopologyKey: topology.kubernetes.io/zone
. Supporting that same value would be ideal; but I see that the Downward API does not currently support providing Node labels to Pods (kubernetes/kubernetes#40610).UPDATES:
There is lots of ambiguity here, the above task list might not be the right approach. It may be difficult to make apiserver support the hint, since it's dialers are often created far away from the associated resource(s). It may be more feasible to
calculate "failure zone" from the dial IP address. Another question is whether to build all the logic into Konnectivity components, or put some responsibility on the cloud provider.
The text was updated successfully, but these errors were encountered: