Skip to main content

Command Palette

Search for a command to run...

Istio 1.1 中的 Sidecar 资源

Updated
3 min read

缺省情况下,Istio 在 Pod 创建之前将 istio-initistio-proxy 注入到 Pod 之中,使用 istio-init 对 iptables 进行初始化,将业务容器的流量拦截到 istio-proxy,从而完成通信控制权的移交工作——应用容器的自发 Ingress 和 Egress 通信,都从 Envoy 中留过,Envoy 作为数据平面,需要接受来自控制面的 xDS 指令,据此作出通信决策。

在 Istio 1.1 中引入了 Sidecar 资源对象,为这一拦截转发过程加入了一定的控制能力,可能给 Istio 的生产应用带来很好的效率提升。

基本结构

Sidecar 资源的一级结构很简单,由三个成员构成:

  • workloadSelector:标签选择器,用来对 Pod 进行选择。这一字段是可选字段,如果忽略这一字段,则会对命名空间内的所有 Pod 生效。需要注意的是,一个命名空间之内,只允许存在一个不设置此字段的 Sidecar 对象。

  • ingress:一个数组,用于处理进入 Pod 的流量,如果省略这一字段,Istio 会根据业务应用的工作负载定义来设置监听过程。

    • port:必要字段,监听的端口,如果使用 Unix domain socket,则设置为 0。
      • number
      • protocal
      • name
    • bind:监听器的绑定设置,可以是 ip,也可以是 unix:///path/to/uds,如果省略这一字段,Istio 会根据工作负载服务来自动填充。
    • captureMode:如果 bind 指定的是 IP 地址,这个字段可以指定是否拦截通信,如果绑定到 Unix domain socket,这一字段必须是 DEFAULT 或者 NONE
    • defaultEndpoint:必要字段,Envoy 接收进入 Pod 的流量之后的转发目标。目标可以是 127.0.0.1:PORT 或者 unix:///path/to/socket
  • egress:一个处理 Egress 流量的定义数组。
    • port:监听器的端口,如果使用 Unix domain socket,则设为 0。
    • bind:绑定到地址或 socket。
    • captureMode:同 ingress
    • hosts:必要字段,用 命名空间/服务 FQDN 组合而成,可以是 VirtualService 或者 ServiceEntry 或者原始 Kubernetes 服务的名称,支持通配符。

开始之前

安装 Kubernetes 集群和 Istio,这里采用 1.1.2 的 demo-auth 配置。创建新命名空间 other,并打标签开启自动注入:

$ helm template install/kubernetes/helm/istio-init \
    --name istio-init --namespace istio-system | kubectl apply -f -
...
$ helm template install/kubernetes/helm/istio \
    --name istio --namespace istio-system \
    --values install/kubernetes/helm/istio/values-istio-demo-auth.yaml | kubectl apply -f -
...
$ kubectl create ns other
namespace/other created

$ kubectl label namespaces other istio-injection=enabled --overwrite
namespace/other labeled

$ kubectl label namespaces default istio-injection=enabled --overwrite
namespace/default labeled

分别在 defaultother 中启动 flaskappsleep 应用。

$ kubectl apply -f sleep/sleep.yaml -n default
service/sleep created
deployment.extensions/sleep created
$ kubectl apply -f sleep/sleep.yaml -n other
service/sleep created
deployment.extensions/sleep created
$ kubectl apply -f httpbin/httpbin.yaml -n default
service/httpbin created
deployment.extensions/httpbin created
$ kubectl apply -f httpbin/httpbin.yaml -n other
service/httpbin created
deployment.extensions/httpbin created

检查一下调用关系:

$ kubectl exec -c sleep -it sleep-69bd44b5bb-vwpzf -- curl http://httpbin:8000/ip
{
  "origin": "127.0.0.1"
}

$ kubectl exec -c sleep -it sleep-69bd44b5bb-vwpzf -- curl http://httpbin.other:8000/ip
{
  "origin": "127.0.0.1"
}

服务的可见性

缺省情况下,注入了 Istio 的工作负载会进行全网格的传播,假设 defaultother 两个不相干的命名空间,other 中有大量的服务,而 default 中只有几个,因为路由传播的关系,default 命名空间中的工作负载,其 Sidecar 也会带上 other 命名空间中的路由信息。例如:

$ istioctl proxy-config clusters sleep-69bd44b5bb-vwpzf | grep other
httpbin.other.svc.cluster.local 8000    -   outbound    &{EDS}
sleep.other.svc.cluster.local   80      -   outbound    &{EDS}

可以看到,在 default 命名空间中的 Pod,保存了其它命名空间中的路由信息。这不管是对内存消耗还是路由控制来说,都会造成一定浪费,我们可以定义一个 Sidecar 资源,限制 sleep 服务只访问同一命名空间的其他服务:

apiVersion: networking.istio.io/v1alpha3
kind: Sidecar
metadata:
  name: sleep
spec:
  workloadSelector:
    labels:
      app: sleep  
  egress:
  - hosts:
    - "default/*"

提交到集群,看看效果:

$ kubectl apply -f sleep-egress.yaml
sidecar.networking.istio.io/sleep created

$ istioctl proxy-config clusters sleep-69bd44b5bb-vwpzf | grep httpbin
httpbin.default.svc.cluster.local   8000    -   outbound    &{EDS}

可以看到,httpbin 的路由只剩下了本命名空间之内的服务。再次尝试访问:

$ kubectl exec -c sleep -it sleep-69bd44b5bb-vwpzf -- curl http://httpbin:8000/ip
{
  "origin": "127.0.0.1"
}

$ kubectl exec -c sleep -it sleep-69bd44b5bb-vwpzf -- curl -v http://httpbin.other:8000/ip
*   Trying 10.245.156.252...
* TCP_NODELAY set
* Connected to httpbin.other (10.245.156.252) port 8000 (#0)
> GET /ip HTTP/1.1
> Host: httpbin.other:8000
> User-Agent: curl/7.61.1
> Accept: */*
>
< HTTP/1.1 404 Not Found
< date: Wed, 10 Apr 2019 04:50:15 GMT
< server: envoy
< content-length: 0
<
* Connection #0 to host httpbin.other left intact

这样一来,已经无法访问 httpbin.other 的服务了,但是如果尝试从 otherdefault 访问的话,还是可以继续的。

Sidecar 的 Ingress 和 Egress

除了上面的小功能之外,Sidecar 的 IstioEgressListenerIstioIngressListener 都提供了很强大的功能,例如:

  1. Envoy 可以为应用容器所监听的 Unix socket 提供反向代理服务。
  2. 在没有 iptables 支持的情况下,可以使用 bind 结合 port 的方式,直接指定代理方案。
  3. 可以在容器内部为 egress 服务提供基于 Unix socket 的反向代理。

详情可以参考官方参考文档:https://istio.io/docs/reference/config/networking/v1alpha3/sidecar/#IstioIngressListener

中文版:https://skyao.io/learning-istio/crd/network/sidecar.html

这些功能都非常有用,上面的文档中都提供了很好的应用场景,但是这些特性我只有可见性部分测试成功了(╬ ̄皿 ̄)=○,目前正在讨说法,非常希望是我错了。。

More from this blog

龙虾恐慌:AIOps 又要改名了?

ChatGPT 开始,把 AI 拉近到普罗大众的面前,让无数人感受到 AI 的亲民魅力。而龙虾,则把大模型驱动的自动化能力,突然间变得水灵灵、活泼泼地走进千家万户。它不只是“风口上的猪”,而是风口本身。热度高到让 Mac mini 一度断货,不知道这在不在库克的预料之内。 每代人都有每代人的鸡蛋,春节期间,我就领了我的鸡蛋。翻出古老的 MacBook Air M1,充值各种大模型。当然了,这个工具

Mar 9, 20261 min read

再见 2025

我猜不少人以为这个号废了吧?并没有,只是今年变化有点大,一直有种抄起键盘,无从说起的感觉,所以一直偷懒到今天,2025 的最后一天。 今年是我的第四个本命年,去年末一期播客里,大内说本命年不是灾年,是变化年,有危也有机。可是讲真啊,只看到危,没看到机。 各种因缘际会,从鹅厂跳槽到前东家,已经接近四年,第一个合同期已经进入尾声。除了前两年还在云原生领域嗷嗷叫,后两年基本都是些鸡零狗碎的东西了,用老东家的术语说是——偏离主航道,可谓是前景暗淡了。 一旦确定要滚蛋,反倒心思轻松起来,每天骑着我的小红车...

Jan 5, 20261 min read

辅助编程?dora 说:我知道你很急可是请你别急

从 OpenGPT 把大模型的火烧旺了之后,这三年来,相信很多组织或摩拳擦掌、或躬身入局,希望借助聪明能干的大模型,或想偿还技术宅,或想降本增效,或想弯道超车。一时间,沉寂许久的 AIxx 又活过来了,LLM Ops、Vibe Coding、中医大模型、GPT 算命等等,全都老树发新芽,焕发了勃勃生机。那么视角拉回从业者最关注的饭碗相关的领域之一——AI 辅助开发,产生了什么触动,应该如何拥抱呢? DORA 的年度报告中给出了很有意思的结论——强者恒强。 执行摘要部分总结了几个有趣的点: 问题...

Oct 6, 20251 min read

[译]dora:ai 辅助软件开发状态报告

执行摘要 在 2025 年,科技领导者面临的核心问题已不再是“是否要采用 AI”,而是“如何实现其价值”。 DORA 的研究基于超过 100 小时的定性访谈和来自全球近 5,000 名技术专业人士的问卷调查。研究揭示了一个关键事实:AI 在软件开发中的主要角色是“放大器”。它会放大高效能组织的优势,也会凸显组织的缺陷。 关键结论:AI 是放大器 AI 投资的最大回报并非来自工具本身,而是来自组织底层系统的战略性建设: 高质量的内部平台 清晰的工作流 团队的协同能力 缺少这些基础,AI ...

Oct 2, 202514 min read

僭越了,有人在用 Rust 写 Kubernetes

一个新语言问世,最爱做的事情之一,就是重写存量软件了。 云原生喝酒 SIG 重点扶持项目——rk8s(https://github.com/rk8s-dev/rk8s) 也可以归在这个范畴里,只不过这个项目重写的东西比较大,是 Kubernetes。 从 2025 年 1 月第一个 Commit 开始,到现在有了 200 多次 Commit,十几万行代码。当然距离 Kubernetes 的几百万行代码还差得远——老马就是喜欢整这种大无畏项目。 另外该项目也是国内第一个脱离 Cargo 转向使用 ...

Sep 27, 20253 min read

【伪】架构师

342 posts