A Deployment named 'myapp' is managing a ReplicaSet. You need to update the application image to version 2.0. What is the recommended approach?
Updating the Deployment triggers a rolling update, ensuring zero-downtime and rollback capability.
Why this answer
Option B is correct because the recommended approach to update a Deployment's application image is to modify the pod template in the Deployment specification. The Deployment controller then automatically performs a rolling update, creating a new ReplicaSet with the updated image and gradually scaling down the old ReplicaSet, ensuring zero-downtime updates and maintaining desired replica count.
Exam trap
CNCF often tests the misconception that you must directly manipulate ReplicaSets or pods to update an application, when in fact the Deployment abstraction is designed to handle all updates through its pod template, and any direct changes to underlying resources are either reverted or break the declarative model.
How to eliminate wrong answers
Option A is wrong because scaling down to 0 replicas and then scaling up with a new image causes an unnecessary service disruption and does not leverage the Deployment's built-in rolling update mechanism, which is designed for seamless updates. Option C is wrong because manually deleting the existing ReplicaSet and creating a new one bypasses the Deployment controller's management, losing revision history and the ability to roll back; the Deployment should manage ReplicaSets automatically. Option D is wrong because directly editing pods in a ReplicaSet is ineffective, as the ReplicaSet controller will immediately revert any changes to match its pod template, and this approach does not update the Deployment's desired state.