在 Kubernetes 中使用 ACK on ECI和ASK有哪些不同？

在 ACK Kubernetes 集群中使用 ECI 的方式。这种方式适合于用 户已经有了一个 ACK 集群，集群中已经有了很多 ECS 节点，此时可以基于 ECI 的弹 性能力来运行一些短时间 Short-Run 的应用，以解决元集群资源不足的问题，或者使用 ECI 来支撑应用的快速扩容，因为使用 ECI 进行扩容的效率要高于 ECS 节点扩容。 在 ACK on ECI 中，ECS 和 ECI Pod 可以互联互通，ECI Pod 可以访问集群 中的 Coredns，也可以访问 ClusterIP Service。与 ACK on ECI 不同的是，ASK（Serverless Kubernetes）集群中没有 ECS 节 点，这是和传统 Kubernetes 集群最主要的差异，所以在 ASK 集群中无需管理任何节点， 实现了彻底的免节点运维环境，是一个纯粹的 Serverless 环境，它让 Kubernetes 的使 用门槛大大降低，也丢弃了繁琐的底层节点运维工作，更不会遇到节点 Notready 等问题。 在 ASK 集群中，用户只需关注应用本身，而无需关注底层基础设施管理。 ASK 的弹性能力会优于普通 Kubernetes 集群，目前是 30s 创建 500 个 Pod 到 Running 状态。集群中 ECI Pod 默认是按量收费，但也支持 Spot 和预留实例劵来 降低成本。在兼容性方面，ASK 中没有真实节点存在，所以不支持 Daemonset 等与节 点相关的功能，像 Deployment / Statefulset / Job / Service / Ingress / CRD 等 都是无缝支持的。 ASK 中默认的 Ingress 是基于 SLB 7 层转发实现，用户无需部署 Nginx Ingress， 维护更加简单。 同时基于 SLB 7 层我们实现了 Knative Serving 能力，其中 Knative Controller 被 ASK 托管，用户无需负担 Controller 的成本。 与 ACK 一样，ASK 和 Arms / SLS 等云产品实现了很好的集成，可以很方便地对 Pod 进行监控，把 Pod 日志收集到 SLS 中。这是 ASK 的整体架构，核心部分是 ASK-Schduler，它负责 Watch Pod 的变化， 然后创建对应的 ECI 实例，同时把 ECI 实例状态同步到 Pod。集群中没有真实 ECS 节点注册到 Apiserver。这个 Nodeless 架构解耦了 Kubernetes 编排层和 ECI 资源 层，让 Kubernetes 彻底摆脱底层节点规模导致的弹性和容量限制，成为面向云的 Nodeless Kubernetes 弹性架构。