Direct Connection

直连模式 #

意义 #

在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。

bookinfo-productpage

此时进入SolarMesh的流量视图界面,您可以看到这样的一幅流量拓扑图。

流量视图

此时可以发现,reviews 服务有3个版本对应着3种状态,我们先在 DestinationRule 上配置 reviews 的版本。

dr版本号

然后在 VirtualService 创建一份http策略,配置故障注入,我们将故障码 500 注入到 reviews 服务上。

故障注入

再次访问示例项目bookinfo的页面。我们可以发现故障已经产生,reviews 服务已经开始报错了。

bookinfo-故障注入

此时进入SolarMesh的流量视图界面,您可以看到这样的一幅流量拓扑图。由于请求已经被系统强制返回500错误,并不会抵达真正的服务,所以可以看到是 productpage 访问了reviews.demo.svc.cluster.local 这个host,并且流量线是红色的。

流量视图-故障注入

现在已经确定是sidecar拦截了流量,那么就可以使用直连模式来保障业务的连续。我们可以使用solarctl的命令让demo这个namespace下所有的pod都切换成直连模式

直连模式

可以看到切换成功后,pod没有重启,并且业务恢复了正常

productpage

流量视图上也监测不到任何流量,说明sidecar没有上报数据,流量已经绕过sidecar直接抵达业务服务

无流量

现在我们恢复它

直连模式-恢复

刷新示例项目bookinfo的页面,故障又会产生,sidecar重新开始起作用。

bookinfo-故障注入

流量视图重新识别出它们的流量

流量视图-故障注入