Невозможно получить внешний IP-адрес в кластере голого металла kubernetes - PullRequest
Новая
       90

Невозможно получить внешний IP-адрес в кластере голого металла kubernetes

0 голосов
/ 12 июля 2019

Я пытаюсь настроить голый металлический кластер Kubernetes.У меня настроен базовый кластер, нет проблем, но я не могу заставить правильно работать MetalLB для предоставления внешнего IP-адреса службе.

Моя конечная цель - развернуть приложение с помощью 2+ реплики и один IP / порт, на который я могу ссылаться, чтобы поразить любой из запущенных экземпляров.

Пока что я сделал (чтобы проверить это): 

kubectl apply -f https://raw.githubusercontent.com/google/metallb/v0.7.3/manifests/metallb.yaml
kubectl apply -f metallb-layer-2.yml
kubectl run nginx --image=nginx --port=80
kubectl expose deployment nginx --type=LoadBalancer --name=nginx-service

metallb-layer-2.yml: 

apiVersion: v1
kind: ConfigMap
metadata:
  namespace: metallb-system
  name: config
data:
  config: |
    address-pools:
    - name: k8s-master-ip-space
      protocol: layer2
      addresses:
      - 192.168.0.240-192.168.0.250

, а затем, когда я запускаю kubectl get svc, я получаю: 

NAME            TYPE           CLUSTER-IP       EXTERNAL-IP   PORT(S)          AGE
nginx-service   LoadBalancer   10.101.122.140   <pending>     80:30930/TCP     9m29s

Независимо от того, что я делаю, яне могу получить услугу, чтобы иметь внешний IP.У кого-нибудь есть идея?

РЕДАКТИРОВАТЬ: Найдя еще один пост об использовании NodePort, я сделал следующее: 

iptables -A FORWARD -j ACCEPT

найдено здесь .

Теперь, к сожалению, когда я пытаюсь свернуть конечную точку nginx, я получаю: 

> kubectl get svc
NAME            TYPE           CLUSTER-IP       EXTERNAL-IP       PORT(S)          AGE
nginx-service   LoadBalancer   10.101.122.140   192.168.0.240     80:30930/TCP     13h
> curl 192.168.0.240:30930
curl: (7) Failed to connect to 192.168.0.240 port 30930: No route to host
> curl 192.168.0.240:80
curl: (7) Failed to connect to 192.168.0.240 port 80: No route to host

Я не уверен, что именно это сейчас означает.

РЕДАКТИРОВАТЬ 2: Когда я делаю дамп TCP на работнике, где работает модуль, я получаю: 

15:51:44.705699 IP 192.168.0.223.54602 > 192.168.0.240.http: Flags [S], seq 1839813500, win 29200, options [mss 1460,sackOK,TS val 375711117 ecr 0,nop,wscale 7], length 0
15:51:44.709940 ARP, Request who-has 192.168.0.240 tell 192.168.0.169, length 28
15:51:45.760613 ARP, Request who-has 192.168.0.240 tell 192.168.0.169, length 28
15:51:45.775511 IP 192.168.0.223.54602 > 192.168.0.240.http: Flags [S], seq 1839813500, win 29200, options [mss 1460,sackOK,TS val 375712189 ecr 0,nop,wscale 7], length 0
15:51:46.800622 ARP, Request who-has 192.168.0.240 tell 192.168.0.169, length 28
15:51:47.843262 IP 192.168.0.223.54602 > 192.168.0.240.http: Flags [S], seq 1839813500, win 29200, options [mss 1460,sackOK,TS val 375714257 ecr 0,nop,wscale 7], length 0
15:51:47.843482 ARP, Request who-has 192.168.0.240 tell 192.168.0.169, length 28
15:51:48.880572 ARP, Request who-has 192.168.0.240 tell 192.168.0.169, length 28
15:51:49.774953 ARP, Request who-has 192.168.0.240 tell 192.168.0.223, length 46
15:51:49.920602 ARP, Request who-has 192.168.0.240 tell 192.168.0.169, length 28

1 Ответ

1 голос
/ 15 июля 2019

Пройдя с сопровождающим MetalLB, он смог выяснить, в чем проблема с новым брандмауэром nftables Debian Buster.Чтобы отключить, 

# update-alternatives --set iptables /usr/sbin/iptables-legacy
# update-alternatives --set ip6tables /usr/sbin/ip6tables-legacy
# update-alternatives --set arptables /usr/sbin/arptables-legacy
# update-alternatives --set ebtables /usr/sbin/ebtables-legacy

и перезапустите узлы в кластере!

...