istio初探以及解决http-426的问题
在之前的文章中，我们花了大量的篇幅，从记录后端pod真实ip开始说起，然后引入envoy，再解决了各种各样的需求：配置自动重载、流量劫持、sidecar自动注入，到envoy的各种能力：熔断、流控、分流、透明代理、可观测性等等，已经可以支撑起一个完整的服务治理框架了 而今天介绍的istio，正是前面提到的这些所有功能的集大成者，从本文开始，我们将详细介绍istio，并且与之前手搓的功能做一个详细的对比，为大家以后选择服务治理的某个功能提供参考 至于其余istio的资源，我们后面详细介绍 不说废话，先把istio安装上去再说 首先准备好k8s集群，其次下载istio（这一步有可能需要上网） 验证兼容性 开始安装 由于镜像仓库没法直接使用，所以需要一些特殊的方法，具体可以看这篇文章： 快速拉取docker镜像 需要的镜像有： 安装完成： 安装完成，要从哪儿开始呢？ 同之前envoy一样，给namespace打上标签之后，重启服务即可 重启之后sidecar已经注入进去了，我们来观察一下istio注入到底做了什么事情 先describe看看events 1个initContainer，1个业务container和1个sidecar 其中initContainer： 和之前envoy中劫持流量的做法一样，istio依然是使用iptables将端口流量导入到代理之中处理 尝试访问一下： 成功，再次查看istio-proxy日志。空的？为了调试方便，将其打开并且输出至控制台 至此，istio的第一个功能探索完毕，自动注入sidecar container并且完成了流量劫持 当前的架构是左图，现在要前进到右图 其实就是在backend注入istio-proxy，直接重启就好 注入完成，测试一下 在nginx注入istio-proxy，backend没有注入的时候并没有报错。而一旦nginx与backend都注入的时候就会出现Upgrade Required (426)错误，Nginx Sidecar 发现目标（Backend）是一个纯文本服务，它会回退到“透明代理”模式，简单地把 Nginx 发出的流量透传出去 Nginx Sidecar 发现目标也有 Sidecar，它会尝试建立一个高度优化的、基于 mTLS 的隧道（关于mTLS后面会详细介绍）。如果此时 Nginx 发出的请求头（比如缺少 Host 字段，或者使用了 HTTP/1.0）不符合 Envoy 对这种隧道 想要解决这个问题有两种方法 Nginx 的 proxy_pass 默认使用 HTTP/1.0。在 Istio 环境中，HTTP/1.0 不支持长连接（Keep-Alive）以及一些现代的协议协商，这与 Istio Sidecar（Envoy）默认的 L7 代理行为冲突，Istio 需要 HTTP/1.1 来支持复杂连接管理问题 如果nginx改造有难度，那也可以尝试改造backend-service Istio 只有在识别到流量是 HTTP 时才会进行深度的协议检查和转换。如果你把这个服务声明为 TCP，Istio 就会将其视为原始字节流进行透传，不再关心它是 HTTP/1.0 还是 1.1。优点就是彻底解决 426 问题，无需改 Nginx。 这里再简单介绍一下两个协议版本的区别 连接管理（最显著的区别） Host Header 以上是istio必须要求HTTP 1.1最主要的两个因素，当然还有其他非常重要的区别 本章内容算是一个开胃小菜，成功安装了istio，并且解决了一个非常常见的426问题，至于怎么把之前在envoy的那些最佳实践搬迁到istio，那就是后面的内容了，敬请期待 如果整个namespace都已经有了注入标签 至此，本文结束前言
istio架构
┌──────────────┐
│ istiod │ ← 控制面
│ (Pilot+CA) │
└──────┬───────┘
│ xDS (gRPC / TLS)
│
┌────────────┐ │ ┌────────────┐
│ Envoy │◄───┼───►│ Envoy │ ← 数据面
│ (Sidecar) │ │ (Sidecar) │
└─────▲──────┘ └─────▲──────┘
│ iptables │
│ │
App Pod App Pod
istio安装
curl -L https://istio.io/downloadIstio | sh -
cd istio-*
sudo ln -s $PWD/istioctl /usr/local/bin/istioctlistioctl x precheckistioctl install --set profile=default -ydocker.io/istio/pilot:1.28.2
docker.io/istio/proxyv2:1.28.2▶ kubectl -n istio-system get pod
NAME READY STATUS RESTARTS AGE
istio-ingressgateway-865c448856-qs8s2 1/1 Running 0 8s
istiod-86c75775bb-j7qbg 1/1 Running 0 12s
istio的自动注入
kubectl label namespace default istio-injection=enabledkubectl rollout restart deploy nginx-testEvents:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal Scheduled 8s default-scheduler Successfully assigned default/nginx-test-6f855b9bb9-9phsv to wilson
Normal Pulled 8s kubelet Container image "docker.io/istio/proxyv2:1.28.2" already present on machine
Normal Created 8s kubelet Created container: istio-init
Normal Started 8s kubelet Started container istio-init
Normal Pulled 8s kubelet Container image "docker.io/istio/proxyv2:1.28.2" already present on machine
Normal Created 8s kubelet Created container: istio-proxy
Normal Started 8s kubelet Started container istio-proxy
Normal Pulled 6s kubelet Container image "registry.cn-beijing.aliyuncs.com/wilsonchai/nginx:latest" already present on machine
Normal Created 6s kubelet Created container: nginx-test
Normal Started 5s kubelet Started container nginx-test
Init Containers:
istio-init:
Container ID: containerd://2bf56cd37703d82a2a43e94e8c8d683ed66b0afe22bf7148a597d67b89a727a8
Image: docker.io/istio/proxyv2:1.28.2
Image ID: docker.m.daocloud.io/istio/proxyv2@sha256:39065152d6bd3e7fbf6bb04be43c7a8bbd16b5c7181c84e3d78fa164a945ae7f
Port: <none>
Host Port: <none>
Args:
istio-iptables
-p
15001
-z
15006
-u
1337
-m
REDIRECT
-i
*
-x
-b
*
-d
15090,15021,15020
--log_output_level=default:info
...▶ curl 10.22.12.178:30785/test
i am backend in backend-6d76f54494-g6srzkubectl -n istio-system edit cm istio
apiVersion: v1
data:
mesh: |-
accessLogFile: /dev/stdout
...Upgrade Required 426 的问题
▶ kubectl get pod -owide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
backend-5d4d7b598c-f7852 2/2 Running 0 13s 10.244.0.49 wilson <none> <none>
nginx-test-6f855b9bb9-9phsv 2/2 Running 0 58m 10.244.0.48 wilson <none> <none>
▶ curl 10.22.12.178:30785/test
Upgrade Required▶ kubectl logs -f -l app=nginx-test -c istio-proxy
[2026-01-26T07:54:42.977Z] "GET /test HTTP/1.1" 426 - upstream=10.244.0.48:80 duration=6ms route=default
[2026-01-26T07:54:42.978Z] "- - -" 0 - upstream=10.105.148.194:10000 duration=9ms route=-
协议的预期，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;
}
改造backend service
apiVersion: v1
kind: Service
metadata:
name: backend-service
namespace: default
spec:
ports:
- name: tcp-80 # 原为 http-80 改为 tcp-80
port: 10000
protocol: TCP
targetPort: 10000
selector:
app: backend
缺点则是你会失去 Istio 针对该服务的 HTTP 监控指标（如请求数、4xx/5xx 统计）、分布式追踪以及基于路径的路由功能http 1.0 与 http 1.1
特性 HTTP 1.0 HTTP 1.1 连接模型 默认短连接，每次请求新开 TCP 默认持久连接 (Keep-Alive)，复用 TCP Host 头部 可选 (导致无法支持虚拟主机) 必须 (支持一 IP 多域名) 流水线 (Pipelining) 不支持 支持 (但在实际应用中受限) 断点续传 不支持 支持 (通过 Range 头部) 缓存控制 简单 (Expires) 复杂且强大 (Cache-Control, ETag) 默认协议版本 许多旧软件(如 Nginx proxy)的默认值 现代 Web 应用的基石标准 小结
后记
istio-injection=enabled，但是某个deployment不想让istio注入kubectl patch deployment nginx -p '{"spec":{"template":{"metadata":{"annotations":{"sidecar.istio.io/inject":"false"}}}}}'联系我
在下才疏学浅，有撒汤漏水的，请各位不吝赐教...
