小鲸鱼大梦想

k8s学习之路 | Day12 k8s 对象（二）

文章目录

标签
- k8s 标签定义
- 为什么需要标签
- 示例标签
- 标签的语法规则
- 标签示例文件
- 如何打标签
标签选择算符
- 用来做什么？
- 支持的类型
- 基于等值的标签选择算符
- 基于集合的标签选择算符
标签的一些参考
- 给节点添加标签
- pod 调度到选择的节点
注解
- 注解的定义
- 注解的规范
- 注解使用的场景
- 浅尝一下注解

标签（Labels）是附加到 Kubernetes 对象（比如 Pod）上的键值对
旨在用于指定对用户有意义且相关的对象的标识属性，但不直接对核心系统有语义含义
标签可以用于组织和选择对象的子集
标签可以在创建时附加到对象，随后可以随时添加和修改
每个对象都可以定义一组键/值标签。每个键对于给定对象必须是唯一的

为什么需要标签

因为标签是能够支持高效的查询和监听操作，对于用户界面和命令行是很理想的

标签使用户能够以松散耦合的方式将他们自己的组织结构映射到系统对象，而无需客户端存储这些映射。

服务部署和批处理流水线通常是多维实体（例如，多个分区或部署、多个发行序列、多个层，每层多个微服务）。管理通常需要交叉操作，这打破了严格的层次表示的封装，特别是由基础设施而不是用户确定的严格的层次结构。

示例标签

"release" : "stable", "release" : "canary"
"environment" : "dev", "environment" : "qa", "environment" : "production"
"tier" : "frontend", "tier" : "backend", "tier" : "cache"
"partition" : "customerA", "partition" : "customerB"
"track" : "daily", "track" : "weekly"

标签的 Key 对于给定对象必须是唯一的

标签的语法规则

它是一个键值对
有效的标签键有2个段：可选的前缀和名称，用斜杠/分隔
- 名称段是必须的
  - 小于等于63个字符
  - 字母数字字符[a-z0-9A-Z]开头和结尾
  - 带有破折号、下划线、点和之间的字母数字组成
- 对于前缀，是可选的
  - 必须是 DNS 子域：由.分隔的一系列 DNS 标签
  - 不超过253字符
  - 后跟斜杠/
如果省略前缀，则假定标签键对于用户是私有的
如果向最终用户对象添加标签的自动系统组件，例如： kube-scheduler、kube-controller-manager、 kube-apiserver、kubectl 或其他第三方自动化工具，必须指定前缀
kubernetes.io/ 和 k8s.io/ 前缀是为 Kubernetes 核心组件保留的
有效的标签值：
- 必须为 63 个字符或更少（可以为空）
- 除非标签值为空，必须以字母数字字符（[a-z0-9A-Z]）开头和结尾
- 包含破折号（-）、下划线（_）、点（.）和字母或数字

标签示例文件

apiVersion: v1
kind: Pod
metadata:
  name: label-demo
  labels:
    environment: production
    app: nginx
spec:
  containers:
  - name: nginx
    image: nginx:1.14.2
    ports:
    - containerPort: 80

如何打标签

_{以一个最基础的deploy对象为例}

对于指令式来说

通过kubectl label --help查看了一个示例

kubectl label [--overwrite] (-f FILENAME | TYPE NAME) KEY_1=VAL_1 ... KEY_N=VAL_N [--resource-version=version]

浅尝一下

##执行几次部署
kubectl create deploy nginx-demo1 --image=nginx:1.21-alpine
kubectl create deploy nginx-demo2 --image=nginx:latest
kubectl create deploy tomcat-demo1 --image=tomcat:latest

查看当前的部署后的标签信息

 kubectl get deploy -owide

增加标签信息

##kubectl label pods foo unhealthy=true
kubectl label deploy nginx-demo1 image=nginx-1.21-alpine

改变已有的标签信息

##加参数覆盖即可
kubectl label deploy nginx-demo1 image=nginx-1.21-alpine-test --overwrite

删除标签信息

kubectl label deploy nginx-demo1 image-

对于yaml文件

通过定义在metadata下面来形成标签

通过层层解释，我们可以看到这个标签的具体写法

kubectl explain deploy
kubectl explain deploy.metadata
kubectl explain deploy.metadata.labels
######################################################
Map of string keys and values

所以就这样写

##label-demo.yaml##
apiVersion: apps/v1
kind: Deployment
metadata:
  creationTimestamp: null
  labels:
    app: tomcat-demo				## 标签1
    environment: production			## 标签2
  name: tomcat-demo
