[stable/kong] refactor env block generation

[rainest]

What this PR does / why we need it:

tl;dr it makes generating EnvVar blocks cleaner and allows us to guarantee that we only provide one version of an environment variable, because providing multiple versions causes bad things to happen.

This change significantly refactors the generation of Kong container env blocks. It also consolidates various secretKeyRef templates into a single generic template, and makes several minor changes elsewhere in the chart to accomodate the new templates.

The current template handles user-provided environment variables and automatically-generated variables differently. User variables are rendered in a loop over the env section of values.yaml, and generated variable values are inserted into a static template. If a user provides a variable that is also generated automatically, the resulting EnvVar block will contain both versions of the variable.

The new template adds both user and generated variables to dictionaries, which are then combined and run through a render loop to generate the EnvVar block. Dictionaries include built-in support for overriding a key's (variable name) value with another value consistently. User-provided variable values take precedence over generated values, and only a single version of a variable will be present in the resulting EnvVar block.

Special notes for your reviewer:

Previously, based on observed behavior in our test environments, we believed that the last instance of a variable in an EnvVar block took precedence in the running container, so user-provided variables were rendered after the generated variables. As seen in helm/charts#18715, Kubernetes' behavior in this scenario is actually undefined: some providers give precedence to the first variable instance in the block. As discussed in kubernetes/kubernetes#59593, providing duplicate variable definitions should not actually be permitted at all. However, per kubernetes/kubernetes#64841, fixing this (i.e. rejecting configurations that include multiple definitions of a variable) is fairly difficult, and Kubernetes will continue to accept multiple instances of a variable going forward.

At present, I believe we should actually reverse our current precedence order: there should not be many cases where it makes sense for users to override generated values (if there are, we should consider those bugs in the value generators and fix them), and overriding values can break the deployment in unexpected ways (e.g. providing your own KONG_ADMIN_LISTEN directly will typically result in the generated admin API Service not matching the listen in the container/blocking admin API access). We could, if necessary, add an additional dictionary that looks for special override values in env (e.g. instead of admin_listen, override_admin_listen) and give it final precedence. However, in the spirit of the original intent of the old template, the new template gives all user variables precedence.

The new template relies on a magic string: if a value contains "valueFrom", it is passed to a different case in the render loop to generate a secretKeyRef block (effectively, dump the string as-is). This is necessary because values in a dictionary are always strings, and cannot be detected by the existing if eq $valueType "map[string]interface {}" case. We furthermore cannot handle these like plain variable values, as those are passed to quote, which mangles the valueFrom block. While this is imperfect, I think it's reasonable, as at present (K8S API version 1.17), valueFrom is the only multi-line block suppported by the EnvVar specification.

Checklist

[Place an '[x]' (no spaces) in all applicable fields. Please remove unrelated fields.]

• Chart Version bumped
• Variables are documented in the README.md

[hbagdi]

This is amazing work. I tested locally a bit and it is pretty neat.

[hbagdi]

Can you fix the conflicts and we will be good to go?

[hbagdi]

@rainest Thank you for this fix. Your persistence and hard-work is truly inspiring!