Использование GKE Ingress loadbalancer с услугами по Compute Engine

голоса
1

Я пытался получить набор услуг на как Google Kubernetes Engine и Compute Engine VM (ы) под тем же балансиром HTTP нагрузки для доступа к ним все под тем же публичным статическим IP и DNS-псевдонима. То, что я борюсь с, чтобы получить услуги по виртуальным машинам доступным.

Я получил основное решение от https://github.com/kubernetes/ingress-gce/blob/master/README.md , с замещением уже существующего развертывания для ReplicationController ( в основном добавляемые GLBC на стороне основного приложения , которое выполняется на GKE кластере).

Я пытался применить решение , предложенное в https://stackoverflow.com/a/35446176/2745865 но фиктивный сервис NodePort , который создается для экземпляра Дженкинс (который работает за пределами кластера в Compute Engine VM) остается нездоровый.

В основном приложение развертывания под контейнеры у меня есть это:

 - name: projectX-glbc
    image: gcr.io/google_containers/glbc:0.9.7
    livenessProbe:
      httpGet:
        path: /ping
        port: 8080
        scheme: HTTP
      initialDelaySeconds: 30
      timeoutSeconds: 5
    resources:
      limits:
        cpu: 100m
        memory: 100Mi
      requests:
        cpu: 100m
        memory: 50Mi
    args:
    - --apiserver-host=http://localhost:8080
    - --default-backend-service=default/projectX-test
    - --sync-period=300s

Остальные услуги:

kind: Service
apiVersion: v1
metadata:
  name: projectX-jenkins-dummyservice
spec:
  type: NodePort
  ports:
  - protocol: TCP
    port: 80

---
kind: Endpoints
apiVersion: v1
metadata:
  name: projectX-jenkins-dummyservice
subsets:
  - addresses:
    - ip: 10.156.0.2 # this IP is the static IP of the Jenkins master VM
    ports:
    - name: jenkins-master-http
      protocol: TCP
      port: 80

---
kind: Service
apiVersion: v1
metadata:
  name: projectX-test
spec:
  type: LoadBalancer
  ports:
  - name: http
    port: 80
    targetPort: projectX-backend
    protocol: TCP
  selector:
    app: projectX
    role: backend
    env: test

---
kind: Ingress
apiVersion: extensions/v1beta1
metadata:
  name: projectX-test-ingress
  annotations:
    ingress.kubernetes.io/rewrite-target: /
    kubernetes.io/ingress.global-static-ip-name: projectX-public-ip
spec:
  backend:
    serviceName: projectX-test
    servicePort: 80
  rules:
  - host: projectX.domain.invalid
    http:
      paths:
      - path: /jenkins
        backend:
          serviceName: projectX-jenkins-dummyservice
          servicePort: 80

Конечный результат этой конфигурации является то , что можно получить доступ к главному приложения на общедоступном IP (а также с псевдонимом DNS , показанным projectX.domain.invalidвыше), но projectX-test-ingressостается нездоровыми благодаря услуге бэкэнда автоматически сгенерированной для Дженкинс , имеющая «0 из 3 экземпляры здоровым». Кроме того, по крайней мере GUI показывает основное приложение Pod причудливо под как projectX-jenkins-dummyserviceи projectX-test, несмотря на то, что не должно иметь ничего общего с фиктивной службы Дженкинс. Основное приложение также получает принудительно перезагружен периодически, который мне говорит о том , что установка не настроена совсем правильно ...

Вопрос, что я делаю неправильно - или я неправильно понял и то, что я пытаюсь достичь просто невозможно (или не должно быть сделано)?

Изначально мы должны были вручную встроенный балансир HTTP нагрузки на Compute Engine, но с этим я не мог понять, как включить услуги от Kubernetes кластера (я искать только для решения с графическим интерфейсом ОТМ однако). Например https://stackoverflow.com/a/35447985/2745865 , кажется, утверждая , что это может быть сделано без объекта Kubernetes Ingress ...

Изменить: Одно решение , которое я смог придумать было выбросить NodePort projectX-jenkins-dummyserviceи ссылку на него в projectX-test-ingressконфигурации (я положил там корневой URL , указывающий на projectX-testиметь что - то там), а затем пойти и изменить систему балансировки нагрузки Compute Engine вручную из графического интерфейса , так что вместо внутреннего интерфейса GKE он направляет /jenkins, /jenkins/*к оригиналу , projectX-jenkins-backendкоторый был создан для балансировки оригинальной HTTP нагрузки.

Таким образом , я получил требуемую функциональность, но это сочетание применения YAML и ручной работы в графическом интерфейсе пользователя, и если кто - то нужно , чтобы восстановить это, возможно , было бы хлопотно ... Имея решение , построенное исключительно в .yamlфайлах будет более само- содержатся. Однако, поскольку GKE Ingress автоматически сохраняя балансировки нагрузки Compute Engine в соответствии с конфигурацией , заданной для него любые изменения вручную сделанные балансировки нагрузки в Compute стороне двигателя переписываются через некоторое время.

Задан 28/12/2017 в 10:31
источник пользователем
На других языках...                            

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more