Вопрос или проблема
Я настроил кластер kubernetes 1.30.3 из одного controlplane (192.168.0.14) и одного worker (192.168.0.15), работающий на Talos 1.7.6 в ВМ с использованием KVM на TrueNAS SCALE.
Пытаюсь использовать truecharts для настройки нескольких базовых сервисов через helm. Сначала MetalLB. Я успешно сконфигурировал его для использования пула IP-адресов от 192.168.0.16 до 192.168.0.30.
Теперь, когда я добавляю сервис, в данном случае adminer, и конфигурирую его как LoadBalancer, он получает IP 192.168.0.16 и слушает порт 18080. Однако при попытке подключиться к этому порту происходит таймаут.
Мой values.yaml для metallb-config выглядит так:
ipAddressPools:
- name: apps
autoAssign: true
avoidBuggyIPs: false
addresses:
- 192.168.0.16-192.168.0.30
L2Advertisements:
- name: l2adv
addressPools:
- apps
А для adminer:
service:
main:
type: LoadBalancer
kubectl describe svc adminer:
Name: adminer
Namespace: default
Labels: app=adminer-10.1.4
app.kubernetes.io/instance=adminer
app.kubernetes.io/managed-by=Helm
app.kubernetes.io/name=adminer
app.kubernetes.io/version=latest
helm-revision=1
helm.sh/chart=adminer-10.1.4
release=adminer
service.name=main
Annotations: meta.helm.sh/release-name: adminer
meta.helm.sh/release-namespace: default
metallb.universe.tf/allow-shared-ip: adminer
metallb.universe.tf/ip-allocated-from-pool: apps
Selector: app.kubernetes.io/instance=adminer,app.kubernetes.io/name=adminer,pod.name=main
Type: LoadBalancer
IP Family Policy: SingleStack
IP Families: IPv4
IP: 10.100.233.191
IPs: 10.100.233.191
LoadBalancer Ingress: 192.168.0.16
Port: main 18080/TCP
TargetPort: 8080/TCP
Endpoints:
Session Affinity: None
External Traffic Policy: Cluster
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal IPAllocated 9s metallb-controller Assigned IP ["192.168.0.16"]
nmap -Pn -p 18080 192.168.0.16:
Starting Nmap 7.95 ( https://nmap.org ) at 2024-08-22 11:04 CEST
Nmap scan report for 192.168.0.16
Host is up.
PORT STATE SERVICE
18080/tcp filtered unknown
Nmap done: 1 IP address (1 host up) scanned in 2.03 seconds
Какую деталь головоломки я пропускаю? Я пробовал разные сервисы с тем же результатом. Я не могу подключиться к портам, которые открывают сервисы. Я в одной подсети с кластером и пулом IP-адресов LB (который находится за пределами диапазона DHCP).
Для полноты картины, kubectl get all -A:
NAMESPACE NAME READY STATUS RESTARTS AGE
default pod/adminer-86d856f947-c94x8 1/1 Running 0 6m52s
kube-system pod/coredns-64b67fc8fd-j4nm8 1/1 Running 0 42h
kube-system pod/coredns-64b67fc8fd-rllsg 1/1 Running 0 42h
kube-system pod/coredns-64b67fc8fd-rp74n 0/1 Completed 0 42h
kube-system pod/coredns-64b67fc8fd-xfg48 0/1 Completed 0 42h
kube-system pod/kube-apiserver-talos-pwj-68i 1/1 Running 0 42h
kube-system pod/kube-controller-manager-talos-pwj-68i 1/1 Running 1 (42h ago) 42h
kube-system pod/kube-flannel-bq8pj 1/1 Running 0 42h
kube-system pod/kube-flannel-zvw66 1/1 Running 1 (42h ago) 42h
kube-system pod/kube-proxy-5znrp 1/1 Running 1 (42h ago) 42h
kube-system pod/kube-proxy-bsqr6 1/1 Running 0 42h
kube-system pod/kube-scheduler-talos-pwj-68i 1/1 Running 1 (42h ago) 42h
metallb pod/metallb-controller-66fddf5ff-9jd79 1/1 Running 0 7m23s
NAMESPACE NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
default service/adminer LoadBalancer 10.100.233.191 192.168.0.16 18080/TCP 6m52s
default service/kubernetes ClusterIP 10.96.0.1 <none> 443/TCP 42h
kube-system service/kube-dns ClusterIP 10.96.0.10 <none> 53/UDP,53/TCP,9153/TCP 42h
metallb service/metallb-webhook-service ClusterIP 10.98.180.212 <none> 443/TCP 7m23s
NAMESPACE NAME DESIRED CURRENT READY UP-TO-DATE AVAILABLE NODE SELECTOR AGE
kube-system daemonset.apps/kube-flannel 2 2 2 2 2 <none> 42h
kube-system daemonset.apps/kube-proxy 2 2 2 2 2 <none> 42h
metallb daemonset.apps/metallb-speaker 2 0 0 0 0 kubernetes.io/os=linux 7m23s
NAMESPACE NAME READY UP-TO-DATE AVAILABLE AGE
default deployment.apps/adminer 1/1 1 1 6m52s
kube-system deployment.apps/coredns 2/2 2 2 42h
metallb deployment.apps/metallb-controller 1/1 1 1 7m23s
NAMESPACE NAME DESIRED CURRENT READY AGE
default replicaset.apps/adminer-86d856f947 1 1 1 6m52s
kube-system replicaset.apps/coredns-64b67fc8fd 2 2 2 42h
metallb replicaset.apps/metallb-controller-66fddf5ff 1 1 1 7m23s
У меня была такая же проблема при установке Kubernetes v1.31.2 — DaemonSet MetalLB speaker не мог масштабироваться. Полезно описать DaemonSet, чтобы диагностировать проблему. В моем случае проблема заключалась в том, что Контроллер допуска подов безопасности применял политики, которые мешали DaemonSet создавать поды с необходимыми привилегиями. Установка следующей метки на пространство имен MetalLB решила проблему, разрешив использование привилегированных подов:
kubectl label namespace metallb pod-security.kubernetes.io/enforce=privileged --overwrite
Ответ или решение
Вопрос интеграции MetalLB в кластер Kubernetes на базе Talos и проверки доступности сервисов — это довольно распространённая проблема, и разрешение её требует внимания к нескольким ключевым аспектам. Ниже приведены рекомендации и шаги для устранения неисправностей, которые могут помочь в решении проблемы с доступом к сервисам, организованным через MetalLB.
Шаг 1: Проверка конфигурации MetalLB
На основании предоставленной конфигурации, необходимо убедиться, что MetalLB правильно настроен для работы с вашим сетевым окружением. Конфигурация, которую вы используете, выглядит корректно, однако стоит пересмотреть настройки на наличие возможных проблем:
ipAddressPools:
- name: apps
autoAssign: true
avoidBuggyIPs: false
addresses:
- 192.168.0.16-192.168.0.30
L2Advertisements:
- name: l2adv
addressPools:
- appsУбедитесь, что нет конфликтов IP-адресов с другими устройствами в вашей сети и что адреса в вашем пуле не попадают в диапазон DHCP.
Шаг 2: Проверка ваших сервисов
Вы указали, что сервис Adminer получает IP-адрес 192.168.0.16, а также видите, что он прослушивает порт 18080. Однако, по результатам сканирования Nmap, порт 18080 показывает состояние «filtered», что указывает на то, что доступ к этому порту ограничен. Это может быть связано с несколькими факторами:
- Настройки брандмауэра. Убедитесь, что на всех узлах кластера и на уровне сети нет правил брандмауэра, которые блокируют доступ к этому порту.
- Правильная конфигурация MetalLB. Проверьте, работают ли компоненты MetalLB: контроллер и спикеры. У вас в выводе
kubectl get all -Aвидно, что спикеры не созданы (2 / 0), что может указывать на проблему с их развертыванием.
Шаг 3: Диагностика DaemonSet MetalLB
Важно проверить статус DaemonSet для MetalLB. Используйте команду:
kubectl describe daemonset metallb-speaker -n metallbЕсли вы обнаружите ошибки, связанные с доступом или правами, вам необходимо будет изменить настройки безопасности. Например, вы можете установить метку на пространство имён MetalLB, чтобы разрешить использование привилегированных подов:
kubectl label namespace metallb pod-security.kubernetes.io/enforce=privileged --overwriteШаг 4: Проверка сетевых плагинов
Убедитесь, что сетевой плагин (например, Flannel) настроен корректно. Иногда проблемы с сетью могут возникать из-за неправильной конфигурации или конфликтов между компонентами кластера.
Шаг 5: Тестирование и дальнейшие шаги
После внесения изменений выполните следующие действия:
-
Перезапустите DaemonSet MetalLB:
kubectl delete daemonset metallb-speaker -n metallb -
Проверьте, создались ли поды для данного DaemonSet:
kubectl get pods -n metallb -
Снова протестируйте доступ к сервису Adminer с помощью
nmapилиcurl.
Если проблема не решится, рекомендую предоставить логи из подов MetalLB для более детальной диагностики:
kubectl logs <pod-name> -n metallbЗаключение
Проблема с доступом к сервисам в вашем кластере на Talos, использующем MetalLB, с высокой вероятностью связана с конфигурацией сетевой среды, правами подов или недоступностью сетевого плагина. Процесс устранения неполадок включает проверку всех компонентов и сеть. Надеюсь, приведенные шаги помогут вам в решении вашей проблемы и успешной настройке окружения Kubernetes.