ingress-nginx的一些小问题
问题1. 创建ingress时，后端的service可以是NodePort类型吗?
可以的，Ingress 后端的 Service 可以是 NodePort 类型，但一般情况下推荐使用 ClusterIP 类型。这是因为：
Ingress 工作原理概述
1. Ingress Controller（如 ingress-nginx）本质上就是一个普通 Pod，它会监听 HTTP/HTTPS 请求（通过 NodePort/LoadBalancer 方式暴露出来）
2. 在集群内部转发请求给指定的 Service（由 Ingress 规则指定）
3. Ingress Controller 只需要能在集群内访问到 Service 即可，不关心它是 NodePort 还是 ClusterIP。
所以：
Service 类型 是否能用作 Ingress 后端？ 推荐使用？ 说明
ClusterIP ✅ 是 ✅ 推荐 默认类型，适合与 Ingress 配合，内部访问即可
NodePort ✅ 是 ❌ 不推荐 虽然可用，但暴露到了节点端口，没必要
LoadBalancer ✅ 是 ❌ 不推荐 会占用公网 IP，多此一举，Ingress 已统一入口
为什么不推荐用 NodePort 作 Ingress 后端？
- 多暴露一个节点端口，无意义又有安全隐患；
- 并不会提升 Ingress 的访问能力；
- 如果你使用了 NodePort 类型，Ingress Controller 依然是通过 Service 名称访问的集群 IP（Cluster DNS），不会走 NodePort。
正确的做法：
使用 ClusterIP 类型的 Service 作为 Ingress 后端。
总结：
- Ingress 可以指向 NodePort 类型的 Service；
- 但不推荐这样做，因为 NodePort 是给 外部访问用的，而 Ingress 是通过 集群内部访问 Service；
- 最推荐的搭配是：Ingress + ClusterIP 类型的 Service。
问题2：创建 ingress规则时，需要指定域名，这个域名解析到哪里呢？
问题3：如果在公有云上部署，使用NodePort类型的Service+SLB,绕过ingress controller，这样做可以吗？
这个思路是完全可以的，很多在阿里云上的部署确实会用 SLB（负载均衡）直接配合 NodePort 类型的 Service，绕过 Ingress Controller，这种方式在某些场景下更简单直观。
可行方案：SLB + NodePort，不用 Ingress
工作流程：
- 你的应用在 K8s 内部通过 Deployment + Service 部署；
- Service 类型设置为 NodePort，暴露一个固定端口；
- 阿里云的 SLB（负载均衡）监听对应的端口，比如 30080；
- SLB 后端绑定所有 Node 的 IP；
- 客户端访问 SLB 的公网 IP，就能通过 SLB → NodePort → Pod；
示例场景
组件 类型 示例
Service NodePort 暴露 30080 → Pod 80
SLB （公网） TCP 监听器 监听 30080
节点绑定 所有 k8s 节点 192.168.x.x
优点
- 不用部署和配置 Ingress Controller；
- 配置直观，使用 SLB 控制台操作更简单；
- 适合服务数量少、路径路由不复杂的情况；
缺点 / 限制
- 没有基于域名/路径的转发能力（除非你在 SLB 配 HTTP/HTTPS 转发规则）；
- 每个服务都需要配置一个 SLB 或 SLB 转发端口，扩展性差；
- 无法使用 Kubernetes 的 Ingress 生态（如证书自动管理、rewrite、canary 等）；
如果你的服务比较简单或短期部署：
推荐用 NodePort + SLB，省事省资源。
如果你要部署多个域名、路径、做证书自动管理等：
推荐用 Ingress + SLB（配合 LoadBalancer 类型 Service），结构清晰，易扩展。
补充：SLB 配置建议
- 类型选择：TCP（或 HTTP 转发也可以）；
- 后端服务器组：绑定所有节点；
- 健康检查：使用对应的 NodePort 检查路径 /health 或 /；
- 保证每个节点都能转发到对应 Pod（Pod 分布在所有节点上 or kube-proxy 转发正常）。
问题4：如果使用NodePort类型的service，配合SLB, 支持七层转发吗？ 比如 访问/a路径转到 30001端口，访问/b路径转到30002端口？
如果使用 NodePort 类型的 Service 配合 SLB（负载均衡），可以支持七层（L7）转发，但有一些注意事项。
七层转发原理： 七层转发指的是基于 HTTP 协议的请求头（如路径、域名等）来决定流量的路由。SLB 可以根据 URL 路径或域名来进行转发，这样就能将 /a 路径的流量转发到一个端口（如 30001），而 /b 路径的流量转发到另一个端口（如 30002）。
工作原理：
1. SLB（七层负载均衡）：
• SLB 会接收来自客户端的 HTTP 请求（如 http://example.com/a）。
• 根据配置的路径规则（如 /a 和 /b），SLB 会将流量转发到不同的后端服务端口（例如，30001 和 30002）。
• 然后，SLB 将请求转发到集群的 NodePort 类型的 Service 对应端口。
2. NodePort Service：
• Kubernetes 中的 NodePort 类型的 Service 会暴露一个端口（如 30001 或 30002），它会在所有节点的相同端口上开放，供外部访问。
• SLB 将流量转发到这些 NodePort 上，由 Kubernetes 集群的 kube-proxy 转发到对应的 Pod。
配置步骤：
创建 NodePort 类型的 Service 首先，你需要为每个路径创建不同的 NodePort 类型的 Service。假设你有两个不同的路径 /a 和 /b，你可以为每个路径创建一个对应的service
apiVersion: v1
kind: Service
metadata:
name: service-a
spec:
selector:
app: my-app
ports:
- protocol: TCP
port: 80
targetPort: 8080
nodePort: 30001
type: NodePort
---
apiVersion: v1
kind: Service
metadata:
name: service-b
spec:
selector:
app: my-app
ports:
- protocol: TCP
port: 80
targetPort: 8081
nodePort: 30002
type: NodePort
这时，service-a 会暴露端口 30001，service-b 会暴露端口 30002。
配置 SLB 进行七层转发
接下来，在阿里云 SLB 控制台中进行配置：
1. 创建一个 HTTP 监听器，监听端口 80。
2. 设置转发规则：
• /a 路径的请求，转发到集群中的 NodePort 30001。
• /b 路径的请求，转发到集群中的 NodePort 30002。
3. 健康检查配置
• 配置健康检查路径 /health（或其他路径）来检测每个 NodePort 的健康状态。
• 确保健康检查能够正确返回，避免流量被转发到不健康的节点。
4. 域名解析配置
• 将你的域名（例如 example.com）解析到 SLB 的公网 IP 地址。
工作流程总结：
1. 用户访问 http://example.com/a，SLB 会根据路径 /a 将流量转发到 NodePort 30001。
2. 用户访问 http://example.com/b，SLB 会根据路径 /b 将流量转发到 NodePort 30002。
3. SLB 将流量转发到相应的 Kubernetes 节点上的 NodePort 服务，Kubernetes 会通过 kube-proxy 将流量路由到正确的 Pod。
注意事项：
1. 路径转发：SLB 在七层转发时，能够根据 HTTP 请求的路径（如 /a、/b）进行不同端口的转发，但前提是 SLB 本身必须支持 L7 转发。
2. 路径重写：如果你需要更复杂的路径转（比如 /a/* 转发到一个服务， /b/* 转发到另一个服务），SLB 支持路径重写，可以配置更多细节。
3. SLB 的性能：如果流量较大，使用 L7 转发可能会对 SLB 的性能带来一定压力，所以需要根据你的需求选择合适的 SLB 类型和配置。
4. SSL/TLS 加密：如果你使用 HTTPS（端口 443），你可以在 SLB 上配置 SSL 证书，然后让 SLB 负责解密，后续的流量转发是明文的。
总结： 使用 NodePort 类型的 Service 配合 SLB 是可以实现七层转发的。
• 你可以配置 SLB 来根据请求的路径（例如 /a 和 /b）将流量转发到不同的 NodePort 服务（30001 和 30002）。
• 这种方式简洁且高效，尤其适用于少量简单的路径转发，不需要复杂的 Ingress 控制器。
浙公网安备 33010602011771号