chore: Merge KAS and Redis charts into Console chart

[maciaszczykm]

Fixes PROD-4288 too.

Test Plan

Deployed on plrl-dev-aws.

Checklist

• If required, I have updated the Plural documentation accordingly.
• I have added tests to cover my changes.
• I have added a meaningful title and summary to convey the impact of this PR to a user.

Plural Flow: console

[linear]

PROD-4459 all codebases should have docker-compose files capable of building and also executing tests

PROD-4288 kas consolidation cleanup

[greptile-apps]

Greptile Summary

This PR consolidates the separate KAS and Redis Helm charts into the console chart by inlining all KAS templates directly under charts/console/templates/kas/ and embedding a simplified standalone-mode Bitnami Redis chart under charts/console/templates/kas/redis/. The chart-dependencies/redis source directory and the charts/kas subchart dependency are removed. A dedicated redis.fullname helper ({release}-redis) correctly scopes all Redis resource names, resolving the previous concern about name ambiguity.

Key changes:

• KAS templates (deployment, service, ingress, HPA, configmap, serviceaccount, servicemonitor, secrets) moved directly into charts/console/templates/kas/
• Full Bitnami Redis standalone templates inlined under charts/console/templates/kas/redis/ with values scoped under kas.redis.*
• bitnami/common added as a direct chart dependency to provide shared helpers
• replicCount → replicaCount rename (breaking for existing value overrides)
• console-kas-service hardcoded string references in ingress.yaml replaced with kas.serviceName helper
• The api sidecar container in the KAS deployment hardcodes the resource name console-env, which will fail if the Helm release is not named console
• When kas.redis.networkPolicy.allowExternal is set to false, KAS pods cannot connect to Redis unless they carry the {redis.fullname}-client: "true" label, which the chart does not add automatically

Confidence Score: 3/5

• Safe to merge for the standard console release name, but the hardcoded console-env reference is a latent bug for non-default release names, and the network policy tightening gap could silently break KAS-to-Redis connectivity.
• The chart consolidation is well-structured and the core templating logic is sound. The Redis fullname helper correctly scopes resources, and the StatefulSet volumeClaimTemplates nesting is correct. The deployment verification on plrl-dev-aws covers the happy path. Score is reduced because (1) the hardcoded console-env reference in the api sidecar will break any installation where the Helm release is not named exactly console, (2) the network policy client-label gap creates a silent operational risk when allowExternal is tightened, and (3) several {{ if }} blocks without trim markers introduce formatting noise that could fail strict validators.
• Pay close attention to charts/console/templates/kas/deployment.yaml (hardcoded resource name and untrimmed template blocks) and charts/console/templates/kas/redis/networkpolicy.yaml (missing KAS client label).

Important Files Changed

Filename	Overview
charts/console/templates/kas/redis/_helpers.tpl	New dedicated redis.fullname helper using console.fullname + -redis suffix (correctly caps at 63 chars). Properly scoped redis.secretName, redis.password, and TLS helpers. The redis.password helper mutates .Values.kas.redis.global.redis to propagate the resolved password — standard Bitnami pattern that works correctly.
charts/console/templates/kas/deployment.yaml	New KAS deployment template. Correctly includes initContainers key, projected volume with Redis secret at redis_server_secret, and dual-container (kas + api) spec. However, several {{ if }} blocks lack trim markers ({{- }}) causing extra blank lines in the rendered YAML, and the api container hardcodes the console-env secret name.
charts/console/templates/kas/configmap.yaml	KAS config correctly references {release}-redis-master via the new redis.fullname helper, resolving the previous concern about ambiguous naming. Redis password_file path matches the volume mount path redis_server_secret in deployment.yaml.
charts/console/templates/kas/redis/master/application.yaml	Comprehensive Redis master StatefulSet/Deployment template ported from Bitnami. Correctly handles standalone mode with volumeClaimTemplates for StatefulSet and standalone PVC for Deployment. The YAML nesting of the volumes/volumeClaimTemplates sections is correct.
charts/console/values.yaml	kas section moved to bottom of file and fully expanded with all Redis sub-values inlined. replicCount renamed to replicaCount (breaking rename for any existing overrides). kas.secrets.redis: "" still present, which creates an orphaned bare-named Secret. No kas.enabled guard, but this was already the case before.
charts/console/templates/kas/secrets.yaml	Creates bare-named Kubernetes Secrets (api, privateapi, redis) without release-name prefixes. The redis key creates an empty Secret that is mounted but never read by KAS config (password comes from the embedded Bitnami Redis secret instead).
charts/console/Chart.yaml	kas dependency removed, common 2.34.0 dependency added to provide Bitnami common helpers for the inlined Redis templates. The comment explaining the version choice (closest to 2.33.2) is helpful.
charts/console/templates/ingress.yaml	Hardcoded console-kas-service references correctly replaced with kas.serviceName helper. Dynamic resolution now works regardless of release name.

Comments Outside Diff (1)

1. charts/console/templates/kas/deployment.yaml, line 253-262 (link)

   Hardcoded console-env resource name breaks non-default release names

   The api sidecar container references a Kubernetes resource named console-env by literal string for both KAS_HOST and CONSOLE_HOST. If the chart is installed with a release name other than console (e.g., helm install my-console ./charts/console), this hard-coded reference will fail at pod startup because the resource will not exist under that exact name.

   All other resources in the chart derive their names through the console.fullname helper. Consider using the same pattern here so the name resolves correctly regardless of release name:

   name: {{ include "console.fullname" . }}-env
   

   This should be applied to both secretKeyRef.name fields in the api container's env block.

_{Last reviewed commit: 642246f}

[maciaszczykm]

@greptileai

[maciaszczykm]

@greptileai

[maciaszczykm]

@greptileai

[maciaszczykm]

@greptileai

[greptile-apps]

allowExternal: true default means KAS pods must be explicitly labeled when tightened

The default kas.redis.networkPolicy.allowExternal: true permits any pod in the cluster to reach Redis. If an operator tightens this to false later, only pods labeled {{ redis.fullname }}-client: "true" are allowed in — but nothing in the chart adds that label to the KAS deployment pods. At that point KAS would be silently blocked from Redis.

Consider either documenting this label requirement in a comment in values.yaml, or adding the label to the KAS pod template when networkPolicy.allowExternal is false:

# In kas/deployment.yaml pod template labels:
{{- if and .Values.kas.redis.networkPolicy.enabled (not .Values.kas.redis.networkPolicy.allowExternal) }}
{{ include "redis.fullname" . }}-client: "true"
{{- end }}