介绍
kubectl 是你在整个 CKAD 风格的 Kubernetes 工作中将要使用的命令行工具。在创建 Pod、Deployment、Service 或配置对象之前，你需要了解 kubectl 当前连接的是哪个集群，以及你的命令默认针对的是哪个命名空间。
在本实验中，你将检查当前的 Kubernetes 上下文，列出命名空间，将一个练习用的命名空间设置为当前命名空间，并创建一个简单的 ConfigMap，以观察命名空间对象是如何实现隔离的。检查的重点在于你所创建的关键 Kubernetes 状态，而非命令输出的精确格式。
确认 kubectl 访问权限
在此步骤中，你将确认 kubectl 是否能够连接到准备好的 Kubernetes 集群，并识别你的命令当前所使用的上下文。
从 /home/labex/project 开始。mkdir -p 命令会在目录不存在时创建它，如果目录已存在则不会产生任何影响。本课程将学员的工作保存在该目录下，以便后续实验可以在一个可预测的位置创建清单文件和辅助文件。
mkdir -p /home/labex/project
cd /home/labex/project
Kubernetes 上下文是 kubeconfig 中保存的连接选择。它告诉 kubectl 使用哪个集群、用户凭据以及默认命名空间。在运行任何更改对象的命令之前，请先检查当前活动的上下文。
kubectl config current-context
你应该会看到准备好的 LabEx Kubernetes 配置文件名称：
labex-v135
为了获得一个可预测的起点，请将当前上下文的命名空间设置为 default。这里你并没有创建对象；你只是在告诉 kubectl，当后续的命名空间相关命令省略了 --namespace 参数时，应该使用哪个命名空间。
kubectl config set-context --current --namespace=default
输出应确认当前上下文已更新：
Context "labex-v135" modified.
在虚拟机启动后，Kubernetes 配置文件可能需要片刻时间才能完成初始化。首先列出集群节点。如果此命令报告 API 服务器尚未就绪，请等待几秒钟并再次运行该命令，直到看到 Ready 状态的节点。
kubectl get nodes --request-timeout=5s
预期的输出将包含一个就绪的节点和 Kubernetes 版本：
NAME STATUS ROLES AGE VERSION
labex-v135 Ready control-plane ... v1.35...
现在向 API 服务器查询基本的集群信息。这证明了你的终端不仅找到了 kubectl 二进制文件，而且确实已经通过身份验证并连接到了正在运行的集群。
kubectl cluster-info
输出应提及 Kubernetes 控制平面端点：
Kubernetes control plane is running at ...
...
读取命名空间
在此步骤中，你将检查 Kubernetes 命名空间，并查看当前上下文默认使用的命名空间。
命名空间是一种将命名空间内的 Kubernetes 对象划分到同一集群内不同作用域的方法。许多应用程序资源（如 Pod、Deployment、Service、Secret 和 ConfigMap）都精确地存在于一个命名空间中。
列出集群中已存在的命名空间：
kubectl get namespaces
你应该会看到系统命名空间（如 kube-system）和普通的应用程序命名空间 default：
NAME STATUS AGE
default Active ...
kube-system Active ...
...
你的上下文也可以存储一个默认命名空间。当你运行不带 --namespace 参数的命名空间相关命令时，kubectl 会使用该默认命名空间。--minify 选项仅显示当前活动的上下文，而 jsonpath 表达式仅打印命名空间字段。
kubectl config view --minify --output 'jsonpath={..namespace}'; echo
由于你在上一步中设置了上下文命名空间，因此这里会打印 default：
default
你始终可以通过 --namespace 为单个命令覆盖当前命名空间。例如，在不更改上下文的情况下检查 Kubernetes 系统命名空间中的 Pod：
kubectl get pods --namespace kube-system
具体的 Pod 名称可能会有所不同，但该命令应返回系统 Pod，例如 CoreDNS、网络或存储组件：
NAME READY STATUS RESTARTS AGE
... ... ... ... ...
选择练习命名空间
在此步骤中，你将为本次实验创建一个命名空间，并将其设置为后续命令的默认命名空间。
创建一个名为 ckad-prep-contexts 的命名空间。命名空间名称是对象标识的一部分：一个命名空间中名为 app-settings 的 ConfigMap 与另一个命名空间中同名的 ConfigMap 是不同的。
kubectl create namespace ckad-prep-contexts
创建命令应确认新命名空间已创建：
namespace/ckad-prep-contexts created
现在仅更新当前上下文，以便不带 --namespace 的命令能够指向 ckad-prep-contexts。--current 选项的意思是“修改我当前正在使用的上下文”，而不是手动指定上下文名称。
kubectl config set-context --current --namespace=ckad-prep-contexts
输出确认上下文已修改：
Context "labex-v135" modified.
再次检查活动上下文中存储的命名空间：
kubectl config view --minify --output 'jsonpath={..namespace}'; echo
现在它应该打印：
ckad-prep-contexts
运行一个简单的 Pod 列出命令，且不带 --namespace。由于当前的命名空间现在是 ckad-prep-contexts，此命令会在你的练习命名空间内查找。命名空间为空是正常的。
kubectl get pods
预期输出：
No resources found in ckad-prep-contexts namespace.
观察命名空间作用域
在此步骤中，你将创建一个小的 ConfigMap，并利用它来观察当前命名空间如何影响对象查找。
ConfigMap 用于存储应用程序的非敏感配置数据。它轻量、创建快速且具有命名空间属性，这使得它非常适合在部署实际应用程序之前练习命名空间行为。
创建一个名为 app-settings 的 ConfigMap，且不传递 --namespace 参数。由于你在上一步中选择了 ckad-prep-contexts，Kubernetes 会在该命名空间中创建它。
kubectl create configmap app-settings --from-literal=mode=prep
该命令应报告：
configmap/app-settings created
在不使用命名空间标志的情况下列出该 ConfigMap。这会使用当前上下文的命名空间。
kubectl get configmap app-settings
预期输出：
NAME DATA AGE
app-settings 1 ...
现在通过显式指定命名空间来查询同一个对象。这应该会返回同一个 ConfigMap，因为 ckad-prep-contexts 正是你创建它的地方。
kubectl get configmap app-settings --namespace ckad-prep-contexts
最后，检查 default 命名空间。--ignore-not-found 选项使得 kubectl 在对象不存在时能够成功退出且不打印任何内容，这对于指导实验非常有用，因为在这种情况下，对象不存在正是预期的结果。
kubectl get configmap app-settings --namespace default --ignore-not-found
没有输出意味着 ConfigMap 没有在 default 中创建。现在你已经看到了在当前上下文中设置命名空间的实际效果。
总结
你确认了 kubectl 可以连接到准备好的 Kubernetes 集群，识别了活动上下文，检查了现有的命名空间，更改了当前上下文的命名空间，并创建了一个 ConfigMap 来观察命名空间的作用域。这些基础知识是后续 CKAD 准备实验的基石，在那些实验中，你将创建应用程序对象，并需要确切地知道每个对象是在哪里被创建和检查的。
