1.什么是 kubectl ？

在学习如何更有效地使用 kubectl 之前，您应该对它是什么以及它如何工作有一个基本的了解。从用户的角度来看，kubectl 是你控制 Kubernetes 的驾驶舱。它允许您执行所有可能的 Kubernetes 操作。从技术角度来看，kubectl 是 Kubernetes API 的客户端。

Kubernetes API 是一个 HTTP REST API。这个 API 是真正的 Kubernetes 用户界面。 Kubernetes 完全通过该 API 进行控制。这意味着每个 Kubernetes 操作都作为 API 端点公开，并且可以通过对此端点的 HTTP 请求来执行。

因此，kubectl 的主要工作是向 Kubernetes API 执行 HTTP 请求：

Kubernetes 是一个完全以资源为中心的系统。这意味着，Kubernetes 维护了资源的内部状态，所有 Kubernetes 操作都是对这些资源的 CRUD 操作。您可以通过操纵这些资源来完全控制 Kubernetes（并且 Kubernetes 根据资源的当前状态来确定要做什么）。因此，Kubernetes API 参考被组织为资源类型及其关联操作的列表。

让我们来看一个例子。假设您想要创建一个 ReplicaSet 资源。为此，您需要在名为 replicaset.yaml 的文件中定义 ReplicaSet，然后运行以下命令：

$ kubectl create -f replicaset.yaml

显然，这会在 Kubernetes 中创建您的 ReplicaSet。但幕后发生了什么？

Kubernetes 有一个 create ReplicaSet 操作，与所有 Kubernetes 操作一样，它作为 API 端点公开。该操作的具体API端点如下：

POST /apis/apps/v1/namespaces/{namespace}/replicasets

您可以在 API 参考中找到所有 Kubernetes 操作的 API 端点（包括上述端点）。要向端点发出实际请求，您需要将 API 服务器的 URL 添加到 API 参考中列出的端点路径前面。

因此，当您执行上述命令时，kubectl 会向上述 API 端点发出 HTTP POST 请求。 ReplicaSet 定义（您在 replicaset.yaml 文件中提供）在请求正文中传递。

这就是 kubectl 适用于与 Kubernetes 集群交互的所有命令的方式。在所有这些情况下，kubectl 只是向适当的 Kubernetes API 端点发出 HTTP 请求。

请注意，完全可以使用像 curl 这样的工具通过手动向 Kubernetes API 发出 HTTP 请求来控制 Kubernetes。kubectl 只是让您更轻松地使用 Kubernetes API。

这些是 kubectl 是什么及其工作原理的基础知识。但每个 kubectl 用户都应该了解有关 Kubernetes API 的更多信息。为此，让我们简要深入了解 Kubernetes 的内部结构。

2.Kubernetes 内部结构

Kubernetes 由一组独立的组件组成，这些组件作为单独的进程在集群的节点上运行。有些组件运行在主节点上，其他组件运行在工作节点上，每个组件都有非常特定的功能。

这些是主节点上最重要的组件：

• 存储后端（storage backend）：存储资源定义（通常使用 etcd）。
• API 服务器：提供 Kubernetes API，并管理存储后端控制器管理器；确保资源状态符合规范调度器；将 Pod 调度到工作节点。Pod 是工作节点上最重要的组件。
• kubelet：管理工作节点上容器的执行。

要了解这些组件如何协同工作，让我们考虑一个示例。假设您刚刚执行了 kubectl create -f replicaset.yaml，此时 kubectl 向 create ReplicaSet API 端点发出了 HTTP POST 请求（传递您的 ReplicaSet 资源定义）。

集群中出现这种情况的原因是什么？

在 kubectl create -f replicaset.yaml 之后，API 服务器将您的 ReplicaSet 资源定义保存在存储后端中。

这会触发控制器管理器（controller manager）中的 ReplicaSet 控制器（ReplicaSet controller），该控制器监视 ReplicaSet 资源的创建、更新和删除。

