Kubernetes 标签：包含10项优秀实践的专家指南

借助 Kubernetes 标签，DevOps 团队可以更快地解决问题、集中应用配置更改并快速响应问题。标签还可以让您深入了解成本，提高您的监控、分配和管理能力。在使用标签时遵循最佳实践可帮助您从基础架构可见性和高效运营中获得巨大收益。

以下是您需要了解的有关 Kubernetes 标签的所有信息 - 它们是什么、它们如何工作、何时使用它们，以及构建可靠标签策略应遵循的 10 条最佳实践。

什么是 Kubernetes 标签?

Kubernetes 标签是将标识元数据链接到 Kubernetes 对象的键值字符串对。Kubernetes 为团队提供了集成支持，可以使用标签从 Kubernetes API 中检索和过滤数据，并对所选对象进行批量操作。

许多团队使用 Kubernetes 标签为 DevOps 提供有关节点、Pod 或其他 Kubernetes 对象的所有权的信息，以便于跟踪和运营决策制定。

创建新标签时，您必须遵守 Kubernetes 对长度和允许值的限制。标签值必须：

• 包含 63 个字符或更少(标签的值也可以为空)，
• 以字母数字字符开头和结尾(除非它为空)，
• 仅包含破折号 (-)、下划线 (_)、点 (.) 和字母数字。

您可以使用 找到 Kubernetes 对象具有的标签kubectl。例如，要获取名为 的 pod 的所有标签pod1，您可以运行：

> kubectl get pod1 -o json | jq .metadata.labels

要创建标签，您可以在配置文件规范的metadata.labels对象中指定它们。让我们考虑pod.yaml描述单个 pod 的文件：

apiVersion: v1kind: Podmetadata: name: nginx labels: environment: dev 
critical: "true"spec: containers: - image: nginx name: nginx resources: 
requests: cpu: 500m

请注意，critical标签的值是“true”而不是true。这是因为标签及其值必须是字符串。

让我们应用配置文件：

> kubectl apply -f pod.yamlpod/nginx created

您现在可以使用 直接在已经存在的 Kubernetes 对象上应用或覆盖标签kubectl。首先，获取 pod 具有的所有标签：

> kubectl get pod nginx -o json | jq .metadata.labels{ "critical": "true", 
"environment": "dev"}

现在，要更改environment标签的值并添加新的键值标签对deprecated=true，我们执行以下命令：

> kubectl label pod nginx environment=prod --overwritepod/nginx 
labeled> kubectl label pod nginx deprecated=truepod/nginx labeled

–overwrite请记住，除非您明确地用标志覆盖它，否则不允许更新标签的值。生成的标签如下：

> kubectl get pod nginx -o json | jq .metadata.labels{ "deprecated": 
"true", "critical": "true", "environment": "prod"}

Kubernetes 标签与注解

Kubernetes 提供了两种将元数据与对象连接起来的策略：标签和注释。

注释是将非标识元数据与对象连接起来的键值对。例如，注释可以包含给定资源的日志记录或监视信息。

标签和注解的主要区别在于注解不用于过滤、分组或操作 Kubernetes 资源。相反，您可以使用它们来访问有关它的其他信息。

例如之前部署的pod已经调度到的节点注解如下：

> kubectl get node demo-node -o json | jq .metadata.annotations{ 
"kubeadm.alpha.kubernetes.io/cri-socket": "unix:///var/run/cri-dockerd.sock", 
"node.alpha.kubernetes.io/ttl": "0", 
"volumes.kubernetes.io/controller-managed-attach-detach": "true"}

这些注释不提供有关节点特征的任何信息。相反，他们提供了一些关于节点如何工作的数据。

什么时候使用 Kubernetes 标签?

对象查询的组资源

如果将相同的标签键值对添加到多个资源中，其他人可以轻松查询到所有资源。例如，DevOps 工程师发现开发环境不可用。此时，他们可以快速查看包括 label 在内的所有 pod 的状态environment:dev。

这是一个示例命令：

> kubectl get pods -l 'environment=dev'NAME READY STATUS RESTARTS AGEnginx 
0/1 CrashLoopBackOff 1 5m

这让团队可以立即看到受影响的 pod 并解决问题，这比浏览所有资源并仅选择dev环境中的资源要快得多。

