#kubernetes #haproxy-ingress
#kubernetes #haproxy-вход
Вопрос:
Я установил контроллер входа через helm в качестве набора демонов. Я настроил вход следующим образом:
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: webapp-ingress
namespace: rcc
annotations:
haproxy.org/check: 'true'
haproxy.org/check-http: /serviceCheck
haproxy.org/check-interval: 5s
haproxy.org/cookie-persistence: SERVERID
haproxy.org/forwarded-for: 'true'
haproxy.org/load-balance: leastconn
kubernetes.io/ingress.class: haproxy
spec:
rules:
- host: example.com
http:
paths:
- path: /
pathType: Prefix
backend:
service:
name: webapp-frontend
port:
number: 8080
kubectl get ingress -n rcc
Warning: extensions/v1beta1 Ingress is deprecated in v1.14 , unavailable in v1.22 ; use networking.k8s.io/v1 Ingress
NAME CLASS HOSTS ADDRESS PORTS AGE
webapp-ingress <none> example.com 10.110.186.170 80 11h
Выбран тип loadbalancer.
Я могу выполнить пинг с любого узла, ip-адрес входа на порт 80 также может его просто свернуть. Я также могу отлично просматривать любой IP-адрес входных модулей с узла. Но когда я просматриваю IP-адрес узла o порт 80, я получаю отказ в подключении. Что-нибудь, чего мне здесь не хватает?
Комментарии:
1. находится ли ваш кластер в управляемом облачном сервисе? расскажите нам немного больше!
2. Это самостоятельный кластер, размещенный через kubeadm. Использование cri-o в качестве движка.
3. Что
type
такое служба входа haproxy?kubectl get svc -n haproxy_namespace
. Скорее всегоNodePort
, тогда вам нужно получить доступ к вашему входу,node_IP:NodePort
потому что порт80
открыт внутри кластера (в то время как кластеры, построенные с использованиемkubeadm
, имеют это подключение от узлов к внутренней настройке кластера). Другой вариант — использоватьmetallb
(см. Здесь ) изменить службу haproxytype
наloadbalancer
.
Ответ №1:
Я установил последнюю haproxy ingress
0.13.4
версию, используя helm.
По умолчанию он установлен с LoadBalancer
типом service:
$ kubectl get svc -n ingress-haproxy
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
haproxy-ingress LoadBalancer 10.102.166.149 <pending> 80:30312/TCP,443:32524/TCP 3m45s
Поскольку у меня тот же kubeadm
кластер, EXTERNAL-IP
будет ожидаться. И, как вы правильно упомянули в вопросе, CLUSTER-IP
доступен на узлах при настройке кластера с использованием kubeadm
.
Есть два варианта доступа к вашему входу:
- Использование
NodePort
:
Из вывода выше есть NodePort 30312
для внутреннего открытого порта 80
. Поэтому извне кластера к нему должен быть доступен Node_IP:NodePort
:
curl NODE_IP:30312 -IH "Host: example.com"
HTTP/1.1 200 OK
- Настройка
metallb
:
Следуйте инструкциям по установке, и второй шаг — настройка metallb
. Я использую уровень 2. Будьте осторожны, чтобы назначить неиспользуемый диапазон ip!
После того, как я установил и настроил metallb
, мой haproxy EXTERNAL-IP
теперь:
$ kubectl get svc -n ingress-haproxy
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
haproxy-ingress LoadBalancer 10.102.166.149 172.16.1.241 80:30312/TCP,443:32524/TCP 10m
И теперь я могу получить доступ к ingress через EXTERNAL-IP
порт on 80
:
curl 172.16.1.241 -IH "Host: example.com"
HTTP/1.1 200 OK
Полезно для чтения:
Комментарии:
1. Круто, я на шаг ближе. Я запросил у поставщика услуг vps два IP-адреса и настроил metallb, я вижу, что внешний IP-адрес настроен на один из внешних IP-адресов. Но изнутри главного узла я могу просматривать, но снаружи он не работает. Но сообщение об ошибке — это тайм-аут, а не отклонение, как раньше.
2. На данный момент это становится вопросом конфигурации сети. Похоже, он правильно настроен на главном узле (также есть другие узлы в той же подсети? Он работает нормально?) Поскольку вы упомянули «поставщика услуг vps», я склонен думать, что речь идет об облачных провайдерах. Поэтому проверьте metallb на облачных платформах . В идеале вы должны использовать балансировщик нагрузки, который может предоставить облако.
3. @zozo6015 Если это команда / отдел локальной сети, я полагаю, они должны позаботиться о маршрутизации и всем остальном за пределами виртуальной машины / целевой сети / подсети.
4. это ovh, и он не предоставляет услуги типа loadbalancer. Кроме того, кластер k8s построен с помощью kubeadm на vps, а не на платформе хостинга kubernetes.
5. Впервые слышу об этом облачном провайдере. Я понимаю, что это не управляемая служба k8s. Для меня это вопрос, отличный от оригинального, и следует задать другой вопрос . Поэтому я бы сначала попросил облачного провайдера устранить неполадки и убедиться, что трафик действительно поступает на узел. Например. установите простой сервер nginx и убедитесь, что трафик может достичь его. Тогда это сетевая настройка
metallb
вашего облачного провайдера. К сожалению, я не сетевой инженер, чтобы помочь с этой частью.