Deployed 1bf58c6 to upcoming with MkDocs 1.6.1 and mike 2.1.4

Author: tsipinakis

upcoming/reference/kubernetes/index.html

@@ -4695,7 +4695,7 @@ <h3 id="configuration-restrictions">Configuration restrictions<a class="headerli
 <li>In <code>persistent</code> mode with <code>createMissingPods</code> enabled, the <code>idleCommand</code>, <code>shellCommand</code>, and at least one container in the pod spec are required.</li>
 </ul>
 <h3 id="persistent-mode">Persistent mode<a class="headerlink" href="#persistent-mode" title="Permanent link">&para;</a></h3>
-<p>The <code>persistent</code> execution mode allows ContainerSSH to exec into an already running pod rather than creating a new one for each connection or session. This is useful when you have long-lived pods that should be reused across SSH sessions, for example pre-provisioned development environments.</p>
+<p>The <code>persistent</code> execution mode allows ContainerSSH to exec into an already running pod rather than creating a new one for each connection or session. This is useful when you have long-lived pods that should be reused across SSH sessions, this can be used for example, to allow users to execute long-running procesess without the risk that it'll be terminated.</p>
 <div class="admonition warning">
 <p class="admonition-title">ContainerSSH cannot guarantee user isolation in this mode</p>
 <p>It is expeced that the users of this feature will use the configuration server to <strong>ensure that every user is dropped into the correct pod</strong>, ideally unique per-user. Do not specify the pod to use in the global configuration as this will lead to all users to be sent to the same pod without any isolation. If this is combined with any type of credential forwarding it can lead to the compromise of the users credentials.</p>