我之前用Docker跑k3s的时候也碰到过类似的连通性问题，给你整理了几个一步步排查的方向，应该能帮你定位问题：

1. 先确认容器网络的基础连通性 #

• 首先要保证server和agent容器在同一个自定义Docker网络中，默认的bridge网络经常会有DNS解析异常的问题。建议先创建专属网络：

  docker network create k3s-net
  

  然后启动容器时都加上--network k3s-net参数，比如server启动命令改成：

  docker run --network k3s-net --name k3s-server rancher/k3s:latest server
  

• 验证容器间能否互相访问：进入agent容器执行ping k3s-server（替换成你的server容器名），如果ping不通，说明网络层面有问题，先解决DNS或网络连通性，再往下排查。

2. 检查k3s Server的启动状态 #

• 查看server容器的启动日志，确认服务是否正常启动：

  docker logs k3s-server
  

  重点看有没有kube-apiserver is running这类成功启动的日志，或者有没有端口监听失败的报错。
• 进入server容器，确认6443端口是否正常监听：

  docker exec k3s-server ss -tulpn | grep 6443
  

  确保能看到kube-apiserver进程在监听这个端口。

3. 验证K3S_TOKEN的一致性 #

• agent使用的K3S_TOKEN必须和server生成的token完全一致。server的token默认存放在容器内的/var/lib/rancher/k3s/server/node-token文件中，你可以用以下命令获取：

  docker exec k3s-server cat /var/lib/rancher/k3s/server/node-token
  

  把获取到的token替换agent启动命令里的xyz，注意token是大小写敏感的，别抄错字符。

4. 确认K3S_URL的正确性 #

• K3S_URL必须是agent容器能解析到的server容器名，并且使用容器内的6443端口，不要用宿主机的端口。比如server容器名叫k3s-server，那么K3S_URL应该是https://k3s-server:6443。
• 可以在agent容器里测试API连通性：

  docker exec <agent_container_id> curl -k https://k3s-server:6443/version
  

  加上-k是因为k3s默认使用自签名证书，如果能返回JSON格式的版本信息，说明API层面已经能正常连通。

5. 查看Agent日志定位具体错误 #

• 启动agent后立刻查看日志，里面会有最直接的错误提示：

  docker logs <agent_container_id>
  

  常见的错误比如x509: certificate signed by unknown authority，这时候需要在server启动时加上-e K3S_TLS_SAN=k3s-server参数（替换成你的server容器名），确保证书包含容器名的SAN字段。

6. 检查容器权限与系统限制 #

• k3s容器需要较高的权限，建议启动时加上--privileged参数，避免因为权限不足导致的网络或存储操作失败：

  docker run --privileged --network k3s-net --name k3s-server rancher/k3s:latest server
  

• 如果你的宿主机开启了SELinux，可能会阻止容器内的操作，可以临时执行setenforce 0关闭SELinux测试，或者给容器添加对应的SELinux标签。

内容的提问来源于stack exchange，提问作者mitra