AutoK3s 是 Rancher 生态中用于管理 K3s 集群的轻量级工具，它把在 AWS、阿里云、腾讯云等平台上拉起 K3s 节点的流程抽象成统一的 create、join、delete 命令。在 AWS 上创建集群时，AutoK3s 会通过 AWS SDK 调用 EC2、VPC、IAM 相关接口，完成安全组创建、实例开机、K3s 二进制下载和节点注册。但 AWS 的权限体系和网络模型相对复杂，如果只按照默认参数操作，容易因为 IAM 策略不完整、安全组端口未放行、SSH 密钥不匹配等问题导致集群创建失败。下面以创建一个单节点 K3s server 为起点，梳理从准备到验证的完整路径。
创建前准备：AWS 凭证与最小化 IAM 权限
在运行 AutoK3s 之前，首先要确认 AWS 账号具备可用凭证。推荐创建一个专门用于基础设施自动化的 IAM 用户，而不是使用根账号的 AccessKey。该用户需要被授予一组最小权限策略，允许 AutoK3s 调用 EC2、VPC、IAM 等接口，但不应拥有删除 S3 或修改账单之类的无关权限。下面是可参考的策略片段，实际使用时可根据是否创建 VPC、是否自动创建安全组等情况裁剪。
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ec2:RunInstances",
"ec2:DescribeInstances",
"ec2:DescribeImages",
"ec2:DescribeVpcs",
"ec2:DescribeSubnets",
"ec2:DescribeSecurityGroups",
"ec2:CreateSecurityGroup",
"ec2:AuthorizeSecurityGroupIngress",
"ec2:DeleteSecurityGroup",
"ec2:TerminateInstances",
"ec2:CreateTags",
"iam:PassRole"
],
"Resource": "*"
}
]
}
其中 iam:PassRole 是关键权限之一。AutoK3s 在启动 EC2 实例时需要给实例关联一个 IAM 角色，以便节点内部的 cloud provider 组件或后续的负载均衡操作能够正常访问 AWS 接口。如果该项缺失，控制台虽然可能显示实例已创建，但 K3s 节点的初始化脚本无法完成 AWS 元数据读取，随后会出现节点注册失败或 Pod 无法获取云资源信息等问题。
同时需要准备目标区域的 VPC 和子网。如果不想使用默认 VPC，可以提前创建好专用 VPC，并确保子网开启了自动分配公网 IP，或者已经配置 NAT 网关供节点访问外网。安全组方面，至少需要放行 K3s API server 使用的 6443/TCP 端口，以及节点之间的 UDP 和 TCP 端口。对于测试环境，可以先放行 0.0.0.0/0 到 6443 端口，但生产环境建议只对办公网或跳板机 IP 开放。
安装 AutoK3s 与配置 AWS 集群参数
AutoK3s 可以通过官方脚本安装，也可以用 Docker 容器运行。使用脚本安装后，可以直接在终端中执行 autok3s 命令。安装脚本一般会从镜像站点下载二进制并放到 /usr/local/bin 下。
curl -sfL https://rancher-mirror.rancher.cn/autok3s/install.sh | sh - autok3s version
安装完成后，先为当前终端设置 AWS 凭证环境变量。AutoK3s 对 AWS provider 的认证会读取这些环境变量，因此不要把它们写进代码仓库或配置文件。可以使用 export 临时设置，也可以借助 AWS CLI 的 profile 机制，但环境变量方式在 CI/CD 中更直观。
export AWS_ACCESS_KEY_ID=AKIAIOSFODNN7EXAMPLE export AWS_SECRET_ACCESS_KEY=wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY export AWS_DEFAULT_REGION=ap-southeast-1
随后可以编写集群描述文件，或者直接使用命令行参数。推荐使用 YAML 文件，因为参数较多且后续可复用。一个典型的 AWS provider 配置示例如下，其中 name 是集群唯一标识，masterCount 和 workerCount 分别控制 server 节点和 agent 节点数量。
provider: aws name: my-k3s-cluster region: ap-southeast-1 instanceType: t3.medium imageId: ami-0c2b0d3f6e92c9a1e vpc: vpc-0a1b2c3d4e5f6a7b8 subnet: subnet-0b1c2d3e4f5a6b7c8 securityGroup: sg-0c1d2e3f4a5b6c7d8 sshUser: ubuntu keypairName: my-aws-key k3sVersion: v1.28.5+k3s1 masterCount: 1 workerCount: 2
这里要特别注意 imageId 必须与 region 匹配，因为不同区域的 AMI ID 不同。如果使用了不存在的 AMI，EC2 会在创建流程刚开始时直接报错，AutoK3s 日志中会看到 InvalidAMIID.NotFound。实例类型建议至少选择 t3.medium，K3s 虽然比 kubeadm 轻量，但 server 节点仍然需要 2 GB 以上内存才能稳定运行。
执行创建时使用 autok3s create 命令并指定 provider 和配置文件。AutoK3s 会在后台创建实例、上传 SSH 公钥、执行 K3s 安装脚本，并把 server 节点初始化为 K3s 控制平面。整个过程通常需要几分钟，可以通过 autok3s list 查看集群状态。
验证集群状态与获取管理配置
集群创建完成后，不能只看到 EC2 实例开机就认为集群就绪。需要确认 K3s 服务是否已经在节点上运行，以及 kubectl 是否能够连接到 API server。AutoK3s 提供 kubectl 子命令，可以直接对指定集群执行 kubectl 操作，省去手动合并 kubeconfig 的步骤。
autok3s kubectl --provider aws --name my-k3s-cluster get nodes autok3s kubectl --provider aws --name my-k3s-cluster get pods -A
如果上面的命令返回节点列表并且状态为 Ready，说明控制平面和节点注册都正常。若只显示 master 节点而没有 worker 节点，通常是 worker 节点未能加入集群，此时需要检查安全组和网络。若节点长时间处于 NotReady，可以登录对应实例查看 k3s 服务状态。
systemctl status k3s journalctl -u k3s -n 100 --no-pager
如果希望使用本机 kubectl 而不用 autok3s kubectl，可以从 AutoK3s 的配置目录中找到生成的 kubeconfig 文件，一般位于用户主目录下的 .autok3s 或 .kube 目录。确认 API server 地址能访问后，再设置 KUBECONFIG 环境变量指向该文件即可。
常见失败场景与排查思路
在 AWS 上创建 K3s 集群失败的原因，绝大多数集中在权限、网络和镜像三个层面。权限问题主要表现为 UnauthorizedOperation 或 AccessDenied，解决方法是回到 IAM 策略中补齐相应 Action。网络问题通常表现为实例已启动但节点无法加入，安全组没有放行 6443 端口，或者子网路由表没有指向互联网网关导致 K3s 安装脚本下载失败。
aws ec2 describe-security-groups --group-ids sg-0c1d2e3f4a5b6c7d8 --query 'SecurityGroups[0].IpPermissions' --region ap-southeast-1
如果怀疑 SSH 密钥不匹配，可以直接用私钥连接实例进行人工排查。注意不同的 AMI 默认用户名不同，Ubuntu 通常为 ubuntu，Amazon Linux 通常为 ec2-user。连接成功后手动运行 K3s 安装脚本，观察输出能更直接定位问题。
ssh -i /path/to/private-key.pem ubuntu@<master-public-ip> curl -sfL https://get.k3s.io | sh -
最后，如果集群不再需要，建议使用 autok3s delete --provider aws --name my-k3s-cluster 清理资源，避免产生不必要的 EC2 费用。删除操作会尝试释放 AutoK3s 创建的实例和安全组，但手动创建的 VPC、子网和 IAM 角色不会被自动删除，需要单独处理。