本文在鲲鹏920和openEuler，从0开始使用Containerd部署k8s1.30.13+Ks。

1.说明

关于kt

kt是基于kk二次开发的产物，具备kk的所有功能。二开主要为适配信创国产化环境、简化arm部署过程和国产化环境离线部署。支持arm64和amd64架构国产操作系统，已适配芯片+操作系统 如下。

kt新增功能点

• 适配arm架构harbor和支持，部署体验与X86一样简单。

• 离线环境部署增强。常用国际和国产操作系统依赖，内置到安装包中。已适配芯片和操作系统如下

  • ./kt init-os 一条命令完成操作系统依赖安装和初始化操作。
  • CPU：鲲鹏、飞腾、海光、兆芯、intel、amd等。
  • OS：Centos、Rocky Linux、Ubuntu、Debian、银河麒麟V10、麒麟V11、麒麟国防版、麒麟信安、中标麒麟V7、统信UOS、华为欧拉、移动大云、阿里龙蜥、TencenOS等。

• 支持开启防火墙，只暴露30000-32767端口，其他k8s端口添加到节点白名单。

  • ./kt firewall 一条命令自动获取节点信息开白名单和防火墙。

kt版本更新和下载地址

• kt： kt
• 关注我不迷路

2.环境准备

服务器基本信息

<!-- 这是一张图片，ocr 内容为： -->

2.1 上传离线制品

操作系统不需要安装docker,不需要设置selinux,swap等操作，全新的操作系统即可。

将离线制品、配置文件、kt和sh脚本上传至服务器其中一个节点(本文以master为例)，后续在该节点操作创建集群。本文使用kt:3.1.13.1版本

<!-- 这是一张图片，ocr 内容为： -->

2.2 修改配置文件

根据实际服务器信息，配置到生成的config-sample.yaml中

kind: Cluster
metadata:
  name: sample
spec:
  hosts:
  - {name: master, address: 192.168.0.101, internalAddress: 192.168.0.101, user: root, password: "123213", arch: "arm64"}
  - {name: node1, address: 192.168.0.133, internalAddress: 192.168.0.133, user: root, password: "123213", arch: "arm64"}
  - {name: harbor, address: 192.168.0.232, internalAddress: 192.168.0.232, user: root, password: "123213", arch: "arm64"}
  roleGroups:
    etcd:
    - master
    control-plane:
    - master
    worker:
    - node1
    # 如需使用 kt 自动部署镜像仓库，请设置该主机组 （建议仓库与集群分离部署，减少相互影响）
    # 如果需要部署 harbor 并且 containerManager 为 containerd 时，由于部署 harbor 依赖 docker，建议单独节点部署 harbor
    registry:
    - harbor
  controlPlaneEndpoint:
    ## Internal loadbalancer for apiservers 
    internalLoadbalancer: haproxy

    domain: lb.kubesphere.local
    address: ""
    port: 6443
  kubernetes:
    version: v1.30.14
    clusterName: cluster.local
    autoRenewCerts: true
    containerManager: containerd
  etcd:
    type: kubekey
  network:
    plugin: calico
    kubePodsCIDR: 10.233.64.0/18
    kubeServiceCIDR: 10.233.0.0/18
    ## multus support. https://github.com/k8snetworkplumbingwg/multus-cni
    multusCNI:
      enabled: false
  registry:
    type: harbor
    registryMirrors: []
    insecureRegistries: []
    privateRegistry: "dockerhub.kubekey.local"
    namespaceOverride: "kubesphereio"
    auths: # if docker add by `docker login`, if containerd append to `/etc/containerd/config.toml`
      "dockerhub.kubekey.local":
        username: "admin"
        password: Harbor@123 # 此处可自定义，kk3.1.8新特性
        skipTLSVerify: true # Allow contacting registries over HTTPS with failed TLS verification.
        plainHTTP: false # Allow contacting registries over HTTP.
        certsPath: "/etc/docker/certs.d/dockerhub.kubekey.local"
  addons: []

2.3 系统初始化

解压kt-centos.tar.gz文件后执行./kt init-os -f config-sample.yaml 已适配操作系统和架构见1.说明

该命令kt会根据配置文件自动判断操作系统和架构以完成所有节点的初始化配置和依赖安装。

<!-- 这是一张图片，ocr 内容为： -->

3 创建 Harbor私有仓库

