You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Right now it's impossible to expose information from the downward API either as a volume or as environment variables since we don't expose either option in the CRD. Technically we do expose the ability to define volumes, but you have no way to provide a volume mapping. We can fix this in a few ways:
add a new option to the CRD (eg. downwardAPI: true) to the CRD to tell the controller to load downward API information automatically. The controller would load all available values as either env vars or through the volume mount depending on how the data is exposed
add a env config option so that users can add their own environment variables to hosts. The controller would need to add those first and merge in the set of environment variables it generates for the pod template
add a volumeMounts configuration option for allowing users to pass in volume mount mappings corresponding to a downward API volume. This would likely end up simply being the ability to define arbitrary volume mappings, one of which could just be a downward API volume.
Options 2 and 3 seem like things we should do anyway, but option 1 would provide us the most control over what we expose without needing to implement environment variable and volume support. However it would require the maintainers to add all available information from the downward API and keep that up to date.
The text was updated successfully, but these errors were encountered:
Right now it's impossible to expose information from the downward API either as a volume or as environment variables since we don't expose either option in the CRD. Technically we do expose the ability to define volumes, but you have no way to provide a volume mapping. We can fix this in a few ways:
downwardAPI: true
) to the CRD to tell the controller to load downward API information automatically. The controller would load all available values as either env vars or through the volume mount depending on how the data is exposedenv
config option so that users can add their own environment variables to hosts. The controller would need to add those first and merge in the set of environment variables it generates for the pod templatevolumeMounts
configuration option for allowing users to pass in volume mount mappings corresponding to a downward API volume. This would likely end up simply being the ability to define arbitrary volume mappings, one of which could just be a downward API volume.Options 2 and 3 seem like things we should do anyway, but option 1 would provide us the most control over what we expose without needing to implement environment variable and volume support. However it would require the maintainers to add all available information from the downward API and keep that up to date.
The text was updated successfully, but these errors were encountered: