乐趣区

关于网关:为什么-Higress-是-Knative-入口网关的最佳实践

jiezi

在传统的利用开发中，通常须要治理底层的基础设施、服务器与网络配置等方面的工作。然而在云原生 Serverless 化的浪潮下，这些基础设施的细节被形象和自动化，开发者无需关注服务器等配置、扩大、监控和保护等工作，能够更专一于应用程序的业务逻辑和性能开发。Serverless 架构的价值在于提供高效、弹性、无服务器治理、服务按需付费、疾速部署与迭代、以及高可扩展性等劣势，升高开发和运维的复杂性，进步开发效率和应用程序的品质。

Knative Serving 是一款基于 K8s 的 Serverless 开源平台，用于构建和治理现代化、可拓展、流量驱动、无服务器的应用程序。Knative Serving 提供了诸多个性来反对用户部署 Serverless 服务，如基于 HTTP 流量触发 pod 的主动扩缩容、服务版本订正、主动流量治理、故障复原等。

$$
起源：https://knative.dev/docs/serving/architecture/
$$

Knative 整体架构如下层所示，Controller 和 DomainMapping 等组件等负责管理 KnativeCRD 资源的生命周期，其弹性能力由外围的 Activator、Autoscaler 和 Queue-Proxy 等组件提供。网络和路由能力依赖各类 Ingress Gateway 提供。

本文重点关注 Knative 网络层能力的实现。Knative 网络层能力须要依赖 Knative Ingress CRD 与其余网络层组件实现。目前，Knative 官网提供了基于 Contour、Istio 和 Kourier 等作为其网络层组件，提供无限的网络能力，如根本的路由、认证鉴权和 TLS 等，能够满足根本的路由和平安要求。Higress 是平安、流量和微服务三合一的云原生网关，应用 Higress 作为 Knative 服务的流量入口可能取得更强的流量治理、平安防护、可观测和可扩大能力。

Knative 网络层工作原理

接下来咱们以 Net-Istio 为例，介绍 Knative Serving 通过网络层实现服务对外公布的过程。Net-istio 网络层将数据面与管制面进行拆散。数据面采纳 Envoy，负责解决网络流量。管制面负责管理与配置数据面，反对对网关的动静配置和治理。

当有 KService 被部署的时候，Knative Serving Controller 将解析 Kservice 中的路由项并生成对应的 KIngress 资源。KIngress 是 Knative 的 CRD，其资源中蕴含了服务对外披露所需的所有信息，示例如下：

apiVersion: networking.internal.knative.dev/v1alpha1
kind: Ingress
metadata:
  annotations:
    networking.knative.dev/ingress.class: istio.ingress.networking.knative.dev #指定 istio 作为网络层
  name: hello
  namespace: default
spec:
  httpOption: Enable #用于定义是否开启 HTTPS 重定向
  rules:
  - hosts:
    - hello.default.example.com
    http:
      paths:
      - splits: #Split 定义了流量按百分比调配调配到不同的服务订正上。- appendHeaders:
            Knative-Serving-Namespace: default
            Knative-Serving-Revision: hello-00001
          percent: 100
          serviceName: hello-00001
          serviceNamespace: default
          servicePort: 80
    visibility: ExternalIP  #定义服务是仅集群内可拜访还是对外披露。tls:  #指定通过 HTTPS 协定披露 Kservice 时应用的证书及密钥。- hosts:
    - hello.default.example.com
    secretName: route-ecbe0df2-101a-4aa4-8cf9-f2e98773fcdf
    secretNamespace: default

以 Istio 作为网络层为例，Net-Istio 组件监听集群中的 Kingress 资源。每次 Kingress 被创立、删除或者批改的时候，Net-Istio 会同步解析 Kingress 资源，将 KIngress 的路由配置转换为 Istio 的 Virtual Service 和 Gateway 等资源。Istio 监听 VirtualService，并通过 xDS 下发路由配置给数据面 Envoy，从而实现路由配置的传递。

Envoy 接管到这个路由指标集群的 EDS 数据后，依据 Service 关联到的 Endpoint 的 IP 将申请转发给 Activator Pod 或者 Revision Pod。处于冷启动状态或者缩容状态时，Knative Controller 会将 Service 关联到的 Endpoint 设置为 Activator 的 Pod IP；处于稳固态时，Service 关联的 Endpoint 将被设置为用户部署的 Revision Pod IP。

理顺 Knative 网络层的工作原理后，咱们可发现在 Knative 网络层中管制面理论承当的性能如下：

  1. 监听并获取 Knative Service 产生的 KIngress 资源。
  2. 将 KIngress 资源映射为数据面 Envoy 配置信息。
  3. 将配置信息披露给其治理的 Envoys。