spec:
  replicas: 1
  selector:
    matchLabels:
      app: tomcat-demo
  strategy: {}
  template:
    metadata:
      creationTimestamp: null
      labels:
        app: tomcat-demo
    spec:
      containers:
      - image: tomcat
        name: tomcat
        resources: {}

修改一下文件

apiVersion: apps/v1
kind: Deployment
metadata:
  creationTimestamp: null
  labels:
    app: tomcat-demo				
    environment-demo: production-demo
  name: tomcat-demo
spec:
  replicas: 1
  selector:
    matchLabels:
      app: tomcat-demo
  strategy: {}
  template:
    metadata:
      creationTimestamp: null
      labels:
        app: tomcat-demo
    spec:
      containers:
      - image: tomcat
        name: tomcat
        resources: {}

标签选择算符

用来做什么？

因为标签不支持唯一性，实际环境中许多对象携带着相同的标签

通过标签选择算法，客户端/用户可以识别一组对象，

支持的类型

基于等值的
基于集合的
标签选择算符可以由逗号分隔的多个需求组成，在多个需求的情况下，必须满足所有要求，因此逗号分隔符充当逻辑与（&&）运算符
空标签选择算符或者未指定的选择算符的语义取决于上下文，支持使用选择算符的 API 类别应该将算符的合法性和含义用文档记录下来

基于等值的标签选择算符

基于等值或基于不等值的需求允许按标签键和值进行过滤。匹配对象必须满足所有指定的标签约束，尽管它们也可能具有其他标签。可接受的运算符有 =、== 和 != 三种。前两个表示相等（并且是同义词），而后者表示不相等。

_{这个东西应该就是快速查找用的吧}

尝试一下

##我们按照这个模板准备3次部署
apiVersion: apps/v1
kind: Deployment
metadata:
  creationTimestamp: null
  labels:
    app: tomcat-demo
    environment: dev
    #environment: qa
    #environment: production
  name: tomcat-demo
spec:
  replicas: 1
  selector:
    matchLabels:
      app: tomcat-demo
  strategy: {}
  template:
    metadata:
      creationTimestamp: null
      labels:
        app: tomcat-demo
    spec:
      containers:
      - image: tomcat
        name: tomcat
        resources: {}

检查一下对应的标签信息

#########对于tomcat-demo1#########
Labels:                 app=tomcat-demo1
                        environment=dev

#########对于tomcat-demo2#########
Labels:                 app=tomcat-demo2
                        environment=qa

#########对于tomcat-demo3#########
Labels:                 app=tomcat-demo3
                        environment=production

试一下标签选择算符

###我要查一下标签中environment=dev的部署信息
kubectl get deploy  -l environment=dev -owide

###多查几个条件(逗号是且的关系，都要满足)
kubectl get deploy  -l environment=dev,app=tomcat-demo1 -owide
kubectl get deploy  -l environment=dev,app=tomcat-demo1,app=tomcat-demo3 -owide

再试一下

kubectl get deploy  -l app!=tomcat-demo3 -owide
kubectl get deploy  -l app==tomcat-demo3 -owide

基于集合的标签选择算符

基于集合的标签需求允许你通过一组值来过滤键。支持三种操作符：in、notin 和 exists（只可以用在键标识符上）

示例说明：

environment in (production, qa)
tier notin (frontend, backend)
partition
!partition

第一个示例选择了所有键等于 environment 并且值等于 production 或者 qa 的资源。

第二个示例选择了所有键等于 tier 并且值不等于 frontend 或者 backend 的资源，以及所有没有 tier 键标签的资源。

第三个示例选择了所有包含了有 partition 标签的资源；没有校验它的值。

第四个示例选择了所有没有 partition 标签的资源；没有校验它的值。

浅尝一下

###我要找出标签信息为environment的值为dev、qa
kubectl get deploy -l 'environment in (dev, qa)' -owide

### 找出键environment并且值不等于dev、qa的
kubectl get deploy -l 'environment notin (dev,qa)' -owide

标签的一些参考

给节点添加标签

获取节点标签信息

kubectl get nodes --show-labels

[root@k8s-01 ~]# kubectl get nodes k8s-01 --show-labels
NAME     STATUS   ROLES                  AGE   VERSION   LABELS
k8s-01   Ready    control-plane,master   9d    v1.21.0   beta.kubernetes.io/arch=amd64,beta.kubernetes.io/os=linux,kubernetes.io/arch=amd64,kubernetes.io/hostname=k8s-01,kubernetes.io/os=linux,node-role.kubernetes.io/control-plane=,node-role.kubernetes.io/master=,node.kubernetes.io/exclude-from-external-load-balancers=
[root@k8s-01 ~]#

