docker - NAT服务暴露背后的Kubernetes节点

Question

我正在尝试让 Kubernetes 集群与一些在 NAT 后面工作但没有公共(public) IP 地址的节点一起工作。 (为什么我需要它是另一回事)

有3个节点:

Kubernetes集群主控(公网IP)

Node1(公网IP)

Node2(在我的笔记本电脑上作为虚拟机在 NAT 后面工作，没有公共(public) IP 地址)

所有 3 个节点都运行带有 Kubernetes v1.10.2(3)、Docker 17.12 的 Ubuntu 18.04

Kubernetes 集群是这样创建的:
kubeadm init --pod-network-cidr=10.244.0.0/16
使用法兰绒网络:
kubectl apply -f https://raw.githubusercontent.com/coreos/flannel/master/Documentation/kube-flannel.yml
Node1 和 Node2 加入集群:
NAME STATUS ROLES AGE VERSION
master-node Ready master 3h v1.10.2
node1 Ready <none> 2h v1.10.3
node2 Ready <none> 2h v1.10.2
Nginx 部署 + 服务 (type=NodePort) 为 Node1 创建和调度(具有公共(public) IP):

https://pastebin.com/6CrugunB
kubectl get svc
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
kubernetes ClusterIP 10.96.0.1 <none> 443/TCP 3h
my-nginx NodePort 10.110.202.32 <none> 80:31742/TCP 16m

此部署可通过 http://MASTER_NODE_PUBLIC_IP:31742 访问和 http://NODE1_PUBLIC_IP:31742正如预期的那样。

另一个为 Node2 创建和调度的 Nginx 部署 + 服务(类型=NodePort)(没有公共(public) IP):

https://pastebin.com/AFK42UNW
kubectl get svc
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
kubernetes ClusterIP 10.96.0.1 <none> 443/TCP 3h
my-nginx NodePort 10.110.202.32 <none> 80:31742/TCP 22m
nginx-behind-nat NodePort 10.105.242.178 <none> 80:32350/TCP 22m
但是无法通过 http://MASTER_NODE_PUBLIC_IP:32350 访问此服务也不是 http://NODE1_PUBLIC_IP:32350 .

只能通过 http://MY_VM_IP:32350 访问从我的笔记本电脑。

此外:我无法进入 nginx-behind-nat pod 通过 kubectl exec任何一个。

有没有办法实现它？

Answer 1

如 Kubernetes documentation 中所述:

Kubernetes imposes the following fundamental requirements on any networking implementation (barring any intentional network segmentation policies):

• all containers can communicate with all other containers without NAT
• all nodes can communicate with all containers (and vice-versa) without NAT
• the IP that a container sees itself as is the same IP that others see it as

What this means in practice is that you can not just take two computers running Docker and expect Kubernetes to work. You must ensure that the fundamental requirements are met.

默认情况下，从 api-server 到节点、端口或服务的连接只是纯 HTTP，没有身份验证和加密。
它们可以通过 HTTPS 工作，但默认情况下，apiserver 不会验证 HTTPS 端点证书，因此它不会提供任何完整性保证，并且可能会受到中间人攻击。

有关保护集群内部连接的详细信息，请查看 document