Kubernetes Operator: pod and service failures, handled safely

Kubernetes Operator is 2501's specialty for failing pods and services on Kubernetes and OpenShift: it finds out why a workload failed, restarts it only when that will help, and hands everything else to your on-call engineer with the evidence.

A pod keeps restarting or a service stops answering, and someone has to work out whether it is a passing glitch, a resource limit, a missing image or a bug in the code. Restarting first is tempting, and it can wipe the logs that explain the failure.

What 2501 does

The Kubernetes specialty takes these alerts from your ticketing system and investigates before it acts, keeping the evidence a restart would erase. It works out whether the failure comes from the application, a temporary problem, a resource limit or the cluster itself. It restarts a workload only when the cause is temporary, such as stale state or a brief network or node problem, and stops after a few attempts rather than looping. Anything else it reports, with the cause, a timeline and the change it recommends, for a person to make.

You stay in control

• You choose the level, per specialty: investigate only, act after a person confirms, or act on its own within your rules.
• A restart is its only action: it can read the cluster and restart pods, and nothing more.
• Your rules apply: which namespaces are in scope and which workloads always need a person, and destructive commands can be blacklisted outright.
• On-prem, cloud or hybrid: 2501 runs wherever you do. On-prem, no data leaves your network.

Frequently asked

Will it restart every failing pod? No. When the cause is in the code, the configuration or a resource limit, a restart would only hide it, so it reports instead.

Does it work on OpenShift? Yes. It covers Kubernetes and OpenShift environments.

Related

• Pod stuck in CrashLoopBackOff after being OOMKilled
• Services Manager for services and containers