Add support for overriding `kubernetes` provider config

[ringods]

What happened?

Customer has a stack where he disabled Kubernetes Server Side Apply. While running preview or up, SSA was still active.

Steps to reproduce

• Have a Pulumi program using EKS and create an EKS cluster.
• Disable SSA in the stack config: pulumi config set kubernetes:enableServerSideApply false
• Run Pulumi preview or up

Expected Behavior

The configuration parameter should be picked up from the stack config.

Actual Behavior

The configuration parameter is not picked up from the stack config. Using the corresponding environment variable PULUMI_K8S_ENABLE_SERVER_SIDE_APPLY=false worked though.

Output of pulumi about

• pulumi-eks v0.4x
• pulumi-kubernetes v3.22.0

Additional context

The EKS code creates two explicit Kubernetes providers:

https://github.com/pulumi/pulumi-eks/blob/ad99ab21390dcaa40796247c808209b7f51d7657/nodejs/eks/cluster.ts#L591-L593

https://github.com/pulumi/pulumi-eks/blob/ad99ab21390dcaa40796247c808209b7f51d7657/nodejs/eks/cluster.ts#L1489-L1493

Both snippets only receive the calculated kubeconfig property. In both cases, the kubernetes config namespace should be merged into it for the rest of the settings to be picked up.

Contributing

Vote on this issue by adding a 👍 reaction. To contribute a fix for this issue, leave a comment (and link to your pull request, if you've opened one already).

[roothorp]

Hi @ringods - I am under the impression that pulumi config should only affect the default provider, and env variables or args should be used to configure explicit providers (such as the k8s provider here). As such, I believe in this case we should be able to pass settings down into the internally created k8s provider - I think we do something similar to this with the AWS provider. I believe for the time being using env variables is the best solution.

[ringods]

@roothorp that is a fair assumption. However, if you allow for explicit arguments to be passed from an eks.Cluster to the k8s providers created within it, make sure to also document clearly that the kubernetes stack config is not automatically applied to these internal providers, otherwise it would remain a source of confusion for our users.