一、一次真实的安全事故：被挖矿的测试服务器
"讲个真实的。"老周严肃起来，"前几年有个公司，测试服务器上跑着一个 Redis 容器，没设密码、直接暴露在公网。攻击者扫描到后，通过 Redis 漏洞写入恶意命令，把容器和主机都打穿，装上了挖矿程序——CPU 飙到 100%，电费账单翻了好几倍。 更糟的是，攻击者通过这台测试机横向渗透，摸到了内网的其他系统。"
"为什么容器时代这种事更多？"老周问，"因为容器部署太方便了，导致很多人在'快'和'安全'之间，选择了快。 拉个镜像就跑、端口一开就完事、密码懒得设……这些'图快'的举动，就是攻击者的门。"
二、容器安全的五大实战要点
老周列出容器安全清单：
2.1 镜像安全：别把漏洞带进来
① 用官方/可信镜像：从 Docker Hub 官方库、自建 Harbor 拉
② 定期扫描漏洞：trivy / Clair / Harbor 内置扫描
→ 高危漏洞镜像禁止部署（流水线里加扫描关卡）
③ 用非 root 用户运行容器：
→ 容器里默认是 root，被打穿 = 主机 root？危险！
→ Dockerfile 里 USER 指定普通用户
④ 最小化镜像：alpine/slim 减少攻击面（第三章瘦身）
# Dockerfile 里用非 root 运行
FROM python:3.11-slim
RUN useradd -m appuser # 建普通用户
USER appuser # 用普通用户跑（关键！）
CMD ["python", "app.py"]
2.2 运行时安全：给容器上"镣铐"
# ① 资源限制（第四章讲过，安全三件套）
docker run --cpus=1 --memory=512m --pids-limit=100 ...
# ② 只读文件系统（防容器被改）
docker run --read-only -v /tmp:/tmp ...
# ③ 最小权限：去掉不用的能力（capabilities）
docker run --cap-drop ALL --cap-add NET_BIND_SERVICE ...
# ④ 禁止特权模式：--privileged 是安全黑洞！坚决不用
# ❌ docker run --privileged ...（等于把主机钥匙给容器）
# ⑤ 容器安全扫描工具：Falco（检测容器异常行为）
"--privileged 是容器安全最大的禁忌——它让容器拥有主机的全部权限，攻击者打进容器就等于打进主机。生产环境禁用。"
2.3 网络与隔离：默认拒绝
① 端口最小暴露：只映射必须要的端口（第六章）
② 网络分段：用 K8s NetworkPolicy 限制 Pod 间访问
→ api 只能访问 db，其他全拒绝（像 NSX 微分段）
③ 敏感服务不暴露公网：数据库/Redis 只在内网
④ 加密传输：容器间用 TLS，不用明文
2.4 凭据安全：密钥不落盘
① 不把密码写进镜像/代码/环境变量明文
② 用 Docker Secret / K8s Secret 管理敏感信息
③ 镜像里不要存 .env / 证书 / 密钥（扫描时会发现）
④ 定期轮换密钥
2.5 审计与监控：看得见才安全
① 容器日志集中收集（ELK/Loki）
② 异常检测：CPU 突增（挖矿征兆）、陌生进程、异常外联
③ K8s 审计日志：谁对集群做了什么
④ 定期安全扫描和渗透测试
"容器安全一句话：默认拒绝 + 最小权限 + 持续扫描 + 看得见。 别等被攻击了才想起来补课。"
三、云原生生态：容器之后的世界
"最后，带你看看容器的'未来'——云原生（Cloud Native）生态。"老周说，"容器只是云原生的一块地基，云原生是一整套'为云而生的开发运维方式'。"
云原生全景（CNCF 云原生计算基金会）：
┌───────────────────────────────────────┐
│ 云原生四大支柱： │
│ ① 容器化 ：应用打包（Docker） │
│ ② 编排 ：容器调度（Kubernetes） │
│ ③ 微服务 ：应用拆小（独立部署） │
│ ④ DevOps ：开发运维一体化（CI/CD） │
└───────────────────────────────────────┘
周边生态（按需选用）：
服务网格（Service Mesh）：Istio/Linkerd
- 微服务间通信的"交通管理"：负载均衡/熔断/限流
- 不用改代码就能加流量治理（Sidecar 模式）
可观测性（Observability）：Prometheus + Grafana
- 指标（Metrics）/ 日志（Logs）/ 链路追踪（Traces）
- 三件套：监控数据、排障日志、调用链
Serverless（无服务器）：Knative/FaaS
- 连 Pod 都不用管，按调用次数付费
- 代码提交即部署，没有服务器概念
云原生存储/网络：CSI/CNI 插件（存和网的标准化）
服务网格（Service Mesh）：微服务的"交通警察"
"简单讲讲服务网格。"老周说，"云间书店如果拆成 20 个微服务，它们之间互相调用：谁超时了？谁挂了？流量怎么分流？——这些'服务间通信的问题'，用一个叫 Sidecar（边车）的代理容器解决："
没有 Service Mesh： 有 Service Mesh（Istio）：
api ──调用──▶ order ──调用──▶ pay api ──▶ [sidecar]──▶ order ──▶ [sidecar]──▶ pay
超时/重试/限流全靠代码自己写 │ 流量控制/熔断/监控全在 sidecar 层做
改一次策略要改代码重新发布 │ 改策略 = 改配置，不用动代码！
└─ 就像给每辆车配了"红绿灯系统"
"服务网格的价值：把'服务治理'（限流、熔断、监控）从业务代码里抽出来，变成基础设施能力。 开发者只管业务，不用管网络策略——这是微服务时代的重要趋势。"
可观测性：让系统"透明"
"最后是可观测性（Observability）——云原生系统必须'看得见'。"老周说：
可观测性三支柱：
Metrics（指标）：系统状态数字（QPS、延迟、错误率、CPU）
Logs（日志） ：事件记录（谁在什么时候干了什么）
Traces（链路） ：一次请求经过的所有服务（从 web → api → db）
云间书店的实践：
Prometheus 采集指标 + Grafana 做看板
Loki/ELK 收集日志
Jaeger 做链路追踪（排查"下单为什么慢"）
→ 故障定位从"翻日志"变成"看链路一目了然"
"微服务一多，一个请求跨 5 个服务——没有链路追踪，你连它走了哪条路都不知道。可观测性不是可选项，是云原生的标配。"
四、云间书店的云原生未来
老周给小陈画了一张"未来路线图"：
云间书店的云原生路线图：
现在（已做到）：
Docker 容器化 + Harbor 仓库 + K8s 集群 + CI/CD 流水线
下一步：
① 应用微服务化（把直播、订单、AI 拆成独立服务）
② 上 Istio 服务网格（流量治理自动化）
③ 完善可观测性（Prometheus + Grafana + Jaeger）
④ 高峰期 Serverless 弹性（秒杀流量暴增时不慌）
最终：
"云原生书店"：开发只管写代码，基础设施全自动
"记住：技术是手段，不是目的。 容器、K8s、Service Mesh……所有的努力，都是为了一个目标：让云间书店更快地响应市场、更稳地服务用户、更省地使用资源。"
五、章末：老周的第十一、十二层总结
第十一层：安全与最佳实践
├── 镜像安全：可信来源 + 漏洞扫描 + 非 root 运行
├── 运行时：资源限制 + 只读 + 最小权限（禁用 --privileged）
├── 网络隔离：最小暴露 + NetworkPolicy + 不暴露敏感服务
├── 凭据安全：Secret 管理 + 不写死密钥
└── 审计监控：日志集中 + 异常检测 + 看得见
第十二层：云原生生态
├── 四大支柱：容器化 / 编排 / 微服务 / DevOps
├── 服务网格（Service Mesh）：sidecar 流量治理
├── 可观测性：指标 + 日志 + 链路追踪
├── Serverless：无服务器，按调用付费
└── 最终目标：更快的响应、更稳的服务、更省的资源
"小陈，到这里，Docker 容器的知识树你已经爬完了——从'为什么需要容器'，到'云原生生态'，整整十二层。"
"明天，是你考 CKA（Certified Kubernetes Administrator）模拟考的日子。"老周递给他一张纸，"去把终章准备好——那是你的出师报告：《从虚拟机到云原生：云间书店的容器之路》。"
小陈接过纸，笑了："师傅，考完试，我想把咱们的 AI 荐书服务也容器化——它现在是跑在虚拟机上的。这样它也能享受 K8s 的自动扩容了。"
"这才是学以致用。"老周拍拍他的肩，"去吧，机房等你。"