在之前的文章中我们花了大量的篇幅从记录后端pod真实ip开始说起然后引入envoy再解决了各种各样的需求配置自动重载、流量劫持、sidecar自动注入到envoy的各种能力熔断、流控、分流、透明代理、可观测性等等已经可以支撑起一个完整的服务治理框架了而今天介绍的istio正是前面提到的这些所有功能的集大成者从本文开始我们将详细介绍istio并且与之前手搓的功能做一个详细的对比为大家以后选择服务治理的某个功能提供参考istio架构┌──────────────┐│ istiod │ ← 控制面│ (PilotCA) │└──────┬───────┘│ xDS (gRPC / TLS)│┌────────────┐ │ ┌────────────┐│ Envoy │?───┼───?│ Envoy │ ← 数据面│ (Sidecar) │ │ (Sidecar) │└─────▲──────┘ └─────▲──────┘│ iptables ││ │App Pod App Pod数据面就是之前一直在研究的envoy包括4/7代理、熔断、限流、可观测性等等envoy就是执行由控制面下发的配置控制面istiod主要的职责将配置下发到每一个envoy去。由于istio中配置以crd的形式成为了k8s的资源所以要不断的监听k8s apiserver将资源的变化翻译成envoy看得懂的配置并且下发到envoy去至于其余istio的资源我们后面详细介绍istio安装不说废话先把istio安装上去再说首先准备好k8s集群其次下载istio这一步有可能需要上网curl -L https://istio.io/downloadIstio | sh -cd istio-*sudo ln -s $PWD/istioctl /usr/local/bin/istioctl验证兼容性istioctl x precheck开始安装istioctl install --set profiledefault -y由于镜像仓库没法直接使用所以需要一些特殊的方法具体可以看这篇文章 快速拉取docker镜像需要的镜像有docker.io/istio/pilot:1.28.2docker.io/istio/proxyv2:1.28.2安装完成? kubectl -n istio-system get podNAME READY STATUS RESTARTS AGEistio-ingressgateway-865c448856-qs8s2 1/1 Running 0 8sistiod-86c75775bb-j7qbg 1/1 Running 0 12s安装完成要从哪儿开始呢istio的自动注入kubectl label namespace default istio-injectionenabled同之前envoy一样给namespace打上标签之后重启服务即可kubectl rollout restart deploy nginx-test重启之后sidecar已经注入进去了我们来观察一下istio注入到底做了什么事情先describe看看eventsEvents:Type Reason Age From Message---- ------ ---- ---- -------Normal Scheduled 8s default-scheduler Successfully assigned default/nginx-test-6f855b9bb9-9phsv to wilsonNormal Pulled 8s kubelet Container image docker.io/istio/proxyv2:1.28.2 already present on machineNormal Created 8s kubelet Created container: istio-initNormal Started 8s kubelet Started container istio-initNormal Pulled 8s kubelet Container image docker.io/istio/proxyv2:1.28.2 already present on machineNormal Created 8s kubelet Created container: istio-proxyNormal Started 8s kubelet Started container istio-proxyNormal Pulled 6s kubelet Container image registry.cn-beijing.aliyuncs.com/wilsonchai/nginx:latest already present on machineNormal Created 6s kubelet Created container: nginx-testNormal Started 5s kubelet Started container nginx-test1个initContainer1个业务container和1个sidecar其中initContainerInit Containers:istio-init:Container ID: containerd://2bf56cd37703d82a2a43e94e8c8d683ed66b0afe22bf7148a597d67b89a727a8Image: docker.io/istio/proxyv2:1.28.2Image ID: docker.m.daocloud.io/istio/proxyv2sha256:39065152d6bd3e7fbf6bb04be43c7a8bbd16b5c7181c84e3d78fa164a945ae7fPort:Host Port:Args:istio-iptables-p15001-z15006-u1337-mREDIRECT-i*-x-b*-d15090,15021,15020--log_output_leveldefault:info...和之前envoy中劫持流量的做法一样istio依然是使用iptables将端口流量导入到代理之中处理尝试访问一下? curl 10.22.12.178:30785/testi am backend in backend-6d76f54494-g6srz成功再次查看istio-proxy日志。空的为了调试方便将其打开并且输出至控制台kubectl -n istio-system edit cm istioapiVersion: v1data:mesh: |-accessLogFile: /dev/stdout...至此istio的第一个功能探索完毕自动注入sidecar container并且完成了流量劫持Upgrade Required 426 的问题当前的架构是左图现在要前进到右图watermarked-istio_1其实就是在backend注入istio-proxy直接重启就好? kubectl get pod -owideNAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATESbackend-5d4d7b598c-f7852 2/2 Running 0 13s 10.244.0.49 wilsonnginx-test-6f855b9bb9-9phsv 2/2 Running 0 58m 10.244.0.48 wilson注入完成测试一下? curl 10.22.12.178:30785/testUpgrade Required? kubectl logs -f -l appnginx-test -c istio-proxy[2026-01-26T07:54:42.977Z] GET /test HTTP/1.1 426 - upstream10.244.0.48:80 duration6ms routedefault[2026-01-26T07:54:42.978Z] - - - 0 - upstream10.105.148.194:10000 duration9ms route-在nginx注入istio-proxybackend没有注入的时候并没有报错。而一旦nginx与backend都注入的时候就会出现Upgrade Required (426)错误Nginx Sidecar 发现目标Backend是一个纯文本服务它会回退到“透明代理”模式简单地把 Nginx 发出的流量透传出去Nginx Sidecar 发现目标也有 Sidecar它会尝试建立一个高度优化的、基于 mTLS 的隧道关于mTLS后面会详细介绍。如果此时 Nginx 发出的请求头比如缺少 Host 字段或者使用了 HTTP/1.0不符合 Envoy 对这种隧道协议的预期Envoy 可能会向 Nginx 发送一个特殊的响应或者 Nginx 在尝试通过这种隧道通信时因为某些 Header 冲突如 Connection: close自发产生了 426 错误想要解决这个问题有两种方法改造nginx中加入标记location /test {proxy_http_version 1.1; # 必须添加这一行proxy_set_header Host $host; # 这一行也是必须的proxy_pass http://backend_ups;}Nginx 的 proxy_pass 默认使用 HTTP/1.0。在 Istio 环境中HTTP/1.0 不支持长连接Keep-Alive以及一些现代的协议协商这与 Istio SidecarEnvoy默认的 L7 代理行为冲突Istio 需要 HTTP/1.1 来支持复杂连接管理问题改造backend service如果nginx改造有难度那也可以尝试改造backend-serviceapiVersion: v1kind: Servicemetadata:name: backend-servicenamespace: defaultspec:ports:- name: tcp-80 # 原为 http-80 改为 tcp-80port: 10000protocol: TCPtargetPort: 10000selector:app: backendIstio 只有在识别到流量是 HTTP 时才会进行深度的协议检查和转换。如果你把这个服务声明为 TCPIstio 就会将其视为原始字节流进行透传不再关心它是 HTTP/1.0 还是 1.1。优点就是彻底解决 426 问题无需改 Nginx。缺点则是你会失去 Istio 针对该服务的 HTTP 监控指标如请求数、4xx/5xx 统计、分布式追踪以及基于路径的路由功能http 1.0 与 http 1.1这里再简单介绍一下两个协议版本的区别连接管理最显著的区别HTTP 1.0短连接 (Short-lived)默认情况下客户端每发起一个请求都要与服务器建立一次 TCP 三次握手。请求结束并收到响应后TCP 连接立即关闭。如果页面有 10 张图片浏览器就要建立 10 次 TCP 连接。这带来了极高的延迟和资源开销。HTTP 1.1持久连接 (Persistent Connection / Keep-Alive)。默认开启 Connection: keep-alive。一个 TCP 连接可以被多个请求复用。只有在明确声明 Connection: close 或连接超时后才会关闭。在 Istio 中 Envoy 极度依赖持久连接来维持高性能的 Sidecar 间隧道。HTTP 1.0 的频繁断开会让 Envoy 感到“压力山大”甚至认为这是一种非标准的协议行为。Host HeaderHTTP 1.0人们认为一个 IP 对应一个网站所以请求头里不需要带域名信息。HTTP 1.1随着虚拟主机一个 IP 跑多个网站的流行HTTP 1.1 规定请求头必须包含 Host 字段。在 K8s/Istio 中 Istio 的路由决策、Service 的匹配完全依赖 Host 头。这也是为什么 Nginx 使用 HTTP 1.0 转发时如果不手动补全 Host 头后端往往会返回 404 或协议错误。以上是istio必须要求HTTP 1.1最主要的两个因素当然还有其他非常重要的区别特性 HTTP 1.0 HTTP 1.1连接模型 默认短连接每次请求新开 TCP 默认持久连接 (Keep-Alive)复用 TCPHost 头部 可选 (导致无法支持虚拟主机) 必须 (支持一 IP 多域名)流水线 (Pipelining) 不支持 支持 (但在实际应用中受限)断点续传 不支持 支持 (通过 Range 头部)缓存控制 简单 (Expires) 复杂且强大 (Cache-Control, ETag)默认协议版本 许多旧软件(如 Nginx proxy)的默认值 现代 Web 应用的基石标准小结本章内容算是一个开胃小菜成功安装了istio并且解决了一个非常常见的426问题至于怎么把之前在envoy的那些最佳实践搬迁到istio那就是后面的内容了敬请期待后记如果整个namespace都已经有了注入标签istio-injectionenabled但是某个deployment不想让istio注入kubectl patch deployment nginx -p {spec:{template:{metadata:{annotations:{sidecar.istio.io/inject:false}}}}}司秸鼐衫