курл не работает nginx со всеми сервисами kubernetes, использующими сеть NAT в virtualbox

Вопрос или проблема

Моя конфигурация:
Kubernetes с использованием VirtualBox с 6 ВМ на NAT NETWORK.
1 ВМ

  • Ansible с kube для взаимодействия с моим кластером kube ip 10.0.2.90
    и 5 ВМ с
  • 3 мастер (10.0.2.21 - 22 - 23)
  • 2 узла ( 10.0.2.31-32).
    Я установил Kubernetes с помощью kubespray
    Все работает хорошо, кроме связи с сервисом.
    LoadBalancer с metallb -> настроил Metallb согласно официальной документации.

Я не могу выполнить curl nginx с использованием внешнего IP или NodePort из моей ansible ВМ, которая находится в той же сети nat, что и мой кластер kube.

Я могу выполнить curl pod с использованием внешнего IP или Nodeport IP только с узла кластера или мастера.

cat /etc/hosts
127.0.1.1 automation
10.0.2.90 automation
10.0.2.21 k8sm1 
10.0.2.22 k8sm2
10.0.2.23 k8sm3
10.0.2.31 node1k8s
#10.0.2.32 node2k8s 
10.0.2.33 node3k8s



kubectl get nodes
NAME       STATUS     ROLES           AGE   VERSION
k8sm1      Ready      control-plane   10d   v1.32.0
k8sm2      Ready      control-plane   10d   v1.32.0
k8sm3      Ready      control-plane   10d   v1.32.0
node1k8s   Ready      <none>          10d   v1.32.0
node2k8s   NotReady   <none>          10d   v1.32.0
node3k8s   Ready      <none>          10d   v1.32.0

METALLB configmap

apiVersion: metallb.io/v1beta1
kind: IPAddressPool
metadata:
  name: first-pool
  namespace: metallb-system
spec:
  addresses:
  - 192.168.2.240-192.168.2.250

И STRICTArp установлен в true

2 pods nginx

kubectl get po -o wide
NAME       READY   STATUS    RESTARTS   AGE   IP               NODE       NOMINATED NODE   READINESS GATES
backend    1/1     Running   0          69m   10.233.119.238   node3k8s   <none>           <none>
frontend   1/1     Running   0          61m   10.233.67.123    node1k8s   <none>           <none>

 kubectl get svc
NAME          TYPE           CLUSTER-IP      EXTERNAL-IP     PORT(S)        AGE
kubernetes    ClusterIP      10.233.0.1      <none>          443/TCP        14d
svcbalancer   LoadBalancer   10.233.1.61     192.168.2.240   80:32106/TCP   29m
svcnode       NodePort       10.233.43.105   <none>          80:31062/TCP   71m

 kubectl describe svc svcbalancer
Name:                     svcbalancer
Namespace:                default
Labels:                   <none>
Annotations:              metallb.io/ip-allocated-from-pool: first-pool
Selector:                 app=balancer
Type:                     LoadBalancer
IP Family Policy:         SingleStack
IP Families:              IPv4
IP:                       10.233.1.61
IPs:                      10.233.1.61
LoadBalancer Ingress:     192.168.2.240 (VIP)
Port:                     <unset>  80/TCP
TargetPort:               80/TCP
NodePort:                 <unset>  32106/TCP
Endpoints:                10.233.67.123:80
Session Affinity:         None
External Traffic Policy:  Cluster
Internal Traffic Policy:  Cluster
Events:
  Type    Reason       Age   From                Message
  ----    ------       ----  ----                -------
  Normal  IPAllocated  30m   metallb-controller  Assigned IP ["192.168.2.240"]

kubectl describe svc svcnode
Name:                     svcnode
Namespace:                default
Labels:                   <none>
Annotations:              <none>
Selector:                 app=test
Type:                     NodePort
IP Family Policy:         SingleStack
IP Families:              IPv4
IP:                       10.233.43.105
IPs:                      10.233.43.105
Port:                     <unset>  80/TCP
TargetPort:               80/TCP
NodePort:                 <unset>  31062/TCP
Endpoints:                10.233.119.238:80
Session Affinity:         None
External Traffic Policy:  Cluster
Internal Traffic Policy:  Cluster
Events:                   <none>

