kubernetes中nginx-ingress高可用需实现控制平面与数据平面解耦冗余：多实例跨节点部署、前置lb健康探针设为/healthz、daemonset+hostnetwork可选；调优连接超时、http/2/tls1.3、限流；强化prometheus指标、结构化日志、主动健康检查；落实最小rbac、cert-manager动态证书、header/cookie灰度路由。
高可用部署的核心要点
在Kubernetes中实现Nginx-Ingress高可用，关键不是单个Ingress Controller副本的“多”，而是控制平面与数据平面的解耦和冗余。你需要确保：
-
多个Ingress Controller实例跨节点部署：通过
podAntiAffinity强制分散到不同Node，避免单点故障；同时设置replicas: 3+并配合资源限制（如requests/limits）防止调度失败 -
前置负载均衡器必须健康探针准确：云厂商SLB或物理LB需指向Ingress Controller的
NodePort或LoadBalancerService，且健康检查路径设为/healthz（默认端口10254），超时与间隔建议设为timeout=3s, interval=5s -
使用DaemonSet + hostNetwork（可选但推荐）：绕过Service转发，降低延迟和连接抖动；需关闭
dnsPolicy: ClusterFirstWithHostNet并显式配置hostNetwork: true，同时绑定宿主机80/443端口
关键调优参数与配置实践
默认Nginx-Ingress配置偏保守，生产环境需针对性调整。重点修改ConfigMap和启动参数：
-
连接与超时优化：在
nginx-configurationConfigMap中添加：
proxy-connect-timeout: "60"
proxy-send-timeout: "600"
proxy-read-timeout: "600"
keep-alive: "300"
keep-alive-requests: "10000" -
启用HTTP/2与TLS 1.3：确保Ingress资源中指定
ssl-protocols: TLSv1.2 TLSv1.3，并在ConfigMap开启http2-max-field-size和http2-max-header-size（如各设为64k） -
限制并发与排队：通过
--max-worker-connections=8192（启动参数）提升吞吐；用limit-req注解实现每IP限流，例如：
nginx.ingress.kubernetes.io/limit-rps: "10"
nginx.ingress.kubernetes.io/limit-rps-burst: "20"
可观测性与故障快速定位
高可用不等于无故障，而在于故障可感知、可回溯、可自愈：
-
暴露Prometheus指标：确认Deployment中已启用
--enable-metrics=true（默认开启），ServiceMonitor或PodMonitor需抓取10254/metrics端点；重点关注nginx_ingress_controller_requests_total、nginx_ingress_controller_response_size_sum、nginx_ingress_controller_ssl_expire_time_seconds -
结构化日志输出：添加启动参数
--log-format-upstream='{"time":"$time_iso8601","remote_addr":"$remote_addr",...}'，配合Filebeat或Fluentd采集到ES/Loki，便于按域名、状态码、延迟聚合分析 -
主动健康检查集成：为后端Service配置
readinessProbe（如GET /readyz），并启用Ingress Controller的sync-period（默认1m）缩短配置收敛时间；对关键路由可加nginx.ingress.kubernetes.io/upstream-hash-by: "$request_uri"保连接粘性
安全加固与灰度发布支持
高可用架构若缺乏安全边界和渐进发布能力，反而会放大风险：
-
最小权限RBAC与网络策略：Ingress Controller ServiceAccount仅需
get/watch/listIngress、Service、Endpoint等必要资源；配合NetworkPolicy限制其只允许访问集群内Service CIDR和DNS端口 -
动态证书管理：集成cert-manager时，使用
ClusterIssuer而非Issuer，确保证书签发不受命名空间限制；Ingress中通过tls.secretName引用，并开启ssl-redirect: "true"自动跳转HTTPS -
基于Header或Cookie的灰度路由：利用
nginx.ingress.kubernetes.io/canary: "true"及配套注解（如canary-by-header、canary-weight），将部分流量导向新版本Service，无需改应用代码
