跳转至

云上运行 — 托管 Kubernetes 与无服务器容器

这一章回答两件事: 本地跑顺的应用怎么上云(先解决架构差,再选托管服务); 以及云的下一站长什么样(serverless 容器)。贯穿全书的主角 TaskBoard 再次登场——同一套 YAML,三家云,原样跑通。

1. 前置功课:多架构镜像

问题具体而常见:你的 MacBook 是 Apple Silicon(ARM64),云上的节点却是 x86_64(比如 AWS 的 t3.small)——本地构建的镜像直接推上去,Pod 拉起来就 架构不符1。解法是 Docker Buildx 一次构建、双架构推送:

  $ docker buildx create --use --name mbuilder
  $ docker buildx inspect --bootstrap
  $ docker buildx build \
        --platform linux/amd64,linux/arm64 \
        -t <你的注册表>/taskboard-api:1.0.1 \
        -f ./api/Dockerfile --push ./api
    ↑ 一条命令产出多架构 manifest,推送后云上任一架构的节点都能拉对版本[^1]

这条命令是本章真正的硬门槛——跳过它,后面全是 ImagePullBackOff。

2. 为什么要托管:自建控制面的账单

书里的劝退清单值得一读(原意转述):自建生产级集群要** provisioning 虚拟机、 维护控制面、管理证书、监控各组件健康、配置网络与负载均衡、定期打安全补丁, 还要保证弹性、合规——深度专长、专职运维、持续投入,缺一不可**2。

托管服务(EKS/AKS/GKE)把控制面接走,五大优势照单接住2:

  1. 集群管理简化:控制面由厂商 provisioning、打补丁、保 HA;
  2. 身份集成:EKS 的 IRSA、AKS 的 Azure AD Workload Identity、 GKE 的 Workload Identity——Pod 级细粒度云权限;
  3. 弹性伸缩:节点和 Pod 的自动扩缩;
  4. 天生高可用:控制面跨可用区分布;
  5. 生态打通:容器注册表、托管数据库、密管、监控、CI/CD 即插即用。

但"托管"不是"免责"。 书里责任划分的原话要点:云厂商管控制面 (API server、scheduler、etcd),你仍然负责 worker 节点、工作负载、 应用层配置——集群内的 RBAC、secrets、网络规则、镜像无漏洞,全是你的账3。

3. 同一份 manifest,三家云

本章的实证结论朴素有力:TaskBoard 在 AKS 上跑完,搬到 GKE, 用的就是第 16 章那套 Kubernetes YAML 原文件;云相关的步骤只剩两件: 建集群、取凭证(gcloud container clusters get-credentials 这类)。 书里的总结一句到位:"Kubernetes 保住了应用的可移植性; 云相关的只有集群创建和凭证两步——这就是云原方的承诺。"4

清理提醒也很云:实验完 kubectl delete namespace + 删集群, 负载均衡器、公网 IP 随集群一起销毁——不然账单会替你记住这次实验5。 (GKE 的 Autopilot 变体更进一步:连节点规格都归 Google 管,同一份 manifest 照跑,还顺手执行 Pod 安全基线5。)

4. 下一站:serverless 容器

演化链一目了然:VM → 容器 → 编排(K8s)→ serverless 容器。 原则不变——应用照旧打进镜像;变的是运行方式:没有可见的节点、集群、 实例组;你给镜像和 CPU/内存配额,调度、扩缩、网络、可用性全归云厂商6。

三家实现(书里点名)6:

厂商 产品 形态
AWS Fargate(配 ECS 或 EKS) 每个 Pod/任务跑在独立隔离运行时,无 EC2 可管
Google Cloud Run 容器即服务,按请求扩缩
Azure Container Apps 同思路,事件驱动

收益书里说得直白:闲时缩到零;团队只写应用逻辑,兼得容器的一致性与 serverless 的弹性。代价(我们的补充,书里未展开):冷启动延迟、可定制面 收窄、按用量计价的成本模型要算细账。

选择建议(书末口径):长期运行/有状态/复杂系统——传统 K8s 集群; 事件驱动、短生命周期、不想见节点——serverless 容器7。

5. 作者的判断与证据

  • "自建集群的隐性账单"清单是本章最有说服力的论证,每条都是真实的 运维工种2。
  • 同 manifest 跨云复用是全书对"可移植性"承诺的实证兑现——不只是 理论上可以,是步骤上只剩建集群和凭证4。
  • 共同责任的划分(控制面 vs 工作负载)与云厂商官方文档一致, 书中明写"you are still accountable for security within your cluster"3。
  • serverless 一节的定位准确——描述现状与形态,没有过度承诺。

判断(我们的,不是书里的): "托管 K8s + 同一份 manifest"组合的真正 战略含义是:YAML 成了跨云的最小公分母。团队可以把"多云可移植"从口号 降到工程现实——只要守住两条:不依赖某云独有的 CRD/服务,镜像多架构。 反过来,一旦用上某家托管服务的独门集成(IRSA、Workload Identity),可移植性 就开始漏——这是书里没点破的张力。 如果错,会错在: serverless 容器持续蚕食"小集群"场景的速度可能快于书中 口径;若连中型应用都涌向 Cloud Run 类平台,"同 manifest 跨云"的话题权重会下降。

