来源链接：https://www.bilibili.com/video/BV1PbeueyE8V?spm_id_from=333.788.videopod.episodes&vd_source=d8c71ff24a3359a807967fc4b5daa0e4&p=78

第十章 k8s HELM-Ingress-nginx 进阶实验笔记

1. Ingress-nginx 后端代理HTTPS协议实验

1.1 实验原理

• 场景说明：Ingress-nginx 代理后端服务时，后端服务本身对外提供HTTPS协议，相当于完成后端HTTPS卸载，对外可提供HTTP/HTTPS两种访问方式
• 架构流程：Client 访问 Ingress-nginx，可选择HTTP/HTTPS协议接入 → Ingress-nginx 代理后端Backend → Backend 对外仅提供HTTPS协议服务
• 典型场景：如Kubernetes官方Dashboard默认以HTTPS协议提供服务，若需通过Ingress接入需采用该配置方案

1.2 资源配置说明

本次实验涉及3类核心资源：

1. Deployment：运行自定义HTTPS测试应用，镜像为自编写的 tuss:https-v1，仅响应HTTPS协议请求
2. Service：ClusterIP类型，端口映射为443:443（TCP协议），标签匹配后端Pod标签，为Ingress提供后端服务发现能力
3. Ingress：核心配置要点：
   • Ingress 的 spec.rules.http.paths.backend.service.name 指向上述Service
   • 由于Ingress默认无HTTPS协议选项，spec.rules.http.paths.backend.protocol 字段仍需填写HTTPS，同时通过Annotation nginx.ingress.kubernetes.io/backend-protocol: "HTTPS" 明确指定后端协议为HTTPS

1.3 实验操作与验证

1. 清理历史残留资源，避免配置冲突
2. 应用资源配置文件，等待Pod拉取镜像完成启动
3. 获取Ingress生成的域名，在本地hosts文件中添加解析：192.168.66.12 prosync-https.new-ingress-test.com
4. 浏览器访问域名：
   • 走HTTP协议可正常返回Hello HTTPS，走HTTPS协议因使用自签证书提示不安全但仍可正常访问，证明Ingress对外支持两种协议接入
5. 后端协议验证：将Service修改为NodePort类型，暴露端口31163，直接访问https://192.168.66.12:31163可正常返回Hello HTTPS，证明后端服务确实为HTTPS协议

2. Ingress-nginx 四层负载（TCP/UDP）实验

2.1 原理说明

• Ingress 最初设计目标是补充七层代理能力，但若其控制器支持四层代理，也可通过Ingress接口实现四层负载
• Ingress-nginx 在1.9.0版本后，开源社区版已支持四层负载能力（该能力最初为付费企业版Ingress Plugins的功能）
• 生产环境建议：若需四层负载优先使用Service实现，底层IPVS的稳定性和性能更优，Ingress四层负载仅作为实验场景补充

2.2 TCP四层负载配置步骤

1. 修改Ingress-nginx的DaemonSet控制器：
   • 找到启动参数args，新增参数 --tcp-services-configmap=ingress-nginx/tcp-services，指定读取ingress-nginx命名空间下的指定ConfigMap生成四层负载配置
2. 创建对应ConfigMap：
   • 命名为ingress-nginx-tcp-services，命名空间与Ingress-nginx一致（实验中为ingress命名空间）
   • 配置格式为：<后端服务命名空间>/<后端服务名>:<后端服务端口> <Ingress节点暴露端口>，示例配置为default/proc-https:443 9000，表示将default命名空间下proc-https服务的443端口，代理到Ingress所在节点的9000端口
3. 验证：访问https://192.168.66.12:9000可正常返回后端内容，证明TCP四层代理生效

2.3 UDP四层负载配置说明

• 配置逻辑与TCP一致，仅需修改DaemonSet启动参数为--udp-services-configmap=ingress-nginx/udp-services，对应ConfigMap格式与TCP配置相同
• 示例配置：default/coredns:53 53，将default命名空间下coredns服务的53端口代理到节点的53端口
• 实际场景中UDP四层负载使用频率较低，本次实验仅给出配置方案不展开演示

3. Ingress-nginx 链路追踪实验

3.1 功能说明

链路追踪可记录每个Ingress代理请求的全链路信息，包括请求时间、代理节点、各阶段耗时、后端服务响应等，方便排查访问慢、请求失败等异常问题。
官方推荐的两款链路追踪工具为Jaeger和Dragon，本次实验选用Dragon实现。

3.2 配置步骤

1. 下载官方部署文件：通过wget下载Dragon官方部署YAML，若无法下载可直接通过浏览器下载后上传到服务器
2. 修改部署文件适配集群版本：
   • 官方默认文件使用已废弃的apps/v1beta1 API版本，需修改为apps/v1
   • apps/v1要求Deployment必须显式声明selector.matchLabels，需补充标签匹配配置
3. 部署到指定命名空间：将所有资源的namespace修改为ingress，避免与默认命名空间资源冲突
4. 开启Ingress-nginx链路追踪能力：
   • 修改Ingress-nginx的ConfigMap，新增配置开启链路追踪，指定trace collector地址为dragon-collector.ingress.svc.cluster.local:14250
5. 重启Ingress-nginx Pod：删除原有Pod，DaemonSet会自动重建新Pod加载新配置
6. 验证链路追踪：
   • Ingress-nginx的Service已修改为NodePort类型，暴露端口31919，访问该端口进入Dragon查询界面
   • 多次访问后端服务生成请求日志，即可在Dragon界面查看单条请求的全链路耗时、代理节点等信息，支持按耗时排序排查慢请求问题

4. 本章节内容总结

本节实验共覆盖Ingress-nginx的13个核心实验场景，重点掌握3类高阶能力：

1. 后端HTTPS协议代理的配置逻辑与验证方法
2. 四层TCP/UDP负载的配置原理与适用场景
3. 链路追踪的集成方法与日志查询方式
   建议结合实际需求动手完成所有实验，深入理解Ingress-nginx的各类特性。

AI 总结

本节视频围绕Ingress-nginx的高阶使用场景展开，通过实操演示了3类核心功能的配置与验证方法：第一类是后端HTTPS协议代理，解决了官方Dashboard等默认HTTPS服务的Ingress接入问题，核心是通过Annotation明确指定后端协议为HTTPS；第二类是四层负载配置，通过修改DaemonSet启动参数和ConfigMap即可实现TCP/UDP的四层代理，但生产环境仍优先推荐使用Service实现四层负载以保证稳定性；第三类是链路追踪集成，通过对接Dragon可实现请求全链路可视化，大幅降低访问异常问题的排查成本。所有实验均提供可直接落地的配置模板和验证步骤，适合需要掌握Ingress-nginx进阶用法的云原生开发者学习。