Kubernetes注解示例-Kubernetes注解场景（9）

本文是Kubernetes权威指南系列的一部分，你可以点击Kubernetes权威指南查看所有教程

Kubernetes 注解

注解用于向 Kubernetes 对象添加额外的元数据，这些元数据是非识别性的，这意味着我们不能使用选择器来查询附加了特定注解的 Kubernetes 对象。简单来说，注解不是用来识别和选择 Kubernetes 对象的。任何 Kubernetes 组件都不会使用注解来对集群执行任何操作或任何操作。注解可以是结构化的或非结构化的，也可以是大的或小的。我们可以在注解中包含元数据，其中包含标签中不允许的字符。它提供了有关工具和库可以使用的 Kubernetes 对象的附加信息。注解对 Kubernetes 本身没有帮助，但它为用户、人们、或与 Kubernetes 对象交互的工具，因为它包含有用的信息，以便人们可以正确理解对象并明智地采取行动。例如，添加负责人的寻呼机信息，知识库文章的链接等。

Kubernetes 中的注解是如何工作的？

注解具有与标签相同的键/值对。注解键由两部分组成，一个是可选的前缀，一个名称。这两部分由斜线“/”分隔。名称部分是强制性的，不超过 63 个字符。它以字母数字字符 ([a-z0-9A-Z]) 开头和结尾，中间有破折号 (-)、下划线 (_)、点 (.) 和字母数字。前缀是可选的，但是如果指定，它必须是 DNS 子域，长度必须为 253 个字符或更少，并以斜杠 (/) 结尾 如果自动化系统组件，如 kube-controller-manager、kube-scheduler、kube-apiserver、kubectl或任何其他第三方自动化）向最终用户 Kubernetes 对象添加注解，它必须指定前缀。Kubernetes 核心组件有两个保留的前缀“kubernetes.io/”和“k8s.io/”。

我们使用“annotations”关键字为对象添加注解。注解也是像标签一样的键/值对，如下所示：

“metadata”: {
“annotations”: {
“key1” : “value1”,
“key2” :  “value2”,
“key3” : “value3”
}
}

Kubernetes 注解示例

让我们了解 Kubernetes Annotations with Syntax 的示例。

示例 1

我们有一个 nginx pod，我们想附加注解，如待命人员寻呼机号码、图像注册表的 URL 或名称以及知识库文章的链接等。我们可以在元数据原语下的注解下添加这些详细信息。无论我们是否将注解附加到 Kubernetes 对象，“kubectl”都会为每个 Kubernetes 对象附加默认注解。这个注解是“kubectl.kubernetes.io/last-applied-configuration”。让我们使用下面的 yaml 文件创建一个 pod。

apiVersion: v1
kind: Pod
metadata:
name: nginx-web-server
labels:
env: prod
app: nginx-web
spec:
containers:
- name: nginx
image: nginx
ports:
- containerPort: 80

创建 pod 后，我们使用以下两个命令来检查附加的注解：

语法：

$kubectl describe <object_type> <object_name>

$kubectl get <object_type> <object_name> -o custom-columns=<custom_column_name>:.metadata.annotations

示例 2

$kubectl describe pod nginx-web-server

$kubectl get pods nginx-web-server -o custom-columns=ANNOTATIONS:.metadata.annotations

说明：在上面的例子中，Pod 没有附加注解，但是有一个注解附加到 Pod 并且由 Kubernetes 核心组件附加，因为它保留了前缀 ‘kubernetes.io’ 并且注解的名称是 ‘ last-applied-configuration’ 这意味着它保存了应用于该对象的最后一个配置。注解的值在我们从第一个命令获得的输出中被截断。如果我们想知道或提取完整的值，我们使用第二个命令，它只输出注解的键/值对。

让我们创建一个 pod 并附加我们上面讨论的注解“oncallPager”、“imageregistry”和“kbArticle”。以下是相同的 YAML 配置文件： –

apiVersion: v1
kind: Pod
metadata:
name: nginx-web-server
labels:
env: prod
app: nginx-web
annotations:
oncallPager: 111-222-3333
imageregistry: "https://hub.docker.com"
kbArticle: "https://kb.docs.example.com/KB34234"
spec:
containers:
- name: nginx
image: nginx
ports:
- containerPort: 80

部署上述 pod 后，我们使用“kubectl describte”命令查看附加的注解，如下面的快照所示：

说明：在上面的快照中，我们可以看到附加的注解以及前面讨论过的默认注解。注解按字母顺序显示，我们如何在配置文件中指定注解并不重要。

让我们只输出注解，看看它是什么样子。这是输出： –

说明：在上面的快照中，键/值对与之前的输出相比并不那么清晰，如果有很多注解附加到 Kubernetes 对象，将很难找到键/值对。

Kubernetes注解场景

在许多场景中，注解非常有用。一些用例如下：

1. 我们可以添加应用程序构建、发布或镜像信息构建号、发布 ID、git 分支、注册地址、镜像哈希等。
2. 我们可以为调试目的附加客户端库或工具的名称、版本和构建信息。
3. 我们可以从对象的来源添加用户或工具/系统信息。例如，对象可以通过 CI/CD 模型中的 Jenkins 等自动化工具创建。谁创建了 Kubernetes 对象，这是非常有用的信息。
4. 附加由声明性配置层管理的字段作为注解有助于将它们与客户端或服务器设置的默认值以及自动生成的字段和由自动调整大小或自动缩放系统设置的字段区分开来。
5. 我们还可以附上负责人的电话或寻呼机号码或目录或链接，如果发生不好的事情，人们可以在其中找到该信息。
6. 还可以附加知识库文章或文章编号的链接，以解决与该对象相关的已知问题。
7. 我们可以添加指向日志记录、监控、分析或审计存储库的指针。

结论

Kubernetes 类似于标签，因为它也有键/值对，但是 Kubernetes 本身无法查询它，但是有许多工具可以根据对象的注解来查询对象，例如 Prometheus、第三方工具等。巨大的注解不会影响 Kubernetes 的内部性能，因此没有像标签那样受约束的键和值。