scottk/kubernetes
1
0
Fork 0
mirror of https://github.com/optim-enterprises-bv/kubernetes.git synced 2025-11-04 04:08:16 +00:00
Code Issues Packages Projects Releases Wiki Activity

Rename ConfigData proposal to ConfigMap

Browse Source
This commit is contained in:
Tamer Tas
2015-12-04 18:16:01 +02:00
parent 81b6ac4755
commit f8c952954d
1 changed files with 68 additions and 68 deletions
Download Patch File Download Diff File Expand all files Collapse all files

136
docs/proposals/config_data.md
View File

@@ -20,7 +20,7 @@ refer to the docs that go with that version.
<strong> <strong>
The latest release of this document can be found The latest release of this document can be found
[here](http://releases.k8s.io/release-1.1/docs/proposals/config_data.md). [here](http://releases.k8s.io/release-1.1/docs/proposals/configmap.md).
Documentation for other releases can be found at Documentation for other releases can be found at
[releases.k8s.io](http://releases.k8s.io). [releases.k8s.io](http://releases.k8s.io).
@@ -35,7 +35,7 @@ Documentation for other releases can be found at
## Abstract ## Abstract
This proposal proposes a new API resource, `ConfigData`, that stores data used for the configuration This proposal proposes a new API resource, `ConfigMap`, that stores data used for the configuration
of applications deployed on `Kubernetes`. of applications deployed on `Kubernetes`.
The main focus points of this proposal are: The main focus points of this proposal are:
@@ -50,9 +50,9 @@ A `Secret`-like API resource is needed to store configuration data that pods can
Goals of this design: Goals of this design:
1. Describe a `ConfigData` API resource 1. Describe a `ConfigMap` API resource
2. Describe the semantics of consuming `ConfigData` as environment variables 2. Describe the semantics of consuming `ConfigMap` as environment variables
3. Describe the semantics of consuming `ConfigData` as files in a volume 3. Describe the semantics of consuming `ConfigMap` as files in a volume
## Use Cases ## Use Cases
@@ -61,48 +61,48 @@ Goals of this design:
3. As a user, I want my view of configuration data in files to be eventually consistent with changes 3. As a user, I want my view of configuration data in files to be eventually consistent with changes
to the data to the data
### Consuming `ConfigData` as Environment Variables ### Consuming `ConfigMap` as Environment Variables
Many programs read their configuration from environment variables. `ConfigData` should be possible Many programs read their configuration from environment variables. `ConfigMap` should be possible
to consume in environment variables. The rough series of events for consuming `ConfigData` this way to consume in environment variables. The rough series of events for consuming `ConfigMap` this way
is: is:
1. A `ConfigData` object is created 1. A `ConfigMap` object is created
2. A pod that consumes the configuration data via environment variables is created 2. A pod that consumes the configuration data via environment variables is created
3. The pod is scheduled onto a node 3. The pod is scheduled onto a node
4. The kubelet retrieves the `ConfigData` resource(s) referenced by the pod and starts the container 4. The kubelet retrieves the `ConfigMap` resource(s) referenced by the pod and starts the container
processes with the appropriate data in environment variables processes with the appropriate data in environment variables
### Consuming `ConfigData` in Volumes ### Consuming `ConfigMap` in Volumes
Many programs read their configuration from configuration files. `ConfigData` should be possible Many programs read their configuration from configuration files. `ConfigMap` should be possible
to consume in a volume. The rough series of events for consuming `ConfigData` this way to consume in a volume. The rough series of events for consuming `ConfigMap` this way
is: is:
1. A `ConfigData` object is created 1. A `ConfigMap` object is created
2. A new pod using the `ConfigData` via the volume plugin is created 2. A new pod using the `ConfigMap` via the volume plugin is created
3. The pod is scheduled onto a node 3. The pod is scheduled onto a node
4. The Kubelet creates an instance of the volume plugin and calls its `Setup()` method 4. The Kubelet creates an instance of the volume plugin and calls its `Setup()` method
5. The volume plugin retrieves the `ConfigData` resource(s) referenced by the pod and projects 5. The volume plugin retrieves the `ConfigMap` resource(s) referenced by the pod and projects
the appropriate data into the volume the appropriate data into the volume
### Consuming `ConfigData` Updates ### Consuming `ConfigMap` Updates
Any long-running system has configuration that is mutated over time. Changes made to configuration Any long-running system has configuration that is mutated over time. Changes made to configuration
data must be made visible to pods consuming data in volumes so that they can respond to those data must be made visible to pods consuming data in volumes so that they can respond to those
changes. changes.
The `resourceVersion` of the `ConfigData` object will be updated by the API server every time the The `resourceVersion` of the `ConfigMap` object will be updated by the API server every time the
object is modified. After an update, modifications will be made visible to the consumer container: object is modified. After an update, modifications will be made visible to the consumer container:
1. A `ConfigData` object is created 1. A `ConfigMap` object is created
2. A new pod using the `ConfigData` via the volume plugin is created 2. A new pod using the `ConfigMap` via the volume plugin is created
3. The pod is scheduled onto a node 3. The pod is scheduled onto a node
4. During the sync loop, the Kubelet creates an instance of the volume plugin and calls its 4. During the sync loop, the Kubelet creates an instance of the volume plugin and calls its
`Setup()` method `Setup()` method
5. The volume plugin retrieves the `ConfigData` resource(s) referenced by the pod and projects 5. The volume plugin retrieves the `ConfigMap` resource(s) referenced by the pod and projects
the appropriate data into the volume the appropriate data into the volume
6. The `ConfigData` referenced by the pod is updated 6. The `ConfigMap` referenced by the pod is updated
7. During the next iteration of the `syncLoop`, the Kubelet creates an instance of the volume plugin 7. During the next iteration of the `syncLoop`, the Kubelet creates an instance of the volume plugin
and calls its `Setup()` method and calls its `Setup()` method
8. The volume plugin projects the updated data into the volume atomically 8. The volume plugin projects the updated data into the volume atomically
@@ -122,13 +122,13 @@ consumed in environment variables will not be updated.
### API Resource ### API Resource
The `ConfigData` resource will be added to the `extensions` API Group: The `ConfigMap` resource will be added to the `extensions` API Group:
```go ```go
package api package api
// ConfigData holds configuration data for pods to consume. // ConfigMap holds configuration data for pods to consume.
type ConfigData struct { type ConfigMap struct {
TypeMeta `json:",inline"` TypeMeta `json:",inline"`
ObjectMeta `json:"metadata,omitempty"` ObjectMeta `json:"metadata,omitempty"`
@@ -137,19 +137,19 @@ type ConfigData struct {
Data map[string]string `json:"data,omitempty"` Data map[string]string `json:"data,omitempty"`
} }
type ConfigDataList struct { type ConfigMapList struct {
TypeMeta `json:",inline"` TypeMeta `json:",inline"`
ListMeta `json:"metadata,omitempty"` ListMeta `json:"metadata,omitempty"`
Items []ConfigData `json:"items"` Items []ConfigMap `json:"items"`
} }
``` ```
A `Registry` implementation for `ConfigData` will be added to `pkg/registry/configdata`. A `Registry` implementation for `ConfigMap` will be added to `pkg/registry/configmap`.
### Environment Variables ### Environment Variables
The `EnvVarSource` will be extended with a new selector for config data: The `EnvVarSource` will be extended with a new selector for `ConfigMap`:
```go ```go
package api package api
@@ -158,22 +158,22 @@ package api
type EnvVarSource struct { type EnvVarSource struct {
// other fields omitted // other fields omitted
// Specifies a ConfigData key // Specifies a ConfigMap key
ConfigData *ConfigDataSelector `json:"configData,omitempty"` ConfigMap *ConfigMapSelector `json:"configMap,omitempty"`
} }
// ConfigDataSelector selects a key of a ConfigData. // ConfigMapSelector selects a key of a ConfigMap.
type ConfigDataSelector struct { type ConfigMapSelector struct {
// The name of the ConfigData to select a key from. // The name of the ConfigMap to select a key from.
ConfigDataName string `json:"configDataName"` ConfigMapName string `json:"configMapName"`
// The key of the ConfigData to select. // The key of the ConfigMap to select.
Key string `json:"key"` Key string `json:"key"`
} }
``` ```
### Volume Source ### Volume Source
A new `ConfigDataVolumeSource` type of volume source containing the `ConfigData` object will be A new `ConfigMapVolumeSource` type of volume source containing the `ConfigMap` object will be
added to the `VolumeSource` struct in the API: added to the `VolumeSource` struct in the API:
```go ```go
@@ -181,18 +181,18 @@ package api
type VolumeSource struct { type VolumeSource struct {
// other fields omitted // other fields omitted
ConfigData *ConfigDataVolumeSource `json:"configData,omitempty"` ConfigMap *ConfigMapVolumeSource `json:"configMap,omitempty"`
} }
// ConfigDataVolumeSource represents a volume that holds configuration data // ConfigMapVolumeSource represents a volume that holds configuration data
type ConfigDataVolumeSource struct { type ConfigMapVolumeSource struct {
// A list of config data keys to project into the volume in files // A list of configuration data keys to project into the volume in files
Files []ConfigDataVolumeFile `json:"files"` Files []ConfigMapVolumeFile `json:"files"`
} }
// ConfigDataVolumeFile represents a single file containing config data // ConfigMapVolumeFile represents a single file containing configuration data
type ConfigDataVolumeFile struct { type ConfigMapVolumeFile struct {
ConfigDataSelector `json:",inline"` ConfigMapSelector `json:",inline"`
// The relative path name of the file to be created. // The relative path name of the file to be created.
// Must not be absolute or contain the '..' path. Must be utf-8 encoded. // Must not be absolute or contain the '..' path. Must be utf-8 encoded.
@@ -202,15 +202,15 @@ type ConfigDataVolumeFile struct {
``` ```
**Note:** The update logic used in the downward API volume plug-in will be extracted and re-used in **Note:** The update logic used in the downward API volume plug-in will be extracted and re-used in
the volume plug-in for `ConfigData`. the volume plug-in for `ConfigMap`.
## Examples ## Examples
#### Consuming `ConfigData` as Environment Variables #### Consuming `ConfigMap` as Environment Variables
```yaml ```yaml
apiVersion: extensions/v1beta1 apiVersion: extensions/v1beta1
kind: ConfigData kind: ConfigMap
metadata: metadata:
name: etcd-env-config name: etcd-env-config
data: data:
@@ -222,7 +222,7 @@ data:
etcdctl_peers: http://etcd:2379 etcdctl_peers: http://etcd:2379
``` ```
This pod consumes the `ConfigData` as environment variables: This pod consumes the `ConfigMap` as environment variables:
```yaml ```yaml
apiVersion: v1 apiVersion: v1
@@ -241,38 +241,38 @@ spec:
env: env:
- name: ETCD_NUM_MEMBERS - name: ETCD_NUM_MEMBERS
valueFrom: valueFrom:
configData: configMap:
configDataName: etcd-env-config configMapName: etcd-env-config
key: number_of_members key: number_of_members
- name: ETCD_INITIAL_CLUSTER_STATE - name: ETCD_INITIAL_CLUSTER_STATE
valueFrom: valueFrom:
configData: configMap:
configDataName: etcd-env-config configMapName: etcd-env-config
key: initial_cluster_state key: initial_cluster_state
- name: ETCD_DISCOVERY_TOKEN - name: ETCD_DISCOVERY_TOKEN
valueFrom: valueFrom:
configData: configMap:
configDataName: etcd-env-config configMapName: etcd-env-config
key: discovery_token key: discovery_token
- name: ETCD_DISCOVERY_URL - name: ETCD_DISCOVERY_URL
valueFrom: valueFrom:
configData: configMap:
configDataName: etcd-env-config configMapName: etcd-env-config
key: discovery_url key: discovery_url
- name: ETCDCTL_PEERS - name: ETCDCTL_PEERS
valueFrom: valueFrom:
configData: configMap:
configDataName: etcd-env-config configMapName: etcd-env-config
key: etcdctl_peers key: etcdctl_peers
``` ```
### Consuming `ConfigData` as Volumes ### Consuming `ConfigMap` as Volumes
`redis-volume-config` is intended to be used as a volume containing a config file: `redis-volume-config` is intended to be used as a volume containing a config file:
```yaml ```yaml
apiVersion: extensions/v1beta1 apiVersion: extensions/v1beta1
kind: ConfigData kind: ConfigMap
metadata: metadata:
name: redis-volume-config name: redis-volume-config
data: data:
@@ -290,18 +290,18 @@ spec:
containers: containers:
- name: redis - name: redis
image: kubernetes/redis image: kubernetes/redis
command: "redis-server /mnt/config-data/etc/redis.conf" command: "redis-server /mnt/config-map/etc/redis.conf"
ports: ports:
- containerPort: 6379 - containerPort: 6379
volumeMounts: volumeMounts:
- name: config-data-volume - name: config-map-volume
mountPath: /mnt/config-data mountPath: /mnt/config-map
volumes: volumes:
- name: config-data-volume - name: config-map-volume
configData: configMap:
files: files:
- path: "etc/redis.conf" - path: "etc/redis.conf"
configDataName: redis-volume-config configMapName: redis-volume-config
key: redis.conf key: redis.conf
``` ```
@@ -311,5 +311,5 @@ In the future, we may add the ability to specify an init-container that can watc
contents for updates and respond to changes when they occur. contents for updates and respond to changes when they occur.
<!-- BEGIN MUNGE: GENERATED_ANALYTICS --> <!-- BEGIN MUNGE: GENERATED_ANALYTICS -->
[![Analytics](https://kubernetes-site.appspot.com/UA-36037335-10/GitHub/docs/proposals/config_data.md?pixel)]() [![Analytics](https://kubernetes-site.appspot.com/UA-36037335-10/GitHub/docs/proposals/configmap.md?pixel)]()
<!-- END MUNGE: GENERATED_ANALYTICS --> <!-- END MUNGE: GENERATED_ANALYTICS -->