直连模式(V1.11.1 版本 废弃此功能) #
意义 #
在Istio设计中,是通过让Sidecar接管流量从而实现的服务治理能力,业务流量会先被Sidecar先行劫持,再抵达业务,若Sidecar自身发生故障,业务也将会中断。
为降低Sidecar自身故障导致的损失,SolarMesh在solarctl
上为集群提供了直连模式,通过直连模式可以将已经接入了Sidecar的服务切换到Kubernetes原生的调用状态。
使用 #
$ solarctl iptables -h
clean iptables to connection istio-proxy.
Usage:
solarctl iptables [flags]
Flags:
--all list the requested object(s) across all pod.
--clean if clean true clean iptables
-c, --context string The name of the kubeconfig context to use
-h, --help help for iptables
-n, --namespace string Namespace in current context is ignored even if specified with --namespace. (default "default")
-p, --pod string pod name
例1:将某个pod切换成直连模式
solarctl iptables -n <namespace> --pod <pod name> --clean
例2:将某个pod恢复
solarctl iptables -n <namespace> --pod <pod name>
例3:将某个namespace下所有的pod切换成直连模式
solarctl iptables -n <namespace> --all --clean
例4:将某个namespace下所有的pod恢复
solarctl iptables -n <namespace> --all
试试看 #
假设我们已经部署过bookinfo示例项目(见
快速开始/安装/使用solarctl安装示例项目
),并且为bookinfo示例项目的服务接入了sidecar(见快速开始/接管服务
)
访问我们事先部署好的示例项目bookinfo的页面,多刷新几次,您会发现在没有任何策略干预的情况下,页面中 Book Reviews 一栏呈现三种状态: 红星、黑星和无星,它们的出现概率约为1:1:1。
此时进入SolarMesh的流量视图界面,您可以看到这样的一幅流量拓扑图。
此时可以发现,reviews 服务有3个版本对应着3种状态,我们先在 DestinationRule 上配置 reviews 的版本。
然后在 VirtualService 创建一份http策略,配置故障注入,我们将故障码 500 注入到 reviews 服务上。
再次访问示例项目bookinfo的页面。我们可以发现故障已经产生,reviews 服务已经开始报错了。
此时进入SolarMesh的流量视图界面,您可以看到这样的一幅流量拓扑图。由于请求已经被系统强制返回500错误,并不会抵达真正的服务,所以可以看到是 productpage 访问了reviews.demo.svc.cluster.local 这个host,并且流量线是红色的。
现在已经确定是sidecar拦截了流量,那么就可以使用直连模式
来保障业务的连续。我们可以使用solarctl
的命令让demo这个namespace下所有的pod都切换成直连模式
可以看到切换成功后,pod没有重启,并且业务恢复了正常
流量视图上也监测不到任何流量,说明sidecar没有上报数据,流量已经绕过sidecar直接抵达业务服务
现在我们恢复它
刷新示例项目bookinfo的页面,故障又会产生,sidecar重新开始起作用。
流量视图重新识别出它们的流量