算力 QoS、容灾、可观测性、可运维性
[迁移自旧评论]
原作者: guangyou yu 原时间: 2026-01-28T15:51:12Z
这里的说明有问题：算力 QOS 不是已经挪到超卖章节了吗？
33 Matching Annotations
- Jan 2026
-
tke-team-book.woa.com tke-team-book.woa.com
-
-
[迁移自旧评论]
原作者: YuMin Liu 原时间: 2026-01-29T07:19:13Z
这里应该单拆一个章节做「基本功能」，结合可用性一起进行。（可用性+基本功能）-> （超卖+弹性） -> gpu
-
可用层 → 05-03-availability.md
[迁移自旧评论]
原作者: guangyou yu 原时间: 2026-01-28T15:50:48Z
希望可用性作为本章节的第一大板块。希望所有人意识到可用性是生死问题，是底线问题
-
整体架构
[迁移自旧评论]
原作者: YuMin Liu 原时间: 2026-01-29T07:37:44Z
caas 层新加一个负责装箱的中间层，eks-server 只服务于计费的逻辑
-
[迁移自旧评论]
原作者: YuMin Liu 原时间: 2026-01-29T07:54:31Z
基本功能roadmap：1. 能创建kata pod，跑通 poc流程（已完成）2. 扩大支持的业务范围：兼容业务使用的基本能力（监控+日志采集+安全组）
-
-
tke-team-book.woa.com tke-team-book.woa.com
-
弹性
[迁移自旧评论]
原作者: guangyou yu 原时间: 2026-01-28T16:05:53Z
少了一个规模大：更强调控制面的承载能力，与供给能力、并发能力都不同
-
开发者体验
[迁移自旧评论]
原作者: guangyou yu 原时间: 2026-01-28T16:00:34Z
我们团队强调的开发者体验，是包含平台开发、平台运维、业务研发等广义的技术人员角色的体验。好的开发体验会带来：架构师售前好演示、客户迁移对接简单、出问题后排障简单。虽然这不是新运行时的重点。
-
制品分发能力
[迁移自旧评论]
原作者: guangyou yu 原时间: 2026-01-28T16:07:51Z
制品分发能力少了基于远程存储，完全不拉到本得的方案。和 lazy 也不一样。类似 DADI 或基于文件系统协议的。
-
-
tke-team-book.woa.com tke-team-book.woa.com
-
审批流
[迁移自旧评论]
原作者: 尤嘉宁 原时间: 2026-01-29T08:26:30Z
对接到starship的后台.
-
OpsConsole 运维集成平台
[迁移自旧评论]
原作者: Ray Huang 原时间: 2026-01-29T03:06:48Z
搞一个类似starship的平台，把cmdb，审批，运营都放上去。先基于新运行时的诉求搞，但最终可以成为tke serverless团队整体的一站式平台。
-
故障检测监控
[迁移自旧评论]
原作者: R WU 原时间: 2026-01-29T08:03:45Z
含影响范围，影响业务全景图
-
Worker Nodes
[迁移自旧评论]
原作者: 尤嘉宁 原时间: 2026-01-29T08:12:37Z
每个资源账号也有自己的master
-
停止新建节点，使用已有节点调度
[迁移自旧评论]
原作者: 尤嘉宁 原时间: 2026-01-29T08:18:03Z
这里的例子不太好
-
降级策略示例：
[迁移自旧评论]
原作者: 尤嘉宁 原时间: 2026-01-29T08:19:32Z
节点不可用的不要用原生的k8s驱逐方式. 要针对性的实现.
-
Operability/可观测性建设
[迁移自旧评论]
原作者: 尤嘉宁 原时间: 2026-01-29T08:33:48Z
每个阶段的里程碑要更明确. 比如: 1. 有个平台. 可以只读看到现有的资产 2. 可以纳管资产. 3. 可以做运维的纳管. 4. 可以通过故障演习.
-
M1.1: 基础监控上线
[迁移自旧评论]
原作者: 尤嘉宁 原时间: 2026-01-29T08:39:55Z
这个也再更新一下
-
-
tke-team-book.woa.com tke-team-book.woa.com
-
[迁移自旧评论]
原作者: guangyou yu 原时间: 2026-01-28T15:41:48Z
这些动机一直都存在，为什么我们今天才开始做这个了？因为 AI。包括 AI 业务带来的 Agent 和推理训练的需求，加剧了底层不可控的问题，如果没有 AI Agent，特别是 AI Coding 技术我们团队的力量无法完整这么庞大的工程，有了 AI 的加持才有了一线的可能：这就到处来我们必须全面利用AI 带来的变化，才可能把这个事情搞定。也即，第一页背景和动机，希望能够新增一个板块解释为什么今天才启动，阐述AI 带来的改变和我们必须借助 AI 的力量。借助AI 的力量，不仅仅是 AI Coding，更是心的 AI Native 的研发模式和组织模式。
-
-
tke-team-book.woa.com tke-team-book.woa.com
-
一个 GPU 加载多个小模型，按需服务
[迁移自旧评论]
原作者: guangyou yu 原时间: 2026-01-28T15:54:49Z
应该是多个小模型共用同一个GPU，而不要强调也给 GPU 加载多个小模型。前者是需求，后者是实现。多个小模型共用统一个 GPU，也可能是通过分时复用实现的。
-
[迁移自旧评论]
原作者: guangyou yu 原时间: 2026-01-28T15:57:38Z
业务场景这个章节，过度抽象化了。一个可行的改进方向是：补充 TKE Serverless 上当前多个典型客户的用户故事，补充多个使用 TKE 无法迁移到 TKE Serverless 的案例。建议由产品同学共创。
-
分钟级启动
[迁移自旧评论]
原作者: guangyou yu 原时间: 2026-01-28T16:01:49Z
这个错了。Argo Workflow 也是典型的数据处理场景，但是对 Pod 启动速度的要求是越快越好，最好逼近于 Agent。这个场景很像 AWS StepFunction
-
需要多层纵深防御
[迁移自旧评论]
原作者: guangyou yu 原时间: 2026-01-28T16:02:53Z
存储也需要隔离。AGS 场景中，不同沙箱会使用同一个 COS 桶，但是挂载不同的 COSFS subpath
-
性能要求
[迁移自旧评论]
原作者: guangyou yu 原时间: 2026-01-28T16:03:43Z
把控制面的弹性性能和数据面的计算性能分开。我理解这里说的是弹性要求
-
[迁移自旧评论]
原作者: YuMin Liu 原时间: 2026-01-29T07:27:10Z
能力大考：找一个具体的用户产品侧，做压测，例如 EMR 能在新架构上压测
-
EMR 在 Serverless 容器上适配差的原因：
[迁移自旧评论]
原作者: YuMin Liu 原时间: 2026-01-29T07:27:29Z
这个梳理有问题
-
-
tke-team-book.woa.com tke-team-book.woa.com99. 变更记录1
-
热迁移基于 VMF 技术，业务无感知
[迁移自旧评论]
原作者: R WU 原时间: 2026-01-29T03:54:37Z
这个是幻觉。没有这部分的内容
-
-
tke-team-book.woa.com tke-team-book.woa.com
-
超卖与混部
[迁移自旧评论]
原作者: roczzhang 原时间: 2026-01-29T09:08:13Z
细化一下里程碑目标，增加交付时间，验收标准。
-
-
tke-team-book.woa.com tke-team-book.woa.com
-
单 Pod 启动速度优化
[迁移自旧评论]
原作者: R WU 原时间: 2026-01-29T09:28:55Z
这里还是改成 update eni 网卡模式。然后想办法解决路由下发问题。
-
-
9.135.97.31 9.135.97.31
-
基本功能roadmap： 1. 能创建kata pod，跑通 poc流程（已完成） 2. 扩大支持的业务范围：兼容业务使用的基本能力（监控+日志采集+安全组）
-
整体架构
caas 层新加一个负责装箱的中间层，eks-server 只服务于计费的逻辑
-
这里应该单拆一个章节做“基本功能”，结合可用性一起进行。 （可用性+基本功能）-> （超卖+弹性） -> gpu
-
-
9.135.97.31 9.135.97.31
-
EMR 在 Serverless 容器上适配差的原因：
这个梳理有问题
-
能力大考：找一个具体的用户产品侧，做压测，例如 EMR 能在新架构上压测
-
-
9.135.97.31 9.135.97.31
-
可用性应该在最前面建设： 1. 是后续能力的基础 2. 可以在eks 团队内闭环
-