第十章 Kubernetes Helm 部署 Nginx Ingress 及功能实验
一、Nginx Ingress 核心特性说明
Nginx Ingress 作为 Ingress 控制器的实现，核心特性与独立外部负载均衡服务存在明显差异：
- Nginx Ingress 会自动监听配置文件变化并自动应用更新，无需手动重启服务
- 传统独立外部负载均衡服务修改配置后需要重启进程，重启过程可能导致用户请求丢失，是有代价的操作
- 因此 Nginx Ingress 的架构设计会尽可能减少重启次数，降低对业务的影响，这也是其架构设计的核心目标之一
二、Ingress-nginx 部署全流程
2.1 前置准备
- 视频提供配套压缩包，包含 Nginx Ingress 的 Helm Chart 文件及所需容器镜像，镜像已提前导入（官方镜像仓库位于海外，直接下载速度慢）
- 操作步骤：将压缩包保存到本地桌面后传入服务器
2.2 解压与目录说明
- 进入「第十章/第四节课」目录，解压压缩包
- 进入解压后的根目录，包含两个子目录：
chart目录：存放 Nginx Ingress 的 Helm Chart 包image目录：存放部署所需的容器镜像
2.3 镜像导入
- 将
image目录下的镜像分别导入到 N1、N2 两个节点的本地镜像仓库：两个节点的 Pod 都会运行 Nginx Ingress 相关组件，需要提前导入镜像避免拉取失败 - 后续部署私有镜像仓库后，无需逐个节点导入镜像，只需将镜像推送到中心私有仓库即可完成所有节点的镜像拉取
2.4 修改 values.yaml 核心配置
进入 chart 目录下的 values.yaml 文件，需要修改以下配置项：
- 开启 hostNetwork
- 默认关闭，开启后 Ingress Pod 的网络命名空间不与主机独立创建，而是与物理机共享网络栈，作用等同于 Pod 的
hostNetwork: true配置
- 默认关闭，开启后 Ingress Pod 的网络命名空间不与主机独立创建，而是与物理机共享网络栈，作用等同于 Pod 的
- **修改 dnsPolicy 为
ClusterFirstWithHostNetwork**- 两种 DNS 策略的区别：
- 开启
ClusterFirstWithHostNetwork时使用该策略：Pod 优先使用物理机的 DNS 解析请求，未匹配到记录时再使用集群内部 DNS 解析 - 未开启
ClusterFirstWithHostNetwork时使用默认ClusterFirst策略：直接使用集群内部 DNS 解析，未匹配到记录时向上级 DNS（物理机 DNS / 根域服务器）发起外部解析
- 开启
- 两种 DNS 策略的区别：
- 修改调度器类型为 DaemonSet
- 默认调度器类型为 Deployment，改为 DaemonSet 的优势：每个物理节点有且仅有一个 Ingress Pod 运行，避免多副本被调度到同一节点导致的单点风险，稳定性更高
- 关闭所有容器的 digest 校验
- 避免节点上已有的镜像 digest 与默认配置不一致，导致 Pod 重复拉取镜像，增加不必要的开销
- 设置默认 Ingress 类名
- 集群可能同时部署多个 Ingress 实现（如 Nginx Ingress、HAProxy Ingress、APISIX Ingress 等），通过类名区分不同 Ingress 控制器
- 将 Nginx Ingress 的类名设置为默认类名，未指定类名的 Ingress 对象默认由 Nginx Ingress 处理
2.5 Helm 安装与验证
- 第一步：创建名为
ingress的命名空间
kubectl create ns ingress - 第二步：执行 Helm 安装命令，基于当前 chart 目录安装 Nginx Ingress，Chart 名称为
ingress-nginx，指定安装到ingress命名空间
[root@k8s-master01 ingress-nginx]# helm install ingress-nginx -n ingress . -f values.yaml - 验证：查看
ingress命名空间下的 Pod，确认两个核心 Ingress Pod 已处于 Running 状态
kubectl get pod -n ingress
三、实验1：Ingress 代理 HTTP 服务
3.1 实验资源准备
创建以下三类资源对象：
- Deployment：使用 1.0 版本的 myapp 镜像创建应用 Pod，标签为
app=myapp:v1.0 - Service：名称为
http-proxy-svc，类型为 ClusterIP，匹配上述 Deployment 的 Pod 标签，暴露 80 端口 - Ingress 资源对象：类名为
nginx，配置规则：主机名为www1.xinxianghongfu.com，路径/采用基本路径匹配，后端指向上述 Service 的 80 端口
3.2 配置与验证
- 创建 Ingress 对应的 yaml 文件并执行
kubectl apply应用 - 配置本地 hosts 解析：将
www1.xinxianghongfu.com解析到 Master 节点 IP（Nginx Ingress 采用 DaemonSet 部署时，每个节点的 80/443 端口可直接通过物理机 IP 访问） - 浏览器访问
www1.xinxianghongfu.com，可正常获取 1.0 版本的应用内容
3.3 多域名路由扩展实验
- 复制原有实验资源，修改主机名为
www2.xinxianghongfu.com，应用版本修改为 2.0 - 配置本地 hosts 解析：将
www2.xinxianghongfu.com解析到同一 Master 节点 IP - 验证：浏览器访问
www2.xinxianghongfu.com可正常获取 2.0 版本内容，实现同一 IP 下不同域名路由到不同后端服务
四、实验2：Ingress 实现 HTTPS 卸载（SSL Termination）
4.1 前置准备
- 生成测试证书与私钥：使用 openssl 生成自签名测试证书（生产环境建议购买商用证书，如沃通，或使用 Let’s Encrypt 免费申请可信证书）
- 封装 Secret：将证书文件（
tls.crt）和私钥文件（tls.key）封装为 TLS 类型的 Secret，名称为ingress-nginx-tls
4.2 实验资源准备
- Deployment：使用指定镜像创建 HTTPS 应用 Pod，标签为
app=ssl，应用版本为 3.0 - Service：名称为
https-proxy-svc，类型为 ClusterIP，匹配上述 Deployment 的 Pod 标签，暴露 80 端口 - Ingress 资源对象配置：
- 类名为
nginx，指定 TLS 配置：主机名为ssl.xinxianghongfu.com的请求需要启用 HTTPS 加密访问，关联上述封装的 Secret - 规则配置：主机名为
ssl.xinxianghongfu.com，路径/匹配到后端 Service 的 80 端口 - 注解配置：添加
nginx.ingress.kubernetes.io/ssl-redirect: "true"，强制将 HTTP 请求重定向到 HTTPS
- 类名为
4.3 验证
- 配置本地 hosts 解析：将
ssl.xinxianghongfu.com解析到 Master 节点 IP - 浏览器访问
http://ssl.xinxianghongfu.com会自动重定向到 HTTPS 协议，访问https://ssl.xinxianghongfu.com可正常获取 3.0 版本的应用内容（自签名证书会提示风险，点击继续访问即可）
4.4 核心概念说明
HTTPS 卸载（SSL Termination）是指 Nginx Ingress 作为流量入口终止 HTTPS 加密请求，内部以 HTTP 明文协议转发到后端 Pod，由 Ingress 组件承担 SSL 加解密开销，后端服务无需处理 HTTPS 相关逻辑，降低后端服务的实现复杂度。
AI 总结
本节内容围绕 Kubernetes 集群中 Nginx Ingress 的部署与使用展开，首先说明了 Nginx Ingress 相比传统外部负载均衡的核心特性（自动热更新配置、减少重启开销），随后详细讲解了通过 Helm 部署 Nginx Ingress 的全流程，包括前置准备、镜像导入、values.yaml 核心配置项的修改逻辑（hostNetwork、dnsPolicy、DaemonSet 调度、镜像校验、默认类名），最后通过 HTTP 代理、HTTPS 卸载两个实战实验演示了 Ingress 的核心功能，同时给出了生产环境 Ingress 高可用的部署建议（前端挂载负载均衡对 Ingress 节点的 80/443 端口做负载，避免单节点故障导致服务不可用）。