This example demonstrates how to protect Sandboxes from voluntary disruptions (e.g., node drains, cluster upgrades) using standard Kubernetes manifests, without relying on the controller's automated disruption control.
In this manual workflow, you create a single Shared PDB per namespace. This PDB acts as a "security blanket" that protects all Sandboxes in that namespace, provided they opt-in via labels.
Protection is not automatic. A Sandbox is only protected if its Template metadata matches the PDB selector exactly.
- PDB Selector:
matchLabels: { sandbox-disruption-policy: "manual-protection" } - Sandbox Template: Must have
labels: { sandbox-disruption-policy: "manual-protection" }
Any Sandbox created in this namespace without this specific label will be ignored by the PDB and can be evicted at any time.
Because multiple Sandboxes share one PDB, we use maxUnavailable: 0.
- Scenario: You have 3 Sandboxes running in the
dev-teamnamespace. - Logic:
maxUnavailable: 0tells Kubernetes: "You cannot voluntarily evict any pod that has this label." - Result: All 3 Sandboxes are protected individually.
Warning: Do not use minAvailable: 1 for a shared PDB. If you have 3 sandboxes and require only 1 to be available, Kubernetes is allowed to evict the other 2 during maintenance.
The template includes the required labels and the safe-to-evict annotation.
kubectl apply -f sandboxtemplate.yaml -n defaultThe WarmPool references the template, with the desired number of sandboxes set to 2.
kubectl apply -f sandboxwarmpool.yaml -n defaultYou must apply the PDB manifest to every namespace where you intend to run Sandboxes.
# Example for the 'default' namespace
kubectl apply -f shared-pdb.yaml -n defaultYou can now create as many Claims as you want in that namespace.
# Example for the 'default' namespace
kubectl apply -f sandboxclaim.yaml -n defaultUnlike the automated controller implementation, manual PDBs do not clean themselves up.
-
When you delete a Sandbox: The PDB remains active in the namespace.
-
When you delete the last Sandbox: You must manually delete the PDB if you want to remove the configuration.
-
Risk: If you delete the PDB while other Sandboxes are still running in that namespace, those Sandboxes immediately lose protection. Coordinate with your team before deleting the shared PDB.