k8s部署深度分析-优快云博客

部署代码案例如下：

如果有需要技术支持，或者需要解决问题的，的可以联系我。

##################################################################################################
# dubhe-admin
##################################################################################################
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: backend-admin
  namespace: dubhe-system
  labels:
    dubhe.io/owner: "dubhe"
    dubhe.io/application: "dubhe-backend-admin"
spec:
  replicas: 1
  selector:
    matchLabels:
      dubhe.io/owner: "dubhe"
      dubhe.io/application: "dubhe-backend-admin"
  template:
    metadata:
      labels:
        dubhe.io/owner: "dubhe"
        dubhe.io/application: "dubhe-backend-admin"
    spec:
      initContainers:
      - name: backend-init
        image: backend-init:v1
        command: ["/data/start.sh"]
        volumeMounts:
        - name: data
          mountPath: /nfs
      containers:
      - name: dubhe-backend-admin
        image: registry.cn-hangzhou.aliyuncs.com/enlin/dubhe-java:v1
        command: ["/bin/bash", "-c", "cd /data/ && java -Xms1024m -Xmx1024m   -jar admin-0.0.1-SNAPSHOT-exec.jar --spring.profiles.active=prod"]
        volumeMounts:
        - name: data
          mountPath: /nfs
      volumes:
      - name: data
        hostPath:
          path: /data/dubhe-storage

---
apiVersion: v1
kind: Service
metadata:
  name: backend-admin
  namespace: dubhe-system
  labels:
    dubhe.io/owner: "dubhe"
    dubhe.io/application: "dubhe-backend-admin"
spec:
  ports:
  - port: 8870
    targetPort: 8870
    name: port-8870
  selector:
    dubhe.io/owner: "dubhe"
    dubhe.io/application: "dubhe-backend-admin"

你提到的 “重复的代码” 主要是指 metadata.labels 和选择器（selector）中重复出现的标签（dubhe.io/owner: "dubhe" 和 dubhe.io/application: "dubhe-backend-admin"）。这些看似重复的配置，其实是 Kubernetes 中标签与选择器绑定机制的核心，每一处都有明确的作用，并非冗余。

一、拆解配置：每个 “重复” 标签的作用

这个 YAML 文件包含两个资源：Deployment（部署管理 Pod）和 Service（服务发现），我们逐一分析标签的作用：

1. Deployment 中的标签（`metadata.labels`）

yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: backend-admin
  namespace: dubhe-system
  labels:  # ① Deployment 自身的标签
    dubhe.io/owner: "dubhe"
    dubhe.io/application: "dubhe-backend-admin"

作用：给 Deployment 资源自身身打标签，用于识别和筛选 Deployment 资源本身（而非 Pod）。
例如，执行 kubectl get deployments -l dubhe.io/owner=dubhe -n dubhe-system 时，会筛选出带有这个标签的 Deployment。

2. Deployment 中 Pod 模板的标签（`template.metadata.labels`）

yaml

spec:
  template:
    metadata:
      labels:  # ② Pod 的标签（核心）
        dubhe.io/owner: "dubhe"
        dubhe.io/application: "dubhe-backend-admin"

作用：定义由这个 Deployment 创建的所有 Pod 会携带的标签。这是后续 Service 识别 Pod 的关键。
例如，Deployment 创建的 Pod 都会带有这两个标签，用于和其他 Pod 区分。

3. Deployment 的选择器（`spec.selector`）

yaml

spec:
  selector:  # ③ Deployment 关联 Pod 的选择器
    matchLabels:
      dubhe.io/owner: "dubhe"
      dubhe.io/application: "dubhe-backend-admin"

作用：告诉 Deployment “需要管理哪些 Pod”—— 只有带有这些标签的 Pod 才会被这个 Deployment 控制（如扩缩容、滚动更新）。
必须与 template.metadata.labels 完全一致，否则 Deployment 会找不到自己创建的 Pod。

4. Service 中的标签（`metadata.labels`）

yaml

apiVersion: v1
kind: Service
metadata:
  name: backend-admin
  namespace: dubhe-system
  labels:  # ④ Service 自身的标签
    dubhe.io/owner: "dubhe"
    dubhe.io/application: "dubhe-backend-admin"

作用：给 Service 资源自身打标签，用于识别和筛选 Service 资源本身。
例如，执行 kubectl get services -l dubhe.io/application=dubhe-backend-admin -n dubhe-system 时，会快速找到这个 Service。

5. Service 的选择器（`spec.selector`）

yaml

spec:
  selector:  # ⑤ Service 关联 Pod 的选择器
    dubhe.io/owner: "dubhe"
    dubhe.io/application: "dubhe-backend-admin"

作用：告诉 Service “需要转发流量到哪些 Pod”—— 只有带有这些标签的 Pod，才会被 Service 纳入负载均衡范围。
必须与 Pod 的标签（template.metadata.labels）一致，否则 Service 会找不到目标 Pod（Endpoints 为空）。

二、为什么需要 “重复”？

这些标签看似重复，实则是 Kubernetes “松耦合” 设计的体现：

Deployment 只负责管理带特定标签的 Pod（通过 spec.selector），即使这些 Pod 不是它创建的，只要标签匹配，也会被纳入管理（实际中通常是自己创建的）。
Service 只负责转发流量到带特定标签的 Pod（通过 spec.selector），无论这些 Pod 是由哪个 Deployment 管理的，只要标签匹配就能被访问。
标签是跨资源关联的 “桥梁”：如果后续需要用另一个 Deployment 替换当前 Deployment，只需保证新 Pod 的标签不变，Service 就能无缝对接，无需修改 Service 配置。

