GKE Ingress с NEG: проверка работоспособности серверной части не проходит - PullRequest
Новая
       61

GKE Ingress с NEG: проверка работоспособности серверной части не проходит

1 голос
/ 01 августа 2020

Я создал GKE Ingress следующим образом: 

apiVersion: cloud.google.com/v1beta1 #tried cloud.google.com/v1 as well
kind: BackendConfig
metadata:
  name: backend-config
  namespace: prod
spec:
  healthCheck:
    checkIntervalSec: 30
    port: 8080
    type: HTTP #case-sensitive
    requestPath: /healthcheck
  connectionDraining:
    drainingTimeoutSec: 60

---
apiVersion: v1
kind: Service
metadata:
  name: web-engine-service
  namespace: prod
  annotations:
    cloud.google.com/neg: '{"ingress": true}' # Creates a NEG after an Ingress is created.
    cloud.google.com/backend-config: '{"ports": {"web-engine-port":"backend-config"}}' #https://cloud.google.com/kubernetes-engine/docs/how-to/ingress-features#associating_backendconfig_with_your_ingress
spec:
  selector:
    app: web-engine-pod
  ports:
    - name: web-engine-port
      protocol: TCP
      port: 8080
      targetPort: 5000

---
apiVersion: apps/v1
kind: Deployment
metadata:
  annotations:
    deployment.kubernetes.io/revision: "1"
  labels:
    app: web-engine-deployment
    environment: prod
  name: web-engine-deployment
  namespace: prod
spec:
  progressDeadlineSeconds: 600
  replicas: 1
  revisionHistoryLimit: 10
  selector:
    matchLabels:
      app: web-engine-pod
  strategy:
    rollingUpdate:
      maxSurge: 25%
      maxUnavailable: 25%
    type: RollingUpdate
  template:
    metadata:
      name: web-engine-pod
      labels:
        app: web-engine-pod
        environment: prod
    spec:
      containers:
        - image: my-image:my-tag
          imagePullPolicy: Always
          name: web-engine-1
          resources: {}
          ports:
            - name: flask-port
              containerPort: 5000
              protocol: TCP
          readinessProbe:
            httpGet:
              path: /healthcheck
              port: 5000
            initialDelaySeconds: 30
            periodSeconds: 100
      restartPolicy: Always
      terminationGracePeriodSeconds: 30
---
apiVersion: networking.gke.io/v1beta2
kind: ManagedCertificate
metadata:
  name: my-certificate
  namespace: prod
spec:
  domains:
    - api.mydomain.com #https://cloud.google.com/load-balancing/docs/ssl-certificates/google-managed-certs#renewal

---
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  name: prod-ingress
  namespace: prod
  annotations:
    kubernetes.io/ingress.allow-http: "false"
    kubernetes.io/ingress.global-static-ip-name: load-balancer-ip
    networking.gke.io/managed-certificates: my-certificate
spec:
  rules:
    - http:
        paths:
          - path: /model
            backend:
              serviceName: web-engine-service
              servicePort: 8080

Я не знаю, что делаю неправильно, потому что мои медицинские проверки не в порядке. И, судя по ведению журнала периметра, которое я добавил в приложение, ничто даже не пытается поразить этот модуль.

Я пробовал BackendConfig для 8080 и 5000. Между прочим, из документации не совсем ясно, следует ли настроить Load Balancer на targetPorts соответствующих модулей или служб.

Проверка работоспособности зарегистрирована с помощью HTTP Load Balancer и Compute Engine: введите описание изображения здесь

Кажется, что-то не так с IP-адресом серверной службы.

Соответствующая конфигурация серверной службы: 

$ gcloud compute backend-services describe k8s1-85ef2f9a-prod-web-engine-service-8080-b938a707
...

affinityCookieTtlSec: 0
backends:
- balancingMode: RATE
  capacityScaler: 1.0
  group: https://www.googleapis.com/compute/v1/projects/wnd/zones/europe-west3-a/networkEndpointGroups/k8s1-85ef2f9a-prod-web-engine-service-8080-b938a707
  maxRatePerEndpoint: 1.0
connectionDraining:
  drainingTimeoutSec: 60
creationTimestamp: '2020-08-01T11:14:06.096-07:00'
description: '{"kubernetes.io/service-name":"prod/web-engine-service","kubernetes.io/service-port":"8080","x-features":["NEG"]}'
enableCDN: false
fingerprint: 5Vkqvg9lcRg=
healthChecks:
- https://www.googleapis.com/compute/v1/projects/wnd/global/healthChecks/k8s1-85ef2f9a-prod-web-engine-service-8080-b938a707
id: '2233674285070159361'
kind: compute#backendService
loadBalancingScheme: EXTERNAL
logConfig:
  enable: true
  sampleRate: 1.0
name: k8s1-85ef2f9a-prod-web-engine-service-8080-b938a707
port: 80
portName: port0
protocol: HTTP
selfLink: https://www.googleapis.com/compute/v1/projects/wnd/global/backendServices/k8s1-85ef2f9a-prod-web-engine-service-8080-b938a707
sessionAffinity: NONE
timeoutSec: 30

(порт 80 выглядит действительно подозрительно, но Я подумал, может быть, он просто оставлен по умолчанию и не используется при настройке NEG).

1 Ответ

1 голос
/ 03 августа 2020

Разобрался. По умолчанию даже самые последние кластеры GKE создаются без поддержки псевдонимов IP. Его также называют VP C -native . Я даже не потрудился проверить это изначально, потому что:

  • NEG поддерживаются из коробки, и, более того, они кажутся по умолчанию без необходимости в явной аннотации при использовании в GKE версии I. имел (1.17.8-gke.17). Тогда нет смысла не включать IP-псевдонимы по умолчанию, потому что это в основном означает, что кластер по умолчанию находится в нефункциональном состоянии.
  • Первоначально я не проверял поддержку VPC-Native, потому что это имя поскольку эта функция просто вводит в заблуждение. У меня был обширный предыдущий опыт работы с AWS, и мое ошибочное предположение заключалось в том, что VPC-Native похож на EC2-VP C, в отличие от EC2-Classi c, который является устаревшим.
...