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

时间:2019-04-10 11:43:36

标签: kubernetes google-kubernetes-engine google-cloud-networking

在此示例中,我在具有2个副本的部署中运行“ echoheaders” Nginx。当我删除1个窗格时,有时会出现缓慢的响应和错误,持续约40秒。

我们正在Kubernetes中运行我们的API网关,并且需要能够允许Kubernetes调度程序处理合适的Pod。

我们最近想引入会话亲和力,为此,我们想迁移到新的闪亮NEG:网络端点组: https://cloud.google.com/load-balancing/docs/negs/

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

deployment.yaml


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

ingress.yaml

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

删除吊舱时,出现错误,如

的此图像所示

$ httping -G -K 35.190.69.21

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

这是使用NEG时的新行为。禁用NEG会产生旧的故障切换行为。

在pod删除过程中,使用Google LB,Ingress,NEG和Kubernetes的任何方式都不会出错吗?

1 个答案:

答案 0 :(得分:0)

在GCP负载平衡器中,只有在随后的两个后端均无法满足响应超时或发生影响性错误(似乎更合理)之后,才会为502请求GET请求。

可能发生的情况可能是一个过渡期,在此过渡期中Pod即将终止并已收到其SIGTERM,但负载均衡器仍认为Pod运行正常,并已发送请求。由于这段时间太短,因此无法完成请求并关闭连接。

计算机中正常的服务停止[1]将使您的服务在收到SIGTERM后将继续满足飞行中的请求,但拒绝新的连接。这可能会解决您的问题,但请记住,不能保证零停机时间。


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