K8s系列第八篇：K8s 服务发现：Ingress 全实战（含SSL配置）

qq_29757467

528人浏览 · 2026-03-20 09:35:01

qq_29757467 · 2026-03-20 09:35:01 发布

前言：在上一篇文章中，我们掌握了K8s配置管理的核心方案——通过ConfigMap管理非敏感配置、Secret管理敏感配置，彻底解决了“配置与镜像耦合、敏感信息明文泄露”的痛点，实现了配置的规范化、高效化管理。
截至目前，我们已经能实现Pod部署、Deployment管理应用、Service提供稳定访问入口、PV/PVC实现数据持久化、ConfigMap/Secret管理配置，但在生产环境中，还会遇到一个核心需求：多Service统一访问入口、HTTPS加密访问、路径路由转发。比如，你在集群内部部署了Nginx、MySQL、Spring Boot三个应用，每个应用对应一个Service，若想通过集群外部的一个域名，分别访问这三个应用（如通过www.example.com/nginx访问Nginx、www.example.com/api访问Spring Boot），同时实现HTTPS加密，仅靠Service是无法实现的。

为了解决这个问题，K8s提供了Ingress（入口控制器）组件。Ingress本质上是“集群外部访问集群内部服务的统一入口”，它通过域名和路径路由，将外部请求转发到对应的Service，同时支持HTTPS加密、负载均衡、路径重写等高级功能，是生产环境中实现集群外部访问的标准方案。
本文依然针对小白，延续系列“全程实操、命令可复制、yaml可复用”的风格，从“为什么需要Ingress、Ingress核心概念、Ingress Controller部署、Ingress路由配置、HTTPS SSL配置、企业级最佳实践、常见问题排错”七个维度，手把手教你掌握Ingress全用法，帮你彻底解决多服务统一访问、HTTPS加密的难题，完善K8s实战技能栈，打通集群内外访问的最后一道关卡。

前置要求：已搭建好K8s集群，掌握Pod、Deployment、Service、ConfigMap/Secret的基本概念和kubectl常用命令（参考前七篇教程）；需准备一个可用的域名（测试环境可修改本地hosts文件模拟，生产环境需备案域名）；需提前准备SSL证书（测试环境可自签证书，生产环境需使用权威机构证书）。

一、先搞懂：为什么必须用Ingress？（核心痛点剖析）

在学习Ingress之前，我们先回顾一下Service的访问方式，剖析其局限性，理解Ingress的设计意义——Service能解决“Pod IP动态变化”的问题，但无法满足生产环境中多服务统一访问、HTTPS加密等高级需求。

1.1 Service访问方式的3大局限性
我们之前学习的Service有三种类型（ClusterIP、NodePort、LoadBalancer），其中NodePort和LoadBalancer可实现外部访问，但存在明显局限性：

端口管理混乱：每个Service若使用NodePort类型，需要占用一个30000-32767之间的端口，当集群内应用增多（如10个、20个应用），端口会变得难以管理，且外部访问需要记住“IP+端口”，体验极差（如http://192.168.1.100:30080访问Nginx、http://192.168.1.100:30081访问Spring Boot）。
无法实现路径路由：无法通过同一个域名、不同路径，访问不同的Service。比如，无法实现“访问www.example.com/nginx转发到Nginx Service，访问www.example.com/api转发到Spring Boot Service”，只能通过不同端口或不同IP区分。
不支持HTTPS加密：Service本身不具备HTTPS加密能力，若想实现HTTPS访问，需要在每个应用内部配置SSL证书，配置繁琐、维护成本高，且无法实现统一的SSL证书管理。

1.2 Ingress的核心价值

Ingress的核心目标，就是“解决Service外部访问的局限性”，提供统一的入口管理和高级访问功能，核心价值体现在4点：

