GKE Ingress with NEGs: backend healthcheck doesn't pass

Viewed 3459

I have created GKE Ingress as follows:

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

I don't know what I'm doing wrong because my heathchecks are not Ok. And based on the perimeter logging I added to the app, nothing is even trying to hit that pod.

I've tried BackendConfig for both 8080 and 5000.
By the way, it's not 100% clear based on the docs if Load Balancer should be configured to targetPorts of corresponding Pods or Services.

The healthcheck is registered with HTTP Load Balancer and Compute Engine: enter image description here

It seems that something is not right with the Backend service IP.

The corresponding backend service configuration:

$ 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

(port 80 looks really suspicious but I thought maybe it's just left there as default and is not in use when NEGs are configured).

1 Answers

Figured it out. By default, even the latest GKE clusters are created with no IP Alias support. It's also called VPC-native. I didn't even bother to check that initially because:

  • NEGs are supported out of the box, and what's more they seem to be default with no need for explicit annotation when used on the GKE version I had(1.17.8-gke.17). It doesn't make sense to not enable IP Aliases by default then because it basically means that cluster is in a non-functional state by default.
  • I didn't check VPC-Native support initially, because this name for the feature is simply misleading. I had extensive prior experience with AWS and my faulty assumption was that VPC-Native is like EC2-VPC, as opposed to EC2-Classic, which is legacy.
Related