1. 项目概述为什么要在单机环境折腾Higress最近在本地开发环境做微服务联调被一堆服务的端口转发和API网关配置搞得头大。之前一直用Nginx做反向代理但面对动态服务发现、全链路灰度这些稍微复杂点的需求配置起来就有点力不从心。正好看到阿里开源的Higress一个基于Envoy构建的云原生网关宣称能无缝对接K8s还支持Wasm插件扩展听起来很适合我们这种技术栈。于是决定在本地Docker环境里先搭一个试试水毕竟生产环境的东西不自己亲手摸一遍心里总没底。这个“单机安装”听起来简单不就是docker run一下嘛但真动起手来从镜像拉取、配置挂载到初次启动几乎每一步都遇到了意料之外的问题。网上能找到的文档大多面向K8s集群部署对于只想在笔记本上快速体验的开发者并不友好。我把这次从零开始到最终成功跑通Higress控制台和网关的完整过程连同踩过的所有坑和解决方案都详细记录在这里。如果你也在寻找一个轻量级、功能强大的本地API网关方案或者单纯想学习Higress这篇基于Docker的单机部署指南应该能帮你省下不少折腾的时间。2. 核心思路与架构选择All in One还是组件分离Higress的标准生产部署包含多个组件控制面Higress Controller、数据面Envoy Proxy、以及可选的配置存储Nacos等。在单机环境下我们有两种主要思路。2.1 方案对比一体化部署与独立组件第一种是使用社区提供的higress-all-in-one镜像。这个镜像把Controller和Gateway打包在一起通过一个进程启动理论上最简单。但实际测试发现这个镜像的文档较少内部端口映射和配置方式是个黑盒一旦出问题很难排查。更关键的是它通常绑定特定的配置模式不利于我们理解Higress各个组件是如何协同工作的。第二种也是我最终采用的方案即在单台机器上使用Docker Compose分别启动Higress Controller和Higress Gateway基于Envoy的独立容器。虽然看起来步骤多了点但好处非常明显架构清晰你能清楚地看到控制面和数据面是如何分离、如何通信的。这对于后续理解配置下发、状态同步等核心机制至关重要。灵活可控每个组件的配置、日志、资源限制都可以独立管理。比如你可以单独调整Gateway容器的网络模式或者给Controller挂载不同的配置文件。易于调试当网关路由不生效时你可以分别检查Controller的日志看配置是否生成正确和Gateway的日志看配置是否加载、请求是否匹配快速定位问题所在。更贴近生产即使是在单机这种组件分离的部署方式也更接近在K8s中的实际状态学到的经验可以直接迁移。因此我放弃了追求极简的All in One选择了更能学到东西的“伪分布式”独立部署方案。这虽然增加了初始的复杂度但为后续的顺利运行和问题排查打下了坚实基础。2.2 单机网络模式的选择Host还是Bridge在Docker单机环境中网络模式的选择直接影响到网关的可用性和性能。主要有两种选择host模式和自定义bridge网络。使用host模式--networkhost时容器直接使用宿主机的网络栈没有NAT性能最好端口映射也最直接容器内监听80端口宿主机就是80端口。但这带来两个问题一是端口冲突风险高如果宿主机已经有服务占用了80、443或8443Higress常用端口容器就会启动失败二是不够“Docker化”容器网络隔离性丧失。我选择创建自定义的bridge网络例如higress-net让Controller和Gateway容器都接入这个网络。这样做的好处是隔离性Higress相关服务在一个独立的网络环境中与宿主机其他服务互不干扰。服务发现容器间可以通过容器名称直接通信Docker内置的DNS这对于Controller向Gateway下发配置至关重要。灵活映射我可以将Gateway容器的80/443端口映射到宿主机的任意空闲高端口如8080、8443完全避免与宿主机服务的冲突。在本地开发时通过localhost:8080访问网关体验完全一样。注意如果你选择映射到80/443以外的端口后续在Ingress或路由规则中配置域名时需要记住访问网关时必须带上这个映射的端口号。3. 前期准备与关键配置解析3.1 环境检查与Docker准备首先确保你的机器已经安装了Docker和Docker Compose。可以通过docker --version和docker-compose --version或docker compose version来检查。这里我直接使用Docker Compose的V2版本即docker compose命令。接下来是一个容易忽略但至关重要的步骤调整Docker守护进程的日志驱动。默认的json-file日志驱动在日志量大时可能影响性能对于网关这类高频服务建议改为local或journaldLinux。这里我们改为local它会对日志进行轮转避免磁盘被撑满。# 编辑Docker守护进程配置如果文件不存在则创建 sudo tee /etc/docker/daemon.json /dev/null EOF { log-driver: local, log-opts: { max-size: 10m, max-file: 3 } } EOF # 重启Docker服务使配置生效 sudo systemctl restart docker这个配置限制了每个容器日志文件最大10MB最多保留3个历史文件。3.2 目录结构与配置文件准备清晰的目录结构是管理复杂应用的基础。我在项目根目录创建了如下结构higress-single-node/ ├── docker-compose.yaml # 核心编排文件 ├── config/ │ ├── gateway/ # 存放GatewayEnvoy的初始配置 │ │ └── envoy.yaml # Envoy的bootstrap配置文件 │ └── controller/ # 存放Controller的配置文件可选 ├── logs/ # 挂载日志目录按需 │ ├── gateway/ │ └── controller/ └── .env # 环境变量文件用于配置版本、端口等重点在于config/gateway/envoy.yaml这个文件。Higress Gateway本质上是一个定制化的Envoy它需要一份初始的bootstrap配置来知道如何连接Controller获取动态配置。这份配置不需要我们写得很复杂核心是配置一个static_resources里面定义一个指向Controller集群的ADSAggregated Discovery Service服务即可。下面是一个最小化的示例node: cluster: higress-gateway id: higress-gateway-1 dynamic_resources: ads_config: api_type: GRPC transport_api_version: V3 grpc_services: - envoy_grpc: cluster_name: xds_cluster cds_config: {ads: {}, resource_api_version: V3} lds_config: {ads: {}, resource_api_version: V3} static_resources: clusters: - name: xds_cluster type: STRICT_DNS connect_timeout: 10s lb_policy: ROUND_ROBIN http2_protocol_options: {} load_assignment: cluster_name: xds_cluster endpoints: - lb_endpoints: - endpoint: address: socket_address: address: higress-controller # 关键使用Compose中Controller的服务名 port_value: 15051这份配置告诉Gateway你的动态配置监听器、路由、集群等需要通过gRPC协议从名为higress-controller的主机的15051端口获取。这里使用Docker Compose的服务名确保了容器间网络的可达性。.env文件用于统一管理变量避免硬编码在Compose文件中HIGRESS_CONTROLLER_IMAGEhigress-registry.cn-hangzhou.cr.aliyuncs.com/higress/higress-controller:latest HIGRESS_GATEWAY_IMAGEhigress-registry.cn-hangzhou.cr.aliyuncs.com/higress/higress-gateway:latest GATEWAY_HTTP_PORT8080 GATEWAY_HTTPS_PORT8443 CONTROLLER_PORT80814. Docker Compose编排详解与启动4.1 docker-compose.yaml 文件逐行解析有了前面的准备现在可以编写核心的docker-compose.yaml文件了。这个文件定义了两个服务higress-controller和higress-gateway。version: 3.8 services: higress-controller: image: ${HIGRESS_CONTROLLER_IMAGE:-higress-registry.cn-hangzhou.cr.aliyuncs.com/higress/higress-controller:latest} container_name: higress-controller restart: unless-stopped ports: - ${CONTROLLER_PORT:-8081}:8080 # 将控制台端口映射出来 environment: - NAMESPACEhigress-system - POD_NAMEhigress-controller-local # 关键环境变量指定Gateway的服务地址用于健康检查和配置推送 - GATEWAY_SERVICE_NAMEhigress-gateway - GATEWAY_SERVICE_NAMESPACEdefault networks: - higress-net volumes: # 挂载Kubernetes的kubeconfig文件如果本地有Minikube或Kind集群用于测试 # - ~/.kube/config:/root/.kube/config:ro # 挂载本地时区文件让容器日志时间与宿主机一致 - /etc/localtime:/etc/localtime:ro healthcheck: test: [CMD, wget, --no-verbose, --tries1, --spider, http://localhost:8080/healthz] interval: 30s timeout: 10s retries: 3 start_period: 40s higress-gateway: image: ${HIGRESS_GATEWAY_IMAGE:-higress-registry.cn-hangzhou.cr.aliyuncs.com/higress/higress-gateway:latest} container_name: higress-gateway restart: unless-stopped ports: - ${GATEWAY_HTTP_PORT:-8080}:80 # HTTP流量入口 - ${GATEWAY_HTTPS_PORT:-8443}:443 # HTTPS流量入口 environment: - NODE_IDhigress-gateway-1 - NODE_CLUSTERhigress-gateway - XDS_ADDRESShigress-controller:15051 # 指向Controller的gRPC服务 networks: - higress-net volumes: # 挂载我们准备好的Envoy初始配置 - ./config/gateway/envoy.yaml:/etc/envoy/envoy.yaml:ro - /etc/localtime:/etc/localtime:ro depends_on: higress-controller: condition: service_healthy # 等待Controller健康检查通过后再启动 command: [ envoy, -c, /etc/envoy/envoy.yaml, --log-level, info ] networks: higress-net: driver: bridge关键点解析镜像源使用了阿里云镜像仓库的地址速度相对稳定。如果拉取慢可以考虑配置Docker镜像加速器或者先docker pull到本地。Controller的环境变量GATEWAY_SERVICE_NAME和GATEWAY_SERVICE_NAMESPACE非常重要。Controller需要知道它管理的Gateway实例在哪里以便推送配置和收集状态。在单机Docker环境下我们模拟了K8s中的服务发现这里指定了Gateway的服务名。Gateway的依赖通过depends_oncondition: service_healthy确保Gateway只在Controller完全就绪后才启动避免了因Controller未准备好导致Gateway连接XDS服务失败的问题。Gateway的启动命令我们覆盖了默认的启动命令指定使用我们挂载的envoy.yaml配置文件并设置了日志级别为info。你也可以改为debug来获取更详细的日志但输出量会非常大。4.2 启动服务与验证在项目根目录下执行启动命令docker compose up -d-d参数表示在后台运行。接着使用docker compose logs -f可以实时查看两个容器的日志。重点关注启动过程中是否有ERROR。正常的日志应该显示Controller启动成功注册了相应的CRD并开始监听Gateway则成功连接到Controller的15051端口并开始接收动态配置。验证服务是否正常检查Controller控制台浏览器打开http://localhost:8081端口取决于你的.env设置。如果能看到Higress控制台的登录界面或健康检查页面说明Controller运行正常。检查Gateway数据面执行curl -v http://localhost:8080。因为此时还没有配置任何路由预期应该返回一个404 Not Found页面可能是Envoy默认的404也可能是Higress定制的。关键是要能收到HTTP响应这证明Gateway的监听器在工作。如果连接被拒绝说明端口映射或容器本身有问题。5. 核心踩坑点与解决方案实录在实际操作中我遇到了以下几个典型问题这里把排查过程和解决方法记录下来。5.1 坑一Gateway容器不断重启日志显示“failed to fetch” XDS配置现象docker compose ps显示Gateway容器状态不断在Restarting查看日志docker compose logs higress-gateway发现大量[error][config] failed to fetch错误指向xds_cluster。排查首先检查网络连通性。进入Gateway容器内部docker exec -it higress-gateway sh尝试用telnet或nc连接Controller的15051端口nc -zv higress-controller 15051。如果连接失败说明容器间网络不通。检查docker network inspect higress-single-node_higress-net网络名可能因项目目录而异确认两个容器是否都在同一个网络中且IP地址正确。检查Controller容器是否真的在15051端口上监听了gRPC服务。进入Controller容器docker exec -it higress-controller sh执行netstat -tlnp | grep 15051。如果没看到监听可能是Controller启动参数或配置有问题。解决 在我的案例中问题是第3步。检查Controller日志发现它并没有在15051端口启动gRPC服务。查阅Higress官方文档和源码启动参数发现Controller的XDS gRPC服务端口是由环境变量XDS_PORT控制的默认值就是15051。但在我的Compose文件中没有显式声明这个环境变量而Controller镜像的默认配置可能因版本而异。为了确保万无一失我在higress-controller服务的environment部分显式添加了environment: - XDS_PORT15051 # ... 其他环境变量然后docker compose down再up -d问题解决。教训对于开源项目即使文档写了默认值如果遇到问题最好在配置中显式地指定关键参数。5.2 坑二通过Gateway访问服务一直返回502 Bad Gateway或503 Service Unavailable现象在控制台配置了一条路由将/api/test转发到本地另一个运行在9999端口的Spring Boot应用。通过Gateway的8080端口访问/api/test返回502错误。Gateway日志显示[error][router] upstream connect error or disconnect/reset before headers。排查检查后端服务首先确保你的后端服务本身是健康的。直接访问http://localhost:9999/api/test确认能正常响应。检查Gateway容器到后端服务的网络这是单机Docker部署最常见的问题。Gateway容器运行在独立的bridge网络中对于它来说localhost或127.0.0.1指的是容器自己而不是宿主机。因此在Gateway的路由配置中上游Upstream地址不能填127.0.0.1:9999。查看路由配置在Higress控制台或通过Kubectl查看对应的Ingress/HTTPRoute资源检查配置的上游主机地址是否正确。解决 有两种方法可以让Gateway容器访问到宿主机上运行的服务方法A使用特殊的Docker DNS名称。在Linux和macOS的Docker Desktop中Gateway容器可以通过host.docker.internal这个主机名访问到宿主机。在Windows的Docker Desktop中则是host.docker.internal。因此在配置上游服务地址时应该使用host.docker.internal:9999。方法B将Gateway容器网络模式改为host。这样它就直接使用宿主机网络localhost就是宿主机。但如前所述这会带来端口冲突风险。修改Compose中Gateway服务的配置higress-gateway: # ... 其他配置 network_mode: host # 注释掉ports映射因为host模式端口已直接暴露 # ports: # - ...我个人在开发环境更倾向于方法A因为它保持了容器的网络隔离性更符合Docker的最佳实践。只需要在配置路由时记住这个特殊的hostname即可。5.3 坑三控制台可以访问但配置路由后不生效现象在Higress控制台创建了Ingress路由规则保存成功但通过Gateway访问始终是404控制台也看不到该条路由的流量统计。排查检查Controller日志查看是否有处理该Ingress资源的日志特别是错误信息。docker compose logs higress-controller --tail100。检查Gateway日志查看是否有配置更新的日志。当Controller推送新配置时Gateway会输出[info][config] all resources updated之类的信息。如果没有说明配置推送链路有问题。验证配置是否已下发可以进入Gateway容器导出当前的Envoy配置来查看。docker exec higress-gateway curl -s http://localhost:15000/config_dump | jq .需要容器内安装curl和jq。在输出的庞大JSON中搜索你配置的域名或路径看是否存在对应的监听器和路由。解决 我遇到的情况是Controller日志显示成功处理了Ingress但Gateway没有更新。根本原因是Controller和Gateway之间的身份认证或集群发现配置不匹配。回顾我们的envoy.yaml其中定义了一个名为xds_cluster的静态集群指向higress-controller:15051。而在Controller端它需要识别并接受来自这个集群的连接。在Higress中Controller通过环境变量GATEWAY_SERVICE_NAME和GATEWAY_SERVICE_NAMESPACE来识别合法的Gateway。必须确保Controller中配置的Gateway服务名与Gateway容器中envoy.yaml里node.cluster或node.id有一定的关联性或者符合Controller的预期。在我的配置中Controller环境变量GATEWAY_SERVICE_NAMEhigress-gateway(这是Docker Compose中的服务名)Gateway的envoy.yamlnode.cluster: higress-gateway这里node.cluster的值higress-gateway与Controller寻找的服务名higress-gateway不完全一致实际上Controller的匹配逻辑可能更灵活或者依赖于其他机制。为了彻底避免歧义一个更稳妥的做法是在Controller的环境变量中明确指定Gateway集群的标识。查阅文档发现可以通过环境变量GATEWAY_CLUSTER_NAME来指定。于是我在Controller的配置中增加environment: - GATEWAY_SERVICE_NAMEhigress-gateway - GATEWAY_CLUSTER_NAMEhigress-gateway # 与envoy.yaml中的cluster匹配 - XDS_PORT15051重启服务后配置推送立即生效。核心教训在云原生网关体系中控制面和数据面之间的发现与认证机制非常关键。在单机模拟时需要仔细对照官方文档确保两边用于识别的标识如集群名、节点ID、服务名能够对应上或者至少有一方配置得足够宽松以接受连接。6. 进阶配置与优化建议当基础服务跑通后可以考虑一些优化和进阶配置让这个单机Higress更实用、更稳定。6.1 启用持久化存储配置可选目前我们的配置都存在于Controller容器的内存中一旦容器重启所有配置的Ingress路由都会丢失。对于本地开发测试这或许可以接受但如果你希望配置能保留可以考虑为Controller添加一个持久化存储卷用于保存其核心的配置数据通常是etcd或数据库的数据目录。不过Higress Controller默认使用Kubernetes的API Server作为存储后端在单机Docker模式下模拟这一点比较复杂。一个更简单的替代方案是将你的路由规则写成Kubernetes YAML文件或Higress的CRD YAML保存在本地。每次重启后通过kubectl apply如果你连接了本地K8s集群或一个初始化脚本重新提交这些配置。6.2 配置监控与日志收集运维离不开监控和日志。我们可以配置将Gateway和Controller的日志输出到标准输出Stdout然后由Docker的日志驱动收集这样方便使用docker compose logs查看。我们已经在前面的daemon.json中配置了日志轮转。对于监控Envoy内置了管理接口默认在15000端口可以暴露丰富的指标。我们可以将Gateway的15000端口也映射出来ports: - ${GATEWAY_HTTP_PORT:-8080}:80 - ${GATEWAY_HTTPS_PORT:-8443}:443 - 15000:15000 # 暴露Envoy管理端口然后访问http://localhost:15000/stats可以查看内部指标/stats/prometheus可以获取Prometheus格式的指标。你可以配置Prometheus来抓取这些指标实现监控告警。6.3 性能调优初步在单机环境下主要关注容器资源限制。可以在Compose文件中为两个服务添加资源限制防止某个服务异常时拖垮整个Docker守护进程。higress-gateway: # ... 其他配置 deploy: resources: limits: cpus: 1.0 memory: 1G reservations: cpus: 0.5 memory: 512M对于GatewayEnvoy是高性能的但在资源受限的环境下可以调整其并发连接数、监听器配置等。这需要修改envoy.yaml属于更高级的调优建议参考Envoy官方文档进行。7. 总结与个人使用体会走完这一趟单机安装Higress的全程最大的感受是云原生网关的强大功能背后是相对复杂的组件交互和配置约定。在K8s环境中很多问题如服务发现、配置存储、证书管理都被平台解决了部署反而简单。一旦脱离K8s在裸机或单机Docker上部署就需要我们自己把这些支撑组件的关系理清并模拟出来。这次实践让我对Higress的架构有了更深的理解。Controller作为大脑负责管理配置Gateway作为肢体负责转发流量。它们之间通过XDSgRPC协议通信。在单机部署时我们手动搭建了这个通信链路包括网络连通、服务发现、身份匹配这每一步都可能成为“坑点”。对于想尝试Higress的开发者我的建议是耐心阅读日志日志是排查问题最直接的线索。一定要学会看Controller和Gateway的日志从错误信息中往往能定位到方向。理解核心概念花点时间理解XDS、Envoy的静态/动态资源、Cluster、Listener、Route等基本概念。这能帮助你在配置出错时知道该检查哪一部分。循序渐进先确保最基本的组件能通网络、XDS连接再配置最简单的路由规则如将/转发到一个已知可用的后端验证通路。成功后再逐步增加复杂度域名、路径重写、鉴权插件等。善用工具docker exec进入容器内部进行调试如curl、telnet、使用docker network inspect检查网络、利用Envoy的管理接口15000端口查看配置和状态这些都是非常有效的调试手段。最后把这次用到的所有配置文件整理好放到一个Git仓库里。下次换机器或者重装环境一个git clone加docker compose up -d五分钟就能重建一个可用的Higress单机环境这才是折腾的最终意义——将经验沉淀为可复用的资产。
1. 项目概述为什么要在单机环境折腾Higress最近在本地开发环境做微服务联调被一堆服务的端口转发和API网关配置搞得头大。之前一直用Nginx做反向代理但面对动态服务发现、全链路灰度这些稍微复杂点的需求配置起来就有点力不从心。正好看到阿里开源的Higress一个基于Envoy构建的云原生网关宣称能无缝对接K8s还支持Wasm插件扩展听起来很适合我们这种技术栈。于是决定在本地Docker环境里先搭一个试试水毕竟生产环境的东西不自己亲手摸一遍心里总没底。这个“单机安装”听起来简单不就是docker run一下嘛但真动起手来从镜像拉取、配置挂载到初次启动几乎每一步都遇到了意料之外的问题。网上能找到的文档大多面向K8s集群部署对于只想在笔记本上快速体验的开发者并不友好。我把这次从零开始到最终成功跑通Higress控制台和网关的完整过程连同踩过的所有坑和解决方案都详细记录在这里。如果你也在寻找一个轻量级、功能强大的本地API网关方案或者单纯想学习Higress这篇基于Docker的单机部署指南应该能帮你省下不少折腾的时间。2. 核心思路与架构选择All in One还是组件分离Higress的标准生产部署包含多个组件控制面Higress Controller、数据面Envoy Proxy、以及可选的配置存储Nacos等。在单机环境下我们有两种主要思路。2.1 方案对比一体化部署与独立组件第一种是使用社区提供的higress-all-in-one镜像。这个镜像把Controller和Gateway打包在一起通过一个进程启动理论上最简单。但实际测试发现这个镜像的文档较少内部端口映射和配置方式是个黑盒一旦出问题很难排查。更关键的是它通常绑定特定的配置模式不利于我们理解Higress各个组件是如何协同工作的。第二种也是我最终采用的方案即在单台机器上使用Docker Compose分别启动Higress Controller和Higress Gateway基于Envoy的独立容器。虽然看起来步骤多了点但好处非常明显架构清晰你能清楚地看到控制面和数据面是如何分离、如何通信的。这对于后续理解配置下发、状态同步等核心机制至关重要。灵活可控每个组件的配置、日志、资源限制都可以独立管理。比如你可以单独调整Gateway容器的网络模式或者给Controller挂载不同的配置文件。易于调试当网关路由不生效时你可以分别检查Controller的日志看配置是否生成正确和Gateway的日志看配置是否加载、请求是否匹配快速定位问题所在。更贴近生产即使是在单机这种组件分离的部署方式也更接近在K8s中的实际状态学到的经验可以直接迁移。因此我放弃了追求极简的All in One选择了更能学到东西的“伪分布式”独立部署方案。这虽然增加了初始的复杂度但为后续的顺利运行和问题排查打下了坚实基础。2.2 单机网络模式的选择Host还是Bridge在Docker单机环境中网络模式的选择直接影响到网关的可用性和性能。主要有两种选择host模式和自定义bridge网络。使用host模式--networkhost时容器直接使用宿主机的网络栈没有NAT性能最好端口映射也最直接容器内监听80端口宿主机就是80端口。但这带来两个问题一是端口冲突风险高如果宿主机已经有服务占用了80、443或8443Higress常用端口容器就会启动失败二是不够“Docker化”容器网络隔离性丧失。我选择创建自定义的bridge网络例如higress-net让Controller和Gateway容器都接入这个网络。这样做的好处是隔离性Higress相关服务在一个独立的网络环境中与宿主机其他服务互不干扰。服务发现容器间可以通过容器名称直接通信Docker内置的DNS这对于Controller向Gateway下发配置至关重要。灵活映射我可以将Gateway容器的80/443端口映射到宿主机的任意空闲高端口如8080、8443完全避免与宿主机服务的冲突。在本地开发时通过localhost:8080访问网关体验完全一样。注意如果你选择映射到80/443以外的端口后续在Ingress或路由规则中配置域名时需要记住访问网关时必须带上这个映射的端口号。3. 前期准备与关键配置解析3.1 环境检查与Docker准备首先确保你的机器已经安装了Docker和Docker Compose。可以通过docker --version和docker-compose --version或docker compose version来检查。这里我直接使用Docker Compose的V2版本即docker compose命令。接下来是一个容易忽略但至关重要的步骤调整Docker守护进程的日志驱动。默认的json-file日志驱动在日志量大时可能影响性能对于网关这类高频服务建议改为local或journaldLinux。这里我们改为local它会对日志进行轮转避免磁盘被撑满。# 编辑Docker守护进程配置如果文件不存在则创建 sudo tee /etc/docker/daemon.json /dev/null EOF { log-driver: local, log-opts: { max-size: 10m, max-file: 3 } } EOF # 重启Docker服务使配置生效 sudo systemctl restart docker这个配置限制了每个容器日志文件最大10MB最多保留3个历史文件。3.2 目录结构与配置文件准备清晰的目录结构是管理复杂应用的基础。我在项目根目录创建了如下结构higress-single-node/ ├── docker-compose.yaml # 核心编排文件 ├── config/ │ ├── gateway/ # 存放GatewayEnvoy的初始配置 │ │ └── envoy.yaml # Envoy的bootstrap配置文件 │ └── controller/ # 存放Controller的配置文件可选 ├── logs/ # 挂载日志目录按需 │ ├── gateway/ │ └── controller/ └── .env # 环境变量文件用于配置版本、端口等重点在于config/gateway/envoy.yaml这个文件。Higress Gateway本质上是一个定制化的Envoy它需要一份初始的bootstrap配置来知道如何连接Controller获取动态配置。这份配置不需要我们写得很复杂核心是配置一个static_resources里面定义一个指向Controller集群的ADSAggregated Discovery Service服务即可。下面是一个最小化的示例node: cluster: higress-gateway id: higress-gateway-1 dynamic_resources: ads_config: api_type: GRPC transport_api_version: V3 grpc_services: - envoy_grpc: cluster_name: xds_cluster cds_config: {ads: {}, resource_api_version: V3} lds_config: {ads: {}, resource_api_version: V3} static_resources: clusters: - name: xds_cluster type: STRICT_DNS connect_timeout: 10s lb_policy: ROUND_ROBIN http2_protocol_options: {} load_assignment: cluster_name: xds_cluster endpoints: - lb_endpoints: - endpoint: address: socket_address: address: higress-controller # 关键使用Compose中Controller的服务名 port_value: 15051这份配置告诉Gateway你的动态配置监听器、路由、集群等需要通过gRPC协议从名为higress-controller的主机的15051端口获取。这里使用Docker Compose的服务名确保了容器间网络的可达性。.env文件用于统一管理变量避免硬编码在Compose文件中HIGRESS_CONTROLLER_IMAGEhigress-registry.cn-hangzhou.cr.aliyuncs.com/higress/higress-controller:latest HIGRESS_GATEWAY_IMAGEhigress-registry.cn-hangzhou.cr.aliyuncs.com/higress/higress-gateway:latest GATEWAY_HTTP_PORT8080 GATEWAY_HTTPS_PORT8443 CONTROLLER_PORT80814. Docker Compose编排详解与启动4.1 docker-compose.yaml 文件逐行解析有了前面的准备现在可以编写核心的docker-compose.yaml文件了。这个文件定义了两个服务higress-controller和higress-gateway。version: 3.8 services: higress-controller: image: ${HIGRESS_CONTROLLER_IMAGE:-higress-registry.cn-hangzhou.cr.aliyuncs.com/higress/higress-controller:latest} container_name: higress-controller restart: unless-stopped ports: - ${CONTROLLER_PORT:-8081}:8080 # 将控制台端口映射出来 environment: - NAMESPACEhigress-system - POD_NAMEhigress-controller-local # 关键环境变量指定Gateway的服务地址用于健康检查和配置推送 - GATEWAY_SERVICE_NAMEhigress-gateway - GATEWAY_SERVICE_NAMESPACEdefault networks: - higress-net volumes: # 挂载Kubernetes的kubeconfig文件如果本地有Minikube或Kind集群用于测试 # - ~/.kube/config:/root/.kube/config:ro # 挂载本地时区文件让容器日志时间与宿主机一致 - /etc/localtime:/etc/localtime:ro healthcheck: test: [CMD, wget, --no-verbose, --tries1, --spider, http://localhost:8080/healthz] interval: 30s timeout: 10s retries: 3 start_period: 40s higress-gateway: image: ${HIGRESS_GATEWAY_IMAGE:-higress-registry.cn-hangzhou.cr.aliyuncs.com/higress/higress-gateway:latest} container_name: higress-gateway restart: unless-stopped ports: - ${GATEWAY_HTTP_PORT:-8080}:80 # HTTP流量入口 - ${GATEWAY_HTTPS_PORT:-8443}:443 # HTTPS流量入口 environment: - NODE_IDhigress-gateway-1 - NODE_CLUSTERhigress-gateway - XDS_ADDRESShigress-controller:15051 # 指向Controller的gRPC服务 networks: - higress-net volumes: # 挂载我们准备好的Envoy初始配置 - ./config/gateway/envoy.yaml:/etc/envoy/envoy.yaml:ro - /etc/localtime:/etc/localtime:ro depends_on: higress-controller: condition: service_healthy # 等待Controller健康检查通过后再启动 command: [ envoy, -c, /etc/envoy/envoy.yaml, --log-level, info ] networks: higress-net: driver: bridge关键点解析镜像源使用了阿里云镜像仓库的地址速度相对稳定。如果拉取慢可以考虑配置Docker镜像加速器或者先docker pull到本地。Controller的环境变量GATEWAY_SERVICE_NAME和GATEWAY_SERVICE_NAMESPACE非常重要。Controller需要知道它管理的Gateway实例在哪里以便推送配置和收集状态。在单机Docker环境下我们模拟了K8s中的服务发现这里指定了Gateway的服务名。Gateway的依赖通过depends_oncondition: service_healthy确保Gateway只在Controller完全就绪后才启动避免了因Controller未准备好导致Gateway连接XDS服务失败的问题。Gateway的启动命令我们覆盖了默认的启动命令指定使用我们挂载的envoy.yaml配置文件并设置了日志级别为info。你也可以改为debug来获取更详细的日志但输出量会非常大。4.2 启动服务与验证在项目根目录下执行启动命令docker compose up -d-d参数表示在后台运行。接着使用docker compose logs -f可以实时查看两个容器的日志。重点关注启动过程中是否有ERROR。正常的日志应该显示Controller启动成功注册了相应的CRD并开始监听Gateway则成功连接到Controller的15051端口并开始接收动态配置。验证服务是否正常检查Controller控制台浏览器打开http://localhost:8081端口取决于你的.env设置。如果能看到Higress控制台的登录界面或健康检查页面说明Controller运行正常。检查Gateway数据面执行curl -v http://localhost:8080。因为此时还没有配置任何路由预期应该返回一个404 Not Found页面可能是Envoy默认的404也可能是Higress定制的。关键是要能收到HTTP响应这证明Gateway的监听器在工作。如果连接被拒绝说明端口映射或容器本身有问题。5. 核心踩坑点与解决方案实录在实际操作中我遇到了以下几个典型问题这里把排查过程和解决方法记录下来。5.1 坑一Gateway容器不断重启日志显示“failed to fetch” XDS配置现象docker compose ps显示Gateway容器状态不断在Restarting查看日志docker compose logs higress-gateway发现大量[error][config] failed to fetch错误指向xds_cluster。排查首先检查网络连通性。进入Gateway容器内部docker exec -it higress-gateway sh尝试用telnet或nc连接Controller的15051端口nc -zv higress-controller 15051。如果连接失败说明容器间网络不通。检查docker network inspect higress-single-node_higress-net网络名可能因项目目录而异确认两个容器是否都在同一个网络中且IP地址正确。检查Controller容器是否真的在15051端口上监听了gRPC服务。进入Controller容器docker exec -it higress-controller sh执行netstat -tlnp | grep 15051。如果没看到监听可能是Controller启动参数或配置有问题。解决 在我的案例中问题是第3步。检查Controller日志发现它并没有在15051端口启动gRPC服务。查阅Higress官方文档和源码启动参数发现Controller的XDS gRPC服务端口是由环境变量XDS_PORT控制的默认值就是15051。但在我的Compose文件中没有显式声明这个环境变量而Controller镜像的默认配置可能因版本而异。为了确保万无一失我在higress-controller服务的environment部分显式添加了environment: - XDS_PORT15051 # ... 其他环境变量然后docker compose down再up -d问题解决。教训对于开源项目即使文档写了默认值如果遇到问题最好在配置中显式地指定关键参数。5.2 坑二通过Gateway访问服务一直返回502 Bad Gateway或503 Service Unavailable现象在控制台配置了一条路由将/api/test转发到本地另一个运行在9999端口的Spring Boot应用。通过Gateway的8080端口访问/api/test返回502错误。Gateway日志显示[error][router] upstream connect error or disconnect/reset before headers。排查检查后端服务首先确保你的后端服务本身是健康的。直接访问http://localhost:9999/api/test确认能正常响应。检查Gateway容器到后端服务的网络这是单机Docker部署最常见的问题。Gateway容器运行在独立的bridge网络中对于它来说localhost或127.0.0.1指的是容器自己而不是宿主机。因此在Gateway的路由配置中上游Upstream地址不能填127.0.0.1:9999。查看路由配置在Higress控制台或通过Kubectl查看对应的Ingress/HTTPRoute资源检查配置的上游主机地址是否正确。解决 有两种方法可以让Gateway容器访问到宿主机上运行的服务方法A使用特殊的Docker DNS名称。在Linux和macOS的Docker Desktop中Gateway容器可以通过host.docker.internal这个主机名访问到宿主机。在Windows的Docker Desktop中则是host.docker.internal。因此在配置上游服务地址时应该使用host.docker.internal:9999。方法B将Gateway容器网络模式改为host。这样它就直接使用宿主机网络localhost就是宿主机。但如前所述这会带来端口冲突风险。修改Compose中Gateway服务的配置higress-gateway: # ... 其他配置 network_mode: host # 注释掉ports映射因为host模式端口已直接暴露 # ports: # - ...我个人在开发环境更倾向于方法A因为它保持了容器的网络隔离性更符合Docker的最佳实践。只需要在配置路由时记住这个特殊的hostname即可。5.3 坑三控制台可以访问但配置路由后不生效现象在Higress控制台创建了Ingress路由规则保存成功但通过Gateway访问始终是404控制台也看不到该条路由的流量统计。排查检查Controller日志查看是否有处理该Ingress资源的日志特别是错误信息。docker compose logs higress-controller --tail100。检查Gateway日志查看是否有配置更新的日志。当Controller推送新配置时Gateway会输出[info][config] all resources updated之类的信息。如果没有说明配置推送链路有问题。验证配置是否已下发可以进入Gateway容器导出当前的Envoy配置来查看。docker exec higress-gateway curl -s http://localhost:15000/config_dump | jq .需要容器内安装curl和jq。在输出的庞大JSON中搜索你配置的域名或路径看是否存在对应的监听器和路由。解决 我遇到的情况是Controller日志显示成功处理了Ingress但Gateway没有更新。根本原因是Controller和Gateway之间的身份认证或集群发现配置不匹配。回顾我们的envoy.yaml其中定义了一个名为xds_cluster的静态集群指向higress-controller:15051。而在Controller端它需要识别并接受来自这个集群的连接。在Higress中Controller通过环境变量GATEWAY_SERVICE_NAME和GATEWAY_SERVICE_NAMESPACE来识别合法的Gateway。必须确保Controller中配置的Gateway服务名与Gateway容器中envoy.yaml里node.cluster或node.id有一定的关联性或者符合Controller的预期。在我的配置中Controller环境变量GATEWAY_SERVICE_NAMEhigress-gateway(这是Docker Compose中的服务名)Gateway的envoy.yamlnode.cluster: higress-gateway这里node.cluster的值higress-gateway与Controller寻找的服务名higress-gateway不完全一致实际上Controller的匹配逻辑可能更灵活或者依赖于其他机制。为了彻底避免歧义一个更稳妥的做法是在Controller的环境变量中明确指定Gateway集群的标识。查阅文档发现可以通过环境变量GATEWAY_CLUSTER_NAME来指定。于是我在Controller的配置中增加environment: - GATEWAY_SERVICE_NAMEhigress-gateway - GATEWAY_CLUSTER_NAMEhigress-gateway # 与envoy.yaml中的cluster匹配 - XDS_PORT15051重启服务后配置推送立即生效。核心教训在云原生网关体系中控制面和数据面之间的发现与认证机制非常关键。在单机模拟时需要仔细对照官方文档确保两边用于识别的标识如集群名、节点ID、服务名能够对应上或者至少有一方配置得足够宽松以接受连接。6. 进阶配置与优化建议当基础服务跑通后可以考虑一些优化和进阶配置让这个单机Higress更实用、更稳定。6.1 启用持久化存储配置可选目前我们的配置都存在于Controller容器的内存中一旦容器重启所有配置的Ingress路由都会丢失。对于本地开发测试这或许可以接受但如果你希望配置能保留可以考虑为Controller添加一个持久化存储卷用于保存其核心的配置数据通常是etcd或数据库的数据目录。不过Higress Controller默认使用Kubernetes的API Server作为存储后端在单机Docker模式下模拟这一点比较复杂。一个更简单的替代方案是将你的路由规则写成Kubernetes YAML文件或Higress的CRD YAML保存在本地。每次重启后通过kubectl apply如果你连接了本地K8s集群或一个初始化脚本重新提交这些配置。6.2 配置监控与日志收集运维离不开监控和日志。我们可以配置将Gateway和Controller的日志输出到标准输出Stdout然后由Docker的日志驱动收集这样方便使用docker compose logs查看。我们已经在前面的daemon.json中配置了日志轮转。对于监控Envoy内置了管理接口默认在15000端口可以暴露丰富的指标。我们可以将Gateway的15000端口也映射出来ports: - ${GATEWAY_HTTP_PORT:-8080}:80 - ${GATEWAY_HTTPS_PORT:-8443}:443 - 15000:15000 # 暴露Envoy管理端口然后访问http://localhost:15000/stats可以查看内部指标/stats/prometheus可以获取Prometheus格式的指标。你可以配置Prometheus来抓取这些指标实现监控告警。6.3 性能调优初步在单机环境下主要关注容器资源限制。可以在Compose文件中为两个服务添加资源限制防止某个服务异常时拖垮整个Docker守护进程。higress-gateway: # ... 其他配置 deploy: resources: limits: cpus: 1.0 memory: 1G reservations: cpus: 0.5 memory: 512M对于GatewayEnvoy是高性能的但在资源受限的环境下可以调整其并发连接数、监听器配置等。这需要修改envoy.yaml属于更高级的调优建议参考Envoy官方文档进行。7. 总结与个人使用体会走完这一趟单机安装Higress的全程最大的感受是云原生网关的强大功能背后是相对复杂的组件交互和配置约定。在K8s环境中很多问题如服务发现、配置存储、证书管理都被平台解决了部署反而简单。一旦脱离K8s在裸机或单机Docker上部署就需要我们自己把这些支撑组件的关系理清并模拟出来。这次实践让我对Higress的架构有了更深的理解。Controller作为大脑负责管理配置Gateway作为肢体负责转发流量。它们之间通过XDSgRPC协议通信。在单机部署时我们手动搭建了这个通信链路包括网络连通、服务发现、身份匹配这每一步都可能成为“坑点”。对于想尝试Higress的开发者我的建议是耐心阅读日志日志是排查问题最直接的线索。一定要学会看Controller和Gateway的日志从错误信息中往往能定位到方向。理解核心概念花点时间理解XDS、Envoy的静态/动态资源、Cluster、Listener、Route等基本概念。这能帮助你在配置出错时知道该检查哪一部分。循序渐进先确保最基本的组件能通网络、XDS连接再配置最简单的路由规则如将/转发到一个已知可用的后端验证通路。成功后再逐步增加复杂度域名、路径重写、鉴权插件等。善用工具docker exec进入容器内部进行调试如curl、telnet、使用docker network inspect检查网络、利用Envoy的管理接口15000端口查看配置和状态这些都是非常有效的调试手段。最后把这次用到的所有配置文件整理好放到一个Git仓库里。下次换机器或者重装环境一个git clone加docker compose up -d五分钟就能重建一个可用的Higress单机环境这才是折腾的最终意义——将经验沉淀为可复用的资产。
