Closed pQraus closed 6 days ago
Currently this is an expected behaviour. We update cluster details (including if it's online or offline) every five minutes, so when first request tries to get cluster status it's deemed offline (since cluster is not up yet) and for the next 5 minutes all requests will be denied, until cluster' status is updated. I'll look into improving this situation.
I have a single node k8s-cluster and a teleport agent running outside from k8s but on the same node. When the node is started, k8s and the teleport agent are started at the same time. K8s takes longer to start than the agent. The agent uses a kubeconfig to connect to the cluster.
Expected behaviour:
As soon as k8s is started, requests can also be forwarded successfully to the kube-apiserver (default behaviour in teleport < 14)
Current behaviour:
When k8s is ready, it takes about 5 minutes until the agent can forward the requests to the kube-apiserver.
Bug details: