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

eufgjt7s  于 12个月前  发布在  Kubernetes
关注(0)|答案(4)|浏览(147)

我发现在很多例子中,在kubectl client之前指定kubectl --context dev --namespace default {other commands}。在k8的环境中,我能清楚地看到它们之间的区别吗?

wmomyfyw

wmomyfyw1#

kubernetes概念(和术语)context仅适用于kubernetes客户端,即运行kubectl命令的地方,例如命令提示符。kubernetes服务器端不识别术语“context”。
例如,在命令提示符下,即作为客户端:

  • 当调用kubectl get pods -n dev时,您将检索位于命名空间“dev”下的pod列表。
  • 当调用kubectl get deployments -n dev时,您将检索位于命名空间“dev”下的部署列表。

如果你知道你目前只针对'dev'命名空间,那么你可以在每个kubectl命令中添加“-n dev”,而不是一直添加“-n dev”:
1.创建一个名为“context-dev”的上下文。
1.为此上下文指定命名空间='dev'。
1.设置current-context ='context-dev'。
这样,你上面的命令将被简化为如下:

  • kubectl get pods
  • kubectl get deployments

您可以设置不同的上下文,例如'context-dev','context-staging'等,其中每个上下文都针对不同的命名空间。顺便说一句,名称前缀不是必须的。您也可以使用'dev','staging'等名称。
就像一群人在谈论电影时的类比一样。所以在对话中的某个地方使用了“Rocky”这个词。因为他们在谈论电影,所以很清楚,这里的“Rocky”指的是拳击电影“Rocky”,而不是“颠簸,多石”的地形。每次提到“电影Rocky”是多余的,也是不必要的。只有一个词,“Rocky”,这就足够了。上下文显然是关于电影的。
Kubernetes和上面的例子也是一样。如果上下文已经设置为某个集群和命名空间,那么在每个命令中设置和/或提及这些参数是多余的,也是不必要的。
我这里的解释只是围绕命名空间,但这只是一个例子。除了指定命名空间,在上下文中,您实际上还将指定您要访问的集群以及用于访问集群的用户信息。您可以查看~/.kube/config文件,以查看除了命名空间之外的其他信息与每个上下文关联。
在上面问题的示例命令中,命名空间和上下文都被指定了。在这种情况下,kubectl将使用'dev'上下文中设置的任何配置值,但是在此上下文中指定的namespace值(如果存在)将被忽略,因为它将被命令中显式设置的值覆盖,即上面示例命令的'default'。
同时,namespace概念在服务器端和客户端都有使用。它是Kubernetes对象的逻辑分组。就像我们在操作系统中将文件分组在不同文件夹中一样。

cig3rfwq

cig3rfwq2#

您可以使用多个上下文来定位多个不同的Kubernetes集群。您可以使用kubectl config use-context命令在集群之间快速切换。
集群空间是在多个用户之间划分集群资源的一种方式(通过资源配额)。集群空间旨在用于多个用户分布在多个团队或项目中的环境。

zpjtge22

zpjtge223#

Kubernetes中的context是一组访问参数。每个上下文包含一个Kubernetes集群,一个用户和一个命名空间。当前上下文是当前kubectl默认的集群:所有kubectl命令都针对该集群运行。已经使用的每个context都将在.kubeconfig上可用。
同时,namespace是一种在同一个物理集群中支持多个虚拟集群的方法。这通常与resource quota以及RBAC管理有关。

slsn1g29

slsn1g294#

context是kubectl使用的到特定集群(username/apiserver host)的连接。您可以通过这种方式管理多个集群。context是特定集群内的逻辑分区,用于管理资源和约束。

相关问题