NGINX 向云原生演进，All in OpenNJet 概述

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

本版本主要特性：

支持Ingress API、支持path/host路由
支持自定义资源VirtualServer，支持path/host、高级(header、请求方法等)路由
支持动态Upstream
支持Upstream 负载均衡, 支持round-robin 及 consitent hash 算法
支持Upstream 主动健康检查
支持 TLS SNI
支持Prometheus 指标采集

架构图如下：

新特性概览

Ingress API

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 CR 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中，配置了两个路由：

path为\.html$ 的正则匹配，匹配以.html结尾的请求，实现高级路由(请求方法为POST的请求被路由到 tea-post upstream，其他请求被路由到 details upstream(默认处理))
path为/productpage的前缀匹配，实现高级路由(请求方法为GET且cookie 为version=v2的请求被路由到 productpage upstream，其他请求被路由到 ratings upstream(默认处理))

实现方式与Ingress基本一致。

动态Upstream

在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;
    }

lua上下文怎么区分不同流量该由谁处理呢？

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

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

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

路由与upstream关联如下所示：

Upstream的更新流程

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。

Upstream 主动健康检查

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

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

下图为健康检查架构图：

更新 Upstream 数据时，生成一份 "raw hc backends" 的副本，定时器中的健康检查使用此副本中的数据进行。当健康检查结果需要触发peers 变更时，更新共享内存中的 upstream backends。
目前健康检查模块的定时器时间间隔是 5秒。策略中的健康检查间隔需>=5s 。

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

TLS Termination/SNI

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对应的证书进行关联。

Prometheus 指标采集

为了满足用户对业务的监控，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

参考链接

OpenNJet 最早是基于 NGINX1.19 基础 fork 并独立演进，具有高性能、稳定、易扩展的特点，同时也解决了 NGINX 长期存在的难于动态配置、管理功能影响业务等问题。

KIC用户手册官网

OpenNJet KIC v1.0发布！K8s Ingress Controller