Issue 1:
This issue is based on the suggestions in #1553. I thought getting a clean overview for a renewed discussion was worth the additional issue.

Similar to secret distribution #2030 there is a need to dynamicaly configure applications. Producing or changing configuration scripts via cat, sed or other "hacky" tooling is a method I dislike and I would love a cleaner way of supporting this.

Option 1: envconsul/etcdenv

Pros:

Injects etcd/consul values as ENVs

Easy way to switch from ENVs to etcd/consul

Cons:

Doesn't actually solve config generation

Option 2: confd

Pros:

Supports various backends (consul, etcd, ENVs)

Supports almost any config structure as it is template based

Easy templates using Golang Text Templates

Support for one-time and watch (etcd/consul)

Command line flags to bootstrap confd config

Cons:

Template based

No encrypted value support -> crypt or just encrypted volumes #2030?

Option 3: viper

Pros:

Supports encrypted values via crypt

No templates

Easy syntax

Command line flags to bootstrap viper config

Cons:

No ini file support

Not as easy for complex configuration files

Option 4: augeas

Pros:

Wide range of config formats supported

Cons:

Complex syntax especially for complex configurations

Option5: tiller

Pros:

Supports almost any config structure as it is template based

Ability to "pipe" json configs into a container instead of ENV files

Cons:

Template based

ERB templates -> more complex than necessary in my opinion

Can use container provided .yaml files -> could prevent image sharing

Clarification:

Confd:

@kelseyhightower

Is a config file needed for confd to work or could everything be done using commandline flags?

Can multiple config files be generated, if yes how?

Viper:

@spf13 @bketelsen

Is a config file needed for viper to work or could everything be done using commandline flags?

-> Config file and various other configuration possibilities for viper are optional. It can be used straight via commandline flags.

Overall I think the way to go would be to use confd with ENV as default backend. Furthermore containers should be able to understand a backend switch ENV so that switching to etcd/consul is easily done on a per container level at runtime. This enables easy testing and environment switching. With the addition of watchable configuration via confd more dynamic setups are possible.

Looking forward to your thoughts and suggestions.

Issue 2:
Kubernetes version 1.0.6

This setup involves pods for Cassandra (2-nodes), Spark (master, 3-workers, driver), RabbitMQ(1-node). Some pods that are not under replication controller die after a day and never restarted automatically. I found out that *influxDB' monitoring was using too much of CPU and the pods dying are from that node.

Please notice the restartPolicy: Always is the default as I have not explicitly specified it. With this I was expecting manually started pods to restart on failure similar to the ones under replication controller

Once the pod died, there was no way to run "kubectl.sh describe pod-is* on it. Could not find any debugging information on the failure. This is very much duplicatable if I switch on the cluster monitoring (with ENABLE_CLUSTER_MONITORING; true by default)

Related threads with more info/discussion

Influxdb is using 1 core on 4 core cluster

Kubernetes pods (some) die after running for a day