Go不提供容器编排能力，而是作为编排系统（如dockerd、kubelet）的开发语言；调用Docker API需用官方client包访问/var/run/docker.sock，构造完整ContainerCreateConfig并显式启动容器。
Go 语言本身不提供容器编排能力，docker、kubectl、containerd 等才是实际执行容器生命周期的组件；Go 的角色是作为“编排系统的开发语言”——比如 dockerd、kubelet、helm CLI 都是用 Go 写的。想用 Go 实现容器编排，本质是调用底层运行时 API，而非从零造轮子。
如何用 Go 调用 Docker API 启动和管理容器
最直接的路径是通过 Docker Engine 的 HTTP API（默认监听 unix:///var/run/docker.sock），用 Go 的 http.Client 发送请求。官方推荐使用 github.com/docker/docker/api/types 和 github.com/docker/docker/client 这套客户端封装。
- 必须确保 Go 进程有权限访问
/var/run/docker.sock（通常需加入docker用户组或用sudo） - 创建 client 时要用
client.NewClientWithOpts，传入client.FromEnv或显式指定 socket 路径，不能只靠http.DefaultClient -
ContainerCreate需要完整构造types.ContainerCreateConfig：镜像名、端口映射（HostConfig.PortBindings）、挂载卷（HostConfig.Mounts）都得手动填，漏掉NetworkMode可能导致容器无法联网 - 启动后记得用
Client.ContainerStart显式触发，创建 ≠ 运行
cli, _ := client.NewClientWithOpts(client.FromEnv, client.WithAPIVersionNegotiation())
resp, _ := cli.ContainerCreate(ctx, &types.ContainerConfig{
Image: "nginx:alpine",
Cmd: []string{"nginx", "-g", "daemon off;"},
}, &types.HostConfig{
PortBindings: nat.PortMap{"80/tcp": []nat.PortBinding{{HostPort: "8080"}}},
}, nil, nil, "my-nginx")
cli.ContainerStart(ctx, resp.ID, types.ContainerStartOptions{})
为什么不用 Go 直接 fork/exec runc？
有人尝试绕过 Docker，用 Go 调用 runc 二进制或直接 import github.com/opencontainers/runc 包来创建容器——这在技术上可行，但极不推荐。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
-
runc是低阶 OCI 运行时，需手动生成符合规范的config.json和 rootfs 目录，镜像解包、层合并、seccomp/apparmor 策略注入全得自己实现 - 缺少镜像拉取、存储管理、网络插件（CNI）集成、健康检查等编排必需能力，很快就会陷入重复造轮子
- 主流容器运行时（
containerd、cri-o）已提供稳定的 Go gRPC 客户端（如containerd/containerd包），应优先复用
在 Kubernetes 场景下，Go 如何安全地管理 Pod 生命周期
如果你的目标是“K8s 原生编排”，Go 应通过 kubernetes/client-go 操作 API Server，而不是操作单个容器。
立即学习“go语言免费学习笔记（深入）”；
- 不要用
PodExec或PodPortForward做长期连接——这些方法会占用 API Server 连接，且连接中断后难以自动恢复；应改用watch+ 自定义控制器模式 - 创建
Pod时，Spec.RestartPolicy必须设为Never或OnFailure，若设为Always且没配Deployment，K8s 会不断重启失败的 Pod，掩盖真实错误 - 对敏感操作（如删除命名空间、强制驱逐节点）务必启用
AdmissionControl校验，并在 client-go 中设置RequestTimeout和重试策略，避免因网络抖动导致状态不一致
真正难的不是调用哪个 API，而是理解每层抽象的职责边界：Docker API 管容器进程，containerd 管镜像与运行时，K8s API 管调度与声明式状态。用 Go 写编排逻辑时，选错抽象层会导致代码脆弱、不可维护——比如在业务服务里嵌入 docker pull 调用，远不如交给 ImagePullPolicy 和 K8s 的 CRI 处理可靠。
