On Syself Autopilot, nodes are replaced constantly. Every Kubernetes upgrade drains and replaces each worker one at a time, and self-healing does the same to any node that becomes unhealthy. Your workloads keep running throughout, but no pod is guaranteed to stay on the node it started on.

So make sure every workload has more than one replica, health probes, resource requests, a PodDisruptionBudget, and a tight spread rule. Get that baseline right and the churn is invisible to your users.

Everything else on this tab assumes you have that in place. So start there.

Start with the production baseline

Whatever you plan to run, begin at Run a production-ready workload . It wires every drain-survival setting into a single working example, so you can see how the pieces fit before you split them apart.

The rest of that sub-topic then takes each setting on its own, one page at a time: health probes so the platform knows when a pod is really ready, resource requests and limits so the scheduler can place it and the kubelet can protect it, PodDisruptionBudgets so a drain can never take down more replicas than you allow, and graceful shutdown so a pod finishes its in-flight work before it goes. Read the example first; use the individual pages when you want the reasoning.

What you inherit for free

Part of the safety net is already strung for you. You get these without writing a line of configuration:

• A best-effort spread of your pods across nodes and cloud zones, applied even to pods that carry no spread rule of their own. It never blocks scheduling, so it costs you no capacity, but it is deliberately loose, and a workload that must survive a single node loss still needs a tighter rule you set yourself.
• Namespace guardrails that take effect the instant you set them, because LimitRanger and ResourceQuota admission are already wired in. Define a quota and it is enforced on the next pod, with nothing to install.
• NUMA-aligned placement on bare-metal nodes for pods that qualify, so memory-bound and latency-sensitive workloads sit close to the CPUs serving them, when the topology fits.
• A GPU stack that ships with the hardware. On supported cards the driver, CDI, and device plugin arrive with the node. You schedule against the GPU, not against a driver install.

Where to go next

• Placement and scheduling
• Scaling
• Stateful workloads
• Batch and jobs
• Specialized workloads
• Secure workloads
• Configuration and delivery

One boundary worth drawing before you start. This tab is about running the workload and isolating it at the workload level: security contexts, user namespaces, and secure runtimes all live here, under Secure workloads . The cluster's wider posture lives in the Security tab: network policy, Pod Security enforcement, admission control, and the zero-trust model.