关于 Neting

刚开始的时候是打算使用微软官方的 Yarp 库，实现一个 API 网关，后面发现坑比较多，弄起来比较麻烦，就放弃了。目前写完了查看 Kubernetes Service 信息、创建 Route 和 Cluster 和绑定 Kubernetes Service。简单来说，就是完成了基础部分，配置路由和后端服务绑定，如果想实现动态路由和直接转发等功能，只需要按照官方的文档，增加中间件即可。

原本打算使用 .NET 6 的 AOT(一共40MB) ，但是打包运行会容易出现一些依赖问题和环境问题，因此放弃了，依然采用 Runtime + 应用 的方式部署，进行总共 120 MB 左右。

后端项目地址：https://github.com/whuanle/neting

前端项目地址：https://github.com/whuanle/neting-web

体验地址：http://neting.whuanle.cn:30080/

大概界面是这样的：

Route：即来源入口，支持 http/https 和 gRPC，Route 是设计进入集群前的访问者流量如何绑定后端服务，可以配置访问者 URL 的区配规则；

Cluster：后端服务，一个 Cluster 可以绑定多个类型的后端服务，主要实现一个域名不同的后缀访问多个微服务，或者同一个实例负载均衡等；

Service：查看 Kubernetes Service 的一些网络信息；

Neting 目前只实现了简单的配置，仅供读者了解 Yarp 以及入门 Kubernetes API 开发、监控集群资源等。读者也可以从中了解 etcd 的使用，如何设计一个 Kubernetes Controller 应用。

基础功能已经做了，读者可根据需求，自行增加中间件即可。

下面介绍如何部署 Neting 项目，需要读者提前创建好集群。

谈谈对 Yarp 的看法。

首先，Yarp 的仓库地址是 https://github.com/microsoft/reverse-proxy

仓库在微软的官方账号下，从了解到的信息来看，Yarp 的出现主要是解决 Microsoft 内部的需求，也有人说是为了给 Azure 用。简而言之，好像看起来让人感觉是不是真的 “开源”。当然肯定是开源的，MIT License 开源协议，但是让人隐约感觉微软的把控力度强，这个项目带着一些 “私心” 去做的。

另外这个项目不是成熟项目，Yarp 只是一个库，它不是一个完整应用，很多地方还没有确定其稳定性，也没有性能测试报告等，也没有基于此的成熟的应用出现。API 上和其他方面，开发难度还是比较复杂的，包括文档很多地方也没有说清楚。

部署 etcd

Neting 的主要设计，是 etcd 作为数据存储后端，当用户创建反向代理或者其他类型的规则时，etcd Watch 自动通知 Neing 实例，刷新这些配置到内存中，交由 Yarp 使用(当然也可以不放到内存，在需要使用的时候，自动从 etcd 中取)。

Neting 使用 etcd 作为存储后端，etcd 支持集群，但是这里为了方便使用单个 etcd 实例。因为 etcd 是有状态应用，因此需要绑定一个存储卷。另外 etcd 也需要创建一个 service，以便在集群中访问实例。

etcd 集群(这里是单实例集群) ->  Service(名称为neting-svc)

     ↓

PersistentVolumeClaim

     ↓

PersistentVolume

你可以在项目的 yaml 下面，找到 etcd.yaml 和 etcds.yaml 、neting-etcd.yaml 三个文件，查看如何部署 etcd 集群。

为了方便，创建的存储卷是本地卷，不能跨节点共享数据。当然你也可以通过修改 neting-etcd.yaml 文件，使用其他类型的卷。

  hostPath:

      # 宿主上目录位置，需要先提前创建

    path: /data/etcd

      # 此字段为可选

    type: Directory

将 neting-etcd.yaml 文件上传到集群，然后创建 etcd 实例。

root@master:~/neting# kubectl apply -f neting-etcd.yaml

service/neting-etcd created

statefulset.apps/neting-etcd created

persistentvolume/neting-etcd created

创建 etcd 集群的时候，会创建多个相关的资源。

root@master:~/neting# kubectl get statefulset

NAME          READY   AGE

neting-etcd   1/1     36s

root@master:~/neting# kubectl get pv

NAME          CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS

neting-etcd   1Gi        RWO            Recycle          Available

root@master:~/neting# kubectl get svc

NAME           TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)                               AGE

neting-etcd    ClusterIP   10.96.206.255    <none>        2379/TCP,2380/TCP                     54s

其实还包括 PersistentVolumeClaim，可以执行 kubectl get pvc 查看。

创建 secret

secret 的主要作用是给 Neting 提供用户登录的账号密码，即前面提到的 admin/admin123，这个配置写在了 secret.yaml。

secret.yaml 的全部内容如下：

apiVersion: v1

kind: Secret

metadata:

  name: neting-basic-auth

type: Opaque

stringData:

# Neting 的登录账号密码

  NETING_USER: admin

  NETING_PASSWORD: admin123

  NETING_TOKENKEY: dzbfhisj@3411DDFF5%$%^&&

这个配置很简单，其中 NETING_TOKENKEY 表示签名 token 的密钥，Neting 使用 Jwt Token 做用户凭证，在颁发凭证给用户时，需要加密用户信息签名。

