OpenNJet KIC(K
ubernetes Ingress Controller)基于OpenNJet proxy的动态特性、高性能实现。弥补nginx 在云原生场景中应用的不足。提供了丰富的流量管理能力，如动态location、host/path路由、负载均衡、动态upstream、金丝雀发布、TLS Termination/SNI等。

本版本主要特性：

架构图如下：

OpenNJet KIC采用动态API方式实现基本路由/TLS的变化的更改，当Ingress资源变化时，而不需要reload OpenNJet 配置文件。我们采用单server多location的方式实现HTTP host头匹配，和path匹配。如下图所示：

当Ingress资源中host或者path变化时，通过动态location API来更新OpenNJet的配置信息，而不是reload OpenNJet配置文件。

当Ingress资源中关联的service发生改变或者service关联的pod进行了动态扩缩容时，我们通过动态Upstream API(目前基于lua实现)来更新OpenNJet的配置信息，而不是reload OpenNJet配置文件。资源变更应用如下表所述：

资源变化	OpenNJet配置信息变化方式
Ingress资源变化	删除新建	Ingress	动态location API 动态Upstream API
内容	host	动态location API
path	动态location API
service	动态Upstream API
pod动态扩缩容		endpoint	动态Upstream API

VirtualServer是一个自定义资源，在OpenNJet KIC中用来替代Ingress资源，是一个替代方案。VirtualServer除了具备Ingress的能力，还提供了更丰富的功能，比如 advanced content-based routing等，可以灵活的配置匹配策略实现灰度发布。

VS在处理一个路由时，高级路由匹配由spec中的matches定义。conditions在匹配中定义条件，支持
header、
cookie、
argument、
variable。

以下是一个VS的示例：

apiVersion: k8s.njet.org/v1
kind: VirtualServer
metadata:
  name: cafe
  namespace: default
spec:
  host: cafe.example.com.vs
  routes:
  - action:
      pass: details
    matches:
    - action:
        pass: tea-post
      conditions:
      - value: POST
        variable: $request_method
    path: ~* .html$
  - action:
      pass: ratings
    matches:
    - action:
        pass: productpage
      conditions:
      - cookie: version
        value: v2
      - value: GET
        variable: $request_method
    path: /productpage
  upstreams:
  - name: ratings
    port: 9080
    service: ratings
  - name: productpage
    port: 9080
    service: productpage
  - name: tea-post
    port: 80
    service: tea-post-svc
  - name: details
    port: 9080
    service: details

上图VS中，配置了两个路由：

实现方式与Ingress基本一致。

在Upstream配置更新方面，OpenNJet KIC使用lua实现Upstream动态配置，来应对云原生场景。在云原生场景中，upstrem变更是常态，比如集群部署了新的服务、某服务进行了动态扩缩容、Pod被重新调度等，这都导致upstream相关配置的变更。

OpenNJet KIC配置当中会生成一个默认的被称为”upstream_balancer”的upstream，此upstream会处理所有路由。当真实流量到来时，会交由内部lua上下文处理。”upstream_balancer”配置如下：

 upstream upstream_balancer {
        ### Attention!!!
        #
        # We no longer create "upstream" section for every backend.
        # Backends are handled dynamically using Lua.
        #
        ###

        server 0.0.0.1; # placeholder

        balancer_by_lua_block {
            balancer.balance()
        }

        keepalive 320;
        keepalive_time 1h;
        keepalive_timeout  120s;
        keepalive_requests 10000;
    }

首先，OpenNJet KIC会通过动态upstream API接口创建所有upstream信息。

其次，每个路由(location)都会关联实际处理自己的upstream名称。

最后，实际处理流量的upstream名称会被传递到lua上下文，最终保证流量被正确处理。

路由与upstream关联如下所示：

Upstream 可以设置对应的负载均衡策略，目前支持默认的 round_robin，及一致性hash。round_robin 使用轮询的方式获取peer。一致性 hash 根据配置的hash key 值来进行负载，相同的key值，将始终访问同一个后端peer。常用的hash key有：

hash key	描述
$arg_{VAR}	根据url 传递的参数 VAR 做一致性hash
$http_{NAME}	根据HEADER 传递的参数 NAME 做一致性hash
$cookie_{NAME}	根据 Cookie 传递的参数 NAME 做一致性hash
$remote_addr	根据客户端的IP做一致性hash

OpenNJet 可使用的内部变量与 Nginx 一致，可以参考文档：https://nginx.org/en/docs/varindex.html

Ingress与VirtualServer CR都支持Upstream 负载均衡策略配置。

下面给出一个VS配置Upstream 负载均衡的一个例子：

上面的例子通过lb-method: “chash $arg_uu” 进行显式的声明Upstream 负载均衡算法为chash且以请求携带的参数uu为hash key。

OpenNJet KIC提供了Upstream 主动健康检查的能力，确保所有请求都能被健康的上游后端处理，提高用户体验度。

通过Ingress、VirtualServer CR配置Upstream 的主动健康检查， OpenNJet KIC 会通过单独的一个 priviliege agent 进程对upstream 的各peer进行检查， 如果 peer 检查失败，并且失败次数达到预先配置的阈值，健康检查程序会将对应的peer 从 upstream peer 列表中移除。被移除的peer, 在之后的检查中如果为健康状态，并达到配置的阈值，将会触发重新上线的操作。

下图为健康检查架构图：

下面给出一个VS配置主动健康检查的一个例子：

OpenNJet KIC处理TLS流量由内部端口443负责，支持TLS Termination/SNI功能，根据主机名在同一端口上进行多路复用。

Ingress、VirtualServer CR都支持 TLS Termination/SNI配置，且OpenNJet KIC支持配置动态更新，不进行reload，这一能力得益于OpenNJet提供的动态map能力。host与证书的对应关系通过动态map HTTP 接口进行更新。

下面给出一个VS配置TLS的一个例子：

上面的例子配置期望把
vstest.example.com与
a.test.com对应的证书进行关联。

为服务器托管网了满足用户对业务的监控，OpenNJet KIC目前提供了VTS(virtual host traffic status)指标采集，OpenNJet使用定制的 vts 模块，采集upstream的相关指标。

OpenNJet KIC容器中的OpenNJet 进程通过vts 模块记录Upstream 的相关指标信息，并且OpenNJet 提供HTTP 接口获取Prometheus 格式的指标信息。

KIC 服务中通过注解Annotations 声明Prometheus 指标的采集端口及路径。配置如下：

apiVersion: v1
kind: Service
metadata:
  annotations:
    prometheus.io/port: "12001"
    prometheus.io/scheme: http
    prometheus.io/scrape: "true"
    prometheus.io/path: "/stats"
  name: njet-ingress
  namespace: njet-ingress
spec:
  type: NodePort
  ports:
  - port: 80
    targetPort: 80
    protocol: TCP
    name: http
  - port: 443
    targetPort: 443
    protocol: TCP
    name: https
  selector:
    app: njet-ingress