Sending .Net Core application settings to kubernetes pods as environment variables

10/16/2018

I'm hosting some stuff as an AppService in Azure and use environment variables to differentiate settings for different slots (test, dev etc).

If the AppSettings.json file contains a structure like:

{
   "ConnectionString": {
      "MyDb": "SomeConnectionString"
   }
}

I can set the environment variable "ConnectionString:MyDb" to "SomeConnectionString" and .Net Core will understand that the : means child level.

But in Kubernetes I cannot use : as part of the environment key. Is there another way to handle hierarchy or do I need to switch to flat settings?

-- Paaland
.net-core
azure
kubernetes

2 Answers

1/10/2020

Yes, example

In the Appsettings.json

 "ConnectionStrings": {
    "Azure": "Server=tcp:uw2qdisa

In the manifest.yml

    env:
    - name:  ConnectionStrings__Azure
      valueFrom:
        configMapKeyRef:
          name: config-disa
          key: ConnectionStrings

Explanation on Kubernetes

  • Some .Net Core applications expect environment variables with a colon (:) in the name. Kubernetes currently does not allow this. Replace colon (:) with double underscore (__) as documented here.
-- Joe Mantil
Source: StackOverflow

10/16/2018

I believe you are referring to the env in the container definition for a Pod. From the YAML/JSON perspective, I don't see a problem with specifying a : in a key for an environment variable. You can also put it within quotes and should be valid JSON/YAML:

# convert.yaml
apiVersion: v1
kind: Pod
metadata:
  name: envar-demo
  labels:
    purpose: demonstrate-envars
spec:
  containers:
  - name: envar-demo-container
    image: dotnetapp
    env:
    - name: ConnectionString:Mydb
      value: ConnectionString

Same in JSON:

$ kubectl convert -f convert.yaml -o=json
{
    "kind": "Pod",
    "apiVersion": "v1",
    "metadata": {
        "name": "envar-demo",
        "creationTimestamp": null,
        "labels": {
            "purpose": "demonstrate-envars"
        }
    },
    "spec": {
        "containers": [
            {
                "name": "envar-demo-container",
                "image": "dotnetapp",
                "env": [
                    {
                        "name": "ConnectionString:Mydb",
                        "value": "ConnectionString"
                    }
                ],
                "resources": {},
                "terminationMessagePath": "/dev/termination-log",
                "terminationMessagePolicy": "File",
                "imagePullPolicy": "Always"
            }
        ],
        "restartPolicy": "Always",
        "terminationGracePeriodSeconds": 30,
        "dnsPolicy": "ClusterFirst",
        "securityContext": {},
        "schedulerName": "default-scheduler"
    },
    "status": {}
}

However, looks like this was a known issue with Windows/.NET applications. An attempt to fix it has been tried and ditched due to the fact the this is not valid in Bash. But looks like they settled to use the __ instead of : workaround

-- Rico
Source: StackOverflow