前言
此前写了三篇文章,介绍了istio的工作原理、流量调度策略、服务可视化以及监控:
k8s(四)、微服务框架istio安装测试
k8s(五)、微服务框架istio流量策略控制
k8s(六)、微服务框架istio服务可视化与监控
istio项目成立1/多以来,鲜有生产上的用例,但这次最新的1.0版本,在官网介绍上赫然写着:
All of our core features are now ready for production use.
既然宣称生产可用,那么不妨来试用一番昨晚刚发布热气腾腾的1.0版本。
一、安装
首先环境还是基于此前的k8s v1.9集群
1.下载安装istio官方包:
1 | curl -L https://git.io/getLatestIstio | sh - |
由于集群使用traefik对外服务,因此对官方的istio-demo.yaml部署文件中名为istio-ingressgateway的Service部分稍作修改,修改部分未删除已注释,大约在文件的第2482行开始:1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
vim istio-demo.yaml
'''
apiVersion: v1
kind: Service
metadata:
name: istio-ingressgateway
namespace: istio-system
annotations:
labels:
chart: gateways-1.0.0
release: RELEASE-NAME
heritage: Tiller
app: istio-ingressgateway
istio: ingressgateway
spec:
type: ClusterIP
selector:
app: istio-ingressgateway
istio: ingressgateway
ports:
-
name: http2
port: 80
-
name: https
port: 443
-
name: tcp
port: 31400
-
name: tcp-pilot-grpc-tls
port: 15011
-
name: tcp-citadel-grpc-tls
port: 8060
-
name: http2-prometheus
port: 15030
-
name: http2-grafana
port: 15031
'''
修改完毕,kubectl apply -f istio-demo.yaml
出现了一些类似如下的报错:1
error: unable to recognize "install/kubernetes/istio-demo.yaml": no matches for authentication.istio.io/, Kind=Policy
WTF?第一步就出错?去Github查了一下,找到一个issue下的答案说再次kubectl apply -f istio-demo.yaml
就不会有报错了,果然,再次apply之后确实没有报错,推测可能是某些资源之间的依赖关系导致的,几千行的yaml文件,就不深入寻找原因了,继续往下。
稍后查看pod和svc是否正常部署:
1 | root@yksv001238:/usr/local/istio/install/kubernetes# kubectl get pods -n istio-system |
1 | root@yksv001238:/usr/local/istio/install/kubernetes# kubectl get svc -n istio-system |
可以看到,istio-sidecar-injector已经部署成功,在此前的0.x的版本中,开启注入的钩子步骤如下,稍显繁琐,在这里已经全部集成在这一个istio-demo.yaml文件中了,省去许多步骤。
0.x版本开启注入的步骤:
开启指定命名空间的自动注入:
1 | kubectl label namespace default istio-injection=enabled |
二、demo测试
继续沿用此前的测试demo,对此demo拆分结构不了解的可以先看前面的文章:
1 | git clone https://github.com/yinwenqin/istio-test.git |
部署服务:
1 | cd istio-test |
暴露服务
1 | kubectl apply -f istio/ingress-python.yml |
查看部署结果:
1 | root@yksv001238:~/istio-test/service# kubectl get pods |
获取到istio-ingressgateway的ClusterIP:
1 | root@yksv001238:~/istio-test/istio# kubectl get svc -n istio-system | grep istio-ingressgateway |
在本机添加一条dns记录,关联ingress host和istio-ingressgateway:
1 | 10.96.171.51 istio-test.will |
打开浏览器测试:
打不开?哭脸一张,莫不是新版资源间的交互方式有什么变化,导致此前的方式不再适用,联想到1.0版本新增了gateway这种资源,去官网查官网的用例,果然发现了不一样的地方
官网的新版bookinfo用例说明:https://istio.io/docs/examples/bookinfo/#confirm-the-app-is-running
查看官方包中用例的服务暴露文件,发现已经不再适用ingress这种资源了,现版用的是由istio申明的Gateway和VirtualService这两种资源结合工作,代替之前的ingress。
cat istio/samples/bookinfo/networking/bookinfo-gateway.yaml1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
name: bookinfo-gateway
spec:
selector:
istio: ingressgateway # use istio default controller
servers:
- port:
number: 80
name: http
protocol: HTTP
hosts:
- "*"
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: bookinfo
spec:
hosts:
- "*"
gateways:
- bookinfo-gateway
http:
- match:
- uri:
exact: /productpage
- uri:
exact: /login
- uri:
exact: /logout
- uri:
prefix: /api/v1/products
route:
- destination:
host: productpage
port:
number: 9080
看来要针对ingress进行修改了,原来的ingress-js.yaml和ingress-python.yaml文件内容:
1 | # service-js ingress配置 |
修改之后(几个注意的点会在后方说明):
1 | root@yksv001238:~/istio-test/istio# cat gateway-demo.yml |
查看资源是否生成:1
2
3
4
5
6
7
8
9root@yksv001238:~/istio-test/istio# kubectl apply -f gateway-demo.yml
gateway "demo-gateway" configured
virtualservice "test-demo" configured
root@yksv001238:~/istio-test/istio# kubectl get gateway
NAME AGE
demo-gateway 2m
root@yksv001238:~/istio-test/istio# kubectl get virtualservice
NAME AGE
test-demo 2m
浏览器查看效果:
如此前一样,多次点击发射按钮,前端js服务在调用后端的服务时,k8s会根据svc的ep负载均衡策略将流量均衡调度,因此可以看到每次点击按钮,后端服务的版本号都不一致。
服务暴露注意事项:
一、.gateway是推荐作为一个项目的所有微服务节点的通用网关来使用的,建议所有VirtualService共用此gateway
二、.gateway.spec.selector 必须有istio: ingressgateway标签,才能加入istio-ingress-gateway这个统一的入口
三、.如果gateway之下的存在多个VirtualService,且VirtualService.spec.hosts如果存在域名冲突的情况,后者会覆盖前者的配置,因此,同一域名下的服务,建议放入同一VirtualService下。
四(重要)、.VirtualService.spec.http中的uri匹配规则有三种:
1.不写match规则,从根路径起包含所有子路径完全匹配到destination.host指向的svc
2.match匹配方式为exact,此方式为路径完全绝对匹配,例如上方的exact: “/“只能匹配根路径
3.match匹配方式为prefix,此方式为路径前缀匹配,例如上方的prefix: “/env”则会匹配以/env开头的所有路径
补充说明:根据路径做路由匹配时,如果写为模糊匹配的方式,且存在某一匹配规则的匹配路径覆盖了其他规则的匹配路径,此时被覆盖的规则对应的服务如果存在前端js与后端交互,则会出现304跳转以及随之而来的同源策略造成的跨域问题,因此这里的路径规则匹配要避免不必要的路径重叠以避免出现此类问题。(见下方举例)
举例:
将上方的VirtualService的第一段稍作修改,exact方式注释掉改为prefix,其余保持不变,此时匹配前缀”/”路径会覆盖其余所有的子路径,因此会产生304跳转:1
2
3
4
5http:
- match:
- uri:
#exact: "/"
prefix: "/"
kubectl apply之后再次打开浏览器查看效果:
无论点击多少次“发射”按钮,结果都是undefined,浏览器提示js未运行,原因如上方说明,请求在处理的过程中先从"/"
在转到"/env"
过程中出现了304跳转,此时js跨域将被禁,因此,一定要避免不必要的路径设计重叠。
简单测试使用先到这里,随后将继续体验关于流量策略以及安全策略的一些新特性,待补充。