Kubernetes 深入与服务网格

🎯学习目标

• 掌握资源请求与限制、调度器预选/优选原理；
• 理解节点亲和性、Pod 亲和/反亲和、污点与容忍；
• 掌握 StatefulSet 与 Deployment 区别、Headless Service、VolumeClaimTemplates；
• 理解 ConfigMap 与 Secret 的配置解耦；
• 掌握持久化存储三层架构（PV / PVC / StorageClass）与动态供给；
• 理解 Service Mesh 与 Istio 架构、Sidecar、流量管理、mTLS、金丝雀发布。

1资源请求与限制（Requests & Limits）

ResourceQuota 与 LimitRange

2调度器原理与亲和性 ⭐

调度（Scheduling）是将未绑定节点的 Pod 分配到合适 Worker 节点的过程，kube-scheduler 通过两阶段筛选完成。

常见预选规则

PodFitsResources（剩余资源 ≥ Request）、PodFitsHostPorts（端口无冲突）、MatchNodeSelector（标签匹配）、NoTaintUnlessTolerated（污点需被容忍）、CheckNodeMemoryPressure（无内存压力）。

常见优选规则

LeastRequestedPriority（剩余资源最多优先，分散调度）、BalancedResourceAllocation（CPU/内存更均衡）、NodeAffinityPriority、InterPodAffinityPriority。

亲和性

3污点与容忍（Taints & Tolerations）

污点（Taint）是节点的属性，表示节点拒绝特定 Pod；容忍（Toleration）是 Pod 的属性，表示可以容忍某节点的污点。

典型场景：GPU 节点 Taint 为 gpu=true:NoSchedule，只有需要 GPU 的 Pod 才容忍；Master 节点默认 Taint node-role.kubernetes.io/master:NoSchedule，避免业务 Pod 调度到 Master。

4StatefulSet 有状态应用管理 ⭐

StatefulSet 为每个 Pod 提供稳定的网络标识和持久化存储，确保 Pod 身份在重建后保持不变。

核心组件

• Headless Service（clusterIP: None）：普通 Service 有 ClusterIP 做负载均衡；Headless 不分配 IP，直接返回后端 Pod 的 IP 列表，配合 StatefulSet 生成稳定 DNS 记录 pod-name.service-name。
• VolumeClaimTemplates：Deployment 所有 Pod 共享一个 PVC（通常只读）；StatefulSet 需要每个 Pod 有自己独立的 PVC（自动化存储绑定）。

5ConfigMap 与 Secret（配置解耦）

Secret 类型：Opaque（通用，默认）、kubernetes.io/tls（TLS 证书 tls.crt + tls.key）、kubernetes.io/dockerconfigjson（Registry 认证）、kubernetes.io/service-account-token（SA Token）。

6持久化存储 PV / PVC / StorageClass ⭐

容器文件系统是临时的——重启或删除后数据丢失。有状态应用需持久化存储。K8s 存储三层架构：Pod → PVC（存储请求）→ PV（存储资源）→ 底层存储（云盘/NFS/Ceph）。

访问模式与回收策略

静态 vs 动态供给

静态供给：管理员手动预创建 PV → 开发者创建 PVC → K8s 寻找匹配 PV 绑定。问题：需提前创建大量 PV、大小不一定匹配、无法自动化。
动态供给：StorageClass 定义供给者（Provisioner），PVC 匹配某 StorageClass 时自动创建对应 PV。

# 动态供给流程
PVC 请求（storageClassName: fast-ssd, 100Gi）
  → StorageClass（provisioner: aws-ebs）
  → 自动创建 100Gi EBS 卷
  → 创建 PV 并绑定 PVC
  → Pod 使用 PVC

7Service Mesh 与 Istio ⭐

随着微服务数量增长，服务间通信面临流量管理、安全、可观测性挑战。传统方式在每个服务中嵌入 SDK（Spring Cloud、Hystrix）——语言绑定、侵入性强。

Istio 架构（控制面 + 数据面）

Istio 由 Google、IBM、Lyft 共同开发，是最流行的 Service Mesh 实现。

8Sidecar 代理（Envoy）与流量管理

Sidecar 模式：Istio 通过自动注入（Injection）为每个 Pod 添加一个 Envoy 代理容器，所有进出 Pod 的网络流量都被 Envoy 拦截和处理。

Envoy：Lyft 开发的高性能 L4/L7 代理，CNCF 毕业项目，是 Istio 数据面核心。能力：L7 路由（基于 HTTP 头/路径/权重）、负载均衡、熔断、重试、超时、自动 mTLS、可观测性（Prometheus 指标 + Jaeger 追踪）。

流量管理

• VirtualService（路由规则）：决定请求到达 Service 后，去哪个版本的 Pod。
• DestinationRule：定义子集（Subsets，把一个 Service 的 Pod 划分为 v1、v2）与 TrafficPolicy（负载均衡策略、连接池、熔断）。

9mTLS 安全与金丝雀发布

Istio 安全：mTLS

mTLS（Mutual TLS）是双向 TLS 认证。传统 TLS 只有客户端验证服务端证书，mTLS 要求双方互相验证身份。流程：Citadel 为每个服务自动签发 X.509 证书 → Envoy 自动用证书建立 mTLS 连接 → 应用代码无需修改，加密对应用透明。

金丝雀发布（Canary Release）

渐进式发布策略：先将少量流量导向新版本，观察无异常后逐步扩大，直到全量切换。Istio 通过修改 VirtualService 权重实现：

# 阶段1: v1=100%, v2=0%   → 部署 v2，不导流量
# 阶段2: v1=90%,  v2=10%  → 10% 流量到 v2，观察指标
# 阶段3: v1=50%,  v2=50%  → 扩大到 50%
# 阶段4: v1=0%,   v2=100% → 全量切换到 v2

⭐重点例题

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: redis
spec:
  serviceName: redis-svc      # 关联 Headless Service
  replicas: 3                 # web-0, web-1, web-2 有序固定
  selector:
    matchLabels: { app: redis }
  template:
    metadata:
      labels: { app: redis }
    spec:
      containers:
      - name: redis
        image: redis:7
        volumeMounts:
        - name: data
          mountPath: /data
  volumeClaimTemplates:        # 每个 Pod 独立 PVC
  - metadata:
      name: data
    spec:
      accessModes: ["ReadWriteOnce"]
      resources:
        requests:
          storage: 5Gi

🎯自测（点击展开）

📝强化题库

选择题点选即时判分；填空题输入后"检查"或"显示答案"。