Kubernetes Configuration Recovery: Retrieving and Cleaning Deployed YAML
This document outlines the technical facts regarding configuration storage in Kubernetes and provides a reliable method for technical leads to retrieve the current, deployed resource configurations, which closely resemble the original YAML files.
1. Kubernetes Does Not Store the Original YAML File Path
When a user executes kubectl apply -f [yaml file], Kubernetes does not record the actual location of the original file. Instead, it only stores the desired state of the resources, as defined in the YAML, within its internal database, etcd.
2. Obtaining the Resource's Current Configuration from the Cluster
While the original YAML file itself cannot be located within the cluster, the cluster holds the complete current configuration of the deployed resource, which is highly similar to the source file.
Steps to Retrieve the Deployed Resource Configuration:
A. Identify the Resource Name, Type, and Namespace
You must first determine the resource's Kind, Name, and its Namespace (if applicable).
| Resource Type |
Command to List Resources |
Notes |
| StorageClass (SC) |
kubectl get sc |
Typically cluster-scoped (no specific Namespace). |
| PersistentVolume (PV) |
kubectl get pv |
Cluster-scoped. |
| PersistentVolumeClaim (PVC) |
kubectl get pvc --all-namespaces |
Use -n <namespace> if the Namespace is known. e.g., for Elasticsearch. |
| Workload (e.g., Elasticsearch) |
kubectl get statefulset --all-namespaces
kubectl get deployment --all-namespaces |
Identify the name (e.g., elasticsearch-master) and its Namespace. (Workloads are usually StatefulSet or Deployment). |
B. Export the Resource's YAML Configuration
Once the resource is identified, use kubectl get with the -o yaml flag to export its current configuration.
| Resource Type |
Example Command |
| StorageClass |
kubectl get sc <sc-name> -o yaml > storageclass-<sc-name>.yaml
(e.g., kubectl get sc netapp-trident-sc -o yaml > netapp-trident-sc.yaml) |
| PersistentVolume (PV) |
kubectl get pv <pv-name> -o yaml > pv-<pv-name>.yaml |
| PersistentVolumeClaim (PVC) |
kubectl get pvc <pvc-name> -n <namespace> -o yaml > pvc-<pvc-name>.yaml |
| Elasticsearch StatefulSet/Deployment |
# Assuming StatefulSet
kubectl get statefulset <es-statefulset-name> -n <namespace> -o yaml > es-statefulset.yaml |
🚨 Critical Note: Cleaning the Exported YAML
The exported YAML files will contain numerous fields automatically added by Kubernetes during runtime. These include: status, creationTimestamp, resourceVersion, uid, and lengthy metadata.annotations (especially kubectl.kubernetes.io/last-applied-configuration).
If a "clean" YAML file is required for subsequent kubectl apply commands or for version control, these system-generated fields must be manually removed or stripped.
- Priority Fields to Delete (Top-Level):
status, metadata.creationTimestamp, metadata.resourceVersion, metadata.uid, metadata.selfLink (if present), and often metadata.generation.
- For Deployment/StatefulSet, review and clean any unnecessary auto-generated annotations and labels within
spec.template.metadata.
C. Using the last-applied-configuration Annotation (If Applicable)
If the initial kubectl apply command was executed without the --save-config=false flag, Kubernetes stores a copy of the successfully applied YAML content in a metadata.annotations field called kubectl.kubernetes.io/last-applied-configuration.
This configuration is typically closer to the original YAML (e.g., it lacks the status block) than the full kubectl get -o yaml output.
You can retrieve this clean configuration using tools like jq or yq:
# Retrieve for a StatefulSet, outputting JSON and piping to jq
kubectl get statefulset <es-statefulset-name> -n <namespace> -o jsonpath='{.metadata.annotations."kubectl\.kubernetes\.io/last-applied-configuration"}' | jq . > clean-es-statefulset.json
# Alternative: Retrieve for a StatefulSet, using yq to output clean YAML (requires yq)
# kubectl get statefulset <es-statefulset-name> -n <namespace> -o yaml | yq '.metadata.annotations."kubectl\.kubernetes\.io/last-applied-configuration"' -r | yq -P > clean-es-statefulset.yaml
Summary for Technical Management
The most robust method to reconstruct the configuration is:
- Use
kubectl get <resource_type> -n <namespace> -o yaml to export the resource.
- Manually clean or use scripting tools to strip the exported YAML of status and system-generated metadata, rendering it a re-applyable configuration file.
Concurrently, the new administration must establish a mandatory process to store all future configuration files in a version control system (e.g., Git) and document the file location corresponding to each deployed resource, preventing recurrence of this "missing file" issue.
.jpg)
