kubectl: Rollout status hangs for 5 minutes after success message

What happened: After running

kubectl rollout status deployment/my-app

the client returns deployment "my-app" successfully rolled out. After this it’s stuck for ~5 minutes causing our pipeline to run for a long time because this happens for every service for which we call rollout status (also happens when running from a local client). This is happening only on the cluster that we recently upgraded to kubernetes v1.21.8. On the clusters running kubernetes v1.19.7 this is issue is not happening. I tried passing --watch=false, selecting a specific revision and not providing the namespace but those didn’t change anything.

What you expected to happen: I expect the process to finish shortly after the success message is displayed (as is happening on the clusters running the older kubernetes version).

How to reproduce it (as minimally and precisely as possible):

kubectl rollout status deployment/my-app

Anything else we need to know?:

Environment:

  • Kubernetes client and server versions (use kubectl version): Version: version.Info{Major:“1”, Minor:“21”, GitVersion:“v1.21.8”, GitCommit:“4a3b558c52eb6995b3c5c1db5e54111bd0645a64”, GitTreeState:“clean”, BuildDate:“2021-12-15T14:46:22Z”, GoVersion:“go1.16.12”, Compiler:“gc”, Platform:“linux/amd64”}
  • OS: NAME=“Ubuntu” VERSION=“20.04.3 LTS (Focal Fossa)” ID=ubuntu ID_LIKE=debian PRETTY_NAME=“Ubuntu 20.04.3 LTS” VERSION_ID=“20.04” HOME_URL=“https://www.ubuntu.com/” SUPPORT_URL=“https://help.ubuntu.com/” BUG_REPORT_URL=“https://bugs.launchpad.net/ubuntu/” PRIVACY_POLICY_URL=“https://www.ubuntu.com/legal/terms-and-policies/privacy-policy” VERSION_CODENAME=focal UBUNTU_CODENAME=focal

About this issue

  • Original URL
  • State: closed
  • Created 2 years ago
  • Reactions: 2
  • Comments: 22 (12 by maintainers)

Most upvoted comments

We are experiencing the same issue. We’re running the a rancher rke cluster, behind a reverse proxy, and the rolluout command only hangs when accessing through the reverse proxy, not while running from “inside”