I've been doing "devops" stuff for a long time, but only got into Kubernetes in the last 18 months or so. I've been endlessly frustrated by how prevalent "just

I've been doing "devops" stuff for a long time, but only got into Kubernetes in the last 18 months or so. I've been endlessly frustrated by how prevalent "just add a <x> second sleep" is in the Kubernetes world. Examples: If you're using IRSA to provide pods an AWS IAM Role, it can take some time on first-run for the role to become usable. So your app has to just wait until it can successfully talk to AWS. If you're using the AWS Elastic Load Balancer controller, you need to add sleeps during pre-stop for a pod. The controller has to see the shutdown event, then start target deregistration on the ELB Target Group. That's a minimum of 30 seconds, during which you can be getting new connections. Service meshes on Kubernetes add some fun on both startup AND shutdown. Linkerd, for instance, will only inject it's linkerd-proxy container into your pod after startup. So it's entirely possible for your main application container to start, begin talking to the world and then a moment later all your connections get reset when Linkerd-proxy takes over the pod's networking configuration. You can fix this by injecting into all of your containers a linkerd-await utility that replaces the container entrypoint. It will wait until linkerd starts before starting your regular entrypoint. It's basically a more advanced version of sleep. Shutdown is just as fun - linkerd-proxy will immediately terminate, dropping all network connectivity for all the containers in your pod. There's a fix for this, too, which involves the above linkerd-await and another option.