核心内容摘要
揭秘“熟女黑料51吃瓜”：岁月沉淀的魅力与不为人知的精彩
前言在之前的文章中我们花了大量的篇幅从记录后端pod真实ip开始说起然后引入envoy再解决了各种各样的需求配置自动重载、流量劫持、sidecar自动注入到envoy的各种能力熔断、流控、分流、透明代理、可观测性等等已经可以支撑起一个完整的服务治理框架了而今天介绍的istio正是前面提到的这些所有功能的集大成者从本文开始我们将详细介绍istio并且与之前手搓的功能做一个详细的对比为大家以后选择服务治理的某个功能提供参考istio架构/* by
hk - online tools website :
hk/zh/imagetojpg.html */ ┌──────────────┐ │ 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这一步有可能需要上网/* by
hk - online tools website :
hk/zh/imagetojpg.html */ 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.
2
2 docker.io/istio/proxyv2:
1.
2
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-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-6f855b9bb
phsv to wilson Normal Pulled 8s kubelet Container image docker.io/istio/proxyv2:
1.
2
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.
2
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-test1个initContainer1个业务container和1个sidecar其中initContainerInit Containers: istio-init: Container ID: containerd://2bf56cd37703d82a2a43e94e8c8d683ed66b0afe22bf7148a597d67b89a727a8 Image: docker.io/istio/proxyv2:
1.
2
2 Image ID: docker.m.daocloud.io/istio/proxyv2sha256: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_leveldefault:info ...和之前envoy中劫持流量的做法一样istio依然是使用iptables将端口流量导入到代理之中处理尝试访问一下▶ curl
10.
22.
1
178:30785/test i am backend in backend-6d76f54494-g6srz成功再次查看istio-proxy日志。
空的为了调试方便将其打开并且输出至控制台kubectl -n istio-system edit cm istio apiVersion: v1 data: mesh: |- accessLogFile: /dev/stdout ...至此istio的第一个功能探索完毕自动注入sidecar container并且完成了流量劫持Upgrade Required 426 的问题当前的架构是左图现在要前进到右图其实就是在backend注入istio-proxy直接重启就好▶ 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.
49 wilson none none nginx-test-6f855b9bb
phsv 2/2 Running 0 58m
10.
244.
48 wilson none none注入完成测试一下▶ curl
10.
22.
1
178:30785/test Upgrade Required▶ kubectl logs -f -l appnginx-test -c istio-proxy [
T07:54:
4
977Z] GET /test HTTP/
1 426 - upstream
10.
244.
48:80 duration6ms routedefault [
T07:54:
4
978Z] - - - 0 - upstream
10.
105.
1
194:10000 duration9ms route-在nginx注入istio-proxybackend没有注入的时候并没有报错。
而一旦nginx与backend都注入的时候就会出现Upgrade Required (
错误Nginx Sidecar 发现目标Backend是一个纯文本服务它会回退到“透明代理”模式简单地把 Nginx 发出的流量透传出去Nginx Sidecar 发现目标也有 Sidecar它会尝试建立一个高度优化的、基于 mTLS 的隧道关于mTLS后面会详细介绍。
如果此时 Nginx 发出的请求头比如缺少 Host 字段或者使用了 HTTP/
0不符合 Envoy 对这种隧道协议的预期Envoy 可能会向 Nginx 发送一个特殊的响应或者 Nginx 在尝试通过这种隧道通信时因为某些 Header 冲突如 Connection: close自发产生了 426 错误想要解决这个问题有两种方法改造nginx中加入标记location /test { proxy_http_version
1; # 必须添加这一行 proxy_set_header Host $host; # 这一行也是必须的 proxy_pass http://backend_ups; }Nginx 的 proxy_pass 默认使用 HTTP/
0。
在 Istio 环境中HTTP/
0 不支持长连接Keep-Alive以及一些现代的协议协商这与 Istio SidecarEnvoy默认的 L7 代理行为冲突Istio 需要 HTTP/
1 来支持复杂连接管理问题改造backend service如果nginx改造有难度那也可以尝试改造backend-serviceapiVersion: 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: backendIstio 只有在识别到流量是 HTTP 时才会进行深度的协议检查和转换。
如果你把这个服务声明为 TCPIstio 就会将其视为原始字节流进行透传不再关心它是 HTTP/
0 还是
1。
优点就是彻底解决 426 问题无需改 Nginx。
缺点则是你会失去 Istio 针对该服务的 HTTP 监控指标如请求数、4xx/5xx 统计、分布式追踪以及基于路径的路由功能http
0 与 http
1这里再简单介绍一下两个协议版本的区别连接管理最显著的区别HTTP
0短连接 (Short-lived)默认情况下客户端每发起一个请求都要与服务器建立一次 TCP 三次握手。
请求结束并收到响应后TCP 连接立即关闭。
如果页面有 10 张图片浏览器就要建立 10 次 TCP 连接。
这带来了极高的延迟和资源开销。
HTTP
1持久连接 (Persistent Connection / Keep-Alive)。
默认开启 Connection: keep-alive。
一个 TCP 连接可以被多个请求复用。
只有在明确声明 Connection: close 或连接超时后才会关闭。
在 Istio 中 Envoy 极度依赖持久连接来维持高性能的 Sidecar 间隧道。
HTTP
0 的频繁断开会让 Envoy 感到“压力山大”甚至认为这是一种非标准的协议行为。
Host HeaderHTTP
0人们认为一个 IP 对应一个网站所以请求头里不需要带域名信息。
HTTP
1随着虚拟主机一个 IP 跑多个网站的流行HTTP
1 规定请求头必须包含 Host 字段。
在 K8s/Istio 中 Istio 的路由决策、Service 的匹配完全依赖 Host 头。
这也是为什么 Nginx 使用 HTTP
0 转发时如果不手动补全 Host 头后端往往会返回 404 或协议错误。
以上是istio必须要求HTTP