Kubernetes ConfigMap Manifest: Difference between revisions
(9 intermediate revisions by the same user not shown) | |||
Line 3: | Line 3: | ||
=Internal= | =Internal= | ||
* [[Kubernetes_Cluster_Configuration_Concepts#ConfigMap_Manifest|Configuration | * [[Kubernetes_Cluster_Configuration_Concepts#ConfigMap_Manifest|Kubernetes Configuration]] | ||
=Example= | =Example= | ||
<font size=-1> | <font size=-1> | ||
Line 26: | 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==' | |||
[[#immutable| immutable]]: true|false | [[#immutable| immutable]]: true|false | ||
</font> | </font> | ||
Line 32: | Line 37: | ||
=Elements= | =Elements= | ||
==<tt>data</tt>== | ==<tt>data</tt>== | ||
Data contains the configuration data. Each key must consist of alphanumeric characters, '-', '_' or '.'. Values with non-UTF-8 byte sequences must use the <code>[[#binaryData|binaryData]]</code> field. The keys stored in <code>[[#data|data]]</code> must not overlap with the keys in the <code>[[#binaryData|binaryData]]</code> field, this is enforced during validation process. | Data contains the configuration data. Each key must consist of alphanumeric characters, '-', '_' or '.'. Values with non-UTF-8 byte sequences must use the <code>[[#binaryData|binaryData]]</code> field. | ||
The keys stored in <code>[[#data|data]]</code> must not overlap with the keys in the <code>[[#binaryData|binaryData]]</code> field, this is enforced during validation process. | |||
It is recommended to use all upper cap characters for ConfigMap keys intended to be projected as environment variables, and proper file name capitalization for those keys intended to be projected as files. | |||
==<tt>binaryData</tt>== | ==<tt>binaryData</tt>== | ||
<code>binaryData</code> contains the binary data, in [[Base64#Overview|base64]] format. Each key must consist of alphanumeric characters, '-', '_' or '.'. <code>binaryData</code> can contain byte sequences that are not in the UTF-8 range. The keys stored in <code>binaryData</code> must not overlap with the ones in the <code>data</code> 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 <code>sample.txt.gz</code> (which contains a gzipped text content): | |||
<syntaxhighlight lang='bash'> | |||
cat sample.txt.gz | base64 | |||
</syntaxhighlight> | |||
The content such generated can be copied and pasted verbatim into the <code>binaryData</code>: | |||
<syntaxhighlight lang='yaml'> | |||
apiVersion: v1 | |||
kind: ConfigMap | |||
... | |||
binaryData: | |||
sample.txt.gz: 'H4sIAH6zH2IAAwvJyCxWAKJErpLUihIFruLE3IKcVD0uLgAXdw7tGQAAAA==' | |||
</syntaxhighlight> | |||
Once this ConfigMap is projected into a pod via a volume, a file with the gzipped content will be exposed as <code>sample.txt.gz</code>. | |||
An example of how to deploy ConfigMaps with <code>binaryData</code> with Helm is available here: {{Internal|Helm_ConfigMap_and_Secrets#ConfigMap_with_binaryData|Helm ConfigMap with binaryData}} | |||
==<tt>immutable</tt>== | ==<tt>immutable</tt>== | ||
See: {{Internal|Kubernetes_Cluster_Configuration_Concepts#Immutable_ConfigMaps|Immutable ConfigMaps}} |
Latest revision as of 20:57, 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.
It is recommended to use all upper cap characters for ConfigMap keys intended to be projected as environment variables, and proper file name capitalization for those keys intended to be projected as files.
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:
immutable
See: