K8s 架构与核心概念深度解析

Kubernetes 是云原生的基石。从容器编排到服务治理，K8s 已成为现代应用部署的标准。 本文深入剖析 K8s 架构设计、核心组件原理、资源对象模型，与 k8s-interview-100-questions（100 题 Q&A 速查）形成互补。 本文为面试通关系列第一篇；后续将涵盖网络与存储、调度与安全等专题。

一、K8s 架构设计

整体架构

┌─────────────────────────────────────────────────┐
│                  Control Plane                    │
│  ┌──────────┐  ┌──────────┐  ┌──────────┐       │
│  │API Server│  │ Scheduler│  │Controller│       │
│  │          │  │          │  │ Manager  │       │
│  └────┬─────┘  └────┬─────┘  └────┬─────┘       │
│       │              │              │             │
│       └──────────────┼──────────────┘             │
│                      │                            │
│               ┌──────┴──────┐                    │
│               │    etcd     │                    │
│               └─────────────┘                    │
└──────────────────────┬──────────────────────────┘
                       │
┌──────────────────────┼──────────────────────────┐
│                 Worker Nodes                      │
│  ┌──────────┐  ┌──────────┐  ┌──────────┐       │
│  │ Kubelet  │  │Kube-proxy│  │Container │       │
│  │          │  │          │  │ Runtime  │       │
│  └──────────┘  └──────────┘  └──────────┘       │
│                                                    │
│  ┌──────────────────────────────────────────┐    │
│  │              Pods (业务容器)                │    │
│  └──────────────────────────────────────────┘    │
└──────────────────────────────────────────────────┘

Control Plane 组件

Worker Node 组件

核心设计理念

• 声明式 API：描述期望状态，控制器自动调谐
• 控制循环（Control Loop）：观测 → 比较 → 执行 → 循环
• 松耦合：组件通过 API Server 通信，Watch 机制驱动
• 可扩展：CRD（自定义资源）、Webhook、CNI/CSI/CRI 接口
• 自愈能力：控制器持续调谐，保证期望状态

与 k8s-troubleshooting-principles 结合可理解排障的底层逻辑。

二、核心资源对象

Pod — 最小调度单元

Pod
├── 共享网络命名空间（共享 IP + 端口空间）
├── 共享 IPC 命名空间
├── 共享存储卷（Volume）
└── 容器集合
    ├── 业务容器（主容器）
    └── Init 容器 / Sidecar 容器

关键特性：

• 同一 Pod 内容器通过 localhost 通信
• Pod 是临时性资源，IP 可能变化
• 健康检查：Liveness Probe（重启）/ Readiness Probe（流量）/ Startup Probe（慢启动）

详见 pod-troubleshooting（Pod 排障）和 k8s-probes-guide（探针机制）。

Deployment — 无状态应用管理

apiVersion: apps/v1
kind: Deployment
spec:
  replicas: 3                    # 期望副本数
  strategy:
    type: RollingUpdate          # 滚动更新策略
    rollingUpdate:
      maxSurge: 1                # 最多额外 Pod 数
      maxUnavailable: 0          # 最多不可用 Pod 数
  selector:
    matchLabels:
      app: nginx
  template:                      # Pod 模板
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.21

Deployment 控制器工作流程：

1. 用户创建/更新 Deployment → API Server 持久化到 etcd
2. Deployment Controller Watch 到变更
3. 创建 ReplicaSet（版本管理）
4. ReplicaSet Controller 创建/删除 Pod
5. Scheduler 调度 Pod 到节点
6. Kubelet 创建容器

滚动更新风险防范参见 k8s-rolling-update-pitfalls。

Service — 服务发现与负载均衡

四种类型：

Service 如何找到 Pod：

Service (selector: app=nginx)
  → Endpoints (自动创建)
    → Pod IP 列表
      → kube-proxy 更新 iptables/ipvs 规则

详见 service-troubleshooting（Service 排障）和 k8s-service-access-troubleshooting（十步排查流程）。

Ingress — 七层路由

apiVersion: networking.k8s.io/v1
kind: Ingress
spec:
  rules:
  - host: api.example.com
    http:
      paths:
      - path: /users
        pathType: Prefix
        backend:
          service:
            name: user-service
            port:
              number: 80

