共计 5464 个字符,预计需要花费 14 分钟才能阅读完成。
在 上一篇 文章中分享了分布式运行时 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+k3s2
curl -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.yaml
fsm:
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.io
helm repo update
helm install \
--namespace flomesh \
--create-namespace \
--version=0.2.1-alpha.3 \
-f values.yaml \
fsm fsm/fsm
部署示例利用
示例利用咱们应用 kennethreitz/httpbin
,为其增加 dapr 相干的注解。
kubectl create ns httpbin
kubectl apply -n httpbin -f - <<EOF
apiVersion: apps/v1
kind: Deployment
metadata:
labels:
app: httpbin
name: httpbin
spec:
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: v1
kind: Service
metadata:
labels:
app: httpbin
name: httpbin
namespace: httpbin
spec:
ports:
- port: 80
protocol: TCP
targetPort: 80
selector:
app: httpbin
EOF
计划 1
参考 Flomesh Ingress 的 文档,创立入口规定应用 Service httpbin
作为后端。
kubectl apply -n httpbin -f - <<EOF
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
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: Prefix
EOF
应用主机 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 - <<EOF
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
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: Prefix
EOF
依然是拜访 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 - <<EOF
apiVersion: dapr.io/v1alpha1
kind: Configuration
metadata:
name: httpbinconfig
spec:
accessControl:
defaultAction: deny
trustDomain: "public"
policies:
- appId: ingress
defaultAction: deny
trustDomain: 'public'
namespace: "flomesh"
operations:
- name: /get
httpVerb: ['GET']
action: allow
EOF
利用配置之后,须要重启利用。
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,在实现上更像是一个全局的利用运行时。
(转载本站文章请注明作者和出处盛世浮生,请勿用于任何商业用途)