三亩地 三亩地SAN MU DI · CODE DIARY
ARTICLE DETAIL

日记详情

真实记录编程学习的某一天,欢迎挑你感兴趣的翻一翻。

Kubernetes Ingress-Nginx部署与调优实战指南

Kubernetes Ingress-Nginx部署与调优实战指南

1. 为什么需要Ingress-Nginx?

在Kubernetes集群中管理外部访问一直是个值得深入探讨的话题。作为从业多年的基础设施工程师,我见证过太多团队在服务暴露方案上的反复折腾。从早期的NodePort直接暴露,到后来为每个服务单独配置LoadBalancer,再到如今广泛采用的Ingress方案,这条演进路径背后反映的是对生产级流量管理的持续追求。

1.1 传统服务暴露方式的痛点

NodePort虽然简单直接,但存在明显的端口管理问题。当集群内服务数量超过几十个时,端口冲突和防火墙规则管理就会变成运维噩梦。我曾参与过某电商平台的迁移项目,他们的测试环境就因NodePort端口耗尽导致新服务无法部署。

LoadBalancer方案看似优雅,但成本问题突出。云厂商的LB实例按小时计费,当微服务数量达到百级规模时,每月仅LB费用就可能高达数万美元。更不用说自建LB方案的技术复杂度,需要专业团队维护Keepalived+HAProxy等组件。

1.2 Ingress控制器的核心价值

Ingress-nginx作为Kubernetes官方维护的Ingress控制器,完美解决了上述痛点。它通过:

  • 单一入口点统一管理所有HTTP/HTTPS流量
  • 基于Host和Path的路由规则
  • 集中式的TLS终止
  • 细粒度的流量控制策略

在实际生产环境中,我们使用DaemonSet方式部署的Ingress-nginx可以轻松处理每秒数万级别的请求量。某金融客户的生产集群中,单个Ingress-nginx实例稳定支撑了日均1.2亿次API调用。

2. 环境准备与前置检查

2.1 集群版本适配性验证

Kubernetes 1.28+版本对Ingress-nginx的支持度最佳。执行以下命令验证集群版本:

kubectl version --short | grep Server

重要提示:如果集群版本低于1.25,建议先升级控制平面。我们曾遇到1.23版本与最新Ingress-nginx的API兼容性问题,导致Admission Webhooks失效。

2.2 网络插件兼容性测试

不同CNI插件可能影响Ingress-nginx的部署模式。对于Calico网络插件,需要特别注意:

kubectl get pods -n kube-system -l k8s-app=calico-node

如果使用HostNetwork模式,需确保节点80/443端口未被占用。快速检查命令:

ss -tulnp | grep -E ':80|:443'

2.3 资源配额规划

生产环境建议为Ingress-nginx预留以下资源:

  • 每个Pod至少1核CPU和1GB内存
  • 设置合理的HPA自动扩缩容策略

示例资源配置文件片段:

resources: requests: cpu: "1" memory: "1Gi" limits: cpu: "2" memory: "2Gi"

3. Helm部署最佳实践

3.1 Helm仓库配置优化

官方推荐使用Helm 3.8+版本。添加仓库时建议指定稳定版本:

helm repo add ingress-nginx https://kubernetes.github.io/ingress-nginx helm repo update

国内用户可能会遇到镜像拉取问题,可以配置阿里云镜像加速:

helm install ingress-nginx ingress-nginx/ingress-nginx \ --set controller.image.repository=registry.cn-hangzhou.aliyuncs.com/google_containers/nginx-ingress-controller

3.2 DaemonSet模式深度解析

对于需要极致性能的场景,DaemonSet是首选部署方式。核心优势包括:

  • 每个节点独立处理流量,避免跨节点跳转
  • 直接使用主机网络栈,减少NAT开销
  • 更好的源IP保持能力

典型配置示例:

controller: kind: DaemonSet hostNetwork: true dnsPolicy: ClusterFirstWithHostNet tolerations: - key: "node-role.kubernetes.io/master" operator: "Exists" effect: "NoSchedule"

3.3 关键参数调优指南

以下参数对性能影响显著,需要根据实际负载调整:

参数默认值生产建议值说明
worker-processes4auto建议设为auto自动匹配CPU核心数
keepalive-requests10010000长连接复用请求数
upstream-keepalive-connections32200到后端服务的保持连接数
max-worker-connections1638465536单个worker最大连接数

配置示例:

controller: config: worker-processes: "auto" keepalive-requests: "10000" upstream-keepalive-connections: "200"

4. 生产级安全加固

4.1 TLS安全策略配置

现代安全标准要求至少使用TLS 1.2协议并禁用弱加密套件。推荐配置:

controller: config: ssl-protocols: "TLSv1.2 TLSv1.3" ssl-ciphers: "ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256" use-forwarded-headers: "true"

4.2 网络策略隔离

使用NetworkPolicy限制Ingress控制器的网络访问:

apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: ingress-nginx-isolation spec: podSelector: matchLabels: app.kubernetes.io/name: ingress-nginx policyTypes: - Ingress - Egress ingress: - ports: - protocol: TCP port: 80 - protocol: TCP port: 443 egress: - to: - namespaceSelector: {} ports: - protocol: TCP port: 80 - protocol: TCP port: 443

4.3 审计日志配置

启用详细访问日志用于安全审计:

controller: config: log-format-upstream: '$remote_addr - $remote_user [$time_local] "$request" $status $body_bytes_sent "$http_referer" "$http_user_agent" $request_length $request_time [$proxy_upstream_name] [$proxy_alternative_upstream_name] $upstream_addr $upstream_response_length $upstream_response_time $upstream_status'

5. 常见故障排查手册

5.1 502 Bad Gateway问题

这是最常见的Ingress问题,通常由以下原因导致:

  1. 后端服务未就绪:
kubectl get endpoints -n <namespace>
  1. 服务端口名称不匹配:
# 错误配置示例 ports: - port: 8080 targetPort: 8080 # 正确配置应包含名称 ports: - name: http port: 8080 targetPort: 8080

5.2 证书管理问题

当遇到TLS握手失败时,按以下步骤排查:

  1. 检查Secret是否存在:
kubectl get secret -n <namespace>
  1. 验证证书有效期:
kubectl get secret <cert-secret> -o jsonpath='{.data.tls\.crt}' | base64 -d | openssl x509 -noout -dates

5.3 性能瓶颈分析

当出现高延迟时,使用以下命令诊断:

  1. 查看Nginx worker状态:
kubectl exec -it <ingress-pod> -- nginx -T | grep worker
  1. 监控连接队列:
kubectl exec -it <ingress-pod> -- netstat -ant | grep -E '80|443'

6. 高级调优技巧

6.1 动态配置热更新

避免频繁重启Ingress控制器:

controller: extraArgs: enable-dynamic-configuration: "true" enable-ssl-chain-completion: "false"

6.2 自定义模板开发

覆盖默认Nginx模板应对特殊场景:

kubectl create configmap ingress-nginx-template --from-file=custom.tmpl=/path/to/template

然后在Helm values中引用:

controller: customTemplate: configMapKey: "custom.tmpl" configMapName: "ingress-nginx-template"

6.3 金丝雀发布支持

通过注解实现流量切分:

metadata: annotations: nginx.ingress.kubernetes.io/canary: "true" nginx.ingress.kubernetes.io/canary-weight: "20"

在金融行业项目中,这种方案帮助我们实现了零宕期的支付系统升级。

← 返回列表