instruction: Create a Kubernetes configuration with Deployment, ConfigMap resources
output: ```yaml
  apiVersion: apps/v1
  kind: Deployment
  metadata:
   name: my-app
   labels:
   app: my-app
  spec:
   selector:
   matchLabels:
   app: my-app
   template:
   metadata:
   labels:
   app: my-app
   spec:
   containers:
   - name: app
   image: my-app
   volumeMounts:
   - name: password
   mountPath: /secrets
   volumes:
   - name: password
   secret:
   secretName: example-secret-1
  EOF
  
  cat <<EOF >./kustomization.yaml
  resources:
  - deployment.yaml
  secretGenerator:
  - name: example-secret-1
   files:
   - password.txt
  EOF
  generatorOptionsThe generated ConfigMaps and Secrets have a content hash suffix appended. This ensures that
  a new ConfigMap or Secret is generated when the contents are changed. To disable the behavior
  of appending a suffix, one can use generatorOptions. Besides that, it is also possible to
  specify cross-cutting options for generated ConfigMaps and Secrets.cat <<EOF >./kustomization.yaml
  configMapGenerator:
  - name: example-configmap-3
   literals:
   - FOO=Bar
  generatorOptions:
   disableNameSuffixHash: true
   labels:
   type: generated
   annotations:
   note: generated
  EOF
  Runkubectl kustomize ./ to view the generated ConfigMap:apiVersion: v1
  data:
   FOO: Bar
  kind: ConfigMap
  metadata:
   annotations:
   note: generated
   labels:
   type: generated
   name: example-configmap-3
  Setting cross-cutting fieldsIt is quite common to set cross-cutting fields for all Kubernetes resources in a project.
  Some use cases for setting cross-cutting fields:setting the same namespace for all resourcesadding the same name prefix or suffixadding the same set of labelsadding the same set of annotationsHere is an example:# Create a deployment.yaml
  cat <<EOF >./deployment.yaml
  ```