上传 secret.yaml 到集群中，然后创建它。Secret 中的信息最终会生成 base64，Kubernetes 的 etcd 中(注，不是前面自行创建的 etcd)。secret 中的信息，最终会以环境变量的形式出现在 Neting Pod 中。

root@master:~/neting# kubectl apply -f secret.yaml

secret/neting-basic-auth created

root@master:~/neting# kubectl get secret

NAME                      TYPE                                  DATA   AGE

neting-basic-auth         Opaque                                3      10s

...

data:

  NETING_PASSWORD: YWRtaW4xMjM=

  NETING_TOKENKEY: ZHpiZmhpc2pAMzQxMURERkY1JSQlXiYm

  NETING_USER: YWRtaW4=

kind: Secret

部署 Neting

Neting 的依赖关系如下：

Neting -> 启动(Secret)

 ↓

Service - etcd

 ↓

etcd 实例

Neting 是由 ASP.NET Core API + React/Ant Design 编写的 Web 项目，为了结构简单，Neting 在 wwwroot 目录托管了前端静态文件，以便在同一个端口下访问，并且减少跨域、绑定 IP 等事情。

Neting 已被上传到阿里云镜像仓库中，docker pull 地址 ： registry.cn-hangzhou.aliyuncs.com/whuanle/neting:review1.0

Neting 是需要在 Pod 中连接到 Kubernetes API Server 的，因此需要配置 ServiceAccount 或者直接使用 Kubeconfig。遗憾的是，C# 的 KubernetesClient 对 ServiceAccount 支持并不好，因此只能使用 Kubeconfig，当然直接使用 Kubeconfig 可能会带来一些安全问题，好在这是 Demo，Neting 只会使用 获取 Servive 和 Endpoint 部分的信息，不会对集群进行修改、删除等操作，因此如果需要更高安全级别的操作，可尝试自行解决 Kubenetes - C# 的 ServiceAccount 问题。

Kubernetes 和 etcd 的 C# SDK 体验不佳，读者搞云原生中间件的时候，还是用 Go 搞比较好，C# 适合写业务。

将你的 Kubernetes 管理配置文件复制到 /root/.kube/config 中。注意，这一步一定要在会被调度 Pod 运行的节点上处理，因为这个配置文件不能跨节点使用。

cp -f /etc/kubernetes/admin.conf /root/.kube/config

然后启动 Neting：

kubectl apply -f neting.yaml

接着，为 Neting 创建 Service，以便在外网访问。

root@master:~/neting# kubectl apply -f neting-svc.yaml

service/neting created

root@master:~/neting# kubectl get svc -o wide

neting         NodePort    10.102.240.255   <none>        80:30080/TCP                          11s   app=neting

neting-etcd    ClusterIP   10.96.206.255    <none>        2379/TCP,2380/TCP                     31m   app=neting-etcd

部署完成后，可以通过节点的 IP 和 30080 端口，访问到。

接着随便点击一个菜单，便会要求登录。

账号密码分别是 admin、admin123。

登录后，凭证会存储到你的浏览器中，有效期为 7 天。

点击 Service 可以看到集群中的 Service 的信息。

使用

接着我们来创建 Yarp 反向代理 配置。

Yarp 的反向代理对象绑定分为两个部分，Route 和 Cluster。

Cluster 即是服务后端实例，如你有一个应用部署了 N 个实例，每个实例都有一个 IP，那么 Cluster 需要记录你这些实例的 IP，以便在访问时，通过负载均衡算法选择其中一个访问。YARP 带有内置的负载平衡算法，但也为任何自定义负载平衡方法提供了可扩展性。这里就不展开来讲。

读者可以参考 https://microsoft.github.io/reverse-proxy/articles/load-balancing.html

我的 Kubernetes 中，有测试 Ingress 时留下来的两个应用， web1 和 web2，这里可以使用一下。

接着，笔者到域名管理处，解析了一个域名绑定应用。

接着创建 Route。

是可以基于 Yarp 项目设计一个 API 网关，或者代替 Kubernetes 的 Ingress ，实现流量入口，API 网关 + 负载均衡。

说不定你还可以编写类似 Dapr 的服务网格功能，使用边车模式为集群中的应用提供非侵入式流量代理服务。

介绍一下项目

Neting 就是后端项目，NetingCrdBuilder 跟当前项目无关，是笔者本来打算做类似 Dapr，创建自定义资源以及以及 Kubernetes Operater 用的，不想写了，就不写了。Yarp.ReverseProxy 是 Yarp 基础库，为了发表调试和查看源码，不通过 Nuget 引用，而是抽取源码，通过代码直接引用。

后端项目大部分都写了注释，这里就不再多说了。

如果想在本地测试和开发，可以先把前后端项目拉下来。

本地开发，你需要在后端项目的 appsettings.json 或 appsettings.Development.json 文件修改配置。

其中 admin.conf 是 Kubernetes API Server 连接的验证配置文件，通过配置文件与 Kuberntes 连接的时候才能通过授权访问资源。代码在 KubernetesExtensions 中，你也可以通过 Kubernetes proxy 等方式访问 Kubernetes 进行开发。

然后需要在前端的 Constants.js 文件中，配置你本地的后端地址。

export const Options = {

    // host: "http://127.0.0.1:80"  // 开发配置

    host: ""                        // 部署配置

}

如果前后端都在同一个端口下，则 host:"" 即可。