创建部署问题时，请参考下面模板，你提供的信息越多，越容易及时获得解答。如果未按模板创建问题，管理员有权关闭问题。
确保帖子格式清晰易读，用 markdown code block 语法格式化代码块。
你只花一分钟创建的问题，不能指望别人花上半个小时给你解答。
操作系统信息
AWS EC2 ap-southeast-1(新加坡)，Ubuntu22.04-x86/64，4C/16G
Kubernetes版本信息
将 kubectl version 命令执行结果贴在下方
Client Version: version.Info{Major:“1”, Minor:“25”, GitVersion:“v1.25.16”, GitCommit:“c5f43560a4f98f2af3743a59299fb79f07924373”, GitTreeState:“clean”, BuildDate:"2023-11-15T22
:39:12Z", GoVersion:“go1.20.10”, Compiler:“gc”, Platform:“linux/amd64”}
Kustomize Version: v4.5.7
Server Version: version.Info{Major:“1”, Minor:“25”, GitVersion:“v1.25.16”, GitCommit:“c5f43560a4f98f2af3743a59299fb79f07924373”, GitTreeState:“clean”, BuildDate:"2023-11-15T22
:28:05Z", GoVersion:“go1.20.10”, Compiler:“gc”, Platform:“linux/amd64”}
容器运行时–docker
Client:
Version: 24.0.9
API version: 1.43
Go version: go1.20.13
Engine:
Version: 24.0.9
API version: 1.43 (minimum version 1.12)
Go version: go1.20.13
KubeSphere版本信息
例如：v2.1.1/v3.0.0。离线安装还是在线安装。在已有K8s上安装还是使用kk安装。
v3.4.1 使用kk安装。kk版本:v3.1.6-linux-amd64
问题是什么
创建或者扩容的时候报错： new sftp client failed: packet too long
(一开始是使用扩容的时候发现的，后来试试新建集群 同样是sftp连接不到)
扩容-加节点：
error: Pipeline[AddNodesPipeline] execute failed: Module[GreetingsModule] exec failed:
failed: [node1] failed to connect to 13.212.251.29: new sftp client failed: packet too long: packet too long
failed: [master] failed to connect to 47.129.187.24: new sftp client failed: packet too long: packet too long
创建集群:
error: Pipeline[CreateClusterPipeline] execute failed: Module[GreetingsModule] exec failed:
failed: [node1] failed to connect to 13.xxx.xxx.29: new sftp client failed: packet too long: packet too long
failed: [master] failed to connect to 47.xxx.xxx.24: new sftp client failed: packet too long: packet too long
条件：这两台机器本身是在同一vpc下 且可以互联，ping通，登陆。（局域网和公网 互相ssh登陆 都能成功）
测试过程：
使用 ./kk create config –with-kubernetes v1.25.16 –with-kubesphere v3.4.1 生成config-sample.yaml
将config-sample.yaml 里的address分别使用过局域网IP和公网IP 测试。结果一样。
下边是addnode-config.yaml的yaml内容
apiVersion: kubekey.kubesphere.io/v1alpha2
kind: Cluster
metadata:
name: sample
spec:
hosts:
##You should complete the ssh information of the hosts
{name: ip-172-31-43-254, address: 172.31.43.254, internalAddress: 172.31.43.254}
{name: ip-172-31-40-178, address: 172.31.40.178, internalAddress: 172.31.40.178}
roleGroups:
etcd:
master:
worker:
controlPlaneEndpoint:
##Internal loadbalancer for apiservers
#internalLoadbalancer: haproxy
##If the external loadbalancer was used, 'address' should be set to loadbalancer's ip.domain: lb.kubesphere.local address: "" port: 6443 kubernetes: version: v1.25.16 clusterName: cluster.local proxyMode: ipvs masqueradeAll: false maxPods: 110 nodeCidrMaskSize: 24 network: plugin: calico kubePodsCIDR: 10.233.64.0/18 kubeServiceCIDR: 10.233.0.0/18 registry: privateRegistry: ""
查看kk源代码初步判断是以下代码行造成的：
即:
// 32768 bits is 4096 bytes
// 32768 bits is 32.00 KB
但是这个是sftp的官方包；按说是有道理和普适性的。（严格讲不算kk的bug，可能算适配性上的问题。）为什么aws 的ec2两台机器的packet会过长呢？
问了AI 讲 是服务器提供商 整底层网络设备的 MTU 设置的问题。但是显然 aws容不得质疑。
那么这个问题是什么原因造成的呢？有没有哪位大佬略施指教， 抱拳！
最后看看AI的回答：
即使你重新使用KubeKey部署master节点，并且在不添加任何工作负载的情况下再次尝试加入新的工作节点，仍然有可能遇到packet too long错误。 原因在于这个错误并非直接由工作负载或数据量引起，而是由**网络路径上的MTU (Maximum Transmission Unit)**限制导致的。
packet too long错误表示KubeKey尝试发送的数据包大小超过了网络路径上某个设备所能处理的最大数据包大小。 即使你重新部署master节点，并且没有工作负载，KubeKey仍然需要传输必要的配置文件、证书和二进制文件来配置新的工作节点。 如果网络路径上的MTU仍然小于这些数据包的大小，则仍然会遇到此错误。
因此，重新部署master节点并不会解决根本问题。 解决packet too long错误的关键在于识别并解决网络路径上的MTU瓶颈。 你需要：
在 AWS EC2 环境中，你无法直接调整底层网络设备的 MTU 设置。AWS 管理底层网络基础设施，你没有权限直接修改这些设置。 因此，“联系网络管理员或云提供商” 在 AWS EC2 的语境下，意味着你必须通过 AWS 支持渠道来寻求帮助。
既然直接联系网络管理员不现实，以下是一些替代方案，来尝试解决 AWS EC2 上的 packet too long 问题，其优先级从高到低排列：
1. AWS 支持工单: 这是最可靠的解决方法。 创建一个支持工单，详细描述你的问题，包括错误信息 (packet too long)、你的 EC2 实例类型、你的网络配置 (VPC, 子网等)，以及你已经尝试过的步骤。 AWS 支持团队拥有必要的工具和权限来诊断并解决底层网络问题，包括 MTU 相关的设置。 这可能是最耗时的方法，但也是最有可能成功的方法。
2. 检查 VPC 和子网设置: 虽然你无法直接修改 MTU，但你可以检查你的 VPC 和子网的配置，确保它们没有设置任何会限制 MTU 的设置。 这不太可能解决问题，因为 AWS 通常使用默认的 MTU 设置，但值得一试。
3. 使用不同的传输方法 (如果可能): 如果 KubeKey 支持不同的传输方法 (例如，除了 SFTP 之外，还支持其他协议)，尝试使用不同的方法来传输数据。 这取决于 KubeKey 的具体实现，可能需要修改 KubeKey 的配置或源代码。 这通常不是一个推荐的方案，因为这需要深入了解 KubeKey 的内部工作原理，并且可能引入新的问题。
4. 使用更小的数据包 (不推荐): 这需要修改 KubeKey 的源代码，将大型文件分割成更小的数据包进行传输。 这非常复杂，不建议除非你对 KubeKey 的代码有深入的了解，并且有能力处理可能由此产生的副作用。
5. 使用不同的网络配置 (如果可能): 如果可能，尝试使用不同的 VPC 或子网。 这需要重新创建你的 EC2 实例和网络配置，因此成本较高，并且不推荐除非其他所有方法都失败了。
总结:
在 AWS EC2 中，直接修改 MTU 设置是不可能的。 创建 AWS 支持工单是解决 packet too long 错误的最有效方法。 其他方法都是变通方案，风险较高，并且可能无法解决根本问题。 优先尝试 AWS 支持工单，并提供尽可能多的细节信息。
问 2：难道之前就没有人在ec2上使用kubekey增加节点吗：
答2：
当然有人在 AWS EC2 上使用 KubeKey 添加节点。 然而，packet too long 错误并非 KubeKey 在 EC2 上独有的问题，而是一个更通用的网络问题。 它表明在数据传输过程中，数据包的大小超过了网络路径上某个设备的 MTU 限制。
即使有人成功地在 EC2 上使用 KubeKey 添加节点，这并不意味着他们没有遇到过网络问题。 他们可能：
没有遇到 packet too long 错误: 他们的网络配置可能没有 MTU 限制问题。
解决了 packet too long 错误: 他们可能通过调整网络配置（虽然在 EC2 上直接调整底层网络设备的 MTU 不现实，但可能通过其他方法解决了问题，例如，使用不同的传输协议或调整 KubeKey 的配置）。
没有报告 packet too long 错误: 他们可能遇到了这个问题，但没有公开报告或记录。
重要的是要理解，packet too long 错误是一个网络问题，而不是 KubeKey 本身的问题。 它可能在任何网络环境中发生，包括 EC2。 成功使用 KubeKey 在 EC2 上添加节点取决于你的网络配置是否符合要求，而不是 KubeKey 是否能够在 EC2 上运行。 如果你的网络配置存在 MTU 限制问题，那么无论你使用什么工具，都可能遇到 packet too long 错误。
因此，虽然其他人可能成功地使用了 KubeKey 在 EC2 上添加节点，但这并不意味着你一定能够避免 packet too long 错误。 解决这个问题的关键在于识别和解决你的网络环境中的 MTU 限制问题，这通常需要与 AWS 支持团队合作。
