Kubernetes在混合云架构下的应用 | U刻

<返回

• Kubernetes在混合云架构下的应用

  2019.06.13

  栏目：技术分享

  “托管云物理机纳入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即可邀请入群 。）

  Post Views: 2

  *本平台所发布文章信息，版权归UCloud所有，如需转载请注明出处！