Pregunta de Service Configuration #019e3a4f

Summary

In Kubernetes, the RollingUpdate deployment strategy is the native approach that supports zero-downtime updates. It gradually replaces old Pods with new ones, ensuring that the application remains available throughout the update process.

How it Works

When a Deployment is configured with strategy.type: RollingUpdate, Kubernetes updates Pods incrementally. It creates new Pods with the updated specification while terminating old ones, maintaining a configurable number of Pods available at all times. The maxUnavailable and maxSurge parameters control the pace of the rollout. By default, maxUnavailable is 25% and maxSurge is 25%, meaning at most 25% of the desired Pods can be unavailable during the update, and up to 25% extra Pods can be created above the desired count. This ensures that the service continues to serve traffic without interruption.

Why RollingUpdate is Correct

• Zero-downtime: The rolling update ensures that a minimum number of Pods are always running, so the service remains available.
• Native Kubernetes: It is the default strategy for Deployments and is fully integrated with Kubernetes controllers and APIs.
• Configurable: Administrators can tune the rollout speed and availability guarantees via maxUnavailable and maxSurge.

Why Other Options are Incorrect

• Canary: While canary deployments can achieve zero-downtime, they are not a native Kubernetes deployment strategy. They require additional tooling (e.g., service mesh, ingress controllers) to route a subset of traffic to the new version. Kubernetes does not provide built-in canary support for Deployments.
• Recreate: This strategy terminates all existing Pods before creating new ones. It causes downtime because the application is unavailable during the transition. It is suitable for development or when downtime is acceptable.
• BlueGreen: Blue-green deployments involve running two identical environments (blue and green) and switching traffic between them. While this can achieve zero-downtime, it is not a native Kubernetes Deployment strategy. It requires external load balancers or service mesh configurations. Kubernetes does not have a built-in BlueGreen strategy for Deployments.

Conclusion

For native zero-downtime updates in Kubernetes, the RollingUpdate strategy is the correct and default choice. It is built into the Deployment resource and provides a reliable, configurable mechanism for updating workloads without service interruption.