<p>We are moving our ruby microservices to kubernetes and we used to hold environment specific configuration in the <code>config/application.yml</code>. With kubernetes, you can create environment specific files for each service, e.g. <code>config/kubernetes/production.yml</code> etc. </p>

<p>While kubernetes pod configuration file is able to hold environmental variables, it seems that you cannot really hold structured data in there.</p>

<p>For an example, in <code>application.yml</code> we have</p>

<pre><code>development: &amp;development
  process:
    notifier:
      type: 'terminal-notifier'
  ...

production: &amp;production
  process:
    notifier:
      type: 'airbrake'
      api_key: 'xxxx'
      host: 'xxx.xxx.com'
  ...
</code></pre>

<p>Is it reasonable to continue this practice with kubernetes and break the environments up in the <code>application.yml</code> or does kubernetes have some other best practices for provisioning structured configuration for pod?</p>

<p>Note that until all services are migrated, we basically have to hold the configurations as such:</p>

<pre><code>kubernetes_staging:
  &lt;&lt;: *staging
  ...
</code></pre>

<p>You can do this a few ways, one is keep doing what you're doing in a single file, another is to use labels to specify which environment's config to use, and the other is use namespaces.  I personally recommend namespaces, this way you can have separate <code>.yml</code> files for each environment that potentially spins up the same pods, but with different configurations, so to do this you would have staging, prod, etc namespaces.  Namespaces also are a great way to have the same kubernetes cluster have a concept of staging and production.  Additionally you can specify permissions for certain namespaces.</p>

<p>Here are the docs on namespaces <a href="https://github.com/kubernetes/kubernetes/blob/release-1.0/docs/design/namespaces.md" rel="nofollow">https://github.com/kubernetes/kubernetes/blob/release-1.0/docs/design/namespaces.md</a></p>
