Questão de Container Orchestration #019e3a4f

The default deployment strategy in Kubernetes is the Rolling Update strategy. This strategy ensures that pods are gradually replaced with new ones, minimizing downtime and maintaining application availability during updates.

How it Works

When a Deployment is updated (e.g., a new container image version), Kubernetes creates a new ReplicaSet and gradually scales it up while scaling down the old ReplicaSet. The maxSurge and maxUnavailable parameters control the pace of the update. By default, maxSurge is 25% (allows up to 25% extra pods above the desired count) and maxUnavailable is 25% (allows up to 25% of pods to be unavailable during the update). This rolling behavior is defined in the Deployment's spec.strategy.type field, which defaults to RollingUpdate.

Why the Correct Value is Right

The Rolling Update strategy is the default because it provides a balance between speed and safety. It updates pods incrementally, ensuring that a certain number of pods remain available to serve traffic. This is suitable for most applications that require zero-downtime deployments.

Why the Incorrect Values are Wrong

• Blue/Green deployment: This strategy involves running two identical environments (blue and green) and switching traffic all at once. It is not the default; it requires manual setup or additional tooling (e.g., using Services with label selectors).
• Canary deployment: This strategy releases a new version to a small subset of users before rolling out to all. It is not built-in as a default strategy; it requires custom configurations or service mesh features.
• Recreate deployment: This strategy terminates all old pods before creating new ones. It is not the default because it causes downtime. It can be set explicitly by changing spec.strategy.type to Recreate.

In summary, Kubernetes defaults to Rolling Update to provide a safe, gradual update process with minimal disruption.