kubectl get pods -l creation_method=manual -l env=debug: 列出包含 creation_method=manual 标签和 env=debug 标签的所有 pod
kubectl get pods -l 'creation_method=manual, env in (debug, prod)': 列出包含 creation_method=manual 标签，且含有 env 标签并且其值为 debug 或 prod 的所有 pod
使用标签选择器 app=pc,rel=beta 选择前面所述示例中属于 product catalog 微服务的 beta 版本所有 pod 。 P71
某些情况下，我们希望对将 pod 调度到何处持有一定发言权，例如：硬件基础设施不同质。 P71
某些工作节点使用机械硬盘，其他节点使用固态硬盘。可能想将一些 pod 调度到一组节点，同时将其他 pod 调度到另一组节点
将执行 GPU 密集型运算的 pod 调度到实际提供 GPU 加速到节点上
这种情况下，我们应该用某种方式描述对节点的需求，使 Kubernetes 选择一个符合这些需求的节点，这恰好可以通过节点标签和节点标签选择器完成。 P72
使用标签分类工作节点 P72向集群添加新节点时，可以通过附加标签来对节点进行分类，这些标签指定节点提供对硬件类型，或者任何调度 pod 时能提供便利对其他信息。 P72
kubectl label node minikube-m02 gpu=true: 给节点 minikube-m02 添加 gpu=true 标签（在 02. 开始使用 Kubernetes 和 Docker 中已使用该命令给工作节点打上标签角色标签，使其 ROLES 设置为 worker ）
kubectl get nodes -l gpu=true: 列出包含 gpu=true 标签的所有节点
将 pod 调度到特定节点 P72基于 kubia-manual-gpu.yaml 创建一个新的描述文件 kubia-manual-gpu.yaml ，并添加 spec.nodeSelector 属性，指定选择的标签为 gpu=true 。这样当我们创建该 pod 时，调度器将只在包含标签 gpu=true 的节点中选择。 P73
# 遵循 v1 版本的 Kubernetes API apiVersion: v1 # 资源类型为 Pod kind: Pod metadata: # pod 的名称 name: kubia-manual-gpu # pod 的标签 labels: creation_method: manual env: prod spec: # 节点选择器 nodeSelector: # 选择的标签 gpu: "true" containers: # 创建容器所使用的镜像 - image: idealism/kubia # 容器的名称 name: kubia ports: # 应用监听的端口 - containerPort: 8080 protocol: TCP 调度到一个特定节点 P73我们也可以将 pod 调度到某个确定的节点，由于每个节点都有一个唯一标签 kubernetes.io/hostname ，值为该节点的实际主机名，因此我们也可以将 pod 调度到某个确定的节点。但如果节点处于离线状态，那么可能会导致 pod 不可调度。我们绝不应该考虑单个节点，而是应该通过标签选择器考虑符合特定标准但逻辑节点组。 P73
注解 pod P73注解也是键值对，本质上与标签非常相似。 P73
注解并不是为了保存标识信息而存在的，它们不能像标签一样用于对对象进行分组
注解可以容纳更多信息，并且主要用于工具使用
Kubernetes 也会将一些注解自动添加到对象，但其他的注解则需要由用户手动添加
向 Kubernetes 引入新特性时，通常会使用注解
一般来说，新功能的 alpha 和 beta 版本不会向 API 对象引入任何新字段，因此使用的是注解而不是字段。一旦所需的 API 更改变得清晰并且得到所有相关人员的认可，就会引入新的字段并废弃相关注解
大量使用注解可以为每个 pod 或其他 API 对象添加说明，以便每个使用该集群的人都可以快速查找有关每个单独对象的信息。例如，指定创建对象的人员姓名的注解可以使在集群中工作的人员之间的协作更加便利
标签应该简短，注解可以包含相对更多的数据（总共不超过 256KB ）
查找对象的注解 P74