<p>For the debug and testing purposes I'd like to find a most convenient way launching Kubernetes pods and altering its specification on-the-fly.</p>

<p>The launching part is quite easy with imperative commands.
Running </p>

<pre><code>kubectl run nginx-test --image nginx --restart=Never
</code></pre>

<p>gives me exactly what I want: the single pod not managed by any controller like Deployment or ReplicaSet. Easy to play with and cleanup when it needed.</p>

<p>However when I'm trying to edit the spec with </p>

<pre><code>kubectl edit po nginx-test
</code></pre>

<p>I'm getting the following warning:</p>

<pre><code>pods "nginx-test" was not valid:
 * spec: Forbidden: pod updates may not change fields other than spec.containers[*].image, spec.initContainers[*].image, spec.activeDeadlineSeconds or spec.tolerations (only additions to existing tolerations)
</code></pre>

<p>i.e. only the limited set of Pod spec is editable at runtime. </p>

<p><strong>OPTIONS FOUND SO FAR:</strong></p>

<ol>
<li><p>Getting Pod spec saved into the file:</p>

<pre><code>kubectl get po nginx-test -oyaml &gt; nginx-test.yaml
</code></pre>

<p>edited and recreated with </p>

<pre><code>kubectl apply -f
</code></pre>

<p>A bit heavy weight for changing just one field though.</p></li>
<li><p>Creating a Deployment not single Pod and then editing <code>spec</code> section in Deployment itself. </p>

<p>The cons are: </p>

<ul>
<li>additional API object needed (Deployment) which you should not forget to cleanup when you are done</li>
<li>the Pod names are autogenerated in the form of <code>nginx-test-xxxxxxxxx-xxxx</code> and less 
convenient to work with. </li>
</ul></li>
</ol>

<p>So is there any simpler option (or possibly some elegant workaround) of editing <strong><em>arbitrary</em></strong> field in the Pod spec?
I would appreciate any suggestion.</p>

<p>You should absolutely use a Deployment here.</p>

<p>For the use case you're describing, most of the interesting fields on a Pod <a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.16/#podspec-v1-core" rel="noreferrer">cannot be updated</a>, so you need to manually delete and recreate the pod yourself.  A Deployment manages that for you.  If a Deployment owns a Pod, and you delete the Deployment, Kubernetes knows on its own to delete the matching Pod, so there's not really any more work.</p>

<p>(There's not really any reason to want a bare pod; you almost always want one of the higher-level controllers.  The one exception I can think of is <code>kubectl run</code> a debugging shell inside the cluster.)</p>

<p>The Pod name being generated can be a minor hassle.  One trick that's useful here: as of reasonably recent <code>kubectl</code>, you can give the <em>deployment</em> name to commands like <a href="https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands#logs" rel="noreferrer"><code>kubectl logs</code></a></p>

<pre><code>kubectl logs deployment/nginx-test
</code></pre>

<p>There are also various "dashboard" type tools out there that will let you browse your current set of pods, so you can do things like read logs without having to copy-and-paste the full pod name.  You may also be able to set up <a href="https://kubernetes.io/docs/reference/kubectl/cheatsheet/#kubectl-autocomplete" rel="noreferrer">tab completion</a> for <code>kubectl</code>, and type</p>

<pre><code>kubectl logs nginx-test&lt;TAB&gt;
</code></pre>
