2. 核心 API 资源模型：Pod、Service、Deployment 等核心资源的 Group/Version/Kind 结构、资源元数据与 Spec/Status 设计模式

Kubernetes 的声明式 API 是控制平面的核心交互界面。每个资源对象都遵循统一的 Group/Version/Kind (GVK) 标识体系，并采用 Spec/Status 设计模式来分离用户期望状态与系统实际状态。本章将深入剖析 Pod、Service、Deployment 等核心资源的 GVK 结构、元数据规范以及 Spec/Status 的实现细节。

2.1 Group/Version/Kind (GVK) 标识体系

Kubernetes API 使用 GVK 三元组唯一标识一个资源类型。Group 表示资源的功能域（如 apps、networking.k8s.io），Version 表示 API 的成熟度（如 v1、v1beta1），Kind 表示资源的具体类型（如 Pod、Deployment）。

2.2 资源元数据 (ObjectMeta) 设计

每个 Kubernetes 资源都包含一个 metadata 字段，用于描述资源的标识、标签、注解、所有权和生命周期信息。元数据是资源模型的基础层，所有 GVK 资源共享同一套元数据结构。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  namespace: production
  labels:
    app: nginx
    tier: frontend
  annotations:
    deployment.kubernetes.io/revision: "3"
    prometheus.io/scrape: "true"
  ownerReferences:
    - apiVersion: apps/v1
      kind: ReplicaSet
      name: nginx-deployment-7d8f9c
      uid: a1b2c3d4-e5f6-7890-abcd-ef1234567890
  finalizers:
    - foregroundDeletion
  managedFields:
    - manager: kube-controller-manager
      operation: Update
      apiVersion: apps/v1
      fieldsType: FieldsV1
      fieldsV1:
        f:spec:
          f:replicas: {}

2.3 Spec/Status 设计模式

Kubernetes 资源模型的核心设计哲学是 声明式期望状态 (Spec) 与观测实际状态 (Status) 的分离。这种模式使得控制器可以持续协调，将系统从当前状态驱动到期望状态。

2.4 核心资源 Spec/Status 深度解析

2.4.1 Pod：原子调度单元

Pod 是 Kubernetes 中最小的部署和调度单元。其 Spec 定义了容器的运行期望，Status 则反映 Pod 的生命周期阶段和网络信息。

apiVersion: v1
kind: Pod
metadata:
  name: web-pod
  labels:
    app: web
spec:
  containers:
    - name: nginx
      image: nginx:1.25
      ports:
        - containerPort: 80
      resources:
        requests:
          memory: "64Mi"
          cpu: "250m"
        limits:
          memory: "128Mi"
          cpu: "500m"
  restartPolicy: Always
  nodeSelector:
    disktype: ssd
status:
  phase: Running
  conditions:
    - type: Ready
      status: "True"
      lastTransitionTime: "2024-01-15T10:30:00Z"
  hostIP: 10.0.0.5
  podIP: 192.168.1.10
  containerStatuses:
    - name: nginx
      ready: true
      restartCount: 0
      state:
        running:
          startedAt: "2024-01-15T10:30:05Z"

2.4.2 Service：稳定的网络抽象

Service 为一组动态变化的 Pod 提供稳定的网络端点。其 Spec 定义了选择器和端口映射，Status 则包含负载均衡的端点信息。

apiVersion: v1
kind: Service
metadata:
  name: web-service
spec:
  selector:
    app: web
  ports:
    - protocol: TCP
      port: 80
      targetPort: 8080
  type: ClusterIP
  clusterIP: 10.96.0.1
status:
  loadBalancer:
    ingress:
      - ip: 203.0.113.10
  conditions:
    - type: LoadBalancerReady
      status: "True"

2.4.3 Deployment：声明式工作负载管理

Deployment 是管理无状态应用最常用的资源。它通过 ReplicaSet 实现 Pod 的滚动更新、回滚和扩缩容。其 Spec 定义了副本数、更新策略和 Pod 模板，Status 则跟踪更新进度和可用性。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 1
      maxSurge: 1
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
        - name: nginx
          image: nginx:1.25
          ports:
            - containerPort: 80
status:
  observedGeneration: 3
  replicas: 3
  updatedReplicas: 3
  readyReplicas: 3
  availableReplicas: 3
  conditions:
    - type: Available
      status: "True"
      lastUpdateTime: "2024-01-15T11:00:00Z"
      reason: MinimumReplicasAvailable
    - type: Progressing
      status: "True"
      reason: NewReplicaSetAvailable

2.5 资源模型版本演进与兼容性

Kubernetes 通过 API 版本机制管理资源模型的演进。不同版本之间通过 内部版本 (Internal Version) 进行转换，确保向后兼容。

2.6 资源模型准入策略适配要点

当 API 版本演进时，资源模型的 Spec 字段可能发生变化。准入控制器（如 MutatingWebhook、ValidatingWebhook）需要适配不同版本的资源模型，确保策略的正确执行。

• 版本感知的默认值注入： MutatingWebhook 需要根据请求的 API 版本注入对应版本的默认值。例如，apps/v1beta1 的 Deployment 可能缺少 spec.progressDeadlineSeconds 字段，而 apps/v1 则必须包含。
• 字段兼容性检查： ValidatingWebhook 应验证字段在不同版本间的兼容性。例如，v1 中废弃的字段在 v1beta1 中可能仍然可用，但应发出警告。
• 转换 Webhook 的字段映射： 对于 CRD 的自定义版本，ConversionWebhook 需要正确处理 Spec 和 Status 字段的映射关系，确保数据不丢失。
• Status 子资源的写保护： 准入控制器应确保普通用户无法直接修改 Status 字段，只有控制器和具有 update/status 权限的主体才能写入 Status。