Kubernetes Ingress Controller Keeps Crashing – Real Fix

You're not alone – this is frustrating

I've seen this at least six times this year across EKS, GKE, and bare-metal clusters. The ingress controller goes into CrashLoopBackOff and your whole app goes dark. Let's get it back up.

The quick fix – check your liveness probe

In 80% of cases, it's the liveness probe failing. Kubernetes restarts the pod because it thinks the controller is dead. The probe is too strict for the startup time.

Here's a real example from a client last month: they were using the default nginx-ingress controller with spec.livenessProbe.httpGet.path: /healthz. The controller took 30 seconds to start because it was loading certs from an S3 bucket. Kubernetes killed it after 3 seconds. So it kept restarting forever.

Fix the liveness probe

Edit your ingress controller deployment or daemonset (whichever you're using). Look for the livenessProbe block. Change the initialDelaySeconds to match your actual startup time. I set mine to 60 seconds for production clusters. Also increase failureThreshold to 5.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-ingress-controller
spec:
  template:
    spec:
      containers:
      - name: nginx-ingress-controller
        livenessProbe:
          httpGet:
            path: /healthz
            port: 10254
          initialDelaySeconds: 60
          periodSeconds: 10
          failureThreshold: 5
        readinessProbe:
          httpGet:
            path: /healthz
            port: 10254
          initialDelaySeconds: 60
          periodSeconds: 10
          failureThreshold: 3

Apply the change: kubectl apply -f deployment.yaml. Wait a minute. Check the pod status – it should stay Running this time.

Why this works

The liveness probe is a health check that runs on a schedule. If it fails X times, Kubernetes kills the pod and recreates it. But the ingress controller needs time to initialize: load config, connect to the API server, maybe sync certs. If the probe triggers before it's ready, it's a false positive. Then the new pod gets killed too, creating the crash loop.

The initialDelaySeconds tells Kubernetes to wait that many seconds before running the check for the first time. So the controller has a chance to fully start. The failureThreshold gives it more tolerance if there's a temporary hiccup.

Less common variations

1. Resource limits too low

The ingress controller runs out of memory. Kubernetes OOM kills it, restarts it, OOM kills it again. Check the pod logs for OOMKilled. Fix: increase memory limits. For nginx ingress, I set limits.memory: 512Mi minimum, often 1Gi in busy clusters.

resources:
  requests:
    memory: 256Mi
    cpu: 500m
  limits:
    memory: 1Gi
    cpu: 2

2. CNI plugin conflict

Had a client on AWS EKS using Calico. The ingress controller pod couldn't get a network IP. Kubernetes kept reporting FailedCreatePodSandBox. The crash was actually the pod failing to schedule. The fix: reboot the node or update the CNI config. Delete the pod and let it reschedule on a different node.

Command: kubectl delete pod -n ingress-nginx -l app.kubernetes.io/name=ingress-nginx

3. Configmap syntax error

The ingress controller reads a ConfigMap for settings like proxy-body-size, SSL protocols, etc. If you make a syntax mistake there, the controller fails to parse it and crashes. Check the controller logs – they'll say something like error parsing configmap. The fix: revert the ConfigMap change and apply a corrected version.

4. API server connectivity issue

If the ingress controller can't talk to the Kubernetes API server, it crashes. This happens if the service account token is missing or the RBAC permissions are wrong. Check logs for unable to connect to API server. Fix: verify the service account and clusterrole bindings.

kubectl get clusterrolebinding ingress-nginx -o yaml
kubectl get serviceaccount -n ingress-nginx ingress-nginx

Prevention tips

• Always set realistic initialDelaySeconds based on your cluster's startup speed. Test it once.
• Monitor resource usage with Prometheus or a simple kubectl top pods to catch memory leaks early.
• Use readinessProbe alongside livenessProbe. Readiness only affects traffic routing, not pod restart.
• Back up your ConfigMap and test changes in a staging cluster first.
• Keep the ingress controller version in sync with your Kubernetes version. Mismatched versions cause weird crashes.

If you're still stuck after trying all this, check the exact logs with kubectl logs -n ingress-nginx --previous. That shows the last crash's output. Most of the time you'll see the real error there – not a crash loop symptom.

Real talk: I spent three hours once chasing a ghost because I didn't look at the --previous flag. Don't be me.