近期learnk8s网站上发布了一些关于k8s的好文章，这里搬运并翻译了一些，供大家参考。

本文翻译自《Architecting Kubernetes clusters — choosing a worker node size》。

当您创建Kubernetes集群时，冒出的第一个问题之一是：“我应该使用哪种类型的工作节点以及需要多少个这样的节点”。

如果您正在构建在内部部署的k8s集群，是应该订购一些最近一代的新服务器，还是使用数据中心内的十几台旧机器？

或者，如果您使用Google Kubernetes Engine（GKE）等托管Kubernetes服务，您是否应该使用八个n1-standard-1或两个n1-standard-4实例来实现所需的计算能力呢？

集群容量

通常，Kubernetes集群可以被视为将一组单个节点抽象为一个大的“超级节点”。

该超级节点的总计算容量（就CPU和内存而言）是所有组成节点容量的总和。

有多种方法可以实现集群的所需目标容量。

例如，假设您需要一个总容量为8个CPU内核和32 GB RAM的集群。

例如，因为要在集群上运行的应用程序集需要如此数量的资源。

以下是设计集群的两种可能方法：

这两个选项都会产生具有相同容量的集群 – 但左侧选项使用4个较小的节点，而右侧选项使用2个较大的节点。

哪个更好？

为了解决这个问题，让我们来看看“少数大节点”和“许多小节点”这两个相反方向思路的优缺点。

请注意，本文中的“节点”始终指的是工作节点(worker node)。master节点的数量和大小的选择是完全不同的话题。

使用少量大节点

这方面最极端的情况是仅使用一个可以提供整个所需集群容量的工作节点。

如果要满足上面的示例中容量的需求，这将是一个具有16个CPU内核和16 GB RAM的单个工作节点。

让我们来看看这种方法可能具有的优势。

1. 减少管理成本

简单地说，管理少量机器比管理大量机器要更省力。

更新和补丁可以更快地应用，机器可以更容易保持同步。

此外，对于机器数量少而言，预期故障的绝对数量要小于机器数量多的情况。

但请注意，这主要适用于裸机服务器而不适用于云实例。

如果您使用云实例（作为托管Kubernetes服务的一部分或您在云基础架构上安装的Kubernetes），则将底层机器的管理外包给云提供商。

因此，管理云中的10个节点并不比管理云中的单个节点成本多得多。

2. 每个节点的成本更低

虽然更强大的机器比低端机器更昂贵，但价格上涨不一定是线性的。

换句话说，具有10个CPU内核和10 GB RAM的单台机器可能比具有1个CPU内核和1 GB RAM的10台机器便宜。

但请注意，如果您使用云实例，这可能同样不适用。

在主要云提供商Amazon Web Services，Google Cloud Platform和Microsoft Azure的当前定价方案中，实例价格是随容量线性增加的。

例如，在Google Cloud Platform上，64个n1-standard-1实例的成本与单个n1-standard-64实例完全相同- 两个选项都为您提供64个CPU内核和240 GB内存。

因此，在云中，您通常无法通过使用更大的机器来节省成本。

3. 允许运行资源消耗较大的应用程序

拥有大型节点可能只是您要在集群中运行一类应用程序的要求。

例如，如果您有一台需要8 GB内存的机器学习应用程序，你无法在仅具有1 GB内存的节点的集群上运行它。

但是，您可以在具有10 GB内存节点的群集上运行它。

看过优势后，让我们再来看看其弊端又是什么。

1. 每个节点有大量的pod

在较少的节点上运行相同的工作负载自然意味着在每个节点上运行更多的pod。

这可能成为一个问题。

原因是每个pod都会在节点上运行的Kubernetes代理上引入一些开销 – 例如容器运行时（例如Docker），kubelet和cAdvisor。

例如，kubelet对节点上的每个容器执行常规活动和就绪探测 – 更多容器意味着在每次迭代中kubelet需要做更多的工作。

cAdvisor收集节点上所有容器的资源使用统计信息，并且kubelet定期查询此信息并通过其API发布它 – 再次，这意味着每次迭代中cAdvisor和kubelet的工作量都会增加。

如果pod的数量变大，这些东西可能会开始减慢系统速度，甚至使系统变得不可靠。

