The crasher in Chapter 1 wanted one thing: MONSTER_DB_URL. It wanted it as an environment variable, the oldest way to configure a program.
In the spec
yaml
spec:
containers:
- name: api
image: stackmonsters/monster-market-api
env:
- name: MONSTER_DB_URL
value: postgres://market-db:5432/market
- name: LOG_LEVEL
value: debugEach container has its own env list of name and value. The image usually brings defaults too (PATH, HOME, its own settings); the spec adds to them.
From the command line
text
learner@shallows:~$ kubectl run api --image=stackmonsters/crasher --env=MONSTER_DB_URL=postgres://market-db:5432/market
pod/api created
learner@shallows:~$ kubectl set env deploy/market-api LOG_LEVEL=debug
deployment.apps/market-api env updated--env sets a variable on a new Pod. set env edits a Deployment's template, which starts a rollout. kubectl set env deploy/market-api --list prints what is set.
See it from inside
text
learner@shallows:~$ kubectl exec api -- env
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
HOSTNAME=api
MONSTER_DB_URL=postgres://market-db:5432/market
APP_NAME=crasher
learner@shallows:~$ kubectl exec api -- printenv MONSTER_DB_URL
postgres://market-db:5432/marketenv prints everything the process sees; printenv NAME prints one.
Fixed at start
A process reads its environment once, when it starts. There is no way to change the variables of a running container. A change to the spec means a new Pod:
kubectl set env deploy/apitemplate changes
rollout
new Podreads the new environment