在kubernetes集群中使用多vk虚拟节点创建1万Pod
使用vk虚拟节点提升k8s集群容量和弹性
在kubernetes集群中添加vk虚拟节点的方式已被非常多的客户普遍使用,基于vk虚拟节点可以极大提升集群的Pod容量和弹性,灵活动态的按需创建ECI Pod,免去集群容量规划的麻烦。目前vk虚拟节点已广泛应用在如下场景。
- 在线业务的波峰波谷弹性需求:如在线教育、电商等行业有着明显的波峰波谷计算特征,使用vk可以显著减少固定资源池的维护,降低计算成本。
- 提升集群Pod容量:当传统的flannel网络模式集群因vpc路由表条目或者vswitch网络规划限制导致集群无法添加更多节点时,使用虚拟节点可以规避上述问题,简单而快速的提升集群Pod容量。
- 数据计算:使用vk承载Spark、Presto等计算场景,有效降低计算成本。
- CI/CD和其他Job类型任务
下面我们介绍如何使用虚拟节点快速创建1万个pod,这些eci pod按需计费,不会占用固定节点资源池的容量。
创建多个vk虚拟节点
请先参考ACK产品文档部署虚拟节点:https://help.aliyun.com/document_detail/118970.html
因为使用多个vk虚拟节点往往用于部署大量ECI Pod,我们建议谨慎确认vpc/vswitch/安全组的配置,确保有足够的vswitch ip资源(vk支持配置多个vswitch解决ip容量问题),使用企业级安全组可以突破普通安全组的2000个实例限制。
通常而言,如果单个k8s集群内eci pod数量小于3000,我们推荐部署单个vk节点。如果希望在vk上部署更多的pod,我们建议在k8s集群中部署多个vk节点来对vk进行水平扩展,多个vk节点的部署形态可以缓解单个vk节点的压力,支撑更大的eci pod容量。这样3个vk节点可以支撑9000个eci pod,10个vk节点可以支撑到30000个eci pod。
为了更简单的进行vk水平扩展,我们使用statefulset的方式部署vk controller,每个vk controller管理一个vk节点,statefulset的默认Pod副本数量是1。当需要更多的vk虚拟节点时,只需要修改statefulset的replicas即可。
# kubectl -n kube-system scale statefulset virtual-kubelet --replicas=4 statefulset.apps/virtual-kubelet scaled # kubectl get no NAME STATUS ROLES AGE VERSION cn-hangzhou.192.168.1.1 Ready <none> 63d v1.12.6-aliyun.1 cn-hangzhou.192.168.1.2 Ready <none> 63d v1.12.6-aliyun.1 virtual-kubelet-0 Ready agent 1m v1.11.2-aliyun-1.0.207 virtual-kubelet-1 Ready agent 1m v1.11.2-aliyun-1.0.207 virtual-kubelet-2 Ready agent 1m v1.11.2-aliyun-1.0.207 virtual-kubelet-3 Ready agent 1m v1.11.2-aliyun-1.0.207 # kubectl -n kube-system get statefulset virtual-kubelet NAME READY AGE virtual-kubelet 4/4 1m # kubectl -n kube-system get pod|grep virtual-kubelet virtual-kubelet-0 1/1 Running 0 1m virtual-kubelet-1 1/1 Running 0 1m virtual-kubelet-2 1/1 Running 0 1m virtual-kubelet-3 1/1 Running 0 1m
当我们在vk namespace中创建多个nginx pod时(将vk ns加上指定label,强制让ns中的pod调度到vk节点上),可以发现pod被调度到了多个vk节点上。
# kubectl create ns vk # kubectl label namespace vk virtual-node-affinity-injection=enabled # kubectl -n vk run nginx --image nginx:alpine --replicas=10 deployment.extensions/nginx scaled # kubectl -n vk get pod -o wide NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES nginx-546c47b569-blp88 1/1 Running 0 69s 192.168.1.26 virtual-kubelet-1 <none> <none> nginx-546c47b569-c4qbw 1/1 Running 0 69s 192.168.1.76 virtual-kubelet-0 <none> <none> nginx-546c47b569-dfr2v 1/1 Running 0 69s 192.168.1.27 virtual-kubelet-2 <none> <none> nginx-546c47b569-jfzxl 1/1 Running 0 69s 192.168.1.68 virtual-kubelet-1 <none> <none> nginx-546c47b569-mpmsv 1/1 Running 0 69s 192.168.1.66 virtual-kubelet-1 <none> <none> nginx-546c47b569-p4qlz 1/1 Running 0 69s 192.168.1.67 virtual-kubelet-3 <none> <none> nginx-546c47b569-x4vrn 1/1 Running 0 69s 192.168.1.65 virtual-kubelet-2 <none> <none> nginx-546c47b569-xmxx9 1/1 Running 0 69s 192.168.1.30 virtual-kubelet-0 <none> <none> nginx-546c47b569-xznd8 1/1 Running 0 69s 192.168.1.77 virtual-kubelet-3 <none> <none> nginx-546c47b569-zk9zc 1/1 Running 0 69s 192.168.1.75 virtual-kubelet-2 <none> <none>
运行1万个ECI Pod
在上述步骤中我们已经创建了4个vk虚拟节点,能够支撑12000个ECI Pod,我们只需要将workload指定调度到vk节点即可。这里我们需要关注kube-proxy的可扩展性。
- vk创建的ECI Pod默认支持访问集群中的ClusterIP Service,这样每个ECI Pod都需要watch apiserver保持一个连接以监听svc/endpoints变化。当大量pod同时Running时,apiserver和slb将维持Pod数量的并发连接,所以需要确保slb规格能否支撑期望的并发连接数。
- 如果ECI Pod无需访问ClusterIP Service,则可以将vk statefulset的ECI_KUBE_PROXY环境变量值设置为"false",这样就不会有大量slb并发连接的存在,也会减少apiserver的压力。
- 我么也可以选择将ECI Pod访问的ClusterIP Service暴露成内网slb类型,然后通过privatezone的方式让ECI Pod不必基于kube-proxy也能否访问到集群中的Service服务。
缩减vk虚拟节点数量
因为vk上的eci pod是按需创建,当没有eci pod时vk虚拟节点不会占用实际的资源,所以一般情况下我们不需要减少vk节点数。但用户如果确实希望减少vk节点数时,我们建议按照如下步骤操作。
假设当前集群中有4个vk节点,分别为virtual-kubelet-0/.../virtual-kubelet-3。我们希望缩减到1个vk节点,那么我们需要删除virtual-kubelet-1/../virtual-kubelet-3这3个节点。
- 先优雅下线vk节点,驱逐上面的pod到其他节点上,同时也禁止更多pod调度到待删除的vk节点上。
# kubectl drain virtual-kubelet-1 virtual-kubelet-2 virtual-kubelet-3 # kubectl get no NAME STATUS ROLES AGE VERSION cn-hangzhou.192.168.1.1 Ready <none> 66d v1.12.6-aliyun.1 cn-hangzhou.192.168.1.2 Ready <none> 66d v1.12.6-aliyun.1 virtual-kubelet-0 Ready agent 3d6h v1.11.2-aliyun-1.0.207 virtual-kubelet-1 Ready,SchedulingDisabled agent 3d6h v1.11.2-aliyun-1.0.207 virtual-kubelet-2 Ready,SchedulingDisabled agent 3d6h v1.11.2-aliyun-1.0.207 virtual-kubelet-3 Ready,SchedulingDisabled agent 66m v1.11.2-aliyun-1.0.207
之所以需要先优雅下线vk节点的原因是vk节点上的eci pod是被vk controller管理,如果vk节点上还存在eci pod时删除vk controller,那样将导致eci pod被残留,vk controller也无法继续管理那些pod。
- 待vk节点下线后,修改virtual-kubelet statefulset的副本数量,使其缩减到我们期望的vk节点数量。
# kubectl -n kube-system scale statefulset virtual-kubelet --replicas=1 statefulset.apps/virtual-kubelet scaled # kubectl -n kube-system get pod|grep virtual-kubelet virtual-kubelet-0 1/1 Running 0 3d6h
等待一段时间,我们会发现那些vk节点变成NotReady状态。
# kubectl get no NAME STATUS ROLES AGE VERSION cn-hangzhou.192.168.1.1 Ready <none> 66d v1.12.6-aliyun.1 cn-hangzhou.192.168.1.2 Ready <none> 66d v1.12.6-aliyun.1 virtual-kubelet-0 Ready agent 3d6h v1.11.2-aliyun-1.0.207 virtual-kubelet-1 NotReady,SchedulingDisabled agent 3d6h v1.11.2-aliyun-1.0.207 virtual-kubelet-2 NotReady,SchedulingDisabled agent 3d6h v1.11.2-aliyun-1.0.207 virtual-kubelet-3 NotReady,SchedulingDisabled agent 70m v1.11.2-aliyun-1.0.207
- 手动删除NotReady状态的vk节点
# kubelet delete no virtual-kubelet-1 virtual-kubelet-2 virtual-kubelet-3 node "virtual-kubelet-1" deleted node "virtual-kubelet-2" deleted node "virtual-kubelet-3" deleted # kubectl get no NAME STATUS ROLES AGE VERSION cn-hangzhou.192.168.1.1 Ready <none> 66d v1.12.6-aliyun.1 cn-hangzhou.192.168.1.2 Ready <none> 66d v1.12.6-aliyun.1 virtual-kubelet-0 Ready agent 3d6h v1.11.2-aliyun-1.0.207
低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
远程办公一周复盘
上周一,很多公司开始了远程办公,一周过去了,疫情控制虽有所起色,但去公司集体撸代码的日子依然遥远,远程办公将成为更多企业的选择。 想必已经开工的各位技术 Leader 们都已经收到了老板的灵魂拷问:远程办公效率怎么样?进度能保证吗?怎么让兄弟们在家撸代码更高效? 我们来谈谈如何能够在老板问起时,如何能保持淡定吧。 任务清晰明确 VS 群聊安排 远程办公最大的影响就是沟通的便捷性和实时性,为了避免等到开发同学提交后才知道做的事情都错了,作为技术 Leader,我们要清晰地将每天的任务和大家沟通清楚,并形成记录,避免在 IM 中群聊安排工作。 首先是,建议每天要与所有开发同学开一次远程“站会”(电话 or 视频),并且“站会”建议在工作时间开始的时候开,一方面向大家传递一天的工作要开始了,更重要的是“站会”上要沟通清楚每位同学每天的“任务”,任务的粒度建议要到天级别,任务要有明确的产出标准。 其次,任务最好要有工具记录下来,工具最好还要能够与我们的代码托管结合起来,解决我们接下来的进展同步的问题。 Gitee 企业版提供的任务管理功能,能够通过“任务卡片”清晰记录任务的责任人、时间要求、验...
- 下一篇
面对业务增长,Uber是如何扩展HDFS文件系统的
3年前,Uber采用了Hadoop作为大数据分析的存储(HDFS)和计算(YARN)基础设施。借助于这套系统,Uber的服务能力得到了增强,用户体验也得到了提升。 Uber将基于Hadoop的批量和流式分析应用在了广泛的场景中,例如反作弊、机器学习和ETA计算等。随着过去几年的业务增长,Uber的数据容量和访问负载也呈现了指数级增长的趋势,如:仅2017年,存储在HDFS中的数据量就增加了超过400%。 同时保证系统扩展能力和高性能并不是一件容易的事情。Uber的数据基础设施团队采用了多种方式来扩展HDFS系统,例如视图文件系统(ViewFS)、频繁的HDFS版本更新、NameNode的垃圾回收调优、减少小文件的数量、HDFS负载管理服务、只读的NameNode副本等。下面将详细介绍,Uber是如何通过这些改进措施来保证存储系统的持续
相关文章
文章评论
共有0条评论来说两句吧...
文章二维码
点击排行
推荐阅读
最新文章
- 设置Eclipse缩进为4个空格,增强代码规范
- CentOS6,CentOS7官方镜像安装Oracle11G
- SpringBoot2整合Thymeleaf,官方推荐html解决方案
- CentOS7编译安装Cmake3.16.3,解决mysql等软件编译问题
- SpringBoot2配置默认Tomcat设置,开启更多高级功能
- SpringBoot2全家桶,快速入门学习开发网站教程
- Docker快速安装Oracle11G,搭建oracle11g学习环境
- CentOS7,CentOS8安装Elasticsearch6.8.6
- CentOS8,CentOS7,CentOS6编译安装Redis5.0.7
- MySQL8.0.19开启GTID主从同步CentOS8