有issue称节点因常规的kubelet运行状况检查花费了太长时间来迭代节点上的所有容器而导致节点处于非就绪状态。

出于这些原因，Kubernetes 建议每个节点最多110个pod。

针对这个数字，Kubernetes已经做过测试，结果证明是可以在通常节点类型上可靠地工作的。

根据节点的性能，您可能能够成功地为每个节点运行更多的pod – 但这依然很难预测事情是否会顺利运行，又或您将遇到问题。

大多数托管Kubernetes服务甚至对每个节点的pod数量施加了严格的限制：

• 在Amazon Elastic Kubernetes Service（EKS）上，每个节点的最大pod数取决于节点类型，范围从4到737。
• 在Google Kubernetes Engine（GKE）上，无论节点类型如何，每个节点的限制为100个pod。
• 在Azure Kubernetes服务（AKS）上，默认限制是每个节点30个pod，但最多可以增加到250个。

因此，如果您计划为每个节点运行大量pod，则应该事先测试事情是否能按预期工作。

2. 有限的复制

少量节点可能会限制应用程序的有效复制程度。

例如，如果您有一个由5个副本组成的高可用性应用程序，但您只有2个节点，那么应用程序的有效复制程度将减少到2。

这是因为5个副本只能分布在2个节点上，如果其中一个失败，它可能会同时删除多个副本。

另一方面，如果您有至少5个节点，则理想情况下每个副本可以在单独的节点上运行，并且单个节点的故障最多只会删除一个副本。

因此，如果您具有高可用性要求，则可能需要对集群中的最小节点数提出要求。

3. 更大的爆破半径

如果您只有几个节点，那么失败节点的影响比您有许多节点的影响要大。

例如，如果您只有两个节点，并且其中一个节点出现故障，那么大约一半的节点会消失。

Kubernetes可以将失败节点的工作负载重新安排到其他节点。

但是，如果您只有几个节点，则风险更高，因为剩余节点上没有足够的备用容量来容纳故障节点的所有工作负载。

结果是，部分应用程序将永久停机，直到再次启动故障节点。

因此，如果您想减少硬件故障的影响，您可能希望选择更多的节点。

4. 大比例增量

Kubernetes 为云基础架构提供了一个Cluster Autoscaler，允许根据当前需求自动添加或删除节点。

如果使用大型节点，则会有大的缩放增量，这会使缩放更加笨重。

例如，如果您只有2个节点，则添加其他节点意味着将群集容量增加50％。

这可能比您实际需要的多得多，这意味着您需要为未使用的资源付费。

因此，如果您计划使用集群自动缩放，则较小的节点允许更流畅且经济高效的缩放行为。

在讨论了使用”很少几个大节点”的方案的优缺点之后，让我们转向”许多小节点”的场景。

使用大量小节点

这种方法包括从许多小节点而不是几个大节点中形成集群。

这种方法的优点和缺点是什么？

使用许多小节点的优点主要对应于使用少量大节点的缺点。

1. 较小的爆破半径

如果您有更多节点，则每个节点上的pod自然会更少。

例如，如果您有100个pod和10个节点，则每个节点平均只包含10个pod。

因此，如果其中一个节点发生故障，则影响仅限于总工作负载的较小比例。

有可能只有一些应用程序受到影响，并且可能只有少量副本，因此整个应用程序都会保持运行状态。

此外，剩余节点上的备用资源很可能足以容纳故障节点的工作负载，因此Kubernetes可以重新安排所有pod，并且您的应用程序可以相对快速地返回到完全正常运行的状态。

2. 允许高可复制性

如果您有高可用性需求的应用程序和足够的可用节点，Kubernetes调度程序可以将每个副本分配给不同的节点。

您可以通过节点亲缘关系，pod亲和力/反亲和力以及taint和tolerations来影响调度程序对pod放置位置的选择。

这意味着如果某个节点出现故障，则最多只有一个副本受影响且您的应用程序仍然可用。

看到使用许多小节点的优点，那它有什么缺点呢？

1. 节点数量大

如果使用容量较小的节点，则自然需要更多节点来实现给定的集群容量。