统一访问入口：通过一个域名（如www.example.com），作为集群外部访问的唯一入口，无需记住多个“IP+端口”，简化访问方式。
路径路由转发：通过不同的路径（如/nginx、/api），将外部请求转发到对应的Service，实现“一个域名对应多个服务”。
HTTPS加密支持：支持统一配置SSL证书，实现HTTPS加密访问，无需在每个应用内部配置证书，简化证书管理。
负载均衡与高可用：Ingress本身集成负载均衡功能，可将请求分发到后端多个Pod，同时支持Ingress Controller多副本部署，实现高可用，避免单点故障。

补充：Ingress本身不是“服务”，而是一个“路由规则的集合”，真正实现路由转发、HTTPS加密的是「Ingress Controller」（入口控制器）。Ingress定义“如何转发请求”，Ingress Controller负责“执行转发规则”，二者协同工作，缺一不可。

二、Ingress核心概念（必懂）

小白学习Ingress，只需掌握3个核心概念：Ingress Controller、Ingress、Ingress Class，三者分工明确，协同实现集群外部访问的统一管理。

2.1 Ingress Controller（入口控制器）
Ingress Controller是实际执行路由规则的组件，本质上是一个“运行在K8s集群内的Pod”，内置了反向代理服务器（如Nginx、Traefik、HAProxy），负责监听Ingress资源的变化，将Ingress定义的路由规则，转换为反向代理服务器的配置（如Nginx的nginx.conf），并执行请求转发。

核心特点：

Ingress Controller是Ingress的“执行者”，没有Ingress Controller，Ingress定义的规则毫无意义；
常用的Ingress Controller有：Nginx Ingress Controller（最常用，基于Nginx）、Traefik（轻量级，自动配置）、HAProxy Ingress Controller；
Ingress Controller需要通过NodePort或LoadBalancer类型的Service暴露到集群外部，供外部请求访问。

简单理解：Ingress Controller就像是“集群的大门守卫”，外部请求首先到达大门守卫，守卫根据Ingress定义的规则，将请求转发到对应的“房间”（Service/应用）。

2.2 Ingress（路由规则）

Ingress是K8s中的一种资源，用于定义“外部请求如何转发到集群内部Service”的路由规则，本质上是“路由规则的集合”，可包含多个域名、多个路径的路由配置。
核心要素：

域名（host）：外部访问的域名（如www.example.com），Ingress Controller通过域名匹配请求；
路径（path）：域名下的具体路径（如/nginx、/api），通过路径匹配请求；
后端服务（backend）：路径对应的集群内部Service，请求会被转发到该Service，再由Service转发到Pod；
SSL证书：可选，配置HTTPS时需要关联Secret中的SSL证书。

2.3 Ingress Class（分类标识）
Ingress Class用于“关联Ingress和Ingress Controller”，当集群内部署了多个Ingress Controller（如同时部署Nginx和Traefik），可通过Ingress Class指定某个Ingress由哪个Ingress Controller执行。

核心特点：

每个Ingress Controller会关联一个Ingress Class（如nginx、traefik）；
每个Ingress会通过ingressClassName字段，指定对应的Ingress Class，从而关联到对应的Ingress Controller；
测试环境中若只部署一个Ingress Controller，可省略Ingress Class配置（使用默认值）。

三、实战1：部署Nginx Ingress Controller（核心步骤）

Ingress Controller有多种实现，其中「Nginx Ingress Controller」是最常用、最成熟的方案，基于Nginx反向代理实现，兼容性好、配置灵活。本节我们实操部署Nginx Ingress Controller，步骤可直接复制执行。

3.1 前置准备：创建命名空间

为了规范管理，我们将Ingress Controller部署在专门的命名空间（ingress-nginx）中，避免与业务应用混淆。

# 创建命名空间ingress-nginx
kubectl create namespace ingress-nginx
# 查看命名空间，确认创建成功
kubectl get namespaces

3.2 部署Nginx Ingress Controller

我们使用官方提供的yaml文件部署，适用于大多数K8s集群（1.19+版本），命令可直接复制执行：

# 部署Nginx Ingress Controller（官方yaml）
kubectl apply -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/controller-v1.8.2/deploy/static/provider/cloud/deploy.yaml

# 查看ingress-nginx命名空间下的Pod，确认Ingress Controller启动成功
kubectl get pods -n ingress-nginx
# 查看Ingress Controller对应的Service（默认是LoadBalancer类型，云环境会自动分配公网IP）
kubectl get svc -n ingress-nginx

关键说明：

如果是本地集群（如Minikube、Docker Desktop），LoadBalancer类型的Service无法获取公网IP，可将Service类型改为NodePort（后续步骤会讲解修改方法）；
Pod启动可能需要1-2分钟，耐心等待，直到Pod状态变为Running；
Ingress Controller对应的Service名称为ingress-nginx-controller，默认暴露80（HTTP）和443（HTTPS）端口。

3.3 （可选）修改Service类型为NodePort（本地集群适用）

本地集群（如Minikube）无法使用LoadBalancer类型的Service（无法分配公网IP），需将ingress-nginx-controller Service改为NodePort类型，通过“Node IP+NodePort”访问Ingress Controller。

# 编辑Ingress Controller的Service
kubectl edit svc ingress-nginx-controller -n ingress-nginx
# 进入编辑模式，将spec.type改为NodePort，保存退出
# 修改后，查看Service，获取NodePort端口（80对应http端口，443对应https端口）
kubectl get svc -n ingress-nginx

示例输出（重点看PORT(S)字段）：

NAME                                 TYPE       CLUSTER-IP       EXTERNAL-IP   PORT(S)                      AGE
ingress-nginx-controller             NodePort   10.109.242.198   <none>        80:30080/TCP,443:30443/TCP   5m

说明：此时HTTP访问端口为30080，HTTPS访问端口为30443，后续外部访问需使用“Node IP:30080”“Node IP:30443”。

3.4 验证Ingress Controller部署成功

部署完成后，我们通过curl命令验证Ingress Controller是否正常工作（本地集群需使用Node IP+NodePort，云环境使用EXTERNAL-IP）：

# 本地集群（Node IP为192.168.1.100，NodePort为30080）
curl http://192.168.1.100:30080
# 云环境（EXTERNAL-IP为47.xxx.xxx.xxx）
curl http://47.xxx.xxx.xxx

# 正常输出：404 Not Found（因为还未配置Ingress路由规则，属于正常现象）

若能输出404页面，说明Ingress Controller部署成功，已准备好接收外部请求并转发。

四、实战2：Ingress路由配置（核心实操）

Ingress Controller部署完成后，我们需要创建Ingress资源，定义路由规则——将外部请求（通过域名+路径）转发到集群内部的Service。本节我们将部署两个测试应用（Nginx、Tomcat），通过Ingress实现“同一个域名、不同路径”访问不同应用。

4.1 前置准备：部署测试应用和Service

先部署两个测试应用（Nginx、Tomcat），并创建对应的ClusterIP类型Service（无需暴露到外部，由Ingress转发请求）。

步骤1：部署Nginx应用和Service

# 创建nginx-deploy.yaml文件
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deploy
spec:
  replicas: 2
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.24
        ports:
        - containerPort: 80

# 创建nginx-service.yaml文件
apiVersion: v1
kind: Service
metadata:
  name: nginx-service
spec:
  selector:
    app: nginx
  ports:
  - port: 80
    targetPort: 80
  type: ClusterIP  # 集群内部访问，无需暴露到外部

# 部署Nginx Deployment和Service
kubectl apply -f nginx-deploy.yaml
kubectl apply -f nginx-service.yaml
# 查看Pod和Service状态，确保正常运行
kubectl get pods -l app=nginx
kubectl get svc nginx-service

步骤2：部署Tomcat应用和Service

# 创建tomcat-deploy.yaml文件
apiVersion: apps/v1
kind: Deployment
metadata:
  name: tomcat-deploy
spec:
  replicas: 2
  selector:
    matchLabels:
      app: tomcat
  template:
    metadata:
      labels:
        app: tomcat
    spec:
      containers:
      - name: tomcat
        image: tomcat:9.0
        ports:
        - containerPort: 8080

