在kubernetes集群中使用vk虚拟节点创建1万Pod-支持在线教育业务疫情高峰-低调大师

在kubernetes集群中使用vk虚拟节点创建1万Pod-支持在线教育业务疫情高峰

2020-02-08 710

使用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按需计费，不会占用固定节点资源池的容量。

相比较而言，AWS EKS在一个集群中最多只能创建1000个 Fargate Pod。基于vk虚拟节点的方式可以轻松创建过万个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

微信关注我们

原文链接：https://yq.aliyun.com/articles/744139

转载内容版权归作者及来源网站所有！

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。

Aliyun Funcraft v3.5.3 发布

Fun是一个用于支持Serverless 应用部署的工具，能帮助您便捷地管理函数计算、API 网关、日志服务等资源。它通过一个资源配置文件（template.yml），协助您进行开发、构建、部署操作。开通服务免费开通函数计算 v3.5.3版本北京时间 2020 年 02 月 10日 Aliyun Funcraft 发布了 v3.5.3 版本，该版本功能增强： fun build 支持 dotnetcore2.1 runtime fun local 以及 fun package 添加 build 生成的 meta.json 的支持 fun package 自动配置 NAS 的 PYTHONPATH Ros 部署错误信息优化 fun deploy 日志服务未开通时错误信息优化 fun deploy 时提供与线上服务配置的 diff 信息问题修复： Funfile 中 RUNTIME 比 template.yml 中 runtime 要高，二者不一致时给出警告大依赖中 NODE_PATH 环境变量的优先级调整修复 fun package 等命令 ctrl + c 不退出的问题 ...

2020-02-11

532

点击《架构师成长系列》立即订阅更多本系列直播对于大部分程序员来说，架构师是一个令人向往的角色。如果说程序员的工作是谋一域，作为架构师就需要对技术的深度和广度都有深刻的了解，是不折不扣的谋全局者。为了让更多普通开发者成为架构师，在不断的开发和学习各种知识，经验，在自我培养和技能强化中不断的提升，我们邀请 30+位阿里专家，整合 40+课时构建《架构师成长系列直播》以微服务、Devops、Serverless、消息中间件，4 个方向为切入点，以真实场景为例，深刻解读技术落地实践，洞悉技术发展方向，期待为广大程序员成为一名合格的架构师打下牢固的基础。系列 3：Serverless工程化落地与实践【系列介绍】 Serverless 是炙手可热的技术，被认为云计算的发展方向。拥有免运维、降低开发成本、按需自动扩展等优点。本系列直播将以真实场景下，Serverless 落地实践为案例，帮助开发者无需关注基础设置，更关注应用程序本身功能的实现。【观众收益】理解 Serverless 理念及应用架构多案例剖析 Serverless 使用场景及价值获得Serverless 场景化应用经验 ...

2020-02-11

583

资源下载

更多资源

优质分享App

近一个月的开发和优化，本站点的第一个app全新上线。该app采用极致压缩，本体才4.36MB。系统里面做了大量数据访问、缓存优化。方便用户在手机上查看文章。后续会推出HarmonyOS的适配版本。

腾讯云软件源

为解决软件依赖安装时官方源访问速度慢的问题，腾讯云为一些软件搭建了缓存服务。您可以通过使用腾讯云软件源站来提升依赖包的安装速度。为了方便用户自由搭建服务架构，目前腾讯云软件源站支持公网访问和内网访问。

Nacos

Nacos /nɑ:kəʊs/ 是 Dynamic Naming and Configuration Service 的首字母简称，一个易于构建 AI Agent 应用的动态服务发现、配置管理和AI智能体管理平台。Nacos 致力于帮助您发现、配置和管理微服务及AI智能体应用。Nacos 提供了一组简单易用的特性集，帮助您快速实现动态服务发现、服务配置、服务元数据、流量管理。Nacos 帮助您更敏捷和容易地构建、交付和管理微服务平台。

Rocky Linux

Rocky Linux（中文名：洛基）是由Gregory Kurtzer于2020年12月发起的企业级Linux发行版，作为CentOS稳定版停止维护后与RHEL（Red Hat Enterprise Linux）完全兼容的开源替代方案，由社区拥有并管理，支持x86_64、aarch64等架构。其通过重新编译RHEL源代码提供长期稳定性，采用模块化包装和SELinux安全架构，默认包含GNOME桌面环境及XFS文件系统，支持十年生命周期更新。