Workload management in Kubernetes covers how you organize, deploy, update, scale, and maintain your applications. After you deploy an application and expose it through a Service, you need strategies for keeping it running reliably: updating to new versions without disrupting users, scaling to meet changing demand, and recovering from failures. This page explains the key concepts and strategies behind these activities, and links to task pages for step-by-step procedures.
Most applications require multiple Kubernetes resources working together. A typical web application might need a Deployment, a Service, a ConfigMap, a PersistentVolumeClaim, and a Gateway (using the Gateway API add-on). Organizing these resources effectively makes your applications easier to deploy, update, and troubleshoot.
Kubernetes supports several approaches to resource organization:
---. You can define resources in any order.For details on kubectl commands that support these approaches, see
Command line tool (kubectl).
Several tools extend Kubernetes object management beyond what kubectl
provides natively.
Helm is a tool for managing packages of pre-configured Kubernetes resources. These packages are known as Helm charts.
Kustomize traverses a Kubernetes manifest to add,
remove, or update configuration options. It is available both as a standalone
binary and as a
native feature of
kubectl.
When you release a new version of your application, how Kubernetes transitions from the old version to the new one determines whether users experience downtime and how much risk the update carries. Kubernetes supports several update strategies, each suited to different scenarios.
A rolling update gradually replaces old Pods with new ones. At any point during the update, a mix of old and new Pods serves traffic, so the application remains available throughout. This is the default strategy for Deployments.
Two parameters control the pace of a rolling update:
maxUnavailable: the maximum number of Pods that can be unavailable
during the update (default: 25%).maxSurge: the maximum number of extra Pods that can exist above the
desired count during the update (default: 25%).Rolling updates also support pausing and resuming, which allows you to inspect a partial update or batch multiple changes into a single rollout. If a new version introduces problems, you can roll back to a previous revision.
For step-by-step instructions, see Update a Deployment Without Downtime. For configuration details, see the Deployment concept page.
The Recreate strategy terminates all existing Pods before creating new ones. This causes a brief period of downtime but ensures that only one version of the application runs at a time.
Use the Recreate strategy when:
For details, see the Deployment strategy documentation.
You can also apply a Recreate strategy for a StatefulSet. Because these workloads (or workload components) very often do manage some durable state, you need to add your own mechanism to ensure that the application remains durable even if you replace all of the Pods.
A canary deployment runs a new version of your application alongside the existing stable version, routing only a small fraction of traffic to the new version. This allows you to monitor the new version under real production conditions before committing to a full rollout.
The canary pattern in Kubernetes uses labels to differentiate between stable
and canary Pods. Both Deployments share a common label (for example,
app: my-app) that allows a single Service to route traffic to both sets
of Pods. A track label (stable or canary) distinguishes the two
releases. By adjusting the replica counts, you control the traffic ratio
between stable and canary Pods.
For a hands-on walkthrough, see Deploy a Release Using a Canary Deployment.
If you want to use canarying with a StatefulSet, you will typically need to add your own mechanism to do that. One detail that's relevant is that a StatefulSet doesn't have to have an ordinal (Pod number) that starts at zero. For example, you have have a main StatefulSet with starting ordinal zero and 7 replicas (pod number 0 to pod number 6), and a canary StatefulSet with starting ordinal 7 (pod number 7). By managing how much traffic or work the canary Pod picks up, you can gradually increase your confidence that the new code or configuration is correct.
Fully developing this pattern for a stateful app is outside the scope of core Kubernetes.
| Strategy | Downtime | Risk level | Best for |
|---|---|---|---|
| Rolling update | None | Low — gradual rollout | Most workloads |
| Recreate | Yes | Low — clean switchover | Incompatible versions |
| Canary | None | Lowest — small traffic percentage | High-risk changes requiring production validation |
Scaling adjusts the number of Pod replicas running your application to match demand. Kubernetes supports two approaches:
replicas field
manually. The HPA continuously reconciles the replica count and overrides
any manual changes.For step-by-step instructions on manual scaling, see Scale a Deployment Manually. For automatic scaling, see the HorizontalPodAutoscaler walkthrough.
After deploying resources, you often need to make changes without replacing the entire object. Kubernetes provides several approaches for in-place updates, each suited to different workflows:
kubectl apply): compares your configuration
file against the live state and applies only the differences. This approach
works well when you maintain configuration as code in source control. For
details, see
server-side apply.kubectl edit): opens the live resource in a text
editor, allowing you to make changes directly. Useful for one-off
adjustments or exploration.kubectl patch): updates specific fields using JSON
patch, JSON merge patch, or strategic merge patch. Best for scripted or
automated changes. For details, see
Update API Objects in Place Using kubectl patch.Some resource fields are immutable after creation (for example, a Pod's
container name or a Service's clusterIP). When you need to change an
immutable field, you must delete and recreate the resource. The
kubectl replace --force command performs this operation in a single step.
As a cluster administrator, you can set guardrails that influence how application teams manage their workloads:
Items on this page refer to third party products or projects that provide functionality required by Kubernetes. The Kubernetes project authors aren't responsible for those third-party products or projects. See the CNCF website guidelines for more details.
You should read the content guide before proposing a change that adds an extra third-party link.