# 创建tomcat-service.yaml文件
apiVersion: v1
kind: Service
metadata:
  name: tomcat-service
spec:
  selector:
    app: tomcat
  ports:
  - port: 8080
    targetPort: 8080
  type: ClusterIP

# 部署Tomcat Deployment和Service
kubectl apply -f tomcat-deploy.yaml
kubectl apply -f tomcat-service.yaml
# 查看Pod和Service状态，确保正常运行
kubectl get pods -l app=tomcat
kubectl get svc tomcat-service

4.2 配置Ingress路由规则（HTTP访问）
创建Ingress资源，定义路由规则：访问www.test.com/nginx转发到nginx-service，访问www.test.com/tomcat转发到tomcat-service（测试环境可修改本地hosts文件，将www.test.com映射到Ingress Controller的IP）。

步骤1：创建Ingress yaml文件

# 创建ingress-test.yaml文件
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: test-ingress
  annotations:
    # 可选：配置Nginx相关参数（如路径重写）
    nginx.ingress.kubernetes.io/rewrite-target: /  # 路径重写：将/www.test.com/nginx重写为/，避免应用无法识别路径
spec:
  ingressClassName: nginx  # 关联Nginx Ingress Controller（必须与Ingress Controller的Ingress Class一致）
  rules:
  # 第一个路由规则：域名www.test.com，路径/nginx
  - host: www.test.com  # 外部访问的域名（测试环境需配置hosts）
    http:
      paths:
      - path: /nginx  # 访问路径
        pathType: Prefix  # 路径匹配模式：前缀匹配（/nginx/xxx也会匹配）
        backend:
          service:
            name: nginx-service  # 对应的Service名称
            port:
              number: 80  # 对应Service的端口
  # 第二个路由规则：域名www.test.com，路径/tomcat
  - host: www.test.com
    http:
      paths:
      - path: /tomcat
        pathType: Prefix
        backend:
          service:
            name: tomcat-service
            port:
              number: 8080

关键参数说明：

ingressClassName: nginx：关联Nginx Ingress Controller，必须正确填写（默认就是nginx，无需修改）；
host: www.test.com：外部访问的域名，测试环境需在本地hosts文件中添加映射（如192.168.1.100 www.test.com）；
pathType: Prefix：路径匹配模式，常用的有3种：Prefix（前缀匹配）、Exact（精确匹配）、ImplementationSpecific（由Ingress Controller决定）；
nginx.ingress.kubernetes.io/rewrite-target: /：路径重写，比如访问/www.test.com/nginx，会重写为/，避免Nginx应用无法识别/nginx路径（若不重写，Nginx会去寻找/nginx目录，导致404）。

步骤2：部署Ingress并查看状态

# 部署Ingress
kubectl apply -f ingress-test.yaml
# 查看Ingress状态，确认规则生效（STATUS为Ready）
kubectl get ingress test-ingress
# 查看Ingress详细信息，确认路由规则配置正确
kubectl describe ingress test-ingress

关键说明：若Ingress的STATUS为Ready，说明路由规则已被Ingress Controller识别并生效；若为Pending，检查Ingress Controller是否正常运行、ingressClassName是否正确。

步骤3：配置本地hosts（测试环境）
测试环境没有真实域名，需修改本地hosts文件，将www.test.com映射到Ingress Controller的IP（本地集群用Node IP，云环境用EXTERNAL-IP）：

# Windows系统：编辑C:\Windows\System32\drivers\etc\hosts
# Linux/Mac系统：编辑/etc/hosts
# 添加以下内容（替换为你的Ingress Controller IP）
192.168.1.100 www.test.com

步骤4：验证路由规则（HTTP访问）

通过浏览器或curl命令，验证不同路径的访问效果（本地集群需加上NodePort，云环境无需加端口）：

