Как правильно настроить readinessProbe для контейнеров, которые перенаправляют с http на https? - PullRequest
Новая
       65

Как правильно настроить readinessProbe для контейнеров, которые перенаправляют с http на https?

0 голосов
/ 05 февраля 2019

У нас есть вход GKE, который использует приведенный ниже сервис внешнего интерфейса.Вход также завершается.Мы хотим иметь постоянные перенаправления с http на https для любого трафика, поступающего на http.

В приведенной ниже конфигурации у нас все работает и обслуживает трафик как по http, так и по https (без перенаправления).

Контейнер, используемый для развертывания, можно настроить для перезаписи http на https с помощью --https-redirect флаг.Он также уважает и доверяет заголовку X-Forwarded-Proto и будет считать его безопасным, если значение заголовка установлено на https .

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

Так что же не так с приведенным ниже подходом?Я протестировал использование переадресации портов как модуля, так и службы, и они оба возвращают 301, если я не предоставляю заголовок X-Forwarded-Proto, и возвращаем 200, если я предоставляю заголовок X-Forwarded-Proto со значением https. 

apiVersion: v1
kind: Service
metadata:
  name: frontend-service
spec:
  type: NodePort
  ports:
    - port: 8080
  selector:
    app: frontend
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: frontend
spec:
  selector:
    matchLabels:
      app: frontend
  template:
    metadata:
      labels:
        app: frontend
    spec:
      containers:
      - image: eu.gcr.io/someproject/frontend:master
        imagePullPolicy: Always
        # args:
        # - '--https-redirect'
        name: frontend
        resources:
          limits:
            memory: 1Gi
            cpu: '0.5'
        ports:
        - containerPort: 8080
          name: frontend
        readinessProbe:
          httpGet:
            path: /_readinessProbe
            port: 8080
            # httpHeaders:
            # - name: X-Forwarded-Proto
            #   value: https

1 Ответ

0 голосов
/ 05 февраля 2019

Проверка работоспособности GCP очень требовательна к кодам ответов HTTP, которые он возвращает.Это должно быть 200, а не редирект.Если в конфигурации, которую вы опубликовали, NLB получает ответ 301/302 от вашего сервера.затем он пометит ваш бэкэнд как нездоровый, поскольку это не ответ 200.Если проверка работоспособности отправляет HTTP без заголовка X-Forwarded-Proto, это вероятно.

Вы можете проверить это, проверив журналы kubectl модулей вашего развертывания.

Мой предыдущий ответ можетбудет полезно, если вы перейдете к проверке состояния HTTPS, чтобы попытаться исправить это.

Из документации GKE : вам нужно будет добавить аннотацию к определению вашей Службы, в которой говоритсяGKE использовать HTTPS для проверки работоспособности.В противном случае он попытается отправить HTTP и запутается. 

kind: Service
metadata:
  name: my-service-3
  annotations:
    cloud.google.com/app-protocols: '{"my-https-port":"HTTPS","my-http-port":"HTTP"}'
spec:
  type: NodePort
  selector:
    app: metrics
    department: sales
  ports:
  - name: my-https-port
    port: 443
    targetPort: 8443
  - name: my-http-port
    port: 80
    targetPort: 50001

Я не использовал последний синтаксис, но раньше он работал для меня.

Однако это было так неуклюже, чтобы использовать его.закончил тем, что перешел к Istio и получил это, чтобы сделать все завершение HTTPS.Однако это не так уж и мало, но если вы подумаете об использовании cert-manager / Let's Encrypt, его стоит изучить.

...