让运维不加班,从一套On-Call响应机制开始!
780
2022-10-31
Kubernetes 中 Label 最佳实践
前言
在 Kubernetes 中 Label 自身是没有任何预定义含义的键值对,我们通常会在创建 objects 或者 resources 前指定 label,然后 label 可以让我们对集群内的 objects 进行搜索、应用批量配置更改等操作。当然 label 可以帮助我们更好的面对和解决 Kubernetes 环境中遇到的许多日常挑战:
挑战 | 描述 |
---|---|
故障排查 | 比如一个服务异常,我们可以通过 label 快速定位他属于哪个环境,帮助我们判断故障影响范围 |
批量操作 | 比如你需要更新后端的几十个服务,那么我们就可以通过 label 支持这类型的批量操作 |
成本控制 | 比如我们需要查看一个集群内属于不同项目组的详细成本情况,那么我们就可以预先设置好 label,然后使用 kubecost 这类的成本计算工具查看某一个项目组的成本 |
安全相关 | 比如我们可以通过 label 来标记各服务的安全等级 |
最佳实践
那么实际业务中,我们该如何使用呢?我们一般分 3 类 label:
定义技术相关的 Labels
第一类便是和技术相关的 label,在 Kubernetes 官方文档中,有一个推荐使用的 labels 列表,如下:
键 | 描述 | 示例 | 邮箱 |
---|---|---|---|
app.kubernetes.io/name | 应用程序的名称 | mysql | 字符串 |
app.kubernetes.io/instance | 用于唯一确定应用实例的名称 | mysql-abcxzy | 字符串 |
app.kubernetes.io/version | 应用程序的当前版本(例如,语义版本,修订版哈希等) | 5.7.21 | 字符串 |
app.kubernetes.io/component | 架构中的组件 | database | 字符串 |
app.kubernetes.io/part-of | 此级别的更高级别应用程序的名称 | wordpress | 字符串 |
app.kubernetes.io/managed-by | 用于管理应用程序的工具 | helm | 字符串 |
app.kubernetes.io/created-by | 创建该资源的控制器或者用户 | controller-manager | 字符串 |
为了说明这些标签的实际使用情况,请参考下面的 Deployment 对象:
apiVersion: apps/v1kind: Deploymentmetadata: name: deployment labels: app.kubernetes.io/name: service-order app.kubernetes.io/instance: service-order-8ef23b2 app.kubernetes.io/version: "v1.1.0" app.kubernetes.io/component: api app.kubernetes.io/part-of: order app.kubernetes.io/managed-by: kubectlspec: replicas: 6 selector: matchLabels: application: service-order template: metadata: labels: app.kubernetes.io/name: service-order app.kubernetes.io/instance: service-order-8ef23b2 app.kubernetes.io/version: "v1.1.0" app.kubernetes.io/component: api app.kubernetes.io/part-of: order app.kubernetes.io/managed-by: kubectl spec: containers: - name: service-order image: ccr.ccs.tencentyun.com/heyteago-prod/service-order:v1.1.0-161100
定义业务相关的 Label
第二类便是和业务相关的 label,我们一般会定义如下几个 labels:
键 | 描述 | 示例 | 邮箱 |
---|---|---|---|
tier | 架构中的层级 | frontend | 字符串 |
env | 环境 | dev | 字符串 |
purpose | 应用的用途 | queue | 字符串 |
owner | 应用的拥有者 | order-team | 字符串 |
repository | 应用的拥有者 | "https://github.com/service/service-order" | 字符串 |
project | 所属的项目 | heytea | 字符串 |
business-unit | 所属的业务单元 | finance | 字符串 |
为了说明这些标签的实际使用情况,请参考下面的 Deployment 对象:
apiVersion: apps/v1kind: Deploymentmetadata: name: deployment labels: tier: frontend env: dev purpose: web owner: frontend-team repository: https://github.com/frontend/web-finance project: heytea business-unit: financespec: replicas: 2 selector: matchLabels: application: web-finance template: metadata: labels: tier: frontend env: dev purpose: web owner: frontend-team repository: https://github.com/frontend/web-finance project: heytea business-unit: finance spec: containers: - name: web-finance image: ccr.ccs.tencentyun.com/heyteago-prod/web-finance:v1.0.0-184100
定义安全相关的 Label
最后一类就是关于安全的相关 label,我们一般会定义如下几个 labels:
键 | 描述 | 示例 | 邮箱 |
---|---|---|---|
sec-level | 安全等级 | s1 | 字符串 |
compliance | 遵守的法律法规 | GDPR | 字符串 |
为了说明这些标签的实际使用情况,请参考下面的 Deployment 对象:
apiVersion: apps/v1kind: Deploymentmetadata: name: deployment labels: sec-level: s1 compliance: gdprspec: replicas: 2 selector: matchLabels: application: service-order template: metadata: labels: sec-level: s1 compliance: gdpr spec: containers: - name: web-finance image: ccr.ccs.tencentyun.com/heyteago-prod/web-finance:v1.0.0-184100
Label Selection 的方式
在设置完 label 后,我们通常可以使用 kubectl 客户端查询 Kubernetes API 以列出具有特定 Label 的特定组件。可以使用三个运算符来执行这些查询:=、== 和 !=。
查询范例:
$ kubectl get all -l name==web-finance,env!=dev -A
当然也可以通过使用 in、notin和exists.来查询或者匹配
$ kubectl get pods -l 'env in (dev)'
$ kubectl delete deployment,services,statefulsets -l env in (dev,test)
总结
以上便是 Kubernetes 中 label 的一些实践,仅供参考。我们还可以参考 AWS ( https://aws.amazon.com/answers/account-management/aws-tagging-strategies/ ) 的文档,虽然他不是专门针对 Kubernetes 的,但是给我们提供了一些常见的资源标记的策略。这次的分享就到这里,下次见。
发表评论
暂时没有评论,来抢沙发吧~