Kubernetes在混合云架构下的应用
“托管云物理机纳入UK8S集群统一管理后,可实现托管云物理机保障平峰时业务正常运行,高峰时期利用UK8S快速扩容公有云资源的理想应用场景,继而提升混合云的可用性。”——海豹他趣技术负责人 张嵩混合云的业务模式厦门海豹他趣信息技术股份有限公司于2012年4月成立,是一家基于 B2C 模式的综合性两性健康电商服务平台企业。目前采用混合云(公有云+托管云)的技术架构模式,在保证存量IT资源合...
“托管云物理机纳入UK8S集群统一管理后,可实现托管云物理机保障平峰时业务正常运行,高峰时期利用UK8S快速扩容公有云资源的理想应用场景,继而提升混合云的可用性。”
——海豹他趣技术负责人 张嵩
混合云的业务模式
厦门海豹他趣信息技术股份有限公司于2012年4月成立,是一家基于 B2C 模式的综合性两性健康电商服务平台企业。目前采用混合云(公有云+托管云)的技术架构模式,在保证存量IT资源合理利用的同时,又能够与公有云产品内网高速安全互通,实现资源的弹性扩展。
海豹他趣选择将部分数据敏感的业务部署在UCloud的托管云区域,通过租赁UCloud机房机柜的方式,托管自有设备,并依照自身电商业务特点进行高峰*冗余部署,但该模式下存在平峰时期物理机资源利用率低的现象。
业务容器化改造的过程中,海豹他趣已在公有云场景下实现UK8S的资源统一纳管,故想进一步提高托管云的资源利用率,实现托管云物理机保障平峰时业务正常运行,高峰时期利用UK8S快速扩容公有云资源的应用场景。
托管云中自建K8S集群的难题
起初,海豹他趣尝试在托管云中自建K8S集群,但运行后发现,同时在公有云和托管云中使用K8S集群,会存在网络互通、存储、负载均衡等方面的问题。与此同时,自行部署K8S集群需投入一支专业团队的人力成本,包含开发以及部署K8S网络、存储和负载均衡等工作,需自行挑选和部署第三方网络插件、搭建存储集群并适配K8S存储类型,以及维护一套负载均衡集群等。此外,集群搭建后的维护工作也费时费力。权衡之下,海豹他趣更希望将集群的管理和运维工作交给云厂商处理,从而自身精力能专注于业务研发之中。
托管云物理机纳入UK8S集群
UCloud已推出的UK8S能自动化实现公有云场景下的K8S集群部署以及运维工作,有效解决上述自行部署和维护K8S集群的难题。
同时,由于公有云和托管云分属不同的环境,在网络、服务器资源管理、控制等各方面完全独立,彼此之间仅有三层网络打通,要实现两者场景下K8S集群的统一略为繁琐。目前市面上各家云厂商针对混合云下的K8S集群部署,给出的解决方案多是在公有云和托管云下分别部署一套K8S集群,提供支持多集群管理的服务。
但考虑到该用户在跨集群模式下的困扰,UCloud开始策划将托管云物理机纳入UK8S现有集群统一管理的方案,即在混合云架构下仅需部署管理一套K8S集群。
解决三大技术问题
前文也提及,部署K8S集群需解决网络、存储以及负载均衡方案,UCloud的UK8S团队尝试在三个问题上逐个击破。
网络实现
K8S本身并不提供网络能力,而是将网络接口开放,由外部插件来实现,其网络模型需要满足以下条件:
1、 Node与Node节点之间可通过IP直接通信;
2、 不同节点的Pod之间可通过IP直接通信;
3、Pod与非宿主Node节点之间可通过IP直接通信。
首先,针对Node节点之间的通信。UK8S运行在公有云的VPC网络下,VPC网络与托管云虽属于不同的网段,但彼此间已实现三层互通,因此UK8S公有云中的Node节点与托管云中的物理机之间可通过IP直接通信,该条件满足。
其次是Pod之间以及Pod与Node节点间的通信问题,可具体描述为(1)公有云中的Pod与托管云中的Pod互通,(2)公有云中的Pod与托管云中的Node互通,或(3)公有云中的Node与托管云中的Pod互通。
下图是UK8S在公有云场景下的网络模型,采用Underlay方案,Pod与Node网络处于同一层面,CNI插件会调用UCloud API为每个Pod分配一个VPC IP。由于VPC IP已默认与托管云中的物理机互通,即代表公有云中的Pod已实现与托管云中的Node互通,此外公有云中Pod与Node网络同等,上述待解决问题可简化为公有云中的Pod与托管云中的Pod互通。
图:公有云下的网络模型
为实现Pod之间的互通,托管云的网络模型也同样采用Underlay模式。如下图所示,两者场景下所有的Node节点均采用Underlay模式的CNI插件,公有云中的Node已默认安装CNI-VPC插件,托管云中的Node可采用二层Bridge或自定义路由的Underlay模式CNI插件。
图:混合云下的网络模型
以自定义路由为例,托管云的网段为172.16.0.0/16,安装kubelet后,将Bridge插件拷贝至/opt/cni/bin下,再配置插件启动参数即可。CNI插件会在Node上先创建一个网桥,当Pod启动时,通过veth pair连接该网桥到pause容器的网络命名空间,即可实现托管云中的Pod互通。由于172.16.0.0/16已在网关上配置完成,最后在交换机侧配置自定义路由,可最终完成公有云中的Pod与托管云中的Pod互通。
图:交换机侧配置信息
存储实现
除去内置的存储插件,UK8S在公有云中额外集成UDisk、UFS两种云储存产品。目前UCloud托管云中物理机尚不支持挂载云存储产品,因此UK8S中的存储插件需实现兼容,只支持挂载至公有云中的Node节点上。
实现形式上,给公有云中的Node节点打上类似nodetype: uhost的标签即可。用户使用时,若Pod需要挂载单写模式的存储卷,在调度Pod时声明nodeAffinity,就可指定Pod分配至公有云中的Node节点。
负载均衡实现
最后需解决服务如何对外暴露的问题,K8S提供了几种服务暴露的方案,其中LoadBalancer类型的Service最为通用,同时由于在托管云中维护一个可靠的负载均衡设备成本较高,故使用公有云中的ULB作为K8S的外部负载均衡器。
业务流量入口由公有云的ULB和Node节点承载,通过在K8S集群中定义LoadBalancer类型的Service,业务流量可先通过ULB转发到公有云Node节点上,再通过公有云节点上kube-proxy配置的iptables规则转发至整个集群中实际工作的Pod。对于ClusterIP类型的Service,与现有K8S集群无异,通过kube-proxy在集群内部通信。
此外,也可在公有云节点部署Ingress Controller,代理部署在托管云节点的业务流量。
图:流量转发链路
采用该方案实现的效果
1、提高托管云物理机的利用率
托管云物理机纳入UK8S集群统一管理后,可实现托管云物理机保障平峰时业务正常运行,高峰时期利用UK8S快速扩容公有云资源的应用场景,无需原先的高峰*冗余部署,有效解决平峰时期资源利用率低的问题,从而节约资源成本。
2、减少公有云主机资源的冗余
实际业务中,遇到大型活动或突增的服务请求时, 采用云主机自动服务扩容的方式处理速度较慢,通常需要五分钟左右的时间,而利用UK8S可以赚取云主机启动与容器启动速度的时差,做到资源的快速扩容,继而减少云主机日常冗余的数量。
3、无需K8S部署和维护的人力投入
用户可在UK8S上部署、管理以及扩展容器化应用,而无需关心K8S集群自身的搭建及维护等运维类工作,能够更加集中于业务实现。
4、加快服务上线速度
一方面,UK8S中通过统一的镜像,可保证代码及部分配置在测试环境、预发布环境、正式环境中的一致性, 避免环境不一致引发的异常状况;另一方面,UK8S有其完善的CI/CD流程,可简化服务部署步骤, 有效减少服务上线时的人工干预,实现效率的全面提升。
写在最后
随着K8S使用的逐步增多,运行部署K8S的环境也日趋复杂,对于企业IT人员而言,找到一种兼容现有业务环境的K8S配置、管理方式显得尤为重要,特别是在多云、IDC与云并存等环境下如何配置K8S。上述提供的针对UCloud混合云场景下的K8S部署方案,其思路同样适用于非UCloud混合云环境。
欢迎加入UCloud K8S技术交流群,和我们共同探讨Kubernetes前沿技术。(由于群人数已超过100人,请添加群主微信zhaoqi628543,备注K8S即可邀请入群。)
更多推荐
所有评论(0)