Discover the power of cloud cost intelligence
Give your team a better cost platform
Give engineering a cloud cost coach
Learn more about CloudZero and who we are
Learn more about CloudZero's pricing
Take a customized tour of CloudZero
Understand your cloud unit economics and measure cost per customer
Discover and monitor your real Kubernetes and container costs
Measure and monitor the unit metrics that matter most to your business
Allocate cost and gain cost visibility even if your tagging isn’t perfect
Identify and measure your software COGS
Decentralize cost decisions to your engineering teams
Automatically identify wasted spend, then proactively build cost-effective infrastructure
Discover the best cloud cost intelligence resources
Browse webinars, ebooks, press releases, and other helpful resourcesBlog
Discover the best cloud cost intelligence contentCase Studies
Learn how we’ve helped happy customers like SeatGeek, Drift, Remitly, and moreEvents
Check out our best upcoming and past eventsFree Cloud Cost Assessment
Gauge the health and maturity level of your cost management and optimization efforts
Discover how SeatGeek decoded its AWS bill and measures cost per customerRead customer story
Learn how Skyscanner decentralized cloud cost to their engineering teamsRead customer story
Learn how Malwarebytes measures cloud cost per productRead customer story
Learn how Remitly built an engineering culture of cost autonomyRead customer story
Discover how Ninjacat uses cloud cost intelligence to inform business decisionsRead customer story
Learn Smartbear optimized engineering use and inform go-to-market strategiesRead customer story
This guide covers Kubernetes labels and annotations in detail, the differences between the two, and best practices when using labels and annotations.
As a Kubernetes environment becomes more complex, it can become harder to manage. You can reduce that overwhelm by organizing your resources in a way that makes them easier to group, filter, and track.
You can do this by tagging your Kubernetes components. Kubernetes labels and annotations are two ways to accomplish this. Both are forms of Kubernetes metadata. Not sure what that is and how annotations and labels differ?
Here’s a straightforward guide to understanding Kubernetes (K8s) labels and annotations, including:
Table Of Contents
Kubernetes annotations are a type of metadata that you attach to your Kubernetes objects, such as ReplicaSets and Pods. In particular, annotations are key-value maps.
Annotations let you organize your application into sets of attributes that correspond to how you think about that application. You can organize, label, and cross-index each Kubernetes resource to reflect the groups that make sense for your use case.
Annotations attach extra metadata to an object, but you cannot use that data to select an object. That’s because this metadata is non-identifying, meaning it is not necessarily meant to identify an object in Kubernetes. Yet, clients, including libraries and tools, can make use of this data.
Depending on the annotation, metadata can be large or small, structured or unstructured, and can contain diverse characters — in fact, more than are permitted by Kubernetes labels (more on this in the next section).
Now, picture this:
Credit: Strings in Kubernetes keys and values
Kubernetes annotations must meet the following characteristics and syntax requirements:
Want to see an example Kubernetes annotation? Here's a manifest for a Pod that has the annotation imageregistry: https://hub.docker.com/
The following are some examples of details you can record in annotations:
Now, here's the thing. An external database or directory could store this type of information instead of in an annotation. But then again, that would make it harder to build shared client libraries and other tools, such as for deployments and management.
Labels in Kubernetes are key-value pairs containing metadata and are used to identify objects. An object can have its own key-value labels. In addition, you can attach labels to a K8s object when creating it. You can then add or modify the label as needed over time.
You can use labels in a variety of ways, including:
Kubernetes labels must meet the following characteristics and syntax requirements:
Using the prefix enables you and automatic system components, such as kube-scheduler, as well as third-party tools, to manage resources.
The biggest difference between annotations and labels in Kubernetes is this: while labels attach identifying metadata to a K8s object, annotations attach additional information that is not identifying.
As you’ve probably already noticed in the definition sections previously, there are several other differences, including the number of characters an annotation can have vs. a label and use cases.
But just to recap, here’s a quick side-by-side comparison of Kubernetes labels vs. annotations:
Primary use case
Attach identifying metadata to objects. Help select, group, or filter Kubernetes objects
Hold non-identifying metadata that third-party tools and clients can retrieve
Short and unstructured
Short, long, structured, and unstructured
Used in operating?
Character set and syntax
Both the name (up to 63 characters long) and prefix (up to 253 characters long) are required
Name is required and must be 63 characters or less.
Prefix is optional
By labeling or annotating your Kubernetes resources, you can keep track of specific components in your rapidly expanding K8s environment.
If you want to select, group, or filter specific K8s objects, you can use labels. You can also use annotations to provide more information about a particular object.
However, this is not always the case, particularly if you miss a couple of crucial best practices for tagging.
Below is a quick list of Kubernetes annotations and labels best practices to always keep in mind when tagging your K8s components.
Tags and tag management can be endless, complicated, and tedious. Yet, if your cost allocation tags aren't perfect, it's hard to figure out who, what, and why your Kubernetes costs are changing. Well, not if you've got CloudZero.
If your labels and annotations aren't perfect, we get it. So we built CloudZero from scratch to deliver accurate and actionable Kubernetes cost intelligence. With CloudZero, you can collect cost data from tagged, untagged, and untaggable Kubernetes resources hassle-free.
Besides breaking down your Kubernetes costs by individual customer, team, product, feature, and more granularity, CloudZero also delivers your cost insights by various K8s concepts, such as per pod, cluster, namespace, environment, service, etc, — down to the hour.
And did we mention that tags are not required?
Cody Slingerland, a FinOps certified practitioner, is an avid content creator with over 10 years of experience creating content for SaaS and technology companies. Cody collaborates with internal team members and subject matter experts to create expert-written content on the CloudZero blog.
CloudZero is the only solution that enables you to allocate 100% of your spend in hours — so you can align everyone around cost dimensions that matter to your business.