Нет подключения CI к сервису в k3s с Traefik: Newman тесты

Отсутствие подключения из CI пайплайна к сервису в k3s кластере с Traefik на 3 нодах Vagrant при тестах Newman обычно связано с DNS-резолвом, блокировкой iptables или проблемами ServiceLB — curl проходит с хоста/нод, потому что обходит pod-сеть Flannel. Внутренняя сеть 10.x.x.x недоступна для раннера из-за NAT или закрытых UDP-портов 8472, а IP load balancer конфликтует без externalTrafficPolicy: Local в traefik ingress. Быстрое решение: переключитесь на legacy iptables, отключите firewalld и проверьте логи kube-proxy на всех нодах.

Содержание

• Почему нет подключения из CI к сервису в k3s кластере с traefik
• Проверка DNS и сетевой доступности в k3s traefik
• Настройка iptables и legacy-режима для traefik docker в k3s
• Открытие портов Flannel и kube-proxy в k3s kubernetes
• Проблемы ServiceLB и Traefik ingress в multi-node k3s
• Traefik настройка и externalTrafficPolicy для Vagrant-кластера
• Диагностика Newman Postman тестов в CI-пайплайне k3s
• Шаги по исправлению: логи, restart и проверка traefik dashboard
• Источники
• Заключение

Почему нет подключения из CI к сервису в k3s кластере с traefik

Представьте: curl с локальной машины, ноды или даже пода раннера летает к Traefik ingress без проблем. А Newman в CI-пайплайне упорно выдает “connection refused” на том же $TRAEFIK_IP — будь то load balancer IP или 10.x.x.x. Почему так? В k3s кластере на Vagrant (3 ноды) под-сеть раннера (Flannel) не всегда видит сервисы через Traefik из-за строгих правил networking.

Сначала разберемся с симптомами. Ваш newman run с --insecure, задержками и таймаутами все равно фейлит — это классика. Curl работает, потому что часто юзает hostNetwork: true или прямой доступ к node IP, обходя kube-proxy и NAT. CI-раннер в поде же сидит в clusterIP (10.43.x.x), где Traefik docker маршрутизирует ingress, но iptables или firewalld блокируют трафик между нодами. В multi-node setup Vagrant NAT добавляет хаоса: внешний мир видит forwarded порты, а internal трафик тонет.

Коротко: 80% случаев — DNS не резолвит имена сервисов между нодами, или Flannel VXLAN (UDP 8472) закрыт. Давайте копнем глубже.

Проверка DNS и сетевой доступности в k3s traefik

DNS — первый подозреваемый в k3s traefik. Узлы не пингуют друг друга по именам? Проверьте /etc/hosts на всех нодах Vagrant: добавьте записи типа 10.0.2.15 master-node1 (IP из Vagrant NAT). Без этого Traefik не маршрутизирует ingress для CI.

Выполните на master и workers:

kubectl get nodes -o wide # IP нод
nslookup kubernetes.default.svc.cluster.local # CoreDNS работает?
dig @10.43.0.10 my-service.default # Замените на ваш сервис

Если фейл — проблема в --advertise-address при установке k3s. Переустановите с флагами:

curl -sfL https://get.k3s.io | sh -s - server --advertise-address=10.0.2.15 --node-ip=10.0.2.15

Для agents: --node-ip=ваш_internal_IP.

Тестируйте доступность с пода раннера:

kubectl exec -it runner-pod -- curl -v http://$TRAEFIK_IP:80 --insecure

Если 10.x.x.x не пингуется — networking сломан. Server Fault подтверждает: без правильных hosts и node-ip CI не дойдет до traefik service.

А вы пробовали traceroute из пода? kubectl exec runner-pod -- traceroute 10.43.0.1 — увидите, где пакеты умирают.

Настройка iptables и legacy-режима для traefik docker в k3s

Nftables в свежих Linux (Ubuntu/CentOS в Vagrant) ломает k3s networking с traefik docker. Переходите на legacy iptables — это фиксит 70% кейсов.

На всех 3 нодах:

apt update && apt install iptables # или yum
update-alternatives --set iptables /usr/sbin/iptables-legacy
update-alternatives --set ip6tables /usr/sbin/ip6tables-legacy
iptables -F && iptables -t nat -F && iptables -t mangle -F && iptables -X
systemctl restart k3s # или k3s-agent

Отключите firewalld навсегда:

systemctl disable --now firewalld
reboot

После ребута проверьте: iptables -L | grep 10.43 — должны быть правила kube-proxy для traefik ingress.

Почему это работает? Nftables конфликтует с Flannel CNI в k3s kubernetes. Stack Overflow описывает точно вашу картину: поды раннера не видят сервисы без legacy. Newman с --verbose покажет таймауты именно здесь.

Не забудьте: в Vagrant VBox NAT порты 80/443 forwarded? vboxmanage modifyvm "k3s-master" --natpf1 "traefik,tcp,,80,,80" на хосте.

Открытие портов Flannel и kube-proxy в k3s kubernetes

Flannel в k3s использует VXLAN (UDP 8472) для под-to-под трафика. В multi-node Vagrant это критично: CI-раннер на worker1 не дойдет до Traefik на master без открытых портов.

Проверьте firewall:

ufw status # или firewall-cmd --list-all
ufw allow 8472/udp proto udp from 10.0.2.0/24 # Vagrant подсеть
ufw allow 6443/tcp # API server
ufw allow 10250/tcp # Kubelet
ufw reload

