containerd 提供了完全命名空间化的 API，因此多个用户可以同时使用一个 containerd 实例，而不会相互冲突。
命名空间允许在单个守护进程中实现多租户。这就不再需要使用嵌套容器的常见模式来实现这种分离。
用户可以使用具有相同名称但设置和/或配置大不相同的容器。
例如，系统或基础架构级容器可以隐藏在一个命名空间中，而用户级容器则保留在另一个命名空间中。
底层镜像内容仍通过内容地址共享，但每个命名空间的镜像名称和元数据是独立的。
谁指定命名空间？
客户端通过 context 指定命名空间。有一个github.com/containerd/containerd/v2/namespaces 软件包允许用户获取和设置上下文的命名空间。
// 设置命名空间
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 客户端命令可用于查询/列出和创建新的命名空间。
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 的默认值：
> 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"。
> sudo ctr -n docker tasks
> sudo ctr -n cri tasks
您还可以使用 CONTAINERD_NAMESPACE 环境变量来指定要用于任何
客户端命令使用的默认命名空间。
