## 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 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 kubectl logs -n ingress-nginx --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 If you see "class nginx not found", restore the Ingress Class from your backup. ### Manual Recovery Steps - Restore the Ingress Class from backup: kubectl apply -f ingressclass-backup.yaml - Verify it exists: kubectl get ingressclass - 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 --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 .yaml - [ ] Verify the resource is updated: kubectl describe ingressclass - [ ] 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 --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.