Как включить HTTPS для Google Kubernetes Engine с помощью консоли - PullRequest
Новая
       44

Как включить HTTPS для Google Kubernetes Engine с помощью консоли

0 голосов
/ 12 июня 2019

Я прочитал кучу SO сообщений, статей и документов по GCP на эту тему, но я все еще в замешательстве, в основном потому, что я не человек DevOps. Представляю, используя консоль GCP, я могу щелкнуть несколько вещей, загрузить несколько сертификатов и альт! , мой API работает по HTTPS.

Этот пост заставил меня немного больше понять Ingress , но я также читал статьи, которые с использованием ClusterIP не годятся для безопасности. Поэтому я продолжаю использовать тип Load Balancer при добавлении поддержки HTTPS, не заходя в терминал. Это возможно?

РЕДАКТ. 1:

Я наткнулся на продукт балансировки нагрузки от GCP и начал его исследовать. Насколько мне известно, это было бы концептуально идеально, но я не могу заставить его работать. Мои шаги:

  • Создание балансировщика нагрузки
  • Создание серверной службы для этого LB, которая указывает на виртуальную машину Compute Engine, на которой работает GKE
  • Создание службы внешнего интерфейса, которая давала мне статический IP-адрес
  • Настройка A-записи на моем провайдере DNS для этого IP-адреса

Но я все еще получаю ошибку The server encountered a temporary error and could not complete your request при попытке посетить мое доменное имя в браузере, которая говорит мне, что каким-то образом мой балансировщик нагрузки, вероятно, работает, но он подключен к моему узлу докер-приложения в GKE.

Кто-нибудь знает, как я могу подключить продукт балансировки нагрузки с HTTPS к GKE? Или мой оригинальный вопрос, как вообще заставить GKE использовать HTTPS?

РЕДАКТИРОВАТЬ 2: Я закончил тем, что нашел конкретные шаги в документах для настройки Ingress здесь (Шаг 2b). Настройка сработала, но теперь у меня проблемы с нездоровыми бэкэнд-сервисами.

РЕДАКТИРОВАТЬ 3 За много обсуждений для НЕЗДОРОВЫХ бэкэнд-сервисов. Я попытался добавить livenessprobe и readinessprobe к моему файлу развертывания yaml следующим образом: 

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  annotations:
    deployment.kubernetes.io/revision: "4"
  creationTimestamp: 2019-06-13T00:46:01Z
  generation: 4
  labels:
    app: video-api-alpha
  name: video-api-alpha
  namespace: video-api
  resourceVersion: "926307"
  selfLink: /apis/extensions/v1beta1/namespaces/video-api/deployments/video-api-alpha
  uid: 9dd774ae-8d74-11e9-aec9-42010af0024b
spec:
  progressDeadlineSeconds: 2147483647
  replicas: 3
  revisionHistoryLimit: 10
  selector:
    matchLabels:
      app: video-api-alpha
  strategy:
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 1
    type: RollingUpdate
  template:
    metadata:
      creationTimestamp: null
      labels:
        app: video-api-alpha
    spec:
      containers:
      - image: gcr.io/mc-service-video/service-video:alpha
        imagePullPolicy: IfNotPresent
        livenessProbe:
          failureThreshold: 3
          httpGet:
            path: /healthcheck
            port: 8080
            scheme: HTTP
          periodSeconds: 10
          successThreshold: 1
          timeoutSeconds: 1
        name: service-video-sha256
        readinessProbe:
          failureThreshold: 3
          httpGet:
            path: /healthcheck
            port: 8080
            scheme: HTTP
          periodSeconds: 10
          successThreshold: 1
          timeoutSeconds: 1
        resources: {}
        terminationMessagePath: /dev/termination-log
        terminationMessagePolicy: File
      dnsPolicy: ClusterFirst
      restartPolicy: Always
      schedulerName: default-scheduler
      securityContext: {}
      terminationGracePeriodSeconds: 30
status:
  availableReplicas: 3
  conditions:
  - lastTransitionTime: 2019-06-13T00:46:03Z
    lastUpdateTime: 2019-06-13T00:46:03Z
    message: Deployment has minimum availability.
    reason: MinimumReplicasAvailable
    status: "True"
    type: Available
  observedGeneration: 4
  readyReplicas: 3
  replicas: 3
  updatedReplicas: 3

Но все равно не повезло. Есть идеи?

1 Ответ

0 голосов
/ 14 июня 2019

Если вы предоставляете службу HTTP (S), размещенную в GKE, балансировка нагрузки HTTP (S) является рекомендуемым методом для распределения нагрузки.

https://cloud.google.com/load-balancing/docs/https/

...