3.1 创建镜像仓库

./kt init registry -f config-sample.yaml -a artifact-arm-k8s13014-ks3.4.1.tar.gz

此命令会在harbor节点自动安装docker和docker-compose

<!-- 这是一张图片，ocr 内容为： -->

<!-- 这是一张图片，ocr 内容为： -->

3.2 创建harbor项目

<font style="background-color:rgb(255,245,235);">说明：</font>

<font style="background-color:rgb(255,245,235);">Harbor 管理员账号：</font><font style="background-color:rgb(255,245,235);">admin</font><font style="background-color:rgb(255,245,235);">，密码：</font><font style="background-color:rgb(255,245,235);">Harbor@123</font><font style="background-color:rgb(255,245,235);">。密码同步使用配置文件中的对应password</font>

<font style="background-color:rgb(255,245,235);">harbor 安装文件在 /opt/harbor<font style="background-color:rgb(255,245,235);"> 目录下，可在该目录下对 harbor 进行运维。</font>

创建 Harbor 项目

chmod +x create_project_harbor.sh && ./create_project_harbor.sh

<!-- 这是一张图片，ocr 内容为： -->

4 创建k8s和KubeSphere

./kt create cluster -f config-sample.yaml -a artifact-arm-k8s13014-ks3.4.1.tar.gz

此命令kt会自动将离线制品中的镜像推送到harbor 私有仓库

执行后会有如下提示,输入yes/y继续执行

<!-- 这是一张图片，ocr 内容为： -->

等待一段时间，直至出现熟悉的等待安装完成的小箭头>>--->

<!-- 这是一张图片，ocr 内容为： -->

期间可以另开一个窗口用以下命令查看部署日志

kubectl logs -n kubesphere-system $(kubectl get pod -n kubesphere-system -l 'app in (ks-install, ks-installer)' -o jsonpath='{.items[0].metadata.name}') -f

继续等待一段时间，可以看到在内核3.10.0上面使用containerd成功部署了1.30.14版本+ks

<!-- 这是一张图片，ocr 内容为： -->

5 验证

<!-- 这是一张图片，ocr 内容为： -->

ps:default-http-backend那个pod显示：ImagePullBackOff，没啥用，不需要理会。

登录页面

<!-- 这是一张图片，ocr 内容为： -->

集群管理

<!-- 这是一张图片，ocr 内容为： -->

集群节点

<!-- 这是一张图片，ocr 内容为： -->

监控告警

<!-- 这是一张图片，ocr 内容为： -->

集群信息

<!-- 这是一张图片，ocr 内容为： -->

节点情况

<!-- 这是一张图片，ocr 内容为： -->

配置文件默认只安装了监控，如果需要安装其他组件，可以自行在自定义资源中开启

<!-- 这是一张图片，ocr 内容为： -->

前言

在之前的文章中，我们花了大量的篇幅，从记录后端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 耗时、内存分配情况等，可以更深度的剖析应用代码性能损耗。

前言

本节详细聊一下基于envoy的可观测性

日志

首先是日志，配置日志的方式也很简单

static_resources:
  listeners:
    - name: ingress_listener
      address:
        socket_address:
          address: 0.0.0.0
          port_value: 10000
      filter_chains:
        - filters:
            - name: envoy.filters.network.http_connection_manager
              typed_config:
                "@type": type.googleapis.com/envoy.extensions.filters.network.http_connection_manager.v3.HttpConnectionManager
                stat_prefix: ingress_http
                ...
                access_log:
                - name: envoy.access_loggers.stdout
                  typed_config:
                    "@type": type.googleapis.com/envoy.extensions.access_loggers.stream.v3.StdoutAccessLog
                    log_format:
                      text_format: "[%START_TIME%] \"%REQ(:METHOD)% %REQ(X-ENVOY-ORIGINAL-PATH?:PATH)% %PROTOCOL%\" %RESPONSE_CODE% %BYTES_SENT% %DURATION% %REQ(X-REQUEST-ID)% \"%REQ(USER-AGENT)%\" \"%REQ(X-FORWARDED-FOR)%\" %UPSTREAM_HOST% %UPSTREAM_CLUSTER% %RESPONSE_FLAGS%\n"

