Serverless Kubernetes 入门:对 Kubernetes 做减法 游戏
程序员文章站
2022-03-16 13:09:09
...
背景
==
Kubernetes 作为通用的容器编排系统,承载了广泛的应用和场景,包括 CI/CD,数据计算,在线应用,AI 等,然而由于其通用性和复杂性,管理一个 Kubernetes 集群对于很多用户而言还是充满挑战的,主要体现在:
* 学习成本高;
* 集群运维管理成本高,包括节点管理、容量规划,以及各种节点异常问题的定位;
* 计算成本在很多场景中没有达到最优,比如对于一个定时运行 Jobs 的集群,长期持有资源池对于用户来说是浪费的行为,资源利用率不高。
对 Kubernetes 集群做减法
==================
无节点管理
-----
我们相信未来用户会更加关注应用的开发,而不是基础设施的维护。体现在 Kubernetes 集群中,我们希望用户能够关注在 pod/service/ingress/job 等应用编排语义上,对底层 node 则可以减少关注。
无需管理节点也可以显著降低集群的运维管理成本,经统计 Kubernetes 常见的异常问题中大多数与节点相关,比如 Node NotReady 问题,也无需担忧 Node 的安全问题,以及基础系统软件的升级和维护。
在 ASK 集群中,我们使用虚拟节点 virtual-kubelet 代替 ecs 节点,虚拟节点的容量可以认为是“无限大”,用户不需要为集群的容量担忧,无需预先做容量规划。
![2.png](https://ucc.alicdn.com/pic/developer-ecology/f8ce481400e54386b79ad4444f9849fa.png)
无 Master 管理
-----------
和 ACK 托管版一样,ASK 的 Master(apiserver, ccm, kcm 等)资源被容器服务平台托管,用户无需管理这些核心组件的升级和运维,也不用付出成本。
极简的 K8s 基础运行环境
--------------
除了无需管理节点和 Master 外,我们还对 Kubernetes 集群管理做了大量简化,包括默认托管很多 addon,用户无需再管理一些基础的 addon,也不需要为这些 addon 付费。依赖阿里云原生的网络和存储等能力,以及独特的托管架构设计,我们提供了极度简化但功能完备的 Kubernetes 基础运行环境。
功能
ACK
ASK
存储
需要部署 aliyun-disk-controller/flexvolume
无需部署(正在支持中)
CNI 网络
需要部署 terway/flannel daemonset
无需部署,基于 vpc 网络通信
coredns 服务发现
需要部署 2 个 coredns 副本
无需部署,基于 privatezone 访问
kube-proxy
需要部署 kube-proxy daemonset
无需部署,基于 privatezone 访问
Ingress
需要部署 nginx-ingress-controller
无需部署,基于 SLB 七层转发
免密拉取 ACR 镜像
需要部署 acr-credential-helper
无需部署,默认支持
sls 日志收集
需要部署 logtail daemonset
无需部署,默认支持
metrics 统计
需要部署 metrics-server
无需部署,开箱即用
挂载 eip
需要部署 terway
无需部署,使用 annotaion 指定
云盘随 pod 创建挂载
依赖 aliyun-disk-controller
无需部署,默认支持
弹性伸缩
需要部署 cluster-autoscaler
无需部署
GPU 插件
需要部署 Nivida-docker
无需部署,开箱即用
综上可以看到,ACK 集群至少需要 2 台 ecs 机器以运行这些基本的 Addon,而 ASK 集群把这些基础 Addon 化为无形,可以达到 0 成本创建一个开箱可用的 Kubernetes 集群。
简化弹性伸缩
------
因为无需管理节点和容量规划,因此当集群需要扩容时也就不需要考虑节点层面的扩容,只需要关注 pod 的扩容,
这对于扩容的速度和效率都是极大的提升,目前一些客户指定使用 ASK/ECI 的方式来快速应对业务流量高峰。
当前 ASK/ECI 支持 30s 完全启动 500 个 pod(至 Running 状态),单个 pod 启动可以达到 10s 以内。
更低成本
----
除去 ASK 集群本身的低成本创建外,pod 的按需使用也让很多场景下资源利用率达到最优。对于很多 Jobs 或者数据计算场景而言,用户并不需要长期维护一个固定的资源池,这时 ASK/ECI 可以很好的支持这些诉求。
经验证,当 pod 一天中运行时间少于 16 个小时,则 ASK/ECI 的方式相比保有 ecs 资源池更节省经济成本。
ECI:快速交付容器资源的弹性计算服务
-------------------
谈起 ASK,一定会谈到 ASK 的资源底座 ECI。ECI 是阿里云基于 ECS IaaS 资源池提供的稳定、高效、高弹性容器实例服务。ECI 让容器成为了公有云的第一等公民,用户无需购买和管理 ecs 就可以直接部署容器应用,这种简化的容器实例产品形态和 ASK 形成了一个完美的组合。
用户可以直接使用 ECI Open API 创建容器实例资源,但在容器场景中用户普遍需要一个编排系统,来负责容器的调度、高可用编排等能力,而 ASK 正是这样的 Kubernetes 编排层。
对于 ASK 而言,ECI 让 ASK 容器服务免去了搭建后台计算资源池的必要,更不用为底层计算资源池的容量而担忧。基于 ECI 就意味着基于整个阿里云 IaaS 规模化资源池,天然拥有了库存和弹性优势(比如可以通过 Annotation 的方式指定底层 eci 对应的 ecs 规格,大部分 ecs 规格都可以在 ASK 中使用,满足多种计算场景的需求)。另外 ECI 和 ECS 复用资源池意味着我们可以最大化释放规模化红利,给用户提供更低成本的计算服务。
容器生态支持
======
ASK 对 Kubernetes 容器生态提供了完善的支持,目前已有大量客户使用 ASK 来支撑如下各种场景:
* CI/CD:gitlab-runner,jenkins/jenkins-x
* 数据计算:spark/spark-operator,flink,presto,argo
* AI:tensorflow/arena
* ServiceMesh: istio,knative
* 测试:locust,selenium
> ASK 集群不支持 Helm v2,近期 ACK/ASK 会发布 Helm v3 的支持,之后用户可以非常方便的在 ASK 集群中部署 Charts。
[原文链接](https://link.zhihu.com/?target=https%3A//yq.aliyun.com/articles/739645%3Futm_content%3Dg_1000094672)
本文为阿里云内容,未经允许不得转载。
==
Kubernetes 作为通用的容器编排系统,承载了广泛的应用和场景,包括 CI/CD,数据计算,在线应用,AI 等,然而由于其通用性和复杂性,管理一个 Kubernetes 集群对于很多用户而言还是充满挑战的,主要体现在:
* 学习成本高;
* 集群运维管理成本高,包括节点管理、容量规划,以及各种节点异常问题的定位;
* 计算成本在很多场景中没有达到最优,比如对于一个定时运行 Jobs 的集群,长期持有资源池对于用户来说是浪费的行为,资源利用率不高。
对 Kubernetes 集群做减法
==================
无节点管理
-----
我们相信未来用户会更加关注应用的开发,而不是基础设施的维护。体现在 Kubernetes 集群中,我们希望用户能够关注在 pod/service/ingress/job 等应用编排语义上,对底层 node 则可以减少关注。
无需管理节点也可以显著降低集群的运维管理成本,经统计 Kubernetes 常见的异常问题中大多数与节点相关,比如 Node NotReady 问题,也无需担忧 Node 的安全问题,以及基础系统软件的升级和维护。
在 ASK 集群中,我们使用虚拟节点 virtual-kubelet 代替 ecs 节点,虚拟节点的容量可以认为是“无限大”,用户不需要为集群的容量担忧,无需预先做容量规划。
![2.png](https://ucc.alicdn.com/pic/developer-ecology/f8ce481400e54386b79ad4444f9849fa.png)
无 Master 管理
-----------
和 ACK 托管版一样,ASK 的 Master(apiserver, ccm, kcm 等)资源被容器服务平台托管,用户无需管理这些核心组件的升级和运维,也不用付出成本。
极简的 K8s 基础运行环境
--------------
除了无需管理节点和 Master 外,我们还对 Kubernetes 集群管理做了大量简化,包括默认托管很多 addon,用户无需再管理一些基础的 addon,也不需要为这些 addon 付费。依赖阿里云原生的网络和存储等能力,以及独特的托管架构设计,我们提供了极度简化但功能完备的 Kubernetes 基础运行环境。
功能
ACK
ASK
存储
需要部署 aliyun-disk-controller/flexvolume
无需部署(正在支持中)
CNI 网络
需要部署 terway/flannel daemonset
无需部署,基于 vpc 网络通信
coredns 服务发现
需要部署 2 个 coredns 副本
无需部署,基于 privatezone 访问
kube-proxy
需要部署 kube-proxy daemonset
无需部署,基于 privatezone 访问
Ingress
需要部署 nginx-ingress-controller
无需部署,基于 SLB 七层转发
免密拉取 ACR 镜像
需要部署 acr-credential-helper
无需部署,默认支持
sls 日志收集
需要部署 logtail daemonset
无需部署,默认支持
metrics 统计
需要部署 metrics-server
无需部署,开箱即用
挂载 eip
需要部署 terway
无需部署,使用 annotaion 指定
云盘随 pod 创建挂载
依赖 aliyun-disk-controller
无需部署,默认支持
弹性伸缩
需要部署 cluster-autoscaler
无需部署
GPU 插件
需要部署 Nivida-docker
无需部署,开箱即用
综上可以看到,ACK 集群至少需要 2 台 ecs 机器以运行这些基本的 Addon,而 ASK 集群把这些基础 Addon 化为无形,可以达到 0 成本创建一个开箱可用的 Kubernetes 集群。
简化弹性伸缩
------
因为无需管理节点和容量规划,因此当集群需要扩容时也就不需要考虑节点层面的扩容,只需要关注 pod 的扩容,
这对于扩容的速度和效率都是极大的提升,目前一些客户指定使用 ASK/ECI 的方式来快速应对业务流量高峰。
当前 ASK/ECI 支持 30s 完全启动 500 个 pod(至 Running 状态),单个 pod 启动可以达到 10s 以内。
更低成本
----
除去 ASK 集群本身的低成本创建外,pod 的按需使用也让很多场景下资源利用率达到最优。对于很多 Jobs 或者数据计算场景而言,用户并不需要长期维护一个固定的资源池,这时 ASK/ECI 可以很好的支持这些诉求。
经验证,当 pod 一天中运行时间少于 16 个小时,则 ASK/ECI 的方式相比保有 ecs 资源池更节省经济成本。
ECI:快速交付容器资源的弹性计算服务
-------------------
谈起 ASK,一定会谈到 ASK 的资源底座 ECI。ECI 是阿里云基于 ECS IaaS 资源池提供的稳定、高效、高弹性容器实例服务。ECI 让容器成为了公有云的第一等公民,用户无需购买和管理 ecs 就可以直接部署容器应用,这种简化的容器实例产品形态和 ASK 形成了一个完美的组合。
用户可以直接使用 ECI Open API 创建容器实例资源,但在容器场景中用户普遍需要一个编排系统,来负责容器的调度、高可用编排等能力,而 ASK 正是这样的 Kubernetes 编排层。
对于 ASK 而言,ECI 让 ASK 容器服务免去了搭建后台计算资源池的必要,更不用为底层计算资源池的容量而担忧。基于 ECI 就意味着基于整个阿里云 IaaS 规模化资源池,天然拥有了库存和弹性优势(比如可以通过 Annotation 的方式指定底层 eci 对应的 ecs 规格,大部分 ecs 规格都可以在 ASK 中使用,满足多种计算场景的需求)。另外 ECI 和 ECS 复用资源池意味着我们可以最大化释放规模化红利,给用户提供更低成本的计算服务。
容器生态支持
======
ASK 对 Kubernetes 容器生态提供了完善的支持,目前已有大量客户使用 ASK 来支撑如下各种场景:
* CI/CD:gitlab-runner,jenkins/jenkins-x
* 数据计算:spark/spark-operator,flink,presto,argo
* AI:tensorflow/arena
* ServiceMesh: istio,knative
* 测试:locust,selenium
> ASK 集群不支持 Helm v2,近期 ACK/ASK 会发布 Helm v3 的支持,之后用户可以非常方便的在 ASK 集群中部署 Charts。
[原文链接](https://link.zhihu.com/?target=https%3A//yq.aliyun.com/articles/739645%3Futm_content%3Dg_1000094672)
本文为阿里云内容,未经允许不得转载。
下一篇: 夺门之变对明朝内政造成了多大的影响?