但是大量节点对Kubernetes控制平面来说可能是一个挑战。

例如，每个节点都需要能够与每个其他节点通信，这使得可能的通信路径数量以节点数量的平方的量级增长 – 所有节点都必须由控制平面管理。

Kubernetes控制器管理器中的节点控制器定期遍历集群中的所有节点以运行运行状况检查 – 更多节点意味着节点控制器的负载更多。

更多节点意味着etcd数据库上的负载也更多 – 每个kubelet和kube-proxy都会导致etcd的观察者(watch)客户端（通过API服务器），etcd必须广播对象更新。

通常，每个工作节点都会给主节点上的系统组件增加一些开销。

据官方统计，Kubernetes声称支持最多5000个节点的集群。

然而，在实践中，500个节点可能已经构成了较大的挑战。

通过使用性能更高的主节点，可以减轻大量工作节点的影响。

这就是在实践中所做的 – 这里是kube-up在云基础架构上使用的主节点大小：

• Google云端平台
  • 5个工作节点→ n1-standard-1主节点
  • 500个工作节点→ n1-standard-32主节点
• 亚马逊网络服务
  • 5个工作节点→ m3.medium主节点
  • 500个工作节点→ c4.8xlarge主节点

如您所见，对于500个工作节点，使用的主节点分别具有32和36个CPU核心以及120 GB和60 GB内存。

这些都是相当大的机器！

因此，如果您打算使用大量小节点，则需要记住两件事：

• 您拥有的工作节点越多，您需要的性能就越高
• 如果您计划使用超过500个节点，则可能会遇到一些需要付出一些努力才能解决的性能瓶颈

像Virtual Kubelet这样的新项目允许绕过这些限制，并允许具有大量工作节点的集群。

2. 更多系统开销

Kubernetes在每个工作节点上运行一组系统守护进程 – 包括容器运行时（例如Docker），kube-proxy和包含cAdvisor的kubelet。

cAdvisor包含在kubelet二进制文件中。

所有这些守护进程一起消耗固定数量的资源。

如果使用许多小节点，则这些系统组件使用的资源部分比例会更大。

例如，假设单个节点的所有系统守护程序一起使用0.1个CPU内核和0.1 GB内存。

如果您拥有10个CPU核心和10 GB内存的单个节点，那么守护程序将占用集群容量的1％。

另一方面，如果您有1个CPU核心和1 GB内存的10个节点，则后台程序将占用集群容量的10％。

因此，在第二种情况下，10％的账单用于运行系统，而在第一种情况下，它只有1％。

因此，如果您希望最大化基础架构支出的回报，那么您可能更喜欢更少的节点。

3. 降低资源利用率

如果您使用较小的节点，那么最终可能会有大量资源片段太小而无法分配给任何工作负载，因此保持未使用状态。

例如，假设您的所有pod都需要0.75 GB的内存。

如果你有10个1 GB内存的节点，那么你可以运行10个这些pod – 你最终会在每个节点上有一块0.25 GB的内存，你不能再使用它了。

这意味着，集群总内存的25％被浪费了。

另一方面，如果您使用具有10 GB内存的单个节点，那么您可以运行13个这样的pod – 而只有0.25 GB的单块内存剩下无法使用。

在这种情况下，您只会浪费2.5％的内存。

因此，如果您想最大限度地减少资源浪费，使用更大的节点可能会提供更好的结果。

4. 小节点上的Pod限制

在某些云基础架构上，小节点上允许的最大pod数量比您预期的要限制得多。

Amazon Elastic Kubernetes Service（EKS）就是这种情况，其中每个节点的最大pod数取决于实例类型。

例如，对于一个t2.medium实例，pod的最大数量是17，因为t2.small它是11，而t2.micro它是4。

这些都是非常小的数字！

任何超出这些限制的pod都无法由Kubernetes调度程序安排，这些pod会一直保持在Pending状态。

如果您不了解这些限制，则可能导致难以发现的错误。

因此，如果您计划在Amazon EKS上使用小节点，请检查相应的每节点pods数，并多算几次计算节点是否可以容纳所有pod。

结论

那么，您应该在集群中使用少量大型节点还是许多小型节点？

一如既往，没有明确的答案。

