Kubernetes Ingress Class Backup and Restore with Practical Examples

Introduction

Kubernetes Ingress Classes control how traffic reaches your services, and losing or misconfiguring them can take down applications in production. This article gives you a practical, version-aware approach to backing up, restoring, and validating Ingress Classes, with commands you can run today.

You'll learn how to take a snapshot of your current Ingress Classes, restore them from a backup, roll back to a known-good state, and verify that everything works as expected. We'll cover the exact commands, expected outputs, common failure modes, and how to recover when something goes wrong.

This guide is written for developers, DevOps engineers, and technical teams who want to manage Ingress Classes safely. The goal is operational safety: observe before changing, limit the blast radius, protect secrets, and verify every result.

Version and Environment Inventory

Before touching anything, understand your environment. The version of Kubernetes and your Ingress controller determines which commands and features are available. For example, the ingressClassName field in the Ingress spec is stable since Kubernetes 1.22, and the networking.k8s.io/v1 API is the current standard.

Check Kubernetes and Controller Versions

Start by identifying your cluster version and the Ingress controller you're using:

kubectl version --short
kubectl get pods -n ingress-nginx -o wide

Expected output for cluster version:

Client Version: v1.29.0
Server Version: v1.29.2

For the controller, you'll see pods like ingress-nginx-controller-xxxx with the image tag showing the version.

Inventory Current Ingress Classes

List all Ingress Classes in the cluster:

kubectl get ingressclass

Sample output:

NAME    CONTROLLER                      PARAMETERS   AGE
nginx   k8s.io/ingress-nginx           <none>       30d

To see details, including annotations and parameters, use:

kubectl describe ingressclass nginx

Capture a Backup

Create a backup of all Ingress Classes in YAML format:

kubectl get ingressclass -o yaml > ingressclass-backup.yaml

Verify the file is not empty and contains the expected data:

wc -l ingressclass-backup.yaml
head -20 ingressclass-backup.yaml

If you use GitOps, commit this file to your repository. For a more robust backup, also export related resources like the Ingress controller deployment, services, and ConfigMaps, because Ingress Classes often depend on them.

Record Timestamps and State

Before making any changes, capture the current time and the exact state of the Ingress Classes:

date -u +"%Y-%m-%dT%H:%M:%SZ"
kubectl get ingressclass -o jsonpath='{range .items[*]}{.metadata.name}{"\t"}{.metadata.creationTimestamp}{"\n"}{end}'

This gives you a clear snapshot to compare against after any changes.

Safe Configuration Path

Now that you have a backup, you can safely make changes. The key is to make one change at a time, test it, and always have a rollback plan.

Create a New Ingress Class

Suppose you want to add a new Ingress Class for a different controller. Create a YAML file:

apiVersion: networking.k8s.io/v1
kind: IngressClass
metadata:
  name: traefik
spec:
  controller: traefik.io/ingress-controller

Apply it:

kubectl apply -f traefik-ingressclass.yaml

Verify it was created:

kubectl get ingressclass traefik

Update an Existing Ingress Class

To change an existing Ingress Class's parameters, edit the object. For example, to add a parameter referencing a ConfigMap for the NGINX controller:

apiVersion: networking.k8s.io/v1
kind: IngressClass
metadata:
  name: nginx
spec:
  controller: k8s.io/ingress-nginx
  parameters:
    apiGroup: k8s.example.com
    kind: IngressParameters
    name: nginx-params

Apply the change:

kubectl apply -f updated-ingressclass.yaml

Always verify the change took effect:

kubectl describe ingressclass nginx | grep -A2 Parameters

Testing with a Minimal Ingress

Create a simple Ingress that uses the Ingress Class and point it to a test service:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: test-ingress
spec:
  ingressClassName: nginx
  rules:
  - host: test.example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: echo
            port:
              number: 80

Apply and verify the Ingress controller picks it up:

kubectl apply -f test-ingress.yaml
kubectl get ingress test-ingress
kubectl logs -n ingress-nginx deployment/ingress-nginx-controller --tail=50 | grep test.example.com

Expected log lines include "Adding or updating ingress" for the host.

