前言

在之前的文章中，我们花了大量的篇幅，从记录后端pod真实ip开始说起，然后引入envoy，再解决了各种各样的需求：配置自动重载、流量劫持、sidecar自动注入，到envoy的各种能力：熔断、流控、分流、透明代理、可观测性等等，已经可以支撑起一个完整的服务治理框架了

而今天介绍的istio，正是前面提到的这些所有功能的集大成者，从本文开始，我们将详细介绍istio，并且与之前手搓的功能做一个详细的对比，为大家以后选择服务治理的某个功能提供参考

istio架构

           ┌──────────────┐
           │   istiod     │   ← 控制面
           │ (Pilot+CA)   │
           └──────┬───────┘
                  │ 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 profile=default -y

由于镜像仓库没法直接使用，所以需要一些特殊的方法，具体可以看这篇文章： 快速拉取docker镜像

需要的镜像有：

docker.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=enabled

同之前envoy一样，给namespace打上标签之后，重启服务即可

kubectl rollout restart deploy nginx-test

重启之后sidecar已经注入进去了，我们来观察一下istio注入到底做了什么事情

先describe看看events

Events:
  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

1个initContainer，1个业务container和1个sidecar

其中initContainer：

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
...

和之前envoy中劫持流量的做法一样，istio依然是使用iptables将端口流量导入到代理之中处理

尝试访问一下：

▶ curl 10.22.12.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.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=-

在nginx注入istio-proxy，backend没有注入的时候并没有报错。而一旦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 Sidecar（Envoy）默认的 L7 代理行为冲突，Istio 需要 HTTP/1.1 来支持复杂连接管理问题

改造backend service

如果nginx改造有难度，那也可以尝试改造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 时才会进行深度的协议检查和转换。如果你把这个服务声明为 TCP，Istio 就会将其视为原始字节流进行透传，不再关心它是 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 Header

  • HTTP 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最主要的两个因素，当然还有其他非常重要的区别

小结

本章内容算是一个开胃小菜，成功安装了istio，并且解决了一个非常常见的426问题，至于怎么把之前在envoy的那些最佳实践搬迁到istio，那就是后面的内容了，敬请期待

后记

如果整个namespace都已经有了注入标签istio-injection=enabled，但是某个deployment不想让istio注入

kubectl patch deployment nginx -p '{"spec":{"template":{"metadata":{"annotations":{"sidecar.istio.io/inject":"false"}}}}}'

联系我

• 联系我，做深入的交流

至此，本文结束
在下才疏学浅，有撒汤漏水的，请各位不吝赐教...

背景

应用在运行过程中，开启性能分析（Profiling）通常是诊断性能瓶颈、内存泄漏和线程问题的关键手段。然而，持续开启 Profiling 会带来显著的性能开销（可能达 5%-20%），并可能生成大量数据，影响生产环境稳定性。动态开启 Profiling 允许开发或运维人员按需、实时地启动/停止数据收集，实现以下目标：

1. 降低持续开销：仅在需要时启用，避免长期性能损耗；
2. 精准问题定位：针对特定时段（如流量高峰或故障期间）进行分析；
3. 在线诊断：无需重启应用即可获取生产环境实时性能快照；
4. 灵活控制：可结合监控指标（如 CPU 飙升）自动触发，或在安全审计时手动开启。

通过动态控制，实现了观测能力与系统负载的平衡，保障了关键业务场景的效率和稳定性。

Flameshot

Flameshot 是一个基于 Sidecar 模式运行的轻量级自动性能剖析（Profiling）工具。它通过监控目标进程的资源使用情况（CPU/内存），在达到预设阈值时自动触发底层 Profiler（如 async-profiler ），从而实现无侵入的现场快照采集。

Flameshot 采用 Sidecar 容器 模式部署。它必须与业务主容器（Main Container）运行在同一个 Pod 中，并开启 PID 命名空间共享。

1. 监控 (Monitor)：Flameshot 持续轮询主容器内目标进程的资源水位。
2. 触发 (Trigger)：当满足阈值（如 CPU > 80%）或收到 HTTP API 请求时，触发采集任务。
3. 执行 (Execute)：根据配置的语言类型（目前支持 Java），调用对应的 Profiler 工具 attach 到目标进程。
4. 收集 (Collect)：生成的 Profile 文件（如 .jfr ）存储于共享卷中，随后上传至数据观测中心。