您要部署到集群的应用程序类型可能会指导您的决策。

例如，如果您的应用程序需要10 GB内存，则可能不应使用小节点 – 集群中的节点应至少具有10 GB内存。

或者，如果您的应用程序需要10倍的复制性以实现高可用性，那么您可能不应该只使用2个节点 – 您的集群应该至少有10个节点。

对于中间的所有场景，它取决于您的具体要求。

以上哪项优缺点与您相关？哪个不是？

话虽如此，没有规则规定所有节点必须具有相同的大小。

没有什么能阻止您在集群中使用不同大小节点混合在一起的方案。

Kubernetes集群的工作节点可以是完全异构的。

这可能会让您权衡两种方法的优缺点。

最后，证明布丁好坏就在于吃 – 最好的方法是试验并找到最适合你的组合！

我的网课“Kubernetes实战：高可用集群搭建、配置、运维与应用”在慕课网上线了，感谢小伙伴们学习支持！

我爱发短信：企业级短信平台定制开发专家 https://tonybai.com/
smspush : 可部署在企业内部的定制化短信平台，三网覆盖，不惧大并发接入，可定制扩展； 短信内容你来定，不再受约束, 接口丰富，支持长短信，签名可选。

著名云主机服务厂商DigitalOcean发布最新的主机计划，入门级Droplet配置升级为：1 core CPU、1G内存、25G高速SSD，价格5$/月。有使用DigitalOcean需求的朋友，可以打开这个链接地址：https://m.do.co/c/bff6eed92687 开启你的DO主机之路。

我的联系方式：

微博：https://weibo.com/bigwhite20xx
微信公众号：iamtonybai
博客：tonybai.com
github: https://github.com/bigwhite

微信赞赏：

商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。

本文翻译自《Boosting your kubectl productivity》。

第一部分：什么是kubectl？
第二部分：命令完成、资源规范快速查看和自定义列输出格式什么是kubectl？

4. 轻松切换集群和名称空间

当kubectl必须向Kubernetes API发出请求时，它会读取系统上所谓的kubeconfig文件，以获取它需要访问的所有连接参数并向API服务器发出请求。

默认的kubeconfig文件是~/.kube/config。此文件通常由某个命令自动创建或更新（例如，aws eks update-kubeconfig或者gcloud container clusters get-credentials，如果您使用托管Kubernetes服务）。

使用多个集群时，您的kubeconfig文件中配置了多个集群的连接参数。这意味着，您需要一种方法来告诉kubectl 您希望它连接到哪个集群。

在集群中，您可以设置多个名称空间（名称空间是物理集群中的一种“虚拟”集群）。Kubectl也会从kubeconfig文件确定用于请求的命名空间。因此，您需要一种方法来告诉kubectl 您希望它使用哪个命名空间。

本节将介绍kubectl切换集群上下文的原理以及它是如何轻松完成的。

请注意，您还可以在KUBECONFIG环境变量中列出多个kubeconfig文件。在这种情况下，所有这些文件将在执行时合并为单个有效配置。您还可以使用–kubeconfig指定kubectl命令的选项以覆盖默认的kubeconfig文件。请参阅官方文档。

Kubeconfig文件

让我们看看kubeconfig文件实际包含的内容：

如您所见，kubeconfig文件由一组上下文组成。上下文包含以下三个元素：

• 集群(cluster)：集群的API服务器的URL
• 用户(user)：集群的特定用户的身份验证凭据
• 命名空间(namespace)：连接到集群时使用的命名空间

实际上，人们经常在他们的kubeconfig文件中为每个集群的配置一个上下文。但是，你也可以为每个集群配置多个上下文，其用户或命名空间不同。但这似乎不太常见，因此通常在集群和上下文之间存在一对一的映射。

在任何给定时间，其中一个上下文被设置为当前上下文（通过kubeconfig文件中的专用字段）：

当kubectl读取kubeconfig文件时，它总是使用当前上下文中的信息。因此，在上面的例子中，kubectl将连接到Hare集群。

因此，要切换到另一个集群，您只需更改kubeconfig文件中的当前上下文：

在上面的示例中，kubectl现在将连接到Fox集群。

