创建 echo Ingress 所需的核心知识：从原理到实践

在 Kubernetes（K8s）集群中，Ingress 是管理 “外部流量访问集群内部 Service” 的核心资源，它像 “集群入口的路由规则”，能通过域名和路径将请求精准转发到对应 Service。本文结合 “创建 echo Ingress” 的具体需求，梳理完成任务必须掌握的知识，帮你避开配置误区，确保 curl http://example.org/echo能正常返回 “Hello World ^_^”。

一、先搞懂：Ingress 到底是什么？它解决了什么问题？

在学习配置前，必须先明确 Ingress 的定位 —— 它不是 “直接暴露服务的组件”，而是 “路由规则的集合”，核心作用是解决 “多 Service 共享一个外部 IP” 的问题。

1. Ingress 的核心价值

K8s 中暴露 Service 的方式有 3 种：NodePort、LoadBalancer、Ingress。前两种存在明显局限：

  • NodePort：每个 Service 占用节点的一个端口，端口范围有限（30000-32767），不适合多服务场景；
  • LoadBalancer：依赖云厂商的负载均衡器，每个 Service 对应一个 LB，成本高且管理复杂。

而 Ingress 的优势在于：

  • 共享 IP：多个 Service 可通过同一个 Ingress 关联的外部 IP 暴露，只需通过 “域名 + 路径” 区分；
  • 规则集中：所有路由规则（如域名匹配、路径转发、SSL 配置）都在 Ingress 中定义，便于管理；
  • 低成本：无需为每个 Service 创建负载均衡器，只需为 Ingress Controller 配置一个外部 IP。

2. Ingress 的工作依赖：Ingress Controller

这是最容易被忽略的前提：Ingress 资源本身不具备 “转发流量” 的能力，它需要依赖 “Ingress Controller”（如 Nginx Ingress Controller、Traefik）来实现规则落地。

Ingress Controller 的作用：

  • 持续监听 K8s API 中 Ingress 资源的变化；
  • 将 Ingress 的路由规则转换为自身的配置（如 Nginx 的 nginx.conf）；
  • 接收外部流量，根据规则转发到集群内部的 Service。

简单说：Ingress 是 “规则清单”，Ingress Controller 是 “执行规则的引擎”—— 没有部署 Ingress Controller，创建再多 Ingress 资源也无法生效。

二、任务核心：Ingress 的 3 个关键配置维度

本次任务要求：Ingress 名称为 echo、命名空间为 sound-repeater，将http://example.org/echo路由到 echoserver-service 的 8080 端口。需精准掌握 Ingress 配置的 3 个核心维度：命名空间隔离、路由规则（Host+Path）、后端 Service 关联。

1. 维度 1：命名空间 ——Ingress 与 Service 的 “归属绑定”

任务明确 Ingress 和 Service 都在 “sound-repeater” 命名空间，这涉及 K8s 命名空间的核心规则：

  • 资源隔离：命名空间内的资源（Ingress、Service、Pod）只能被同一命名空间的资源访问，跨命名空间需显式配置；
  • Ingress 的限制：Ingress 只能关联 “同一命名空间” 的 Service，无法直接转发到其他命名空间的 Service（除非通过 ServiceImport 等特殊资源）。

配置要点：在 Ingress 的 metadata 中必须指定namespace: sound-repeater，否则 Ingress 会默认创建在default命名空间，导致无法找到 sound-repeater 中的 echoserver-service。

2. 维度 2：路由规则 ——Host+Path 精准匹配请求

Ingress 通过 “Host（域名）” 和 “Path（路径）” 确定请求的转发目标，这是任务的核心配置。

（1）Host：域名匹配

任务中的 Host 是example.org，需理解：

  • Host 的作用：Ingress 会检查请求的Host头（即访问的域名），只有匹配的请求才会进入该 Ingress 的规则；
  • 通配符支持：若需匹配子域名，可使用*.example.org（但需 Ingress Controller 支持）。

误区提醒：若不指定 Host，Ingress 会匹配 “所有没有 Host 头的请求”，但本次任务需精准匹配example.org，必须显式配置host: example.org。

（2）Path：路径匹配

任务中的 Path 是/echo，需掌握 Path 的匹配规则和pathType（K8s 1.18 + 新增，必填）：

  • 常见 pathType 类型：
    1. Exact：精确匹配路径，仅当请求路径与配置完全一致时生效（如/echo只匹配/echo，不匹配/echo/或/echo/test）；
    1. Prefix：前缀匹配，请求路径以配置的 Path 开头即生效（如/echo会匹配/echo、/echo/、/echo/test）；
    1. ImplementationSpecific：由 Ingress Controller 决定匹配规则，不推荐新手使用。

任务适配：本次需转发http://example.org/echo，若希望仅匹配 “/echo” 路径，建议用pathType: Exact；若需支持 “/echo” 下的子路径（如/echo/detail），可使用pathType: Prefix。

3. 维度 3：后端 Service 关联 —— 路由的 “最终目标”

Ingress 匹配 Host 和 Path 后，需转发到集群内部的 Service，这部分通过backend字段配置，核心是 “Service 名称 + Service 端口”。

配置要求：
  • Service 必须存在：需确保 sound-repeater 命名空间中已有名为echoserver-service的 Service，且该 Service 的spec.ports中包含port: 8080（无需关注 targetPort，Ingress 只需关联 Service 的端口，由 Service 转发到 Pod 的 targetPort）；
  • 字段格式：在 Ingress 的spec.rules.http.paths.backend中配置：


backend:

service:

name: echoserver-service # Service名称

port:

number: 8080 # Service的端口号


排查点：若 Service 不存在或端口错误，Ingress 会显示 “后端不可用”，curl 请求会返回 404 或 503 错误。


三、域名解析：让http://example.org/echo能找到集群


任务最后需要通过curl http://example.org/echo验证，这涉及 “域名解析” 的关键知识 —— 必须让example.org指向 Ingress Controller 的外部 IP，否则请求无法到达集群。


1. 两种常见的域名解析方式


（1）测试环境：修改 /etc/hosts 文件（推荐）


适合本地测试，无需配置 DNS 服务器，直接在执行 curl 的机器上修改/etc/hosts文件：


    
 
  • 第一步：获取 Ingress Controller 的外部 IP（通常是 Ingress Controller 的 Service 的 EXTERNAL-IP）：
    • 





# 查看Ingress Controller的Service（以Nginx Ingress为例，通常在ingress-nginx命名空间）

kubectl get svc -n ingress-nginx

# 输出中找到EXTERNAL-IP列，如192.168.1.100


    
 
  • 第二步：编辑/etc/hosts，添加一行：
    • 





192.168.1.100 example.org # 格式：Ingress Controller外部IP + 域名



（2）生产环境：配置 DNS 服务器


在生产环境中，需在 DNS 服务器（如阿里云 DNS、CoreDNS）中添加一条 “A 记录”：


    
 
  • 记录类型：A（将域名指向 IPv4 地址）；
    • 



    
 
  • 主机记录：@（表示example.org，若为子域名则填 api、www 等）；
    • 



    
 
  • 记录值：Ingress Controller 的外部 IP；
    • 



    
 
  • TTL：建议设置为 300 秒（5 分钟），便于后续 IP 变更时快速生效。
    • 



2. 常见误区：直接解析到 Service 的 ClusterIP


绝对不能将example.org解析到 echoserver-service 的 ClusterIP（如 10.96.0.10）！因为 ClusterIP 是集群内部的虚拟 IP，仅能在集群内部访问，外部机器（如执行 curl 的机器）无法通过 ClusterIP 访问 Service。


四、实操配置：Ingress YAML 文件的完整拆解


掌握上述知识后，可通过 YAML 文件创建 echo Ingress。下面是完整的 YAML 配置，并拆解每个字段的含义：




# echo-ingress.yaml

apiVersion: networking.k8s.io/v1 # Ingress的API版本（1.19+稳定版，推荐使用）

kind: Ingress # 资源类型为Ingress

metadata:

name: echo # Ingress名称，需与任务一致

namespace: sound-repeater # 命名空间，需与Service所在命名空间一致

# 可选：添加注解（Annotation），如配置Ingress Controller的特殊规则

annotations:

# 若使用Nginx Ingress，可添加该注解确保路径匹配正确

nginx.ingress.kubernetes.io/use-regex: "false"

spec:

# 可选：若需HTTPS，可配置tls字段（本次任务为HTTP，暂不配置）

# tls:

# - hosts:

# - example.org

# secretName: example-tls-secret

rules: # 路由规则列表，可配置多个规则

- host: example.org # 匹配的域名，需与任务一致

http:

paths: # 该域名下的路径规则列表

- path: /echo # 匹配的路径，需与任务一致

pathType: Exact # 路径匹配类型，根据需求选择Exact或Prefix

backend: # 匹配后的后端Service

service:

name: echoserver-service # 目标Service名称

port:

number: 8080 # 目标Service的端口号


关键字段说明：


    
 
  1. apiVersion：必须使用networking.k8s.io/v1（K8s 1.19+），旧版本extensions/v1beta1已废弃；
    2. 



    
 
  1. pathType：不可省略，需根据业务需求选择（本次任务用Exact更精准）；
    2. 



    
 
  1. annotations：可选但常用，用于配置 Ingress Controller 的特殊行为（如 Nginx 的路径重写、缓存策略等）。
    2. 



创建命令：




kubectl apply -f echo-ingress.yaml


五、验证与排查：确保 curl 能返回 “Hello World ^_^”


