In this post, we will be learning about a few general, but important, configuration best practices in Kubernetes.
Use Latest Stable API version
👉 Always specify the latest stable API version when defining the configurations.
👉 This will ensure reliability and avoid any issues when K8s deprecates (and finally removes) older API versions.
Use Version control system
👉 Configuration files should always be stored in the version control before it is getting applied to the cluster.
👉 A pipeline can be created (or use existing tools like ArgoCD) to pull the configuration from version control solution (such as github, gitlab etc) and apply the configurations to the cluster.
👉 This allows to quickly roll back, if required.
👉 It is also helpful in cluster re-creation and restoration.
Use YAML (not JSON)
👉 Use YAML for all your configuration files rather than JSON as it is more user-friendly
👉 One of the reasons I find to use YAML, it is very easy to figure out the changes done in the configuration file while reviewing them as compared to a JSON file(especially when it is not formatted properly)
Use single file for similar objects
👉 Rather than using multiple files for each k8s objects/configurations, it’s a good idea to keep them in a single file.
👉 It will be easier to manage and make changes in multiple configurations together.
👉 Also, we would be referring many objects in many manifests file, having a single file reduce the chances of errors (such as typos) and easier to review. (For eg: Using secrets in deployments)
Keep it Minimal
👉 Keeping the manifest files as minimal as possible to increase the readability and understandability
👉 Don’t specify default values unnecessarily. (For eg: RollingUpdate is the default strategy in K8s deployments and shouldn’t be specified explicitly)
Use annotations
👉 Make use of annotations to put the object descriptions, owners, teams etc to easily identify the details about the objects
👉 It would allow us to better introspection and provides a better visibility across teams and clusters.
Don’t use Naked Pods
👉 Naked pods (not bounded to a deployment or replicaset) will not be rescheduled in the event of a node failure.
Use the Kubernetes common labels
👉 These standardized labels enrich the metadata in a way that allows tools, including kubectl and dashboard, to work in an interoperable way.
References
🔗 Configuration Best Practices (Kubernetes official documentation)
