Resolve env vars in kubelet; add downward API env for pod name #6000
Conversation
|
Thanks for your pull request. It looks like this may be your first contribution to a Google open source project, in which case you'll need to sign a Contributor License Agreement (CLA) at https://cla.developers.google.com/. If you've already signed a CLA, it's possible we don't have your GitHub username or you're using a different email address. Check the information on your CLA or see this help article on setting the email on your git commits. Once you've done that, please reply here to let us know. If you signed the CLA as a corporation, please let us know the company's name. |
|
@smarterclayton @thockin @bgrant0607 PTAL; it needs a lot more doc. |
| @@ -55,6 +56,7 @@ import ( | |||
| func init() { | |||
| api.ForTesting_ReferencesAllowBlankSelfLinks = true | |||
| util.ReallyCrash = true | |||
| flag.Set("v", "5") | |||
There was a problem hiding this comment.
I'll remove this once we're ready to put this in
| &api.Pod{ObjectMeta: api.ObjectMeta{Namespace: "unknown", Name: "test-pod"}}, | ||
| &api.Container{ | ||
| Env: []api.EnvVar{ | ||
| {Name: "BAR", Value: "bar"}, |
There was a problem hiding this comment.
What will Docker's transitive expansion do for us? I looked at the code, but have forgotten already. I'd rather define a simpler mechanism to populate environment variables with Kubernetes data, and then rely upon Docker and/or the shell for more general expansion/substitution.
There was a problem hiding this comment.
We could introduce a separate field on EnvVar that is the source of the data, and disallow value via validation. That would clearly delineate the two.
----- Original Message -----
},},"kubernetes",true,util.NewStringSet("BAR=bar","FOO=bar",),2,},{"slightly more complex substitution",&api.Pod{ObjectMeta: api.ObjectMeta{Namespace: "unknown", Name:&api.Container{Env: []api.EnvVar{{Name: "BAR", Value: "bar"},What will Docker's transitive expansion do for us? I looked at the code, but
have forgotten already. I'd rather define a simpler mechanism to populate
environment variables with Kubernetes data, and then rely upon Docker and/or
the shell for more general expansion/substitution.
Reply to this email directly or view it on GitHub:
https://github.com/GoogleCloudPlatform/kubernetes/pull/6000/files#r27256435
There was a problem hiding this comment.
@bgrant0607 @smarterclayton I cannot find an info regarding expansion of vars that is not scoped to the docker builder. If you can point me to anything, I'd appreciate it.
There was a problem hiding this comment.
So, yes, that's scoped to the builder.
There was a problem hiding this comment.
@smarterclayton On second reading, I don't get the bools for fields thing.
There was a problem hiding this comment.
It was for specific fields that are not cleanly represented by an API resource. I think ObjectReference makes sense for many cases, but not all data we expose necessarily has an API object (although maybe you could argue that they should).
----- Original Message -----
},},"kubernetes",true,util.NewStringSet("BAR=bar","FOO=bar",),2,},{"slightly more complex substitution",&api.Pod{ObjectMeta: api.ObjectMeta{Namespace: "unknown", Name:&api.Container{Env: []api.EnvVar{{Name: "BAR", Value: "bar"},@smarterclayton On second reading, I don't get the bools for fields thing.
Reply to this email directly or view it on GitHub:
https://github.com/GoogleCloudPlatform/kubernetes/pull/6000/files#r27497979
There was a problem hiding this comment.
Yes, maybe they should.
What I think is great about all of the approaches discussed here is that the substitution is performed by the control plane, which preserves separation of dev/ops concerns.
By contrast, a downward API that would be directly read/polled/watched by applications would bake that API into many more thousands of applications than those otherwise targeting the management API. Consequently, such an API would need to be narrower and more slowly changing than the management API, since it would be much harder to change.
There was a problem hiding this comment.
@bgrant0607 what do you consider the control plane in this case?
There was a problem hiding this comment.
@bgrant0607 Disregard, I see what you mean. That is a good point re: consuming the API within the image, and another facet of how hard it would be make a sensible API to consume that way.
|
This is parked until we figure out how we really want to do substitution. |
|
@bgrant0607 @smarterclayton closing this one; will make another PR with the env var sources we discussed here. |
As discussed in #2316; also relevant to #386