容器编排的艺术

# Dockerfile（示例：一个 Python 服务）
FROM python:3.11-slim        # 基础镜像
WORKDIR /app
COPY requirements.txt .
RUN pip install -r requirements.txt    # 构建期
COPY . .
EXPOSE 8080
CMD ["python", "app.py"]     # 启动命令

# 构建并推送
docker build -t ledger/order:v1.2 .
docker push ledger/order:v1.2

【容器 vs 虚拟机】
          虚拟机          容器
  启动     分钟级          秒级
  资源     每个带 OS       共享内核，只装应用
  隔离     强（独立内核）  进程级（Namespace+Cgroups）
  密度     一台几十个      一台几百个
  场景     强隔离/异构     微服务/云原生

【K8s 时代的容器运行时】
  Docker → 已内置为 containerd（CNCF 标准）
  镜像标准：OCI（Open Container Initiative）——不绑定 Docker

【镜像最佳实践】
  小镜像（slim/distroless）→ 拉取快、攻击面小
  多阶段构建 → 只留运行所需
  版本 tag 固定（v1.2.0），别用 latest！

┌──────────── 控制面（Master ×3 高可用）────────────┐
│  API Server（唯一入口，kubectl 都走这）             │
│  etcd（状态记账本——集群的「真相」）                 │
│  Scheduler（决定 Pod 放哪个节点）                   │
│  Controller Manager（控制器：盯着期望状态调和）     │
└──────────────────────┬────────────────────────────┘
                       │
   ┌─────────┬─────────┼─────────┬─────────┐
   ▼         ▼         ▼         ▼         ▼
┌ Node1 ─┐ ┌ Node2 ─┐ ┌ Node3 ─┐ ┌ Node4 ─┐ ┌ Node5 ─┐
│ kubelet │ │ kubelet │ │ kubelet │ │ kubelet │ │ kubelet │ ← 每台机器管家
│ kube-proxy│ │ ...    │ │ ...    │ │ ...    │ │ ...    │
│ containerd│ │        │ │        │ │        │ │        │ ← 真正跑容器
│ Pod×N   │ │ Pod×N  │ │ Pod×N  │ │ Pod×N  │ │ Pod×N  │
└─────────┘ └─────────┘ └─────────┘ └─────────┘ └─────────┘

【一次部署的旅程】
  kubectl apply -f deploy.yaml
  → API Server 校验 → 存 etcd → Scheduler 选节点
  → 该节点 kubelet 拉镜像 → 起容器 → 汇报状态
  → Controller 发现期望=现实 → 完成

【etcd：一切状态的真相】
  集群任何状态都记在 etcd——它是 K8s 的「数据库」
  备份 etcd = 备份整个集群（第 10 站重点讲）

# Deployment：管理副本，负责自愈与发布
apiVersion: apps/v1
kind: Deployment
metadata:
  name: order-service
spec:
  replicas: 3                    # 期望 3 个副本
  selector:
    matchLabels: { app: order }  # 管理哪些 Pod
  template:
    metadata:
      labels: { app: order }     # 给 Pod 贴标签
    spec:
      containers:
        - name: order
          image: ledger/order:v1.2
          ports: [{ containerPort: 8080 }]
---
# Service：稳定入口 + 负载均衡
apiVersion: v1
kind: Service
metadata:
  name: order-svc
spec:
  selector: { app: order }       # 通过标签找到 Pod
  ports:
    - port: 80                   # 集群内访问端口
      targetPort: 8080           # 转发到 Pod 的端口

【命令速查】
  kubectl apply -f deploy.yaml      # 声明式应用
  kubectl get pods / deploy / svc   # 查看状态
  kubectl logs -f pod/xxx           # 看日志
  kubectl describe pod/xxx          # 详细信息（排障第一招）

【Deployment 滚动更新】
  改镜像版本 → apply → 逐个替换 Pod，不中断服务
  失败自动回滚（rollout undo）

【排障第一课】
  Pod 起不来？kubectl describe 看事件！
  CrashLoopBackOff？kubectl logs 看日志！

# ConfigMap：普通配置
apiVersion: v1
kind: ConfigMap
metadata: { name: order-config }
data:
  REDIS_URL: redis://redis-svc:6379
  LOG_LEVEL: info
---
# Secret：敏感信息
apiVersion: v1
kind: Secret
metadata: { name: order-secret }
type: Opaque
data:
  DB_PASSWORD: cGFzc3dvcmQxMjM=      # base64（不是加密！）
---
# Deployment 里挂载使用
spec:
  containers:
    - name: order
      envFrom:
        - configMapRef: { name: order-config }
        - secretRef:    { name: order-secret }

