如何全局修改Kubernetes的revisionHistoryLimit默认值至2或3？

Great question—tweaking each Deployment individually is such a hassle when you’re trying to save storage space across your cluster. Let’s break down your options, since Kubernetes doesn’t have a built-in global switch to change the default revisionHistoryLimit (hardcoded to 10 in the Deployment controller) directly.

1. Batch Update All Existing Deployments #

First, let’s fix your current Deployments in one shot with a kubectl command. This will set revisionHistoryLimit to 2 (swap to 3 if that’s your preference) for every Deployment across all namespaces:

kubectl get deployments --all-namespaces -o name | xargs -I {} kubectl patch {} -p '{"spec":{"revisionHistoryLimit":2}}'

If you only want to target a specific namespace, remove --all-namespaces and add -n your-target-namespace to the kubectl get command.

2. Use a Mutating Admission Webhook for New Deployments #

To ensure every new Deployment automatically gets your desired limit, a Mutating Admission Webhook is the most scalable solution. This component intercepts Deployment creation/update requests and injects the revisionHistoryLimit field before the resource is saved to the cluster:

• You can build a simple webhook service (using Go, Python, etc.) that checks if the field is missing and sets it to 2/3.
• Alternatively, use Kustomize to package and deploy a pre-built webhook, or leverage operators that handle default configuration injection.

Once the webhook is active, any new Deployment (even those deployed via Helm or other tools) will inherit the limit without manual edits.

3. Standardize with Kustomize or Helm #

If you manage deployments using Kustomize or Helm, bake the revisionHistoryLimit into your base templates to ensure consistency:

• Helm: Add a variable to your values.yaml like revisionHistoryLimit: 2, then reference it in your Deployment template:

  spec:
    revisionHistoryLimit: {{ .Values.revisionHistoryLimit }}
    # Rest of your Deployment spec
  

• Kustomize: Use a patch to apply the setting across all your Deployment resources, or define it in a base Deployment that all overlays inherit from.

Key Note #

Kubernetes doesn’t expose a global configuration flag to change the default revisionHistoryLimit—the 10 value is hardcoded in the Deployment controller logic. The methods above are the most reliable ways to enforce your desired limit across all existing and future Deployments.

内容的提问来源于stack exchange，提问作者Michael Dostál