Merge pull request #47461 from bergerhoffer/BZ-2099319

BZ-2099319: Adding option to perform rolling node restart

Author: bergerhoffer

authentication/bound-service-account-tokens.adoc

@@ -14,4 +14,9 @@ include::modules/bound-sa-tokens-about.adoc[leveloffset=+1]
 // Configuring bound service account tokens using volume projection
 include::modules/bound-sa-tokens-configuring.adoc[leveloffset=+1]
 
+[role="_additional-resources"]
+.Additional resources
+
+* xref:../nodes/nodes/nodes-nodes-rebooting.adoc#nodes-nodes-rebooting-gracefully_nodes-nodes-rebooting[Rebooting a node gracefully]
+
 // TODO: Verify distros: openshift-enterprise,openshift-webscale,openshift-origin

modules/bound-sa-tokens-configuring.adoc

@@ -23,7 +23,7 @@ This step is typically not required if the bound tokens are used only within the
 ====
 If you change the service account issuer to a custom one, the previous service account issuer is still trusted for the next 24 hours.
 
-If necessary, you can manually restart all pods in the cluster so that the holder will request a new bound token. Before doing this, wait for a new revision of the Kubernetes API server pods to roll out with your service account issuer changes.
+You can force all holders to request a new bound token either by manually restarting all pods in the cluster or by performing a rolling node restart. Before performing either action, wait for a new revision of the Kubernetes API server pods to roll out with your service account issuer changes.
 ====
 
 .. Edit the `cluster` `Authentication` object:
@@ -44,9 +44,7 @@ spec:
 
 .. Save the file to apply the changes.
 
-.. Optional: Manually restart all pods in the cluster so that the holder will request a new bound token.
-
-... Wait for a new revision of the Kubernetes API server pods to roll out. It can take several minutes for all nodes to update to the new revision. Run the following command:
+.. Wait for a new revision of the Kubernetes API server pods to roll out. It can take several minutes for all nodes to update to the new revision. Run the following command:
 +
 [source,terminal]
 ----
@@ -67,13 +65,26 @@ If the output shows a message similar to one of the following messages, the upda
 ** `3 nodes are at revision 11; 0 nodes have achieved new revision 12`
 ** `2 nodes are at revision 11; 1 nodes are at revision 12`
 
-... Manually restart all pods in the cluster:
+.. Optional: Force the holder to request a new bound token either by performing a rolling node restart or by manually restarting all pods in the cluster.
+
+*** Perform a rolling node restart:
++
+[WARNING]
+====
+It is not recommended to perform a rolling node restart if you have custom workloads running on your cluster, because it can cause a service interruption. Instead, manually restart all pods in the cluster.
+====
++
+Restart nodes sequentially. Wait for the node to become fully available before restarting the next node. See _Rebooting a node gracefully_ for instructions on how to drain, restart, and mark a node as schedulable again.
+
+*** Manually restart all pods in the cluster:
 +
 [WARNING]
 ====
 Be aware that running this command causes a service interruption, because it deletes every running pod in every namespace. These pods will automatically restart after they are deleted.
 ====
 +
+Run the following command:
++
 [source,terminal]
 ----
 $ for I in $(oc get ns -o jsonpath='{range .items[*]} {.metadata.name}{"\n"} {end}'); \