什么是入口?

入口是一个 API 对象,它允许通过定义边缘入口流量路由规则(例如负载平衡、SSL 终止、基于路径的路由、协议)从 Kubernetes 集群外部访问您的 Kubernetes 服务。入口使用公共 IP 和端口映射管理对集群内服务的外部访问。

负责执行此操作的组件称为 Ingress 控制器。

[](https://res.cloudinary.com/practicaldev/image/fetch/s--4Okle4yQ--/c_limit%2Cf_auto%2Cfl_progressive%2Cq_auto%2Cw_880/https://cdn.hashnode.com/ res/hashnode/image/upload/v1649772100803/4IArmUThS.png)

K8s Ingress Controller 在集群中的角色?

在 Kubernetes 应用程序中,Pod 在集群内部运行,而负载均衡器在外部运行。负载均衡器负责接受来自 Internet 的连接并将它们路由到位于集群内的边缘代理。此边缘代理负责将流量路由到您的 pod。您可以使用入口通过单个 IP 地址路由多个后端服务。

入口控制器是实现入口的第三方边缘代理。他们负责读取入口资源信息并相应地处理该数据。入口控制器不替换负载均衡器;相反,它在负载均衡器后面添加了一层路由和控制。

• 它有助于将路由规则合并到一个位置。

• 它的声明、创建和销毁独立于您希望公开的服务。

• 使用 Kubernetes API 配置以部署称为“入口资源”的对象。

缺点

Kubernetes 提供了几种公开边缘接口的方法,包括节点端口、负载均衡器、入口等。入口无疑是使用反向代理的一种更具成本效益的方式,因为它显示了有限数量的公共 IP。但是,一旦实施,它就会伴随着特定的风险,例如复杂性、延迟和安全性。这些问题经常交织在一起;如果有人在场,其他人可能会。

复杂:

微服务架构采用轻量级和简单的设计构建,这是大多数组织在其应用程序中寻找的功能。然而,K8s Ingress 并没有坚持这些原则,因为它主要是使用复杂的脚本和函数来开发的。这会导致实现它的底层引擎的复杂性,甚至会使配置器更加困惑。 Kubernetes 是一个过于复杂的工具,必须实现其他复杂的功能可能会影响应用程序的可扩展性和整体性能。

缺乏对有状态负载平衡的支持:

Kubernetes是一个面向运维的非业务管理系统。因此,不支持会话持久性等复杂的负载平衡解决方案。它在短期内也不支持这些矛盾的负载平衡解决方案。

Google 已经尝试通过其服务网格解决方案(istio)来解决这个问题。 istio 架构完美无缺。但是,它会影响性能,可以使用其混合器 v2 进行补救。

动态调整权重:

在 Kubernetes 中按百分比控制流量是很棘手的,尽管这是大多数组织都在寻找的功能。但是,在 v1.8 之后,Kubernetes 开始支持IPVS作为 Kube-proxy 启动参数或 Kube-route 的注解。

弱可扩展性:

尽管开发人员创建了入口来解决边缘流量,但人们对管理边缘流量的渴望等于或大于他们对内部流量的需求。

业务级灰度控制、熔断、流控、鉴权、流控是ingress上流行的基本需求。但是,原生入口扩展在这些方面受到限制。

重新加载问题:

YAML 配置文件由 ingress 控制器解析,转换为 Nginx.conf,然后触发重新加载 Nginx.conf,使设置在 Kubernetes 原生 ingress 架构中生效。

日常运维难免偶尔会碰到入口 YAML 配置。每次配置生效,都会触发重载。这是不可接受的,主要是当边缘交通使用长连接时,这更有可能导致事故。

为什么选择 Apache APISIX 入口控制器?

APISIX Ingress 是另一个 Ingress Controller 实现。 APISIX Ingress 与 Kubernetes Ingress Nginx 的不同之处在于它使用 Apache APISIX 作为业务流量的实际数据平面。使用 Apache APISIX 作为入口实现可以帮助解决上述缺点,同时还为社区提供额外的入口控制器选项。

[](https://res.cloudinary.com/practicaldev/image/fetch/s--IcXSQmGn--/c_limit%2Cf_auto%2Cfl_progressive%2Cq_auto%2Cw_880/https://cdn.hashnode.com/ res/hashnode/image/upload/v1649772103547/rhxrheSRf.png)

解决复杂性:

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

支持有状态负载均衡:

Apache APISIX 原生支持会话持久化等负载均衡,并保留了 balancer 阶段的扩展能力。由于 Kubernetes 允许项目扩展,完全基于 Apache APISIX 可以扩大高级负载均衡需求。

本质上是动态的:

Apache APISIX 抽象出路由、服务、消费者、上游、插件等主要对象,自然支持权重调整等操作。因此,在上游改变节点权重。

扩展能力:

在扩展能力方面,Apache APISIX 支持插件。除了官方提供的插件外,您还可以创建自定义插件以满足您的特定需求。

热重载:

Apache APISIX 支持热配置,可以随时定义和修改路由,不会触发 Nginx 重载。所以无论是在磁盘内添加、删除或修改插件,更新插件代码,都不需要重启服务。

在 AISpeech 中实现 APISIX 入口控制器

AI Speech是领先的语音技术平台。它专门研究计算机语音识别、音调分析和对话管理技术。

[](https://res.cloudinary.com/practicaldev/image/fetch/s--hWgSwp26--/c_limit%2Cf_auto%2Cfl_progressive%2Cq_auto%2Cw_880/https://cdn.hashnode .com/res/hashnode/image/upload/v1649772105766/hbZwJwqi1.png)

为了实现 Apache APISIX 入口控制器,AISpeech 考虑了两个需要立即关注的挑战。

• 同步 Kubernetes 集群和 Apache APISIX 的状态。

Apache APISIX 入口控制器项目通过将 Kubernetes pod 信息与 APISIX 中的上游同步来解决此问题。同时,构建主系统和备份系统以管理其高可用性问题。

• 在 Kubernetes 自定义资源定义中定义 Apache APISIX 中的对象(CRD)。

Apache APISIX 入口提供 CRD 支持以更好地理解声明性配置。但是,状态检查可确保快速访问声明性配置的同步状态。由于 Kubernetes 使用 YAML 声明集群状态,因此必须在 Apache APISIX 中定义 CRD,以便对象(路由/服务/上游/插件)集成到 Kubernetes 中。

结论

Kubernetes 有几种流行的 Ingress 控制器,但为您的应用程序选择正确的一种总是很棘手。随着您的应用程序扩展,您需要考虑在测试和生产模式下与您的 Kubernetes 应用程序保持一致的入口控制器。Apache APISIX 入口控制器是一个开源项目,可以满足所有这些需求。