设为首页 - 加入收藏 ASP站长网(Aspzz.Cn)- 科技、建站、经验、云计算、5G、大数据,站长网!
热搜: 创业者 数据 手机
当前位置: 首页 > 站长资讯 > 动态 > 正文

KubeSphere 帮助本来生活网在 K8s 物理环境暴露集群服务

发布时间:2020-04-08 01:28 所属栏目:15 来源:站长网
导读:副标题#e# 本来生活网架构负责人陈杰 关于本来生活网 本来生活网创办于 2012 年,是一个专注于食品、水果、蔬菜的电商网站,从优质食品供应基地、供应商中精挑细选,剔除中间环节,提供冷链配送、食材食品直送到家服务。致力于通过保障食品安全、提供冷链宅

本来生活网架构负责人陈杰

关于本来生活网

本来生活网创办于 2012 年,是一个专注于食品、水果、蔬菜的电商网站,从优质食品供应基地、供应商中精挑细选,剔除中间环节,提供冷链配送、食材食品直送到家服务。致力于通过保障食品安全、提供冷链宅配、基地直送来改善中国食品安全现状,成为中国优质食品提供者。

KubeSphere 帮助本来生活网在 K8s 物理环境暴露集群服务

技术现状

基础设施

部署在 IDC 机房

拥有 100 多台物理机

虚拟化部署

存在的问题

物理机 95% 以上的占用率

相当多的资源闲置

应用扩容比较慢

互联网、电商公司的核心业务集中在线上进行,IT 支持决定公司的命脉。本来生活网原本的 IT 基础设施以传统虚拟化的方式部署在 IDC 机房,物理机日常占用率达到了 95% 以上,资源紧缺,应用弹性扩容缓慢,无法满足线上业务的需求。

同时,本来生活网虽然是一家互联网电商公司,但很早就停止了烧钱模式,开始追求盈利,对IT 建设也提出了尽量平衡成本、开源节流的要求。所以,本来生活网迫切需要重构基础设施,建设一套更为灵活、更为敏捷的 IT架构,帮助自己优化开发运维流程,最大程度提高应用开发效率并降低 IT生产环境运维成本。

迁移到 Kubernetes

最终,我们决定将生产环境容器化,把生产环境从虚拟化迁移到 Kubernetes 上,这样做的好处有以下几点:

提高资源的利用率

使应用能快速扩容

降低运维人员工作复杂度

此外,本来生活的应用发布由测试团队完成,但测试人员缺乏一定的开发运维经验,无法快速上手 Kubernetes 实现版本快速迭代。想要打通开发、测试与运维的 DevOps 一体化流程,需要有一个统一的平台配合应用开发和上线发布整套流程。我们通过大量调,选择可视化覆盖率高、运维友好、简单易用 KubeSphere 作为底层容器平台,我们在上进行二次开发,这样可以帮助我们节省很多开发时间。

KubeSphere 帮助本来生活网在 K8s 物理环境暴露集群服务

如何暴露集群

由于本来生活网是基于物理机也就是裸机(Bare Metal)部署,所以无论基于什么平台还是要考虑如何暴露 K8s 集群,目前,常用的暴露K8s 集群的方式有以下几种:

KubeSphere 帮助本来生活网在 K8s 物理环境暴露集群服务

LoadBalancer

LoadBalancer 是 Kubernetes 官方推荐的暴露方式,很可惜使用 LoadBalancer需要部署在云上。本来生活网是全部是裸机环境部署,因此这个方式在一开始就被我们放弃了。

NodePort

NodePort 的端口范围一般是 30000 以上,每个端口只能对应一种服务,随着应用越来越多,端口可能不够用。除此之外,它最大的问题是如果你暴露某一个节点给外部访问,那么这个节点会成为单点。如果你要做高可用,这几个节点都暴露出去,前面一样需要要部属一个负载均衡,这样事情就变得复杂了。

Ingress

Ingress 可以解决 NodePort 端口复用的问题,它工作在7 层上,可以复用 80 和 443 端口。使用 Ingress 的前提是必须要有 Ingress Controller 配合,而 Ingress Controller 同样会出现暴露端口并公开的问题。这时候如果你用 HostNetwork 或 HostPort 把端口暴露在当前的节点上,就存在单点问题;如果你是暴露多个节点的话,同样需要在前面再加一个 LoadBalancer。

HostNetwork/HostPort

这是一种更暴力的方式,直接把 Pod 的端口绑定到宿主机的端口上。这时候端口冲突会是一个很大的问题,同时单点问题依旧存在。

发现 Porter

我们当时没有想出如何更优雅的解决这个问题,甚至都决定是不是还要像以前一样,在前面加一套 HAProxy with keepalived 做高可用。

后来我在浏览 KubeSphere 的文档时,在安装负载均衡器插件页面底部看到了一行不起眼的文字:

"Porter 是一款适用于物理机部署 Kubernetes 的负载均衡器,该负载均衡器使用物理交换机实现,利用 BGP 和 ECMP 从而达到性能最优和高可用性,Porter 是一个提供用户在物理环境暴露服务和在云上暴露服务一致性体验的插件。"

看到了物理机部署的字样后,我们发现这正是我们需要的东西。

Porter 是开源项目 KubeSphere 下的子项目,的所有代码和文档已在 GitHub 开源 ,欢迎大家关注和使用。

使用 Porter 的前置条件

我们对 Porter 研究了很久,中间也踩了较多的坑,总结下来要用这个东西必须满足以下条件:

首先你的路由器,也可以是三层交换机需要支持 BGP 协议。现在大多数路由设备都会支持这个协议,所以这个条件一般都能满足;

其次集群节点上不能有和路由器建立 BGP 通信的服务。举例来说,当使用 Calico 时,开启了 BGP 模式。它的 BGP 模式有一种方式是让所有代理同时连到一个路由器,如果 Calico 和 Porter 要连的路由器是同一个的话,需要注意这个方案是有问题的。而 KubeSphere 默认安装的 Calico 是 IPIP 模式的,所以我们没有遇到冲突问题;

最后一定要有网络运维人员支持,配合你完成路由器配置以及了解整个网络拓扑结构。了解网络拓扑结构是非常重要的,否则会遇到很多问题。

物理部署架构图

KubeSphere 帮助本来生活网在 K8s 物理环境暴露集群服务

Porter 官方介绍比较简单,有三张图片。这是第一张。这个网络结构应该是云环境的网络拓扑结构。在公司测试环境或者普通小机房不一定有这么复杂的网络结构。

我们来看下它是如何工作的,首先当你访问云上的 1.1.1.1 地址,请求转到 Border 路由器,Border 路由器再转到 Spine 交换机,Spine 交换机再转到 leaf 交换机,最后落到 K8s 的集群节点上。

Porter 的主要作用就是动态告诉这些路由器,整个路由应该怎么走。

(编辑:ASP站长网)

网友评论
推荐文章
    热点阅读