ReplicaSet 控制器为 ReplicaSet 的每个副本创建一个 Pod 定义（根据 ReplicaSet 定义中的 Pod 模板）并将其保存在存储后端。

这会触发调度程序（scheduler）监视尚未分配给工作节点的 Pod。

调度程序为每个 Pod 选择合适的工作节点，并将此信息添加到存储后端的 Pod 定义中。

这会触发 Pod 已调度到的工作节点上的 kubelet，该节点会监视已调度到其工作节点的 Pod。

kubelet 从存储后端读取 Pod 定义，并指示 container runtime（例如 Docker）在工作节点上运行容器。

以下是文字描述：

• 对创建 ReplicaSet 端点的 API 请求由 API 服务器处理。 API 服务器对请求进行身份验证并将您的 ReplicaSet 资源定义保存在存储后端中。
• 该事件会触发 ReplicaSet 控制器，它是控制器管理器的子进程。 ReplicaSet 控制器监视存储后端中 ReplicaSet 资源的创建、更新和删除，并在发生这种情况时收到事件通知。
• ReplicaSet 控制器的工作是确保 ReplicaSet 存在所需数量的副本 Pod。在我们的示例中，尚不存在 Pod，因此 ReplicaSet 控制器创建这些 Pod 定义（根据 ReplicaSet 定义中的 Pod 模板）并将它们保存在存储后端。
• 新 Pod 的创建会触发调度程序，调度程序会监视尚未调度到工作节点的 Pod 定义。调度程序为每个 Pod 选择合适的工作节点，并使用此信息更新存储后端中的 Pod 定义。
• 请注意，到目前为止，集群中的任何位置都没有运行任何工作负载代码。到目前为止所做的只是在主节点上的存储后端中创建和更新资源。
• 此事件会触发 kubelet 来监视调度到其工作节点的 Pod。您的 ReplicaSet Pod 已调度的工作节点的 kubelet 指示配置的 container runtime（可能是 Docker）下载所需的容器映像并运行容器。

至此，您的 ReplicaSet 应用程序终于开始运行了！

3.Kubernetes API 的作用

从上面的例子可以看出，Kubernetes 组件（除了 API 服务器和存储后端）通过监视存储后端的资源变化并操作存储后端的资源来工作。

然而，这些组件并不直接访问存储后端，而是只能通过 Kubernetes API 访问。

看一个示例：

ReplicaSet 控制器使用 list ReplicaSets API 端点 API 携带监视参数的操作来监视 ReplicaSet 资源的更改。 ReplicaSet 控制器使用 create Pod API 端点来创建 Pod。调度程序使用 patch Pod API 端点来更新 Pod，其中包含有关所选工作节点的信息。如您所见，kubectl 也使用相同的 API。

内部组件和外部用户双重使用 Kubernetes API 是 Kubernetes 的基本设计理念。

有了这些知识，您可以总结 Kubernetes 的工作原理如下：

存储后端存储 Kubernetes 的状态（即资源）。 API 服务器以 Kubernetes API 的形式提供与存储后端的接口。所有其他 Kubernetes 组件和用户都通过 Kubernetes API 读取、观察和操作 Kubernetes 的状态（即资源）。熟悉这些概念将有助于您更好地理解 `kubectl` 并充分利用它！

# 4.使用技巧 现在让我们看看一系列具体的提示和技巧，以帮助您提高 `kubectl` 生产力。

提高 kubectl 生产力的最有用但经常被忽视的技巧之一是 completion 命令。

completion 命令允许您使用 Tab 键自动完成 kubectl 命令的各个部分。这适用于子命令、选项和参数，包括资源名称等难以输入的内容。

在这里您可以看到 kubectl 命令完成的实际效果：

命令补全适用于 Bash 和 Zsh shell。

一般来说，completion 命令是一种通过 completion 脚本来工作的 shell 功能。completion 脚本是定义特定命令的完成行为的 shell 脚本。获取完成脚本可以完成相应的命令。

Kubectl 可以使用以下命令自动生成并打印出 Bash 和 Zsh 的完成脚本：

kubectl completion bash
# or
kubectl completion zsh