C# 开源一个基于 yarp 的 API 网关 Demo,支持绑定 Kubernetes Service

时间:2024-03-12 09:26:14

关于 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 用。仓库代码目标也是主要解决微软内部需求,很多 API 对外部开发者也不是很友好,实际开发起来有一定难度,当然可定制性也比较多,主要从 ASP.NET Core 的中间件下手,做各方面的扩展。

另外这个项目不是成熟项目,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 端口,访问到。

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

账号密码分别是 adminadmin123

登录后,凭证会存储到你的浏览器中,有效期为 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:"" 即可。