serverless

摘自 Kubernetes 实践指南 背景 超级节点(Serverless) 的 Pod，默认分配的系统盘大小是 20GB，当容器镜像非常大的时候（比如镜像中包含大的 AI 模型)，拉取镜像会因空间不足而失败: Warning Failed 50s eklet Failed to pull image "registry.imroc.cc/test/large:latest": rpc error: code = Unknown desc = failed to pull and unpack image "registry.

摘自 Kubernetes 实践指南 概述 腾讯云容器服务的超级节点有着隔离性强，扩容快，成本低等特点，天然适合离线任务与大规模压测。 本文分享这种场景的几个真实实践案例。 案例一: CI 系统(某出行客户) gitlab-runner 启动 Pod 运行 CI 任务，任务结束即销毁 Pod，使用常驻节点会造成资源利用率低。任务量大时扩容节点时间长，造成部分 CI 任务过慢。 方案改进: 使用 Serverless 集群(超级节点)，无需常驻节点资源，Pod 按量计费，且支持竞价实例，任务结束即停止计费，降低成本。任务量大时也可以快速扩容，提高 CI 效率。 案例二: 游戏 AI 训练(某游戏客户) 使用 GPU Pod 训练游戏 NPC AI 模型，训练完成后，再启动大量 CPU Pod 对模型进行验证。

摘自 Kubernetes 实践指南 概述 腾讯云容器服务的超级节点可以轻松应对流量洪峰。 本文分享这种场景的几个真实实践案例。 案例一: 信息流系统(某新闻媒体客户) 在线业务，购买了包年包月普通节点，在业务高峰期算力不足，扩容节点慢导致部分请求失败。业务高峰时间有时无法预测(可能某个新闻突然就爆火了)，扩容慢问题的影响进一步被放大。 方案改进: 普通节点作为常驻资源池进行兜底，优先调度 Pod 到普通节点，当普通节点资源不足再调度到超级节点。高峰期 HPA 自动扩容 Pod，过程中不会触发扩容节点，不存在扩容慢问题。超级节点上 Pod 缩容后停止计费，降低成本。 案例二: 元宇宙案例(某元宇宙客户) 元宇宙业务，类似在线游戏，全球同服，带宽需求量极大，需要每个 Pod 绑 EIP，且使用的游戏框架依赖读 eth0 公网 IP。做活动时，流量相比平时大很多，大概100倍，需要能够快速扩容。

摘自 Kubernetes 实践指南 概述 腾讯云容器服务中集群节点有普通节点和超级节点之分，具体怎么选呢？本文告诉你答案。 集群与节点类型 腾讯云容器服务产品化的 Kubernetes 集群最主要是以下两种: 标准集群 Serverless 集群 不管哪种集群，都需要添加节点才能运行服务(Pod)。对于标准集群，同时支持添加普通节点与超级节点: 而对于 Serverless 集群，只支持添加超级节点: 普通节点与超级节点的区别 普通节点都很好理解，就是将虚拟机(CVM)添加到集群中作为 K8S 的一个节点，每台虚拟机(节点)上可以调度多个 Pod 运行。