不同的 Knative 网络层管制面通过本身机制实现路由配置的转化和传递，实现根本的路由能力。但在更简单的利用场景下，现有网络层可能无奈齐全满足诸如平安、认证、可观测、细粒度流量治理与可扩大等方面的需要。一个解决的思路是在 Knative 网络层之上持续集成诸如平安网关、流量网关与可观测平台等组件，但多层网关的设计无疑会占用更多运行资源、减少运维老本。

Higress 适配 Knative Serving 计划

为了拓展 Knative 对各种场景的适应能力，叠加多层网关显然不是最好的抉择。Higress 云原生网关作为集平安、流量、微服务三位于一体的下一代云上网关，应用 Higress 作为 Knative 服务的流量入口可能取得更强的流量治理、平安防护、可观测与可拓展能力，在稳定性、安全性上更有保障。目前，Higress 能够通过两种形式适配 Knative Serving，并在管制面能力进行了加强。

计划一：Higress+KIngress

本计划适配 Knative Serving 的工作原理与其余 Knative 网络层相似，蕴含 KIngress 的监听与更新、路由配置的转换与数据面配置推送等过程。与此同时，Higress 兼容了 Knative Serving 网络层的所有个性，如不同服务订正间的流量划分、TLS、超时、重试、流量打标、主动端点发现等，确保 Knative 服务可能轻松应用 Higress 作为其流量入口。

值得一提的是，在此计划中，Higress 脱离了对其余自定义资源的依赖，只依赖于 Knative Serving 治理的 KIngress 资源与 K8s 集群通用资源如 endpoints，secrets 等，以一种更加“原生”的形式适配了 Knative。

得益于与微服务技术栈的良好集成和 WASM 扩大机制，Higress 可能为 Knative 服务提供诸如认证鉴权、限流、Waf 防护与可观测等更弱小的能力。Serverless 服务开发者将无需关注根本能力的实现，只需关注于开发本人的业务逻辑。Higress 推出插件市场，在满足根本的平安、限流、认证鉴权等需要的同时，凋谢了自定义插件的接口，帮忙用户更好的适配本身的 Serverless 利用。

计划二：Higress+IstioCRD

Higress 能够通过本人对 IstioCRD 的兼容能力来代替 Istio 成为 Knative 网关的管制面。具体计划如下图所示。不难看出，本计划是基于 Higress 对 IstioCRD 的兼容能力，通过 net-istio-controller 实现路由配置向 IstioCRD 的转化，Higress Controller 解析 IstioCRD 资源并进行配置的数据面下发，从而实现路由配置的传递。

计划比拟

Higress+Kingress 与 Higress+IstioCRD 都能够实现 Knative 网络层的能力，并兼容 Higress 在流量治理、平安防护、可观测和可扩大等方面的大部分能力。Istio 是个优良的服务网格解决方案，但如果在利用场景中不须要服务网格，IstioCRD 反而会给集群带来额定的复杂度与资源耗费。而 Higress+KIngress 计划脱离了对其余自定义资源的依赖，以一种更加“原生”的形式适配了 Knative 且能力不打折。

Higress 对接 Knative 服务实际

前提条件

  1. 已装置 kubectl[1]、Helm[2]、Knative CLI (kn)[3]。
  2. 已有 K8s 集群，版本在 Kubernetes v1.24 或以上。为演示不便，本文在本地 K8s 集群上进行实际。
  3. 装置 Knative CRD 与 Knative Serving 组件，详情可参考 Knative 装置指南 [4]。
  4. 装置 Higress[5]。

注：Higress Controller 部署时会进行 Knative CRD 查看，装置 Higress 前请确认 KnativeCRD 曾经装置。

计划一：Higress+KIngress

配置 Knative 与 Higress 的适配项

  1. 配置 Knative 应用 Higress 作为 Ingress：
kubectl patch configmap/config-network \
  --namespace knative-serving \
    --type merge \
      --patch '{"data":{"ingress-class":"higress"}}'
  1. Knative 默认的路由策略是围绕域名开展的，须要设置 Knative 域名：
kubectl edit configmap config-domain -n knative-serving

通过编辑 configmap 中的 data 项来批改默认域名。本实际将默认域名批改为 http://example.com。该批改失效后，所有的 Knative 服务与路由将自动更新域名。

apiVersion: v1
data:
  example.com: ""
kind: ConfigMap
  1. 确认 Higress 对 Knative 资源的 RBAC 权限：
kubectl get clusterrole higress-controller-higress-system -o yaml

RBAC 权限列表中应有下列字段，如没有请通过 kubectl edit 命令手动增加：

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
rule:
 ...
- apiGroups:
  - networking.internal.knative.dev
  resources:
  - ingresses
  verbs:
  - get
  - watch
  - list
- apiGroups:
  - networking.internal.knative.dev
  resources:
  - ingresses/status
  verbs:
  - get
  - patch
  - update

实现上述配置后，即可应用 higress 无缝对接 Knative 服务。

Higress 兼容 Knative 网络层个性性能验证

  1. 部署 Knative 服务 
kn service create hello \
--image ghcr.io/knative/helloworld-go:latest \
--port 8080 \
--env TARGET=World
#Expected Output
Service hello created to latest revision 'hello-00001' is available at URL: 
http://hello.default.${LOADBALANCER_IP}.example.com
#其中 ${LOADBALANCER_IP} 即为 Higress Gateway IP, 本地 k8s 集群部署时为空。
  1. 验证 Knative AutoScaling

向 Hello 服务发送申请：

# 本地部署时，LOADBALANCER_IP 为 127.0.0.1，此处通过 No DNS 的形式模仿
curl -H "host: hello.default.example.com" http://${LOADBALANCER_IP}
#Expected Output
Hello World!

通过下列命令察看 AutoScaling 过程：

kubectl get pod -l serving.knative.dev/service=hello -w

能够察看到申请转发到 Hello Service 上时触发了扩容过程，当一段时间没有申请时，Pod 数量主动缩容到 0：

NAME                                      READY   STATUS              RESTARTS   AGE
hello-00001-deployment-689c99c59b-6f5fw   0/2     Pending             0          0s
hello-00001-deployment-689c99c59b-6f5fw   0/2     ContainerCreating   0          0s
hello-00001-deployment-689c99c59b-6f5fw   1/2     Running             0          1s
hello-00001-deployment-689c99c59b-6f5fw   2/2     Running             0          1s
hello-00001-deployment-689c99c59b-6f5fw   2/2     Terminating         0          62s
hello-00001-deployment-689c99c59b-6f5fw   1/2     Terminating         0          91s
hello-00001-deployment-689c99c59b-6f5fw   0/2     Terminating         0          92s
  1. 验证 Knative Traffic Splitting

KIngress 定义的 Traffic Splitting 个性负责管理不同 Knative 服务订正（Revision）间的流量划分规定。这个个性能够用于 Knative 服务蓝绿公布与灰度部署。Revision 是利用程序代码和配置的即时快照。每次更改 Knative 服务的配置时，都会创立一个新的订正。当有新订正公布时，Higress 会依据 KIngress 中的路由规定在 Knative 服务的不同版本之间划分流量。

创立 Hello 服务新的订正：

kn service update hello --env TARGET=Knative
#Expected Output   
Service 'hello' created to latest revision 'hello-00002' is available at URL:
http://hello.default.${LOADBALANCER_IP}.example.com

设置不同订正的流量百分比，其中 hello-00001 的流量百分比为 50%，hello-00002 的流量百分比为 50%。

kn service update hello --traffic hello-00001=50  --traffic @latest=50

屡次向 Hello 服务发送申请，能够察看到流量被划分到两个不同的 Revision 上，并且比例满足设定的流量比例：

#Expected Output   
Hello Knative!
Hello World!
Hello Knative!
Hello World!

基于 Higress 插件加强 Knative 网络层能力

前文提到，Higress 可能为 Knative 服务提供诸如认证鉴权、限流、Waf 防护与可观测等更弱小的能力。在本节实际中咱们将联合 Higress 插件市场中的 key-auth 和 key-rate-limit 插件来简要演示 Higress 作为 Knative 网络层可能提供的认证鉴权和限流的能力。

  1. 验证 Higress 对 Knative 服务的限流能力

设置限流规定，部署 key-rate-limit 插件。详情可参考基于 Key 限流 [6]。

apiVersion: extensions.higress.io/v1alpha1
kind: WasmPlugin
metadata:
  name: key-rate-limit
  namespace: higress-system
spec:
  defaultConfig:
    _rules_:
    # 规定二：按域名匹配失效
    - _match_domain_:
      - "hello.default.example.com"
      limit_by_header: x-ca-key
      limit_keys:
      - key: 123456
        query_per_minute: 2
  url: oci://higress-registry.cn-hangzhou.cr.aliyuncs.com/plugins/key-rate-limit:1.0.0

上述配置具体含意如下，含申请头“x-ca-key: 123456”的申请速率将被限度为每分钟 3 次，1 分钟内超过 3 次的申请无法访问到 Knative 服务，该配置对 Knative 服务域名 “http://hello.default.example.com” 失效。咱们通过如下申请进行验证：