创建 Ingress 后，需通过一系列命令验证配置是否生效，若出现问题可按步骤排查。


1. 第一步：检查 Ingress 资源状态




kubectl get ingress -n sound-repeater


正常输出应包含：


    
 
  • NAME：echo（Ingress 名称）；
    • 




    
 
  • ADDRESS：Ingress Controller 的外部 IP（若为空，说明 Ingress Controller 未部署或配置错误）；
    • 



    
 
  • PORTS：80（HTTP 端口）；
    • 



    
 
  • AGE：Ingress 创建时间。
    • 



若ADDRESS为空，需先检查 Ingress Controller 是否正常运行：




# 以Nginx Ingress为例，检查Pod状态

kubectl get pods -n ingress-nginx

# 若Pod未Running，查看日志排查问题

kubectl logs <ingress-controller-pod-name> -n ingress-nginx


2. 第二步：检查 Service 可用性


Ingress 依赖 Service，需先确保 echoserver-service 正常：




# 查看Service状态

kubectl get svc echoserver-service -n sound-repeater

# 输出应包含PORT(S)：8080/TCP，且TYPE不为ClusterIP（若为ClusterIP，需确保Ingress能访问）

# 集群内测试Service是否返回“Hello World ^_^”

# 1. 在集群内创建临时Pod

kubectl run -it --rm test-pod --image=busybox:1.35 -n sound-repeater

# 2. 在临时Pod内curl Service

curl http://echoserver-service:8080/echo

# 若返回“Hello World ^_^”，说明Service正常；否则需检查Service关联的Pod是否正常


3. 第三步：curl 验证外部访问


完成上述检查后，执行任务要求的 curl 命令：




curl http://example.org/echo


若返回 “Hello World ^_^”，说明 Ingress 配置成功；若失败，按以下步骤排查：


    
 
  • 排查 1：/etc/hosts或 DNS 是否正确解析example.org到 Ingress Controller 的外部 IP（执行ping example.org验证）；
    • 



    
 
  • 排查 2：Ingress Controller 的外部 IP 是否能被访问（执行telnet example.org 80，若无法连接，检查防火墙规则）；
    • 



    
 
  • 排查 3：查看 Ingress Controller 日志，分析请求转发情况（以 Nginx 为例）：
    • 





kubectl logs <ingress-controller-pod-name> -n ingress-nginx | grep example.org


六、总结：完成任务的知识链


创建 echo Ingress 的任务看似简单，实则需要串联 “Ingress 原理→Ingress Controller 依赖→命名空间隔离→路由规则配置→域名解析→验证排查” 的完整知识链：


    
 
  1. 理解 Ingress 不是 “转发组件”，而是 “规则清单”，必须依赖 Ingress Controller；
    2. 



    
 
  1. 确保 Ingress 和 Service 在同一命名空间（sound-repeater）；
    2. 



    
 
  1. 精准配置 Host（example.org）、Path（/echo）和后端 Service（echoserver-service:8080）；
    2. 



    
 
  1. 通过/etc/hosts或 DNS 将域名解析到 Ingress Controller 的外部 IP；
    2. 



    
 
  1. 按 “Ingress 状态→Service 可用性→外部 curl” 的顺序验证，快速定位问题。
    2. 



掌握这些知识后，不仅能完成本次任务，更能应对复杂场景（如多域名、HTTPS、路径重写）的 Ingress 配置，真正理解 K8s 外部流量管理的核心逻辑。
 
  

        # kubernetes
      
        # 容器
      
        # 云原生
      
  
 
 Logo 
码道开发者社区
 
码道开发者社区，聚焦华为云码道 CodeArts 代码智能体，沉淀 Agent、Skill、鸿蒙开发实战内容，供开发者查阅资料、交流技术、分享工程实践
 
 
  
更多推荐
  
cover
 
AI 已经能直接改设计稿了:Windows部署Penpot，接入Codex MCP实测
 
 
avatar 码道开发者社区
 
 
【AI 业务流架构师】AI 业务流架构师方法论：Agentic AI 范式转移与业务编排思维
 
2026 年，Anthropic CEO Dario Amodei 在 Code with Claude 大会上的一个判断广为流传：一个人运营一家十亿美元级公司的概率是 70%–80%。这句话听起来像科幻小说的设定，但它背后是一个正在发生的结构性变化——AI 把"执行"的成本压到了历史低点，同时把"编排"的价值推到了前台。这意味着我们需要一套新的思考框架，来回答两个问题：一个人如何拥有一个公司的产
 
avatar 码道开发者社区
 
cover
 
Codex CLI实战 从一句模糊需求到可执行可测试可验收的开发任务把“帮我优化一下”变成 Codex 能执行、团队能复核、测试能证明的工程任务
 
 
avatar 码道开发者社区