三、执行 `kubectl apply -f backend-admin.yaml` 后的效果

创建 Deployment：
- 生成 1 个 Pod（replicas: 1），Pod 带有标签 dubhe.io/owner: "dubhe" 和 dubhe.io/application: "dubhe-backend-admin"。
- Deployment 通过选择器关联这些 Pod，负责维护 Pod 的数量和状态。
创建 Service：
- Service 通过选择器匹配上述 Pod，生成一个集群内的虚拟 IP（CLUSTER-IP）。
- 集群内其他 Pod 可通过 backend-admin.dubhe-system.svc.cluster.local:8870 访问这些 Pod 的 8870 端口，Service 会自动负载均衡（如果有多个 Pod）。

总结

这些 “重复” 的标签和选择器是 Kubernetes 中资源关联的核心机制：

Deployment 的标签 → 用于识别 Deployment 自身；
Pod 的标签 + Deployment 选择器 → 用于 Deployment 管理 Pod；
Pod 的标签 + Service 选择器 → 用于 Service 转发流量到 Pod；
Service 的标签 → 用于识别 Service 自身。

看似冗余，实则每一处都不可或缺，确保了 Kubernetes 中资源的灵活关联和管理。

这个labels实际上就是id，那为何不使用id捏

在 Kubernetes 中，标签（labels）和 ID 虽然都能用于标识资源，但设计理念和作用场景有本质区别。标签并非简单的 “替代 ID”，而是一种更灵活的 **“多维度分类机制”**，这也是 Kubernetes 不直接用 ID 来关联资源的核心原因。

一、ID 的问题：唯一性 vs 灵活性

Kubernetes 中的每个资源（如 Pod、Deployment、Service）都有一个唯一的 ID（由系统自动生成，如 metadata.uid），例如：

yaml

metadata:
  uid: 7f9b8f4d9d-xyzabc  # 资源唯一 ID，系统自动生成

但 ID 有两个致命缺陷，导致无法用于资源关联：

不可控：ID 由 Kubernetes 自动生成（如随机字符串），用户无法自定义，无法通过 ID 表达资源的 “含义”（如 “这是一个后端服务”“属于 dubhe 项目”）。
单一维度：一个资源只能有一个 ID，无法从多个维度对资源进行分类（如同时标记 “环境 = 生产”“部门 = 研发”“功能 = 支付”）。

二、标签（`labels`）的核心优势：多维度、可自定义、松耦合

标签本质是 **“键值对”（如 dubhe.io/owner: "dubhe"），设计目的是为资源提供灵活的分类和筛选能力 **，这是 ID 无法实现的：

1. 多维度分类

一个资源可以有多个标签，从不同维度描述其属性。例如：

yaml

labels:
  dubhe.io/owner: "dubhe"    # 所属项目
  dubhe.io/application: "admin"  # 应用名称
  environment: "production"  # 环境
  version: "v1"              # 版本

通过这些标签，可以轻松筛选出 “生产环境中属于 dubhe 项目的 v1 版本 admin 应用”，而 ID 无法承载这些信息。

2. 资源关联的 “松耦合”

Kubernetes 中，Deployment 管理 Pod、Service 转发流量到 Pod，都是通过标签选择器（selector）实现的，而非 ID：

假设某个 Pod 因故障重启，新 Pod 的 ID 会变化，但只要标签不变，Deployment 和 Service 仍能识别它（无需修改任何配置）。
如果用 ID 关联，Pod 重启后 ID 改变，所有关联的 Deployment、Service 都需要手动更新，这在动态变化的容器环境中完全不可行。

3. 适配动态扩缩容和滚动更新

当 Deployment 扩缩容时，新创建的 Pod 会自动继承标签，被 Deployment 和 Service 识别，无需手动干预。
滚动更新时，旧版本 Pod 会被逐步替换为新版本 Pod，只要新旧 Pod 保持相同标签，Service 就能无缝切换流量（用户无感知）。

三、标签与 ID 的分工：各有其用

ID（metadata.uid）：唯一标识一个资源实例，用于 Kubernetes 内部追踪资源的生命周期（如删除、更新时确保操作的是特定实例），用户几乎不需要关心。
标签（labels）：用于用户层面的资源分类、筛选和关联，是 Kubernetes 中 “声明式管理” 和 “动态扩缩容” 的核心支撑。

举例：为什么 ID 无法替代标签？

假设用 ID 关联 Service 和 Pod：

初始状态：Service 关联 Pod ID pod-123。
Pod 故障重启，新 Pod ID 变为 pod-456。
此时 Service 仍指向 pod-123，导致流量无法转发到新 Pod，服务中断。

而用标签关联时：

新旧 Pod 都带有标签 app: admin。
Service 始终通过 app: admin 选择 Pod，无论 Pod 如何重启或更新，只要标签不变，流量就能正常转发。

总结

标签不是 “ID 的替代品”，而是 Kubernetes 为应对动态、复杂的容器环境设计的多维度分类工具。它解决了 ID 无法表达资源含义、无法多维度筛选、无法适应资源动态变化的问题，是实现 Deployment 管理 Pod、Service 负载均衡等核心功能的基础。这种设计让 Kubernetes 具备了高度的灵活性和可扩展性，这也是容器编排平台的关键特性。