DOC-328: Rename K8s/EKS config variables to cloud-agnostic names#745
DOC-328: Rename K8s/EKS config variables to cloud-agnostic names#745alexrashed wants to merge 2 commits into
Conversation
The Kubernetes runtime configuration variables were renamed to cloud-agnostic names (K8S_*, K3S_*, K3D_*) in localstack-pro#7642, since they are shared across all services that run workloads on Kubernetes (EKS, Lambda, ECS, ...). Update the config reference and Kubernetes guides to the new names, note the deprecated aliases, and document the CLI v1 LOCALSTACK_-prefix behaviour. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Deploying localstack-docs with
|
| Latest commit: |
83f978e
|
| Status: | ✅ Deploy successful! |
| Preview URL: | https://27f35b9c.localstack-docs.pages.dev |
| Branch Preview URL: | https://rename-k8s-eks-config-vars.localstack-docs.pages.dev |
alexrashed
changed the title
alexrashed
changed the title
alexrashed
requested review from
HarshCasper,
nik-localstack,
pinzon,
quetzalliwrites and
remotesynth
as code owners
| The Kubernetes runtime configuration variables were renamed to cloud-agnostic names (`K8S_*`, `K3S_*`, `K3D_*`) since they are shared across all services that run workloads on Kubernetes (EKS, Lambda, ECS, …). The previous `EKS_*`, `LOCALSTACK_K8S_*`, and `LAMBDA_K8S_*` names still work as deprecated aliases and will be removed in a future release. | ||
|
|
||
| If you configure these options through the LocalStack CLI **v1**, keep the `LOCALSTACK_` prefix on the new names (e.g. `LOCALSTACK_K8S_PROVIDER`). The CLI v1 only forwards host environment variables prefixed with `LOCALSTACK_` into the container, where the prefix is stripped to yield the in-container variable (`K8S_PROVIDER`). |
There was a problem hiding this comment.
Sorry for insisting on this, but the wording here is not correct IMO.
We need to separate the Kubernetes runtime configuration variables (used in Lambda, ECS, Batch, RDS, .....) with the EKS configuration variables (which are the ones mentioned in the table above).
Maybe we can say:
"The EKS configuration variables were renamed to cloud-agnostic names since they're shared across cloud emulators (AWS EKS / Azure AKS)"
There was a problem hiding this comment.
Thanks for the suggestion! I updated the sentence in the last commit :)
| | `EKS_K3S_IMAGE_REPOSITORY` | `rancher/k3s` (default) | Custom repository of the `rancher/k3s` image used to spin up Kubernetes clusters locally. | | ||
| | `EKS_START_K3D_LB_INGRESS` | `0` (default) | Whether to start the k3d load balancer and Traefik ingress controller automatically when creating an EKS cluster. Set to `1` to enable. | | ||
| | `K3S_IMAGE_TAG` | `v1.31.5-k3s1` (default) | Custom tag of the `rancher/k3s` image used to spin up Kubernetes clusters locally. (formerly `EKS_K3S_IMAGE_TAG`, still accepted as a deprecated alias) | | ||
| | `K8S_PROVIDER` | `k3s` (default)\|`local` | The k8s provider which should be used to start the k8s cluster backing EKS. For more information on the providers, please see [Elastic Kubernetes Service (EKS)](/aws/services/eks) (formerly `EKS_K8S_PROVIDER`, still accepted as a deprecated alias) | |
There was a problem hiding this comment.
Something I just noticed is that this env var is no longer prefixed with EKS and it may be mixed with the rest of the K8S_* env vars which are related to the kubernetes executor. Sorry for the late observation but would it make sense to bring the EKS prefix back ? Or rename it to something different ?
There was a problem hiding this comment.
This one is not EKS specific, it is also used by AKS for example. So I actually feel like this is the right name for the variable? Otherwise it would be great if you could propose an explicit alternative name which is in line with the generic usage of the variable across cloud emulators now...
There was a problem hiding this comment.
Well naming is hard, but I would prefer to avoid the K8S_* prefix for consistency.
wdyt about MANAGED_K8S_PROVIDER ?
btw the same stands for K8S_STARTUP_TIMEOUT. It's related to EKS/AKS but from the prefix it reads like it's something related to the Kubernetes executor / runtime.
Not a blocker though, I just raised it because it seems confusing to me.
2 participants
Motivation
The Kubernetes configuration variables have been renamed to cloud-agnostic names so they apply consistently across both (a) all emulated services that run workloads on Kubernetes (Lambda, ECS, …) and (b) services that run Kubernetes clusters (AWS EKS, Azure AKS). This updates the docs to match.
Changes
aws/configuration/config/configuration.md): renamed the six affected EKS variables in the table, each annotated with its former name as a deprecated alias, and added a note explaining the rename + the CLI v1LOCALSTACK_-prefix behaviour.EKS_LOADBALANCER_PORTandEKS_PERSIST_CLUSTER_CONTENTSare left as-is — they remain AWS/EKS-specific and were not renamed.aws/services/eks.mdx) and Kubernetes enterprise guides (kubernetes-executor.md,pod-configuration.md,configuration.md): updated prose and examples to the new names.LOCALSTACK_K8S_NAMESPACEK8S_NAMESPACELOCALSTACK_K8S_LABELS/LAMBDA_K8S_LABELSK8S_LABELSLOCALSTACK_K8S_ANNOTATIONSK8S_ANNOTATIONSLOCALSTACK_K8S_POD_CONFIGK8S_POD_CONFIGLAMBDA_K8S_SECURITY_CONTEXTK8S_CONTAINER_SECURITY_CONTEXTEKS_K8S_PROVIDERK8S_PROVIDEREKS_STARTUP_TIMEOUTK8S_STARTUP_TIMEOUTEKS_K3S_IMAGE_REPOSITORYK3S_IMAGE_REPOSITORYEKS_K3S_IMAGE_TAGK3S_IMAGE_TAGEKS_K3S_FLAGSK3S_FLAGSEKS_K3D_CLUSTER_TOKENK3D_CLUSTER_TOKENEKS_K3D_VERSIONK3D_VERSIONEKS_START_K3D_LB_INGRESSK3D_START_LB_INGRESSThe old names continue to work as deprecated fallbacks and emit a warning at startup.
Fixes DOC-328
🤖 Generated with Claude Code