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

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.

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.

    env:
      - name: SECRET_USERNAME
        valueFrom:
          secretKeyRef:
            name: mysecret
            key: mysql-username
      - name: SECRET_PASSWORD
        valueFrom:
          secretKeyRef:
            name: mysecret
            key: mysql-password

From the pod preset design doc.

Motivation:

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.

Use Cases

1. 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.
2. 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.
3. As an app developer, I want to provision a Cloud Spanner instance and then access it from within my Kubernetes cluster.
4. 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).