`
大涛学长
  • 浏览: 105676 次
  • 性别: Icon_minigender_1
  • 来自: 北京
社区版块
存档分类
最新评论

Serverless Kubernetes入门:对kubernetes做减法

阅读更多
背景
--

Kubernetes作为通用的容器编排系统,承载了广泛的应用和场景,包括CI/CD,数据计算,在线应用,AI等,然而由于其通用性和复杂性,管理一个kubernetes集群对于很多用户而言还是充满挑战的,主要体现在:

*   学习成本高;
*   集群运维管理成本高,包括节点管理、容量规划,以及各种节点异常问题的定位;
*   计算成本在很多场景中没有达到最优,比如对于一个定时运行Jobs的集群,长期持有资源池对于用户来说是浪费的行为,资源利用率不高。

Serverless Kubernetes是阿里云容器服务团队对未来kubernetes演进方向的一种探索,通过对kubernetes做减法,降低运维管理负担,简化集群管理,让kubernetes从复杂到简单。

对Kubernetes集群做减法
----------------

### 无节点管理

我们相信未来用户会更加关注应用的开发,而不是基础设施的维护。体现在kubernetes集群中,我们希望用户能够关注在pod/service/ingress/job等应用编排语义上,对底层node则可以减少关注。

无需管理节点也可以显著降低集群的运维管理成本,经统计kubernetes常见的异常问题中大多数与节点相关,比如Node NotReady问题,也无需担忧Node的安全问题,以及基础系统软件的升级和维护。

在ASK集群中,我们使用虚拟节点virtual-kubelet代替ecs节点,虚拟节点的容量可以认为是“无限大”,用户不需要为集群的容量担忧,无需预先做容量规划。 
![image](https://yqfile.alicdn.com/bcf093a44401583625b15e23f65f3bc3e699630e.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

 

 

 

[原文链接](https://yq.aliyun.com/articles/730349?utm_content=g_1000090543)

本文为阿里云内容,未经允许不得转载。
分享到:
评论

相关推荐

Global site tag (gtag.js) - Google Analytics