KEP-4742: Expose Node Labels via Downward API #4747
- Loading branch information
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -163,11 +163,11 @@ to extract information. | |
| We’d like to change the runtime behavior of containers based on node labels. | ||
| In our case, we’re using a CNI with DaemonSets to perform network setup, and | ||
| would like to configure the network differently based on the presence of a node | ||
| label (e.g. `topology.k8s.io/vpn=true`). | ||
|
There was a problem hiding this comment.
There was a problem hiding this comment. We used this based off the suggestion made in kubernetes/kubernetes#40610 (comment) that these labels could be copied - but I think the comment there was addressing the very specific use case of things like being AZ-aware, and not the broader need to make certain node labels visible in pods. Whatever the scheme, I think I'd like to stick with a convention for labels (e.g. There was a problem hiding this comment. When we started this conversation, I assumed (I know, my mistake) that we would only be copying topology labels, and those topology labels are few in number and well defined by the project. I am okay if we want to define a way for admins to extend that using our topology label space, as long as we make it clear what's an extension and what is standard. But we have to define that somewhere. I am also okay, I guess, to define a different label space, which explicitly means that "these labels are safe to copy to pods". But again we have to define that somewhere. I really really really do not want this to be something that is configurable, either through flags or crds or something else. Until and unless we can show that something simple and well defined absolutely cannot work, let's just do the simple thing. |
||
|
|
||
| A number of other use cases exist for providing node labels to pods. One | ||
| example is utilizing topology data from cloud providers, which are automatically | ||
| assigned to nodes, and then used to tailor workloads to minimize cross-zone data | ||
| transfers and reduce costs. Having an easy way for pods to access these node | ||
| topology labels would provide users a straightforward, maintainable way to | ||
| optimize their workloads given topology constraints. | ||
|
|
||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For very specific cases, we have workarounds like sidecars. If these DaemonSets need more info, that's their escape path.