使用NEG时，Pod删除会导致错误

Question

在本例中，我在一个包含2个副本的部署中运行“echoheaders”Nginx。当我删除一个pod时，我有时会收到约40秒的缓慢响应和错误。

我们正在库伯内特斯运行我们的API网关，并且需要能够允许库伯内特斯调度程序在它认为合适的时候处理pod。

我们最近想引入会话相关性，为此，我们想迁移到新的闪亮的NEG：网络endpoint组：https://cloud.google.com/load-balancing/docs/negs/

使用NEG时，我们会在故障转移期间遇到问题。没有NEG，我们很好。

部署。亚马尔

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: echoheaders
  labels:
    app: echoheaders
spec:
  replicas: 2
  selector:
    matchLabels:
      app: echoheaders
  template:
    metadata:
      labels:
        app: echoheaders
    spec:
      containers:
      - image: brndnmtthws/nginx-echo-headers
        imagePullPolicy: Always
        name: echoheaders
        readinessProbe:
          httpGet:
            path: /
            port: 8080
        lifecycle:
          preStop:
            exec:
              # Hack: wait for kube-proxy to remove endpoint before exiting, and
              # gracefully shut down 
              command: ["bash", "-c", "sleep 10; nginx -s quit; sleep 40"]
      restartPolicy: Always
      terminationGracePeriodSeconds: 60

service.yaml

apiVersion: v1
kind: Service
metadata:
  name: echoheaders
  labels:
    app: echoheaders
  annotations:
    cloud.google.com/neg: '{"ingress": true}'
spec:
  ports:
  - port: 80
    protocol: TCP
    targetPort: 8080
  selector:
    app: echoheaders

进入。亚马尔

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  annotations:
    kubernetes.io/ingress.global-static-ip-name: echoheaders-staging
  name: echoheaders-staging
spec:
  backend:
    serviceName: echoheaders
    servicePort: 80

删除pod时，我会收到错误，如下图所示

<代码>$httping-G-K 35.190.69.21

（https://i.imgur.com/u14MvHN.png）

这是使用NEG时的新行为。禁用NEG会提供工作故障转移的旧行为。

有没有办法使用谷歌LB，入口，NEG和库伯内特斯在pod删除期间没有错误？

Answer 1

在GCP负载平衡器中，只有在两个后续后端无法满足响应超时或出现更合理的影响性错误后，GET请求才会被服务于502。

可能发生的情况可能是一个过渡期，在此期间，Pod将被终止并已收到其SIGTERM，但负载平衡器仍认为其正常，并发送了一个请求。由于这段时间很短，它无法完成请求并关闭了连接。

在机器中进行一次优雅的服务停止[1]将使您的服务在收到SIGTERM后继续服务于飞行中的请求，但拒绝新的连接。这可能会解决您的问题，但请记住，不能保证零停机时间。

[1] https://landing.google.com/sre/sre-book/chapters/load-balancing-datacenter/#robust_approach_lame_duck