Rolling Deployment

A rolling deployment updates a service gradually by replacing old instances with new ones in small groups. At any moment during the rollout, some instances run the old version and some run the new one, and the load balancer sends traffic to whichever are healthy.

Why it matters

Rolling updates avoid the downtime of stopping everything and the double infrastructure cost of a full parallel environment. If the new version fails its health checks, the rollout can pause with most capacity still on the old version.

The catch is that two versions serve traffic at once. Database schemas, API contracts and cached data must work with both, which usually means making changes in backward-compatible steps.

Example

Kubernetes Deployments use rolling updates by default. These settings allow one extra pod and no lost capacity during the rollout:

spec:
  replicas: 4
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 0

Kubernetes waits for each new pod's readiness probe to pass before removing an old one. kubectl rollout status deployment/web shows progress and kubectl rollout undo deployment/web reverts.

Common mistakes

• Skipping readiness checks, so unready instances receive traffic mid-rollout.
• Shipping a breaking schema change in the same release as the code that needs it.
• Setting maxUnavailable too high and losing capacity during peak traffic.

Related

• Blue-green deployment
• Canary release
• Readiness probe
• Rollback

यह पेज सामान्य जानकारी है, जिसे हमारी संपादकीय टीम ने लिखा है और दस्तावेज़ीकरण बदलने पर अपडेट किया जाता है। सर्वर और प्रदाता अलग-अलग होते हैं, इसलिए बदलाव पहले सुरक्षित तरीके से जाँचें। देखें: संपादकीय नीति और अस्वीकरण.