containerd 提供了完全命名空间化的 API,因此多个用户可以同时使用一个 containerd 实例,而不会相互冲突。 命名空间允许在单个守护进程中实现多租户。这就不再需要使用嵌套容器的常见模式来实现这种分离。 用户可以使用具有相同名称但设置和/或配置大不相同的容器。 例如,系统或基础架构级容器可以隐藏在一个命名空间中,而用户级容器则保留在另一个命名空间中。 底层镜像内容仍通过内容地址共享,但每个命名空间的镜像名称和元数据是独立的。
谁指定命名空间?
客户端通过 context
指定命名空间。有一个github.com/containerd/containerd/v2/namespaces
软件包允许用户获取和设置上下文的命名空间。
go
// 设置命名空间
ctx := namespaces.WithNamespace(context.Background(), "my-namespace")
// 获取命名空间
ns, ok := namespaces.Namespace(ctx)
由于客户端调用 containerd 的 gRPC API 来与守护进程交互,因此所有 API 调用都需要一个设置了命名空间的上下文。
请注意,命名空间不能被命名为 `"version"(#6944)。
实现有多低级?
命名空间通过 containerd API 传递给提供功能的底层插件。 编写插件时必须将命名空间考虑在内。 文件系统路径、ID 和其他系统级资源必须使用命名空间,插件才能正常工作。
如何实现多租户?
只需创建一个新的context
,并在 context
中设置应用程序的命名空间。 确保为应用程序使用唯一的命名空间,且不与现有命名空间冲突。命名空间 API 或 ctr namespaces
客户端命令可用于查询/列出和创建新的命名空间。
go
ctx := context.Background()
var (
docker = namespaces.WithNamespace(ctx, "docker")
vmware = namespaces.WithNamespace(ctx, "vmware")
ecs = namespaces.WithNamespace(ctx, "aws-ecs")
cri = namespaces.WithNamespace(ctx, "cri")
)
命名空间标签
命名空间可以有一个与命名空间关联的标签列表。这有助于将元数据与特定命名空间关联起来。 例如,标签还可用于配置 containerd 的默认值:
bash
> sudo ctr namespaces label k8s.io containerd.io/defaults/snapshotter=btrfs
> sudo ctr namespaces label k8s.io containerd.io/defaults/runtime=testRuntime
这将把默认快照器设置为 btrfs
,运行时设置为 testRuntime
。 请注意,目前只有这两个标签用于配置(译者注: k8s.io命名空间的)默认值,而 default
命名空间的标签不会被用于配置默认值。
检查命名空间
如果我们需要检查不同命名空间中的容器、镜像或其他资源,ctr
工具就能帮你做到。 只需在 ctr
上设置 --namespace,-n
标记,就能更改命名空间。如果不提供命名空间,ctr
客户端命令 都将使用默认命名空间,即简单地命名为"default
"。
bash
> sudo ctr -n docker tasks
> sudo ctr -n cri tasks
您还可以使用 CONTAINERD_NAMESPACE
环境变量来指定要用于任何 客户端命令使用的默认命名空间。