Skip to content

Instantly share code, notes, and snippets.

@duglin
Last active Jul 27, 2017
Embed
What would you like to do?
params.yaml
spec:
serviceClassName: user-provided-service
planName: default
parameters:
- name: username # easy name/value pair case
value: root
- name: password # pull value from a secret's key
valueFrom:
secretKeyRef:
name: mySecret1
key: passwd
- name: size # pull value from a configMap key
valueFrom:
configMapKeyRef:
name: myConfigMap0
key: length
parametersFrom:
- configMapRef: myConfigMap1 # pull in all the CM's key/value's (string/string)
- secretRef: mySecret2 # pull in all the secret key/value's (string/string)
- configMapKeyBlobRef:
name: myConfigMap2
key: credentials # "credentials" is a JSON object so we take it verbatim and we merge with the above
- secretKeyBlobRef:
name: mySecret3
key: creds # "creds" is a JSON object so we take it verbatim and merge with the the above
@nilebox
Copy link

nilebox commented Jul 27, 2017

Just to demonstrate the consistency between this approach and Pod environment variables:

apiVersion: v1
kind: Pod
metadata:
  name: my-pod
spec:
  containers:
  - name: test-container
    image: nginxdemos/hello
    env:
    - name: USERNAME
      value: root
    - name: PASSWORD
      valueFrom:
        secretKeyRef:
          name: mySecret1
          key: passwd
    - name: SIZE
      valueFrom:
        configMapKeyRef:
          name: myConfigMap0
          key: length
    envFrom:
    - configMapRef:
      name: myConfigMap1
    - secretRef:
      name: mySecret2
  • there is no analogy for secretKeyBlobRef and configMapKeyBlobRef of course, but the rest maps one-to-one
  • envFrom items have prefix attribute, which we might want to leverage as well (for conflict resolution)

@ash2k
Copy link

ash2k commented Jul 27, 2017

This looks like a comprehensive solution for a variety of use cases, I like it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment