Skip to main content

Command Palette

Search for a command to run...

摸索:Istio 路由规则 Alpha v3

Updated
1 min read

Istio 近期的版本中出现了一个新的 API 组:networking.istio.io/v1alpha3,应该会替代现有的config.istio.io/v1alpha2 API。新的 API 不管是结构上还是功能上、以及命名上,都有很大差异。这里使用一些简单例子,体验一下 Alpha 3 带来的变化。

注意:正常情况下 istioctl 和 kubectl 都可以用来操作这些对象,但是 kubectl 缺乏验证功能,因此调试阶段使用 istioctl 会更方便一些。

路由分配

过去的路由分配比较简单,使用标签即可。新的版本中,提出了 VirtualService 的概念。VirtualService 由一组路由规则构成,用于对服务实体(原文为 Host,个人认为在 K8S 中对应为 Pod)进行寻址。一旦有流量符合其中规则的选择条件,就会发送流量给对应的服务(或者服务的一个版本/子集)。

流量的特征除了请求数据之外,还包括流量的来源,这样就能根据一些上下文来进行灵活的定义了。

这里我们定义来自 sleep 对 php-server 的请求,都转向 v1:


apiVersion: networking.istio.io/v1alpha3

kind: VirtualService

metadata:

  name: sleep-server-route

spec:

  hosts:

  - "php-server"

  http:

  - match:

    - sourceLabels:

        app: sleep

    route:

    - destination:

        name: php-server

        subset: v3

  - route:

    - destination:

        name: php-server

        subset: v2

这里的匹配策略是具有从上到下的优先级的,也就是说,最下一条就是缺省路由。

可以看到,match中不再包含 source,这里使用标签来过滤。写完应用之后,我们在 Sleep Pod 中使用 curl 发起请求,会发现并没有生效。这是因为,在 v3 中,目标规则不再是小透明了。,路由定义必须以目标策略为基础。

因此这里需要定义一个 DestinationRule 对象,来满足上面的目标需求:


apiVersion: networking.istio.io/v1alpha3

kind: DestinationRule

metadata:

  name: phpserver

spec:

  name: php-server

  subsets:

  - name: v1

    labels:

      version: v1

  - name: v2

    labels:

      version: v2

  - name: v3

    labels:

      version: v3

上面的文件,创建了名为 phpserver 的目标规则,并在下级使用标签创建了三个子集。再次测试,会发现按照我们的要求执行了。

注意:VirtualService 中引用的 Destination.name 似乎对应的是目标规则中的 spec.name,而不是 metadata.name。

断路器

这部分的 API 变化较大。可以在上面的 DestinationRule 中加入熔断策略:


  - name: v2

    labels:

      version: v2

  trafficPolicy:

    connectionPool:

      http:

        http1MaxPendingRequests: 1

        maxRequestsPerConnection: 1

      tcp:

        maxConnections: 100

    outlierDetection:

      http:

        baseEjectionTime: 180.000s

        consecutiveErrors: 1

        interval: 1.000s

        maxEjectionPercent: 100

接下来就可以使用 Fortio 或其他工具来测试熔断效果了,具体操作可以参考官方文档的断路器一节

总结

新版本 API 加入了相当多的非 K8S 特性,另外突出了 Gateway,VirtualService 等主要对象,使得各个定义的条理性大为增强。但是目前这一组 API 仍然是 Alpha 阶段,因此还是存在相当大的变数的,但是个人推测的是,新 API 会得到更大的支持力度,因此可靠性应该更强。总之 Alpha 有风险,使用需谨慎。

参考链接

  1. VirtualService: https://istio.io/docs/reference/config/istio.networking.v1alpha3.html#VirtualService

  2. 断路器https://istio.io/docs/tasks/traffic-management-v1alpha3/circuit-breaking.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