要切换到同一集群中的另一个命名空间，您可以更改当前上下文的命名空间元素的值：

在上面的示例中，kubectl现在将使用Fox群集中的Prod命名空间（而不是之前设置的Test命名空间）。

请注意，kubectl还提供了–cluster，–user和–namespace，以及–context允许您覆盖单个元素和当前上下文本身的选项，无论kubeconfig文件中设置了什么。见kubectl options。

理论上，您可以通过手动编辑kubeconfig文件来执行这些更改。但当然这很乏味。以下部分介绍了允许您自动执行这些更改的各种工具。

使用kubectx

kubectx是一种非常流行的用于在集群和命名空间之间切换的工具。

此工具提供允许您分别更改当前上下文和命名空间的命令kubectx和kubens命令。

如上所述，如果每个集群只有一个上下文，则更改当前上下文意味着更改集群。

在这里，您可以看到这两个命令：

在表象之下，这些命令只是编辑kubeconfig文件，如上一节中所述。

要安装kubectx，只需按照GitHub页面上的说明操作即可。

kubectx和kubens都通过完成交办提供命令完成(command completion)。这允许您自动完成上下文名称和名称空间，这样您就不必完全键入它们。您也可以在GitHub页面上找到设置完成的说明。

kubectx的另一个有用功能是交互模式。这与fzf工具结合使用，您必须单独安装（事实上，安装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的交互模式）。这意味着，您需要安装fzf才能使用这些别名。

以下是别名的定义：

# Get current context
alias krc='kubectl config current-context'
# List all contexts
alias klc='kubectl config get-contexts -o name | sed "s/^/  /;\|^  $(krc)$|s/ /*/"'
# Change current context
alias kcc='kubectl config use-context "$(klc | fzf -e | sed "s/^..//")"'

# Get current namespace
alias krn='kubectl config get-contexts --no-headers "$(krc)" | awk "{print \$5}" | sed "s/^$/default/"'
# List all namespaces
alias kln='kubectl get -o name ns | sed "s|^.*/|  |;\|^  $(krn)$|s/ /*/"'
# Change current namespace
alias kcn='kubectl config set-context --current --namespace "$(kln | fzf -e | sed "s/^..//")"'

要安装这些别名，你只需要在上面定义添加到您的~/.bashrc或~/.zshrc文件，并重新加载你的shell(source ~/.bashrc or source ~/.zshrc)！

使用插件

Kubectl允许安装可以像本机命令一样调用的插件。例如，您可以安装名为kubectl-foo的插件，然后将其调用为kubectl foo。

Kubectl插件将在本文的后续部分中详细介绍。

能够像这样更改当前上下文和命名空间不是很好吗？例如，运行kubectl ctx以更改上下文，kubectl ns更改名称空间？

我创建了两个允许这样做的插件：

• kubectl-CTX
• kubectl-NS

在内部，插件构建在上一节的别名之上。

在这里你可以看到插件的实际效果：

请注意，插件使用fzf来提供交互式模糊搜索界面。这意味着，您需要安装fzf才能使用这些插件。

要安装插件，你只需要将名为的shell脚本kubectl-ctx和kubectl-ns的脚本下载以到PATH下的任何目录中，并使他们具备可执行权限（例如，使用chmod +x）。紧接着，你就应该能够使用kubectl ctx和kubectl ns！

5. 使用自动生成的别名减少输入

Shell别名通常是减少手工输入的好方法。该kubectl-aliases项目就是以这个想法为核心，并提供800多个kubectl命令别名。

您可能想知道如何记住800个别名？实际上，您不需要记住它们，因为它们都是根据一个简单的方案生成的，下面将显示一些示例别名：

如您所见，别名由组件(component)组成，每个组件代表kubectl命令的特定元素。每个别名可以有一个用于基本命令，操作和资源的组件，以及用于选项的多个组件，您只需根据上述方案从左到右“填充”这些组件。

请注意，目前完全详细的方案在GitHub页面上。在那里，您还可以找到别名的完整列表。

例如，别名kgpooyamlall代表命令kubectl get pods -o yaml –all-namespaces：

请注意，大多数选项组件的相对顺序无关紧要。所以，kgpooyamlall相当于kgpoalloyaml。

