Kubernetes生产实践系列之二十四：Service Mesh之Istio proxy的流量劫持详细分析

最新推荐文章于 2022-08-14 20:40:31 发布
最新推荐文章于 2022-08-14 20:40:31 发布
阅读量1.3k 收藏 4
点赞数
分类专栏： Kubernetes生产实践系列 云原生 ServiceMesh 文章标签： kubernetes 云原生 ServiceMesh
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/cloudvtech/article/details/106532419
版权

一、前言

文章《Kubernetes生产实践系列之二十三：Service Mesh之在Kubernetes部署Istio进行service mesh》介绍了Istio的部署和使用案例，本文对于v1.6版本的Istio proxy sidecar的工作原理进行分析，包括：

  • sidecar注入方法
  • 流量劫持方法
  • 数据流转方法

转载自https://blog.csdn.net/cloudvtech

 

二、sidecar注入方法

2.1 注入方式

根据Istio官方文档《Installing the Sidecar》，sidecard有手动注入和自动注入两种方式，这两种注入方式可以使用默认的注入配置文件：

kubectl -n istio-system get configmap istio-sidecar-injector -o=jsonpath='{.data.config}' > inject-config.yaml
kubectl -n istio-system get configmap istio-sidecar-injector -o=jsonpath='{.data.values}' > inject-values.yaml
kubectl -n istio-system get configmap istio -o=jsonpath='{.data.mesh}' > mesh-config.yaml
  • inject-config.yaml里面是注入sidecard使用的模版
  • inject-values.yaml里面是注入sidecard使用的一些配置value
  • mesh-config.yaml里面是servicemesh的配置文件：
accessLogEncoding: TEXT
accessLogFile: /dev/stdout
accessLogFormat: ""
defaultConfig:
  concurrency: 2
  configPath: ./etc/istio/proxy
  connectTimeout: 10s
  controlPlaneAuthPolicy: NONE
  discoveryAddress: istiod.istio-system.svc:15012
  drainDuration: 45s
  parentShutdownDuration: 1m0s
  proxyAdminPort: 15000
  proxyMetadata:
    DNS_AGENT: ""
  serviceCluster: istio-proxy
  tracing:
    zipkin:
      address: zipkin.istio-system:9411
disableMixerHttpReports: true
disablePolicyChecks: false
enablePrometheusMerge: false
ingressClass: istio
ingressControllerMode: STRICT
ingressService: istio-ingressgateway
protocolDetectionTimeout: 100ms
reportBatchMaxEntries: 100
reportBatchMaxTime: 1s
sdsUdsPath: unix:/etc/istio/proxy/SDS
trustDomain: cluster.local
trustDomainAliases: null

a) 使用istioctl进行手动注入

istioctl kube-inject -f sample.yaml | kubectl apply -f -

也可以在注入的时候overwrite默认的Istio配置文件，使用自定义的配置：

istioctl kube-inject \
    --injectConfigFile inject-config.yaml \
    --meshConfigFile mesh-config.yaml \
    --valuesFile inject-values.yaml \
    --filename sample.yaml \
    | kubectl apply -f -

b) 使用webhook admission controller进行自动注入

需要先将一个namespace标记成可以注入的：

kubectl label namespace istio-test istio-injection=enabled

之后在这个namespace部署的POD会由Kubernetes自动按照注入的配置文件进行sidecar注入

2.2 注入效果

在执行sidecar注入之后，新启动的POD会启动sidecar，包含两个container，一个是初始化容器，一个是proxy容器。

a) 初始化容器istio-init

该容器主要是进行POD network namespace sidecar iptables的写入，这些iptables规则主要是进行出站和入站数据的劫持转发：

b) 数据流代理容器istio-proxy

该容器进行数据面数据流的转发和控制，实现servicemesh的所有数据流管控工作，包括目的地查找、负载均衡、熔断、服务发现、服务健康管理、metrics和trace等工作。该数据proxy借助envoy进行数据面得到操作，envoy使用C++进行编码，同时使用xDS协议进行系统化和规范化的控制面和数据面、数据面和数据面的信息交互。

转载自https://blog.csdn.net/cloudvtech

 

三、数据流量劫持方法

数据流量的劫持主要发生在istio-init容器里面建立的iptables规则中，由于这些iptables是建立在业务POD的namespace的，所以在主机上是看不到这些规则的。

3.1 iptables规则插入

init容器通过istio-iptables命令和指定的参数来插入iptables：

istio-iptables -p 15001 -z 15006 -u 1337 -m REDIRECT -i * -x -b * -d 15090,15021,15020

对应的代码在这里：

https://github.com/istio/istio/blob/master/tools/istio-iptables/pkg/cmd/run.go

该命令参考如下一些变量：

PROXY_PORT=15001
PROXY_INBOUND_CAPTURE_PORT=15006
PROXY_UID=1337
PROXY_GID=1337
INBOUND_INTERCEPTION_MODE=REDIRECT
INBOUND_TPROXY_MARK=1337
INBOUND_TPROXY_ROUTE_TABLE=133
INBOUND_PORTS_INCLUDE=*
INBOUND_PORTS_EXCLUDE=15090,15021,15020
OUTBOUND_IP_RANGES_INCLUDE=*
OUTBOUND_IP_RANGES_EXCLUDE=
OUTBOUND_PORTS_EXCLUDE=
KUBEVIRT_INTERFACES=
ENABLE_INBOUND_IPV6=false

PROXY_UID/GID是enovy proxy以该ID运行，15006和15001分别是入站和出站端口，15090/15021/25020是istio的管理端口，所以会从入站监控端口里面去除，另外入站流量使用REDIRECT的模式进行劫持，另外一种劫持方式是TPROXY。

插入的规则如下：

* nat
-N ISTIO_REDIRECT
-N ISTIO_IN_REDIRECT
-N ISTIO_INBOUND
-N ISTIO_OUTPUT
-A ISTIO_REDIRECT -p tcp -j REDIRECT --to-ports 15001
-A ISTIO_IN_REDIRECT -p tcp -j REDIRECT --to-ports 15006
-A PREROUTING -p tcp -j ISTIO_INBOUND
-A ISTIO_INBOUND -p tcp --dport 22 -j RETURN
-A ISTIO_INBOUND -p tcp --dport 15090 -j RETURN
-A ISTIO_INBOUND -p tcp --dport 15021 -j RETURN
-A ISTIO_INBOUND -p tcp --dport 15020 -j RETURN
-A ISTIO_INBOUND -p tcp -j ISTIO_IN_REDIRECT
-A OUTPUT -p tcp -j ISTIO_OUTPUT
-A ISTIO_OUTPUT -o lo -s 127.0.0.6/32 -j RETURN
-A ISTIO_OUTPUT -o lo ! -d 127.0.0.1/32 -m owner --uid-owner 1337 -j ISTIO_IN_REDIRECT
-A ISTIO_OUTPUT -o lo -m owner ! --uid-owner 1337 -j RETURN
-A ISTIO_OUTPUT -m owner --uid-owner 1337 -j RETURN
-A ISTIO_OUTPUT -o lo ! -d 127.0.0.1/32 -m owner --gid-owner 1337 -j ISTIO_IN_REDIRECT
-A ISTIO_OUTPUT -o lo -m owner ! --gid-owner 1337 -j RETURN
-A ISTIO_OUTPUT -m owner --gid-owner 1337 -j RETURN
-A ISTIO_OUTPUT -d 127.0.0.1/32 -j RETURN
-A ISTIO_OUTPUT -j ISTIO_REDIRECT
COMMIT

同时注入之后的POD网卡设备信息如下：

root@web-54f74db995-c26xv:/# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
2: tunl0@NONE: <NOARP> mtu 1480 qdisc noop state DOWN group default qlen 1000
    link/ipip 0.0.0.0 brd 0.0.0.0
4: eth0@if106: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1440 qdisc noqueue state UP group default 
    link/ether 86:4c:63:b6:14:cc brd ff:ff:ff:ff:ff:ff link-netnsid 0
    inet 10.244.241.91/32 scope global eth0
       valid_lft forever preferred_lft forever

3.2 iptables规则解读

在进行iptables规则解读之前，有几个基本的规则需要先进行了解，以便于理解后续的iptables规则：

  • 所有数据经由enovy处理之后，数据包所属的UID/GID即是envoy运行所使用的ID：1337
  • 15001和15006分别是envoy proxy监听的数据包出站和入站端口
  • enovy proxy数据处理完毕之后的出口设备是lo或者eth0，取决于是入站还是出站流量，默认情况下入站数据经过proxy处理之后源IP地址是127.0.0.1(这个文章介绍了透明代理的情况)
  • 127.0.0.6是envoy PassThroughCluster使用的IP(PassThroughCluster is the default cluster traffic is directed to if no listeners -> routes -> clusters are found during the lookup.)，这个目标是没有任何match情况下的默认处理。
  • iptables的规则主要分成出站和入站两类规则，其中入站规则比较简单，主要考虑需要ignore的istio管理端口，出站规则则比较复杂，需要根据数据包的来源/去向/处理阶段(envoy proxy处理之前还是之后)进行分别处理
  • 业务容器收到的来自envoy proxy的数据包目的地址应该是业务POD的IP(因为客户端侧envoy调用的时候，已经确定是要调用哪个IP的endpoint POD)，经由lo进入，业务容器发出的数据包目的地址是对方服务的clusterIP地址
  • 进入和流出istio proxy sidecar和业务容器的流量都需要分别经过ISTIO_INBOUND和ISTIO_OUTPUT的处理

init容器插入的iptables规则编号如下：

01: * nat
02: -N ISTIO_REDIRECT
03: -N ISTIO_IN_REDIRECT
04: -N ISTIO_INBOUND
05: -N ISTIO_OUTPUT
06: -A ISTIO_REDIRECT -p tcp -j REDIRECT --to-ports 15001
07: -A ISTIO_IN_REDIRECT -p tcp -j REDIRECT --to-ports 15006
08: -A PREROUTING -p tcp -j ISTIO_INBOUND
09: -A ISTIO_INBOUND -p tcp --dport 22 -j RETURN
10: -A ISTIO_INBOUND -p tcp --dport 15090 -j RETURN
11: -A ISTIO_INBOUND -p tcp --dport 15021 -j RETURN
12: -A ISTIO_INBOUND -p tcp --dport 15020 -j RETURN
13: -A ISTIO_INBOUND -p tcp -j ISTIO_IN_REDIRECT
14: -A OUTPUT -p tcp -j ISTIO_OUTPUT
15: -A ISTIO_OUTPUT -o lo -s 127.0.0.6/32 -j RETURN
16: -A ISTIO_OUTPUT -o lo ! -d 127.0.0.1/32 -m owner --uid-owner 1337 -j ISTIO_IN_REDIRECT
17: -A ISTIO_OUTPUT -o lo -m owner ! --uid-owner 1337 -j RETURN
18: -A ISTIO_OUTPUT -m owner --uid-owner 1337 -j RETURN
19: -A ISTIO_OUTPUT -o lo ! -d 127.0.0.1/32 -m owner --gid-owner 1337 -j ISTIO_IN_REDIRECT
20: -A ISTIO_OUTPUT -o lo -m owner ! --gid-owner 1337 -j RETURN
21: -A ISTIO_OUTPUT -m owner --gid-owner 1337 -j RETURN
22: -A ISTIO_OUTPUT -d 127.0.0.1/32 -j RETURN
23: -A ISTIO_OUTPUT -j ISTIO_REDIRECT
24: COMMIT

iptables规则解释：

  • 1，表明这些规则都插入到NAT表中
  • 2~5，是新建新的chain，istio的所有iptables操作都在自己的chain里面进行，不修改系统的默认chain。其中ISTIO_REDIRECT chain用于转发到proxy入站端口，ISTIO_IN_REDIRECT chain用于转发到proxy的出站端口，ISTIO_INBOUND和ISTIO_OUTPUT用于入站和出站数据类型判断和下一步规则确定
  • 6～7，分别指定数据最后的跳转目标是envoy proxy监听的出站和入站端口，进入envoy proxy进行servicemesh
  • 8，将入站数据导入入站处理的chain ISTIO_INBOUND
  • 9~12，Istio管理端口数据不进行任何servicemesh处理，直接由envoy的proxy进行响应
  • 13，其余数据包进入ISTIO_IN_REDIRECT chain，最后由规则7主导，进入enovy监听的15006入站端口进行servicemesh处理
  • 14，出站数据包进入ISTIO_OUTPUT chain进行处理
  • 15，对于inbound PassThroughCluster来源的数据，不做额外处理，直接返回
  • 16/19，对于由envoy proxy经由lo发出的目的地非127.0.0.1的数据包，进入envoy proxy的入站处理端口；这条规则主要应对的容器调用本身所在的svc，并且经过envoy proxy代理mesh之后调度到自己的情况(即appN <=> Envoy (client) <=> Envoy (server) <=> appN)，这种情况下目的IP是当前POD自己的IP，但是数据是由envoy经过mesh之后发出的(uid owner 1337)，这种情况也属于数据包入站的case，所以直接进入envoy的入站端口，进行后续转发处理逻辑
  • 17/20，如果是来自lo的业务容器通过自己的POD IP调用自己的数据包(appN => appN by lo)，不走envoy proxy处理流程，直接返回
  • 18/21，如果是来自envoy proxy的其它数据包，不做任何处理，直接返回
  • 22，如果是通过localhost/127.0.0.1进行调用的数据包，不做任何处理，直接返回
  • 23，其它数据包转入envoy proxy的出站端口，进行servicemesh处理(包括选定endpoint和proxy出去)

综上所述，入站的数据包的处理比较简单，除了exlcude一些端口，其余的都进入proxy入站处理逻辑，而出站的情况比较复杂，对于如下一些case进行了特殊处理：

  • app通过clusterIP调用自己所在的svc最后被自己POD所在的envoy调度会自己的情况，需要将出站数据包转送到入站iptables处理chain，进而走标准的入站数据包处理流程，需要由envoy进行处理
  • app容器通过自己的POD IP调用自己所在的POD内的服务的情况，不需要envoy进行处理
  • envoy发出的其它数据包，不需要envoy进行处理
  • app容器通过localhost调用自己所在的POD内的服务的情况，不需要envoy进行处理
  • 剩余的属于标准的出站数据包，需要由envoy进行处理

这里主要的区分点包括：

  • 是否是localhost的流量
  • 是否是envoy proxy用户空间的流量(uid/gid)

其它参考信息：

转载自https://blog.csdn.net/cloudvtech

 

 

四、数据流转方法

4.1 istio mesh的调用流程

基本流程：进入和流出istio proxy sidecar和业务容器的流量都需要分别经过ISTIO_INBOUND和ISTIO_OUTPUT的处理，sidecar和业务容器发出或者接收的流量都会独立走一次iptables链表

servicemesh流程：app1 => envoy proxy1 =>  envoy proxy2 => app2，app1调用app2所在的服务会通过Kubernetets的cluster service IP进行，进入envoy proxy1之后会选定app2所在的服务的后端列表里面的某一个endpoint比如app2容器，获取其IP，将请求的目的地设置为该IP，发送过去，envoy proxy2在接收到数据包之后，会直接转发给后端app2容器。

proxy和mesh操作：而对于envoy proxy而言，入站数据包是指外部业务容器调用本地业务容器的流量以及本地调用外部之后的返回流量，这里都只要让proxy进行转发操作而不需要mesh操作；出站数据包是指本地业务容器调用外部业务容器的流量以及本地给外部返回的响应流量，这里前者需要本地proxy进行mesh操作而后者只需要proxy操作不需要mesh操作；入站和入站的数据包经过evnoy mesh操作之后都带有明确的源POD和目的POD地址。

4.2 劫持的数据的流转动作

对于入站的数据，被劫持之后的目的动作有两个：

  • RETURN，不进行任何istio proxy的处理
  • ISTIO_IN_REDIRECT，进行istio proxy的入站处理

对于出站的数据，被劫持之后的目的动作有三个：

  • RETURN，不进行任何istio proxy的处理
  • ISTIO_IN_REDIRECT，进行istio proxy的入站处理
  • ISTIO_REDIRECT，进行istio proxy的出站处理

这里比较费解的是出站数据竟然有可能要进行入站处理，主要是考虑服务A的某个POD1调用自己所在的服务A的Kubernetes service IP，最后被istio proxy进行mesh之后调度到自己(POD1)的情况，这种情况下出站操作之后紧接着就应该是入站操作。

4.3 istio mesh的请求响应流程分析

servicemesh的调用和响应流程

app1(svc1)会使用app2所在的svc2来进行调用：

  • a) app1容器发出请求数据包P1(src: POD1_IP, dst: svc2, out device: eth0)
  • b) P1会先经过iptables的ISTIO_OUTPUT链表，根据P1的TCP包头信息以及数据包owner是app1，所以不能匹配规则15～22，而匹配规则23进入ISTIO_REDIRECT链表
  • c) P1经过ISTIO_REDIRECT链表规则6的引导进入proxy的15001出站监听端口
  • d) proxy根据svc2的域名进行mesh而选中svc2的一个endpoint app2，确定其地址POD2_IP，数据包P1被修改成P2(src: POD1_IP, dst: POD2_IP, out device: eth0)，该数据包进入ISTIO_OUTPUT链表
  • e) 由于数据包P2输出设备是eth0，owner是proxy，所以不满足链表规则15～17，但是满足规则18，所以直接return，并且随后eth0被发送出去到app2所在的POD2
  • f) 在POD2数据包P2被接收之后被修改成数据包P3(src: POD1_IP, dst: POD2_IP, in device: eth0)，并进入ISTIO_INBOUND链表
  • g) ISTIO_INBOUND链表内部的规则9～12都无法匹配，所以直接进入ISTIO_IN_REDIRECT链表
  • h) ISTIO_IN_REDIRECT链表规则7将数据包P3引导进入proxy的15006入站监听端口
  • i) proxy处理完毕之后数据包P3被修改成数据包P4(src: POD1_IP, dst: 127.0.0.1, out device: lo)并且由proxy发送出去并进入ISTIO_OUTPUT链表
  • j) 由于数据包P4的owner是proxy并且输出设备是lo，所以不满足ISTIO_OUTPUT链表的规则15～21，而匹配规则22，直接return并且将数据包P4发送给业务容器app2

app2(svc2)处理之后响应app1的流程如下：

  • k) app2将响应数据包P5(src: POD2_IP, dst: POD1_IP, out device: eth0)发送出来进入ISTIO_OUTPUT链表
  • l) 数据包P5的owner是app2并且出口设备是eth0，所以无法匹配ISTIO_OUTPUT链表规则15～22，可以匹配规则23，进入ISTIO_REDIRECT链表
  • m) ISTIO_REDIRECT链表的规则6将数据包P5引导进入proxy的15001出站监听端口
  • n) 针对响应数据包，proxy不做mesh处理，直接将数据包P5(src: POD2_IP, dst: POD1_IP, out device: eth0)发出来至ISTIO_OUTPUT链表，并将数据包owner变成proxy的uid
  • o) 数据包P5会匹配ISTIO_OUTPUT链表的规则18，直接return，后续发送给app1所在的POD1
  • p) POD1接收之后会进入ISTIO_INBOUND链表，此时数据包P5被修改成数据包P6(src: POD2_IP, dst: POD1_IP, in device: eth0)，这个数据包P6会匹配规则13，进入ISTIO_IN_REDIRECT链表
  • q) ISTIO_IN_REDIRECT链表规则7会将数据包P6引导进入proxy的15006入站监听端口
  • r) 针对响应数据包，proxy不做mesh处理，会将数据包P6修改成P7(src: POD2_IP, dst: 12.0.0.1, out device: lo)并直接将数据包P7发出来至ISTIO_OUTPUT链表，并将数据包owner变成proxy的uid
  • s) 根据P7数据包的特点，会匹配ISTIO_OUTPUT链表的规则22，直接return并且将数据包P7发送给业务容器app1，完成一次请求响应

注释：

特别的，如果svc1 = svc2，并且在步骤d)中POD1 = POD2，则数据包的出口设备会变成lo，目的地址为POD1的IP地址，则会匹配ISTIO_OUTPUT链表中的规则16/19，然后进入ISTIO_IN_REDIRECT链表

转载自https://blog.csdn.net/cloudvtech


 

 

 

