top of page

K8s Anti-Design Pattern Series: Manual Kubectl Edit/Patch Deployments - Blog #17

Updated: Apr 12






Introduction


In Kubernetes deployments, configuration dispersion can be a significant issue, especially when two or more identical environments no longer share the same setup due to ad hoc deployments or adjustments. This can lead to reverse-engineering a running instance to determine the machine's original setup, which can be a time-consuming process.





Kubernetes offers a lot of flexibility when it comes to deploying applications using the 'kubectl' tool. This tool has in-built apply, edit, and patch commands that allow developers to modify resources on a running cluster. However, the issue arises when developers abuse this technique by making changes on the fly in the cluster without documenting them outside of it. Such changes can cause issues and are one of the common causes of unsuccessful deployments.


One of the problems with making ad hoc adjustments is that they are usually done for quick fixes or as a temporary measure. These adjustments are never documented, leading to undocumented changes to the cluster. Furthermore, if the configuration of the production environment has changed from that of the testing environment, the deployment will fail in production even though it succeeded in staging.



To avoid these issues, it is strongly recommended that manual distributions not be performed using Kubectl. Instead, the GitOps paradigm suggests that all deployments be managed by the deployment tool and, ideally, documented there. By exclusively using Git commits for deployments, developers can keep track of cluster activity, be fully aware of the precise contents of each cluster, and have a simple way to clone or recreate an entire system.


Git change history provides a comprehensive record of cluster activity, and reading the Git configuration is a simple way to clone or recreate an entire system. Additionally, resetting the cluster to an earlier commit will restore its prior configuration. Most significantly, in the event of a failed deployment, developers can quickly identify the most recent change that affected it and how that change impacted its configuration.



All editing and patching done with kubectl should be considered experimental. Attempting to make manual resource changes to a cluster in production is extremely risky and should be avoided. It's important to have a well-thought-out deployment process, but it's also crucial to concur with your colleagues that this misuse of kubectl is unacceptable.


In summary, manual deployments using the kubectl tool can cause configuration dispersion and lead to undocumented changes and unsuccessful deployments. To avoid these issues, the GitOps paradigm is recommended, where all deployments are managed by a deployment tool and documented in Git commits. By avoiding manual distributions using Kubectl, a well-thought-out deployment process can be maintained.







Continuous Blog Series :

Blog #1 : Kubernetes Design Pattern Series - An Overview

Blog #2 : K8s Design Pattern Series - Fundamental Pattern

Blog #3 : K8s Design Pattern Series - Structural Pattern

Blog #4: K8s Design Pattern Series: Behavioral Patterns

Blog #5: K8s Design Pattern Series: Higher Level Patterns

Blog #6: K8s Design Pattern Series: Summary

Blog #7: K8s Anti-Design Pattern Series

Blog #8: K8s Anti-Design Pattern Series - Putting the Configuration into the Images of the Containers

Blog #9: K8s Anti-Design Pattern Series - Connecting Applications to Kubernetes Features/Services without Justification

Blog #10: K8s Anti-Design Pattern Series - Mixing Infrastructure and Application Deployment

Blog #11: K8s Anti-Design Pattern Series - Deploying without Memory and CPU Limits

Blog #12: K8s Anti-Design Pattern Series - Understanding Health Probes In Kubernetes

Blog #13: K8s Anti-Design Pattern Series - The Pitfall of ignoring Helm in Kubernetes Package Management

Blog #14: K8s Anti-Design Pattern Series - Why Deployment Metrics matter in Kubernetes

Blog #15: K8s Anti-Design Pattern Series - To Kubernetes or not to Kubernetes weighing Pros and Cons

Blog #16:K8s Anti-Design Pattern Series - Connecting Applications to Kubernetes Features/Services

Blog #17: K8s Anti-Design Pattern Series - Manual Kubectl Edit/Patch Deployments

Blog #18: K8s Anti-Design Pattern Series - Kubernetes Deployments with Latest-Tagged Containers

Blog #19: K8s Anti-Design Pattern Series - Kubectl Debugging

Blog #20: K8s Anti-Design Pattern Series - Misunderstanding Kubernetes Network Concepts

Blog #21: K8s Anti-Design Pattern Series - Dynamic Environments in Kubernetes why Fixed Staging is an Anti-Design

Blog #22: K8s Anti-Design Pattern Series - Combining Clusters of Production and Non-Production



5 views0 comments

Recent Posts

See All
bottom of page