Using kubectl rollout status
may lead to connection churn and pauses
#7294
Labels
area/status-check
kind/friction
Issues causing user pain that do not have a workaround
source/partnerships
@npintaux is seeing long pauses with some deployments of the Cloud Code Go-Guestbook. When running with
-v debug
, he sees output like:If you match up the
Running command
s with theCommand output
s, you can see that the finalCommand output
forgo-guesbook-frontend
at t=0282 corresponds to thekubectl rollout status
at t=0101.Nicolas reports that running
kubectl rollout status
from the command-line during this pause returns much faster. He's trying to isolate whether this is an issue with the remote cluster or whether it's connection-establishment cost.Regardless, it would be better if our deployment status checks could talk to the cluster directly over a shared connection rather than repeatedly calling out to
kubectl rollout status
.The text was updated successfully, but these errors were encountered: