在 上一篇 文章中分享了分布式运行时 Dapr 的应用，在示例中将状态存储能力拆散到 Dapr 运行时中，利用通过 Dapr API 来应用该能力。这篇文章将介绍如何通过 Ingress Controller（入口控制器）来拜访 Dapr 利用。
计划
如何公开 Dapr 利用的拜访，计划有两种：
- 像传统用法一样，配置利用的 Service 作为后端，由入口控制器间接将流量转发到利用容器，简略说就是反对主动配置的 L7 负载均衡器。
- 不间接拜访利用容器，而是通过 Daprd 运行时来拜访。这时，咱们就须要将入口控制器也申明为 Dapr 利用，为其注入 Daprd 运行时容器。此时创立入口规定指向的后端，则是 Ingress 的 Dapr Service。
两种计划各有优劣，前者架构简略；后者尽管引入 Daprd 容器，架构简单，耗费了更多的资源，但也因而能够应用 Dapr 的服务治理能力，如超时、重试、访问控制等等。
接下来咱们将通过示例来别离验证两种计划。
演示
前置条件
- helm
- dapr cli
装置集群
export INSTALL_K3S_VERSION=v1.23.8+k3s2curl -sfL https://get.k3s.io | sh -s - --disable traefik --write-kubeconfig-mode 644 --write-kubeconfig ~/.kube/config装置 Dapr
dapr init --kubernetes --wait装置入口控制器
这里应用 Flomesh 的入口控制器。通过 valus.yaml 为入口控制器增加 dapr 相干的注解。这里须要留神因为默认状况下 Daprd 运行时监听的端口是绑定在回环地址上的，而 Ingress 向后端转发申请时应用的是 Pod IP，因而须要注解 dapr.io/sidecar-listen-addresses: "[::],0.0.0.0" 让 Daprd 运行时能够接管来自 Pod IP 的申请。
# values.yamlfsm: ingress: podAnnotations: dapr.io/sidecar-listen-addresses: "[::],0.0.0.0" dapr.io/enabled: "true" dapr.io/app-id: "ingress" dapr.io/app-port: "8000" dapr.io/enable-api-logging: "true" dapr.io/config: "ingressconfig"helm repo add fsm https://charts.flomesh.iohelm repo updatehelm install \ --namespace flomesh \ --create-namespace \ --version=0.2.1-alpha.3 \ -f values.yaml \ fsm fsm/fsm部署示例利用
示例利用咱们应用 kennethreitz/httpbin，为其增加 dapr 相干的注解。
kubectl create ns httpbinkubectl apply -n httpbin -f - <<EOFapiVersion: apps/v1kind: Deploymentmetadata: labels: app: httpbin name: httpbinspec: replicas: 1 selector: matchLabels: app: httpbin strategy: {} template: metadata: annotations: dapr.io/enabled: "true" dapr.io/app-id: "httpbin" dapr.io/app-port: "80" dapr.io/enable-api-logging: "true" dapr.io/config: "httpbinconfig" labels: app: httpbin spec: containers: - image: kennethreitz/httpbin name: httpbin resources: {}---apiVersion: v1kind: Servicemetadata: labels: app: httpbin name: httpbin namespace: httpbinspec: ports: - port: 80 protocol: TCP targetPort: 80 selector: app: httpbinEOF计划 1
参考 Flomesh Ingress 的 文档，创立入口规定应用 Service httpbin 作为后端。
kubectl apply -n httpbin -f - <<EOFapiVersion: networking.k8s.io/v1kind: Ingressmetadata: name: httpbin annotations: pipy.ingress.kubernetes.io/rewrite-target-from: ^/httpbin/? pipy.ingress.kubernetes.io/rewrite-target-to: /spec: ingressClassName: pipy rules: - http: paths: - backend: service: name: httpbin port: number: 80 path: /httpbin pathType: PrefixEOF应用主机 IP 地址和入口控制器的 80 端口来拜访 /httpbin/get，因为下面配置了门路重写，最终申请 /get 将会被发送到指标 Pod。
curl HOST_IP:80/httpbin/get{ "args": {}, "headers": { "Accept": "*/*", "Connection": "keep-alive", "Content-Length": "0", "Host": "10.0.0.13:80", "User-Agent": "curl/7.86.0" }, "origin": "10.42.0.18", "url": "http://10.0.0.13:80/get"}计划 2
计划 2 也同样须要配置入口规定，只是这次后端服务配置的入口控制器的 Dapr Service，通过 kubectl get svc -n flomesh 就能够找到名字带有 -dapr 后缀的 Service。
kubectl apply -n flomesh -f - <<EOFapiVersion: networking.k8s.io/v1kind: Ingressmetadata: name: dapr annotations: pipy.ingress.kubernetes.io/rewrite-target-from: ^/dapr/? pipy.ingress.kubernetes.io/rewrite-target-to: /spec: ingressClassName: pipy rules: - http: paths: - backend: service: name: ingress-dapr port: number: 80 path: /dapr pathType: PrefixEOF依然是拜访 httpbin 的门路 /get，然而拜访形式要遵循 Dapr 服务调用的 API：通过申请头指定 dapr-app-id 为 httpbin.httpbin。因为入口控制器和指标利用不在同一命名空间下，在利用 id 须要带上其命名空间。
同样是胜利返回，然而能够看到最终利用收到申请头部会多了一些信息，这些信息都是来自 Daprd 运行时，比方 Dapr-Caller-App-Id、"Dapr-Callee-App-Id 标识示意申请的发起方和接管方；Forwarded 标识了发动申请的主机名。如果开启了 tracing，还会有链路相干的信息（本示例中并未开启）。
curl HOST_IP:80/dapr/get -H 'dapr-app-id:httpbin.httpbin'{ "args": {}, "headers": { "Accept": "*/*", "Accept-Encoding": "gzip", "Connection": "keep-alive", "Dapr-App-Id": "httpbin.httpbin", "Dapr-Callee-App-Id": "httpbin", "Dapr-Caller-App-Id": "ingress", "Forwarded": "for=10.42.0.18;by=10.42.0.18;host=fsm-ingress-pipy-864d8d9c76-4kb7r", "Host": "127.0.0.1:80", "Proto": "HTTP/1.1", "Protomajor": "1", "Protominor": "1", "Referer": "", "Traceparent": "00-00000000000000000000000000000000-0000000000000000-00", "User-Agent": "curl/7.86.0", "X-Forwarded-Host": "fsm-ingress-pipy-864d8d9c76-4kb7r" }, "origin": "10.42.0.18", "url": "http://fsm-ingress-pipy-864d8d9c76-4kb7r/get"}访问控制
文章结尾提到应用 计划 2 尽管带来了提早减少了复杂度，然而能够应用 Dapr 的服务治理能力。这里以 Dapr 的访问控制性能 为例。
不晓得大家留神到没，在部署入口控制器和示例利用时，有个注解 dapr.io/config: xxx。这个注解是为利用的 Daprd 运行时指定配置，运行时启动时会从名为 xxx 的 Configuration 资源读取配置。
执行上面的命令为 httpbin 利用设置访问控制规定：默认回绝所有申请，只容许 flomesh 命名空间下的 id 为 ingress 的利用通过 GET 形式拜访门路 /get。更多访问控制配置，能够参考 Dapr 访问控制官网文档。
kubectl apply -n httpbin -f - <<EOFapiVersion: dapr.io/v1alpha1kind: Configurationmetadata: name: httpbinconfigspec: accessControl: defaultAction: deny trustDomain: "public" policies: - appId: ingress defaultAction: deny trustDomain: 'public' namespace: "flomesh" operations: - name: /get httpVerb: ['GET'] action: allowEOF利用配置之后，须要重启利用。
kubectl rollout restart deploy httpbin -n httpbin等到重启实现，再拜访 /get 门路，失常响应。
curl HOST_IP:80/dapr/get -H 'dapr-app-id:httpbin.httpbin'{ "args": {}, "headers": { "Accept": "*/*", "Accept-Encoding": "gzip", "Connection": "keep-alive", "Dapr-App-Id": "httpbin.httpbin", "Dapr-Callee-App-Id": "httpbin", "Dapr-Caller-App-Id": "ingress", "Forwarded": "for=10.42.0.40;by=10.42.0.40;host=fsm-ingress-pipy-864d8d9c76-jctcx", "Host": "127.0.0.1:80", "Proto": "HTTP/1.1", "Protomajor": "1", "Protominor": "1", "Referer": "", "Traceparent": "00-00000000000000000000000000000000-0000000000000000-00", "User-Agent": "curl/7.86.0", "X-Forwarded-Host": "fsm-ingress-pipy-864d8d9c76-jctcx" }, "origin": "10.42.0.40", "url": "http://fsm-ingress-pipy-864d8d9c76-jctcx/get"}然而，如果是拜访门路 /headers，会收到上面的响应：被禁止拜访 /headers。
curl HOST_IP:80/dapr/headers -H 'dapr-app-id:httpbin.httpbin'{ "errorCode": "ERR_DIRECT_INVOKE", "message": "fail to invoke, id: httpbin.httpbin, err: rpc error: code = PermissionDenied desc = access control policy has denied access to appid: ingress operation: headers verb: GET"}总结
文中应用的两种入口计划各有优缺点，计划 1 架构简略，也是咱们罕用的计划；计划 2 中相当于将入口控制器申明为 Dapr 利用，实际上裸露的是 Dapr 的 API，在实现上更像是一个全局的利用运行时。
（转载本站文章请注明作者和出处盛世浮生，请勿用于任何商业用途）