Nginx Load Balancer Config

本文介绍了如何使用Nginx实现HTTP负载均衡,包括轮询、最少连接数及IP哈希三种分配策略,并讨论了Session管理和错误检测配置。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

用Nginx实现负载均衡

由于Nginx的简单轻巧,如今越来越多的人采用Nginx当作Web服务器,Nginx除了可以当作web server之外,还可以利用Nginx来实现负载均衡,用Nginx来配置http(或https)的负载均衡也非常简单。

Nginx的负载均衡支持以下几种方式:
round-robin — 简单轮询(默认方式)
least-connected — 最少活跃链接数(基本就是相对来说谁最闲就分配给谁)
ip-hash — 根据IP进行哈希(请求来源的IP)

举例说明,假设后台有3台服务器用户处理用户的请求,用Nginx来实现负载均衡:

基本配置
1.round-robin方式:

http {
    upstream myapp1 {
        server srv1.example.com;
        server srv2.example.com;
        server srv3.example.com;
    }

    server {
        listen 80;

        location / {
            proxy_pass http://myapp1;
        }
    }
}

当有用户请求时,Nginx会采用round-robin方式来分配各个请求到3台服务器上。

2. least-connected方式:

http {
    upstream myapp1 {
        least_conn; #注意是least_conn不是least_connected
        server srv1.example.com;
        server srv2.example.com;
        server srv3.example.com;
    }

    server {
        listen 80;

        location / {
            proxy_pass http://myapp1;
        }
    }
}

3. ip-hash

http {
    upstream myapp1 {
        ip_hash;
        server srv1.example.com;
        server srv2.example.com;
        server srv3.example.com;
    }

    server {
        listen 80;

        location / {
            proxy_pass http://myapp1;
        }
    }
}

以上三种实现方式中,round_robin和least_conn不能保证同一用户的请求会发送到同一服务器上,如果你的服务中用到了Session的话,就需要考虑Session分布的问题。通常的解决办法是将Session统一存储,比如用Memcache或数据库存储。
如果采用ip_hash可以将同一用户的请求发到同一台机器上。

除了上面的配置以外,Nginx还支持给每台服务器设置权重:
比如:

http {
    upstream myapp1 {
        ip_hash;
        server srv1.example.com weight=3;
        server srv2.example.com;
        server srv3.example.com;
    }

    server {
        listen 80;

        location / {
            proxy_pass http://myapp1;
        }
    }
}

在srv1中加了一个权值3,这样分配给srv1的请求数将是其它机器的3倍,比如有5个请求,会分给srv13个,srv2和srv3各一个。

least_conn和ip_hash也同样支持权重分配,配置方法和上面一样。

错误检测

Nginx在分配任务时会查看(被动)各台服务器的运行状态,如果分配给某台服务器的请求没有正确响应那么,Nginx会将该机器暂时标为不可用(请求仍会分配给其它服务器),可以通过max_fails参数(默认为1)来设置最大重试次数,用fail_timeout(默认为10s)来设置超时时间。

如:

http {
    upstream myapp1 {
        ip_hash;
        server srv1.example.com max_fails=2 fail_timeout=30s;
        server srv2.example.com;
        server srv3.example.com;
    }

    server {
        listen 80;

        location / {
            proxy_pass http://myapp1;
        }
    }
}

max_fails=2 fail_timeout=30s意思是在30秒内,连接该服务器连续2次失败,刚在接下来的30秒内,不再分配新的请求给这台机器(30秒之后新请求会重新尝试分配给该服务器)。

如果设置max_fails=0,那么Nginx不检测这台机器的状况。

如果想让某台机器下线,可以设置成down,如下:

http {
    upstream myapp1 {
        ip_hash;
        server srv1.example.com max_fails=2 fail_timeout=30s;
        server srv2.example.com down;
        server srv3.example.com;
    }

    server {
        listen 80;

        location / {
            proxy_pass http://myapp1;
        }
    }
}

以上是使用Nginx做负载均衡的基本配置,其它详细的用法请参考Nginx手册。

