为什么我们重写 k8s ingress controller

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

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

借助 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 选择。

时序图如下:

想要实现 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 的配置项。

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