Kubernetes ConfigMap Manifest: Difference between revisions

From NovaOrdis Knowledge Base
Jump to navigation Jump to search
Line 27: Line 27:
     color.bad=yellow
     color.bad=yellow
     allow.textmode=true     
     allow.textmode=true     
  COLOR: red  <font color=teal># It is recommended to use all upper cap characters for ConfigMap
                                # keys intended to be projected as environment variables.</font>
  SHAPE: square
  [[#binaryData | binaryData]]:
  [[#binaryData | binaryData]]:
   sample.txt.gz: 'H4sIAH6zH2IAAwvJyCxWAKJErpLUihIFruLE3IKcVD0uLgAXdw7tGQAAAA=='
   sample.txt.gz: 'H4sIAH6zH2IAAwvJyCxWAKJErpLUihIFruLE3IKcVD0uLgAXdw7tGQAAAA=='

Revision as of 20:37, 28 February 2024

External

Internal

Example

apiVersion: v1
kind: ConfigMap
metadata:
  name: blue
  labels:
    color: blue
  annotations:
    ...
data:
  # property-like keys; each key maps to a simple value
  quantity: "3"
  file_name: "somefile.properties"
   # file-like keys
  game.properties: |
    shape=square
    strength=5    
  somefile.properties: |
    color.good=purple
    color.bad=yellow
    allow.textmode=true    
  COLOR: red  # It is recommended to use all upper cap characters for ConfigMap 
                               # keys intended to be projected as environment variables.
  SHAPE: square 
 binaryData:
  sample.txt.gz: 'H4sIAH6zH2IAAwvJyCxWAKJErpLUihIFruLE3IKcVD0uLgAXdw7tGQAAAA=='
 immutable: true|false

Elements

data

Data contains the configuration data. Each key must consist of alphanumeric characters, '-', '_' or '.'. Values with non-UTF-8 byte sequences must use the binaryData field. The keys stored in data must not overlap with the keys in the binaryData field, this is enforced during validation process.

binaryData

binaryData contains the binary data, in base64 format. Each key must consist of alphanumeric characters, '-', '_' or '.'. binaryData can contain byte sequences that are not in the UTF-8 range. The keys stored in binaryData must not overlap with the ones in the data field, this is enforced during validation process.

Exposing a Binary Data File via a ConfigMap

First base64-encode the binary fine. Assuming that the binary file is a local sample.txt.gz (which contains a gzipped text content):

cat sample.txt.gz | base64

The content such generated can be copied and pasted verbatim into the binaryData:

apiVersion: v1
kind: ConfigMap
...
binaryData:
  sample.txt.gz: 'H4sIAH6zH2IAAwvJyCxWAKJErpLUihIFruLE3IKcVD0uLgAXdw7tGQAAAA=='

Once this ConfigMap is projected into a pod via a volume, a file with the gzipped content will be exposed as sample.txt.gz.

An example of how to deploy ConfigMaps with binaryData with Helm is available here:

Helm ConfigMap with binaryData

immutable