一：七层负载均衡和四层负载均衡的对比
1：四层负载均衡
- 核心原理 ：基于 IP + 端口 的负载均衡，在三层负载均衡（VIP）基础上增加四层端口号，通过 NAT 处理流量，将同一 TCP/UDP 连接的所有流量转发至同一台后端服务器。
- 特点：仅关注网络层和传输层信息，转发效率高，能保持连接会话的一致性。
2：七层负载均衡
- 核心原理 ：基于 虚拟 URL 或主机 IP 的负载均衡，依赖四层负载均衡基础，进一步解析应用层特征（如 URL、浏览器类型、语言等）来做流量分发。
- 典型场景 ：
- 根据用户访问的 URL 路径，将请求转发到不同的服务集群。
- 根据用户语言偏好，自动分配到对应语言的服务器组（如中文 / 英文服务集群）。
- 特点：粒度更细，能感知应用层内容，但性能开销略高于四层负载均衡。
3：核心区别总结
| 维度 | 四层负载均衡 | 七层负载均衡 |
|---|---|---|
| 工作层级 | 传输层（TCP/UDP） | 应用层（HTTP/HTTPS 等） |
| 决策依据 | IP + 端口 | URL、主机头、请求内容、语言等 |
| 性能 | 更高，转发逻辑简单 | 稍低，需解析应用层内容 |
| 场景 | 通用流量转发、保持会话 | 精细化应用路由、内容感知分发 |
二：k8s当中为什么要做负载均衡
1. Pod 漂移问题
Kubernetes 具备强大的副本控制能力，当 Pod 挂掉时会自动在其他节点启动新 Pod，同时支持动态扩容。这导致 Pod 会在任意节点上被创建或销毁，Pod IP 会动态变化，无法直接用固定 IP 访问。
2. 解决方案：Service 机制
通过 Kubernetes 的 Service 机制解决动态 Pod IP 的暴露问题：
- Service 以标签（Label）选定一组匹配的 Pod，自动监控并负载均衡它们的 Pod IP。
- 对外仅暴露 Service IP，实现服务发现与访问的稳定性。
3. NodePort 模式详解
NodePort 是 Service 的一种暴露模式：
- 原理：在每个节点上开放一个固定端口（NodePort），将流量转发到内部 Service，再路由到对应 Pod。
- 访问格式 ：
http://<nodeIP>:<nodePort>/ - 数据包流向：客户端请求 → Node 节点的 IP:Port → Service 的 IP:Port → Pod 的 IP:Port
4：NodePort 暴露服务的问题
当服务数量增多时，NodePort 会在每个节点上开启大量端口，端口管理和维护变得极为复杂，难以规模化。
5：Nginx 转发的实现思路
- 网络基础：Kubernetes 中 Pod 之间可互通，Pod 可共享宿主机网络名称空间，此时 Pod 监听的端口等价于 Node 节点的端口。
- 具体实现 ：
- 使用 DaemonSet 在每个 Node 上部署 Nginx Pod，让其监听宿主机的 80 端口（类似 NodePort 绑定宿主机端口）。
- 配置 Nginx 转发规则，将外部请求转发到集群内部对应的 Service IP 上。
- 这样外部只需访问节点 80 端口，由 Nginx 统一路由到内部服务，避免了大量 NodePort 端口的维护问题。
6：域名分配及动态更新问题
从上面的方法，采用 Nginx-Pod 似乎已经解决了问题，但是这里面有一个很大缺陷：当每次有新服务加入又该如何修改 Nginx 配置呢？
我们知道使用 Nginx 可以通过虚拟主机域名进行区分不同的服务，而每个服务通过 upstream 进行定义不同的负载均衡池，再加上 location 进行负载均衡的反向代理，在日常使用中只需要修改 nginx.conf 即可实现，那在 K8S 中又该如何实现这种方式的调度呢？
假设后端的服务初始服务只有 ecshop，后面增加了 bbs 和 member 服务，那么又该如何将这 2 个服务加入到 Nginx-Pod 进行调度呢？总不能每次手动改或者 Rolling Update 前端 Nginx Pod 吧。此时 Ingress 出现了，如果不算上面的 Nginx，Ingress 包含两大组件：Ingress Controller 和 Ingress。
三：Ingress和IngressController
1：Ingress介绍
在 Kubernetes 中，Ingress 是一种 API 对象，它充当了将外部网络流量路由到 Kubernetes 集群内部服务的入口。它是一个规范化的流量管理方式，可以方便地进行配置和管理。
Ingress 支持扩展的路由规则，包括基于主机、路径、HTTP 方法和其他 Web 请求流量的路由控制。这使得 Ingress 成为将 Kubernetes 作为 Web 应用程序托管解决方案时的一个理想选择。
在 Kubernetes 中，使用不同的 Ingress Controller 来实现 Ingress 规范。实际上，Ingress Controller 是一种 Kubernetes 部署，它通过 Ingress API 对象接收流量，实现请求路由和负载平衡等功能。Nginx Ingress Controller、Traefik Ingress Controller、HAProxy Ingress Controller 等常用于 Kubernetes 中。
总之，Kubernetes Ingress 是一种定义配置和路由网络流量的规范，而 Ingress Controller 是用于实现 Ingress 规范的 Kubernetes 部署。
2：Ingress Controller介绍
在 Kubernetes 中，Ingress Controller 是一种特殊的 Kubernetes 部署，它通过实现 Ingress 规范来将外部的网络流量路由到 Kubernetes 集群内部的服务。Ingress Controller 通常是作为 Pod 来运行的，它们使用 Ingress 规范中定义的路由规则和负载平衡算法来将请求路由到正确的服务实例中。
**Kubernetes 本身并没有提供 Ingress Controller 的实现，而是通过官方提供的 API 规范来定义 Ingress 对象。**实际上，Ingress 规范仅定义了路由规则，而不涉及任何负载平衡、SSL 终止等方面的细节。因此，为了实现 Ingress 规范，需要使用不同的 Ingress Controller 来构建完整的网络流量路由和负载平衡方案。
常用的 Ingress Controller 有 Nginx Ingress Controller、Traefik Ingress Controller、HAProxy Ingress Controller 等等。这些 Ingress Controller 除了实现 Ingress 规范，还提供了一些扩展功能，例如基于策略的负载均衡、SSL 卸载以及基于 HTTP 重定向的路由等功能。
Ingress Controller 这东西就是解决 "Nginx 的处理方式" 的。Ingress Controller 通过与 Kubernetes API 交互，动态的去感知集群中 Ingress 规则变化，然后读取他，按照他自己模板生成一段 Nginx 配置，再写到 Nginx Pod 里，最后 reload 一下。
实际上 Ingress 也是 Kubernetes API 的标准资源类型之一，它其实就是一组基于 DNS 名称（host）或 URL 路径把请求转发到指定的 Service 资源的规则。用于将集群外部的请求流量转发到集群内部完成的服务发布。
我们需要明白的是，Ingress 资源自身不能进行 "流量穿透"，仅仅是一组规则的集合，这些集合规则还需要其他功能的辅助，比如监听某套接字，然后根据这些规则的匹配进行路由转发，这些能够为 Ingress 资源监听套接字并将流量转发的组件就是 Ingress Controller。
总之，Kubernetes Ingress Controller 是为实现 Ingress 规范而设计的 Kubernetes 部署，它通过定义路由规则来将外部的网络流量路由到 Kubernetes 服务之中，并提供负载均衡、SSL 卸载等额外功能。
四：使用Ingress controller代理k8s内部的流程
使用 Ingress Controller 代理 Kubernetes 内部应用的流程大致如下：
1、创建一个新的 Kubernetes Service：Ingress Controller 需要知道要将流量路由到哪个 Service 上，因此首先需要创建一个新的 Service 对象，可以使用 Deployment 或 Pod 来创建后端服务，或使用 ServiceType: ClusterIP 来创建一个单独的 Service 对象。
2、安装 Ingress Controller：为了将外部流量路由到内部 Kubernetes 应用程序，需要安装并配置一种 Ingress Controller，例如 Nginx Ingress Controller、Traefik Ingress Controller 或 HAProxy Ingress Controller。通常情况下，可以使用 Helm Charts 或者官方提供的 YAML 文件来安装 Ingress Controller。
3、创建 Ingress 对象并定义路由规则：创建一个新的 Ingress 对象，并定义流量路由规则。路由规则可以基于主机、路径、HTTP 方法和其他 Web 请求流量进行控制，并且可以在不同服务间进行负载均衡。
4、检查 Ingress 资源是否正常运行：使用 kubectl 命令检查新创建的 Ingress 资源的状态，确保它被成功地应用到 Kubernetes 集群中，并且可以正常处理流量。
在完成这些步骤以后，就可以使用 Ingress Controller 将外部流量路由到 Kubernetes 内部应用程序了。需要注意的是，Ingress Controller 代理内部应用程序的方式会根据不同的 Ingress Controller 而异，具体取决于实际的配置。
五：Ingress 应用场景
Kubernetes Ingress 是一种路由网络流量的规范，它提供了在 Kubernetes 中将外部流量路由到集群内部服务的标准化方式。下面是一些 Kubernetes Ingress 的应用场景：
1、Web 应用程序：对于基于 Web 的应用程序，可以使用 Kubernetes Ingress 将不同的路径和主机名路由到不同的服务，实现灵活的请求路由和负载均衡。
2、API Gateway：在微服务架构中，API Gateway 是将多个微服务后端聚合到一个入口点的一种常见模式。使用 Kubernetes Ingress 可以很容易地实现 API Gateway 模式，并提供灵活的请求路由、负载均衡和 API 版本控制等功能。
3、SSL/TLS 终止点：Kubernetes Ingress 可以在请求进入集群内部之前进行 SSL/TLS 协议的终止。这可以让应用程序仅需要处理普通 HTTP 请求，而由 Ingress Controller 处理加密和解密的过程。
4、应用程序流量控制：可以通过 Kubernetes Ingress 设置流量规则和限制，对外部请求进行限制，减少恶意攻击并保护应用程序免受 DDoS 攻击。
总之，Kubernetes Ingress 可以在不同的应用场景中提供灵活的请求路由、负载均衡和访问控制等功能，是一种强大的网络流量路由解决方案。
六：总结归纳
1. 请解释 K8s 中 Ingress（7 层）和 Service（4 层）的核心区别，以及 "4 层 / 7 层" 的含义？
- 4 层 / 7 层：对应 OSI 网络模型，4 层是传输层（TCP/UDP），只识别 IP + 端口；7 层是应用层（HTTP/HTTPS），能识别域名、URI 路径、请求头、Cookie 等应用层内容。
- Service（4 层）：工作在传输层，核心作用是 Pod 的稳定入口 + 4 层负载均衡，仅根据 IP + 端口转发流量，无法识别域名 / URI，适用于服务间通信、TCP/UDP 服务。
- Ingress（7 层）：工作在应用层，依赖 Ingress Controller（如 Nginx）实现，核心作用是集群外网统一入口，能基于域名 / URI 路径做路由分发，还支持 SSL 卸载、限流等高级功能，适用于 HTTP/HTTPS 服务。
2. 请描述 K8s 中外部请求通过 Ingress 访问应用 Pod 的完整流量链路？
参考答案：完整链路：外网请求 → Ingress Controller 的 Service（4 层入口，NodePort/LoadBalancer 暴露） → Ingress Pod（7 层解析：匹配域名 / URI） → 应用 Service（4 层负载均衡，匹配 Pod 标签） → 应用 Pod。核心逻辑：Ingress Service 负责 "外网进集群"，Ingress Pod 负责 "7 层路由分发"，应用 Service 负责 "Pod 的 4 层负载"，最终到业务 Pod。
3. 场景题：某应用有 4 个 Pod，均带标签 app=myapp，其中 2 个额外带 app1=daochu。要求：URI 含 /daochu/ 的请求仅打到这 2 个特殊 Pod，其他请求打到任意 4 个 Pod；且应用代码不可修改、不能返回 404 / 重定向。请说明实现方案？
参考答案：核心方案：双 Service + Ingress 多路径匹配（唯一无代码侵入的方案），步骤如下：① 创建两个 Service：
- Service A（myapp-all）：selector 为 app=myapp，匹配所有 4 个 Pod；
- Service B（myapp-daochu）：selector 为 app=myapp && app1=daochu，仅匹配 2 个特殊 Pod；② 配置 Ingress 规则：
- 优先级匹配 /daochu (/|$)(.*) 路径，转发到 Service B；
- 所有其他路径转发到 Service A；③ 关键：Ingress 需开启正则匹配（如 nginx.ingress.kubernetes.io/use-regex: "true"），确保路径匹配精准。
4. 上述场景中，能否仅用单个 Service 实现该分流需求？为什么？
参考答案：不能。原因：
- Service 是 4 层负载均衡，仅能按标签筛选 Pod（要么匹配所有 4 个，要么匹配 2 个），无法识别 URI 路径；
- 若用单个 Service 匹配所有 4 个 Pod，流量会随机转发到任意 Pod，而应用代码不可修改、不能 404 / 重定向，无法过滤 /daochu/ 请求；
- 仅双 Service 能实现 "标签级 Pod 筛选"，结合 Ingress 的 "路径级路由"，才能精准分流。
5. K8s Service 的默认负载均衡策略是什么？能否修改？Service 的负载均衡能否做到和 Ingress 一样复杂？为什么？
参考答案：① 默认策略：
- kube-proxy 默认是 iptables 模式：基于概率的随机分发；
- 若切换为 IPVS 模式：默认是轮询（RR）；② 能否修改：仅当 kube-proxy 切换为 IPVS 模式时，可通过注解（service.kubernetes.io/ipvs-scheduler）修改为加权轮询（wrr）、最小连接数（lc）、源 IP 哈希（sh）等基础策略；iptables 模式无法修改。③ 能否和 Ingress 一样复杂：不能。核心原因：Service 是 4 层（传输层）转发，仅识别 IP + 端口，无法识别域名 / URI / 请求头等应用层内容；而 Ingress 是 7 层（应用层），能基于这些内容实现路径级、域名级的复杂策略（限流、黑白名单、SSL 卸载等），Service 仅能做 Pod 级的基础 4 层负载，无法实现应用级的复杂控制。
6. 为什么 Ingress 必须依赖 Ingress Controller 才能生效？Ingress 和 Ingress Controller 的关系是什么？
参考答案：
- Ingress 本身只是 "路由规则的声明"（YAML 配置），不具备实际转发能力；
- Ingress Controller（如 Nginx/Traefik）是具体的运行态组件（以 Pod 形式部署），负责监听 Ingress 规则的变化，并将规则转化为自身的配置（如 Nginx.conf），最终实现 7 层路由转发；
- 关系：Ingress 是 "规则"，Ingress Controller 是 "规则的执行者"，无 Controller 的 Ingress 规则仅为无效配置。