curl -H "Host: hello.default.example.com" http://127.0.0.1 -H "x-ca-key: 123456" 
Hello World!    #失常申请到 Knative 服务，返回 200
curl -H "Host: hello.default.example.com" http://127.0.0.1 -H "x-ca-key: 123456" 
Hello Knative!  #失常申请到 Knative 服务，返回 200
curl -H "Host: hello.default.example.com" http://127.0.0.1 -H "x-ca-key: 123456" 
rate_limited   #触发限流，返回 429
  1. 验证 Higress 对 Knative 服务的认证鉴权能力

设置认证鉴权的相干规定，部署 key-auth 插件。详情可参考基于 Key 认证 [7]。

apiVersion: extensions.higress.io/v1alpha1
kind: WasmPlugin
metadata:
  name: key-auth
  namespace: higress-system
spec:
  defaultConfig:
    consumers:
    - credential: 2bda943c-ba2b-11ec-ba07-00163e1250b5
      name: consumer1
    - credential: c8c8e9ca-558e-4a2d-bb62-e700dcc40e35
      name: consumer2
    keys:
    - apikey
    in_query: true
    _rules_:
    - _match_domain_:
      - "hello.default.example.com"
      allow:
      - consumer2
  url: oci://higress-registry.cn-hangzhou.cr.aliyuncs.com/plugins/key-auth:1.0.0

上述配置具体含意如下：在用户组 consumer 中，只有 consumer2 有权拜访，该配置对 knative 服务域名 “http://hello.default.example.com” 失效。咱们通过如下申请进行验证：

curl -H "Host: hello.default.example.com" http://127.0.0.1
#申请未提供 APIKey，返回 401
curl -H "Host: hello.default.example.com" http://127.0.0.1/?apikey=2bda943c-ba2b-11ec-ba07-00163e1250b5
#consumer1 不具备拜访权限，返回 403
curl -H "Host: hello.default.example.com" http://127.0.0.1/?apikey=c8c8e9ca-558e-4a2d-bb62-e700dcc40e35
Hello World!  #consumer2 具备拜访权限，返回 200

计划二：Higress+IstioCRD

除了上述 Higress+KIngress 解析的办法外，Higress 还能够基于本身对 IstioCRD 的兼容能力，通过 IstioCRD 来对接 Knative 服务。具体形式如下：

Step 1. 装置 IstioCRD

helm repo add istio https://istio-release.storage.googleapis.com/charts
helm install istio-base istio/base -n istio-system --create-namespace

启用 IstioCRD 时，需更新 Higress 的部署参数：

helm upgrade higress -n higress-system --set global.enableIstioAPI=true higress.io/higress --reuse-values

Step 2. 装置相干网络层组件

通过运行以下命令装置 Knative Istio Controller（即 net-istio-controller）

kubectl apply -f https://github.com/knative/net-istio/releases/download/knative-v1.10.1/net-istio.yaml

Step 3. 配置 Istio Config 指向 Higress

Knative 社区给出了应用非默认网关的配置，详情参见 Install Istio for Knative-Knative[8]。具体步骤：

批改 config-istio 中的 svc 为 higress-gateway：

kubectl edit configmap config-istio -n knative-serving

增加如下配置：

data:
  gateway.knative-serving.knative-ingress-gateway: higress-gateway.higress-system.svc.cluster.local
  local-gateway.knative-serving.knative-local-gateway: higress-gateway.higress-system.svc.cluster.local

更新命名空间 Knative-serving 中网关实例 knative-local-gateway 与 knative-ingress-gateway：

kubectl edit gw knative-local-gateway -n knative-serving
kubectl edit gw knative-ingress-gateway -n knative-serving

将网关实例 Knative-local-gateway 与 Knative-ingress-gateway 的 selector 下的 label 替换为 higress-gateway 的 label，higress-gateway 的默认如下：

spec:
  selector:
    app: higress-gateway
    higress: higress-system-higress-gateway

上述配置实现后，同样能够通过 Higress 实现 Knative 网络层的根本能力。

相干链接：

[1] kubectl

https://kubernetes.io/docs/tasks/tools/

[2] Helm

https://helm.sh/

[3] Knative CLI (kn)

https://knative.dev/docs/getting-started/quickstart-install/#…

[4] Knative 装置指南

https://knative.dev/docs/install/yaml-install/serving/install…

[5] Higress

https://higress.io/zh-cn/docs/ops/deploy-by-helm/

[6] 基于 Key 限流

https://higress.io/zh-cn/docs/plugins/key-rate-limit/

[7] 基于 Key 认证

https://higress.io/zh-cn/docs/plugins/key-auth/

[8] Install Istio for Knative-Knative

https://knative.dev/docs/install/installing-istio/#configurin…

[9] github: Higress

https://github.com/alibaba/higress

作者：赵伟基（兆维）

点击立刻收费试用云产品 开启云上实际之旅！

原文链接

本文为阿里云原创内容，未经容许不得转载。

退出移动版