Closed ipochi closed 1 month ago
The Kubernetes project currently lacks enough contributors to adequately respond to all issues.
This bot triages un-triaged issues according to the following rules:
lifecycle/stale
is appliedlifecycle/stale
was applied, lifecycle/rotten
is appliedlifecycle/rotten
was applied, the issue is closedYou can:
/remove-lifecycle stale
/close
Please send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle stale
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues.
This bot triages un-triaged issues according to the following rules:
lifecycle/stale
is appliedlifecycle/stale
was applied, lifecycle/rotten
is appliedlifecycle/rotten
was applied, the issue is closedYou can:
/remove-lifecycle rotten
/close
Please send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle rotten
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.
This bot triages issues according to the following rules:
lifecycle/stale
is appliedlifecycle/stale
was applied, lifecycle/rotten
is appliedlifecycle/rotten
was applied, the issue is closedYou can:
/reopen
/remove-lifecycle rotten
Please send feedback to sig-contributor-experience at kubernetes/community.
/close not-planned
@k8s-triage-robot: Closing this issue, marking it as "Not Planned".
Currently the server readiness is a simple check i.e if atleast one agent is connected
This works absolutely fine in the case of default proxy strategy. However in the case of destHost and default-route strategies, especially in a scenario described by hypershift project member in the issue-496.
excerpt
In such a scenario, the agents in the control plane network would have a much quicker route to get connected to server(being in the same network) and upon doing so konnectivity-server readiness becomes true. The agents in the customer network if connected later wouldn't create a problem, however if they cannot and are set default-route as true, this poses problem as of today kube-apiserver doesn't have any mechanism to know if the apiserver -> konnectivity-server -> konnectivity-agent route is fully functional or not.