Lately I have had some discussion about Kubernetes workload and how to manage our environment correctly especially for planned upgrades (notes: this is more in voluntary disruption). One of the most amazing things in Kubernetes in my opinion is the Declarative operation in which we defined the state that we want and let Kubernetes manage it at its best.

So if we want to say I want two replicas of my pods, then it’s the only thing we need to put in our Deployment yaml, combined with LoadBalance and some configuration such as horizontal pod autoscaler (if needed) it will be a great tools to let my workload to be spread around the clusters and let the Kubernetes manage the scheduling to available nodes.

Now this story is not about the best-practice and official guide, just a thought on how we may have some approach to prepare for voluntary disruption which one of the use case is in upgrading the version of our Kubernetes Cluster (in this term I am using GKE) yet we want to have more control in upgrading the cluster.

#poddisruptionbudget #cloud #upgrade #gke #manuals

Day 2 Kubernetes — Pod Disruption Budget for helping manually upgrading GKE Cluster
1.35 GEEK