K
Q

Understanding built-in Labels

5/12/2020

I'm new to kubernetes and I'm trying to understand how labels work on a node. We have eks server version 1.14 running in our organization. I'm trying to change built-in deprecated labels.

In aws-node daemonset, I want to replace beta.kubernetes.io/os to kubernetes.io/os and beta.kubernetes.io/arch to kubernetes.io/arch.

Since it both beta.kubernetes.io/arch and kubernetes.io/arch labels when i describe a node.

  • Is it safe to go ahead remove the beta.kubernetes.io/arch and beta.kubernetes.io/os labels?
  • I want to understand if I change the label, what are its effects?
  • Does Pods running on that node are affected?
  • Can apiVersion: apps/v1 change built-in labels?
  • Can I just run kubectl label node "node-name" beta.kubernetes.io/arch=amd64 - to remove the labels?

  • Is there a need to apply the daemonset ?

    kind: DaemonSet
apiVersion: apps/v1
metadata:
  name: aws-node
  namespace: kube-system
  labels:
    k8s-app: aws-node
spec:
  updateStrategy:
    type: RollingUpdate
  selector:
    matchLabels:
      k8s-app: aws-node
  template:
    metadata:
      labels:
        k8s-app: aws-node
    spec:
      priorityClassName: system-node-critical
      affinity:
        nodeAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
            nodeSelectorTerms:
              - matchExpressions:
                  - key: "beta.kubernetes.io/os"
                    operator: In
                    values:
                      - linux
                  - key: "beta.kubernetes.io/arch"
                    operator: In
                    values:
                      - amd64

    kubectl describe node/ip-10-xx-xx-xx.ec2.internal -n kube-system

    Labels:             beta.kubernetes.io/arch=amd64
                        beta.kubernetes.io/instance-type=c4.xlarge
                        beta.kubernetes.io/os=linux
                        failure-domain.beta.kubernetes.io/region=us-east-1
                        failure-domain.beta.kubernetes.io/zone=us-east-1a
                        group=nodes
                        kubernetes.io/arch=amd64
                        kubernetes.io/hostname=ip-10-182-32-156.ec2.internal
                        kubernetes.io/os=linux
-- user6826691
kubernetes

Similar Questions

"Request entity too large: limit is 3145728" when trying to update a k8s CR resource
containers with ipv6 addresses can't connect to outside in k8s/calico environment
How can take tcpdump of a NodePort of a NodePort service in Kubernetes cluster?
Kubernetes elasticserach health check fails - but only in some containers

1 Answer

5/13/2020

From the documentation we can read that beta.kubernetes.io/arch and beta.kubernetes.io/os are deprecated since version 1.14 (removed on version 1.18) and kubernetes.io should be used instead.

You are using version 1.14 and there is no reason for you to change/remove these labels. Changing them would add one more layer of complication to your cluster when you want to add a node for example (you have to always keep in mind that you have non-stock labels in your nodes).

  • Is it safe to go ahead remove the beta.kubernetes.io/arch and beta.kubernetes.io/os labels?

It's safe but unnecessary unless you have applications running on mixed clusters and you are using these labels.

  • I want to understand if I change the label, what are its effects?

From the documentation we can read:

kubernetes.io/arch: This can be handy if you are mixing arm and x86 nodes.

kubernetes.io/os: This can be handy if you are mixing operating systems in your cluster (for example: mixing Linux and Windows nodes).

So these labels are there for your convenience, you can use them to keep track of things.

  • Does Pods running on that node are affected?

No, pods are still going to be normally scheduled .

  • Can I just run kubectl label node "node-name" beta.kubernetes.io/arch=amd64 - to remove the labels?

To remove the label you can run:

kubectl label node "node-name" beta.kubernetes.io/arch-

To remove from all nodes:

kubectl label nodes --all beta.kubernetes.io/arch-
  • Is there a need to apply the daemonset ?

I particularly don't see a need for that.

-- mWatney
Source: StackOverflow