什么是Ingress（Ingress 资源）？
Ingress 是 Kubernetes 的一种 API 资源类型（类似 Deployment、Service），用于声明性地定义外部访问集群内服务的规则。其核心功能是：
-
指定 HTTP/HTTPS 路由规则（如域名、路径、TLS 证书等）。
-
不直接处理流量，仅存储路由配置（相当于“说明书”）。
什么又是Ingress 控制器（Ingress Controller）？
Ingress 控制器是一个实际运行的反向代理服务（如 Nginx、Traefik、Istio），负责监听 Ingress 资源的变化，并动态配置自身以实现路由规则。其核心功能包括：
-
监听 Kubernetes API 中的 Ingress 资源变更。
-
将 Ingress 规则转换为代理配置（如生成 Nginx 的
nginx.conf）。 -
处理外部流量（负载均衡、SSL 终止、路由转发等）。
以上两者又是什么关系？
-
Ingress：定义“应该怎么路由”（规则声明）。
-
Ingress 控制器：实现“实际怎么路由”（规则执行）。
类比理解
| 角色 | 类比 | 说明 |
|---|---|---|
| Ingress | 餐厅的菜单 | 告诉顾客（用户）有哪些菜品（服务） |
| Ingress 控制器 | 厨师和后厨系统 | 根据菜单实际制作菜品（处理请求） |
Ingress 控制器如何关联到 Ingress 资源？
-
默认关联：如果未显式指定
ingressClassName，某些控制器（如 Nginx）会监听所有 Ingress 资源。 -
显式关联：通过
ingressClassName或控制器特定的注解（如kubernetes.io/ingress.class: nginx）。
Kubernetes 安装后会默认安装Ingress 控制器吗？
在默认情况下，Kubernetes 不会自动安装 Ingress 控制器。安装 Kubernetes 集群（如使用 kubeadm、Minikube、kops 等工具）时，核心组件（如 API Server、Scheduler、Controller Manager 等）会被部署，但 Ingress 控制器需要用户手动选择并单独安装。
为什么 Kubernetes 不默认安装 Ingress 控制器？
-
灵活性
Ingress 控制器的选择依赖具体需求（如云厂商集成、功能特性），Kubernetes 避免强制绑定特定实现。 -
避免资源浪费
不是所有集群都需要 Ingress 功能（例如仅处理内部服务调用的集群）。 -
生态多样性
社区有多种 Ingress 控制器（Nginx、Traefik、Istio 等），由用户按需选择。
如何检查集群是否已安装 Ingress 控制器？
以Nginx Ingress 控制器为例：
kubectl get pods -n ingress-nginx # 检查 Nginx Ingress 控制器
kubectl get ingressclasses # 查看可用的 Ingress 控制器类型
#如果返回结果为空或显示 No resources found，则说明未安装。常见 Ingress 控制器及其插件生态
| Ingress 控制器 | 典型插件/扩展能力 |
|---|---|
| Nginx Ingress | 注解控制重定向、缓存、认证等 |
| Traefik | 中间件（Middleware）插件（如重试、压缩） |
| Istio IngressGateway | VirtualService 和 Gateway CRD |
| AWS ALB Ingress | 与 AWS 负载均衡器集成（ALB 特性） |
Nginx Ingress 和传统的 Nginx（负载均衡/反向代理）区别
Nginx Ingress 和传统的 Nginx（负载均衡/反向代理） 核心功能相似（都是处理 HTTP/HTTPS 流量），但它们在设计目标、使用场景和管理方式上有显著区别。
本质区别
| 维度 | Nginx Ingress | 传统 Nginx |
|---|---|---|
| 定位 | Kubernetes 原生流量入口控制器 | 通用的独立负载均衡/反向代理服务器 |
| 部署环境 | 专为 Kubernetes 设计，运行在集群内 | 可运行在任何环境（物理机、VM、容器等） |
| 配置方式 | 通过 Kubernetes Ingress 资源动态管理规则 | 手动修改 nginx.conf 文件或模板 |
| 动态能力 | 自动监听 Ingress 变化，实时更新配置 | 需手动重载或通过脚本/工具同步配置 |
架构差异
Nginx Ingress 架构
传统 Nginx 架构
使用场景
-
选择 Nginx Ingress 当：
-
你的应用运行在 Kubernetes 集群内。
-
需要自动化管理路由规则（如 CI/CD 自动发布）。
-
依赖 Kubernetes 生态（如 Cert-Manager 自动证书）。
-
-
选择传统 Nginx 当：
-
代理非 Kubernetes 服务（如传统虚拟机应用）。
-
需要深度定制 Nginx 配置（如自定义模块）。
-
环境简单，无需动态服务发现。
-
常见误解
-
Nginx Ingress ≠ Nginx
-
Nginx Ingress 是基于 Nginx 的定制化实现，专为 Kubernetes 优化。
-
传统 Nginx 是独立软件，不依赖 Kubernetes。
-
-
性能差异
-
Nginx Ingress 可能因动态配置引入少量开销，但通常可忽略。
-
-
是同一个 Nginx 核心：两者均基于 Nginx 的代理引擎。
-
不是同一个使用方式：Nginx Ingress 是 Kubernetes 化的封装，传统 Nginx 需手动运维。
-
如何选：
-
用 Kubernetes → Nginx Ingress；
-
非 Kubernetes 或需要绝对控制 → 传统 Nginx。
-