【持久化存储（数据库这类有状态应用）】
  PVC 申请 → StorageClass 自动创建云盘（动态供应）
  Deployment 换成 StatefulSet（有状态应用专用）：
    稳定的网络标识（order-0, order-1…）、稳定的存储绑定

【存储类型】
  emptyDir：临时（Pod 生命周期内，缓存用）
  hostPath：节点本地盘（测试用）
  云盘/分布式存储：生产首选（AWS EBS / 阿里云云盘 / Ceph）

【Secret 安全要点】
  Secret 是「混淆」不是「加密」——生产要开启 etcd 加密
  访问控制走 RBAC（第 9 站）
  别把 Secret 提交进 Git！（密钥扫描——第七本老朋友）

用户请求 api.example.com/order/123
   ↓ DNS 解析到 Ingress 控制器
   ↓ Ingress（七层网关）：按域名/路径路由
   ↓ Service（ClusterIP）：负载均衡
   ↓ Pod × 3（订单服务）：真正处理

【Service 三种类型（必考）】
  ClusterIP：集群内虚拟 IP（默认）——服务间访问
  NodePort ：每节点开端口——测试/临时用
  LoadBalancer：云厂商 LB——生产对外入口（配 Ingress 用）

【Ingress 配置示例】
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata: { name: api-ingress }
spec:
  rules:
    - host: api.example.com
      http:
        paths:
          - path: /order
            pathType: Prefix
            backend:
              service: { name: order-svc, port: { number: 80 } }

【CNI 插件】
  Calico（生产主流）：网络策略 + BGP 路由
  Flannel：简单 overlay（VXLAN）——小集群够用
  Cilium：eBPF 新一代（性能强，趋势）

【网络排障口诀】
  服务不通？先查：Service 选择器对不对 → Pod 起来了没 → DNS 能不能解析 → CNI 通不通

# Deployment 里声明资源
spec:
  containers:
    - name: order
      resources:
        requests: { cpu: "500m", memory: "512Mi" }   # 最少要多少
        limits:   { cpu: "1",    memory: "1Gi" }    # 最多用多少
---
# HPA：自动伸缩
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata: { name: order-hpa }
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: order-service
  minReplicas: 3
  maxReplicas: 20
  metrics:
    - type: Resource
      resource:
        name: cpu
        target: { type: Utilization, averageUtilization: 70 }

【QoS 三等级（requests/limits 组合决定）】
  Guaranteed：requests == limits（最高保障）
  Burstable ：requests < limits（常见）
  BestEffort：都没设置（最低，先被杀）

【调度高级特性】
  节点亲和（nodeAffinity）：Pod 想待在「有 GPU」的节点
  污点与容忍（Taint/Toleration）：节点标记「特殊」，只让特定 Pod 来
  反亲和（podAntiAffinity）：两个副本别放同一台机器（高可用）

【HPA 扩展思考】
  指标源不止 CPU：自定义指标（QPS/队列长度，KEDA）
  垂直伸缩（VPA）：自动调 requests/limits
  节点级伸缩：Cluster Autoscaler 自动加机器

【排障提醒】
  Pod 一直 Pending？→ 节点资源不够（requests 放不下）
  Pod 反复 OOM？→ limits 内存给小了 / 内存泄漏

spec:
  containers:
    - name: order
      # 就绪探针：能接流量吗？（没就绪，Service 不分流量）
      readinessProbe:
        httpGet: { path: /healthz, port: 8080 }
        initialDelaySeconds: 5
        periodSeconds: 10
      # 存活探针：还活着吗？（失败 3 次 → 重启容器）
      livenessProbe:
        httpGet: { path: /healthz, port: 8080 }
        failureThreshold: 3
      # 启动探针：启动慢的应用给宽限
      startupProbe:
        httpGet: { path: /healthz, port: 8080 }
        failureThreshold: 30        # 给 30×5s 的启动时间

  # 优雅终止：下线时等请求处理完
  terminationGracePeriodSeconds: 30   # 给 30 秒优雅时间
  # （应用内处理 SIGTERM：停止接新请求 → 处理完存量 → 退出）

【发布策略】
  滚动更新（默认）：maxSurge 多起几个 + maxUnavailable 少停几个
  金丝雀：先发 1 个新版 → 观察指标 → 全量
  蓝绿：两个版本并存，切 Service 选择器（简单粗暴）

【状态速查】
  Running（正常）/ Pending（等待调度）/ CrashLoopBackOff（起不来循环）
  ImagePullBackOff（拉镜像失败）/ OOMKilled（内存超限被杀）
  → 90% 的故障排查：describe + logs

