Два контроллера входа в одном кластере K8S - PullRequest
Новая
       143

Два контроллера входа в одном кластере K8S

1 голос
/ 06 мая 2020

Я установил следующие два разных контроллера входа на мой управляемый DigitalOcean кластер K8S:

  • Nginx

  • Istio

, и они были назначены на два разных IP-адреса. У меня вопрос: если в одном кластере K8S неправильно иметь два разных контроллера входа?

Причина, по которой я это сделал, потому что nginx предназначен для таких инструментов, как harbor, argocd, et c. и istio для микросервисов.

Я также понял, когда оба установлены рядом друг с другом, иногда во время развертывания K8S внезапно выходит из строя.

Например, я развернул: 

apiVersion: v1
kind: Service
metadata:
  name: hello-kubernetes-first
  namespace: dev
spec:
  type: ClusterIP
  ports:
    - port: 80
      targetPort: 8080
  selector:
    app: hello-kubernetes-first
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: hello-kubernetes-first
  namespace: dev
spec:
  replicas: 3
  selector:
    matchLabels:
      app: hello-kubernetes-first
  template:
    metadata:
      labels:
        app: hello-kubernetes-first
    spec:
      containers:
        - name: hello-kubernetes
          image: paulbouwer/hello-kubernetes:1.7
          ports:
            - containerPort: 8080
          env:
            - name: MESSAGE
              value: Hello from the first deployment!
---
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  annotations:
    kubernetes.io/ingress.class: istio
  name: helloworld-ingress
  namespace: dev
