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

最新推荐文章于 2025-06-11 17:25:06 发布

原创最新推荐文章于 2025-06-11 17:25:06 发布

· 1k 阅读

11 ·

版权

文章标签：

#kubernetes #云原生 #nginx

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

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

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

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

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

配置说明如下：

字段	描述	类型	是否必填
enable	是否启用健康检查，默认false	boolean	No
interval	检查的间隔时间。默认为 5	string	No
fails	失败几次后将视为下线。默认1次	integer	No
passes	成功几次后将视为上线。默认1次	integer	No
port	健康检查服务所在端口	integer	No
timeout	健康检查连接超时时间	string	No

动态worker 进程数调整

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

配置项	说明	字段类型	默认值	备注
worker-processes	Worker 进程数 (允许设置的值 1 - 512)	String	默认是auto根据cpu核数自动生成的进程数

配置项

说明

字段

类型

默认值

备注

worker-processes

Worker 进程数 (允许设置的值 1 - 512)

String

默认是auto根据cpu核数自动生成的进程数

分片处理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，外部客户端可以直接访问。

整体架构

场景图：