GKE Kubernetes で Ingress が 503 を返す

GKE を利用時に、GKE Ingress を利用した時に、どう考えても設定が正しいのに 503 が帰る場合があった。
注意しなければいけないポイントは、

  • ヘルスチェックのURLは200を返さなければいけない (当然BASIC認証もかかっていてはいけない)
  • ヘルスチェックのURLを変更するには、Deployment の readinessProbe を設定する必要がある
  • Ingress を再作成しなければ、設定変更が反映されない

ヘルスチェックのURLは200を返さなければいけない

Ingress は Service が有効かを判定するために、アクセスログを見ればわかるが、デフォルトだと / にアクセスしてくる。このとき200を返していなければならない。

ヘルスチェックのURLを変更するには、Deployment の readwinessProbe を設定する必要がある

わかりにくいが、Ingress が確認する readinessProbe は、Ingress が参照する Service の中で利用している、Deployment 側の readinessProbe が継承される。これがとてもわかりにくい。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-deploy
spec:
  replicas: 1
  selector:
    matchLabels:
      app: web
  template:
    metadata:
      labels:
        app: web
    spec:
      containers:
        - name: web
          image: gcr.io/PROJECT_NAME/web:0.1
          ports:
            - containerPort: 80
          readinessProbe:
            httpGet:
              path: /healthcheck
              port: 80
            initialDelaySeconds: 15
            periodSeconds: 5

---
apiVersion: v1
kind: Service
metadata:
  name: web-nodeport
spec:
  type: NodePort
  selector:
    app: web
  ports:
    - port: 80
      targetPort: 80

---
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: ingress-name
  annotations:
    kubernetes.io/ingress.global-static-ip-name: my-ip
spec:
  backend:
    serviceName: web-nodeport
    servicePort: 80

Ingress を再作成しなければ、設定変更が反映されない

途中で Deployment の設定を変更しても / にずっとアクセスが来ていたが、ingress を作り直すことで反映された。
これは公開後に変更した場合はかなり困ることになるはず。

$ kubectl delete ing ingress-name
$ kubectl apply -f sample.yml