使用 NJet 作为 K8s 的 Ingress Controller - 高性能、可动态配置

Ingress Controller 是 Kubernetes 生态系统中的一个关键组件，它为管理进入集群的流量提供了一种声明式和灵活的方法。通过使用 Ingress Controller，开发者可以更容易地将应用程序暴露给外部网络，同时保持集群的安全性和可扩展性。

截至目前，基于不同的业务场景和技术架构，业界活跃着多种风格的 Ingress Controller 可供选择。Kubernetes 官方文档在也列出了常见的 Ingress 控制器，具体可参考链接所示：

https://kubernetes.io/docs/concepts/services-networking/ingress-controllers/#additional-controllers   

NJet-KIC 已在官网可查，欢迎大家试用！1

NJet KIC(Kubernetes Ingress Controller) 基于 NJet proxy 的动态特性、高性能实现。弥补 NGINX 在云原生场景中应用的不足。提供了丰富的流量管理能力，如动态 location、host/path 路由、负载均衡、动态 upstream、金丝雀发布、TLS Termination/SNI、TCP/UDP、WebSocket 等。目前已更新到 v2.0 版本。

本版本主要特性：

• 支持分片处理 Ingress/VS CR

• 支持与 ADC 集成

• 支持 HTTP 头操作

• 支持 TCP 代理

• 支持跨 namespace

• 支持 WebSocket 代理

• 支持 UDP 代理

• 支持动态 NJet VS/Accesslog

• 支持 TCP 主动健康检查

• 支持动态 worker 进程数调整  

新特性概览

动态 NJet VS

与第一版相比较，我们将单 server 多 location 的方式实现 HTTP host 头匹配，和 path 匹配，修改为多 server 多 location 的方式，使用 nginx 标准的 server_name 实现 host 头匹配，但是是动态化更新配置的，不需要进行 reload 操作。第二版针对 Ingress 和 VirtualServer 没有增加额外其他功能。

动态 Accesslog

KIC Accesslog 功能可以实现对某一个应用单独应用 accesslog 策略(包括开关状态、accesslog 文件路径)。也可以通过 njet-config ConfigMap 进行全局设置，但是"某一个应用单独应用 accesslog 策略"优先级更高。

TCP 主动健康检查

对于 Transport Server 资源，支持配置一个 TCP 端口，主动健康检查将根据配置的检查间隔，检测该 TCP 端口是否正常监听，并根据检查结果对后端进行上线及下线操作。

apiVersion: k8s.njet.org/v1alpha1 kind: TransportServer metadata: name: testapp-tcp spec: listener: name: test-tcp protocol: TCP upstreams: - name: testapp1 service: testapp port: 80 healthCheck: enable: true interval: 20s timeout: 5s fails: 1 passes: 1 port: 83 action: pass: testapp1

配置说明如下：

动态 worker 进程数调整

支持通过 ConfigMap 资源，配置 NJet 实例的 worker 进程数目，ConfigMap 中的配置项更新后，将触发 worker 进程数动态修改。

分片处理 Ingress/VS CR

针对不同的 Ingress/VS 资源有专门的 KIC 来处理，这就是 KIC 分片机制。

不同的 Ingress/VS 资源由 IngressClass 标识，Ingress 资源可以通过注解 kubernetes.io/ingress.class 或者 spec.ingressClassName 来标识，而 VS 资源可以通过 spec.ingressClassName 来标识。

注意，这种分片机制中的每一片 KIC 我们称为一类 KIC，且与 IngressClass 一一对应，一个 k8s 集群中，有多种 Njet KIC，那么就需要创建多个 IngressClass 对象。每一类 KIC 可以有多个副本(对应 k8s 架构中的多个 pod)。

分片机制，导致每种 KIC 拥有自己感兴趣的 Ingress/VS 资源，而不是 k8s 集群中的全量 Ingress/VS 资源。其旨在解决单类型 KIC 无法承受全量配置的压力的问题。

与 ADC 集成

KIC 与 ADC 集成后，ADC 可以作为 KIC 的前端 LB，通过 ADC 进行管理客户端流量并最终负载均衡到 KIC 服务。KIC 完成了如下功能：

• ADC 域名注册：KIC 向 ADC 注册了被 KIC 管理的 k8s 集群中的服务的域名，比如通过 k8s ingress、vs CR 管理的服务。此功能可以让客户端直接通过域名进行请求(需配置 ADC 的 DNS 服务器为默认 DNS 服务器)。

• ADC SlbPool 注册：KIC 向 ADC 注册了 KIC 服务关联的应用池(nodeIP+nodePort)，此功能可以让 ADC 路由到 KIC 服务。

• ADC VS 注册：KIC 向 ADC 注册了一个 VS，并关联第二步创建的应用池，此功能可以让客户端直接访问 VS，实现 ADC 可以作为 KIC 的前端 LB。

   

ADC VS 中的 VIP 与被 KIC 管理的服务的域名相对应。ADC VS 中的 VIP 为一个公网 IP，外部客户端可以直接访问。

整体架构

场景图：

交互架构图：