添加一个标签

kubectl label nodes k8s-01 disktype=ssd

pod 调度到选择的节点

看下节点信息

[root@k8s-01 ~]# kubectl get nodes --show-labels
NAME     STATUS   ROLES                  AGE   VERSION   LABELS
k8s-01   Ready    control-plane,master   9d    v1.21.0   beta.kubernetes.io/arch=amd64,beta.kubernetes.io/os=linux,disktype=ssd,kubernetes.io/arch=amd64,kubernetes.io/hostname=k8s-01,kubernetes.io/os=linux,node-role.kubernetes.io/control-plane=,node-role.kubernetes.io/master=,node.kubernetes.io/exclude-from-external-load-balancers=
k8s-02   Ready    worker                 9d    v1.21.0   beta.kubernetes.io/arch=amd64,beta.kubernetes.io/os=linux,kubernetes.io/arch=amd64,kubernetes.io/hostname=k8s-02,kubernetes.io/os=linux,node-role.kubernetes.io/worker=
k8s-03   Ready    worker                 9d    v1.21.0   beta.kubernetes.io/arch=amd64,beta.kubernetes.io/os=linux,kubernetes.io/arch=amd64,kubernetes.io/hostname=k8s-03,kubernetes.io/os=linux,node-role.kubernetes.io/worker=
[root@k8s-01 ~]#

给任意工作节点打一个标签

kubectl label nodes k8s-02 environment=dev

准备一个 pod

apiVersion: v1
kind: Pod
metadata:
  name: nginx
  labels:
    env: test
spec:
  containers:
  - name: nginx
    image: nginx
    imagePullPolicy: IfNotPresent
  nodeSelector:			## 节点选择器，表示该pod调度到有environment: dev标签的节点上
    environment: dev

运行一下

kubectl apply -f pod.yaml

检查一下调度情况

kubectl describe pod nginx

可以看到默认调度器调度到k8s-02节点上了

注解

注解的定义

为对象附加任意的非标识的元数据
客户端程序（例如工具和库）能够获取这些元数据信息
有助于识别对象信息

注解的规范

层层解释一下，注解这个东西

kubectl explain deploy.metadata.annotations

注解中的元数据，可以很小，也可以很大，可以是结构化的，也可以是非结构化的，能够包含标签不允许的字符
ap 中的键和值必须是字符串。换句话说，你不能使用数字、布尔值、列表或其他类型的键或值

注解（Annotations） 存储的形式是键/值对：

有效的注解键分2部分
- 可选的前缀。以斜杠/分隔
  - 必须是 DNS 子域：一系列由点（.）分隔的 DNS 标签，总计不超过 253 个字符，后跟斜杠（/）
  - 如果省略前缀，则假定注解键对用户是私有的。由系统组件添加的注解（例如，kube-scheduler，kube-controller-manager，kube-apiserver，kubectl 或其他第三方组件），必须为终端用户添加注解前缀。
- 名称段。
  - 63个字符以内
  - 以字母数字字符（[a-z0-9A-Z]）开头和结尾
  - 允许使用破折号（-），下划线（_），点（.）和字母数字

注解使用的场景

以下是一些例子，用来说明哪些信息可以使用注解来记录：

由声明性配置所管理的字段。将这些字段附加为注解，能够将它们与客户端或服务端设置的默认值、自动生成的字段以及通过自动调整大小或自动伸缩系统设置的字段区分开来。
构建、发布或镜像信息（如时间戳、发布 ID、Git 分支、PR 数量、镜像哈希、仓库地址）。
指向日志记录、监控、分析或审计仓库的指针。
可用于调试目的的客户端库或工具信息：例如，名称、版本和构建信息。
用户或者工具/系统的来源信息，例如来自其他生态系统组件的相关对象的 URL。
轻量级上线工具的元数据信息：例如，配置或检查点。
负责人员的电话或呼机号码，或指定在何处可以找到该信息的目录条目，如团队网站。
从用户到最终运行的指令，以修改行为或使用非标准功能。

你可以将这类信息存储在外部数据库或目录中而不使用注解，但这样做就使得开发人员很难生成用于部署、管理、自检的客户端共享库和工具。

浅尝一下注解