Skip to main content

Command Palette

Search for a command to run...

Istio 尾行记

Updated
2 min read

Istio 一直没有什么像样的更新,Conduit 也迟迟不出来怼,眼看 2017 就要过去,安装试用也不新鲜了,补一篇 Istio 的笔记,算做个收尾了。

Istio 最大的亮点之一,就是使用 Pilot 将集群控制语言翻译成为 Envoy 配置,利用 Sidecar 的方式对服务通信进行控制,下面就是对这一过程的跟踪尝试。

kubectl apply -f install/kubernetes/istio.yaml

cat istio.yaml| grep ^kind

会看到,这里生成了相当多的内容,除去 Deployment、Service 和 ConfigMap 老几样之外,还有当前集群必须的 RBAC 几要素:Service Account、ClusterRole 以及 ClusterRoleBinding。然后就是 Kubernetes 世界里强力扩展的标志:各种 CRD(CustomResourceDefinition) 了。

kubectl apply -f install/kubernetes/addons/

这里会生成一系列的监控用具,包括了 Prometheus、Grafana、ZipKin 以及 ServiceGraph,原则上这些并非必须组件。不过为了监控方便,一般还是会加上。

另外这里的 Prometheus 以及 Grafana 的监控、仪表盘配置都可以保存下来,方便同现有设施进行融合。

istioctl kube-inject -f ...

运行这个命令之前,务必注意几个对 Workload 的要求:

  1. 目前,Pod 对应单一服务的情况才能得到支持。
  2. 服务端口必须命名,[协议]-[后缀] 的方式,后缀部分可以忽略,写一部分可以使用 http, http2, grpc, mongo 以及 redis。如果不进行合理的命名,又没有显示声明这一端口是 UDP 端口,那么就会被当做普通 TCP 端口处理。
  3. Deployment 需要有 App 标签,注意看示例应用的标签方法。
  4. 目前的缺省安装不支持 cluster.local 之外的 Kubernetes 域名。

在安装好 Istio 之后,一般会使用这一命令对服务进行注入(同样也有自动注入的能力),使之称为被 istio 加持的 Service Mesh 成员服务。注入之后的 YAML 会变得比较丰腴:

  • 一组注解
  • 两个 Init
  • 一个同 Pod 容器
  • 两个卷

下面分别讲解一下多出来的这些部分:

Annotation

为 Deployment 和 Pod 加入了同样的注解:

sidecar.istio.io/status: injected-version...,目前理解是,标注了这一部署和 Pod 是否已经被注入,被什么版本注入。

Init 1

使用 Alpine 镜像,设置内核 Dump 模板,以及 ulimit。

Init 2

使用 docker.io/istio/proxy_init:0.4.0 进行初始化,参数为 -p 15001 -u 1337

Sidecar

镜像为: docker.io/istio/proxy_debug:0.4.0

其中定义了大量的服务关系,包括:

  • Istio Pilot
  • Zipkin
  • Mixer
  • 管理端口

  • 内存卷用于存储配置;
  • Secret 卷用于后面的 TLS。

运行

利用 kubectlapply -f,将注入后的 yaml 文件运行起来,接下来就可以使用各个 Pod 来查看刚才注入的内容的行迹了。

列出 Pod:

NAME READY STATUS RESTARTS AGE httpbin-7965799df7-ll75q 2/2 Running 0 53m

通过前面的 yaml 定义,我们知道这个 Pod 的两个容器分别是 httpbinistio-proxy,Istio 强调的是 Sidecar 模式的无侵入管理,因此我们可以认为 httpbin 是没有变化的,Service Mesh 的 Sidecar 功能会体现在 istio-proxy 这一容器中。

初始化

上一节中提到了,使用 proxy_init 进行的初始化(Alpine 部分修改内核参数,就不用多说了),我们可以进入源码,查查他的初始化做了什么。

Dockerfile 中我们看到,这一容器的入口命令为 istio-start.sh,找出这个文件,会看到其中使用这两个参数对 iptables 的 nat 部分做了配置,另外还可以看到,其中加入了 iptables 命令,这里我们可以进行验证:kubectl exec httpbin-7965799df7-ll75q -c istio-proxy sudo iptables-save,输出内容可以这样解读:

  1. 跳过和 Proxy 进程用户一致的用户进程的流量处理;
  2. 跳过 Loopback 流量处理;
  3. 所有流量转发到 15001 端口。

和脚本初始化内容一致。

istio-proxy

启动之后,我们可以使用 kubectl exec -it [httpbin] -c istio-proxy sh 进入 Proxy 容器,执行命令 ps -ef,会发现有两个正在运行的进程:

  • /usr/local/bin/pilot-agent
  • /usr/local/bin/envoy

并且 Envoy 的父进程就是这个 pilot-agent。其运行参数和我们前面注入到 YAML 中的参数一致。

另外还可以查看 /etc/istio/proxy/ 下面的配置文件,可以看出:

  • Envoy 通过 pilot-agent 传递的参数运行
  • 服务发现是通过 Pilot 完成的
  • Envoy 开放了 15000 端口进行管理

验证路由规则

执行 kubectl exec [Pod] -c istio-proxy curl localhost:15000/routes

可以看到 httpbin 的路由如下:

{
    "version_info": "hash_35afd004f717e588",
    "route_config_name": "8000",
    "cluster_name": "rds",
    "route_table_dump": {"name":"8000","virtual_hosts":[{"name":"httpbin.default.svc.cluster.local|http","domains":["httpbi
n:8000","httpbin","httpbin.default:8000","httpbin.default","httpbin.default.svc:8000","httpbin.default.svc","httpbin.defaul
t.svc.cluster:8000","httpbin.default.svc.cluster","httpbin.default.svc.cluster.local:8000","httpbin.default.svc.cluster.loc
al","10.0.34.255:8000","10.0.34.255"],"routes":[{"match":{"prefix":"/"},"route":{"cluster":"out.httpbin.default.svc.cluster
.local|http","timeout":"0s"},"decorator":{"operation":"default-route"}}]}]}
}

新建缺省路由:

apiVersion: config.istio.io/v1alpha2
kind: RouteRule
metadata:
  name: rule-all-http
spec:
  destination:
    name: httpbin
  precedence: 1
  route:
  - labels:
      app: httpbin
    weight: 100

再次查询路由,可以看到其中发生了变化:

{
    "version_info": "hash_146c02ed176ff12b",
    "route_config_name": "8000",
    "cluster_name": "rds",
    "route_table_dump": {"name":"8000","virtual_hosts":[{"name":"httpbin.default.svc.cluster.local|http","domains":["httpbi
n:8000","httpbin","httpbin.default:8000","httpbin.default","httpbin.default.svc:8000","httpbin.default.svc","httpbin.defaul
t.svc.cluster:8000","httpbin.default.svc.cluster","httpbin.default.svc.cluster.local:8000","httpbin.default.svc.cluster.loc
al","10.0.34.255:8000","10.0.34.255"],"routes":[{"match":{"prefix":"/"},"route":{"cluster":"out.httpbin.default.svc.cluster
.local|http|app=httpbin","timeout":"0s"},"decorator":{"operation":"rule-all-http"}}]}]}
}

cluster

kubectl exec [pod] -c istio-proxy curl localhost:15000/routes

可以看到所有对应的服务信息,以及可能存在的断路器信息。

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