Is Kubernetes cluster name available to chart templates?

[mcandre]

Is there a way for a chart to become aware of the Kubernetes cluster name, for tagging purposes?

[technosophos]

Good idea. I'm trying to find where we can get this from the Kubernetes API.

[tback]

Opened a feature request in kubernetes: kubernetes/kubernetes#44954

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

Prevent issues from auto-closing with an /lifecycle frozen comment.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or @fejta.
/lifecycle stale

[fejta-bot]

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or @fejta.
/lifecycle rotten
/remove-lifecycle stale

[naphthalene]

/remove-lifecycle rotten

This is something that's really nice to have when doing hostname based ingress + external-dns with a single Route53 zone and <svc>.<namespace>.<cluster>.domain.com.

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

[ivandov]

Any updates or workarounds here?

[bacongobbler]

This issue was labeled as a wontfix on kubernetes' side, so there will not be a way to identify the name of the kubernetes cluster through the API.

However, perhaps there may be a way to fetch the name of the current context we are using from ~/.kube/config to connect to the cluster and supply that to the template engine. It's not the same (since everyone can have different names for the same cluster in their own ~/.kube/config) but is that "close enough" to what users are asking for?

[bacongobbler]

a similar ticket with some background context: #2613

[fejta-bot]

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle rotten
/remove-lifecycle stale

[nikhita]

/remove-lifecycle rotten

[nikhita]

/remove-lifecycle rotten

[bacongobbler]

we've moved out of the kubernetes org so the stale bot is no longer active. :)

[nikhita]

we've moved out of the kubernetes org so the stale bot is no longer active. :)

@bacongobbler Haha, I figured. :)