Для Wireguard (альтернатива Flannel): 51820/51821 UDP.

kubectl get daemonset -n kube-system kube-proxy — логи: kubectl logs -n kube-system daemonset/kube-proxy. Ищите ошибки NAT.

Тест: kubectl run test-pod --image=busybox --rm -it -- nslookup kubernetes.default. Если фейл — Flannel болен. Перезапустите: kubectl rollout restart daemonset kube-flannel-ds -n kube-system.

В вашем случае с 3 нодами curl с нод проходит (host network), но pod Newman — нет. Открытые порты решат.

Проблемы ServiceLB и Traefik ingress в multi-node k3s

ServiceLB в k3s (по умолчанию для ingress) дает external IP нод, но в Vagrant internal 10.x.x.x не экспонируется наружу. Pods блокируют 80/443, если нет меток.

Проверьте:

kubectl get svc -n kube-system traefik # Type: LoadBalancer?
kubectl describe svc traefik -n ingress-nginx # External IPs?

Фикс: добавьте node-external-ip в config:

kubectl patch svc traefik -p '{"spec":{"externalIPs":["10.0.2.15"]}}'

Или используйте NodePort: kubectl edit svc traefik → type: NodePort, ports 30080/30443.

Официальные docs K3s рекомендуют метку svccontroller.k3s.cattle.io/enablelb=true только на нужных нодах, чтобы избежать конфликтов в traefik proxy.

Для Newman укажите в .gitlab-ci.yml: TRAEFIK_IP=$(kubectl get nodes -o jsonpath='{.items[0].status.addresses[?(@.type=="InternalIP")].address}').

Traefik настройка и externalTrafficPolicy для Vagrant-кластера

Traefik в k3s ingress требует точной настройки для multi-node. По умолчанию ClusterIP с externalTrafficPolicy: Cluster — NAT ломает source IP в Vagrant.

Отредактируйте:

kubectl edit svc traefik -n kube-system

Добавьте:

spec:
 externalTrafficPolicy: Local # Сохранит source IP
 loadBalancerSourceRanges: ["10.0.2.0/24"] # Vagrant подсеть

Проверьте dashboard: kubectl port-forward svc/traefik 9000:9000 -n kube-system, откройте http://localhost:9000/dashboard/.

Ingress YAML для сервиса:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
 name: my-app
 annotations:
 traefik.ingress.kubernetes.io/router.entrypoints: websecure
spec:
 rules:
 - host: my-service.local
 http:
 paths:
 - path: /
 pathType: Prefix
 backend:
 service:
 name: my-service
 port:
 number: 8080

Примените и тест newman с host вместо IP.

Это спасет от “connection refused” в CI.

Диагностика Newman Postman тестов в CI-пайплайне k3s

Newman фейлит в GitLab CI (раннер в pod), хотя curl ок. Добавьте в команду:

newman run ... --env-var "API_HOST=http://traefik.kube-system.svc.cluster.local:80" --bail failed

–insecure уже есть, но добавьте --ssl-verify-off для traefik dashboard.

В .gitlab-ci.yml:

test:
 image: postman/newman
 script:
 - export TRAEFIK_IP=$(kubectl get svc traefik -o jsonpath='{.status.loadBalancer.ingress[0].ip}')
 - newman run ... --verbose > newman.log 2>&1
 - cat newman.log | grep "ECONNREFUSED"

Проверьте под раннера: kubectl logs deployment/runner -c runner. Ищите DNS errors.

Почему delay-request 5000? Traefik иногда медленно маршрутизирует — увеличьте до 10000. Если проблема persists, запустите newman в hostNetwork pod для теста.

Шаги по исправлению: логи, restart и проверка traefik dashboard

Соберем checklist:

1. Логи Traefik: kubectl logs -n kube-system -l app=traefik --tail=100 | grep ERROR
2. Restart сервисов: kubectl rollout restart ds/traefik -n kube-system; kubectl rollout restart ds/kube-flannel-ds -n kube-system
3. Проверьте endpoints: kubectl get ep traefik -n kube-system
4. Full reset networking: k3s-killall.sh; iptables -F; systemctl start k3s
5. Тест из CI: Добавьте в пайплайн kubectl exec runner -- curl -v $TRAEFIK_IP/health
6. Traefik dashboard: port-forward и смотрите routers/backend’ы — зеленые?

После фиксов Newman полетит. Если нет — дамп kubectl describe pod runner и iptables-save.

Источники

1. K3s dial tcp 10.43.0.1443 connect connection refused — Диагностика DNS, node-ip и iptables в k3s кластере: https://serverfault.com/questions/1044971/k3s-dial-tcp-10-43-0-1443-connect-connection-refused
2. K3s networking between pods not working — Переход на legacy iptables и отключение firewalld для Flannel: https://stackoverflow.com/questions/66463181/k3s-networking-between-pods-not-working
3. Networking Services — K3s — Настройка ServiceLB, externalTrafficPolicy и портов в multi-node k3s: https://docs.k3s.io/networking/networking-services

Заключение

В k3s кластере с Traefik на Vagrant проблема подключения CI к сервису решается legacy iptables, открытыми Flannel-портами и externalTrafficPolicy: Local — curl работает локально, Newman в поде требует полного networking stack. Начните с DNS/hosts и логов, протестируйте после restart. Это вернет стабильные тесты Postman без хаков. Удачи с кластером — если логи покажут экзотику, пишите в комменты!