Kubernetes笔记8-Kubernetes的标签和选择器

Posted 2023-04-25

参考技术A

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

标签允许高效的查询和观察，非常适合在 UI 和 CLI 中使用。非识别信息应使用 注释 记录 。

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

服务部署和批处理管道通常是多维实体（例如，多个分区或部署、多个发布轨道、多个层、每层多个微服务）。管理通常需要横切操作，这打破了严格分层表示的封装，尤其是由基础设施而不是用户确定的刚性层次结构。

示例标签：

这些是 常用标签的 示例；您可以自由制定自己的约定。请记住，标签 Key 对于给定对象必须是唯一的。

标签 是键/值对。有效的标签键有两个部分：一个可选的前缀和名称，用斜杠 ( / )分隔。名称段是必需的，并且必须不超过 63 个字符，以字母数字字符 ( [a-z0-9A-Z] )开头和结尾，中间有破折号 ( - )、下划线 ( _ )、点 ( . ) 和字母数字。前缀是可选的。如果指定，前缀必须是 DNS 子域：一系列由点 ( . )分隔的 DNS 标签，总长度不超过 253 个字符，后跟斜线 ( / )。

如果省略前缀，则标签 Key 被认为是用户私有的。向最终用户对象添加标签的自动化系统组件（例如 kube-scheduler 、 kube-controller-manager 、 kube-apiserver 、 kubectl 或其他第三方自动化）必须指定前缀。

在 kubernetes.io/ 和 k8s.io/ 前缀 保留 用于Kubernetes核心组件。

有效标签值：

例如，这是一个 Pod 的配置文件，它有两个标签 environment: production 和 app: nginx ：

与 名称和 UID 不同，标签不提供唯一性。通常，我们希望许多对象带有相同的标签。

通过 标签选择器 ，客户端/用户可以识别一组对象。标签选择器是 Kubernetes 中的核心分组原语。

目前，API支持两种类型的选择： 平等为基础的 和 基于集合的 。标签选择器可以由多个以逗号分隔的 要求 组成。在多个要求的情况下，必须满足所有要求，因此逗号分隔符充当逻辑 AND ( && ) 运算符。

空或未指定选择器的语义取决于上下文，使用选择器的 API 类型应记录它们的有效性和含义。

注意： 对于某些 API 类型，例如 ReplicaSet，两个实例的标签选择器不能在命名空间内重叠，否则控制器会将其视为冲突指令而无法确定应存在多少副本。

注意： 对于基于相等和基于集合的条件，没有逻辑 OR ( || ) 运算符。确保您的过滤器语句具有相应的结构。

基于 等式 或 不等式的 要求允许按标签键和值进行过滤。匹配的对象必须满足所有指定的标签约束，尽管它们也可能有额外的标签。允许三种操作符 = ， == , != 。前两个代表 平等 （并且是同义词），而后者代表 不平等 。例如：

前者选择所有 key 等于 environment 且 value 等于 的资源 production 。后者选择所有键等于 tier 且值不同于 的 frontend 资源，以及所有没有带有 tier 键的标签的资源。可以使用逗号运算符在 production 排除中过滤资源 frontend ： environment=production,tier!=frontend

基于相等的标签要求的一种使用场景是让 Pod 指定节点选择标准。例如，下面的示例 Pod 选择标签为“ accelerator=nvidia-tesla-p100 ”的节点。

基于集合的 标签要求允许根据一组值过滤键。支持三种运算符： in , notin 和 exists （仅密钥标识符）。例如：

同样，逗号分隔符充当 AND 运算符。因此，与过滤资源 partition 键（无论价值），并用 environment 不同的比 qa 可以使用来实现 partition,environment notin (qa) 。基于 集合的 标签选择器是等式的一般形式，因为 environment=production 等价于 environment in (production) ; != 和类似 notin 。

基于集合的 需求可以与 基于平等的 需求混合在一起。例如： partition in (customerA, customerB),environment!=qa 。

LIST 和 WATCH 操作可以指定标签选择器来过滤使用查询参数返回的对象集。这两个要求都是允许的（在此处显示，因为它们将出现在 URL 查询字符串中）：

两种标签选择器样式均可用于通过 REST 客户端列出或查看资源。例如，靶向 apiserver 与 kubectl 和使用 基于平等- 一个可写：

或使用 基于集合的 要求：

如前所述 ，基于集合的 需求更具表现力。例如，他们可以对值实施 OR 运算符：

或通过 存在 运算符限制负匹配：

一些 Kubernetes 对象，例如 services and replicationcontrollers ，也使用标签选择器来指定其他资源的集合，例如 pods 。

service 使用标签选择器定义目标的一组 pod 。类似地，a replicationcontroller 应该管理的 pod数量也由标签选择器定义。

两个对象的标签选择器都使用映射在 json 或 yaml 文件中定义，并且仅支持 基于相等的 要求选择器：

或者

此选择器（分别为 json 或 yaml 格式）等效于 component=redis 或 component in (redis) 。

较新的资源，如 Job ， Deployment ， ReplicaSet ，和 DaemonSet ，支持 基于组 的要求也是如此。

