<p>When I want to generate yaml by running <code>kubectl</code>, it denotes that I should denote <code>--generator=something</code> flag within the command.</p>

<p>For example, to get the deployment template via <code>kubectl</code>, I should run the below command:</p>

<pre><code>kubectl run --generator=deployment/v1beta1 nginx --image=nginx --dry-run -o yaml
</code></pre>

<p>Without mentioning <code>--generator</code> flag the CLI states in some kind that I should mention the generator flag with a proper value (e.g. <code>run-pod/v1</code>).</p>

<p>My question is, what is essentially a generator? What does it do? Are they some sort of object creation templates or something else?</p>

<p>That was introduced in <a href="https://github.com/kubernetes/kubernetes/commit/426ef9335865ebef43f682da90796bd8bf976637" rel="noreferrer">commit 426ef93</a>, Jan. 2016 for Kubernetes v1.2.0-alpha.8.</p>

<p><a href="https://github.com/kubernetes/kubernetes/blob/426ef9335865ebef43f682da90796bd8bf976637/docs/devel/kubectl-conventions.md#generators" rel="noreferrer">The generators</a> were described as:</p>

<blockquote>
  <p>Generators are <code>kubectl</code> commands that generate resources based on a set of inputs (other resources, flags, or a combination of both).</p>
  
  <p>The point of generators is:</p>
  
  <ul>
  <li>to enable users using <code>kubectl</code> in a scripted fashion to pin to a particular behavior which may change in the future.<br>
  Explicit use of a generator will always guarantee that the expected behavior stays the same.</li>
  <li>to enable potential expansion of the generated resources for scenarios other than just creation, similar to how <code>-f</code> is supported for most general-purpose commands.</li>
  </ul>
</blockquote>

<p>And:</p>

<blockquote>
  <p>Generator commands should obey to the following conventions:</p>
  
  <ul>
  <li>A <code>--generator</code> flag should be defined. Users then can choose between different generators, if the command supports them (for example, <code>kubectl run</code> currently supports generators for pods, jobs, replication controllers, and deployments), or between different versions of a generator so that users depending on a specific behavior may pin to that version (for example, <code>kubectl</code> expose currently supports two different versions of a service generator).</li>
  <li>Generation should be decoupled from creation.<br>
  A generator should implement the <code>kubectl.StructuredGenerator</code> interface and have no dependencies on cobra or the Factory</li>
  </ul>
</blockquote>
