一. 自动注入(sidecar)
说到服务网格必然是侵入式的包裹着你的服务,在中间过程完成了一些列工作,那么就到了我们的第一个主题自动注入,大家在通过webui或者是kubectl创建的时候默认并不会触发Istio的容器注入,那么有以下几种方式可以让istio注入生效:
- 使用命令注入istioctl来创建容器
> istioctl kube-inject -f samples/sleep/sleep.yaml | kubectl apply -f -
- 开启namespace自动注入无论从任何地方创建POD在这个namespace都会自动注入
首先我们需要确认MutatingAdmissionWebhook并且ValidatingAdmissionWebhook许可控制器并以正确的顺序添加了,也就是我们在搭建K8S时的修改,并且需要确认启用了registrationregistration API:
先创建一个用于测试的namespace:
apiVersion: v1
kind: Namespace
metadata:
name: istio-test
labels:
name: istio-test
我们可以通过以下命令查看开启了自动注入的namespace:
> kubectl get namespace -L istio-injection
NAME STATUS AGE ISTIO-INJECTION
default Active 4d
istio-system Active 1h disabled
istio-test Active 21m
kube-public Active 4d
kube-system Active 4d
通过以下命令可以开启自注入:
> kubectl label namespace istio-test istio-injection=enabled
NAME STATUS AGE ISTIO-INJECTION
default Active 4d
istio-system Active 1h disabled
istio-test Active 21m enabled
kube-public Active 4d
kube-system Active 4d
我们在istio中创建一个nginx镜像看看和正常的镜像有什么区别:
在容器组中明显多出了一个istio-proxy这个就表示注入成功了
二, 部署示例项目bookinfo
要开始进行请求路由实验之前我们需要先部署好官方提供的demo其实也就是几条命名搞定的事情:
创建基础Deployment + Service
> kubectl apply -n istio-test -f istio-1.0.3/samples/bookinfo/platform/kube/bookinfo.yaml
# 确认pod创建成功
NAME READY STATUS RESTARTS AGE
details-v1-6764bbc7f7-49mnq 2/2 Running 0 14m
nginx-65c588c7d5-6jmzz 2/2 Running 0 23m
productpage-v1-54b8b9f55-jtwmd 2/2 Running 0 13m
ratings-v1-7bc85949-hcl9r 2/2 Running 0 14m
reviews-v1-fdbf674bb-5n7t7 2/2 Running 0 13m
reviews-v2-5bdc5877d6-4fg72 2/2 Running 0 13m
reviews-v3-dd846cc78-vp4r7 2/2 Running 0 13m
# 确认service创建成功
> kubectl get services -n istio-test
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
details ClusterIP 10.43.31.242 9080/TCP 35s
productpage ClusterIP 10.43.80.92 9080/TCP 24s
ratings ClusterIP 10.43.51.233 9080/TCP 34s
reviews ClusterIP 10.43.220.25 9080/TCP 27s
创建Istio网关(可选使用主要控制域名路由的入口):
> kubectl apply -n istio-test -f istio-1.0.3/samples/bookinfo/networking/bookinfo-gateway.yaml
# 确定网关创建成功
> kubectl get gateway -n istio-test
NAME AGE
bookinfo-gateway 14s
创建基础路由规则(控制流量就是控制rule的规则):
> kubectl apply -n istio-test -f istio-1.0.3/samples/bookinfo/networking/destination-rule-all.yaml
# 通过以下命令可以查看路由规则
kubectl get destinationrules -o yaml -n istio-test
三. 请求路由
开始之前我们需要先理解下图整个服务之间的关系
部署好了之后Istio网关会默认占用31380端口作为80端口的出口,在网关中从31380进来的流量进行了路由判断并且统一路由到了**productpage
**9080端口,所以我们访问http://:31380/productpage能得到以下界面:
因为reviews有v1.v2.v3三个版本,并且在rule配置中都进行了配置,所以多次访问在右边的星星会有不一样的结果(此时概率是3/1):
3.1 所有流量指向V1版本
> kubectl apply -n istio-test -f istio-1.0.3/samples/bookinfo/networking/virtual-service-all-v1.yaml
规则如下,去除了V2和V3:
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: reviews
spec:
hosts:
- reviews
http:
- route:
- destination:
host: reviews
subset: v1
现在在无论怎么刷新就只能看到V1返回内容:
3.2 指定jason用户的流量指向到V2版本
> kubectl apply -n istio-test -f istio-1.0.3/samples/bookinfo/networking/virtual-service-reviews-test-v2.yaml
规则中定义了在headers中有配置的情况下路由访问到V2
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: reviews
spec:
hosts:
- reviews
http:
- match:
- headers:
end-user:
exact: jason
route:
- destination:
host: reviews
subset: v2
- route:
- destination:
host: reviews
subset: v1
登录之后发现怎么刷新都显示的是V2版本的黑星星
四. 故障注入
4.1 HTTP延迟故障
在微服务系统中可能表明看上去没有问题,可能存在潜在的弹性文档,当请求压力变大响应时间变长可能会应为一些内部的超时机制不合理等问题导致不可使用,这个时候通过Istio的HTTP延迟故障可以模拟出访问延迟来排查这类异常BUG
我们将在 reviews:v2 和 ratings 服务之间的一个用户 jason 注入一个 7 秒的延迟。 这个测试将会发现故意引入 Bookinfo 应用程序中的错误。
由于 reviews:v2 服务对其 ratings 服务的调用具有 10 秒的硬编码连接超时,比我们设置的 7s 延迟要大，因此我们期望端到端流程是正常的（没有任何错误）。
> kubectl apply -n istio-test -f istio-1.0.3/samples/bookinfo/networking/virtual-service-ratings-test-delay.yaml
> kubectl get -n istio-test virtualservice ratings -o yaml
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: ratings
...
spec:
hosts:
- ratings
http:
- fault:
delay:
fixedDelay: 7s
percent: 100
match:
- headers:
end-user:
exact: jason
route:
- destination:
host: ratings
subset: v1
- route:
- destination:
host: ratings
subset: v1
你期望 Bookinfo 主页在大约 7 秒钟加载完成并且没有错误。但是，出现了一个问题，Reviews 部分显示了错误消息,页面实际上用了大约 6s。
在 productpage 和 reviews 服务之间超时时间是 6s - 编码 3s + 1 次重试总共 6s ，reviews 和 ratings 服务之间的硬编码连接超时为 10s 。由于我们引入的延时，/productpage 提前超时并引发错误。
这些类型的错误可能发生在典型的企业应用程序中，其中不同的团队独立地开发不同的微服务。Istio 的故障注入规则可帮助您识别此类异常，而不会影响最终用户。
PS : 请注意，这里仅限制用户 “jason” 的失败影响。如果您以任何其他用户身份登录，则不会遇到任何延迟。
4.2 HTTP abort进行故障注入
测试微服务弹性的另一种方法是引入 HTTP abort 故障,如果异常中断那么需要做出对应的处理。为用户 “jason” 创建故障注入规则发送 HTTP abort
> kubectl apply -n istio-test -f istio-1.0.3/samples/bookinfo/networking/virtual-service-ratings-test-abort.yaml
> kubectl get -n istio-test virtualservice ratings -o yaml
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: ratings
...
spec:
hosts:
- ratings
http:
- fault:
abort:
httpStatus: 500
percent: 100
match:
- headers:
end-user:
exact: jason
route:
- destination:
host: ratings
subset: v1
- route:
- destination:
host: ratings
subset: v1
立即看到页面加载并看到 Ratings service is currently unavailable 消息
我们退出账号发现又恢复正常了
五.流量控制
一个常见的用例是将流量从一个版本的微服务逐渐迁移到另一个版本。 在Istio中，您可以通过配置一系列规则来实现此目标， 这些规则将一定百分比的流量路由到一个或另一个服务。 在此任务中，您将先分别向 reviews:v1 和 reviews:v3 各发送50%流量。 然后，您将通过向 reviews:v3 发送100％的流量来完成迁移。
走了上面流程的童鞋现在在不等了的情况下怎么都是访问的V1版本的返回,使用下面的命令把50%的流量从 reviews:v1 转移到 reviews:v3:
> kubectl apply -n istio-test -f istio-1.0.3/samples/bookinfo/networking/virtual-service-reviews-50-v3.yaml
> kubectl get -n istio-test virtualservice reviews -o yaml
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: reviews
...
spec:
hosts:
- reviews
http:
- route:
- destination:
host: reviews
subset: v1
weight: 50
- destination:
host: reviews
subset: v3
weight: 50
最后将所有流量全部指向到V3版本,会发现始终能够看到红色的星星
> kubectl apply -n istio-test -f istio-1.0.3/samples/bookinfo/networking/virtual-service-reviews-v3.yaml
> kubectl get -n istio-test virtualservice reviews -o yaml