6. 边界与局限

  • 实操以 AKS/GKE 为主(附 EKS 对照),每家只到一个示例应用上线为止; 多云联邦、跨云流量、成本优化均未展开(书卡 notCovered 已记录)。
  • 没有讲注册表的云对应物(ECR/ACR/GCR)的具体配置,只提了生态打通。
  • serverless 的成本模型、冷启动、供应商锁定三个经典争议未讨论。
  • 云命令(gcloud/az/aws)随版本漂移,书里 2026 年初的快照仅供参考。

7. 可带走的

  1. 上云先修架构差:docker buildx --platform linux/amd64,linux/arm64 --push1。
  2. 自建集群的账单:控制面、证书、补丁、网络、HA、合规——托管服务接走控制面2。
  3. 五大优势 + 一条责任边界:身份集成、弹性、HA、生态、减负; worker 与工作负载安全仍归你23。
  4. 同一份 YAML 跨云,云相关步骤=建集群+取凭证4。
  5. 实验完删集群,公网 IP 和 LB 随集群销毁5。
  6. serverless 容器:给镜像+配额,不见节点,闲时归零;三家产品各归其云6。

8. 原文地图

主题 原书章 原文位置
架构不匹配与 buildx Preparing multiplatform images text/189-fm-preparing-multiplatform-images.txt:2(搜「mismatch」) · text/189-fm-preparing-multiplatform-images.txt:5(搜「t3.small」) · text/189-fm-preparing-multiplatform-images.txt:10(搜「Buildx」) · text/189-fm-preparing-multiplatform-images.txt:22(搜「--platform」)
自建账单与五大优势 Preparing multiplatform images text/189-fm-preparing-multiplatform-images.txt:42(搜「different story」) · text/189-fm-preparing-multiplatform-images.txt:43(搜「provision」) · text/189-fm-preparing-multiplatform-images.txt:55(搜「advantages」) · text/189-fm-preparing-multiplatform-images.txt:63(搜「IRSA」) · text/189-fm-preparing-multiplatform-images.txt:68(搜「availability zones」)
共同责任 Overview of the managed Kubernetes services covered in this chapter text/190-fm-overview-of-the-managed-kubernetes-services-cove.txt:4(搜「control plane」) · text/190-fm-overview-of-the-managed-kubernetes-services-cove.txt:5(搜「You are still accountable」)
同 manifest 的可移植性 Running a containerized application on GKE text/192-fm-running-a-containerized-application-on-gke.txt:6(搜「same Kubernetes manifests」) · text/193-fm-serverless-containers-and-the-future-of-cloud-na.txt:30(搜「portable」)
清理与 Autopilot Serverless containers and the future of cloud-native architectures text/193-fm-serverless-containers-and-the-future-of-cloud-na.txt:1(搜「Cleaning up」) · text/193-fm-serverless-containers-and-the-future-of-cloud-na.txt:15(搜「Autopilot」)
serverless 定义与三家产品 Serverless containers and the future of cloud-native architectures text/193-fm-serverless-containers-and-the-future-of-cloud-na.txt:38(搜「fades entirely」) · text/193-fm-serverless-containers-and-the-future-of-cloud-na.txt:41(搜「CPU and memory」) · text/193-fm-serverless-containers-and-the-future-of-cloud-na.txt:44(搜「Fargate」)
形态选择与展望 Summary text/194-fm-summary.txt:2(搜「next stage」) · text/194-fm-summary.txt:6(搜「abstraction」)

  1. 出处:「Preparing multiplatform images」第 1–35 段(text/189-fm-preparing-multiplatform-images.txt:2,搜「mismatch」;:5,搜「t3.small」;:10,搜「Buildx」;:14,搜「buildx create」;:22,搜「--platform」)。 ↩↩

  2. 出处:「Preparing multiplatform images」第 37–75 段(托管动机与优势因转码顺序位于本文件后半:text/189-fm-preparing-multiplatform-images.txt:43,搜「complex and time-consuming tasks」;:48,搜「fully managed」;:57,搜「provisions and maintains」;:60,搜「IRSA」;:68,搜「HA by design」;:74,搜「Reduced operational」)。 ↩↩↩↩↩

  3. 出处:「Overview of the managed Kubernetes services covered in this chapter」第 1–10 段(text/190-fm-overview-of-the-managed-kubernetes-services-cove.txt:4,搜「manage the control plane」;:3,搜「You are still accountable」;:5,搜「accountable」)。 ↩↩↩

  4. 出处:「Running a containerized application on GKE」与「Serverless containers」的总结(text/192-fm-running-a-containerized-application-on-gke.txt:6,搜「same Kubernetes manifests used」;text/193-fm-serverless-containers-and-the-future-of-cloud-na.txt:30,搜「portable」)。 ↩↩↩

  5. 出处:「Serverless containers and the future of cloud-native architectures」的清理与 Autopilot 段(text/193-fm-serverless-containers-and-the-future-of-cloud-na.txt:1,搜「Cleaning up」;:8,搜「load balancers」;:17,搜「create-auto」;:20,搜「right-size」)。 ↩↩↩

  6. 出处:「Serverless containers and the future of cloud-native architectures」第 20–50 段(text/193-fm-serverless-containers-and-the-future-of-cloud-na.txt:38,搜「fades entirely」;:41,搜「CPU and memory」;:44,搜「Fargate」;:36,搜「isolated runtime」)。 ↩↩↩

  7. 出处:「Summary」第 1–10 段(text/194-fm-summary.txt:2,搜「next stage」;:6,搜「abstraction」;:6,搜「universal unit」)。 ↩