matchLabels 是对的映射 key,value 。map key,value 中的一个single matchLabels 相当于一个元素 matchExpressions ，其 key 字段为“key”，字段 operator 为“In”， values 数组中只包含“value”。 matchExpressions 是 pod 选择器要求的列表。有效的运算符包括 In、NotIn、Exists 和DoesNotExist。在 In 和 NotIn 的情况下，设置的值必须是非空的。来自 matchLabels 和 的所有要求都 matchExpressions 被 AND 运算在一起——它们必须全部得到满足才能匹配。

选择标签的一个用例是限制 pod 可以调度到的节点集。有关更多信息，请参阅有关 节点选择 的文档。

《Kubernetes网络权威指南》读书笔记 | 终于等到你：Kubernetes网络

书籍来源：《Kubernetes网络权威指南：基础、原理与实践》

一边学习一边整理读书笔记，并与大家分享，侵权即删，谢谢支持！

附上汇总贴：《Kubernetes网络权威指南》读书笔记 | 汇总_COCOgsta的博客-CSDN博客

---

Kubernetes网络包括网络模型、CNI、Service、Ingress、DNS等。

在Kubernetes的网络模型中，每台服务器上的容器有自己独立的IP段，各个服务器之间的容器可以根据目标容器的IP地址进行访问，如图3-4所示。

图3-4 Kubernetes网络模型概览

实现Kubernetes的容器网络重点需要关注两方面：IP地址分配和路由。

3.2.1 Kubernetes网络基础

下面简单介绍Kubernetes网络的基本概念和框架。

1. IP地址分配

Kubernetes使用各种IP范围为节点、Pod和服务分配IP地址。

• 系统会从集群的VPC网络为每个节点分配一个IP地址。
• 系统会为每个Pod分配一个地址块内的IP地址。
• 系统会从集群的VPC网络为每项服务分配一个IP地址（称为ClusterIP）。

1. Pod出站流量

Kubernetes处理Pod的出站流量的方式主要分为以下三种：

Pod到Pod

运行在Pod内的应用都可以使用标准的端口号，Pod之间可以保持三层网络的连通性。

Pod到Service

每台计算节点上都运行一个Kubeproxy进程，通过复杂的iptables/IPVS规则在Pod和Service之间进行各种过滤和NAT。

Pod到集群外

从Pod内部到集群外部的流量，Kubernetes会通过SNAT来处理。

3.2.2 Kubernetes网络架构综述

Kubernetes网络总体架构如图3-5所示。

图3-5 Kubernetes网络总体架构

具体过程如下：

（1）创建了一个Pod后，Kubelet调用CRI创建Pod内的若干个容器。

（2）第一个被创建的被称为pause容器，作用就是占用一个Linux的network namespace。

（3）Pod内其他用户容器通过加入这个network namespace的方式共享同一个network namespace。

（4）CNI主要负责容器的网络设备初始化工作，创建容器的eth0并分配IP，Pod内其他容器就使用这个IP与其他容器或节点进行通信。

3.2.3 Kubernetes主机内组网模型

Kubernetes经典的主机内组网模型是veth pair+bridge的方式。

Kubernetes使用veth pair将容器与主机的网络协议栈连接起来，从而使数据包可以进出Pod。容器放在主机根network namespace中veth pair的一端连接到Linux网桥，可让同一节点上的各Pod之间相互通信，如图3-6所示。

图3-6 Kubernetes bridge网络模型

3.2.4 Kubernetes跨节点组网模型

Kubernetes典型的跨机通信解决方案有bridge、overlay等。

Kubernetes的bridge跨机通信网络模型如图3-7所示。

图3-7 Kubernetes的bridge跨机通信网络模型

bridge网络本身不解决容器的跨机通信问题，需要显式地书写主机路由表，映射目标容器网段和主机IP的关系，集群内如果有N个主机，需要N-1条路由表项。

至于overlay网络，它是构建在物理网络之上的一个虚拟网络，其中VXLAN是主流的overlay标准。图3-8所示为典型的overlay网络的拓扑图。

图3-8 典型的overlay网络的拓扑图

和bridge网络类似，Pod同样接在Linux网桥上，目的地址落在本机Pod网段的网络包同样发给Linux网桥cni0。不同的是，这次是直接发给本机的tun/tap设备tun0，而tun0就是overlay隧道网络的入口。

3.2.5 Pod的hosts文件

与宿主机一样，容器也有/etc/hosts文件，用来记录容器的hostname和IP地址的映射关系。通过向Pod的/etc/hosts文件中添加条目，可以在Pod级别覆盖对hostname的解析。

当一个Pod被创建后，默认情况下，hosts文件只包含IPv4和IPv6的样板内容，例如localhost和主机名称。除了默认的样板内容，我们可能有向Pod的hosts文件添加额外的条目的需求，Kubernetes提供downward API，支持用户通过PodSpec的HostAliases字段添加这些自定义的条目，如下所示：

于是，Pod的hosts文件的内容类似如下：

建议通过使用HostAliases的方式进行修改，最主要的原因是该文件由Kubelet托管，用户修改该hosts文件的任何内容都会在容器重启或Pod重新调度后被Kubelet覆盖。

3.2.6 Pod的hostname

Pod之间主机名相互隔离，但Pod内容器分享同一个主机名。

一个Pod内如果有多个容器，修改任意一个容器的hostname都会影响其他容器，因为Pod共享UTS namespace。

容器重启带来的UTS namespace的改变也会导致hostname被覆盖。