观测云 datakit-operator 从 1.7.0 版本开始支持工具 flameshots，实现动态开启应用 Profiling。

实践

当前在 K8S 环境上部署 JAVA 应用，当 CPU、内存使用率达到 20%（演示方便）则触发 Profiling 数据采集。

前提条件

• 观测云帐号
• K8S 环境

DataKit

DataKit 主要是用来采集数据并上报观测云。

1. 下载 & 安装

wget https://static.guance.com/datakit/datakit.yaml

2. 配置 datakit.yaml

配置 DataWay 数据网关地址

name: ENV_DATAWAY
value: https://openway.guance.com?token=tkn_xxxxx

DataKit 会默认开启主机相关采集器，这里需要追加 pyroscope

name: ENV_DEFAULT_ENABLED_INPUTS
value: cpu,disk,diskio,mem,swap,system,hostobject,net,host_processes,container,pyroscope

3. 启动

调整完配置后，启动 DataKit

root@root:~$ kubectl apply -f datakit.yaml
root@root:~$ kubectl get pods -n datakit
NAME                                READY   STATUS    RESTARTS   AGE
datakit-4zg7q                       1/1     Running   0          14h
datakit-wdtdq                       1/1     Running   0          14h

DataKit Operator

1. 下载

下载最新的 datakit-operator.yaml

wget https://static.guance.com/datakit-operator/datakit-operator.yaml

2. 配置 datakit-operator.yaml

主要调整 jsonconfig 下的 flameshots 内容，参考如下：

apiVersion: v1
kind: ConfigMap
metadata:
  name: datakit-operator-config
  namespace: datakit
data:
  jsonconfig: |-
    {
        "server_listen": "0.0.0.0:9543",
        "log_level":     "info",
        "admission_inject_v2": {
            ...
            "flameshots": [
                {
                    "namespace_selectors": ["default"],
                    "label_selectors":     [],
                    "image": "pubrepo.jiagouyun.com/datakit/flameshot:0.1.1",
                    "envs": {
                        "FLAMESHOT_DATAKIT_ADDR":     "http://datakit-service.datakit.svc:9529/profiling/v1/input",
                        "FLAMESHOT_MONITOR_INTERVAL": "1s",
                        "FLAMESHOT_PROFILING_PATH":   "/flameshot-data",
                        "FLAMESHOT_HTTP_LOCAL_IP":    "{fieldRef:status.podIP}",
                        "FLAMESHOT_HTTP_LOCAL_PORT":  "8089",
                        "FLAMESHOT_SERVICE":          "{fieldRef:metadata.labels['app']}",
                        "POD_NAME":                "{fieldRef:metadata.name}",
                        "POD_NAMESPACE":           "{fieldRef:metadata.namespace}",
                        "NODE_NAME":               "{fieldRef:spec.nodeName}",
                        "FLAMESHOT_TAGS":          "pod_name:$(POD_NAME),pod_namespace:$(POD_NAMESPACE),host:$(NODE_NAME)"
                        
                    },
                    "resources": {
                        "requests": {
                            "cpu":    "100m",
                            "memory": "128Mi"
                        },
                        "limits": {
                           "cpu":    "200m",
                           "memory": "256Mi"
                        }
                    },
                    "processes": "[{\"command\":\"java\",\"duration\":\"60s\",\"events\":\"--all\",\"language\":\"java\",\"jdk_version\":\"-\",\"tags\":[\"env:testing\",\"version:1.0.0\"],\"cpu_usage_percent\":20,\"mem_usage_percent\":20,\"mem_usage_mb\":1024}]"
                }
            ]
        },
        ...
    }

参数说明：

• namespace_selectors： 空间选择，即哪些空间需要开启 flameshots
• env: 配置环境变量信息
• processes： 执行命令，如果为空，则 flameshots 不生效

processes 通用字段说明：

