Why Leaving Pods in CrashLoopBackOff Can Have a Bigger Impact Than You Might Think

How CrashLoopBackOff works

High volumes of container restarts may eventually cause other new containers on the Node to not start

shim: OCI runtime create failed: container_linux.go:380: starting container process caused: process_linux.go:385: applying cgroup configuration for process caused: mkdir /sys/fs/cgroup/memory/kubepods/burstable/pod0f8fe7dd-87bf-4f13-9e17-b12c41c46418/0a55234bf4c2b1785bdaefb63227b606d71eb6025a44de34e16db87032f77950: cannot allocate memory: unknown

Repeatedly restarting containers may cause unnecessarily high Node resource usage

This example container (It just happens to be Spring Boot) demonstrates a pretty common scenario — where startup processing uses significantly more CPU to start than is used to subsequently run

If the container doesn’t reach a ready state, your rollout may not complete

Containers that are constantly restarting aren’t doing real work

The takeaway



Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Paul Dally

Paul Dally

Distinguished Architect at Sun Life Financial. Focused on containers & Kubernetes. Views & opinions expressed here are my own, not necessarily those of Sun Life