一个集群（中小公司起步）：
  ┌─ ns/dev ─┐  ┌─ ns/test ─┐  ┌─ ns/prod ─┐
  │ 订单服务  │  │ 订单服务  │  │ 订单服务  │
  │ 配置:dev  │  │ 配置:test │  │ 配置:prod │   ← 同一镜像，不同 ConfigMap
  │ 配额:小  │  │ 配额:中   │  │ 配额:大   │
  └─────────┘  └──────────┘  └──────────┘

【ResourceQuota 示例】
apiVersion: v1
kind: ResourceQuota
metadata: { name: dev-quota, namespace: dev }
spec:
  hard:
    requests.cpu: "8"
    requests.memory: 16Gi
    pods: "50"                 # dev 最多 50 个 Pod，超了拒绝

【LimitRange：没声明资源的兜底】
  → 默认 requests/limits——防止「裸奔 Pod」抢资源

【命令速查】
  kubectl get ns
  kubectl -n prod get pods          # 指定命名空间
  kubectl config set-context ...    # 切换上下文（当前 NS）

【多集群 vs 单集群多 NS（决策）】
  单集群多 NS：省钱省事（中小团队起步）
  多集群：故障隔离强、合规要求、团队大——规模大了再上
  管理工具：Rancher / KubeSphere / ArgoCD（GitOps 部署）

# RBAC：给开发角色「只看 prod」权限
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata: { name: dev-readonly, namespace: prod }
rules:
  - apiGroups: [""]
    resources: ["pods", "services", "configmaps"]
    verbs: ["get", "list", "watch"]     # 只读！不能改

# 绑定用户/ServiceAccount
kind: RoleBinding
metadata: { name: dev-readonly-bind, namespace: prod }
subjects: [{ kind: User, name: "xiaozhe" }]
roleRef: { kind: Role, name: dev-readonly, apiGroup: rbac.authorization.k8s.io }
---
# NetworkPolicy：只允许订单 → 支付
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata: { name: allow-order-to-pay }
spec:
  podSelector: { matchLabels: { app: payment } }   # 目标：支付服务
  ingress:
    - from:
        - podSelector: { matchLabels: { app: order } }   # 只放行订单
      ports: [{ port: 8080 }]

【PodSecurity 标准（baseline/restricted）】
  禁止 privileged 容器、禁止 root 用户、只读根文件系统
  → 镜像里用非 root 运行应用（USER appuser）

【镜像安全】
  镜像扫描（Trivy/Clair）→ 有 CVE 漏洞不让上线
  只从受信仓库拉取（Harbor 私有仓 + 签名）

【审计日志】
  API Server 审计——谁在什么时候干了什么（第七本审计老朋友）

【上线前 Checklist】
  □ 控制面 3 节点高可用（etcd 备份 + 恢复演练）
  □ 所有对象声明了 requests/limits（QoS 不低于 Burstable）
  □ 探针配齐（readiness + liveness）
  □ 镜像扫描通过 + 非 root 运行
  □ RBAC 最小权限 + 审计开启
  □ 日志/监控/告警接入（ELK + Prometheus）
  □ Secret 加密 + 不落 Git
  □ 备份恢复演练做过一次（不是「备份了」而是「恢复过」）

【Helm 速览】
  helm create my-app          # 创建 Chart
  helm install my-app ./chart # 一键部署整套
  helm upgrade / rollback     # 升级 / 回滚
  → 把「50 个 YAML」变成「1 个命令」

【排障思路（体系化）】
  ① Pod 起不来：kubectl describe pod → 事件！
  ② 服务不通：Service selector 对不对 → DNS → NetworkPolicy
  ③ 集群异常：控制面健康 → etcd 健康 → 节点状态
  ④ 性能问题：资源不够 → 加副本/调 requests → 查慢查询

【认证（要不要考）】
  CKA（管理员）/ CKAD（应用开发）——K8s 官方认证
  CKA：集群运维、排障、etcd 备份恢复（实操考试）
  CKAD：应用部署、Pod/Service/存储（偏开发）
  → 含金量：招聘硬通货，考一次管 3 年
  → 建议：先 CKAD 入门，再 CKA 进阶

【避坑清单（血泪）】
  ✗ latest 标签（不可复现）
  ✗ 不声明资源（OOM 先死）
  ✗ 有状态应用用 Deployment（要用 StatefulSet）
  ✗ 直接改生产（要走 CI/CD + 审计）
  ✗ 没备份就升级 etcd（备份是底线！）