Verification and Diagnostics

Verification is not just about checking that resources exist; it's about confirming the system works as intended.

Check Ingress Controller Health

Use these commands to ensure the Ingress controller is running correctly:

kubectl get pods -n ingress-nginx -o wide
kubectl describe pod -n ingress-nginx <pod-name>
kubectl logs -n ingress-nginx <pod-name> --tail=20

Look for "Running" status, recent logs, and no crash loops.

Validate Ingress Resources

List all Ingress resources and check their class:

kubectl get ingress -A
kubectl get ingress -A -o custom-columns=NAME:.metadata.name,CLASS:.spec.ingressClassName

This helps you confirm that every Ingress points to the correct class.

Test Traffic Flow

For a local test, use port-forwarding:

kubectl port-forward service/echo 8080:80

Then, in another terminal, make a request:

curl -H "Host: test.example.com" http://localhost:8080/

You should see a response from the echo service, confirming the Ingress Class and controller work.

Use Diagnostic Commands

When something fails, use kubectl describe and kubectl logs to diagnose. For example, if the Ingress doesn't get an address, check events:

kubectl describe ingress test-ingress

Look for events like "Error on ingress ..." or "Scheduled for sync".

Failure Modes and Recovery

Even with careful planning, things fail. Here are common failure modes and how to recover.

Ingress Class Not Found

If your Ingress references a non-existent class, the controller might ignore it or error. Check the Ingress events:

kubectl describe ingress <name>

If you see "class nginx not found", restore the Ingress Class from your backup.

Manual Recovery Steps

1. Restore the Ingress Class from backup:

kubectl apply -f ingressclass-backup.yaml

1. Verify it exists:

kubectl get ingressclass

1. Re-apply the Ingress if needed:

kubectl replace -f test-ingress.yaml

Rolling Back a Change

If you modified an Ingress Class and it caused issues, roll back to a previous version. Since Ingress Classes are not versioned like ConfigMaps, you must re-apply the backup file. If you use the --server-side flag, you can also use kubectl apply --server-side --force-conflicts to overwrite.

Controller Crash

If the Ingress controller crashes, check its logs:

kubectl logs -n ingress-nginx <pod-name> --previous

If it's a crash loop, roll back to a previous controller version. If you have a GitOps setup, revert the commit that changed the controller.

Operations Checklist

Follow this checklist for every Ingress Class operation.

Before the Change

• [ ] Verify the cluster version: kubectl version --short
• [ ] List current Ingress Classes: kubectl get ingressclass
• [ ] Take a backup: kubectl get ingressclass -o yaml > backup.yaml
• [ ] Save timestamps: date -u +"%Y-%m-%dT%H:%M:%SZ"
• [ ] Identify the blast radius: which services are affected?

During the Change

• [ ] Apply the change: kubectl apply -f <file>.yaml
• [ ] Verify the resource is updated: kubectl describe ingressclass <name>
• [ ] Test with a dummy Ingress: apply a test Ingress and check traffic

After the Change

• [ ] Confirm the Ingress controller is healthy: kubectl get pods -n ingress-nginx
• [ ] Validate that all Ingresses use the correct class: kubectl get ingress -A -o custom-columns=...
• [ ] Update your backup file with the new state: kubectl get ingressclass -o yaml > backup.yaml

If Something Fails

• [ ] Don't panic; assess the error.
• [ ] Restore from backup: kubectl apply -f backup.yaml
• [ ] Check controller logs: kubectl logs -n ingress-nginx <pod> --previous
• [ ] If needed, roll back the controller deployment to a previous version.

Conclusion

Backing up and restoring Kubernetes Ingress Classes is a routine operation that can prevent downtime and data loss. By following a version-aware, observable, and reversible process, you can handle changes with confidence.

The key takeaways are: always inventory your environment, take backups before changes, make small scoped changes, and verify everything with concrete commands. Use the examples in this article as your starting point, and adapt them to your specific controller and version.

As a next step, run a low-risk backup and restore drill in a development cluster. Document the process, and share it with your team. This way, when a production incident occurs, everyone knows exactly what to do.