Kubernetes 中的命名空间和上下文有什么区别？

Question

我发现kubectl --context dev --namespace default {other commands}在许多示例中都像在 kubectl 客户端之前一样指定。我可以在 k8 的环境中清楚地看到它们之间的区别吗？

Answer 1

kubernetes 概念（和术语）上下文仅适用于 kubernetes 客户端，即运行 kubectl 命令的地方，例如命令提示符。kubernetes 服务器端无法识别“上下文”这个术语。

例如，在命令提示符下，即作为客户端：

如果您知道目前您基本上只针对“dev”命名空间，那么您不必在每个 kubectl 命令中始终添加“-n dev”，您可以：

这样，上面的命令将被简化为如下：

您可以设置不同的上下文，例如“context-dev”、“context-staging”等，其中每个上下文都针对不同的命名空间。顺便说一句，名称不必带有“上下文”前缀。您还可以使用“dev”、“staging”等名称。

就像一群人在谈论电影一样。所以在对话中的某个地方使用了“Rocky”这个词。既然他们谈论的是电影，那么很明显，毫无疑问，这里的“洛奇”指的是拳击电影“洛奇”，而不是指“崎岖不平、多石”的地形。每次都提到“电影洛奇”是多余的，没有必要的。只要一个字“洛奇”就足够了。上下文显然是关于电影的。

Kubernetes 和上面的示例也是如此。如果上下文已设置为某个集群和命名空间，则在每个命令中设置和/或提及这些参数是多余且不必要的。

我这里的解释只是围绕命名空间，但这只是一个例子。除了指定命名空间之外，在上下文中，您实际上还需要指定您的目标集群以及用于访问该集群的用户信息。您可以查看 ~/.kube/config 文件内部，了解除命名空间之外还有哪些信息与每个上下文相关联。

在上面问题的示例命令中，指定了命名空间和上下文。在这种情况下，kubectl将使用“dev”上下文中设置的任何配置值，但namespace在此上下文中指定的值（如果存在）将被忽略，因为它将被命令中显式设置的值（即“默认”）覆盖对于上面的示例命令。

同时，命名空间概念被用于服务器端和客户端。它是 Kubernetes 对象的逻辑分组。就像我们如何将操作系统中不同文件夹中的文件分组一样。

Answer 2

上下文是 kubectl 使用的到特定集群（用户名/apiserver 主机）的连接。您可以通过这种方式管理多个集群。命名空间是特定集群内的逻辑分区，用于管理资源和约束。

Answer 3

您可以使用多个上下文来定位多个不同的 Kubernetes 集群。您可以使用kubectl config use-context命令在集群之间快速切换。

命名空间是在多个用户之间划分集群资源的一种方式（通过资源配额）。命名空间旨在用于多个用户分布在多个团队或项目的环境中。

Answer 4

contextKubernetes 中的A是一组访问参数。每个上下文都包含一个 Kubernetes 集群、一个用户和一个命名空间。当前上下文是当前默认的集群kubectl：kubectl针对该集群运行的所有命令。每个context已使用的将在您的.kubeconfig.

同时anamespace是一种在同一个物理集群内支持多个虚拟集群的方式。这通常与资源配额以及 RBAC 管理有关。