第十一章：云原生彼岸 - Kubernetes群岛的迷雾之战

---

知识具象化场景

陆小柒穿越至由Kubernetes集群构成的漂浮群岛，云海间穿梭着Pod形态的飞艇：

• 控制平面神殿：API Server化作中央水晶塔，Etcd星轨环绕其运行，Scheduler是调度罗盘，Controller Manager是齿轮阵列
• 节点浮岛：每个岛屿由Kubelet引擎驱动，Docker容器是岛上的魔法小屋，CNI网络化作岛屿间的彩虹桥
• 服务网格迷宫：Istio的Envoy Sidecar组成镜面回廊，VirtualService是悬浮路标，mTLS加密符文在墙面闪烁
• Helm星图：Chart仓库是旋转的星盘，Release版本化作流星轨迹，values.yaml是调控参数的符文石板
• 十二要素法典：悬浮空中的发光碑文，刻有“基准代码/依赖/配置/后端服务/构建发布/进程/端口绑定/并发/易处理/开发与生产等价/日志/管理进程”

---

实战代码谜题

任务： 修复被篡改的Deployment咒文

# 漏洞百出的Pod炼成阵（导致OOMKilled）
apiVersion: apps/v1
kind: Deployment
metadata:
  name: soul-forge
spec:
  replicas: 3
  template:
    spec:
      containers:
      - name: demon-smith
        image: quay.io/hellforge:latest
        resources: 
          requests: # 缺失内存请求
            cpu: "2"
        ports:
        - containerPort: 6666

正确解法：

1. 补充内存资源限制
2. 添加健康检查探针
3. 设置Pod安全策略

resources:
  requests:
    cpu: "1"
    memory: "512Mi"
  limits:
    memory: "2Gi"
livenessProbe:
  httpGet:
    path: /health
    port: 8080
securityContext:
  runAsNonRoot: true
  capabilities:
    drop: ["ALL"]

---

原理剖析（群岛对话）

Kubernetes大祭司（手持kubectl权杖）：
“看这ReplicaSet的平衡术！（权杖挥出金光）当Pod飞艇坠毁，控制器通过spec.replicas（浮现数字3的符文）召唤新的飞艇，维持副本数的时空平衡…”

陆小柒（触碰Service的虚拟IP光环）：
“这些ClusterIP如何穿透节点结界？”

祭司（激活kube-proxy的iptables模型）：
“每个节点的kube-proxy（浮现规则链条）将虚拟IP映射到Endpoint（展示Pod IP列表），就像在群岛间架设隐形桥梁！”

Istio先知（从服务网格走出）：
“Envoy Sidecar是每个Pod的守护灵（展示流量镜像），它劫持进出容器的所有请求，实施路由/熔断/监控——如同在迷宫设置全息路标！”

---

陷阱关卡

危机： HPA配置错误引发的死亡螺旋

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: soul-forge
  minReplicas: 1
  maxReplicas: 100
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 1000 # 错误阈值

破局步骤：

1. 发现CPU利用率目标值过高
2. 监控到无限扩容触发云供应商配额限制
3. 修正为合理阈值并添加冷却时间

averageUtilization: 60
behavior:
  scaleDown:
    stabilizationWindowSeconds: 300 # 缩容冷却

---

性能优化挑战

任务： 镇压万级QPS的API风暴
原始配置：

# 无限制的Pod导致资源争抢
apiVersion: apps/v1
kind: Deployment
spec:
  replicas: 50
  strategy:
    rollingUpdate:
      maxSurge: 100%
      maxUnavailable: 100%

优化方案：

1. 配置合理的QoS等级
2. 启用PodDisruptionBudget保护
3. 采用KEDA自动缩放

resources:
  requests:
    cpu: "500m"
    memory: "1Gi"
  limits:
    cpu: "2"
    memory: "4Gi"
---
apiVersion: policy/v1
kind: PodDisruptionBudget
spec:
  minAvailable: 80%
---
apiVersion: keda.sh/v1alpha1
kind: ScaledObject
spec:
  triggers:
  - type: prometheus
    metadata:
      serverAddress: http://prometheus:9090
      metricName: http_requests_total
      threshold: "1000"

---

本章技术总结

核心概念	现实映射	奇幻隐喻
Pod	最小调度单元	魔法飞艇
Service Mesh	服务间通信管理层	镜面迷宫
Operator	CRD扩展机制	自动化傀儡术
Sidecar	辅助容器模式	守护灵附体
GitOps	声明式持续交付	星图同步术

章末彩蛋： 当群岛恢复平静时，kubectl get pods的输出中惊现Evicted状态的Pod，日志显示Unauthorized的API调用来自kube-system命名空间…

---

反转剧情

云原生危机的真正源头是被劫持的ServiceAccount：

• 攻击者利用过宽的RBAC权限创建恶意CronJob
• 通过挂载ServiceAccount Token渗透到AWS元数据服务
• 在Kubernetes集群内横向移动获取etcd权限

隐藏的攻击代码：

# 恶意CronJob中的命令
curl -H "Authorization: Bearer $(cat /var/run/secrets/kubernetes.io/serviceaccount/token)" 
     -k https://${KUBERNETES_SERVICE_HOST}/apis/rbac.authorization.k8s.io/v1/clusterroles

终极防御：

# 最小权限RBAC配置
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "list"]
---
# 启用Pod安全策略
apiVersion: policy/v1beta1
kind: PodSecurityPolicy
spec:
  privileged: false
  allowPrivilegeEscalation: false
  requiredDropCapabilities: ["ALL"]

---