Traefik中诡异的502和504问题

我们都知道在 Kubernetes 集群中通常会使用 Ingress 方案来统一代理集群内部的流量，而常用的 Ingress 方案为 traefik 和 nginx，和传统的 Nginx 作为企业内部的反向代理以及负载设备一样，在不同的场景下可能需要专有的配置才能满足需求，否则会出现奇奇怪怪的异常状态码。本篇文章一起来看下，我们在 traefik 中遇到的 500 和 502 异常。

一、前言

在开始之前，我们先来看几个在 Nginx 作为反向代理工具中经常遇到的几个异常状态码：

• 499: 客户端主动断开连接。通常为一次请求未在客户端指定时间内返回，客户端主动关闭连接，客户端无数据返回 (在 Nginx 中会记录 499)。一般是客户端超时
• 500: 服务器内部错误。服务器遇到未知错误导致无法完成请求处理，通常由于后端业务逻辑异常导致 (本身 Bug)
• 502: 网关错误。通常为网关未从上游服务中获取期望的响应 (上游未返回数据或未按照协议约定返回数据)，网关感觉自己没用了，返回了网关错误。一般是后端服务器宕机或业务逻辑超时
• 504: 网关超时。表示网关没有及时从上游获取响应数据。一般是 Nginx 网关作为客户端去向上游服务请求响应的过程中，Nginx 网关超时导致，但此时对于上游服务器来将，它会继续执行，直到结束。(Nginx网关作为客户端时的超时)

# 499 的实际情况就是，客户端指定超时时间为N秒，但是该请求在服务端实际需要执行M秒(M>N秒)，客户端等的不耐烦了就关闭了
# 对于499状态来讲，解决方式是优化后端代码逻辑或者修改nginx参数
$ cat nginx.conf
proxy_ignore_client_abort    on;
$ curl -i -m 3 http://127.0.0.1/hello.php


# 502的实际情况通常是Nginx网关后端的服务器直接宕机了(所以就拿不到上游的响应了)
# 当然也有可能是上游服务器真正的执行逻辑超过了上游服务器的超时时间限制(比如php-fpm.conf设置request_terminate_timeout5s，但是实际的业务逻辑需要7s才能完成)，此时上游服务器端出现`业务逻辑超时`，给Nginx网关返回了异常的数据造成的
# 502时后端的几种错误日志
 recv() failed (104: Connection reset by peer) while reading response header from upstream
 upstream prematurely closed connection while reading response header from upstream
 connect() failed (111: Connection refused) while connecting to upstream
# 整体来说502出现的问题通常是因为后端挂了，或者因为后端负载太高，暂时不可响应
# 可以在nginx侧增加proxy_read_timeout来暂时缓解
$ cat nginx.conf
proxy_read_timeout  20s;

# 504的实际情况就是客户端->Nginx->Backend，在过程中Nginx需要作为客户端访问Backend服务，但是在Backend还没用执行完成时，Nginx首先超过了自己的客户端超时时间，此时就会出现504的异常(但是对于客户端来说返回什么呢?)
# 对于504场景而言，通常的做法就是优化Backend的逻辑，适当减少执行时间；另外也可以适当的增加Nginx作为客户端时的超时时间
# 要知道，当Nginx作为客户端时，是以一个Proxy的角色存在的，配置如下参数即可
$ cat nginx.conf
uwsgi_connect_timeout 5;
uwsgi_send_timeout 5;
uwsgi_read_timeout 5;
fastcgi_read_timeout 5;
fastcgi_send_timeout 5;
proxy_connect_timeout      90;
proxy_send_timeout         90;
proxy_read_timeout         90;

二、traefik 中诡异的 500 和 502

traefik 在 Kubernetes 集群中的部署配置

我们当前集群的 traefik 的配置如下:

# traefik的configmap配置文件
$ cat traefik-config.yaml
apiVersion: v1
kind: ConfigMap
metadata:
  name: traefik-config
  namespace: kube-system
data:
  traefik.toml: |
    defaultEntryPoints = ["http","https"]
    debug = false
    logLevel = "INFO"

    InsecureSkipVerify = true
    [entryPoints]
      [entryPoints.http]
      address = ":80"
      compress = true
      [entryPoints.https]
      address = ":443"
        [entryPoints.https.tls]
    [web]
      address = ":8080"
    [kubernetes]
    [metrics]
      [metrics.prometheus]
      buckets=[0.1,0.3,1.2,5.0]
      entryPoint = "traefik"
    [ping]
    entryPoint = "http"

# traefik的DaemonSet配置
$ cat traefik-ds-v1.7.16.yaml
---
apiVersion: v1
kind: ServiceAccount
metadata:
  name: traefik-ingress-controller
  namespace: kube-system
---
kind: DaemonSet
apiVersion: extensions/v1beta1
metadata:
  name: traefik-ingress-controller
  namespace: kube-system
  labels:
    k8s-app: traefik-ingress-lb
spec:
  template:
    metadata:
      labels:
        k8s-app: traefik-ingress-lb
        name: traefik-ingress-lb
    spec:
      affinity:
        nodeAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
            nodeSelectorTerms:
            - matchExpressions:
              - key: node-role.kubernetes.io/master
                operator: DoesNotExist
      serviceAccountName: traefik-ingress-controller
      terminationGracePeriodSeconds: 30
      hostNetwork: true
      containers:
      - image: traefik:v1.7.16
        name: traefik-ingress-lb
        ports:
        - name: http
          containerPort: 80
          hostPort: 80
        - name: admin
          containerPort: 8080
        securityContext:
          capabilities:
            drop:
            - ALL
            add:
            - NET_BIND_SERVICE
        args:
        -