我已经使用kubeadm设置了一个kubernetes集群。
环境
状态
工作程序节点能够加入集群并运行
kubectl get nodes
节点的状态已准备就绪。
Kubernetes可以在该节点上部署和运行Pod。
问题
我遇到的问题是我无法访问该节点上部署的Pod。例如，如果我运行
kubectl logs <pod-name>
其中pod-name是部署在工作节点上的pod的名称，出现此错误：
Error from server: Get https://192.168.0.17:10250/containerLogs/default/stage-bbcf4f47f-gtvrd/stage: dial tcp 192.168.0.17:10250: i/o timeout
因为它正在尝试使用本地IP 192.168.0.17，该IP无法从外部访问。
我已经看到该节点具有以下注释：
flannel.alpha.coreos.com/public-ip: 192.168.0.17
因此，我尝试通过以下方式修改注释，设置外部IP：
flannel.alpha.coreos.com/public-ip: <my_externeal_ip>
我看到该节点已正确注释，但它仍在使用192.168.0.17。
在工作节点或群集配置中还有其他设置吗？
答案 0 :(得分：1)
侧边栏中有大量相关问题，我大概90％的人都肯定这是一个常见问题解答，但不要麻烦对重复项进行分类
在工作节点或群集配置中还有其他设置吗？
否，这种情况不是您的工作节点的配置错误，也不是您的集群配置错误。这只是kubernetes处理以Pod为中心的流量的方式的副作用。这确实意味着，如果您选择继续进行该设置，则将无法使用kubectl exec或kubectl logs（我也认为port-forward），因为这些命令不会发送通过API服务器访问流量，而是直接与托管您要与之交互的Pod的节点上的kubelet端口进行联系。这主要是为了减轻流量通过API服务器的负担，但是如果同时发生大量的exec / log / port-foward / etc命令，这也是一个扩展问题，因为TCP端口不是无限的。
我认为从理论上来说是可以让您的工作站加入覆盖网络的，因为按照定义，它与外部网络无关，但是我没有大量尝试获取覆盖网络的经验。可以很好地与NAT配合使用的覆盖层，所以这是“理论上”的部分。
我个人已经使Wireguard可以跨NAT工作，这意味着您可以将VPN接入Node的网络，但这需要进行一些调整，并且可能会带来更多麻烦。