如果您使用 Kubernetes，那么 kubectl 可能是您最常使用的实用程序之一。 每当您花费大量时间使用某个特定工具时，好好研究它并学习如何有效地使用它是值得的。
团队 翻译了 Daniel Weibel 撰写的一篇文章，您将在其中找到有效使用 kubectl 的提示和技巧。 它还将帮助您更深入地了解 Kubernetes。
作者表示，本文的目标是让您使用 Kubernetes 的日常工作不仅更加高效，而且更加愉快！
简介：什么是 kubectl
在学习更有效地使用 kubectl 之前，您需要对它是什么以及它如何工作有一个基本的了解。
从用户的角度来看，kubectl 是一个控制面板，允许您执行 Kubernetes 操作。
从技术上讲，kubectl 是一个 Kubernetes API 客户端。
Kubernetes API 是一个 HTTP REST API。 这个API是真正的Kubernetes用户界面，通过它可以完全控制。 这意味着每个 Kubernetes 操作都作为 API 端点公开，并且可以通过对该端点的 HTTP 请求来进行。
因此，kubectl的主要工作是向Kubernetes API发出HTTP请求：
Kubernetes 是一个完全面向资源的系统。 这意味着它维护资源的内部状态，并且所有 Kubernetes 操作都是 CRUD 操作。
通过管理这些资源，您可以完全控制 Kubernetes，并且 Kubernetes 根据资源的当前状态确定要做什么。 因此，Kubernetes API 参考被组织为资源类型及其关联操作的列表。
让我们看一个例子.
假设您要创建一个 ReplicaSet 资源。 为此，您可以按名称在文件中描述 ReplicaSet replicaset.yaml，然后运行命令：
$ kubectl create -f replicaset.yaml这将创建一个 ReplicaSet 资源。 但幕后发生了什么？
Kubernetes 有一个 ReplicaSet 创建操作。 与任何其他操作一样，它作为 API 端点公开。 此操作的具体 API 端点如下所示：
POST /apis/apps/v1/namespaces/{namespace}/replicasets所有 Kubernetes 操作的 API 端点可以在以下位置找到： （包括 ）。 要向端点发出实际请求，您必须首先将 API 服务器 URL 添加到 API 参考中列出的端点路径。
因此，当您执行上述命令时，kubectl 会向上述 API 端点发送 HTTP POST 请求。 您在文件中提供的 ReplicaSet 定义 replicaset.yaml，在请求正文中发送。
这就是 kubectl 适用于与 Kubernetes 集群交互的所有命令的方式。 在所有这些情况下，kubectl 只是向适当的 Kubernetes API 端点发出 HTTP 请求。
请注意，您可以使用实用程序来完全管理 Kubernetes，例如 curl通过手动向 Kubernetes API 发送 HTTP 请求。 Kubectl 只是让 Kubernetes API 的使用变得更容易。
这是 kubectl 是什么及其工作原理的基础知识。 但每个 kubectl 用户都应该了解有关 Kubernetes API 的其他内容。 让我们快速了解一下 Kubernetes 的内部世界。
Kubernetes的内部世界
Kubernetes 由一组独立的组件组成，这些组件作为单独的进程在集群节点上运行。 一些组件在主节点上运行，其他组件在工作节点上运行，每个组件执行自己的特定任务。
以下是主节点上最重要的组件：
- 知识库 - 存储资源定义（).
- API服务器 — 提供 API 并管理存储。
- 控制器经理 — 确保资源状态符合规范。
- 调度器 — 在工作节点上调度 pod。
这是工作节点上最重要的组件之一：
- 库贝莱特 — 管理工作节点上容器的启动。
要了解这些组件如何协同工作，让我们看一个示例。
假设您刚刚完成 kubectl create -f replicaset.yaml，之后 kubectl 向 （传递ReplicaSet资源定义）。
集群中发生了什么？
- 做完之后
kubectl create -f replicaset.yamlAPI 服务器将您的 ReplicaSet 资源定义存储在存储中： - 接下来，在控制器管理器中启动ReplicaSet控制器，该控制器处理ReplicaSet资源的创建、修改和删除：
- ReplicaSet控制器为每个ReplicaSet副本创建一个Pod定义（根据ReplicaSet定义中的Pod模板）并将它们存储在存储中：
- 调度程序启动，跟踪尚未分配给任何工作节点的 Pod：
- 调度程序为每个 pod 选择合适的工作节点，并将此信息添加到存储中的 pod 定义中：
- 在分配 pod 的工作节点上，启动 Kubelet，它跟踪分配给该节点的 pod：
- Kubelet 从存储中读取 pod 定义，并指示容器运行时（例如 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 必须指示容器运行时（例如 Docker）下载所需的容器映像并运行它们。
至此，您的 ReplicaSet 应用程序终于运行起来了！
Kubernetes API 的作用
正如您在前面的示例中看到的，Kubernetes 组件（API 服务器和存储除外）会监视存储中资源的更改并更改有关存储中资源的信息。
当然，这些组件并不直接与存储交互，而是仅通过 Kubernetes API 进行交互。
考虑以下示例:
- ReplicaSet控制器使用API端点 带参数
watch监控ReplicaSet资源的变化。 - ReplicaSet控制器使用API端点 (create pod) 创建 pod。
- 调度程序使用API端点 （编辑 pod）以使用有关所选工作节点的信息更新 pod。
如您所见，这与 kubectl 访问的 API 相同。 对内部组件和外部用户使用相同的 API 是 Kubernetes 设计中的一个基本概念。
现在我们可以总结一下 Kubernetes 的工作原理：
- 存储存储状态，即 Kubernetes 资源。
- API服务器以Kubernetes API的形式提供存储接口。
- 所有其他 Kubernetes 组件和用户都通过 API 读取、观察和操作 Kubernetes 状态（资源）。
了解这些概念将帮助您更好地理解 kubectl 并充分利用它。
现在让我们看看一些具体的提示和技巧，它们将有助于提高您使用 kubectl 的工作效率。
1.使用命令补全加速输入
用于提高 kubectl 性能的最有用但经常被忽视的技术之一是命令完成。
命令补全允许您使用 Tab 键自动补全 kubectl 命令的部分内容。 这适用于子命令、选项和参数，包括像资源名称这样复杂的东西。
查看 kubectl 命令补全的工作原理：
命令完成适用于 Bash 和 Zsh shell。
包含设置自动完成的详细说明，但下面我们将提供简短的摘录。
命令完成的工作原理
命令完成是一项使用完成脚本工作的 shell 功能。 扩展脚本是一个 shell 脚本，它定义特定命令的扩展行为。
Kubectl 使用以下命令自动生成并输出 Bash 和 Zsh 的扩展脚本：
$ kubectl completion bashИли：
$ kubectl completion zsh理论上，将这些命令的输出连接到适当的命令 shell 就足够了，以便 kubectl 可以补充这些命令。
实际上，Bash（包括Linux和MacOS之间的差异）和Zsh的连接方法是不同的。 下面我们将看看所有这些选项。
Linux 上的 Bash
Bash 补全脚本依赖于 bash-completion 包，因此需要先安装它：
$ sudo apt-get install bash-completionИли：
$ yum install bash-completion您可以使用以下命令测试软件包是否安装成功：
$ type _init_completion
如果输出 shell 函数代码，则 bash-completion 已正确安装。 如果该命令给出“Not Found”错误，您需要将以下行添加到您的文件中 ~ / .bashrc:
$ source /usr/share/bash-completion/bash_completion
文件中是否需要添加这一行 ~ / .bashrc 或不取决于您用于安装 bash-completion 的包管理器。 这对于 APT 是必需的，但对于 YUM 不是必需的。
安装 bash-completion 后，您需要配置所有内容，以便在所有 shell 会话中启用 kubectl 完成脚本。
一种方法是将以下行添加到文件中 ~ / .bashrc:
source <(kubectl completion bash)
另一种方法是将kubectl扩展脚本添加到目录中 /etc/bash_completion.d （如果不存在则创建）：
$ kubectl completion bash >/etc/bash_completion.d/kubectl
目录中的所有附加脚本 /etc/bash_completion.d 自动包含在 bash-completion 中。
两个选项同样适用。
重新启动 shell 后，kubectl 命令完成将起作用。
MacOS 上的 Bash
在 MacOS 上，设置稍微复杂一些。 事实是，默认情况下，MacOS 使用 Bash 3.2 版本，而 kubectl 自动完成脚本需要至少 4.1 的 Bash 版本，并且在 Bash 3.2 中不起作用。
在 MacOS 上使用过时版本的 Bash 存在相关的许可问题。 Bash 版本 4 根据 GPLv3 授权，Apple 不支持。
要在 MacOS 上配置 kubectl 自动完成功能，您需要安装更新版本的 Bash。 您还可以将更新后的 Bash 设置为您的默认 shell，这将为您在将来节省很多问题。 并不难，文章中有详细介绍““。
在继续之前，请确保您使用的是最新版本的 Bash（检查输出 bash --version).
Bash 完成脚本因项目而异 ，所以你需要先安装它。
您可以使用安装 bash-completion :
$ brew install bash-completion@2
这是 @2 代表 bash-completion version 2。kubectl 自动完成需要 bash-completion v2，而 bash-completion v2 至少需要 Bash 版本 4.1。
命令输出 brew-install 包含一个警告部分，它指定需要添加到文件中的内容 ~/.bash_profile:
export BASH_COMPLETION_COMPAT_DIR=/usr/local/etc/bash_completion.d
[[ -r "/usr/local/etc/profile.d/bash_completion.sh" ]] && .
"/usr/local/etc/profile.d/bash_completion.sh"
但是，我建议不要添加这些行 ~/.bash_profile而在 ~/.bashrc。 在这种情况下，自动完成功能不仅在主命令 shell 中可用，而且在子命令 shell 中也可用。
重新启动命令 shell 后，您可以使用以下命令验证安装是否正确：
$ type _init_completion如果您在输出中看到 shell 函数，则说明一切配置正确。
现在我们需要确保在所有会话中启用 kubectl 自动完成功能。
一种方法是将以下行添加到您的 ~/.bashrc:
source <(kubectl completion bash)
第二种方法是将自动完成脚本添加到文件夹中 /usr/local/etc/bash_completion.d:
$ kubectl completion bash
>/usr/local/etc/bash_completion.d/kubectl仅当您使用 Homebrew 安装了 bash-completion 时，此方法才有效。 在这种情况下，bash-completion 会加载此目录中的所有脚本。
如果你安装了 ，那么就不需要执行上一步了，因为自动补全脚本会自动放到该文件夹中 /usr/local/etc/bash_completion.d 在安装过程中。 在这种情况下，一旦您安装了 bash-completion，kubectl 自动完成功能就会开始工作。
因此，所有这些选项都是等效的。
岩组
Zsh 的自动完成脚本不需要任何依赖项。 您所需要做的就是在加载命令 shell 时启用它们。
您可以通过在您的 ~/.zshrc 文件：
source <(kubectl completion zsh)
如果您收到错误 not found: compdef 重新启动 shell 后，您需要启用内置功能 compdef。 您可以通过将其添加到文件的开头来启用它 ~/.zshrc 以下内容：
autoload -Uz compinit
compinit2.快速查看资源规格
创建 YAML 资源定义时，您需要了解这些资源的字段及其含义。 可以在 API 参考中查找此信息，其中包含所有资源的完整规范。
然而，每次需要搜索某些内容时都切换到网络浏览器很不方便。 因此 kubectl 提供了命令 kubectl explain，它显示终端中所有资源的规格。
命令格式如下：
$ kubectl explain resource[.field]...该命令将输出所请求的资源或字段的规范。 显示的信息与 API 手册中包含的信息相同。
默认情况下， kubectl explain 仅显示字段的第一层嵌套。
看看它是什么样子 .
如果添加选项，则可以显示整个树 --recursive:
$ kubectl explain deployment.spec --recursive如果您不确切知道需要哪些资源，可以使用以下命令显示所有资源：
$ kubectl api-resources
此命令以复数形式显示资源名称，例如 deployments 而不是 deployment。 它还显示短名称，例如 deploy，对于那些拥有它的资源。 不用担心这些差异。 所有这些命名选项对于 kubectl 都是等效的。 也就是说，您可以将它们中的任何一个用于 kubectl explain.
以下所有命令都是等效的：
$ kubectl explain deployments.spec
# или
$ kubectl explain deployment.spec
# или
$ kubectl explain deploy.spec3.使用自定义列输出格式
默认命令输出格式 kubectl get:
$ kubectl get pods
NAME READY STATUS RESTARTS AGE
engine-544b6b6467-22qr6 1/1 Running 0 78d
engine-544b6b6467-lw5t8 1/1 Running 0 78d
engine-544b6b6467-tvgmg 1/1 Running 0 78d
web-ui-6db964458-8pdw4 1/1 Running 0 78d这种格式很方便，但包含的信息量有限。 与完整的资源定义格式相比，这里只显示了几个字段。
在这种情况下，您可以使用自定义列输出格式。 它允许您确定要输出哪些数据。 您可以将任何资源字段显示为单独的列。
自定义格式的使用由以下选项决定：
-o custom-columns=<header>:<jsonpath>[,<header>:<jsonpath>]...
您可以将每个输出列定义为一对 <header>:<jsonpath>哪里 <header> 是列名称，并且 <jsonpath> — 定义资源字段的表达式。
让我们看一个简单的例子：
$ kubectl get pods -o custom-columns='NAME:metadata.name'
NAME
engine-544b6b6467-22qr6
engine-544b6b6467-lw5t8
engine-544b6b6467-tvgmg
web-ui-6db964458-8pdw4输出包含一列，其中包含 Pod 的名称。
选项表达式从字段中选择 pod 名称 metadata.name。 这是因为 pod 的名称是在 child name 字段中定义的 metadata 在 pod 的资源描述中。 更多详细信息可以参见 或输入命令 kubectl explain pod.metadata.name.
现在假设您想在输出中添加一个额外的列，例如显示每个 Pod 运行的节点。 为此，您只需将适当的列规范添加到自定义列选项即可：
$ kubectl get pods
-o custom-columns='NAME:metadata.name,NODE:spec.nodeName'
NAME NODE
engine-544b6b6467-22qr6 ip-10-0-80-67.ec2.internal
engine-544b6b6467-lw5t8 ip-10-0-36-80.ec2.internal
engine-544b6b6467-tvgmg ip-10-0-118-34.ec2.internal
web-ui-6db964458-8pdw4 ip-10-0-118-34.ec2.internal
该表达式从以下位置选择节点名称 spec.nodeName — 当一个 pod 被分配给一个节点时，它的名字被写在字段中 spec.nodeName Pod 资源规范。 更详细的信息可以在输出中找到 kubectl explain pod.spec.nodeName.
请注意，Kubernetes 资源字段区分大小写。
您可以将任何资源字段视为列。 只需查看资源规范并尝试使用您喜欢的任何字段即可。
但首先，让我们仔细看看字段选择表达式。
JSONPath 表达式
选择资源字段的表达式基于 .
JSONPath 是一种用于从 JSON 文档检索数据的语言。 选择单个字段是 JSONPath 最简单的用例。 他有很多 ，包括选择器、过滤器等。
Kubectl解释支持有限数量的JSONPath功能。 下面描述了它们的可能性和使用示例：
# Выбрать все элементы списка
$ kubectl get pods -o custom-columns='DATA:spec.containers[*].image'
# Выбрать специфический элемент списка
$ kubectl get pods -o custom-columns='DATA:spec.containers[0].image'
# Выбрать элементы списка, попадающие под фильтр
$ kubectl get pods -o custom-columns='DATA:spec.containers[?(@.image!="nginx")].image'
# Выбрать все поля по указанному пути, независимо от их имени
$ kubectl get pods -o custom-columns='DATA:metadata.*'
# Выбрать все поля с указанным именем, вне зависимости от их расположения
$ kubectl get pods -o custom-columns='DATA:..image'[] 运算符尤其重要。 许多 Kubernetes 资源字段都是列表，此运算符允许您选择这些列表的成员。 它通常与 [*] 等通配符一起使用来选择列表中的所有元素。
应用实例
使用自定义列输出格式的可能性是无限的，因为您可以在输出中显示任何字段或资源字段的组合。 以下是一些示例应用程序，但您可以随意自行探索并找到适合您的应用程序。
- 显示 Pod 的容器镜像：
$ kubectl get pods -o custom-columns='NAME:metadata.name,IMAGES:spec.containers[*].image' NAME IMAGES engine-544b6b6467-22qr6 rabbitmq:3.7.8-management,nginx engine-544b6b6467-lw5t8 rabbitmq:3.7.8-management,nginx engine-544b6b6467-tvgmg rabbitmq:3.7.8-management,nginx web-ui-6db964458-8pdw4 wordpress此命令显示每个 Pod 的容器映像名称。
请记住，一个 pod 可以包含多个容器，那么镜像名称将显示在一行上，并以逗号分隔。
- 显示节点可用区：
$ kubectl get nodes -o custom-columns='NAME:metadata.name,ZONE:metadata.labels.failure-domain.beta.kubernetes.io/zone' NAME ZONE ip-10-0-118-34.ec2.internal us-east-1b ip-10-0-36-80.ec2.internal us-east-1a ip-10-0-80-67.ec2.internal us-east-1b如果您的集群托管在公共云中，则此命令非常有用。 它显示每个节点的可用区域。
可用区是一个云概念，它将复制区域限制在一个地理区域内。
每个节点的可用区都是通过一个特殊的标签获得的 - 。 如果集群在公共云中运行，则会自动创建此标签并填充每个节点的可用区名称。
标签不是 Kubernetes 资源规范的一部分，因此您在以下位置找不到有关它们的信息 。 但是，如果您以 YAML 或 JSON 格式请求有关节点的信息，则可以看到它们（与任何其他标签一样）：
$ kubectl get nodes -o yaml # или $ kubectl get nodes -o json除了学习资源规范之外，这是了解更多资源的好方法。
4.集群和命名空间之间轻松切换
当 kubectl 向 Kubernetes API 发出请求时，它首先读取 kubeconfig 文件以获取连接所需的所有参数。
默认情况下，kubeconfig 文件是 ~/.kube/config。 通常，该文件是由特殊命令创建或更新的。
当您使用多个集群时，您的 kubeconfig 文件包含用于连接到所有这些集群的设置。 您需要一种方法来告诉 kubectl 命令您正在使用哪个集群。
在一个集群中，您可以创建多个命名空间——物理集群中的一种虚拟集群。 Kubectl 还根据 kubeconfig 文件确定要使用哪个命名空间。 这意味着您还需要一种方法来告诉 kubectl 命令要使用哪个命名空间。
在本章中，我们将解释它是如何工作的以及如何使其有效地工作。
请注意，KUBECONFIG 环境变量中可能列出了多个 kubeconfig 文件。 在这种情况下，所有这些文件将在运行时组合成一个通用配置。 您还可以通过使用参数运行 kubectl 来更改默认的 kubeconfig 文件 --kubeconfig. 看 .
kubeconfig 文件
让我们看看 kubeconfig 文件到底包含什么：
如您所见，kubeconfig 文件包含一组上下文。 上下文由三个元素组成：
- 集群 — 集群服务器的 API URL。
- 用户 - 集群中的用户身份验证凭据。
- 命名空间 - 加入集群时使用的命名空间。
在实践中，他们经常在 kubeconfig 中为每个集群使用一个上下文。 但是，每个集群可以有多个上下文，按用户或命名空间进行区分。 然而，这种多上下文配置并不常见，因此集群和上下文之间通常存在一对一的映射。
在任何给定时间，其中一个上下文都是当前的：
当 kubectl 读取配置文件时，它总是从当前上下文中获取信息。 在上面的示例中，kubectl 将连接到 Hare 集群。
因此，要切换到另一个集群，您需要更改 kubeconfig 文件中的当前上下文：
现在 kubectl 将连接到 Fox 集群。
要切换到同一集群中的不同命名空间，您需要更改当前上下文的命名空间元素的值：
在上面的示例中，kubectl 将使用 Fox 集群的 Prod 命名空间（之前设置了 Test 命名空间）。
请注意，kubectl 还提供了选项 --cluster, --user, --namespace и --context，它允许您覆盖单个元素和当前上下文本身，无论 kubeconfig 中设置了什么。 看 kubectl options.
理论上，您可以手动更改 kubeconfig 中的设置。 但很不方便。 为了简化这些操作，有多种实用程序允许您自动更改参数。
使用kubectx
一个非常流行的实用程序，用于在集群和命名空间之间切换。
该实用程序提供命令 kubectx и kubens 分别更改当前上下文和命名空间。
如前所述，如果每个集群只有一个上下文，则更改当前上下文意味着更改集群。
以下是运行这些命令的示例：
本质上，这些命令只是如上所述编辑 kubeconfig 文件。
安装 kubectx，按照说明进行操作
这两个命令都支持上下文和命名空间名称的自动完成，这样就无需完整键入它们。 设置自动完成的说明 .
另一个有用的功能 kubectx 这是 。 它与实用程序结合使用 ，必须单独安装。 自动安装 fzf 使交互模式可用 kubectx。 交互式地，您可以通过 fzf 提供的交互式免费搜索界面选择上下文和命名空间。
使用 shell 别名
您不需要单独的工具来更改当前上下文和命名空间，因为 kubectl 也为此提供了命令。 是的，团队 kubectl config 提供用于编辑 kubeconfig 文件的子命令。
下面是其中一些：
kubectl config get-contexts：显示所有上下文；kubectl config current-context：获取当前上下文；kubectl config use-context：改变当前上下文；kubectl config set-context：更改上下文元素。
然而，直接使用这些命令并不是很方便，因为它们很长。 您可以为它们创建易于执行的 shell 别名。
我根据这些命令创建了一组别名，提供类似于 kubectx 的功能。 在这里您可以看到它们的实际效果：
请注意，别名使用 fzf 来提供交互式免费查找界面（如 kubectx 的交互模式）。 这意味着你需要 使用这些别名。
以下是别名本身的定义：
# Получить текущий контекст
alias krc='kubectl config current-context'
# Список всех контекстов
alias klc='kubectl config get-contexts -o name | sed "s/^/ /;|^ $(krc)$|s/ /*/"'
# Изменить текущий контекст
alias kcc='kubectl config use-context "$(klc | fzf -e | sed "s/^..//")"'
# Получить текущее пространство имен
alias krn='kubectl config get-contexts --no-headers "$(krc)" | awk "{print $5}" | sed "s/^$/default/"'
# Список всех пространств имен
alias kln='kubectl get -o name ns | sed "s|^.*/| |;|^ $(krn)$|s/ /*/"'
# Изменить текущее пространство имен
alias kcn='kubectl config set-context --current --namespace "$(kln | fzf -e | sed "s/^..//")"'
要设置这些别名，您需要将上述定义添加到您的文件中 ~/.bashrc или ~/.zshrc 并重新启动你的外壳。
使用插件
Kubectl 允许您加载以与基本命令相同的方式执行的插件。 例如，您可以安装 kubectl-foo 插件并通过执行命令来运行它 kubectl foo.
以这种方式更改上下文和命名空间会很方便，例如通过运行 kubectl ctx 改变上下文和 kubectl ns 更改命名空间。
我写了两个插件来做到这一点：
插件的工作基于上一节中的别名。
以下是它们的工作方式：
请注意，插件使用 fzf 提供交互式免费搜索界面（如 kubectx 的交互模式）。 这意味着你需要使用这些别名。
要安装插件，您需要下载名为 и 到 PATH 变量中的任何目录并使它们可执行，例如 chmod +x。 在此之后您将能够立即使用 kubectl ctx и kubectl ns.
5. 使用自动别名减少输入
Shell 别名是加快输入速度的好方法。 项目 包含大约 800 个基本 kubectl 命令的快捷方式。
您可能想知道 - 您如何记住 800 个别名？ 但您不需要全部记住它们，因为它们是根据一个简单的方案构建的，如下所示：
例如：
- kgpooyaml - kubectl 获取 pods oyaml
- ksysgsvcw — kubectl -n kube-system 获取 svc w
- ksysrmcm -kubectl -n kube-system rm cm
- kgdepallsl - kubectl 获取部署所有 sl
如您所见，别名由组件组成，每个组件代表 kubectl 命令的一个特定元素。 每个别名可以有一个用于基本命令、操作和资源的组件，以及多个用于参数的组件。 您只需根据上图从左到右“填充”这些组件即可。
目前的详细图位于 。 在那里你还可以找到.
例如，别名 kgpooyamlall 相当于命令 kubectl get pods -o yaml --all-namespaces.
选项的相对顺序并不重要：命令 kgpooyamlall 相当于命令 kgpoalloyaml.
您不必使用所有组件作为别名。 例如 k, kg, klo, ksys, kgpo 也可以使用。 此外，您可以在命令行上组合别名和常规命令或选项：
例如：
- 而不是
kubectl proxy你可以写k proxy. - 而不是
kubectl get roles你可以写kg roles（角色资源当前没有别名）。 - 要获取特定 pod 的数据，可以使用以下命令
kgpo my-pod — kubectl get pod my-pod.
请注意，某些别名需要命令行参数。 例如，别名 kgpol 手段 kubectl get pods -l。 选项 -l 需要一个参数 - 标签规范。 如果您使用别名，它将看起来像 kgpol app=ui.
由于某些别名需要参数，因此必须最后使用别名 a、f 和 l。
一般来说，一旦掌握了这个方案，您就可以直观地从要执行的命令中派生别名，并节省大量的打字时间。
安装
要安装kubectl-aliases，需要下载文件 来自 GitHub 并将其包含在文件中 ~/.bashrc или ~/.zshrc:
source ~/.kubectl_aliases自动完成
正如我们之前所说，您经常在命令行上向别名添加其他单词。 例如：
$ kgpooyaml test-pod-d4b77b989如果您使用 kubectl 命令完成，您可能已经对资源名称等内容使用了自动完成功能。 但是使用别名时可以做到这一点吗？
这是一个非常重要的问题，因为如果自动完成不起作用，您将失去别名的一些好处。
答案取决于您使用的 shell：
- 对于 Zsh，别名补全是开箱即用的。
- 不幸的是，对于 Bash 来说，需要做一些工作才能让自动完成功能发挥作用。
在 Bash 中启用别名自动补全
Bash 的问题在于它尝试完成（每次按 Tab 时）别名，而不是别名引用的命令（例如 Zsh 所做的）。 由于您没有所有 800 个别名的完成脚本，因此自动完成功能不起作用。
项目 为这个问题提供了一个通用的解决方案。 它连接到别名的完成机制，在内部将别名扩展为命令，并返回已完成命令的完成选项。 这意味着别名的填充行为与完整命令的填充行为完全相同。
下面，我将首先解释如何安装complete-alias，然后如何配置它以启用所有 kubectl 别名的补全。
安装完整别名
首先，完整别名取决于 。 因此，在安装complete-alias之前，需要确保已安装bash-completion。 之前已提供 Linux 和 MacOS 的安装说明。
MacOS 用户的重要注意事项：与 kubectl 自动完成脚本一样，complete-alias 不适用于 Bash 3.2，这是 MacOS 上的默认设置。 特别是，complete-alias 依赖于 bash-completion v2 (brew install bash-completion@2），至少需要 Bash 4.1。 这意味着要在 MacOS 上使用完整别名，您需要安装较新版本的 Bash。
您需要下载脚本 из 并将其包含在您的文件中 ~/.bashrc:
source ~/bash_completion.sh重新启动 shell 后，complete-alias 将被完全安装。
为 kubectl 别名启用自动补全
从技术上来说，complete-alias 提供了一个包装函数 _complete_alias。 此函数检查别名并返回别名命令的完成提示。
要将函数与特定别名关联起来，需要使用内置的 Bash 机制 ， 安装 _complete_alias 作为别名完成函数。
作为示例，我们以别名 k 为例，它代表 kubectl 命令。 安装 _complete_alias 作为此别名的补充函数，您应该运行以下命令：
$ complete -F _complete_alias k
这样做的结果是，每当您自动完成别名 k 时，都会调用该函数 _complete_alias，它检查别名并返回命令的完成提示 kubectl.
作为第二个例子，我们使用别名 kg，这表示 kubectl get:
$ complete -F _complete_alias kg
就像前面的示例一样，当您自动完成 kg 时，您会得到与获得相同的完成提示 kubectl get.
请注意，您可以对系统上的任何别名使用complete-alias。
因此，要为所有 kubectl 别名启用自动完成功能，您需要为每个别名运行上述命令。 如果您已将 kubectl-aliases 设置为，以下代码片段正是这样做的 ~/.kubectl-aliases:
for _a in $(sed '/^alias /!d;s/^alias //;s/=.*$//' ~/.kubectl_aliases);
do
complete -F _complete_alias "$_a"
done
这段代码需要放在你的 ~/.bashrc，重新启动命令 shell，自动补全功能将适用于所有 800 个 kubectl 别名。
6. 使用插件扩展 kubectl
自 , kubectl 支持 ，它允许您使用附加命令扩展其功能。
如果你熟悉 ，那么 kubectl 插件也是基于相同的原理构建的。
在本章中，我们将介绍如何安装插件、在哪里找到它们以及如何创建您自己的插件。
安装插件
Kubectl 插件作为简单的可执行文件分发，其名称如下 kubectl-x。 字首 kubectl- 是必需的，后跟一个新的 kubectl 子命令，允许您调用该插件。
例如，hello 插件将作为一个名为的文件分发 kubectl-hello.
要安装插件，需要复制文件 kubectl-x 到 PATH 中的任何目录并使其可执行，例如 chmod +x。 在此之后您可以立即调用该插件 kubectl x.
您可以使用以下命令列出系统上当前安装的所有插件：
$ kubectl plugin list如果您有多个同名插件，或者存在不可执行的插件文件，此命令也会显示警告。
使用 Krew 查找并安装插件
Kubectl 插件可以像软件包一样共享或重用。 但是在哪里可以找到其他人共享的插件呢？
旨在为共享、搜索、安装和管理 kubectl 插件提供统一的解决方案。 该项目称自己为“kubectl 插件的包管理器”（Krew 类似于 ).
Krew 是您可以选择并安装的 kubectl 插件列表。 同时Krew也是kubectl的插件。
这意味着安装 Krew 的工作原理本质上就像安装任何其他 kubectl 插件一样。 您可以在以下位置找到详细说明： .
最重要的克鲁命令是：
# Поиск в списке плагинов
$ kubectl krew search [<query>]
# Посмотреть информацию о плагине
$ kubectl krew info <plugin>
# Установить плагин
$ kubectl krew install <plugin>
# Обновить все плагины до последней версии
$ kubectl krew upgrade
# Посмотреть все плагины, установленные через Krew
$ kubectl krew list
# Деинсталлировать плагин
$ kubectl krew remove <plugin>请注意，使用 Krew 安装插件不会干扰使用上述标准方法安装插件。
请注意该命令 kubectl krew list 仅显示使用 Krew 安装的插件，而命令 kubectl plugin list 列出所有插件，即使用 Krew 安装的插件和通过其他方法安装的插件。
在其他地方寻找插件
Krew 是一个年轻的项目，目前正处于 只有大约 30 个插件。 如果找不到所需的插件，可以在其他地方找到插件，例如 GitHub。
我建议查看 GitHub 部分 。 在那里你会发现数十个值得一试的可用插件。
编写自己的插件
你可以自己 - 这并不难。 您需要创建一个执行您需要的可执行文件，将其命名为 kubectl-x 并按照上述方法安装。
该文件可以是 bash 脚本、Python 脚本或已编译的 GO 应用程序 - 这并不重要。 唯一的条件是可以在操作系统中直接执行。
现在让我们创建一个示例插件。 在上一节中，您使用 kubectl 命令列出每个 pod 的容器。 将此命令转换为插件很容易，您可以使用例如调用 kubectl img.
创建文件 kubectl-img 以下内容：
#!/bin/bash
kubectl get pods -o custom-columns='NAME:metadata.name,IMAGES:spec.containers[*].image'
现在使文件可执行 chmod +x kubectl-img 并将其移动到 PATH 中的任何目录。 之后您就可以立即使用该插件 kubectl img.
如前所述，kubectl 插件可以用任何编程或脚本语言编写。 如果您使用 shell 脚本，则可以从插件中轻松调用 kubectl 的优点。 但是，您可以使用真实的编程语言编写更复杂的插件 。 如果您使用 Go，您还可以使用 ，它专门用于编写 kubectl 插件。
如何分享您的插件
如果您认为您的插件对其他人有用，请随时在 GitHub 上分享。 请务必将它们添加到主题中 .
您还可以请求将您的插件添加到 。 有关如何执行此操作的说明位于 .
命令完成
插件当前不支持自动完成。 也就是说，您必须输入插件的全名和参数的全名。
该函数的 GitHub kubectl 存储库有 。 所以这个功能有可能在未来的某个时候实现。
祝你好运！
关于该主题还可以阅读什么:
- .
- .
- .
来源： habr.com