# 本地集群（NodePort为30080）
# 访问Nginx：www.test.com:30080/nginx
curl http://www.test.com:30080/nginx
# 访问Tomcat：www.test.com:30080/tomcat
curl http://www.test.com:30080/tomcat

# 云环境（EXTERNAL-IP为47.xxx.xxx.xxx）
curl http://www.test.com/nginx
curl http://www.test.com/tomcat

验证结果：访问/nginx能看到Nginx默认页面，访问/tomcat能看到Tomcat默认页面，说明Ingress路由转发生效。

五、实战3：HTTPS SSL配置（生产环境必做）

生产环境中，外部访问必须使用HTTPS加密，防止数据传输过程中被窃取、篡改。Ingress支持通过Secret挂载SSL证书，实现HTTPS加密访问，本节我们实操配置HTTPS，包括自签证书（测试用）和权威证书（生产用）。

5.1 步骤1：准备SSL证书
SSL证书分为“自签证书”（测试用，不被浏览器信任）和“权威证书”（生产用，如Let’s Encrypt、阿里云SSL证书），我们分别讲解。

场景1：自签SSL证书（测试用）
通过OpenSSL工具生成自签证书，适用于测试环境，步骤如下（需安装OpenSSL）：

# 1. 生成私钥（key文件）
openssl genrsa -out test.key 2048
# 2. 生成证书签名请求（csr文件），需填写域名（www.test.com）
openssl req -new -key test.key -out test.csr
# 填写信息时，Common Name（CN）需填写域名（如www.test.com），其他信息可随意填写
# 3. 生成自签证书（crt文件），有效期365天
openssl x509 -req -days 365 -in test.csr -signkey test.key -out test.crt

场景2：权威SSL证书（生产用）
生产环境需使用权威机构颁发的SSL证书（如Let’s Encrypt免费证书、阿里云付费证书），下载证书后，会得到两个核心文件：私钥文件（.key）、证书文件（.crt或.pem），无需额外处理，直接使用即可。

5.2 步骤2：创建Secret存储SSL证书

SSL证书属于敏感信息，需通过Secret存储（类型为kubernetes.io/tls），再由Ingress挂载使用。

# 创建Secret，存储SSL证书（替换test.crt和test.key为你的证书文件路径）
kubectl create secret tls test-ssl-secret --cert=test.crt --key=test.key
# 查看Secret，确认创建成功
kubectl get secret test-ssl-secret
# 查看Secret详细信息（证书已被Base64编码存储）
kubectl describe secret test-ssl-secret

关键说明：Secret的类型必须是kubernetes.io/tls，–cert指定证书文件（.crt/.pem），–key指定私钥文件（.key），名称可自定义（后续Ingress需引用该名称）。

5.3 步骤3：修改Ingress，配置HTTPS

修改之前的Ingress yaml文件，添加tls字段，关联存储SSL证书的Secret，实现HTTPS访问。

# 修改ingress-test.yaml文件，添加tls配置
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: test-ingress
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /
    # 可选：强制将HTTP请求重定向到HTTPS（生产环境推荐）
    nginx.ingress.kubernetes.io/ssl-redirect: "true"
spec:
  ingressClassName: nginx
  # 添加HTTPS配置
  tls:
  - hosts:
    - www.test.com  # 需与SSL证书的域名一致
    secretName: test-ssl-secret  # 关联存储SSL证书的Secret名称
  rules:
  - host: www.test.com
    http:
      paths:
      - path: /nginx
        pathType: Prefix
        backend:
          service:
            name: nginx-service
            port:
              number: 80
      - path: /tomcat
        pathType: Prefix
        backend:
          service:
            name: tomcat-service
            port:
              number: 8080

关键说明：

tls.hosts：必须与SSL证书的域名一致，否则会出现证书不匹配的错误；
tls.secretName：关联之前创建的存储SSL证书的Secret名称；
nginx.ingress.kubernetes.io/ssl-redirect: “true”：强制将HTTP请求重定向到HTTPS，生产环境推荐开启，确保所有访问都是加密的。

