我发现在很多例子中，在kubectl client之前指定kubectl --context dev --namespace default {other commands}。在k8的环境中，我能清楚地看到它们之间的区别吗？
kubectl --context dev --namespace default {other commands}
wmomyfyw1#
kubernetes概念（和术语）context仅适用于kubernetes客户端，即运行kubectl命令的地方，例如命令提示符。kubernetes服务器端不识别术语“context”。例如，在命令提示符下，即作为客户端：
kubectl get pods -n dev
kubectl get deployments -n 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对象的逻辑分组。就像我们在操作系统中将文件分组在不同文件夹中一样。
kubectl
namespace
cig3rfwq2#
您可以使用多个上下文来定位多个不同的Kubernetes集群。您可以使用kubectl config use-context命令在集群之间快速切换。集群空间是在多个用户之间划分集群资源的一种方式（通过资源配额）。集群空间旨在用于多个用户分布在多个团队或项目中的环境。
kubectl config use-context
zpjtge223#
Kubernetes中的context是一组访问参数。每个上下文包含一个Kubernetes集群，一个用户和一个命名空间。当前上下文是当前kubectl默认的集群：所有kubectl命令都针对该集群运行。已经使用的每个context都将在.kubeconfig上可用。同时，namespace是一种在同一个物理集群中支持多个虚拟集群的方法。这通常与resource quota以及RBAC管理有关。
context
.kubeconfig
slsn1g294#
context是kubectl使用的到特定集群（username/apiserver host）的连接。您可以通过这种方式管理多个集群。context是特定集群内的逻辑分区，用于管理资源和约束。
4条答案
按热度按时间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对象的逻辑分组。就像我们在操作系统中将文件分组在不同文件夹中一样。
cig3rfwq2#
您可以使用多个上下文来定位多个不同的Kubernetes集群。您可以使用
kubectl config use-context命令在集群之间快速切换。集群空间是在多个用户之间划分集群资源的一种方式（通过资源配额）。集群空间旨在用于多个用户分布在多个团队或项目中的环境。
zpjtge223#
Kubernetes中的
context是一组访问参数。每个上下文包含一个Kubernetes集群，一个用户和一个命名空间。当前上下文是当前kubectl默认的集群：所有kubectl命令都针对该集群运行。已经使用的每个context都将在.kubeconfig上可用。同时，
namespace是一种在同一个物理集群中支持多个虚拟集群的方法。这通常与resource quota以及RBAC管理有关。slsn1g294#
context是kubectl使用的到特定集群（username/apiserver host）的连接。您可以通过这种方式管理多个集群。context是特定集群内的逻辑分区，用于管理资源和约束。