您不需要将所有组件用于别名。例如k，kg，klo，ksys，或者kgpo是有效的别名也。此外，您可以在命令行中将别名与其他单词组合使用。

例如，您可以k proxy用于运行kubectl proxy：

或者您可以kg roles用于运行kubectl get roles（目前不存在Roles资源的别名组件）：

要获取特定Pod，您可以使用kgpo my-pod以运行kubectl get pod my-pod：

请注意，某些别名甚至需要在命令行上的进一步参数。例如，kgpol别名代表kubectl get pods -l。该-l选项需要一个参数（标签规范）。所以，你必须使用这个别名，例如，像这样:

出于这个原因，你可以使用a，f以及l只在一个别名的结尾部分。

一般来说，一旦你掌握了这个方案，就可以直观地从你想要执行的命令中推断出别名，并节省大量的输入！

安装

要安装kubectl-别名，你只需要下载.kubectl-aliasesGitHub文件，并在你的~/.bashrc或~/.zshrc文件生效它：

source ~/.kubectl_aliases

重新加载shell后，您应该能够使用所有800个kubectl别名！

命令完成

如您所见，您经常在命令行上向别名添加更多单词。例如：

$kgpooyaml test-pod-d4b77b989

如果你使用kubectl命令完成，那么你可能习惯于自动完成资源名称之类的事情。但是当你使用别名时，你还可以这样做吗？

这是一个重要的问题，因为如果它不起作用，那将消除这些别名的一些好处！

答案取决于您使用的shell。

对于Zsh，完成对于别名是开箱即用的。

不幸的是，对于Bash，默认情况下，对于别名，完成功能不起作用。好消息是它可以通过一些额外的步骤来完成。下一节将介绍如何执行此操作。

在Bash中启用别名的完成

Bash的问题在于它尝试在别名上尝试完成（每当你按Tab键），而不是在别名命令（如Zsh）上。由于您没有所有800个别名的完成脚本，因此不起作用。

complete-alias项目提供了解决这个问题的通用解决方案。它使用别名的完成机制，在内部将别名扩展到别名命令，并返回扩展命令的完成建议。这意味着，它使别名的完成行为与别名命令完全相同。

在下文中，我将首先解释如何安装complete-alias，然后如何配置它以启用所有kubectl别名的完成。

安装complete-alias

首先，complete-alias依赖于bash-completion。因此，您需要确保在安装complete-alias之前安装了bash-completion。早先已经为Linux和macOS提供了相关说明。

对于macOS用户的重要注意事项：与kubectl完成脚本一样，complete-alias不适用于Bash 3.2，这是macOS上Bash的默认版本。特别是，complete-alias依赖于bash-completion v2（brew install bash-completion@2），它至少需要Bash 4.1。这意味着，要在macOS上使用complete-alias，您需要安装较新版本的Bash。

要安装complete-alias，您只需bash_completion.sh从GitHub存储库下载脚本，并将其在您的~/.bashrc文件中source：

source ~/bash_completion.sh

重新加载shell后，应正确安装complete-alias。

启用kubectl别名的完成

从技术上讲，complete-alias提供了_complete_aliasshell函数。此函数检查别名并返回别名命令的完成建议。

要将其与特定别名挂钩，您必须使用completeBash内置来设置别名_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

从版本1.12开始，kubectl包含一个插件机制，允许您使用自定义命令扩展kubectl。

以下是kubectl插件的示例，可以调用为kubectl hello：

$ kubectl hello
Hello, I'm a kubectl plugin!

kubectl插件机制将严格遵循Git插件机制的设计。

本节将向您展示如何安装插件，您可以在哪里找到现有的插件，以及如何创建自己的插件。

安装插件

Kubectl插件作为简单的可执行文件分发，其名称的形式为kubectl-x。前缀kubectl-是必需的，接下来是允许调用插件的新kubectl子命令。

例如，上面显示的hello插件将作为名为的文件分发kubectl-hello。

要安装插件，您只需将kubectl-x文件复制到您的任何目录中PATH并使其可执行（例如，使用chmod +x）。之后，您可以立即调用该插件kubectl x。