Можете помочь мне отладить эту проблему?

Спасибо

Ответ или решение

Проблема, с которой вы столкнулись, связана со сложностью настройки сетевой инфраструктуры Kubernetes кластера при использовании VirtualBox и NAT-сети. Давайте разберем возможные причины и шаги для решения этой проблемы через призму теоретической части, примеров, и практического применения.

Теория:

Основная задача заключается в обеспечении правильной маршрутизации и доступности сервисов внутри кластера Kubernetes и их взаимодействия с внешними элементами инфраструктуры. В частности, вы использовали MetalLB для распределения сетевых ресурсов через LoadBalancer. Однако, NAT-сеть VirtualBox может создать ограничения в сетевой доступности, поскольку NAT (Network Address Translation) обычно не поддерживает коммуникацию по специфическим портам или IP-адресам за пределами упрощенной внутренней сети.

Когда речь идет о Kubernetes, нужно учитывать следующие моменты:

  1. Сетевая конфигурация: NAT в VirtualBox обычно позволяет выходить в интернет, но изолирует виртуальные машины в контексте внешнего доступа, что может затруднить привязку и доступ к внешним IP-адресам или портам, выделенным MetalLB.

  2. LoadBalancer в локальных средах: Он обеспечивает возможность получения внешнего IP, доступного для коммуникации с интернетом. Однако в локальных средах, таких как VirtualBox, могут возникать проблемы с маршрутизацией.

  3. NodePort: Этот режим позволяет выделять специфические порты на нодах для доступа из внешних сетей. Но и здесь NAT-сеть может стать преградой на пути внешнего подключения к этим портам.

Пример:

В вашей конфигурации, если вы пытаетесь выполнить запрос curl с Ansible машины на NAT-сети к внешнему IP или NodePort, выделенному nginx-подом, NAT-сеть может не содержать корректные маршруты для таких внешних IP. Подобные проблемы были отмечены и в других конфигурациях, особенно в локальных тестовых кластерах.

Практическое применение:

Для решения этой проблемы:

  1. Проверка сетевой конфигурации VirtualBox:

    • Убедитесь, что NAT-сеть правильно налаштована и поддерживает требуемые для Kubernetes маршруты.
    • Рассмотрите возможность создания сеть Bridge в VirtualBox вместо NAT. Bridge сеть может предоставить внешние IP адреса, которые будут видимы из вашей локальной сети, тем самым расширяя доступ за пределы виртуализированной среды.
  2. Проблемы с MetalLB:

    • Проверьте конфигурацию MetalLB и убедитесь, что диапазон IP-адресов, выделенный MetalLB, находится в пределах допустимой сети NAT или Bridge, если вы используете их.
    • Возможно, стоит попробовать другой IP пул или проверить правила firewall, чтобы убедиться, что порты не блокируются.
  3. NodePort и внешний доступ:

    • Убедитесь, что порты NodePort открыты и правильно настроены. Иногда NAT сеть может блокировать специфицированные порты из-за отсутствия проброса портов. Например, в настройках маршрутизации VirtualBox могут быть конфликты в пробросе портов, что требует проверки и корректировки.
  4. Альтернативы и отладка:

    • Используйте tcpdump или аналогичные инструменты для анализа сетевых пакетов и диагностики проблемных мест в маршрутизации.
    • Проверьте журналы MetalLB и сервиса Kubernetes на предмет ошибок или предупреждений, которые могут указать на проблемные участки.

Полностью оценив и перепроверив конфигурацию каждой из сетевых компонентов и любого сетевого оборудования, используемого в сети, вы сможете диагностировать и исправить проблему с доступом к внешним сервисам вашего Kubernetes кластера.

Оцените материал
Добавить комментарий

Капча загружается...