Naming individual nodes (of node pool)

First, I understand the notion of a node pool is cloud-specific - I come from the Azure Kubernetes Services (AKS) world, where I’ve started to learn Kubernetes world, not too long ago. So, I’m using AKS and I sense my problem may be AKS-specific, for example, notion of “node pool”, which does not exist in plain Kubernetes. However, I would also like to understand the cloud-agnostic behaviour of Kubernetes w.r.t. to naming individual nodes.

I’m looking into ways of assigning pods to nodes, especially, the direct form of node selection using nodeName.

TL;TR: What is the recommended way to set Node with user-defined name value?


The docs on Nodes explains that a new node is created from manifest

  "kind": "Node",
  "apiVersion": "v1",
  "metadata": {
    "name": "",
    "labels": {
      "name": "my-first-k8s-node"

Is my understanding correct below, that:

  • if I use plain/self-hosted Kubernetes, I can freely set the value of the name
  • if I use a managed Kubernetes (e.g. AKS), then the platform/service creates the manifest on my behalf, following my request (e.g. via or using Terraform), and the service intermediary generates the value for the name?
  • if I use a managed Kubernetes, then it is specific to particular platform if it provides users with any mean to influence the value of the name of Node.

am I correct?

Platform-specific (Azure Kubernetes Services)

Here is a bit of (pseudo/incomplete) Terraform code which requests AKS to create a pool of 1-3 nodes:

resource "azurerm_kubernetes_cluster_node_pool" "npwin1" {
  name                = "npwin1"    # can be set by user
  node_count          = 1
  min_count           = 1
  max_count           = 3
  node_labels = {
    "nodepool-os"     = "windows"
    "environment"     = "dev"
  tags = {
    "nodepool-os"     = "windows"
    "environment"     = "dev"

Alternatively, user can issue the same request via CLI, for example:

az aks nodepool add ... \
  --name npwin1 --node-count 1 --min-count 1 --max-count 3 --os-type Windows

Now, AFAIU, the managed Kubernetes platform like AKS takes such request as a blueprint to generate the Kubernetes manifest of "kind": "Node"’ for number of requested nodes. In other words, from there the platform takes it over and does whatever it needs to do to create requested nodes.

In consequence, AFAIU, once the request has been issued, then the platform user has no influence on the final shape of individual nodes. Namely, there is no mean to tell the platform what value of name property to set the nodes with.

Well, as per the third bullet point above, existence of any means to affect the name is platform-specific.
Some platforms may promise predictable (e.g. counted) naming convention for nodes or allow user to specify a generator for user-specific names. However, AFAICT, there seem to be no such mean in case of the Azure Kubernetes Services.


Moving back to the plain Kubernetes, it looks to me that availability of the Kubernetes feature of assigning pods to nodes using the nodeName is specific to the way a user hosts Kubernetes service, specific to the managed Kubernetes platform features. And, in case of the AKS, the use of nodeName is not available.

Is my earlier understanding and final conclusion correct or am I missing anything?

Cluster information:

Kubernetes version: 1.25.5
Cloud being used: AKS
Installation method: AKS

Your best simple way is using labels, But affinity/antiaffinity way will give you more benefits, check this.

There are a bunch of places in code that seem to assume that the node name and the name of the VM behind it are the same.

There’s nothing at all special about the name, it’s just a string with some format rules, and whomever creates the VM can choose the name.

NodeName as a feature is how the scheduler works, so it’s safe to assume that is not platform-specific.

Thank you both @felixdpg and @thockin for the answers.

The problem with using or relying on node name is that it is unknown when one uses node pools like on AKS. AFAIK, I can only specify name of a node pool like npl1 below, but names of individual nodes are automatically generated:

$ k get nodes
NAME                              STATUS   ROLES   AGE     VERSION
aks-default-37242843-vmss000000   Ready    agent   19d     v1.25.5
aks-npl1-66531061-vmss000000      Ready    agent   8d      v1.25.5
aks-npl1-66531061-vmss000001      Ready    agent   8d      v1.25.5
aks-npl1-66531061-vmss000002      Ready    agent   4d20h   v1.25.5

This means, it is not possible to apply the pod to node allocation based on selecting node by name.

In general you shouldn’t do that anyway.

Nodes can come and go over time - don’t rely on their names. Use a nodeSelector or use taints/tolerations.

1 Like

@thockin Yes, this is a very good piece of advice.

I’m learning and the Kubernetes docs explains the feature of selecting node by name, so it raised my questions. However, I understand there is also the issue of available set of features vs best practices.

nodeName exists so that schedulers can be written. If we were designing that today, we might have done it differently, but it is what it is now. The fact that it is part of the user-available API surface doesn’t mean it’s the best way to do anything in particular except the act of scheduling.


1 Like