ingress-nginx部署模式：DaemonSet vs Deployment
项目地址: https://gitcode.com/GitHub_Trending/in/ingress-nginx 概述
在Kubernetes集群中部署ingress-nginx控制器时，您面临一个关键决策：选择DaemonSet还是Deployment作为控制器的工作负载类型。这个选择直接影响集群的网络拓扑、性能特征和运维复杂度。本文将深入分析两种部署模式的优缺点，并提供具体的使用场景建议。
部署模式对比
Deployment模式（默认）
Deployment是ingress-nginx的默认部署方式，通过Service暴露服务，支持灵活的副本管理和自动扩缩容。
controller:
kind: Deployment
replicaCount: 2
service:
type: LoadBalancer
架构特点：
- 通过Service（LoadBalancer/NodePort）暴露服务
- 支持水平扩缩容（HPA）
- 灵活的副本数量配置
- 标准的Kubernetes服务发现机制
DaemonSet模式
DaemonSet确保每个节点（或符合选择器的节点）上都运行一个ingress-nginx Pod实例。
controller:
kind: DaemonSet
hostNetwork: true
hostPort:
enabled: true
ports:
http: 80
https: 443
架构特点：
- 每个节点运行一个Pod实例
- 通常结合
hostNetwork: true使用 - 直接绑定节点网络端口（80/443）
- 无中间服务层
技术特性对比
下表详细比较了两种部署模式的关键特性：
| 特性维度 | Deployment模式 | DaemonSet模式 |
|---|---|---|
| 网络架构 | 通过Service抽象，支持多种类型 | 直接使用主机网络，无Service抽象 |
| 端口绑定 | 随机NodePort或负载均衡器IP | 直接绑定节点80/443端口 |
| IP保留 | 需要externalTrafficPolicy: Local | 原生保留客户端源IP |
| 扩展性 | 支持副本数动态调整 | 固定每个节点一个实例 |
| 资源利用 | 按需分配资源，可集中调度 | 每个节点均占用资源 |
| 服务发现 | 通过Kubernetes Service | 直接使用节点IP |
| 高可用 | 跨节点副本分布 | 天然的多节点部署 |
| 运维复杂度 | 中等，需要管理Service | 简单，直接访问节点 |
性能考量
网络性能
Deployment模式网络路径：
- 客户端 → 负载均衡器 → NodePort → kube-proxy → Ingress Pod → 后端服务
- 多了一层网络转发，可能增加延迟
DaemonSet模式网络路径：
- 客户端 → 节点IP:80/443 → Ingress Pod → 后端服务
- 路径更短，延迟更低
资源消耗对比
| 资源类型 | Deployment模式 | DaemonSet模式 |
|---|---|---|
| CPU使用 | 集中分配，可优化 | 每个节点固定占用 |
| 内存使用 | 按需分配，可共享 | 每个节点独立占用 |
| 网络开销 | 有Service转发开销 | 直接主机网络，无额外开销 |
适用场景分析
适合Deployment模式的场景
-
云环境部署
# 云环境典型配置 controller: kind: Deployment replicaCount: 3 service: type: LoadBalancer annotations: service.beta.kubernetes.io/aws-load-balancer-type: "nlb" -
需要自动扩缩容
autoscaling: enabled: true minReplicas: 2 maxReplicas: 10 targetCPUUtilizationPercentage: 80 -
多租户环境
- 通过IngressClass隔离不同业务线
- 灵活的副本调度策略
适合DaemonSet模式的场景
-
裸金属集群
controller: kind: DaemonSet hostNetwork: true hostPort: enabled: true ports: http: 80 https: 443 -
性能敏感应用
- 需要最低网络延迟
- 要求保留客户端真实IP
-
边缘计算场景
- 每个边缘节点都需要入口能力
- 网络环境受限，无法使用负载均衡器
配置示例
Deployment模式完整配置
controller:
kind: Deployment
replicaCount: 3
minAvailable: 2
updateStrategy:
type: RollingUpdate
rollingUpdate:
maxUnavailable: 1
service:
type: LoadBalancer
externalTrafficPolicy: Local
annotations:
service.beta.kubernetes.io/aws-load-balancer-type: "nlb"
resources:
requests:
cpu: 200m
memory: 200Mi
limits:
cpu: 1000m
memory: 512Mi
DaemonSet模式完整配置
controller:
kind: DaemonSet
hostNetwork: true
dnsPolicy: ClusterFirstWithHostNet
hostPort:
enabled: true
ports:
http: 80
https: 443
tolerations:
- effect: NoSchedule
operator: Exists
nodeSelector:
ingress-ready: "true"
resources:
requests:
cpu: 100m
memory: 128Mi
limits:
cpu: 500m
memory: 256Mi
运维考虑
监控和日志
两种模式通用的监控配置：
# Prometheus监控注解
podAnnotations:
prometheus.io/scrape: "true"
prometheus.io/port: "10254"
prometheus.io/path: "/metrics"
升级策略
| 升级方式 | Deployment模式 | DaemonSet模式 |
|---|---|---|
| 滚动更新 | 支持，可控制更新节奏 | 支持，但会短暂影响节点服务 |
| 蓝绿部署 | 容易实现 | 较难实现 |
| 金丝雀发布 | 天然支持 | 需要额外配置 |
故障恢复
Deployment模式恢复流程：
- 检测Pod故障
- 自动重启Pod
- Service自动更新端点
- 负载均衡器健康检查
DaemonSet模式恢复流程：
- 检测Pod故障
- 在相同节点重启Pod
- 客户端直接重试
最佳实践建议
选择决策树
混合部署策略
对于大型集群，可以考虑混合部署：
- 核心节点使用DaemonSet保证性能
- 边缘节点使用Deployment提高资源利用率
# 节点标签选择器示例
nodeSelector:
node-type: "ingress-node"
tolerations:
- key: "ingress"
operator: "Equal"
value: "enabled"
effect: "NoSchedule"
常见问题解决
Deployment模式问题
问题： 客户端IP丢失 解决方案：
service:
externalTrafficPolicy: Local
问题： 服务发现延迟 解决方案：
dnsPolicy: ClusterFirstWithHostNet
DaemonSet模式问题
问题： 端口冲突 解决方案：
# 检查节点端口使用
netstat -tlnp | grep ':80\|:443'
问题： DNS解析失败 解决方案：
dnsPolicy: ClusterFirstWithHostNet
总结
ingress-nginx的Deployment和DaemonSet部署模式各有优劣，选择取决于您的具体需求：
- Deployment模式适合大多数云环境，提供灵活的扩缩容和服务发现能力
- DaemonSet模式适合性能敏感的裸金属环境，提供最低的网络延迟和直接的端口访问
建议根据实际业务需求、基础设施环境和性能要求做出选择，并在生产环境部署前进行充分的测试验证。无论选择哪种模式，都要确保配置正确的监控、日志和故障恢复机制，以保证服务的稳定性和可靠性。
创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