Btw a quick GitHub search shows that there are many issues with lifecycle/* labels. I think it would helpful if the rotten or stale labels were removed, just to avoid confusion. :)

[odinsy]

There is one way with yq itlity

kubectl -n kube-system get configmap kubeadm-config -o jsonpath={.data.ClusterConfiguration} | yq r - clusterName

[bacongobbler]

I guess that's only possible with clusters spawned with kubeadm, right? That command looks at the cluster name provided when kubeadm created the cluster.

In any case, that should be helpful for a small subset of users. Nice trick. 👍

[sgandon]

The coredns config map seems to be holding the value

>k get cm coredns -n kube-system -oyaml
apiVersion: v1
data:
  Corefile: |
    .:53 {
        errors
        health
        kubernetes cluster.local in-addr.arpa ip6.arpa {
          pods insecure
          upstream
          fallthrough in-addr.arpa ip6.arpa
        }
        prometheus :9153
        proxy . /etc/resolv.conf
        cache 30
        loop
        reload
        loadbalance
    }
kind: ConfigMap
metadata:
  annotations:
    kubectl.kubernetes.io/last-applied-configuration: |
      {"apiVersion":"v1","data":{"Corefile":".:53 {\n    errors\n    health\n    kubernetes cluster.local in-addr.arpa ip6.arpa {\n      pods insecure\n      upstream\n      fallthrough in-addr.arpa ip6.arpa\n    }\n    prometheus :9153\n    proxy . /etc/resolv.conf\n    cache 30\n    loop\n    reload\n    loadbalance\n}\n"},"kind":"ConfigMap","metadata":{"annotations":{},"labels":{"eks.amazonaws.com/component":"coredns","k8s-app":"kube-dns"},"name":"coredns","namespace":"kube-system"}}
  creationTimestamp: "2019-06-14T14:03:02Z"
  labels:
    eks.amazonaws.com/component: coredns
    k8s-app: kube-dns
  name: coredns
  namespace: kube-system
  resourceVersion: "47"
  selfLink: /api/v1/namespaces/kube-system/configmaps/coredns

[josh9191]

Any updates on the issue?

[katsew]

Any updates on this issue?

I made the feature request, but this issue is discussing the same thing, so my issue was closed.

My idea is as the same as this comment

[github-actions]

This issue has been marked as stale because it has been open for 90 days with no activity. This thread will be automatically closed in 30 days if no further activity occurs.

[tetchel]

This was closed as stale, but the community still wants it. It was even added to a milestone.

Can it be re-opened?

I'd love to be able to reference the cluster domain in my ingress host rather than needing the user to pass it as a value.

[jmuleiro]

Seconded. My use case is getting the cluster name for a Job that creates objects on buckets to use as path.

[dwerder]

It would be nice if this can be implemented

[MariaPaypoint]

We are waiting for this

[bacongobbler]

Repeating what I mentioned earlier...

This issue was labeled as a wontfix on Kubernetes' side. To answer the original question:

Is Kubernetes cluster name available to chart templates?

No, because Kubernetes has no concept of a "cluster name". We cannot support something that does not exist.

Your best bet would be to provide a custom clusterName value in your templates, which you can choose to override by passing kubectl config current-context as input either via --set or --values.

Helm cannot provide the current context's name as part of helm install or helm upgrade's built-in objects because one user could set their current context with the name "myCluster" and another user could use "default", which means upgrades and installs are nondeterministic from one upgrade to the next. This also does not work with users who use an in-cluster service account to authenticate with the Kubernetes cluster because there's no concept of a "current context".

If you can convince the Kubernetes authors to implement a "cluster ID" or a "cluster name" that can uniquely identify a cluster, we'd accept PRs to add that to Helm's built-in objects.

[GounGG]

I believe that everyone performs update operations on a similar publishing machine. This .kube/config will configure a lot of cluster information. I need to get the name of the context I am currently using to judge whether I need to do differential deployment. This should belong to a very common requirement.

[jeffWelling]

Posting this in case it saves other folks some time.

One solution that I've seen work is, if you're using terraform to create the cluster, then use terraform to create a configmap containing the name of the cluster, and then read the configmap value from helm.

[imperialguy]

How about cluster ID? Can I read cluster ID using helm and pass it to (say) a pod?

[emmeowzing]

I want this feature, also.

[joejulian]

If you really want to have some unique piece of info, use lookup and grab the uuid of the default namespace. This is the closest thing you're going to have to finding a unique id for a kubernetes cluster.

[maximveksler]

If you really want to have some unique piece of info, use lookup and grab the uuid of the default namespace. This is the closest thing you're going to have to finding a unique id for a kubernetes cluster.

That's an interesting workaround. ty.

[joeloplot]

kubectl config current-context | cut -f2 -d/ is the name of the cluster, surely?
Whether or not it's unique, I mean.

[joeloplot]

Sure, I understand that. But why is that a bad name to use? If the local context isn’t configured, there’s no server to talk to. Using the name the user gives that context (or the ‘default’ default value) seems fine to me. Is there some reason it needs to be globally unique?

…

On 10. Jul 2023, at 16:26, Till Backhaus ***@***.***> wrote: No, it's what _you_ call it. It's stored in your kubeconfig. There is no cluster name. A couple of workarounds exist that come close. On Mon, 10 Jul 2023, 13:27 joeloplot, ***@***.***> wrote: > kubectl config current-context | cut -f2 -d/ is the name of the cluster, > surely? > > — > Reply to this email directly, view it on GitHub > <#2055 (comment)>, or > unsubscribe > <https://github.com/notifications/unsubscribe-auth/AAAUL2GA2SWRY27AWSXKYNTXPPRIHANCNFSM4DCFKE3A> > . > You are receiving this because you commented.Message ID: > ***@***.***> > — Reply to this email directly, view it on GitHub <#2055 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/A7DMX4AOLQKB3BKJLS6YGNDXPQGIFANCNFSM4DCFKE3A>. You are receiving this because you commented.

-- <http://holoplot.com/?utm_source=email&utm_medium=sg&utm_campaign=Holoplot_Signature+> *HOLOPLOT GmbH - Headquarters* Ringbahnstr. 12 (10-14) / A2 12099 Berlin, Germany +49 (0) 30 40745812 *HOLOPLOT GmbH - Manufacturing* Alboinstr. 17-23 / Hall 12 12103 Berlin, Germany +49 (0) 30 959988740 www.holoplot.com <https://holoplot.com/> Follow us on <https://www.facebook.com/OriginalHOLOPLOT/?utm_source=email&utm_medium=sg&utm_campaign=Holoplot_Signature+> LinkedIn <https://www.linkedin.com/company/holoplot-gmbh?utm_source=email&utm_medium=sg&utm_campaign=Holoplot_Signature+>. Roman Sick – CEO | HRB183974B, Register Court Charlottenburg, Germany | EU Tax-Registration No. DE277000701 This e-mail contains confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the information in this e-mail is strictly forbidden.

[tback]

That depends on your use case.
Relying on kubeconfig make the code dependant on which host it is executed on. This is a pattern that many people try to avoid.

[joeloplot]

Oh yes, this makes sense. I appreciate the explanation, thank you.

…

On 10. Jul 2023, at 21:41, Till Backhaus ***@***.***> wrote: That depends on your use case. Relying on kubeconfig make the code dependant on which host it is executed on. This is a pattern that many people try to avoid. — Reply to this email directly, view it on GitHub <#2055 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/A7DMX4AANBLRJSRNZGEPR5TXPRLFDANCNFSM4DCFKE3A>. You are receiving this because you commented.

-- <http://holoplot.com/?utm_source=email&utm_medium=sg&utm_campaign=Holoplot_Signature+> *HOLOPLOT GmbH - Headquarters* Ringbahnstr. 12 (10-14) / A2 12099 Berlin, Germany +49 (0) 30 40745812 *HOLOPLOT GmbH - Manufacturing* Alboinstr. 17-23 / Hall 12 12103 Berlin, Germany +49 (0) 30 959988740 www.holoplot.com <https://holoplot.com/> Follow us on <https://www.facebook.com/OriginalHOLOPLOT/?utm_source=email&utm_medium=sg&utm_campaign=Holoplot_Signature+> LinkedIn <https://www.linkedin.com/company/holoplot-gmbh?utm_source=email&utm_medium=sg&utm_campaign=Holoplot_Signature+>. Roman Sick – CEO | HRB183974B, Register Court Charlottenburg, Germany | EU Tax-Registration No. DE277000701 This e-mail contains confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the information in this e-mail is strictly forbidden.

[pkazi]

For AWS EKS Specific, we can get it via user-data, Run below from pod with ec2 instance metadata access available -

curl -s http://169.254.169.254/latest/user-data | grep /etc/eks/bootstrap.sh | awk '{print $2}'