从Nginx ConfigMap到Higress路由：一个‘Hello World’服务在K8s里的完整流量旅程

从Nginx ConfigMap到Higress路由一个‘Hello World’服务在K8s里的完整流量旅程当你在浏览器中输入192.168.21.223:1105并按下回车时背后发生了什么这个简单的HTTP请求如何在Kubernetes集群中穿越层层组件最终从Nginx Pod返回那个熟悉的Hello World让我们跟随这个请求的脚步揭开云原生网关Higress路由配置的神秘面纱。1. 请求的起点Higress Gateway入口想象你是一名邮递员正站在Higress Gateway的大门前。这个大门由Kubernetes的NodePort服务开放地址是192.168.21.223:1105。当你客户端发送请求时网络层拦截请求首先到达集群节点的1105端口Service路由Kubernetes的kube-proxy将这个端口映射到Higress Gateway Pod的实际端口Ingress Controller接收Higress的Ingress Controller组件监听到这个请求提示在本地测试环境中我们通常使用NodePort暴露服务生产环境则更推荐LoadBalancer或Ingress Controller此时Higress Gateway就像机场的安检通道它需要决定这个请求是否被允许进入应该将它转发到哪个后端服务2. 路由匹配寻找正确的目的地Higress的路由规则就像机场的航班信息显示屏。在我们的例子中路由配置非常简单apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: demo-nginx-ingress spec: ingressClassName: higress rules: - host: http: paths: - pathType: Prefix path: / backend: service: name: demo-nginx-svc port: number: 8080这段配置告诉Higress匹配所有Host头host: 匹配所有路径path: /将流量转发到demo-nginx-svc服务的8080端口路由决策过程检查项配置值实际请求值是否匹配Host头空(任意)无/任意是路径//是路径类型Prefix--3. 后端服务从Service到Pod请求通过路由检查后现在需要找到真正的处理者。Kubernetes的Service系统就像机场的行李转运带Service发现Higress查询Kubernetes API找到名为demo-nginx-svc的ServiceEndpoint选择Service通过标签选择器找到对应的Pod负载均衡如果有多个PodService会选择一个合适的本例只有1个Pod我们的demo-nginx-svc配置如下apiVersion: v1 kind: Service metadata: name: demo-nginx-svc spec: ports: - port: 8080 targetPort: 8080 selector: app: demo-nginx关键点targetPort: 8080必须与Pod中容器暴露的端口一致selector确保流量只会转发到带有app: demo-nginx标签的Pod4. Nginx Pod请求的最终目的地现在请求到达了目的地——运行Nginx的Pod。这个Pod的特殊之处在于它的配置完全来自ConfigMapapiVersion: v1 kind: ConfigMap metadata: name: demo-nginx-configmap data: nginx.conf: | server { listen 8080; location / { default_type application/json; return 200 {status:success,result:nginx json}; } }ConfigMap如何挂载到PodDeployment中定义了volume来自ConfigMapvolumes: - name: nginx-config configMap: name: demo-nginx-configmap容器挂载这个volume到/etc/nginx/nginx.confvolumeMounts: - name: nginx-config mountPath: /etc/nginx/nginx.conf subPath: nginx.conf当请求到达Nginx时监听8080端口的server块接收请求匹配location /规则返回预定义的JSON响应5. 日志与可观测性追踪请求全过程一个完整的流量旅程离不开日志记录。我们的Nginx配置了详细的JSON格式日志log_format logsjson { timestamp:$time_iso8601, client_ip:$remote_addr, request_method:$request_method, request_uri:$request_uri, status:$status }; access_log /var/log/nginx/access.log logsjson;关键日志字段解析字段说明示例值timestamp请求时间2023-07-20T15:04:0508:00client_ip客户端IP192.168.1.100request_methodHTTP方法GETrequest_uri请求路径/api/teststatusHTTP状态码2006. 两种路由配置方式对比Higress提供了灵活的路由配置方式满足不同用户需求方式一Ingress CRDYAML声明式优点适合GitOps工作流方便版本控制易于批量修改典型使用场景基础设施即代码(IaC)环境CI/CD流水线中自动部署方式二Higress Console图形界面优点操作直观无需编写YAML实时生效无需kubectl apply适合快速测试和调试操作步骤访问Higress Console通常通过NodePort 39474导航到路由管理页面填写路由规则表单保存并立即生效7. 常见问题排查指南当Hello World没有如期而至时可以按照以下步骤排查检查Higress Gateway是否就绪kubectl get pods -n higress-system确保所有Pod状态为Running验证路由规则是否正确应用kubectl get ingress kubectl describe ingress demo-nginx-ingress检查后端服务是否可达# 获取Pod IP kubectl get pods -o wide # 从集群内测试访问 kubectl run -it --rm debug --imagecurlimages/curl -- sh curl http://pod-ip:8080查看Nginx日志kubectl logs nginx-pod-name典型错误案例返回502 Bad Gateway检查Service的selector是否匹配Pod标签验证targetPort与容器端口是否一致返回404 Not Found检查Ingress的path配置确认Nginx的location规则8. 进阶配置建议当你熟悉了基础路由后可以尝试这些增强配置多路径路由paths: - path: /api backend: service: api-service - path: /static backend: service: static-service基于Host的路由rules: - host: app.example.com http: paths: - path: / backend: service: app-service流量镜像用于测试新版本metadata: annotations: higress.io/canary: true higress.io/canary-weight: 10在实际项目中我们通常会结合监控系统如Prometheus来观察路由流量确保每个请求都能找到回家的路。