关于云计算:KubeSphere-网关的设计与实现解读

作者：泓舟子，KubeSphere 后端研发工程师，云原生爱好者，现专一于云原生微服务方向。

KubeSphere 中为什么须要网关？

如果须要将 K8s 集群内的服务裸露到内部拜访有那些形式呢？能够通过将 Service 设置成 NodePort 形式裸露进来或者通过 Ingress 形式。另外应用 Ingress 形式能够实现将申请散发到一个或多个 Service，能够同一个 IP 地址下裸露多个服务等劣势。

然而对于 Ingress 形式而言，在 K8s 中只是内置了 Ingress CRD（能够创立 Ingress 资源），没有内置 Ingress Controller，必须部署了 Ingress Controller 能力为 Ingress 资源提供内部拜访集群外部服务的能力。而 KubeSphere 中的网关就是 Ingress Controller。

网关的设计

KubeSphere v3.2 对网关进行了重构，在保留了原有网关性能的根底上减少了以下几点新性能：

1. 启用集群和我的项目级别的网关：能够依据业务上的需要灵便抉择不同粒度的网关。
2. 增减网关正本数：灵便调整正本数达到更高的可用性。
3. 灵便配置 Ingress Controller 配置选项。
4. 可指定网关利用负载装置的地位：可抉择将网关利用负载装置的地位指定某固定命名空间或别离让其位于各自我的项目命名空间下。联合 KubeSphere 中的权限治理，若让资源位于各个我的项目命名空间下，领有该我的项目权限的用户也能查看到网关资源。
5. 网关日志：集中查问网关日志，将散布在各个正本的网关日志集中起来查问。
6. 网关监控指标：监控网关中的一些指标，包含申请总量 / 成功率 / 提早 等指标。

网关的实现

目前 K8s 反对和保护 AWS、GCE 和 Nginx Ingress 控制器，KubeSphere 应用 Ingress Nginx Controller 作为默认的网关实现，没有做任何代码批改。

各个性能点的实现思路

• 集群和我的项目级别的网关：这个通过传入参数笼罩默认的 Helm Chart Values 来实现并在代码逻辑里管制，如果启用了集群网关就不能启用我的项目网关了；若启用了我的项目网关又启用了集群网关，那么通过两个网关入口都能够拜访，只是这样会有两个 Ingress Controller 同时 Watch 雷同的 Ingress 对象。
• 增减网关正本数 & 配置 Ingress Controller 配置选项：这个通过传入参数笼罩默认的 Helm Chart Values 来实现，实现过程用到的 Helm Operator 将在前面重点介绍。
• 可指定网关利用负载装置的地位：可抉择将网关利用负载装置的地位指定某固定命名空间或别离让其位于各自我的项目命名空间下。这个在代码逻辑中管制，并做成了配置项，默认将所有资源装置在 kubesphere-controls-system 下。
• 网关日志：应用到了 KubeSphere 中日志组件，日志组件会采集日志数据而后存储在 Elasticsearch 中，网关在查问日志过程就依据参数在 Elasticsearch 中查问日志。
• 网关监控指标：应用到了 KubeSphere 中监控组件，KubeSphere 外部配置了 Prometheus 相干的参数采集 Ingress 相干指标，查问监控信息过程就依据监控组件中的 API 查问相干数据。

上面重点介绍设计实现过程形象出的 CRD 和如何奇妙地用 Helm Operator 集成。

形象出 Gateway CRD 做适配

在设计上形象了一个 Gateway CRD 来适配不同的 Ingress Controller，Gateway CRD 中蕴含设置 Ingress Controller 所需的公共属性。KubeSphere API 和 UI 只与 Gateway CRD 交互。

# Gateway sample
apiVersion: gateway.kubesphere.io/v1alpha1
kind: Gateway
metadata:
  name: kubesphere-router-proj1
  namespace: kubesphere-controls-system # all Gateway workload will be created in the kubesphere-controls-system namespace by default. However, it's configurable in kubesphere-config when calling KubeSphere API. 