• service (String): 选填，上报到观测中心的服务名称。
• language (String): 目标进程语言。目前支持 java。
• command (String): 匹配进程命令行的正则表达式。
• duration (String): 单次采集时长（例如 30s，1m）。注意：受限于执行超时，建议不超过 5 分钟。
• tags (List): 自定义标签列表，建议包含 env，version 等元信息。
• cpu_usage_percent (Int): CPU 触发阈值 (0-N)。多核环境下数值可能超过 100。
• mem_usage_percent (Int): 内存使用率触发阈值 (0-100)。
• mem_usage_mb (Int): 内存使用量绝对值触发阈值 (MB)。

当前配置 processes 可以实现所有 JAVA 服务，为了实践方便，当 cpu 使用率达到 20% 或内存使用率达到 20% 或内存使用值达到 1024m，则会触发执行 Profiling 操作。

"processes": "[{\"command\":\"java\",\"duration\":\"60s\",\"events\":\"--all\",\"language\":\"java\",\"jdk_version\":\"-\",\"tags\":[\"env:testing\",\"version:1.0.0\"],\"cpu_usage_percent\":20,\"mem_usage_percent\":20,\"mem_usage_mb\":1024}]"

3. 启动

root@root:~$ kubectl apply -f datakit-operator.yaml
root@root:~$ kubectl get pods -n datakit
NAME                                READY   STATUS    RESTARTS   AGE
datakit-4zg7q                       1/1     Running   0          15h
datakit-operator-849f868b78-zbcd9   1/1     Running   0          58s
datakit-wdtdq                       1/1     Running   0          15h

JAVA 应用

1. Yaml 配置

apiVersion: apps/v1
kind: Deployment
metadata:
  name: springboot-server
spec:
  selector:
    matchLabels:
      app: springboot-server
  replicas: 1
  template:
    metadata:
      labels:
        app: springboot-server
    spec:
      containers:
        - image: registry.cn-shenzhen.aliyuncs.com/lr_715377484/springboot-server:flameshots
          name: springboot-server
          imagePullPolicy: IfNotPresent
          ports:
            - containerPort:  8080
              protocol: TCP

          securityContext:
            seccompProfile:
              type: Unconfined

2. 启动应用

root@root:~$  kubectl apply -f springboot-server.yaml
root@root:~$ kubectl get pods
NAME                                READY   STATUS    RESTARTS   AGE
springboot-server-d55fc79dd-48c95   2/2     Running   0          3s

3. 查看 flameshot 执行日志

需要指定 containerName 为 -c datakit-flameshot

root@root:~$ kubectl logs -f springboot-server-d55fc79dd-48c95 -c datakit-flameshot
2026-01-15T03:55:58.090Z        ERROR        flameshot        flameshot/config.go:243        read config file failed, err:open /flameshot/flameshot.conf: no such file or directory
2026-01-15T03:55:58.092Z        INFO        flameshot        flameshot/monitor.go:78        start monitor, interval: 1s
2026-01-15T03:55:58.092Z        INFO        flameshot        flameshot/http.go:77        start http server on 10.187.217.101:8089
2026-01-15T03:55:58.092Z        INFO        flameshot        flameshot/http.go:78        profile start at /v1/profile
2026-01-15T03:55:58.092Z        INFO        flameshot        flameshot/http.go:79        prom http start at /metrics
2026-01-15T03:56:58.093Z        INFO        flameshot        flameshot/monitor.go:102        match: PID=7, name=java or cmd=java -jar app.jar

从启动日志上分析，已经找到了 java 服务，且 PID 为 7，等待触发事件

4. 触发阈值

访问应用

root@root:~$ kubectl exec -it springboot-server-d55fc79dd-48c95  -- /bin/bash 
Defaulted container "springboot-server" out of: springboot-server, datakit-flameshot
springboot-server-d55fc79dd-48c95:/home/app#
springboot-server-d55fc79dd-48c95:/home/app# curl http://localhost:8080/profiling/generator
write success!springboot-server-d55fc79dd-48c95:/home/app# 

再来看看 flameshot 执行日志，已触发了阈值 cpu_avg:36.60 且正常上报数据。

之后恢复了正常，正常之后则不会再产生 Profiling 数据，除非再次触发了阈值。

观测云平台

登录观测云平台，访问「应用性能检测」-「Profling」可以查看到刚刚上报的 Profling 信息

点击列表可以查看 Profling 详细信息，如 CPU 耗时、内存分配情况等，可以更深度的剖析应用代码性能损耗。