一、对象名称name和ID
集群中的每一个对象都一个名称 来标识在同类资源中的唯一性。
每个 Kubernetes 对象也有一个UID 来标识在整个集群中的唯一性。
比如，在同一个namespace中只能命名一个名为 myapp-1234 的 Pod, 但是可以命名一个 Pod 和一个 Deployment 同为 myapp-1234.
对于非唯一的用户提供的属性，Kubernetes 提供了标签labels和注释annotations。
1.名称
客户端提供的字符串，引用资源 url 中的对象，如/api/v1/pods/some name。
一个给定类型的对象一次只能具有一个给定的名称，但是，如果删除对象，则可以使用相同的名称创建一个新对象。
比较常见的三种资源命名约束：DNS 子域名，DNS 标签名称，Path 部分名称
2.UID
Kubernetes 系统生成的字符串，唯一标识对象。
在 Kubernetes 集群的整个生命周期中创建的每个对象都有一个不同的 uid，它旨在区分类似实体的历史事件。
二、命名空间namespace
Kubernetes 支持多个虚拟集群，它们底层依赖于同一个物理集群。 这些虚拟集群被称为命名空间。
1.何时使用多个命名空间
命名空间适用于存在很多跨多个团队或项目的用户的场景。对于只有几到几十个用户的集群，根本不需要创建或考虑命名空间。当需要名称空间提供的功能时，请开始使用它们。
命名空间提供了名称范围。资源的名称需要命名空间中必须唯一，但跨命名空间可以相同。命名空间不能相互嵌套，每个 Kubernetes 资源只能在一个命名空间中。
命名空间是在多个用户之间划分集群资源的一种方法（通过资源配额）。
在 Kubernetes 未来版本中，相同命名空间中的对象默认将具有相同的访问控制策略。
不需要使用多个命名空间来分隔轻微不同的资源，例如同一软件的不同版本：使用 labels 来区分即可。
2.使用命名空间
使用以下命令列出集群中现存的命名空间：kubectl get namespace
Kubernetes 会创建四个初始命名空间：
default 没有指明使用其它命名空间的对象所使用的默认命名空间
kube-system Kubernetes系统创建的对象所使用的命名空间
kube-public 该命名空间是自动创建的，并且对所有用户（包括未经身份验证的用户）可读。此命名空间主要用于集群使用，以防某些资源在整个集群中公开可见。此命名空间的公共方面仅是约定，并非要求。
kube-node-lease 该命名空间是与每个节点关联的租用对象使用的，可在集群扩展时提高节点的性能。
要为当前请求设置命名空间，请使用 --namespace 参数，默认是default。
如 kubectl create deployment nginx --image=nginx --namespace=kube-public
您可以设置名称空间首选项，永久保存该上下文中所有后续 kubectl 命令使用的命名空间。
kubectl config set-context --current --namespace=<insert-namespace-name-here>
# Validate it
kubectl config view | grep namespace:
3.命名空间和 DNS
当创建一个 Service 时，Kubernetes 会创建一个相应的 DNS 条目。
该条目的形式是 <service-name>.<namespace-name>.svc.cluster.local，这意味着如果容器只使用 <service-name>，它将被解析到本地命名空间的服务。这对于跨多个命名空间（如开发、分级和生产）使用相同的配置非常有用。如果要跨命名空间访问，则需要使用完全限定域名（FQDN）。
4.并非所有对象都在命名空间中
大多数 kubernetes 资源（例如 Pod、Service、副本控制器等）都位于某些命名空间中。但是命名空间资源本身并不在命名空间中。而且底层资源，例如 nodes 和 persistentVolumes 不属于任何命名空间。
使用以下命令查看哪些 Kubernetes 资源在命名空间中，哪些不在命名空间中：
# In a namespace
kubectl api-resources --namespaced=true
# Not in a namespace
kubectl api-resources --namespaced=false
三、标签label和选择器
标签是附加到 Kubernetes 对象（比如 Pods）上的键值对。
标签用于指定对用户有意义且相关的对象的标识属性，但不直接对核心系统有语义含义。 标签可以用于组织和选择对象的子集。标签可以在创建时附加到对象，随后可以随时添加和修改。
每个对象都可以定义一组键/值标签。每个键对于给定对象必须是唯一的。
标签可以进行有效的查询和监视，非常适合在UI和CLI中使用。非识别信息应使用注释记录。
1.动机
标签使用户能够以松散耦合的方式将他们自己的组织结构映射到系统对象，而无需客户端存储这些映射。
服务部署和批处理流水线通常是多维实体（例如，多个分区或部署、多个发行序列、多个层，每层多个微服务）。管理通常需要交叉操作，这打破了严格的层次表示的封装，特别是由基础设施而不是用户确定的严格的层次结构。
示例标签：
"release" : "stable", "release" : "canary"
"environment" : "dev", "environment" : "qa", "environment" : "production"
"tier" : "frontend", "tier" : "backend", "tier" : "cache"
"partition" : "customerA", "partition" : "customerB"
"track" : "daily", "track" : "weekly"
这些只是常用标签的例子，您可以任意制定自己的约定。请记住，对于给定对象标签的键必须是唯一的。
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]）开头和结尾，中间可以包含破折号（-）、下划线（_）、点（.）和字母或数字。
3.标签选择器
与 名称和UID 不同，标签不提供唯一性。通常，我们希望许多对象携带相同的标签。
通过 标签选择器，客户端/用户可以识别一组对象。标签选择器是 Kubernetes 中的核心分组原语。
API 目前支持两种类型的选择器：基于相等性的 和 基于集合的。 标签选择器可以由逗号分隔的多个 需求 组成。在多个需求的情况下，必须满足所有要求，因此逗号分隔符充当逻辑 与（&&）运算符。
空的或未指定的选择器的语义取决于上下文。（这是英文版说明，下面是中文版的，猜测是默认情况）
空标签选择器（即，需求为零的选择器）选择集合中的每个对象。
null 值的标签选择器（仅可用于可选选择器字段）不选择任何对象
基于相等性 或 不相等 的需求允许按标签键和值进行过滤。匹配对象必须满足所有指定的标签约束，尽管它们也可能具有其他标签。 可接受的运算符有=、== 和 ！= 三种。 前两个表示 相等（并且只是同义词），而后者表示 不相等。
基于集合 的标签需求允许通过一组值来过滤键。支持三种操作符：in,notin and exists (只可以用在键标识符上)。
也可以将基于集合 的要求可以与基于 相等 的要求混合使用。
4.API
LIST 和 WATCH 操作可以使用查询参数指定标签选择器过滤一组对象。
两种标签选择器都可以通过 REST 客户端用于 list 或者 watch 资源，
如kubectl get 使用 -l 参数：kubectl get pod -l app=hello-node。
一些 Kubernetes 对象，例如 services 和 replicationcontrollers ，也使用了标签选择器去指定了其他资源的集合，例如 pods。
一个 Service 指向的一组 pods 是由标签选择器定义的。同样，一个 ReplicationController 应该管理的 pods 的数量也是由标签选择器定义的。
两个对象的标签选择器都是在 json 或者 yaml 文件中使用映射定义的，并且只支持 基于相等性 需求的选择器：
"selector": {
"component" : "redis",
}
或者
selector:
component: redis
比较新的资源，例如 Job、Deployment、Replica Set 和Daemon Set ,也支持 基于集合的 需求：
selector:
matchLabels:
component: redis
matchExpressions:
- {key: tier, operator: In, values: [cache]}
- {key: environment, operator: NotIn, values: [dev]}
通过标签进行选择的一个用例是确定节点集，方便 pod 调度。
四、注解
你可以使用Kubernetes注解为对象附加任意的非标识的元数据。客户端程序（例如工具和库）能够获取这些元数据信息。
1.为对象附加元数据
您可以使用标签或注解将元数据附加到 Kubernetes 对象。 标签可以用来选择对象和查找满足某些条件的对象集合。 相反，注解不用于标识和选择对象。 注解中的元数据，可以很小，也可以很大，可以是结构化的，也可以是非结构化的，能够包含标签不允许的字符。
注解和标签一样，是键/值对:
"metadata": {
"annotations": {
"key1" : "value1",
"key2" : "value2"
}
}
可以不使用注解而将信息存储在外部数据库或目录中，但这样做就使得开发人员很难生成用于部署、管理、自检的客户端共享库和工具。
2.语法和字符集
注解存储的形式是键/值对。
有效的注解键分为两部分：可选的前缀和名称，以斜杠（/）分隔。 名称段是必需项，并且必须在63个字符以内，以字母数字字符（[a-z0-9A-Z]）开头和结尾，并允许使用破折号（-），下划线（_），点（.）和字母数字。 前缀是可选的。 如果指定，则前缀必须是DNS子域：一系列由点（.）分隔的DNS标签，总计不超过253个字符，后跟斜杠（/）。 如果省略前缀，则假定注释键对用户是私有的。 由系统组件添加的注释（例如，kube-scheduler，kube-controller-manager，kube-apiserver，kubectl 或其他第三方组件），必须为终端用户添加注释前缀。
kubernetes.io / 和 k8s.io / 前缀是为Kubernetes核心组件保留的。
五、字段选择器
字段选择器（Field selectors）允许您根据一个或多个资源字段的值筛选 Kubernetes 资源。本质上是资源过滤器。
下面是一些使用字段选择器查询的例子：
metadata.name=my-service
metadata.namespace!=default
status.phase=Pending
如kubectl get 使用 --field-selector 参数：kubectl get pods --field-selector status.phase=Running
1.支持的字段
不同的 Kubernetes 资源类型支持不同的字段选择器。所有资源类型都支持 metadata.name 和 metadata.namespace 字段。使用不被支持的字段选择器会产生错误。
2.支持的运算符
您可以使用 =、==和 != 对字段选择器进行运算（= 和 == 的意义是相同的）。
3.链式选择器
同标签和其他选择器一样，字段选择器可以通过使用逗号分隔的列表组成一个选择链。
4.多种资源类型
您能够跨多种资源类型来使用字段选择器。
六、推荐使用的标签
除了 kubectl 和 dashboard 之外，您可以使用其他工具来可视化和管理 Kubernetes 对象。一组通用的标签可以让多个工具之间相互操作，用所有工具都能理解的通用方式描述对象。
除了支持工具外，推荐的标签还以一种可以查询的方式描述了应用程序。
元数据围绕 应用（application） 的概念进行组织。Kubernetes 不是 平台即服务（PaaS），没有或不强制执行正式的应用程序概念。 相反，应用程序是非正式的，并使用元数据进行描述。应用程序包含的定义是松散的。
共享标签和注解都使用同一个前缀：app.kubernetes.io。没有前缀的标签是用户私有的。共享前缀可以确保共享标签不会干扰用户自定义的标签。
1.标签
为了充分利用这些标签，应该在每个资源对象上都使用它们。
键 描述 示例 类型 app.kubernetes.io/name 应用程序的名称 mysql 字符串 app.kubernetes.io/instance 用于唯一确定应用实例的名称 wordpress-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 字符串
2.应用和应用实例
应用可以在 Kubernetes 集群中安装一次或多次。在某些情况下，可以安装在同一命名空间中。例如，可以不止一次地为不同的站点安装不同的 wordpress。
应用的名称和实例的名称是分别记录的。例如，某WordPress实例的应用名称 app.kubernetes.io/name 为 wordpress，而其实例名称为 app.kubernetes.io/instance 的属性值 wordpress-abcxzy。这使应用程序和应用程序的实例是可识别的。应用程序的每个实例都必须具有唯一的名称。
也即没有应用程序都可以安装多次，每次都是一个应用实例，每个实例的名称必须唯一。