spec:
  rules:
    - host: hello.service.databaker.io
      http:
        paths:
          - path: /*
            backend:
              serviceName: hello-kubernetes-first
              servicePort: 80
---

Тогда у меня: 

Error from server (InternalError): error when creating "istio-app.yml": Internal error occurred: failed calling webhook "validate.nginx.ingress.kubernetes.io": Post https://ingress-nginx-controller-admission.nginx.svc:443/extensions/v1beta1/ingresses?timeout=30s: dial tcp 10.245.107.175:443: i/o timeout

Ответы [ 3 ]

1 голос
/ 09 июля 2020

Вы подняли несколько вопросов - прежде чем ответить на ваш вопрос, давайте сделаем шаг назад.

K8s Ingress не рекомендуется Istio

Важно отметить, что Istio не рекомендует использовать K8s Ingress:

Использование Istio Рекомендуется использовать Gateway , а не Ingress, для использования полного набора функций, предлагаемых Istio, таких как функции управления c и расширенного трафика *1078*.

Ref: https://istio.io/latest/docs/tasks/traffic-management/ingress/kubernetes-ingress/

Как уже отмечалось, Istio Gateway (Istio IngressGateway и EgressGateway) действует как граница, которую вы можете найти в https://istio.io/latest/docs/tasks/traffic-management/ingress/ingress-control/.

Несколько конечных точек в Istio

Если вам нужно назначить одну конечную точку publi c для бизнес-требований, а другую - для мониторинга (например, Ar go CD, Harbor, как вы упомянули), вы можете достичь только с помощью Istio. Существует примерно два подхода к этому.

  1. Создайте отдельные шлюзы Istio IngressGateways - один для основного трафика c, а другой для мониторинга
  2. Создайте один Istio IngressGateway и используйте Шлюз определение для обработки множественных шаблонов доступа

Оба действительны, и в зависимости от требований вам может потребоваться выбрать тот или иной способ.

Что касается подхода # 2. Именно здесь сияет система управления трафиком c Istio. Это отличный пример мощи Istio, но настройка будет немного сложной, если вы новичок в ней. Итак, вот пример.

Пример подхода # 2

Когда вы создаете Istio IngressGateway, следуя установке по умолчанию , будет создано istio-ingressgateway, как показано ниже (я слишком упростил определение YAML): 

apiVersion: v1
kind: Service
metadata:
  labels:
    app: istio-ingressgateway
    istio: ingressgateway
  name: istio-ingressgateway
  namespace: istio-system
  # ... other attributes ...
spec:
  type: LoadBalancer
  # ... other attributes ...

Тогда эта LB-служба будет вашей конечной точкой. (Я не знаком с env DigitalOcean K8s, но полагаю, что они справятся с созданием LB.)

Затем вы можете создать определение шлюза, как показано ниже: 

apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
  name: your-gateway
  namespace: istio-system
spec:
  selector:
    app: istio-ingressgateway
    istio: ingressgateway
  servers:
    - port:
        number: 3000
        name: https-your-system
        protocol: HTTPS
      hosts:
        - "your-business-domain.com"
        - "*.monitoring-domain.com"
      # ... other attributes ...

Затем вы можете создать 2 или более VirtualService определений. 

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: business-virtsvc
spec:
  gateways:
    - istio-ingressgateway.istio-system.svc.cluster.local
  hosts:
    - "your-business-domain.com"
  http:
    - match:
        - port: 3000
      route:
        - destination:
            host: some-business-pod
            port:
              number: 3000
    # ... other attributes ...

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: monitoring-virtsvc
spec:
  gateways:
    - istio-ingressgateway.istio-system.svc.cluster.local
  hosts:
    - "harbor.monitoring-domain.com"
  http:
    - match:
        - port: 3000
      route:
        - destination:
            host: harbor-pod
            port:
              number: 3000
    # ... other attributes ...

ПРИМЕЧАНИЕ. Приведенное выше предполагает множество вещей, таких как сопоставление портов, обработка c трафика и т. Д. c .. Пожалуйста, ознакомьтесь с официальным документом c для получения подробной информации.

Итак, вернемся к вопросу после долгого обхода:

Вопрос: [Это] неправильно иметь два разных контроллера входящего трафика в одном кластере K8S [?]

Я считаю, что это так Хорошо, хотя это может вызвать ошибку, как вы видите, поскольку два контроллера входа борются за ресурс K8s Ingress.

Как упоминалось выше, если вы используете Istio, лучше придерживаться Istio IngressGateway вместо K8s Ingress. Если вам нужен K8s Ingress по какой-то конкретной c причине, вы можете использовать другой Ingress-контроллер для K8s Ingress, например Nginx.

Что касается ошибки, которую вы видели, она исходит из Nginx развернутого веб-перехватчика, тот ingress-nginx-controller-admission.nginx.svc недоступен. Это означает, что вы создали K8s Ingress helloworld-ingress с аннотацией kubernetes.io/ingress.class: istio, но веб-перехватчик Nginx мешает обработке Ingress K8s. Затем веб-перехватчик не может обработать ресурс, поскольку Pod / Sv c, отвечающий за трафик веб-перехватчика c, не найден.

Сама ошибка просто говорит о том, что в K8s что-то не работает - потенциально недостаточно Node выделен кластеру, и, следовательно, выделения Pod не происходит. Также приятно отметить, что Istio требует некоторого объема ресурсов ЦП и памяти, что может оказывать большее давление на кластер.

0 голосов
/ 07 июля 2020

Вы смотрели, указав ingress.class (kubernetes.io/ingress.class: "nginx" ), как указано здесь? - https://kubernetes.github.io/ingress-nginx/user-guide/multiple-ingress/

0 голосов
/ 06 мая 2020

Оба продукта имеют разные характеристики и решают разные типы проблем. Итак, нет проблем с тем, чтобы оба были установлены в вашем кластере.

Неверно называть их Ingress Controller: - Nginx - хорошо известный веб-сервер - Nginx Ingress Controller - это реализация Kubernetes Ingress контроллер на основе Nginx (балансировка нагрузки, завершение HTTPS, аутентификация, трафик c маршрутизация и т. д. c) - Istio - это сервис me sh (хорошо известный в микросервисной архитектуре и используемый для решения сквозных проблем в стандартный способ - такие вещи, как ведение журнала, трассировка, завершение Https и т. д. c - на уровне POD)

Не могли бы вы подробнее объяснить, что вы имеете в виду под «K8S внезапно отключается». Вы говорите об узлах кластера или работающих внутри POD?

Спасибо.

...