You are ready to deploy a new feature of a web-based application to production. You want to use Google Kubernetes Engine (GKE) to perform a phased rollout to half of the web server pods. What should you do?
A.
Use a partitioned rolling update.
B.
Use Node taints with NoExecute.
C.
Use a replica set in the deployment specification.
D.
Use a stateful set with parallel pod management policy.
A partitioned rolling update allows you to control the percentage of pods that are updated at a time, which allows you to perform a phased rollout. This way you can incrementally test and monitor the new feature, before it is deployed to all the pods. This approach is useful when you want to minimize the risk of introducing new bugs or breaking changes in your production environment, it allows you to have more control over the process, and it's less likely to cause service disruption, or to have all the pods down at the same time.
B. Using Node taints with NoExecute could be used to prevent pods from being scheduled on certain nodes, but it would not be the best option for a phased rollout as it does not allow for a specific percentage or number of pods to be updated.
C. A replica set in the deployment specification is used for ensuring that a specified number of replicas of a pod are running at any given time, but it does not provide a way to perform a phased rollout.
D. A stateful set with parallel pod management policy is used for managing stateful applications, but it also does not provide a way to perform a phased rollout.
The option A, Using a partitioned rolling update, allows you to specify the percentage of pods that should be updated at a time, so it is the best option for performing a phased rollout.
A is right https://cloud.google.com/kubernetes-engine/docs/concepts/statefulset#partitioning_rolling_updates
Partitioning is useful if you want to stage an update, roll out a canary, or perform a phased roll out.
When you partition an update, all Pods with an ordinal greater than or equal to the partition value are updated when you update the StatefulSet’s Pod specification. Pods with an ordinal less than the partition value are not updated and, even if they are deleted, are recreated using the previous version of the specification. If the partition value is greater than the number of replicas, the updates are not propagated to the Pods.
A is the answer.
https://cloud.google.com/kubernetes-engine/docs/how-to/updating-apps#partitioning_a_rollingupdate
Partitioning is useful if you want to stage an update, roll out a canary, or perform a phased roll out.
IMHO, the question mentioned: a "PHASED ROLLOUT" to "HALF" of the web server pods.
So we use .spec.updateStrategy field to partition a RollingUpdate for the Pods in a StatefulSet.
https://cloud.google.com/kubernetes-engine/docs/how-to/updating-apps#partitioning_a_rollingupdate
partition rollout only works if the workload is stateful. Nothing in the question tells us this.
A voting comment increases the vote count for the chosen answer by one.
Upvoting a comment with a selected answer will also increase the vote count towards that answer by one.
So if you see a comment that you already agree with, you can upvote it instead of posting a new comment.
TNT87
Highly Voted 2 years, 6 months agojomonkp
Most Recent 4 months, 4 weeks agoJonathanSJ
1 year, 3 months agoJonathanSJ
1 year, 3 months agoWhyIronMan
1 year, 4 months agoAzureDP900
1 year, 6 months agozellck
1 year, 6 months agoramzez4815
1 year, 7 months agoSekierer
2 years, 3 months agohelg
2 years, 3 months agopaul223344
2 years agobob_builder
2 years, 4 months agonot_thanos
2 years, 4 months agoShasha1
2 years, 5 months ago