Контроллер входа Haproxy

#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 (см. Здесь ) изменить службу haproxy type на 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 .


Есть два варианта доступа к вашему входу:

  1. Использование NodePort :

Из вывода выше есть NodePort 30312 для внутреннего открытого порта 80 . Поэтому извне кластера к нему должен быть доступен Node_IP:NodePort :

 curl NODE_IP:30312 -IH "Host: example.com"
HTTP/1.1 200 OK
 
  1. Настройка 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 вашего облачного провайдера. К сожалению, я не сетевой инженер, чтобы помочь с этой частью.