5.4 步骤4：部署修改后的Ingress并验证

# 重新部署Ingress
kubectl apply -f ingress-test.yaml
# 查看Ingress状态，确认STATUS为Ready
kubectl get ingress test-ingress

# 验证HTTPS访问（本地集群需加上HTTPS的NodePort，如30443）
# 本地集群
curl -k https://www.test.com:30443/nginx  # -k参数忽略自签证书的信任提示
curl -k https://www.test.com:30443/tomcat

# 云环境
curl -k https://www.test.com/nginx  # 权威证书可去掉-k参数
curl -k https://www.test.com/tomcat

验证结果：访问HTTPS地址能正常看到应用页面，浏览器地址栏会显示“小锁”图标（自签证书会显示警告，权威证书会显示正常），说明HTTPS配置生效；同时，访问HTTP地址会自动重定向到HTTPS地址（开启了ssl-redirect）。

六、Ingress 企业级最佳实践（面试必问）

前面的实操已经覆盖了Ingress的基本用法，本节补充生产环境中的最佳实践，帮助小白规范使用Ingress，避免踩坑，同时应对面试提问。

6.1 核心使用规范

按环境/应用拆分Ingress：不同环境（开发、测试、生产）、不同应用的Ingress路由规则，分别创建对应的Ingress资源，如test-ingress、prod-ingress、nginx-ingress，避免路由规则混乱，便于维护和排查问题。
配置HTTPS并强制重定向：生产环境必须开启HTTPS，使用权威SSL证书，同时配置ssl-redirect注解，强制将HTTP请求重定向到HTTPS，保障数据传输安全。
合理配置路径匹配模式：根据业务需求选择合适的路径匹配模式，精确匹配（Exact）用于固定路径（如/api/login），前缀匹配（Prefix）用于通用路径（如/api），避免路径冲突。
配置Ingress Controller高可用：Ingress Controller是集群外部访问的入口，必须部署多副本（至少2个），避免单点故障；同时，结合NodePort+负载均衡器（如阿里云SLB、Nginx负载均衡），实现Ingress Controller的高可用访问。

6.2 性能优化建议

开启Ingress缓存：通过nginx.ingress.kubernetes.io/proxy-cache注解，开启Nginx缓存，缓存静态资源（如图片、CSS、JS），减少后端Service的请求压力，提升访问速度。
限制请求速率：通过nginx.ingress.kubernetes.io/limit-rps注解，限制每秒请求数，防止恶意请求（如DDoS攻击）压垮后端应用。
配置连接超时时间：通过nginx.ingress.kubernetes.io/proxy-connect-timeout、nginx.ingress.kubernetes.io/proxy-read-timeout注解，配置连接超时、读取超时时间，避免长连接占用资源。

6.3 安全加固建议

限制访问来源：通过nginx.ingress.kubernetes.io/whitelist-source-range注解，配置允许访问的IP段（如公司内网IP），禁止外部非法IP访问，提升安全性。
保护SSL证书安全：SSL证书的Secret需限制权限，禁止非授权用户读取；生产环境使用权威证书，定期更新证书（避免证书过期）；禁止将证书文件明文存储在代码仓库或未授权目录。
禁用不必要的HTTP方法：通过nginx.ingress.kubernetes.io/limit-methods注解，禁用PUT、DELETE等不必要的HTTP方法，防止恶意请求修改或删除资源。

七、常见问题排错（小白必看）

在Ingress的实战过程中，小白很容易遇到路由转发失败、HTTPS配置异常等问题，本节整理了6个最常见的问题，给出详细的原因分析和解决方法，帮你快速排错。

问题1：Ingress状态为Pending，无法变为Ready
原因：1. Ingress Controller未正常运行（Pod状态不是Running）；2. ingressClassName配置错误，与Ingress Controller的Ingress Class不匹配；3. 集群内没有可用的Ingress Controller。