<think>嗯,用户想了解如何使用Deployment和Service(NodePort/LoadBalancer)部署Ingress控制器。这个问题需要分步骤解释,因为Ingress本身不是服务类型,而是通过Ingress控制器实现的。 用户提供的引用材料很有帮助:引用[1]详细说明了Deployment的功能,包括管理Pod副本和滚动更新;引用[2][3]解释了NodePort类型Service的工作原理;引用[4]提到了一些K8s基础组件。这些正好是部署Ingress控制器所需的核心知识。 需要重点说明的是:Ingress控制器本质上就是个特殊Pod,所以可以用Deployment部署。而为了让外部访问,需要给它创建Service,这里NodePort和LoadBalancer都是可选方案。NodePort适合测试环境,LoadBalancer更适合生产环境。 准备分四部分回答:先解释Ingress控制器的部署逻辑,然后分别说明Deployment配置、Service配置,最后补充实际使用步骤。每个配置部分都会给出yaml示例,特别要标注出NodePort和LoadBalancer的关键区别。 用户可能是K8s中级学习者,ta能准确说出"NodePort/LoadBalancer"这些术语,说明对Service类型有基础认知。但可能混淆了Ingress和Ingress控制器的概念,这点需要在回答开头就澄清。 最后考虑生成三个延伸问题:第一个关于Ingress控制器的高可用部署,这是生产环境常见需求;第二个关于HTTPS配置,涉及实际应用安全;第三个比较不同Ingress方案,帮助用户拓宽视野。这些问题都围绕用户当前知识深度合理延伸。</think>以下是使用 Deployment 和 Service (NodePort/LoadBalancer) 部署 Ingress 控制器的详细步骤: ### 核心概念 1. **Ingress 控制器**:是一个特殊的 Pod(如 Nginx Ingress Controller、Traefik),负责解析 Ingress 规则并配置负载均衡器。 2. **Deployment**:用于部署和管理 Ingress 控制器的 Pod 副本[^1]。 3. **Service**:暴露 Ingress 控制器供外部访问。通常使用: * `NodePort`:通过集群节点的 IP 和端口访问(适合测试/简单环境)[^2][^3]。 * `LoadBalancer`:由云平台自动创建外部负载均衡器(推荐生产环境)[^3]。 ### 部署步骤 #### 1. 部署 Ingress 控制器 (Deployment) 创建 YAML 文件(如 `ingress-controller-deployment.yaml`): ```yaml apiVersion: apps/v1 kind: Deployment metadata: name: nginx-ingress-controller namespace: ingress-nginx # 建议使用独立命名空间 spec: replicas: 2 # 副本数 selector: matchLabels: app: nginx-ingress template: metadata: labels: app: nginx-ingress spec: containers: - name: nginx-ingress-controller image: registry.k8s.io/ingress-nginx/controller:v1.10.0 # 使用官方镜像 args: - /nginx-ingress-controller - --publish-service=$(POD_NAMESPACE)/nginx-ingress-service # 关联Service - --election-id=ingress-controller-leader - --ingress-class=nginx - --configmap=$(POD_NAMESPACE)/nginx-configuration env: - name: POD_NAME valueFrom: fieldRef: fieldPath: metadata.name - name: POD_NAMESPACE valueFrom: fieldRef: fieldPath: metadata.namespace ports: - name: http containerPort: 80 - name: https containerPort: 443 livenessProbe: httpGet: path: /healthz port: 10254 scheme: HTTP readinessProbe: httpGet: path: /healthz port: 10254 scheme: HTTP ``` 应用配置: ```bash kubectl apply -f ingress-controller-deployment.yaml ``` #### 2. 暴露 Ingress 控制器 (Service) * **方式一:NodePort Service** (适合测试/无云平台环境) ```yaml apiVersion: v1 kind: Service metadata: name: nginx-ingress-service namespace: ingress-nginx spec: type: NodePort selector: app: nginx-ingress # 匹配Deployment的Pod标签 ports: - name: http port: 80 # Service端口(集群内访问) targetPort: 80 # Pod端口 nodePort: 30080 # 集群节点端口(外部访问端口,范围30000-32767)[^2][^3] - name: https port: 443 targetPort: 443 nodePort: 30443 ``` **访问方式**:`http://<任意NodeIP>:30080` * **方式二:LoadBalancer Service** (推荐生产环境/云平台) ```yaml apiVersion: v1 kind: Service metadata: name: nginx-ingress-service namespace: ingress-nginx spec: type: LoadBalancer selector: app: nginx-ingress ports: - name: http port: 80 targetPort: 80 - name: https port: 443 targetPort: 443 # 云平台特定注解(示例) # annotations: # service.beta.kubernetes.io/aws-load-balancer-type: nlb # cloud.google.com/load-balancer-type: "Internal" # GCP内网LB ``` **访问方式**:云平台分配的负载均衡器外部 IP(如 `http://<LB-IP>`) 应用 Service 配置: ```bash kubectl apply -f ingress-controller-service.yaml ``` #### 3. 部署应用并创建 Ingress 规则 * **部署示例应用 (Deployment & Service)**: ```yaml apiVersion: apps/v1 kind: Deployment metadata: name: my-app spec: replicas: 3 selector: matchLabels: app: my-app template: metadata: labels: app: my-app spec: containers: - name: my-app image: my-app-image:latest ports: - containerPort: 8080 --- apiVersion: v1 kind: Service metadata: name: my-app-service spec: selector: app: my-app ports: - protocol: TCP port: 80 # Service端口 targetPort: 8080 # Pod端口 ``` * **创建 Ingress 规则**: ```yaml apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: my-app-ingress spec: ingressClassName: nginx # 指定使用的Ingress控制器类 rules: - host: myapp.example.com # 域名 http: paths: - path: / pathType: Prefix backend: service: name: my-app-service # 指向后端Service port: number: 80 # Service端口 ``` #### 4. 验证 1. 检查 Ingress 控制器 Pod 状态:`kubectl get pods -n ingress-nginx` 2. 检查 Service 外部 IP/NodePort:`kubectl get svc -n ingress-nginx` 3. 检查 Ingress 规则:`kubectl get ingress` 4. 使用 `curl` 或浏览器访问配置的域名或 Service 的外部端点。 ### 关键点总结 1. **Deployment 管理控制器 Pod**:确保 Ingress 控制器高可用[^1]。 2. **Service 暴露控制器**: * `NodePort`:通过节点 IP+端口访问,需手动管理流量/防火墙[^2][^3]。 * `LoadBalancer`:由云平台提供外部 IP 和负载均衡,是生产环境首选[^3]。 3. **Ingress 定义路由规则**:将外部 HTTP(S) 流量路由到集群内部 Service。 4. **控制器处理规则**:Ingress 控制器 Pod 持续监控 Ingress 资源变化并实时更新代理配置。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值