【问题标题】:Kubernetes service unreachable from master node on EC2无法从 EC2 上的主节点访问 Kubernetes 服务
【发布时间】:2018-09-12 21:41:25
【问题描述】:

我使用 kubeadm 在 AWS 上创建了一个 k8s 集群,按照here 提供的指南,有 1 个 master 和 1 个 worker。

然后,我启动了 1 个 ElasticSearch 容器:

kubectl run elastic --image=elasticsearch:2 --replicas=1

并且在worker上成功部署。然后,我尝试将其公开为集群上的服务:

kubectl expose deploy/elastic --port 9200

并且曝光成功:

NAMESPACE     NAME                                                     READY     STATUS    RESTARTS   AGE
default       elastic-664569cb68-flrrz                                 1/1       Running   0          16m
kube-system   etcd-ip-172-31-140-179.ec2.internal                      1/1       Running   0          16m
kube-system   kube-apiserver-ip-172-31-140-179.ec2.internal            1/1       Running   0          16m
kube-system   kube-controller-manager-ip-172-31-140-179.ec2.internal   1/1       Running   0          16m
kube-system   kube-dns-86f4d74b45-mc24s                                3/3       Running   0          17m
kube-system   kube-flannel-ds-fjkkc                                    1/1       Running   0          16m
kube-system   kube-flannel-ds-zw4pq                                    1/1       Running   0          17m
kube-system   kube-proxy-4c8lh                                         1/1       Running   0          17m
kube-system   kube-proxy-zkfwn                                         1/1       Running   0          16m
kube-system   kube-scheduler-ip-172-31-140-179.ec2.internal            1/1       Running   0          16m

NAMESPACE     NAME         TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)         AGE
default       elastic      ClusterIP   10.96.141.188   <none>        9200/TCP        16m
default       kubernetes   ClusterIP   10.96.0.1       <none>        443/TCP         17m
kube-system   kube-dns     ClusterIP   10.96.0.10      <none>        53/UDP,53/TCP   17m

NAMESPACE     NAME              DESIRED   CURRENT   READY     UP-TO-DATE   AVAILABLE   NODE SELECTOR                   AGE
kube-system   kube-flannel-ds   2         2         2         2            2           beta.kubernetes.io/arch=amd64   17m
kube-system   kube-proxy        2         2         2         2            2           <none>                          17m

NAMESPACE     NAME       DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
default       elastic    1         1         1            1           16m
kube-system   kube-dns   1         1         1            1           17m

NAMESPACE     NAME                  DESIRED   CURRENT   READY     AGE
default       elastic-664569cb68    1         1         1         16m
kube-system   kube-dns-86f4d74b45   1         1         1         17m

但是,当我尝试执行 curl 到 http://10.96.141.188:9200(从主节点)时,我遇到了超时,并且一切都表明生成的集群 IP 无法从主节点访问。它仅适用于工作节点。

我尝试了所有我能找到的东西:

给iptables添加一堆规则

iptables -P FORWARD ACCEPT
iptables -I FORWARD 1 -i cni0 -j ACCEPT -m comment --comment "flannel subnet"
iptables -I FORWARD 1 -o cni0 -j ACCEPT -m comment --comment "flannel subnet"
iptables -t nat -A POSTROUTING -s 10.244.0.0/16 ! -d 10.244.0.0/16 -j MASQUERADE
  • 禁用防火墙
  • 启用 ec2 安全策略上的所有端口(来自任何地方)
  • 使用不同的 docker 版本(1.13.1、17.03、17.06、17.12)
  • 不同的 k8s 版本(1.9.0 ~1.9.6)
  • 不同的 CNI(法兰绒和编织)
  • 在 kubeadm init 命令中添加一些参数(--node-name with FQDN and --apiserver-advertise-address with public master IP)

但是这些都不起作用。这似乎是 AWS 上的一个特定问题,因为教程指南在 Linux Academy Cloud Server 上运行良好。

还有什么我可以尝试的吗?

观察: 目前,我在 Centos7 上使用 docker 1.13 和 k8s 1.9.6(带有 flannel 0.9.1)。

【问题讨论】:

    标签: amazon-ec2 kubernetes kubeadm


    【解决方案1】:

    我终于找到了问题所在。根据this page,Flannel 需要在 Master 和 Worker 节点上打开 UDP 8285 和 8472 端口。有趣的是,官方 kubeadm 文档中没有提到这一点。

    【讨论】:

      【解决方案2】:

      kubectl run elastic --image=elasticsearch:2 --replicas=1

      据我所知,您没有告知 kubernetes elasticsearch:2 图像在任何端口上侦听,它不会自行推断。如果您只是在docker 下运行该映像而没有类似地指定--publish--publish-all 选项,您会遇到同样的问题。

      因此,当ClusterIP 尝试将流量从端口 9200 转发到与其选择器匹配的Pods 时,这些数据包会落入/dev/null,因为容器没有监听它们。

      给iptables添加一堆规则

      绝对不要那样做;如果您观察到,已经有大量的 iptables 规则由kube-proxy 管理:事实上,它的主要工作是拥有运行它的节点上的 iptables 规则。你的规则只会混淆 kube-proxy 以及任何跟随你的人,试图找出这些随机规则的来源。如果您还没有将它们永久化,那么要么撤消它们,要么重新启动机器以刷新这些表。保留您的临时规则不会 100% 使您的故障排除过程变得更容易。

      【讨论】:

      • 在第二步(服务创建)分配端口。它正在工作,我可以从工作节点成功 curl 到 10.96.141.188:9200。但是您对 iptables 的看法是绝对正确的!
      • 端口是在第二步分配的(服务创建) 是的,我知道 Service 端口已分配,但 Service 端口是ClusterIP 的合约,容器端口是Pod 与其容器之间的合约。它们可以而且在我的集群中绝对会有所不同,因为它们代表了对集群其他成员的不同程度的长期承诺。
      猜你喜欢
      • 2020-09-02
      • 2019-05-07
      • 1970-01-01
      • 2018-02-27
      • 1970-01-01
      • 1970-01-01
      • 2016-11-17
      • 2020-07-15
      • 2022-01-24
      相关资源
      最近更新 更多