Нездоровые бэкэнды, использующие группы конечных точек сети GCP для собственной балансировки нагрузки контейнера

Question

мы тестируем новую функцию Google для балансировки нагрузки контейнера .Мы успешно следовали этому учебнику и пытаемся внедрить его в наши три службы в GKE.

Насколько я могу судить, единственная разница между функцией NEG иУстаревший входящий объект GCLB - это аннотации в каждой службе, поэтому сопоставление URL должно работать одинаково.

Мы обновили все службы, чтобы использовать эту аннотацию, но две из трех - Unhealthy, хотя одна считаетсяздоровый.Единственные различия в сервисе yamls - это имя и селектор.

Все развертывания имеют проверки работоспособности и исправны, когда мы проверяем вручную, но 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

Answer 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", которого нет у вас на входе.

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/*