cloudvtech
关注
  • 0
    点赞
  • 踩
  • 4
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
专栏目录
凌晨 12 点突发 Istio 生产事故！一顿操作猛如虎解决了
Qingcloudedu的博客
10-21 393
事故起因 业务上新集群，本来以为"洒洒水"，11 点切，12 点就能在家睡觉了。流量切过来后，在验证过程中，发现网页能够正常打开，在登录时返回了 502，当场懵逼。在相关的容器日志发现一个高频的报错条目“7000 端口无法连接”，向业务组了解到这是 redis 集群中的一个端口，前后端是通过 redis 交互的，该集群同时还有 7001-7003 其它三个端口。 用 nc 命令对 redis 集群进行连接测试：向服务端发送 keys * 命令时，7000 端口返回的是 HTTP/1.1 400 Bad Re
云原生和ServiceMesh主要组件--理解K8s/Istio/Envoy
网络安全研究
05-24 3121
Kubernetes 作为一种容器编排调度工具，解决了分布式应用程序的部署和调度问题。 Istio通过透明代理（sidecar)将流量管理从K8S中解耦，满足了ServiceMesh对细粒度流量管理的需求。 Envoy是 Istio 中默认的 sidecar 代理。
微服务学习笔记 K8S、ISTIO、微服务、容器不得不说的故事
qj4865的博客
02-01 5600
微服务运行在容器内；容器依靠K8S进行编排、服务发现、负载均衡等；Istio和K8S进行融合，在利用K8S的一些功能的基础上（服务注册），对K8S进行功能的扩展，追加了一些服务治理功能（熔断、限流、动态路由、调用链追踪）。 微服务与容器 为了微服务的快速部署和迭代，如今的微服务架构中，通常将微服务部署在容器内。使用容器的好处 K8S K8S是一个基于容器技术的分布式架构方案。利用K8S，我们可以很好的对容器进行管理。 其架构如下： K8S的最基础单位是Pod，一个Pod下可以支持许多容器，Pod中的容器.
Istio知识点
最新发布
Linux_cui的博客
08-14 285
istio
istio请求路由分析
yevvzi的博客
08-07 1588
环境 这里我们是在本机使用kind，安装 查看容器对应的虚拟设备对 for container in `crictl ps -q` do iflink=`crictl exec $container cat /sys/class/net/eth0/iflink` iflink=`echo $iflink|tr -d '\r'` veth=`grep -l $iflink /sys/class/net/*/ifindex` veth=`echo $veth|sed -e 's;^.*net/\(.*\)/if
istio-proxy性能洞察之路---性能调研的终点、调优之路的出发点
qq_32783703的博客
11-18 2781
最近配合公司落地 service mesh，整体架构采用了istio 的部署架构，但是最近对envoy的sidecar做了压力测试，sidecar的性能是十分的差 说下istio-proxy是istio社区对envoy做了插件，包装成了istio-proxy,git目录是 https://github.com/istio/proxy 落地istio之后我们对istio-proxy性能进行了压测，每年技术大会演讲的envoy做sidecar在我们压测下，是那么单薄，显得差强人意，下面公布我们架构组
jupyterhub-istio-proxy:适用于运行istio Service Mesh的kubernetes集群的JupyterHub代理实现
05-07
jupyterhub-istio-proxy是可扩展的解决方案，可满足Jupyterhub的高网络流量需求。 它实现了jupyterhub代理api，以根据来自集线器的请求配置istio。 支持以下请求： GET /api/routes ：获取在istio上配置的所有...
service-mesh-fight:服务网格比较工具（例如，istio和linkerd）
03-21
本项目“service-mesh-fight”旨在对比两个知名的服务网格解决方案：Istio和Linkerd，帮助开发者和架构师了解它们的特性、优缺点以及适用场景。 首先，让我们深入理解服务网格的概念。服务网格是一种专门用于处理...
istio之流量管理能力.docx
09-03
Service和Proxy的组合构成了服务网格，使服务流量管理变得轻松。 Istio的流量管理能力主要体现在以下几个方面： 1. 请求路由：Istio引入服务版本的概念，允许通过配置将不同比例的流量分配给服务的不同版本。例如...
ServiceMesh架构反思：数据平面和控制平面的界线该如何划定？
02-24
苦等一年，始终不见Istio的性能有实质性提升，失望之余，开始反思Istio而至ServiceMesh的架构。焦点所在：proxy到底该做哪些事情？架构的优美和性能的实际表现该如何平衡？Istio的性能，从去年5月问世以来，就是一块...
k8s之Istio Gateway 单向/双向/透传TLS配置(1)
jiayu的博客
04-28 1986
这篇文章将根据Istio官方案例实现Gateway的TLS或mTLS，以及HTTPS透传
逃脱只会部署集群系列 —— Istio实现微服务流量治理以及envoy剖析
一别两宽丶各生欢喜
01-16 2452
目录 一、利用istio进行微服务流量分配 1、模拟流量分配规则场景 2、使用Istio实现 二、服务网格细节剖析 1、宏观角度剖析 2、认识envoy 3、envoy的xDS 4、envoy在微服务治理中的工作环境 三、envoy实现原理 1、工作原理 四、envoy实现流量转发剖析 （重要） 1、istio-init容器作用 2、init容器进行入站出站流量监控 3、envoy接管出口流量剖析 1、监听15001端口跳转路由 2、route规则跳转cluster配置 .
禁止内核创建fallback设备
redwingz的博客
06-01 663
使用ip link命令查看接口的时候，会发现一些系统自动创建的隧道fallback设备，如：tunl0、gre0、gretap0、sit0、ip6tnl0和ip6gre0等。 / # ip link 14: tunl0@NONE: <NOARP> mtu 1480 qdisc noop state DOWN mode DEFAULT group default qlen 1 link/ipip 0.0.0.0 brd 0.0.0.0 15: gre0@NONE: <NOARP&gt
深度解析Istio系列之Istio-proxy初始化篇
BoCloud博云
03-20 2924
注：以下讲述的按理环境场景是基于Kubernetes环境基础上部署的Istio环境。 涉及到Envoy概念介绍请参考深度解析Istio系列之流量控制篇。本文重点针对Envoy初始化场景进行拆解。 Istio-proxy（Envoy）作为Istio数据平面的重要组件，基于sidecar方式与业务应用混合部署到同一pod，为应用提供代理服务。Pilot作为控制平面组件，基于元数据的抽象层，屏...
[kubernetes]故障排查 istio
爷来辣的博客
06-18 6166
[kubernetes]故障排查 istio 问题是这样的，部署了自己公司的服务，发现相关的的pods都只有二分之一个容器是READY的。 启动deployment 显示not ready 我这里的pod是由一个tomcat容器和一个sidecar容器组成的。 1/2 running表示sidecar容器有问题，通过查看日志并指定容器 发现的确是sidecar健康检查有问题 没有通过readiness probe测试的是istio-proxy这个容器。它的readiness probe规则定义如下。 re
Istio及Bookinfo示例程序安装试用笔记
呦呦鹿鸣，食野之芩
11-30 9974
本博客为 http://zhaohuabing.com 在CSDN的镜像，评论请移步 http://zhaohuabing.com/2017/11/04/istio-install_and_example/ Istio是来自Google，IBM和Lyft的一个Service Mesh（服务网格）开源项目，是Google继Kubernetes之后的又一大作,本文将演示如何从裸机开始从零搭建Istio及Bookinfo示
kubernetes Istio是什么
软件工程小施同学 的专栏
11-16 1072
一、Istio Istio 是一个服务网格，它允许集群中的 pods 和服务之间进行更详细、复杂和可观察的通信。 它通过使用 CRD 扩展 Kubernetes API 来进行管理，它将代理容器注入到所有 pods 中，然后由这些 pods 来控制集群中的流量。 二、kube-proxy Kubernetes 中的服务是由运行在每个节点上的kube-proxy组件实现的，该组件创建 iptables 规则，并将请求重定向到 Pod。 因此，服务就是 iptables 规则。 ...
K8S运维笔记-istio安装与配置(1.0.0版本)
恶性佛
09-11 3169
K8S上安装istio1.0.0 安装(node节点执行) 下载 下载地址 https://github.com/istio/istio/releases/ 解压缩 tar zxvf istio-1.0.0-linux.tar.gz 安装目录一览 bin istioctl客户端工具 install 针对不同环境的安装文档，这里使用的是kubernetes s...

“相关推荐”对你有帮助么？

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值