Вы подняли несколько вопросов - прежде чем ответить на ваш вопрос, давайте сделаем шаг назад.
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. Существует примерно два подхода к этому.
- Создайте отдельные шлюзы Istio IngressGateways - один для основного трафика c, а другой для мониторинга
- Создайте один 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 требует некоторого объема ресурсов ЦП и памяти, что может оказывать большее давление на кластер.