📚 课程目录第2章 K8s核心架构回顾

2. K8s核心架构回顾：Master/Node组件、Pod、Service、Deployment、Namespace核心概念与资源模型

在深入容量性能压测与巡检脚本编排之前，必须对Kubernetes的核心架构与资源模型建立清晰、准确的认识。本章将系统回顾Master/Node组件、核心工作负载资源以及资源管理模型，为后续的压测目标设定、巡检指标采集和故障排查奠定基础。

2.1 Master与Node组件架构

Kubernetes集群由控制平面（Master）和工作节点（Node）组成。控制平面负责全局决策与集群状态管理，工作节点负责运行容器化应用。

  关键理解：Master组件是集群的“大脑”，Node组件是“肌肉”。压测时，Master组件的性能瓶颈（如etcd延迟、API Server吞吐）直接影响集群的调度与扩缩容能力；Node组件的资源耗尽（CPU、内存、磁盘）则直接导致Pod驱逐与应用故障。

2.2 核心资源对象详解

Kubernetes 的一切皆资源。以下四个资源对象是日常运维与压测中最常打交道的核心。

资源对象	API 版本 (稳定)	核心作用	压测关注点
Pod	v1	最小的部署单元，包含一个或多个容器，共享网络栈与存储卷	Pod 启动时间、重启次数、资源限制（requests/limits）
Service	v1	提供稳定的网络端点，通过标签选择器关联一组 Pod，实现负载均衡与服务发现	Service 后端 Pod 数量、连接延迟、会话保持
Deployment	apps/v1	声明式管理 Pod 副本数，支持滚动更新、回滚、扩缩容	副本数变化速率、更新策略（maxSurge/maxUnavailable）
Namespace	v1	虚拟集群隔离，用于多租户、环境划分（dev/staging/prod）	资源配额（ResourceQuota）、网络策略隔离

巡检提示：在压测前，务必检查 Deployment 的 spec.replicas、spec.template.spec.containers[].resources 以及 Service 的 spec.selector 是否与目标 Pod 标签匹配。标签不匹配是导致压测流量“空转”的常见原因。

2.3 Pod 与容器的资源模型

Kubernetes 资源模型的核心是 Requests 和 Limits。这两个字段决定了 Pod 的调度优先级、QoS 等级以及节点资源超卖程度。

Requests：容器保证的最小资源量，调度器据此选择满足条件的节点。
Limits：容器可使用的资源上限，防止单个 Pod 耗尽节点资源。

根据 Requests 和 Limits 的设置，Pod 被划分为三种 QoS 等级：

QoS 等级	条件	节点资源压力时的行为	压测影响
Guaranteed	所有容器 Requests == Limits	最优先保留，几乎不会被驱逐	适合压测目标应用，性能稳定
Burstable	至少一个容器 Requests < Limits	当节点资源不足时，可能被驱逐	压测时可能出现突发抖动
BestEffort	所有容器未设置 Requests 和 Limits	最先被驱逐，无资源保障	不推荐用于压测，结果不可预测

# 一个典型的 Guaranteed Pod 资源定义
apiVersion: v1
kind: Pod
metadata:
  name: stress-test-pod
spec:
  containers:
  - name: stress-container
    image: polinux/stress
    resources:
      requests:
        cpu: "1"
        memory: "512Mi"
      limits:
        cpu: "1"
        memory: "512Mi"
    command: ["stress"]
    args: ["--cpu", "1", "--vm", "1", "--vm-bytes", "256M", "--timeout", "60s"]

2.4 Namespace 与资源隔离

Namespace 是 Kubernetes 实现多租户隔离的基础。在压测场景中，建议为每轮压测创建独立的 Namespace，以便于资源清理和指标隔离。

资源配额（ResourceQuota）：限制 Namespace 级别的总资源消耗（CPU、内存、Pod 数量等）。
限制范围（LimitRange）：为 Namespace 内的 Pod 或容器设置默认的 Requests/Limits。

常见故障：压测时创建大量 Pod 但未设置 ResourceQuota，可能导致 Namespace 资源耗尽，影响同集群其他业务。始终在压测 Namespace 中设置合理的 ResourceQuota 和 LimitRange。

2.5 核心组件交互流程

理解组件间的交互流程，有助于在压测故障排查时快速定位问题环节。以下是一个 Pod 创建与 Service 访问的典型流程：

用户提交：通过 kubectl apply 或 API 调用创建 Deployment。
API Server 验证与存储：kube-apiserver 验证请求，将资源对象写入 etcd。
Scheduler 调度：kube-scheduler 监听未调度的 Pod，根据资源请求与节点状态选择合适节点。
kubelet 创建 Pod：目标节点的 kubelet 通过容器运行时创建并启动容器。
kube-proxy 更新规则：kube-proxy 监听 Service 与 Endpoint 变化，更新节点 iptables/IPVS 规则。
流量到达：客户端通过 Service ClusterIP/NodePort/LoadBalancer 访问后端 Pod。

  压测故障排查切入点：
  Pod 创建慢 → 检查 etcd 延迟、Scheduler 队列长度、节点资源是否充足。
Service 访问不通 → 检查 kube-proxy 规则、Endpoint 是否就绪、网络策略。
滚动更新卡住 → 检查 Deployment 的 maxSurge/maxUnavailable 配置、Pod 健康检查。

2.6 资源模型与压测指标映射

将 Kubernetes 资源模型与压测指标建立映射关系，是制定巡检脚本的基础。

K8s 资源/组件	关键压测指标	巡检脚本采集方式
Pod	启动时间、重启次数、CPU/Memory 使用率	`kubectl get pods -o wide` + Metrics Server
Node	节点资源分配率、磁盘 IO、网络带宽	`kubectl top nodes` + node_exporter
API Server	请求延迟、QPS、错误率	Prometheus metrics endpoint
etcd	读写延迟、Leader 变更次数、DB 大小	etcd metrics / `etcdctl endpoint status`
Service	连接延迟、后端 Pod 分布、连接数	网络探测 + Service 监控