无法在裸机 kubernetes 集群上获取外部 IP
Can't get external IP on bare metal kubernetes cluster
我正在尝试设置一个裸机 Kubernetes 集群。我已经设置了基本集群,没问题,但我似乎无法让 MetalLB 正常工作以向服务公开外部 IP。
我的最终目标是能够部署具有 2 个以上副本的应用程序,并拥有一个我可以引用的 IP/Port,以便命中任何 运行ning 实例。
到目前为止,我所做的(为了对此进行测试)是:
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
金属层-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 的 post 之后,我做了以下操作:
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:
当我在 pod 为 运行ning 的工作线程上执行 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
在与 MetalLB 维护者沟通后,他发现问题出在 Debian Buster 的新 nftables 防火墙上。要禁用,
# 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
并重启集群中的节点!
我正在尝试设置一个裸机 Kubernetes 集群。我已经设置了基本集群,没问题,但我似乎无法让 MetalLB 正常工作以向服务公开外部 IP。
我的最终目标是能够部署具有 2 个以上副本的应用程序,并拥有一个我可以引用的 IP/Port,以便命中任何 运行ning 实例。
到目前为止,我所做的(为了对此进行测试)是:
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
金属层-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 的 post 之后,我做了以下操作:
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: 当我在 pod 为 运行ning 的工作线程上执行 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
在与 MetalLB 维护者沟通后,他发现问题出在 Debian Buster 的新 nftables 防火墙上。要禁用,
# 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
并重启集群中的节点!