云原生场景下应升级使用可管理、可发现、可隔离的自定义bridge网络：通过docker network create创建带子网和网关的专用网络，按业务域分层建网，并用docker compose声明式编排实现服务发现与隔离。
云原生场景下对 Docker Bridge 网络的改造，核心不是替换它，而是“升级用法”：从依赖默认 bridge 网络，转向使用**可管理、可发现、可隔离的自定义 bridge 网络**。默认 bridge（即 docker0）缺乏 DNS 解析、IP 不固定、无子网规划，不适合微服务协同与 Agent 通信等云原生需求。
用自定义 bridge 替代默认 bridge
默认 bridge 网络不支持容器名解析，所有跨容器调用必须硬编码 IP 或依赖 --link（已弃用）。自定义网络由 Docker 内置 DNS 服务自动维护，同一网络内容器可直接用 service-name 通信。
- 创建带子网和网关的专用网络：
docker network create --driver bridge --subnet=172.20.0.0/24 --gateway=172.20.0.1 agent-net - 启动容器时显式接入：
docker run -d --name api-server --network agent-net your-api-image - 其他服务（如 agent、monitor、logger）同样接入
agent-net，即可通过api-server直接访问
按业务域划分网络平面
云原生系统中，不同组件的安全等级与通信需求不同。不应把所有容器塞进一个网络，而应分层分域建网：
- 前端服务（Web/API）单独一个网络，如
web-net，仅开放必要端口给宿主机或 Ingress - 后端微服务（DB、Cache、Auth）放入
backend-net，内部互通但对外完全封闭 - 可观测组件（Prometheus、Loki、Tempo）接入
observe-net，与业务网通过docker network connect有选择地打通 - Agent 容器建议独占网络或与被监控服务共网，便于本地采集而不穿透防火墙
配合 Docker Compose 声明式编排
手动 docker run 难以维护多服务拓扑。用 docker-compose.yml 显式定义网络结构，既提升可读性，也天然支持服务发现：
- 在
networks:下声明驱动为bridge的自定义网络 - 每个
service:指定networks: [app-net]，Docker 自动为其分配 IP 并注册 DNS 记录 - 无需
ports:即可实现服务间调用；只有需要暴露给外部时才映射端口 - 示例中
db:和app:同属app-net，app可直接ping db或连接postgresql://db:5432
避免常见误区
Bridge 网络本身是轻量可靠的，问题常出在误用而非机制缺陷：
- ❌ 不要混用默认
bridge和自定义网络——它们彼此隔离，无法互通 - ❌ 不要在生产环境用
--network host跑 Agent，会丧失网络隔离且端口易冲突 - ❌ 不要依赖
docker0的172.17.0.0/16子网，它可能与宿主机或云平台 VPC 冲突 - ✅ 用
docker network inspect agent-net查看子网、网关、已连容器，确认 DNS 和路由状态
