:_mod-docs-content-type: ASSEMBLY
[id="nodes-nodes-rebooting"]
= Understanding node rebooting
include::_attributes/common-attributes.adoc[]
:context: nodes-nodes-rebooting

toc::[]


[role="_abstract"]
Review the following information to learn about rebooting a node without causing an outage for applications running on the
platform by first evacuating the pods on the node. 

For pods that are made highly available by the routing tier, nothing
else needs to be done. For other pods needing storage, typically databases, it
is critical to ensure that they can remain in operation with one pod
temporarily going offline. While implementing resiliency for stateful pods
is different for each application, in all cases it is important to configure
the scheduler to use node anti-affinity to
ensure that the pods are properly spread across available nodes.

Another challenge is how to handle nodes that are running critical
infrastructure such as the router or the registry. The same node evacuation
process applies, though it is important to understand certain edge cases.

// The following include statements pull in the module files that comprise
// the assembly. Include any combination of concept, procedure, or reference
// modules required to cover the user story. You can also include other
// assemblies.

include::modules/nodes-nodes-rebooting-infrastructure.adoc[leveloffset=+1]

include::modules/nodes-nodes-rebooting-affinity.adoc[leveloffset=+1]

include::modules/nodes-nodes-rebooting-router.adoc[leveloffset=+1]

include::modules/nodes-nodes-rebooting-gracefully.adoc[leveloffset=+1]

[role="_additional-resources"]
[id="additional-resources_{context}"]
== Additional resources

* xref:../../nodes/scheduling/nodes-scheduler-pod-affinity.adoc#nodes-scheduler-pod-affinity[Placing pods relative to other pods using affinity and anti-affinity rules]
* xref:../../backup_and_restore/control_plane_backup_and_restore/backing-up-etcd.adoc#backup-etcd[Backing up etcd data]
