I've a Deployment object where I expose the POD ID using the Downward API. That works fine. However, I want to set up another env variable, log path, with reference to the POD ID. But, setting that variable value to /var/log/mycompany/${POD_ID}/logs isn't working, no logs are created in the container. I can make the entrypoint script or the app aware of the POD ID, and build up the log path, but I'd rather not do that.
- Can you include your deployment config?Eric Walker– Eric Walker2018-03-30 22:43:29 +00:00Commented Mar 30, 2018 at 22:43
- @EricWalker I'm afraid, I can't, it's proprietary. If you've a specific question, I can try to answer that.Abhijit Sarkar– Abhijit Sarkar2018-03-30 22:44:31 +00:00Commented Mar 30, 2018 at 22:44
Add a comment |
4 Answers
The correct syntax is to use $(FOO), as is described in the the documentation; the syntax you have used is "shell" syntax, which isn't the way kubernetes interpolates variables. So:
containers: - env: - name: POD_ID valueFrom: # etc etc - name: LOG_PATH value: /var/log/mycompany/$(POD_ID)/logs Also please note that, as mentioned in the Docs, the variable to expand must be defined before the variable referencing it.
9 Comments
Abhijit Sarkar
Thanks. Why be consistent when you can cook up something new just to confuse people.
devstructor
how about Kubernetes ConfigMaps? I tried that solution and I failed :-(
mdaniel
@devstructor it smells like you have a new question; please don't hijack other people's comment threads
mdaniel
The syntax is, as I both said and linked to,
$() -- there is no "unquoted" flavor, you must enclose the reference with dollar, left-paren, the identifier, right-paren |
I'd just like to add to this question, a caveat we ran into the other day. According to the documentation:
Variable references $(VAR_NAME) are expanded using the previous defined environment variables in the container and any service environment variables. If a variable cannot be resolved, the reference in the input string will be unchanged.
Emphasis mine. If you have
- name: POD_ID valueFrom: # etc etc - name: LOG_PATH value: /var/log/mycompany/$(POD_ID)/logs it will work, but if you have
- name: LOG_PATH value: /var/log/mycompany/$(POD_ID)/logs - name: POD_ID valueFrom: # etc etc it will not. If you're using a templating engine to generate your specs, beware.
2 Comments
Egalitarian
Is there a way I can mark a variable for last evaluation ?
Cyril Duchon-Doris
I ran into this problem while trying to refactor environment variables to a dict to solve the value override problem stackoverflow.com/a/58636928/2832282
Here is an example which reads metadata.name
- name: POD_NAME valueFrom: fieldRef: fieldPath: metadata.name - name: LOG_FILE_NAME value: "/app/log/$(POD_NAME).log" Here is another example, which reads metadata.namespace
- name: POD_NAMESPACE valueFrom: fieldRef: fieldPath: metadata.namespace - name: REACT_APP_DB_URI value: "http://api-$(POD_NAMESPACE).org.com" One more example, demonstrating how to read from metadata.labels
- name: SRVC_NAME valueFrom: fieldRef: fieldPath: metadata.labels['app'] - name: LOG_FILE_NAME value: '/app/log/$(SRVC_NAME).log' The key is dependent variable should defined later
Refer this for more details
2 Comments
Abhijit Sarkar
What does your answer add to the other ones? Apparently nothing.
craftsmannadeem
Two things: 1) Correct link from Kubernetes on dependent variables 2) Practical use case, reading from meta data, instated of made up. It demonstrate how to read meta data and use it as variables in another dependent variable.
you can also add a secret first then use newly created secret into your countless deployment files to share same environment variable with value:
kubectl create secret generic jwt-secret --from-literal=JWT_KEY=my_awesome_jwt_secret_code spec: containers: - name: auth image: lord/auth env: - name: MONGO_URI value: "mongodb://auth-mongo-srv:27017/auth" - name: JWT_KEY valueFrom: secretKeyRef: name: jwt-secret key: JWT_KEY process.env.MONGO_URI process.env.JWT_KEY 