品牌名称
思必驰
所在行业
科技
企业规模
51-200人

为什么我们重写 k8s ingress controller

331次阅读

大家好,我是来自苏州思必驰的金卫,今天和大家聊聊 Apache APISIX 与 k8s 集成代替原生 ingress 的话题。

 

写这篇文章时,我们已经在生产环境上应用了 Apache APISIX,接管了部分业务的入口流量,同时正逐步把原生 ingress 中流量迁移过来,如下图所示:

 

2.png

 

借助 Apache APISIX 动态路由能力做流量分发,同时自定义一些插件,满足业务需求。

 

APISIX-ingress-controller 将 pod ip 注册到 upstream 的,node 中,业务流量可以绕过 kube DNS 直接访问到 pod。也正是在此基础上,可以通过插件实现一些特殊负载均衡策略。

 

从图上看,好像做了一件与原生 ingress 重复的事情。那这篇文章我们就简单介绍一下为什么舍弃原生 ingress,用 Apache APISIX 自建一套 ingress controller。

 

ingress 是什么

简单讲,Ingress 是 Kubernetes 处理边缘入口流量的一种方式。

 

ingress 解决什么问题

由于 Kubernetes 集群内的服务都是虚拟网络,外部流量访问集群内部,至少需要一个公网ip和端口映射。

 

Kubernetes 原生 ingress controller 的问题

Nginx ingress controller 帮助我们维护了 Kubernetes 集群与 Nginx 的状态同步,并且提供了基本的反向代理能力,为什么我们还要自己造个轮子呢? 业务的需求不容忽视,我们对 ingress controller 有更多的期待。

 

在使用 Kubernetes 原生 ingress controller 之后,我们发现以下几点比较突出的问题:

reload 问题

 

Kubernetes 原生 ingress 在设计上,将 YAML 配置文件交由 ingress controller 处理,转换为 nginx.conf,再触发 reload nginx.conf 使配置生效。

 

日常运维免不了偶尔动一动 ingress YAML 配置,每一次配置生效,都会触发一次 reload,这是不能接受的,尤其在边缘流量采用⻓连接时,更容易导致事故。

 

Apache APISIX 支持热配置,随时可以定义和修改路由,而且不会触发 nginx reload。

 

在 annotation 中写脚本、填充参数

原生 ingress controller 支持在 yaml 中 annotation 定义脚本片段,感觉是为了支持高级功能而实现的一个临时方案,说实话,真不好管理。大量的 annotation 脚本给配置人员带来困扰。

 

在 Apache APISIX 中,我们可以通过插件代码编写逻辑,暴露出简单的配置接口,方便配置的维护,避免脚本对配置人员的干扰。

 

缺少对有状态负载均衡的支持

 

动态调整权重

业务服务常常需要按照百分比控制流量,这在 Kubernetes 中却变成了麻烦。

 

扩展能力薄弱

 

 

Apache APISIX ingress controller

由于 Apache APISIX 强大的路由和扩展能力,将 Apache APISIX 作为 ingress 的一种实现,可以轻松解决以上提到的痛点,也为社区多一种 ingress controller 选择。

时序图如下:

 

1.png

 

想要实现 Apache APISIX ingress controller,需要解决两类基础问题,一是解决 kubernetes 集群与 Apache APISIX 状态的同步; 二是将 Apache APISIX 中的对象在 kubernetes 中定义出来 (CRD)。

 

为了快速集成 Apache APISIX,发挥出 Apache APISIX 的优势,我们创建了 Apache APISIX ingress controller 项目(欢迎大家参与),该项目目前初步实现了第一类基础问题: 同步 Kubernetes pod 信息到 Apache APISIX 中的 upstream,同时实现主备,解决自身的高可用问题。

 

由于 Kubernetes 采用 YAML 申明式定义集群状态,我们需要为 Apache APISIX 中的对象(route/service/upstream/plugin) 定义 CRD(Custom Resource Definitions), 以融入 kubernetes。

 

同时为了方便现有 Kubernetes ingress 使用者的迁移,我们会尽量兼容现有 ingress 的配置项。

 

这些特性将是我们接下来努力的目标,欢迎大家一起参与。