Ingress vs Service：

• Service：L4 负载均衡（TCP/UDP）
• Ingress：L7 路由（HTTP/HTTPS），支持基于域名/路径的路由、SSL 终止

三、工作负载管理

StatefulSet — 有状态应用

适用场景： 数据库（MySQL/PostgreSQL）、消息队列（Kafka）、分布式存储

详见 k8s-statefulset-guide（StatefulSet 完全指南）。

DaemonSet — 每节点一个 Pod

kind: DaemonSet
spec:
  template:
    spec:
      containers:
      - name: log-collector
        image: fluentd

典型用途： 日志采集（Fluentd）、监控代理（Node Exporter）、网络插件（Calico/Fannel）

Job / CronJob — 任务型工作负载

# Job: 一次性任务
kind: Job
spec:
  completions: 1
  template: ...

# CronJob: 定时任务
kind: CronJob
spec:
  schedule: "0 2 * * *"
  jobTemplate: ...

四、服务发现机制

服务发现流程

Pod → DNS 查询 (my-svc.default.svc.cluster.local)
  → CoreDNS 解析
    → 返回 Service ClusterIP
      → kube-proxy iptables/ipvs 规则
        → 负载均衡到后端 Pod

DNS 命名规范

<pod-ip>.<namespace>.pod.cluster.local       # Pod DNS
<svc-name>.<namespace>.svc.cluster.local     # Service DNS
<statefulset-pod>.<headless-svc>.<ns>.svc.cluster.local  # StatefulSet 稳定 DNS

Endpoints 与 EndpointSlice

• Endpoints：存储 Service 对应的 Pod IP 列表
• EndpointSlice：K8s 1.21+ 的替代方案，将 Endpoints 分片提高扩展性

详见 k8s-coredns-custom-domain-resolution（CoreDNS 自定义域名）。

五、配置管理

ConfigMap — 非敏感配置

apiVersion: v1
kind: ConfigMap
metadata:
  name: app-config
data:
  database_url: "mysql://db:3306/mydb"
  log_level: "info"

使用方式：

1. 环境变量注入（envFrom.configMapRef）
2. 文件挂载（volumes.configMap）
3. 命令行参数

🔥 常见踩坑： ConfigMap 以 Volume 挂载时创建符号链接，应用以 inotify 监听可能不触发；热更新有延迟。

详见 configmap-mount-pitfalls（ConfigMap 挂载踩坑指南）。

Secret — 敏感信息

apiVersion: v1
kind: Secret
type: Opaque
data:
  password: bXlwYXNzd29yZA==   # base64 编码

⚠️ Secret 默认 base64 编码而非加密，生产环境应配合 etcd 加密 + RBAC 最小权限。

PV / PVC — 持久化存储

PV (PersistentVolume)  ← 集群管理员创建（或 StorageClass 动态创建）
PVC (PersistentVolumeClaim) ← 用户申请存储
StorageClass ← 定义存储类型（SSD/HDD，云盘/NFS）

绑定流程：

PVC 创建 → 查找匹配 PV（容量/访问模式/StorageClass）
  → 匹配成功 → 绑定
  → 匹配失败 → Pending（等待动态创建或手动 PV）

详见 k8s-persistent-storage-guide（PV/PVC 生产实战）和 storage-troubleshooting（存储排障）。

六、核心工作流程

Pod 创建全流程

1. 用户提交 Pod YAML → API Server
2. API Server 认证/授权/准入控制 → 写入 etcd
3. Scheduler Watch 到未调度 Pod → 过滤+打分 → 选择节点 → 更新 Pod.nodeName
4. 目标节点 Kubelet Watch 到分配给自己的 Pod
5. Kubelet 调用 CRI 创建容器
6. Kubelet 更新 Pod 状态为 Running

声明式 API 与控制循环

期望状态（YAML） → API Server → etcd
                                ↓
                          Controller Watch
                                ↓
                    当前状态 vs 期望状态
                      ↓            ↓
                    一致          不一致 → 调谐（Reconcile）
                                         ↓
                                    执行操作
                                         ↓
                                    回到 Watch

关联页面