2016-09-23 22:40:21 +00:00
|
|
|
---
|
2016-12-15 20:16:54 +00:00
|
|
|
title: Annotations
|
2018-05-05 16:00:51 +00:00
|
|
|
content_template: templates/concept
|
2018-06-06 23:51:26 +00:00
|
|
|
weight: 50
|
2016-09-23 22:40:21 +00:00
|
|
|
---
|
|
|
|
|
2018-05-05 16:00:51 +00:00
|
|
|
{{% capture overview %}}
|
2016-09-23 22:40:21 +00:00
|
|
|
You can use Kubernetes annotations to attach arbitrary non-identifying metadata
|
|
|
|
to objects. Clients such as tools and libraries can retrieve this metadata.
|
2018-05-05 16:00:51 +00:00
|
|
|
{{% /capture %}}
|
2016-09-23 22:40:21 +00:00
|
|
|
|
2018-05-05 16:00:51 +00:00
|
|
|
{{% capture body %}}
|
2017-01-18 18:18:37 +00:00
|
|
|
## Attaching metadata to objects
|
2016-09-23 22:40:21 +00:00
|
|
|
|
|
|
|
You can use either labels or annotations to attach metadata to Kubernetes
|
|
|
|
objects. Labels can be used to select objects and to find
|
|
|
|
collections of objects that satisfy certain conditions. In contrast, annotations
|
|
|
|
are not used to identify and select objects. The metadata
|
|
|
|
in an annotation can be small or large, structured or unstructured, and can
|
|
|
|
include characters not permitted by labels.
|
|
|
|
|
|
|
|
Annotations, like labels, are key/value maps:
|
|
|
|
|
2018-04-16 16:33:58 +00:00
|
|
|
```json
|
|
|
|
"metadata": {
|
|
|
|
"annotations": {
|
|
|
|
"key1" : "value1",
|
|
|
|
"key2" : "value2"
|
|
|
|
}
|
|
|
|
}
|
|
|
|
```
|
2016-09-23 22:40:21 +00:00
|
|
|
|
|
|
|
Here are some examples of information that could be recorded in annotations:
|
|
|
|
|
|
|
|
* Fields managed by a declarative configuration layer. Attaching these fields
|
|
|
|
as annotations distinguishes them from default values set by clients or
|
|
|
|
servers, and from auto-generated fields and fields set by
|
|
|
|
auto-sizing or auto-scaling systems.
|
|
|
|
|
|
|
|
* Build, release, or image information like timestamps, release IDs, git branch,
|
|
|
|
PR numbers, image hashes, and registry address.
|
|
|
|
|
|
|
|
* Pointers to logging, monitoring, analytics, or audit repositories.
|
|
|
|
|
|
|
|
* Client library or tool information that can be used for debugging purposes:
|
|
|
|
for example, name, version, and build information.
|
|
|
|
|
|
|
|
* User or tool/system provenance information, such as URLs of related objects
|
|
|
|
from other ecosystem components.
|
|
|
|
|
|
|
|
* Lightweight rollout tool metadata: for example, config or checkpoints.
|
|
|
|
|
|
|
|
* Phone or pager numbers of persons responsible, or directory entries that
|
|
|
|
specify where that information can be found, such as a team web site.
|
|
|
|
|
2017-04-07 18:08:47 +00:00
|
|
|
Instead of using annotations, you could store this type of information in an
|
2016-09-23 22:40:21 +00:00
|
|
|
external database or directory, but that would make it much harder to produce
|
|
|
|
shared client libraries and tools for deployment, management, introspection,
|
|
|
|
and the like.
|
|
|
|
|
2018-05-05 16:00:51 +00:00
|
|
|
{{% /capture %}}
|
2016-09-23 22:40:21 +00:00
|
|
|
|
2018-05-05 16:00:51 +00:00
|
|
|
{{% capture whatsnext %}}
|
2017-09-26 01:43:26 +00:00
|
|
|
Learn more about [Labels and Selectors](/docs/concepts/overview/working-with-objects/labels/).
|
2018-05-05 16:00:51 +00:00
|
|
|
{{% /capture %}}
|
|
|
|
|
2016-09-23 22:40:21 +00:00
|
|
|
|