Использование проверки подлинности HTTP basi c для readinessProbe при использовании GKE Ingress - PullRequest
Новая
       36

Использование проверки подлинности HTTP basi c для readinessProbe при использовании GKE Ingress

5 голосов
/ 17 января 2020

Я использую nosqlclient docker изображение с GKE. URL-адрес проверки работоспособности по умолчанию доступен вместе с изображением по адресу / healthcheck . Однако, когда я пытаюсь включить аутентификацию для приложения, оно также включает аутентификацию для этого URL. Мне нужно использовать GKE Ingress вместе с приложением. GKE Ingress требует, чтобы я создал HTTP readinessProbe, который может возвращать 200. Однако, когда я пытаюсь использовать этот путь для readinessCheck, проверка готовности не работает. Странно то, что при запуске kubectl describe pods <pod_name> журналы проверки готовности не появляются. Это часть моего файла развертывания yaml: 

...
    spec:
      containers:
      - name: mongoclient
        image: mongoclient/mongoclient:2.2.0
        resources:
          requests:
            memory: "32Mi"
            cpu: "100m"
          limits:
            memory: "128Mi"
            cpu: "500m"
        ports:
        - containerPort: 3000
        env:
        - name: MONGOCLIENT_AUTH
          value: "true"
        - name: MONGOCLIENT_USERNAME
          value: "admin"
        - name: MONGOCLIENT_PASSWORD
          value: "password"
        readinessProbe:
          httpGet:
            httpHeaders:
              - name: "Authorization"
                value: "Basic YWRtaW46cGFzc3dvcmQ="           
            port: 3000
            path: /healthcheck      
          initialDelaySeconds: 60
          timeoutSeconds: 5
...

Когда я пытаюсь свернуться с авторизацией из модуля, он возвращает 200, хотя: 

node@mongoclient-deployment-7c6856d6f6-mkxqh:/opt/meteor/dist/bundle$ curl -i http://localhost:3000/healthcheck
HTTP/1.1 401 Unauthorized
WWW-Authenticate: Basic realm="Authorization Required"
Date: Fri, 17 Jan 2020 18:02:20 GMT
Connection: keep-alive
Transfer-Encoding: chunked

Unauthorizednode@mongoclient-deployment-7c6856d6f6-mkxqh:/opt/meteor/dist/bundle$ curl -i http://admin:password@localhost:3000/healthcheck
HTTP/1.1 200 OK
Date: Fri, 17 Jan 2020 18:02:30 GMT
Connection: keep-alive
Transfer-Encoding: chunked

Server is up and running !
node@mongoclient-deployment-86bc77cc5b-9qg67:/opt/meteor/dist/bundle$ curl -i -H "Authorization: Basic YWRtaW46cGFzc3dvcmQ=" http://localhost:3000/healthcheck
HTTP/1.1 200 OK
Date: Sat, 18 Jan 2020 07:19:49 GMT
Connection: keep-alive
Transfer-Encoding: chunked

Некоторая дополнительная информация: 

> kubectl get pods -l app=mongoclient-app -o wide
NAME                                      READY   STATUS    RESTARTS   AGE     IP            NODE                                            NOMINATED NODE   READINESS GATES
mongoclient-deployment-7c6856d6f6-mkxqh   1/1     Running   0          5m25s   10.28.1.152   **************************************          <none>           0/1

> kubectl describe pods -l app=mongoclient-app
...
    Liveness:   http-get http://:3000/healthcheck delay=70s timeout=5s period=10s #success=1 #failure=3
    Readiness:  http-get http://:3000/healthcheck delay=60s timeout=5s period=10s #success=1 #failure=3
...

Я не могу найти никакой информации о передаче такого пользовательского заголовка через Ingress, используя ресурс конфигурации бэкенда. Даже если такая вещь работает, я использую этот же вход для других сервисов, и вмешиваться в Ingress в таком сценарии, похоже, не очень хорошая вещь.

Я новичок в GKE и Kubernetes. Так что я не уверен, есть ли другие места для поиска. Журналы стручков не предоставляли много информации о шаблонах доступа. Как я могу продолжить в этой ситуации?

Обновление 1: Итак, я обновил кластер разработки до 1.15.7-gke.2, так как он поддерживает настраиваемые заголовки для входа, и добавил следующее : 

apiVersion: cloud.google.com/v1beta1
kind: BackendConfig
metadata:
  name: mongoclient-backendconfig
spec:
  timeoutSec: 300
  connectionDraining:
    drainingTimeoutSec: 400
  sessionAffinity:
    affinityType: "GENERATED_COOKIE"
    affinityCookieTtlSec: 86400
  customRequestHeaders:
    headers:
    - "Authorization: Basic YWRtaW46cGFzc3dvcmQ="

Несмотря на то, что заголовки появляются в бэкэнде балансировщика нагрузки, время проверки готовности истекло: 

  Normal  Scheduled                15m                default-scheduler                                   Successfully assigned default/mongoclient-deployment-86bc77cc5b-9qg67 to gke-kubernetes-default-pool-50ccdc3e-d608
  Normal  LoadBalancerNegNotReady  15m (x2 over 15m)  neg-readiness-reflector                             Waiting for pod to become healthy in at least one of the NEG(s): [k8s1-00c7387d-default-mongoclient-mayamd-ai-service-80-292db9f4]
  Normal  Pulled                   15m                kubelet, gke-kubernetes-default-pool-50ccdc3e-d608  Container image "mongoclient/mongoclient:2.2.0" already present on machine
  Normal  Created                  15m                kubelet, gke-kubernetes-default-pool-50ccdc3e-d608  Created container mongoclient
  Normal  Started                  15m                kubelet, gke-kubernetes-default-pool-50ccdc3e-d608  Started container mongoclient
  Normal  LoadBalancerNegTimeout   5m43s              neg-readiness-reflector                             Timeout waiting for pod to become healthy in at least one of the NEG(s): [k8s1-00c7387d-default-mongoclient-mayamd-ai-service-80-292db9f4]. Marking condition "cloud.google.com/load-balancer-neg-ready" to True.
...