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