OpenNJet KIC v1.0发布！K8s Ingress Controller

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配置文件。资源变更应用如下表所述：

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

1. path为\.html$ 的正则匹配，匹配以.html结尾的请求，实现高级路由(请求方法为POST的请求被路由到
   tea-post upstream，其他请求被路由到
   details upstream(默认处理))

2. 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有：

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用户手册
 
官网