📚 课程目录第4章数据采集与接入

4. 拓扑数据采集与导入：从Kubernetes、Service Mesh、DNS、CMDB等源采集拓扑数据的方法

IDP网络拓扑的构建质量直接取决于数据源的覆盖度与采集精度。单一数据源（如仅依赖Kubernetes）只能提供Pod与Service的静态关系，无法反映服务网格中的流量路径、DNS解析链路或CMDB中的业务归属。本章详细阐述从Kubernetes、Service Mesh、DNS、CMDB四大核心源采集拓扑数据的方法，并给出统一的导入与去重策略。

4.1 数据源分类与采集策略

不同数据源提供不同维度的拓扑信息，采集频率与接口协议也各不相同。下表对比了四大数据源的核心特征：

数据源	拓扑维度	采集接口	推荐采集频率	数据量级参考
Kubernetes	Pod、Service、Ingress、Endpoint	Kubernetes API (List/Watch)	实时（Watch） + 每30s全量	中（千级节点）
Service Mesh	服务间调用关系、延迟、错误率	Istio/Envoy xDS、Prometheus	每15s（指标） / 每60s（拓扑）	大（万级边）
DNS	域名解析记录、别名、CNAME链	CoreDNS API、DNS日志	每5min（增量） / 每日（全量）	小（百级记录）
CMDB	业务系统、应用分组、负责人	CMDB REST API / 数据库视图	每30min（变更驱动）	中（千级CI项）

采集策略建议：Kubernetes与Service Mesh数据变化频繁，应采用事件驱动+定时补偿的双重机制；DNS与CMDB数据相对稳定，以定时轮询为主，配合变更通知（Webhook）实现准实时更新。

4.2 Kubernetes数据采集

Kubernetes是IDP网络拓扑的基础设施层骨架。采集目标包括：Pod（IP、标签、所属Namespace）、Service（ClusterIP、Selector、Port）、Ingress（域名、后端Service）、Endpoint（Pod IP与端口映射）。

推荐使用Informer机制（基于List+Watch）实现低延迟采集，避免频繁全量拉取。核心代码片段如下：

// 使用 client-go 的 Informer 监听 Pod 变化
factory := informers.NewSharedInformerFactory(clientset, 30*time.Second)
podInformer := factory.Core().V1().Pods().Informer()

podInformer.AddEventHandler(cache.ResourceEventHandlerFuncs{
    AddFunc: func(obj interface{}) {
        pod := obj.(*v1.Pod)
        // 提取 Pod IP、Labels、OwnerReferences
        // 写入拓扑数据管道
        topologyPipeline <- &TopologyNode{
            ID:        string(pod.UID),
            IP:        pod.Status.PodIP,
            Labels:    pod.Labels,
            Namespace: pod.Namespace,
        }
    },
    UpdateFunc: func(old, new interface{}) {
        // 处理 IP 变化、标签更新
    },
    DeleteFunc: func(obj interface{}) {
        // 标记节点下线
    },
})

factory.Start(stopCh)
factory.WaitForCacheSync(stopCh)

  关键字段映射：采集到的Pod数据需转换为统一的拓扑节点模型。建议保留UID作为唯一标识，PodIP作为网络地址，Labels用于后续与CMDB的关联匹配。

4.3 Service Mesh数据采集

Service Mesh（以Istio为例）提供服务间调用关系，是拓扑中“边”的主要来源。采集方式分为两类：

控制面采集：通过Pilot/istiod的xDS接口获取服务注册信息与路由规则，得到服务间的静态依赖关系。
数据面采集：通过Envoy Sidecar暴露的Prometheus指标（如istio_requests_total），聚合出动态调用拓扑，包含请求量、成功率、延迟百分位。

推荐使用Kiali架构中的聚合策略：先通过Prometheus查询最近5分钟的请求矩阵，再与Kubernetes Service列表做笛卡尔积补全，形成完整的服务调用图。

# PromQL 示例：获取服务间请求量
sum(
  rate(istio_requests_total{
    reporter="destination",
    response_code=~"2.*|3.*|4.*|5.*"
  }[5m])
) by (
  source_workload_namespace,
  source_workload,
  destination_service_name,
  destination_service_namespace
)

注意：Service Mesh数据存在时间窗口盲区——若某服务在5分钟内无请求，则不会出现在Prometheus结果中。建议结合Kubernetes Service定义做静态边补全，确保拓扑图中不会遗漏“静默服务”。

4.4 DNS数据采集

DNS解析记录揭示了域名到IP的映射关系，对于理解外部流量入口与内部服务别名至关重要。采集来源包括：

CoreDNS API：通过/health与/ready端点获取基本状态；通过解析日志（JSON格式）提取查询记录。
DNS日志文件：采集/var/log/coredns.log，使用正则提取A/AAAA/CNAME记录。
etcd（若CoreDNS使用etcd后端）：直接读取存储的DNS记录，适合全量快照。

采集后的DNS记录需转换为拓扑中的域名节点与解析边：

DNS记录类型	拓扑节点A	拓扑节点B	边类型
A / AAAA	域名	IP地址	解析
CNAME	别名域名	规范域名	别名
SRV	服务域名	目标域名+端口	服务定位

4.5 CMDB数据采集

CMDB提供业务语义层，将技术拓扑与组织架构关联。采集内容主要包括：

CI（配置项）关系：应用系统、模块、主机、数据库实例之间的依赖。
标签与属性：负责人、环境（生产/预发/测试）、SLA等级、部署单元。
变更历史：最近一次变更时间、变更人、变更单号。

采集方式推荐使用REST API分页拉取，配合增量同步（基于last_updated时间戳）。关键映射逻辑：将CMDB中的“应用系统”映射为拓扑中的业务服务节点，将“主机/容器实例”映射为基础设施节点，并通过部署关系边连接。

4.6 统一导入与去重策略

多源数据汇聚后，必须解决节点冲突与边重复问题。下图展示了数据导入管道的核心流程：

去重策略的核心原则：

UID优先：若多个数据源提供相同的Kubernetes UID或CMDB CI ID，以UID为唯一键合并。
IP+Port+Namespace三元组：当UID不可用时，使用该组合作为次优键，适用于Service Mesh与DNS数据。
标签合并：CMDB标签（如业务线、负责人）具有最高优先级，覆盖Kubernetes与Service Mesh中的同名标签。
时间戳裁决：对于冲突的边属性（如延迟、请求量），保留最新时间戳的数据。

  导入性能优化：建议使用批量写入（每批500-1000条边）与索引预热策略。对于Neo4j，使用UNWIND + MERGE语句实现幂等导入，避免重复创建节点。

4.7 数据质量校验

导入完成后，需执行以下校验确保拓扑数据可用：

节点覆盖率：Kubernetes中Running状态的Pod是否100%出现在拓扑中？
边连通性：每个Service是否至少有一条出边或入边？孤立节点应标记告警。
标签一致性：随机抽取10%节点，比对CMDB标签与拓扑中标签是否一致。
时间戳新鲜度：所有节点与边的last_seen时间戳不应超过采集周期的2倍。

通过上述方法，IDP网络拓扑能够实现分钟级的数据更新延迟，为Backstage查询优化与样本留存提供可靠的数据底座。