<p>Both seems to achieve the same - configure a pod at build time.</p>

<p>Can anyone please explain me what is the difference between the two?
Maybe also give a simple 1 use case example of each after, if you think that's going to make it clearer.</p>

KDX2
<p>A pod preset is more scalable and powerful than configmaps/secrets for injecting common information into Pods.</p>

<p>A Kubernetes cluster may contain hundreds of Pods. Many of these Pods share common constructs like Environment Variables, ConfigMaps, Secrets etc. For instance, in case of microservices using MySQL, we need to inject MySQL credentials as K8s Secrets in the pod. If cluster has 100 microservices( not so uncommon) , we would need to add following section in all 100 pod's configuration. </p>

<p>This is terribly inefficient and error prone. Pod Preset help us avoid this by injecting common information in multiple Pods so that we put all common information in one place.</p>

<pre><code>    env:
      - name: SECRET_USERNAME
        valueFrom:
          secretKeyRef:
            name: mysecret
            key: mysql-username
      - name: SECRET_PASSWORD
        valueFrom:
          secretKeyRef:
            name: mysecret
            key: mysql-password
</code></pre>

<p>From the pod preset design <a href="https://github.com/kubernetes/community/blob/master/contributors/design-proposals/service-catalog/pod-preset.md#motivation" rel="nofollow noreferrer">doc</a>.</p>

<blockquote>
  <p><strong>Motivation</strong>:</p>
  
  <p>Consuming a service involves more than just connectivity. In addition
  to coordinates to reach the service, credentials and non-secret
  configuration parameters are typically needed to use the service. The
  primitives for this already exist, but a gap exists where loose
  coupling is desired: it should be possible to inject pods with the
  information they need to use a service on a service-by-service basis,
  without the pod authors having to incorporate the information into
  every pod spec where it is needed.</p>
  
  <p><strong>Use Cases</strong></p>
  
  <ol>
  <li>As a user, I want to be able to provision a new pod without needing to
  know the application configuration primitives the services my pod will
  consume. </li>
  <li>As a cluster admin, I want specific configuration items of a
  service to be withheld visibly from a developer deploying a service,
  but not to block the developer from shipping. </li>
  <li>As an app developer, I
  want to provision a Cloud Spanner instance and then access it from
  within my Kubernetes cluster. </li>
  <li>As an app developer, I want the Cloud
  Spanner provisioning process to configure my Kubernetes cluster so the
  endpoints and credentials for my Cloud Spanner instance are implicitly
  injected into Pods matching a label selector (without me having to
  modify the PodSpec to add the specific Configmap/Secret containing the
  endpoint/credential data).</li>
  </ol>
</blockquote>