spec:
  controller:
  # controlpanel replicas. For ingress Controler that has controlpanel and workers. *Reserved field. Changing on UI isn't supported yet. 
  replicas: 1
  # annotations of the controlpanel deployment. *Reserved field. Changing on UI isn't supported yet. 
  annotations: {}
  
  # Watching scope,
  # enabled =true, watching for the project only. The user needs to specify the watching namespace.
  # enabled =false, Global gateway, watching for all namespaces.
  scope:
    enabled: false
    namespace: ""  # defaults to .Release.Namespace

  # gateway configurations. only key-value pair supported currently.
  config:
    max-bucket: 1m

  # worker workload deployment configuration
  deployment:
    annotations: 
    "servicemesh.kubesphere.io/enabled": "false"
    replicas: 1

  # 
  service:
    # Cloud LoadBalancer configurations for service
    annotations: 
      "service.beta.kubernetes.io/qingcloud-load-balancer-eip-ids": "test-ip-id"
    # Service Type, only LoadBalancer and NodePort are supported
    type: LoadBalancer

集成 Nginx Ingress Controller

KubeSphere 应用 Nginx Ingress Controller 作为默认的网关实现。为了简化部署步骤，咱们集成了 Helm-operator-plugins 作为 Helm Operator。

在 Helm Operator 中次要有以下关键点：

依据 watch.yaml 中配置的监听指定 CRD 下的 CR 来创立或更新 Chart 资源。其中能够依据 CR spec 中的值笼罩默认 Helm Chart 中的值，这是由 Helm Operator 中的机制决定的，详见官网阐明。

如下的含意是须要 Watch gateway.kubesphere.io/v1alpha1 的 Nginx CR，如果有变动就触发 Reconcile，依据 chart 中配置的地址创立或更新对应的资源。

- group: gateway.kubesphere.io
  version: v1alpha1
  kind: Nginx
  chart: /var/helm-charts/ingress-nginx

在 KubeSphere 中的应用：

watchs.yaml 中就做了如下配置：

- group: gateway.kubesphere.io
  version: v1alpha1
  kind: Nginx
  chart: /var/helm-charts/ingress-nginx
- group: gateway.kubesphere.io
  version: v1alpha1
  kind: Gateway
  chart: /var/helm-charts/gateway

其中对 chart 而言：

• Nginx 是用的官网的 Helm Chart，在打包 ks-controller-manager 时下载的官网 Helm Chart。详见：https://github.com/kubesphere…
• Gateway 是在 KubeSphere 中定制的 Helm Chart，外面次要就操作了 Nginx CR 资源。详见：https://github.com/kubesphere…

整体而言：

Helm Operator Watch 了 Gateway 和 Nginx 2 个 CRD 的资源，以后端发动创立或更新网关时是对 Gateway CR 发动创立或更新操作：

1. 发动申请创立或更新 Gateway CR；
2. 依据 watchs.yaml 配置的 Gateway，Helm Operator 监听到有 Gateway CR 资源变动，将创立或更新 Nginx CR；
3. 依据 watchs.yaml 配置的 Nginx，Helm Operator 监听到 Nginx CR 资源变动后就依据 Nginx CR 中的 spec 中的值来笼罩默认 Helm Chart 中的值来创立或更新 Nginx Ingress Contoller。

配置项的设计

为了不便更改网关的一些参数设计了如下配置项：

gateway:
  watchesPath: /var/helm-charts/watches.yaml
  repository: kubesphere/nginx-ingress-controller
  tag: v1.1.0
  namespace: kubesphere-controls-system

• watchesPath：指定 Helm Operator Watch 的配置文件，如果须要禁用 Helm Operator 就能够删掉这个配置项。
• repository：指定 nginx-ingress-controller 的仓库。
• tag：指定 nginx-ingress-controller 的 tag。
• namespace：指定网关利用负载装置的地位位于指定的命名空间下，若删掉这个配置项就会装置在各个我的项目命名空间下。

应用过程注意事项

1. 如果启用了 servicemesh，在原有的 Ingress 须要加上额定的注解 nginx.ingress.kubernetes.io/upstream-vhost: [service-name].[service-namespace].svc.cluster.local 流量拓扑 / 链路追踪能够失常工作，不然入口流量处会有异样。
2. 批改网关相干属性，比方：正本数、Nginx 配置项等，不能间接在相干的 deploy/configmap 等利用负载外面批改，须要在网关设置中批改（批改的是 Gateway CR）。因为应用的是 Helm Operator 来管理控制网关相干资源的状态，所有值都会以 Gateway CR 中的配置为准，改了网关相干利用负载中的值最终都会被 Helm Operator 还原掉。

参考：

1. https://kubernetes.io/docs/co…
2. https://github.com/kubesphere…
3. https://github.com/kubesphere…
4. https://sdk.operatorframework…

本文由博客一文多发平台 OpenWrite 公布！