concepts/overview/working-with-objects/annotations/
You can use Kubernetes annotations to attach arbitrary non-identifying metadata to objects. Clients such as tools and libraries can retrieve this metadata 可以使用kubernetes註釋將任意非標識後設資料附加到物件。工具和庫等客戶端可以檢索此後設資料。
Attaching metadata to objects 將後設資料附加到物件
可以使用標籤或註釋將後設資料附加到kubernetes物件。標籤可用於選擇物件和查詢滿足特定條件的物件集合。相反，註釋不用於標識和選擇物件。註釋中的後設資料可以是小的或大的、結構化的或非結構化的，並且可以包含標籤不允許的字元。
註釋和標籤一樣，是鍵/值對映：
"metadata": {
"annotations": {
"key1" : "value1",
"key2" : "value2"
}
}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.
- Directives from the end-user to the implementations to modify behavior or engage non-standard features.
Instead of using annotations, you could store this type of information in an 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.
以下是一些可以記錄在註釋中的資訊示例：
-由宣告性配置層管理的欄位。將這些欄位附加為註釋可以將它們與客戶端或伺服器設定的預設值以及自動生成的欄位和由自動調整大小或自動縮放系統設定的欄位區分開來。
-生成、釋出或影像資訊，如時間戳、釋出ID、Git分支、PR編號、影像雜湊和登錄檔地址。
-指向日誌記錄、監視、分析或稽核儲存庫的指標。
-可用於除錯目的的客戶端庫或工具資訊：例如，名稱、版本和生成資訊。
-使用者或工具/系統來源資訊，例如來自其他生態系統元件的相關物件的url。
-輕量級卷展欄工具後設資料：例如，配置或檢查點。
-負責人的電話號碼或尋呼機號碼，或指定在哪裡可以找到該資訊的目錄項，例如團隊網站。
-從終端使用者到實現的指令，以修改行為或使用非標準功能。
與使用註釋不同，您可以將此類資訊儲存在外部資料庫或目錄中，但這將使生成用於部署、管理、內省等的共享客戶端庫和工具變得更加困難。
Syntax and character set
Annotations are key/value pairs. Valid annotation keys have two segments: an optional prefix and name, separated by a slash (/). The name segment is required and must be 63 characters or less, beginning and ending with an alphanumeric character ([a-z0-9A-Z]) with dashes (-), underscores (_), dots (.), and alphanumerics between. The prefix is optional. If specified, the prefix must be a DNS subdomain: a series of DNS labels separated by dots (.), not longer than 253 characters in total, followed by a slash (/).
If the prefix is omitted, the annotation Key is presumed to be private to the user. Automated system components (e.g. kube-scheduler, kube-controller-manager, kube-apiserver, kubectl, or other third-party automation) which add annotations to end-user objects must specify a prefix.
The kubernetes.io/ and k8s.io/ prefixes are reserved for Kubernetes core components.
For example, here’s the configuration file for a Pod that has the annotation imageregistry: https://hub.docker.com/ :
註釋是鍵/值對。有效的註釋鍵有兩個段：可選的字首和名稱，用斜線（/）分隔。名稱段是必需的，必須不超過63個字元，以字母數字字元（[A-Z0-9A-Z]）開頭和結尾，中間有破折號（-）、下劃線（u）、點（.）和字母數字。字首是可選的。如果指定，字首必須是DNS子域：由點（.）分隔的一系列DNS標籤，總共不超過253個字元，後跟斜槓（/）。
如果省略字首，則註釋鍵被假定為使用者專用。向終端使用者物件新增註釋的自動化系統元件（例如kube排程器、kube控制器管理器、kube apiserver、kubectl或其他第三方自動化）必須指定字首。
kubernetes.io/和k8s.io/字首是為kubernetes核心元件保留的。
例如，下面是一個pod的配置檔案，其中包含註釋imageregistry:https://hub.docker.com/：
apiVersion: v1
kind: Pod
metadata:
name: annotations-demo
annotations:
imageregistry: "https://hub.docker.com/"
spec:
containers:
- name: nginx
image: nginx:1.7.9
ports:
- containerPort: 80
What's next
Learn more about Labels and Selectors.
本作品採用《CC 協議》，轉載必須註明作者和本文連結