【问题标题】:Unhealthy backends using GCP network endpoint groups for container-native Load Balancing使用 GCP 网络端点组进行容器原生负载平衡的不健康后端
【发布时间】:2019-04-27 00:39:56
【问题描述】:

我们正在测试 google 的新 container-native load balancingfeature。我们成功地关注了这个tutorial,我们正在尝试将它推广到我们在 GKE 上的三个服务中。

据我所知,NEG 功能和旧版 GCLB 入口对象之间的唯一区别是每个服务中的注释,因此 URL 映射应该工作相同。

我们已更新所有服务以使用此注释,但三分之二是 Unhealthy,而一个被认为是健康的。服务 yaml 的唯一区别是名称和选择器。

所有部署都有健康检查,当我们手动检查时都是健康的,但 LB 说后端不健康。

我们缺少什么?

Ingress.yaml

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: fanout-ingress
  annotations:
    kubernetes.io/ingress.global-static-ip-name: "neg-ip"
spec:
  backend:
    serviceName: frontend-svc
    servicePort: 8080
  rules:
  - host: testneg.test.com
    http:
      paths:
      - path: /*
        backend:
          serviceName: frontend-svc # Healthy service
          servicePort: 8080
      - path: /backend/*
        backend:
          serviceName: backend-svc # Unhealthy service
          servicePort: 8080
      - path: /notifications/*
        backend:
          serviceName: notifications-svc # Unhealthy service
          servicePort: 8080

--

frontend-svc.yaml - 除了名称和选择器之外,后端/通知是相同的

apiVersion: v1
kind: Service
metadata:
  name: frontend-svc
  annotations:
    cloud.google.com/neg: '{"ingress": true}' # Creates an NEG after an Ingress is created
spec:
  selector:
    app: frontend
  ports:
  - port: 8080
    protocol: TCP
    targetPort: 8080

--

backend-deployment.yaml

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: backend
spec:
  replicas: 1
  minReadySeconds: 60
  strategy:
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 1
    type: RollingUpdate
  template:
    spec:
      containers:
        image: us.gcr.io/<OUR_DJANGO_IMAGE>
        imagePullPolicy: Always
        name: backend
        ports:
        - containerPort: 8080
          protocol: TCP
        terminationMessagePath: /dev/termination-log
        terminationMessagePolicy: File
        readinessProbe:
          tcpSocket:
            port: 8080
          initialDelaySeconds: 60
          periodSeconds: 30
          timeoutSeconds: 3
        livenessProbe:
          tcpSocket:
            port: 8080
          initialDelaySeconds: 60
          periodSeconds: 30
          timeoutSeconds: 3   
      terminationGracePeriodSeconds: 60

【问题讨论】:

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


    【解决方案1】:

    您的入口 yaml 文件显示不同的服务

    - path: /*
            backend:
              serviceName: frontend-svc # Healthy service
              servicePort: 8080
          - path: /backend/*
            backend:
              serviceName: backend-svc # Unhealthy service
              servicePort: 8080
          - path: /notifications/*
            backend:
              serviceName: notifications-svc # Unhealthy service
              servicePort: 8080
    

    您的 frontend-svc.yaml 有一个不同的服务名称“li-frontend-svc”,它不在您的入口中。

    Ingress 中的 Spec.Backend.serviceName 应与您的服务名称匹配,预计后端服务不健康。

    上次编辑:

    在您的入口中,您指定两次服务前端-svc,您应该使用入口规范,如下规范:

    spec:
      rules:
      - http:
          paths:
          - backend:
              serviceName: first-service # Name of the Service targeted by the Ingress
              servicePort: 8080 # Should match the port used by the Service
            path: <first-service-path>/*
          - backend:
              serviceName: second-service # Name of the Service targeted by the Ingress
              servicePort: 8080 # Should match the port used by the Service
            path: <second-service-path>/*
          - backend:
              serviceName: third-service # Name of the Service targeted by the Ingress
              servicePort: 8080 # Should match the port used by the Service
            path: <third-service-path>/*
    

    这是我的复制品:

    apiVersion: apps/v1
    kind: Deployment
    metadata:
      labels:
        run: neg-hello-1 # Label for the Deployment
      name: neg-hello-1 # Name of Deployment
    spec: # Deployment's specification
      minReadySeconds: 60 # Number of seconds to wait after a Pod is created and its status is Ready
      selector:
        matchLabels:
          run: neg-hello-1
      template: # Pod template
        metadata:
          labels:
            run: neg-hello-1 # Labels Pods from this Deployment
        spec: # Pod specification; each Pod created by this Deployment has this specification
          containers:
          - image: gcr.io/google-samples/hello-app:1.0 # Application to run in Deployment's Pods
            name: neg-hello-1 # Container name
            ports:
            - containerPort: 8080 # Port used by containers running in these Pods
              protocol: TCP
            readinessProbe:
              tcpSocket:
                port: 8080
              initialDelaySeconds: 5
              periodSeconds: 10
            livenessProbe:
              tcpSocket:
                port: 8080
              initialDelaySeconds: 15
              periodSeconds: 20
          terminationGracePeriodSeconds: 60 # Number of seconds to wait for connections to terminate before shutting down Pods
    

    apiVersion: apps/v1
    kind: Deployment
    metadata:
      labels:
        run: neg-hello-2 # Label for the Deployment
      name: neg-hello-2 # Name of Deployment
    spec: # Deployment's specification
      minReadySeconds: 60 # Number of seconds to wait after a Pod is created and its status is Ready
      selector:
        matchLabels:
          run: neg-hello-2
      template: # Pod template
        metadata:
          labels:
            run: neg-hello-2 # Labels Pods from this Deployment
        spec: # Pod specification; each Pod created by this Deployment has this specification
          containers:
          - image: gcr.io/google-samples/hello-app:2.0 # Application to run in Deployment's Pods
            name: neg-hello-2 # Container name
            ports:
            - containerPort: 8080 # Port used by containers running in these Pods
              protocol: TCP
            readinessProbe:
              tcpSocket:
                port: 8080
              initialDelaySeconds: 5
              periodSeconds: 10
            livenessProbe:
              tcpSocket:
                port: 8080
              initialDelaySeconds: 15
              periodSeconds: 20
          terminationGracePeriodSeconds: 60 # Number of seconds to wait for connections to terminate before shutting down Pods
    

    --

    apiVersion: v1
    kind: Service
    metadata:
      name: neg-hello-1 # Name of Service
      annotations:
        cloud.google.com/neg: '{"ingress": true}' # Creates an NEG after an Ingress is created
    spec: # Service's specification
      selector:
        run: neg-hello-1 # Selects Pods labelled run: neg-hello-1
      ports:
      - port: 80 # Service's port
        protocol: TCP
        targetPort: 8080
    

    --

    apiVersion: v1
    kind: Service
    metadata:
      name: neg-hello-2 # Name of Service
      annotations:
        cloud.google.com/neg: '{"ingress": true}' # Creates an NEG after an Ingress is created
    spec: # Service's specification
      selector:
        run: neg-hello-2 # Selects Pods labelled run: neg-hello-2
      ports:
      - port: 80 # Service's port
        protocol: TCP
        targetPort: 8080
    

    --

    apiVersion: extensions/v1beta1
    kind: Ingress
    metadata:
      name: neg-ingress
    spec:
      rules:
      - http:
          paths:
          - backend:
              serviceName: neg-hello-1 # Name of the Service targeted by the Ingress
              servicePort: 80 # Should match the port used by the Service
            path: /*
          - backend:
              serviceName: neg-hello-2 # Name of the Service targeted by the Ingress
              servicePort: 80 # Should match the port used by the Service
            path: /v2/* 
    

    【讨论】:

    • 感谢您指出这一点 - 只是 stackoverflow 上的一个错字,我已经更正了。它们确实匹配,因为前端服务是唯一返回健康的服务。
    • 您可以查看我的答案,我确实对其进行了相应修改,请确保您留出至少 15 分钟的时间来创建入口
    • 我第一次指定frontend-svc是声明默认后端。没有它,LB 会创建一个新的后端,它不会路由到任何服务。尽管如此,我厌倦了你的建议,等了 20 分钟,尽管 GKE 就绪和活跃度探测显示其他情况,但同样的两个服务被认为是不健康的。我应该注意到原始 ingress.yaml 文件在没有 NEG 功能的情况下效果很好。我认为这很可能是 GCE 负载均衡器和 NEG 的错误。
    • 你好 Mike@,我确实成功地创建了一个 neg 集群,其中包含 2 个使用 ingress 运行的服务我可以修改我的答案以添加我使用的 yaml 文件,让我知道
    • 感谢@alioua - 不过,我们的 yaml 之间几乎没有区别。唯一的区别是我的部署在 containerPort 上指定了就绪和活跃度检查。否则,服务 + 入口是相同的,但仍然存在相同的问题。
    猜你喜欢
    • 1970-01-01
    • 2019-08-27
    • 2020-03-12
    • 1970-01-01
    • 2014-09-16
    • 2020-01-12
    • 2021-11-15
    • 2015-05-02
    • 2019-06-28
    相关资源
    最近更新 更多