在具有许多不同部署的复杂情况下，dev如果工程团队没有将environment:dev标签添加到资源中，那么找到合适的 pod 将花费 DevOps 工程师很长时间。DevOps 工程师必须使用通用kubectl get pods命令，然后使用grep.

执行批量操作

Kubernetes 标签的另一个用例是根据资源标签执行批量操作。

假设工程师每晚移除所有暂存环境以降低云成本。通过使用 Kubernetes 标签，他们可以轻松地自动执行此任务。

例如，这是一个删除所有标记为environment:local,environment:dev或的对象的命令environment:staging：

> kubectl delete deployment,services,statefulsets -l 'environment in 
(local,dev,staging)'

根据节点标签调度 pod

Kubernetes 标签的隐藏宝石是它们在 Kubernetes 本身中被大量使用，用于将 pod 调度到适当的节点。通过使用标签，您可以通过让 Kubernetes 将特定部署安排到特定节点来更好地控制您创建的资源。

让我们看看这在实践中是如何工作的：

> kubectl get nodesNAME STATUS ROLES AGE VERSIONgke-node-1fe68171 Ready 
1d v1.22.12-gke.2300gke-node-3cdf3d2b Ready 3d 
v1.22.12-gke.2300gke-node-5f7b4cf1 Ready 5d v1.22.12-gke.500> kubectl 
get nodes -l ‘critical=true’No resources found

当前，不存在具有标签的节点critical:true。

让我们尝试critical:true使用节点选择器创建一个必须在具有标签的节点上调度的 pod。这是一个pod.yaml配置文件：

apiVersion: v1kind: Podmetadata: name: nginx labels: environment: prodspec: 
nodeSelector: critical: "true" containers: - image: nginx name: nginx resources: 
requests: cpu: 500m

现在让我们应用它并检查会发生什么：

> kubectl apply -f pod.yamlpod/nginx created> kubectl get pod nginxNAME 
READY STATUS RESTARTS AGEnginx 0/1 Pending 0 1m> kubectl get events 
--field-selector involvedObject.name=nginxLAST SEEN TYPE REASON OBJECT 
MESSAGE46s Warning FailedScheduling pod/nginx 0/1 nodes are available: 1 node(s) 
didn't match Pod's node affinity/selector. preemption: 0/1 nodes are available: 
1 Preemption is not helpful for scheduling.

请注意，pod 无法在任何节点上调度，因为它们都没有所需的标签。现在，让我们用所需的标签标记其中一个节点：

> kubectl label node gke-node-5f7b4cf1 critical=truenode/gke-node-5f7b4cf1 
labeled> kubectl get nodes -l 'critical=true'NAME STATUS ROLES AGE 
VERSIONgke-node-5f7b4cf1 Ready 5h v1.22.12-gke.500

现在，让我们检查 pod：

> kubectl get pod nginxNAME READY STATUS RESTARTS AGEnginx 1/1 Running 0 
3m31s

Pod 已成功调度到该节点。

请记住，如果在节点选择器中指定了多个标签，则它们都必须被一个节点满足，以便 pod 被调度到它上面。

Kubernetes 标签的 10 个最佳实践

1.使用Kubernetes推荐的标签

Kubernetes 提供了一个推荐的标签列表，用于对对象进行分组。例如，Kubernetes 推荐使用app.kubernetes.io/name和

app.kubernetes.io/instance分别表示应用程序的名称和实例。只需删除前缀“app.kubernetes.io”并添加您公司的子域即可自定义标签。

2.注意语法正确

要创建 Kubernetes 标签键值对，您需要使用以下语法：/. 让我们深入了解细节：

• <前缀>

前缀是可选的;如果您选择使用它，它需要是一个有效的 DNS 子域(例如“cast.ai”)并且总共不超过 253 个字符。对于非用户私有的工具和命令，前缀会派上用场。它们也很有用，因为它们允许团队使用多个标签，否则会发生冲突(想想第三方包中的标签)。

请注意，前缀kubernetes.io/和k8s.io前缀是为 Kubernetes 核心组件保留的。

• <名称>

这部分是指标签的任意属性名。为了清楚起见，团队可以使用名称“环境”和标签值，例如“生产”或“测试”。

名称必须满足与标签值相同的要求，但不能为空。因此，名称需要包含 63 个字符或更少，以字母数字字符 ([a-z0-9A-Z]) 开头和结尾，中间有破折号 (-)、下划线 (_)、点 (.) 和字母数字.