• 该配置是将日志输出在控制台，也可以直接输出为文件，然后通过工具采集走path: /var/log/envoy/access.log
• 也可以直接将日志输出至kafka，并且按比例采集、只采集4xx、5xx等都可以配置，这里就不在赘述了

admin管理页面

envoy有默认的admin页面，方便查看统计信息、打开某些功能的开关等

admin:
  address:
    socket_address:
      address: 0.0.0.0
      port_value: 9901

打开9901页面：

可以查看相关的统计信息、也可以打开某些开关，功能还是很丰富的

merics接入prometheus

打开了admin之后，就默认提供了相关的prometheus stats http://10.105.148.194:9901/stats/prometheus

这时只需在k8s集群外弄一个prometheus，并且采集该envoy即可

prometheus.yml

global:
  scrape_interval: 5s
  evaluation_interval: 5s

rule_files:
  - /etc/prometheus/*.rules

scrape_configs:
  - job_name: 'prometheus'
    static_configs:
    - targets: ['localhost:9090']

  - job_name: "envoy"
    metrics_path: /stats/prometheus
    static_configs:
    - targets: ["10.105.148.194:9901"]

docker run -d --name prometheus \
  -p 9090:9090 \
  -v ./prometheus.yml:/etc/prometheus/prometheus.yml \
  -v /usr/share/zoneinfo/Asia/Shanghai:/etc/localtime \
  registry.cn-beijing.aliyuncs.com/wilsonchai/prometheus:v3.5.0

traces接入jaeger

jaeger的安装可以参考这里： opentelemetry全链路初探--埋点与jaeger

jaeger启动之后，改造一下envoy的配置，这里要特别注意，不同版本的配置不一样，我这里envoy的版本是：v1.32

static_resources:
  listeners:
    - name: ingress_listener
      filter_chains:
        - filters:
            - name: envoy.filters.network.http_connection_manager
              typed_config:
                ...

                tracing:

                  provider:
                    name: envoy.tracers.opentelemetry
                    typed_config:
                      "@type": type.googleapis.com/envoy.config.trace.v3.OpenTelemetryConfig
                      service_name: envoy-proxy
                      grpc_service:
                        envoy_grpc:
                          cluster_name: jaeger_otlp_collector
                ...

  clusters:
    ...
    - name: jaeger_otlp_collector
      type: LOGICAL_DNS
      connect_timeout: 5s
      lb_policy: ROUND_ROBIN
      http2_protocol_options: {}

      load_assignment:
        cluster_name: jaeger_otlp_collector
        endpoints:
        - lb_endpoints:
          - endpoint:
              address:
                socket_address:
                  address: 10.22.12.178
                  port_value: 4317
    ...

修改完成之后重启下envoy

jaeger成功接收到了来自envoy的trace

由于只在envoy配置了trace，没有和后端服务联动，所有只显示了envoy这一段的trace信息，如果要联动后端，可以参考这个系列的文章： 全链路监控配置

小结

至此，logs、metrics、traces三大可观测的指标建设完成，envoy可观测性的建设也结束了

联系我

• 联系我，做深入的交流

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

运维大模型训练数据集：从采集到落地的实操手册

引言

智能运维（AIOPS）的核心竞争力，源于大模型对运维场景的深度适配 —— 而这一切的前提，是具备高质量、场景化的训练数据集。运维数据天然存在 “分散、敏感、非结构化” 的特点，通用数据集无法满足故障诊断、流程自动化等核心需求。本文跳出传统文档框架，以 “实操流程 + 工具矩阵 + 避坑指南” 的形式，拆解运维领域数据集构建的全链路，助力快速落地可用数据集。

一、数据来源：双轨采集（真实 + 合成）

1. 真实数据采集清单（脱敏为前提）

数据类别主流来源必采信息点采集工具推荐故障工单Jira/ServiceNow/ 钉工牌故障现象、排查步骤、根因、解决方案、耗时接口同步 + 定时爬虫监控告警Prometheus/Zabbix/Grafana异常指标、触发阈值、时间、关联资源PromQL 查询 + Logstash 同步系统日志ELK/Splunk/Fluentd错误堆栈、日志级别、时间戳、资源 IDFilebeat 采集 + Kafka 缓存运维知识库Confluence/Wiki/ 内部文档SOP 流程、故障复盘、配置规范文档导出 + PDF 解析工具专家经验企业微信 / 钉钉运维群 / Slack故障讨论、临时方案、踩坑记录聊天记录导出 + 关键词过滤自动化脚本GitHub/GitLab/Gitee修复脚本、配置模板、执行逻辑Git API 批量拉取

1. 合成数据补充方案（填补稀缺场景）

• 故障注入生成：用 Chaos Mesh（K8s 环境）、Chaos Blade（多云环境）注入常见故障（网络延迟、磁盘满、CPU 飙升），录制完整处理流程；
• 模板化生成：基于 “故障类型 - 环境 - 现象 - 根因 - 方案” 五要素模板，批量生成标准化案例（如 “VM 环境 + MySQL + 连接超时 + 最大连接数不足 + 调优参数”）；
• 大模型辅助生成：输入 Prompt（例：“生成 K8s 环境下 Pod CrashLoopBackOff + 内存泄漏的故障日志与处理步骤”），通过 GLM4.5/DeepSeek 生成数据后，需经运维专家校验技术准确性。

二、数据处理三步法：合规→标准→去噪

1. 脱敏合规：规避数据安全风险

• 核心操作：

  • 替换类：IP / 域名 / 设备 ID→[MASKED] 占位符（例：172.16.0.5→[IP_MASKED]）；
  • 删除类：密钥、密码、订单号等敏感信息直接剔除；
  • 模糊化：业务数据（如用户量、峰值流量）按区间处理（例：12300 用户→1.2 万 + 用户）。
• 工具选型：IBM Presidio（多语言敏感信息识别）、AWS Glue DataBrew（可视化操作）、自定义正则（快速适配特定格式）。

1. 数据标准化：统一格式与术语

• 日志结构化：非结构化日志→JSON 格式（固定字段：time level resource content）；
• 时间统一：所有数据转为 UTC 时间戳（避免时区混乱）；
• 术语词典：建立运维术语映射表（例：“Pod 重启”=“容器实例重启”、“磁盘满”=“存储资源耗尽”）。

1. 噪声过滤：保留高价值数据

• 剔除无效信息：闲聊记录、重复日志、测试告警、描述模糊的工单；
• 去重处理：通过 “故障现象 + 根因” 字段去重，避免重复训练；
• 质量筛选：仅保留 “现象清晰 + 根因明确 + 方案可执行” 的案例（低质量数据占比≤5%）。

三、标注结构化：让数据 “可被模型理解”

1. 核心标注维度（简化版）

标注维度标注要求示例故障层级三级分类（大类 - 中类 - 小类）应用服务故障→连接故障→Redis 连接超时根因与证据主 / 次根因 + 对应依据主根因：Redis 最大连接数不足；证据：日志 “maxclients reached”执行步骤含工具、命令、验证环节1. redis-cli info clients 查连接数；2. 修改 redis.conf；3. 重启 Redis；4. 验证服务连通性环境特征部署环境 + 核心组件K8s 1.25 + Redis 6.2 + 云服务器 ECS

1. 标注流程与质量控制

2. 分工：资深运维→标注复杂案例（复合故障 / 罕见故障）；初级运维→基础分类标注；
3. 校验：交叉标注 15% 案例，Cohen's Kappa 系数≥0.8 视为合格；
4. 工具：优先选 Label Studio（开源免费 + 支持多类型数据），高精度需求可选 Prodigy。

四、数据增强：3 种方式提升模型鲁棒性

1. 文本层面增强

• 同义替换：“查看日志”→“检索日志输出”“查看日志信息”；
• 句式转换：主动句 “运维人员重启服务”→被动句 “服务已被重启”→疑问句 “是否需要重启服务？”；
• 多语言适配：核心案例翻译为中英双语（适配国际化团队）。

1. 场景层面增强

• 复合故障组合：“网络抖动 + 数据库连接池耗尽”“CPU 过载 + 日志磁盘满”；
• 跨环境适配：同一故障（如 MySQL 慢查询）生成 K8s/VM/Serverless 三种环境的案例；
• 步骤变体：同一根因提供多种解决方案（如重启服务可通过命令行 / 可视化平台 / 自动化脚本实现）。

1. 负样本构造

• 误导性案例：“磁盘使用率 90%” 但根因为 “内存泄漏”；“HTTP 502 错误” 但根因为 “缓存失效”；
• 无效步骤案例：根因为 “网络分区”，却包含 “修改数据库配置” 等无关操作。

五、数据集落地：划分、存储与版本管理

1. 数据集划分（按比例 + 场景覆盖）

• 训练集（70%）：覆盖 80% 以上常见故障类型（如服务不可用、配置错误、资源过载）；
• 验证集（15%）：含中等复杂度案例，用于调优模型超参数；
• 测试集（15%）：聚焦边缘场景（罕见故障、复合故障、极端环境），评估模型泛化能力。

1. 存储格式选型

数据类型推荐格式优势适用场景结构化数据Parquet/JSON压缩率高、查询快故障案例、标注数据非结构化数据Markdown保留上下文、易读取复盘报告、SOP 文档大文件数据二进制 + 索引存储高效、检索便捷日志片段、脚本文件

1. 版本管理实操

• 工具：优先 DVC（数据版本控制专用，支持大文件）；关联代码仓库则用 Git LFS；
• 版本规范：v 主版本。次版本。修订号（例：v1.2.0，主版本 = 结构变更，次版本 = 新增案例，修订号 = 小幅优化）；
• 变更记录：每版需记录 “新增案例数、优化点、负责人、更新时间”。

六、质量评估：3 类核心指标 + 避坑指南

1. 自动化质检指标

指标类型具体要求校验工具完整性必填字段（如根因、步骤）缺失率≤0.5%Great Expectations一致性术语统一、时间格式统一Python 正则 + SQL 查询准确性命令语法正确、脱敏格式规范Pydantic + 自定义校验脚本逻辑性步骤与根因匹配、现象与日志一致规则引擎 + 人工抽样

1. 常见坑与规避方案

• 坑 1：敏感信息脱敏不彻底→规避：先人工审核 5% 数据，再用工具批量脱敏；
• 坑 2：标注规则不一致→规避：先制定标注手册，交叉标注分歧案例统一评审；
• 坑 3：数据场景单一导致模型过拟合→规避：测试集中边缘案例占比不低于 30%；
• 坑 4：数据集更新后模型效果下降→规避：每次更新后做 A/B 测试，对比准确率 / 召回率。

七、工具矩阵速查表（按环节分类）

构建环节工具名称核心特点适用规模数据采集Apache NiFi多源接入、可视化流程中大型企业数据采集Logstash+Filebeat轻量高效、易部署中小型团队数据脱敏IBM Presidio多语言支持、识别精准全规模数据标注Label Studio开源免费、功能全面全规模数据增强NLPAug文本增强、自定义规则全规模版本管理DVC大文件支持、版本追溯中大型企业质量检查Great Expectations规则灵活、自动化校验全规模存储管理MinIO对象存储、高可用中大型团队存储管理MySQL结构化存储、查询便捷小型团队

八、实战案例片段（结构化示例）

plaintext

案例ID：OPS-2025-0892
时间：2025-05-12T09:45:00Z
环境：Kubernetes 1.28 + Redis 7.0 + 阿里云ECS
故障类型：中间件故障→缓存服务故障→Redis连接超时
现象：
1. 订单服务接口响应时间从200ms升至3s+；
2. 监控告警：Redis连接数达1000（阈值800）；
日志片段：
- level=error msg="Redis connection timeout: dial tcp [IP_MASKED]:6379: i/o timeout"
- level=warning msg="maxclients limit reached, closing connection"
根因：
主根因：Redis配置maxclients=1000，未随业务扩容；
次根因：订单服务未配置连接池复用，连接数激增；
处理步骤：
1. 执行redis-cli -h [IP_MASKED] -p 6379 config set maxclients 2000 临时调整；
2. 修改Redis配置文件redis.conf，持久化maxclients参数；
3. 优化订单服务连接池配置（maxIdle=50，maxActive=200）；
4. 重启订单服务，通过jmeter压测验证接口响应时间恢复至250ms内；
影响范围：
受影响服务：订单服务、购物车服务；
故障时长：12分钟；
受影响用户：约8000人；

结语

运维数据集的构建，本质是 “运维经验的数字化沉淀”。无需追求 “大而全”，而应聚焦 “准而精”—— 先覆盖 80% 的常见故障，再通过持续迭代补充边缘场景。核心是建立 “数据采集 - 处理 - 标注 - 增强 - 评估” 的闭环，让数据集随运维场景、技术栈的变化不断优化，最终成为大模型赋能 AIOPS 的核心燃料。