在 AWS ec2 中从 master 创建的 3 节点集群上的 Pod 无法访问（超时）答案

【问题标题】：Pods not accessible (timeout) on 3 Node cluster created in AWS ec2 from master在 AWS ec2 中从 master 创建的 3 节点集群上的 Pod 无法访问（超时）
【发布时间】：2021-05-19 16:23:03
【问题描述】：

我在 AWS ec2 (Centos 8 ami) 中有 3 个节点集群。

当我尝试从主节点访问调度在工作节点上的 pod 时：

kubectl exec -it kube-flannel-ds-amd64-lfzpd -n kube-system /bin/bash
Error from server: error dialing backend: dial tcp 10.41.12.53:10250: i/o timeout

kubectl get pods --all-namespaces -o wide
NAMESPACE     NAME                             READY   STATUS    RESTARTS   AGE     IP             NODE             NOMINATED NODE   READINESS GATES
kube-system   coredns-54ff9cd656-8mpbx         1/1     Running   2          7d21h   10.244.0.7     master           <none>           <none>
kube-system   coredns-54ff9cd656-xcxvs         1/1     Running   2          7d21h   10.244.0.6     master           <none>           <none>
kube-system   etcd-master                      1/1     Running   2          7d21h   10.41.14.198   master           <none>           <none>
kube-system   kube-apiserver-master            1/1     Running   2          7d21h   10.41.14.198   master           <none>           <none>
kube-system   kube-controller-manager-master   1/1     Running   2          7d21h   10.41.14.198   master           <none>           <none>
kube-system   kube-flannel-ds-amd64-8zgpw      1/1     Running   2          7d21h   10.41.14.198   master           <none>           <none>
kube-system   kube-flannel-ds-amd64-lfzpd      1/1     Running   2          7d21h   10.41.12.53    worker1          <none>           <none>
kube-system   kube-flannel-ds-amd64-nhw5j      1/1     Running   2          7d21h   10.41.15.9     worker3   <none>           <none>
kube-system   kube-flannel-ds-amd64-s6nms      1/1     Running   2          7d21h   10.41.15.188   worker2          <none>           <none>
kube-system   kube-proxy-47s8k                 1/1     Running   2          7d21h   10.41.15.9     worker3   <none>           <none>
kube-system   kube-proxy-6lbvq                 1/1     Running   2          7d21h   10.41.15.188   worker2          <none>           <none>
kube-system   kube-proxy-vhmfp                 1/1     Running   2          7d21h   10.41.14.198   master           <none>           <none>
kube-system   kube-proxy-xwsnk                 1/1     Running   2          7d21h   10.41.12.53    worker1          <none>           <none>
kube-system   kube-scheduler-master            1/1     Running   2          7d21h   10.41.14.198   master           <none>           <none>

kubectl get nodes
NAME             STATUS   ROLES    AGE     VERSION
master           Ready    master   7d21h   v1.13.10
worker1          Ready    <none>   7d21h   v1.13.10
worker2          Ready    <none>   7d21h   v1.13.10
worker3          Ready    <none>   7d21h   v1.13.10

我在所有节点中尝试了以下步骤，但到目前为止没有运气：

iptables -w -P FORWARD ACCEPT 在所有节点上
开启伪装
开启端口 10250/tcp
开启8472/udp端口
启动 kubelet

任何指针都会有所帮助。

【问题讨论】：

如果您使用的是centOS（我假设您这样做，因为它在标签中）可能是nftables后端centOS使用的问题。你用的是哪个版本的centOS？
CentOS_8(ami) @PawełGrondal
你的问题很可能是因为centOS使用了NFT后端。您可能需要将 CNI 更改为支持它的 CNI，例如 Calico
@PawełGrondal 你的意思是法兰绒在这种情况下不起作用？或者有什么方法可以禁用 nft 并回退到 iptables ...？任何解决方法都可以。
是的，我相信 flannel 不会工作，不幸的是你不能在 centOS 8 上回退到 iptables。你应该切换到 Calico 并使用 FELIX_IPTABLESBACKEND: NFT 环境变量配置它。

标签： kubernetes amazon-ec2 centos

【解决方案1】：

Flannel 不支持 NFT，而且由于您使用的是 CentOS 8，因此无法回退到 iptables。
在这种情况下，您最好的选择是切换到Calico。
您必须使用以下命令更新 Calico DaemonSet：

....
    Environment:
      FELIX_IPTABLESBACKEND: NFT
....

或使用版本 3.12 或更高版本，因为它添加了
自动检测 iptables 后端

以前版本的 Calico 要求您指定主机的 iptables 后端（NFT 或 Legacy 之一）。在此版本中，Calico 现在可以通过将 Felix 配置参数 IptablesBackend 设置为 Auto 来自动检测主机上的 iptables 变体。这在您不知道 iptables 后端可能是什么的情况下（例如在混合部署中）很有用。有关详细信息，请参阅 iptables 数据平面配置文档

或者切换到 Ubuntu 20.04。 Ubuntu 还没有使用 nftables。

【讨论】：

我也可以使用redhat 7.9 吗？我认为 nft 是在 Redhat 8 中引入的？我会尽快让你知道。
嗨@Chris_vr，您找到解决问题的方法了吗？
它不工作...我尝试使用 CentOS_7...我遇到了同样的问题。我正在使用法兰绒。我不能使用印花布，因为外包装使用法兰绒。 @Pawel

【解决方案2】：

问题是因为 SG 中的入站端口。我在 SG 中添加了这些端口，我能够通过该问题。

  2222
  24007
  24008
49152-49251

在虚拟机和独立机器上运行时，我的原始安装程序脚本不需要执行上述步骤。由于 SG 特定于 EC2，因此应允许入站端口。这里要注意的是我所有的节点（主节点和工作节点）都在同一个 SG 上。即使这样，端口也必须在入站规则中打开，这就是 SG 的工作方式。

【讨论】：