3.标准化标签命名约定

使用 Kubernetes 的多个团队需要遵循相同的标签约定。否则，所有的标签工作都不会给你带来任何价值。

让您的开发管道对资源配置文件执行静态代码分析以确保所有必需的标签都存在是一个很好的做法。如果您未能正确应用标签，自动化流程可能会中断——您使用的任何监控解决方案都可能向您发送误报警报。

4.避免对标签进行不必要的改动

Kubernetes 中的标签用于识别和选择用于调度、部署和管理目的的资源。因此，修改资源标签可能会产生深远且无法预料的影响。

例如，如果您将一组 pod 的“app”标签从“frontend”切换到“backend”，Kubernetes 可以将这些 pod 重新安排到未设置为运行“backend”应用程序的节点上。吊舱可能会崩溃;结果，使它们不可用。

只有在绝对必要时才修改标签，并在进行任何更改之前仔细评估其后果以避免此类问题，这一点至关重要。

5.使用标签选择选项

团队可以根据相等性和集合来选择带标签的对象。

基于相等性的选择允许您检索标签等于或不等于指定值(或多个值)的对象。深入语法，= 和 == 都表示相等，而 != 表示不等。可以添加以逗号分隔的多个标签(所有条件都需要在此处匹配)。例如，如果您执行以下命令：

> kubectl get pods -l ‘environment=dev,release=daily’

它将返回所有带有标签environment:devAND的 pod release:daily。

另一方面，基于集合的选择允许一次查找具有多个值的资源。集合类似于INSQL 中的关键字。例如，以下命令：

> kubectl get pods -l ‘environment in (prod,dev)’

将找到所有包含标签environment=prodOR的 pod environment=dev。

6. 不要在标签中存储应用程序级语义

Kubernetes 标签可能与对象的元数据一起出现，但它们不应该用作应用程序的数据存储。鉴于 Kubernetes 资源的使用时间通常很短，并且与应用程序没有紧密关联，标签很快就会变得不同步，因此变得无用。

7. 不要在标签中存储敏感信息

如果有人在您将密码或 API 凭据或其他敏感数据存储在标签中时获得了对您的 Kubernetes 集群的访问权限，他们将能够以纯文本形式看到它。这是一个重大的安全风险，可能会产生身份盗用或数据泄露等负面影响。

建议以秘密而不是标签的形式保存敏感信息。秘密是加密的，只有需要它们的 pod 才能解密。通过这样做，即使有人设法访问您的 Kubernetes 集群，他们也无法查看保密的私有数据。

8. 给 pod 模板添加标签

将基本标签添加到作为工作负载资源一部分的 pod 模板。这样，Kubernetes 控制器可以始终如一地创建具有您指定状态的 pod。

目标不应该是创建尽可能多的标签，而是创建能为您的团队带来价值的标签。从小处着手，创建一个标签列表作为模板的一部分。例如，您可以从确定资源所有者、资源运行环境和版本开始。

9. 自动化你的标签实践

自动化可以为您节省大量时间，标签也不例外。如果您设置了持续集成/持续交付 (CI/CD) 管道，则可以轻松地自动化一些横切关注点标签。

使用 CD 工具自动附加标签是明智的，因为它可以保证一致性并提高工程师的工作效率。让 CI 作业通过使构建失败并在标签丢失时向负责团队发送通知来强制执行正确的标签也是一种很好的做法。

10.使用标签进行成本监控

标签对于更好地了解您的 Kubernetes 云成本非常有帮助。成本监控、分配和管理都依赖于适当的标签策略。

如果多个租户在单个集群中共享资源，您需要使用相关标签来创建成本分配报告。这就是您可以确定哪个团队、服务或应用程序产生了特定成本的方式，这在调查意外成本激增时非常有帮助。

使用此免费监控工具按标签跟踪您的成本

CAST AI 提供了一个成本监控工具，让您可以随时了解任何工作负载的成本。成本可以通过任何工作负载上存在的任何标签进行过滤，从而可以轻松跟踪每个团队、服务或您使用的任何其他标签的云成本。按标签对工作负载进行分组的选项即将推出。

通过将集群连接到 CAST AI 的免费成本监控解决方案，了解良好的标签和成本监控可以带来的不同。