解决：1. 查看Ingress Controller的Pod状态（kubectl get pods -n ingress-nginx），重启异常Pod；2. 确认ingressClassName为nginx（与Nginx Ingress Controller一致）；3. 重新部署Ingress Controller。

问题2：访问Ingress域名，出现404 Not Found
原因：1. 本地hosts配置错误，域名未映射到Ingress Controller的IP；2. Ingress路由规则配置错误（如路径、Service名称、端口错误）；3. 后端Service未正常运行，或Pod未就绪；4. 未配置路径重写，导致应用无法识别路径。

解决：1. 检查本地hosts配置，确保域名映射正确；2. 查看Ingress详细信息（kubectl describe ingress），确认路由规则的路径、Service名称、端口正确；3. 查看后端Service和Pod状态，确保正常运行；4. 添加nginx.ingress.kubernetes.io/rewrite-target: /注解，配置路径重写。

问题3：HTTPS访问出现证书不匹配警告
原因：1. SSL证书的域名与Ingress的tls.hosts不一致；2. 自签证书未被浏览器信任；3. 证书已过期或损坏。
解决：1. 确认SSL证书的域名与Ingress的tls.hosts一致；2. 测试环境可忽略警告（curl加-k参数），生产环境需使用权威SSL证书；3. 更换未过期、完好的SSL证书。
问题4：HTTP请求无法重定向到HTTPS
原因：1. 未添加nginx.ingress.kubernetes.io/ssl-redirect: "true"注解；2. 注解配置错误（如值为false、拼写错误）；3. Ingress Controller未重新加载配置。

解决：1. 添加ssl-redirect注解，确保值为"true"（带引号）；2. 重新部署Ingress，让Ingress Controller加载新配置；3. 检查Ingress Controller日志，确认配置加载成功。

问题5：Ingress路由转发失败，报错“503 Service Unavailable”
原因：1. 后端Service未找到（名称、端口错误）；2. Service的selector与Pod的labels不匹配，导致Service无法关联到Pod；3. 后端Pod未就绪（如健康检查失败）。

解决：1. 检查Ingress路由规则中的Service名称、端口，确保与实际一致；2. 检查Service的selector和Pod的labels，确保匹配；3. 查看Pod状态，确保Pod处于Running状态，健康检查通过。

问题6：本地集群无法访问Ingress（Connection refused）
原因：1. Ingress Controller的Service类型为LoadBalancer，本地集群无法分配公网IP；2. NodePort端口未开放，或防火墙拦截；3. Ingress Controller的Pod未正常运行。

解决：1. 将Ingress Controller的Service改为NodePort类型，使用“Node IP+NodePort”访问；2. 开放NodePort端口（如30080、30443），关闭防火墙或添加规则；3. 重启Ingress Controller的Pod。

八、总结及下一篇预告
本文详细讲解了K8s服务发现的核心组件——Ingress，从“为什么需要Ingress”到“Ingress核心概念、Ingress Controller部署、路由配置、HTTPS SSL配置”，再到“企业级最佳实践和常见问题排错”，覆盖了小白入门Ingress的所有关键内容，帮你彻底解决“多Service统一访问入口、HTTPS加密、路径路由”的难题。

重点记住3点：

Ingress是路由规则集合，Ingress Controller是规则执行者，二者协同工作，缺一不可；常用的Ingress Controller是Nginx Ingress Controller；
Ingress核心功能是“统一入口、路径路由、HTTPS加密”，通过域名+路径将外部请求转发到对应的Service，简化外部访问方式；
生产环境中，需开启HTTPS、配置Ingress Controller高可用、限制访问权限，确保外部访问的安全和稳定。

下一篇文章，我们将学习K8s的高可用部署——《K8s 高可用实战：Deployment 进阶与 StatefulSet 全解析》，带你解决“无状态应用高可用、有状态应用部署”的问题，实现应用的稳定运行和故障自愈，敬请关注！

最后，如果你觉得这篇文章对你有帮助，欢迎点赞、收藏、关注，后续会持续更新K8s系列实战文章，从入门到精通，带你轻松搞定K8s！