您可以使用以下命令列出系统上当前安装的所有插件：

$kubectl plugin list

如果您有多个具有相同名称的插件，或者存在不可执行的插件文件，则此命令还会显示警告。

使用krew查找和安装插件

Kubectl插件可以像软件包一样共享和重用。但是在哪里可以找到其他人共享的插件？

该krew项目旨在提供一个统一的解决方案，共享，查找，安装和管理kubectl插件。该项目将自己称为“kubectl插件的包管理器”（名称krew是brew的提示）。

Krew 以kubectl插件索引为中心，您可以从中选择和安装。

$ kubectl krew search | less
$ kubectl krew search view
$ kubectl krew info view-utilization
$ kubectl krew install view-utilization
$ kubectl krew list

如您所见，krew本身是一个kubectl插件。这意味着，安装krew本质上就像安装任何其他kubectl插件一样。您可以在GitHub页面上找到krew的详细安装说明。

最重要的krew命令如下：

# Search the krew index (with an optional search query)
$ kubectl krew search [<query>]
# Display information about a plugin
$ kubectl krew info <plugin>
# Install a plugin
$ kubectl krew install <plugin>
# Upgrade all plugins to the newest versions
$ kubectl krew upgrade
# List all plugins that have been installed with krew
$ kubectl krew list
# Uninstall a plugin
$ kubectl krew remove <plugin>

请注意，使用krew安装插件并不妨碍以传统方式安装插件。即使你使用krew，你仍然可以通过其他方式安装你在其他地方找到的插件（或自己创建）。

请注意，该kubectl krew list命令仅列出已使用krew安装的插件，而该kubectl plugin list命令列出了所有插件，即使用krew安装的插件和以其他方式安装的插件。

在其他地方寻找插件

Krew仍然是一个年轻的项目，目前krew索引中只有大约30个插件。如果你在那里找不到你需要的东西，你可以在其他地方寻找插件，例如，在GitHub上。

我建议查看kubectl-plugins GitHub主题。你会发现有几十个可用的插件值得一看。

创建自己的插件

当然，您可以创建自己的kubectl插件，这很容易实现。

您只需创建一个可执行文件，执行您想要的操作，为其命名kubectl-x，然后按上述方法安装它。

可执行文件可以是任何类型，Bash脚本，编译的Go程序，Python脚本，它确实无关紧要。唯一的要求是它可以由操作系统直接执行。

我们现在创建一个示例插件。在上部分中，您使用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。但是，您可以使用实际编程语言编写更复杂的插件，例如，使用Kubernetes客户端库。如果使用Go，您还可以使用cli-runtime库，它专门用于编写kubectl插件。

分享你的插件

如果您认为其中一个插件可能对其他人有用，请随时在GitHub上分享。确保将其添加到kubectl-plugins主题中，以便其他人可以找到它。

您还可以请求将您的插件添加到krew索引中。您可以在krew GitHub存储库中找到有关如何执行此操作的说明。

命令完成

目前，插件机制遗憾的是还不支持命令完成。这意味着您需要完全键入插件名称以及插件的任何参数。

但是，在kubectl GitHub存储库中有一个处于open状态的功能请求issue。因此，此功能有可能在将来的某个时间得到实现。

以上就是有关kubectl高效使用的所有内容了！

我的网课“Kubernetes实战：高可用集群搭建、配置、运维与应用”在慕课网上线了，感谢小伙伴们学习支持！

我爱发短信：企业级短信平台定制开发专家 https://tonybai.com/
smspush : 可部署在企业内部的定制化短信平台，三网覆盖，不惧大并发接入，可定制扩展； 短信内容你来定，不再受约束, 接口丰富，支持长短信，签名可选。

著名云主机服务厂商DigitalOcean发布最新的主机计划，入门级Droplet配置升级为：1 core CPU、1G内存、25G高速SSD，价格5$/月。有使用DigitalOcean需求的朋友，可以打开这个链接地址：https://m.do.co/c/bff6eed92687 开启你的DO主机之路。

我的联系方式：

微博：https://weibo.com/bigwhite20xx
微信公众号：iamtonybai
博客：tonybai.com
github: https://github.com/bigwhite

微信赞赏：

商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。