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

如果您使用Kubernetes，那么kubectl可能是您最常用的工具之一。每当您花费大量时间使用某种特定工具时，值得深入了解并了解如何有效地使用它。

本文包含一系列提示和技巧，使您对kubectl的使用更加高效和有效。同时，它旨在加深您对Kubernetes各方面工作的理解。

本文的目标是让您在Kubernetes的日常工作更高效、更愉快！

简介：什么是kubectl？

在学习如何更有效地使用kubectl之前，您应该基本了解它是什么以及它是如何工作的。

从用户的角度来看，kubectl是控制Kubernetes的驾驶舱。它允许您执行所有可能的Kubernetes操作。

从技术角度来看，kubectl是Kubernetes API的客户端。

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

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

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

让我们考虑一个例子。

想象一下，您想要创建ReplicaSet资源。为此，您需要在名为replicaset.yaml file 的文件中定义ReplicaSet ，然后运行以下命令：

kubectl create -f replicaset.yaml

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

Kubernetes具有创建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的内部结构。

Kubernetes内部

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

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

• 存储后端：存储资源定义（通常使用etcd）
• API服务器：提供Kubernetes API并管理存储后端
• 控制器管理器：确保资源状态符合规范
• 调度程序：将Pod调度到工作节点

这是工作节点上最重要的组件：

• Kubelet：负责管理工作节点上的容器执行

为了了解这些组件如何协同工作，让我们考虑一个例子。

假设您刚刚执行kubectl create -f replicaset.yaml。kubectl向创建ReplicaSet API端点发送HTTP POST请求（传递ReplicaSet资源定义）。

集群中有什么影响？观看以下内容：

图：执行kubectl create -f replicaset.yaml，API服务器将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定义。

请注意，到目前为止，集群中的任何位置都没有运行工作负载代码。到目前为止所做的就是在主节点上的存储后端创建和更新资源。

此事件触发监视调度到其工作节点的Pod的kubelet。已安排ReplicaSet Pods的工作节点的kubelet指示已配置的容器运行时（可能是Docker）下载所需的容器映像并运行容器。

此时，最后，您的ReplicaSet应用程序正在运行！

Kubernetes API的作用

从上面的示例中可以看出，Kubernetes组件（API服务器和存储后端除外）通过监视存储后端中的资源更改和操作存储后端中的资源来工作。

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

请考虑以下示例：

• ReplicaSet控制器使用列表ReplicaSets API端点 API操作以及watch用于监视ReplicaSet资源更改的参数。
• ReplicaSet控制器使用create Pod API端点来创建Pod。
• 调度程序使用修补程序Pod API端点来更新Pod，其中包含有关所选工作节点的信息。

如您所见，这与kubectl也使用的API相同。

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

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

• 存储后端存储Kubernetes的状态（即资源）。
• API服务器以Kubernetes API的形式提供存储后端的接口。
• 所有其他Kubernetes组件和用户通过Kubernetes API读取，观察和操纵Kubernetes的状态（即资源）。

熟悉这些概念将有助于您更好地理解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

微信赞赏：

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

本文翻译自Alexis Ducastel的文章《Benchmark results of Kubernetes network plugins (CNI) over 10Gbit/s network (Updated: April 2019)》。

本文是我之前的基准测试的最新更新，这次测试在最新版Kubernetes 1.14上运行，其中CNI版本在2019年4月更新。

首先，非常感谢Cilium团队对我的帮助，包括协助审查测试结果以及更正我的指标监控脚本。

自2018年11月以来都有哪些新变化

如果你只是想知道自上次以来发生的变化，这里有一个简短的总结：

Flannel仍然是CNI竞赛中最快和最精简的那个选手，但它仍然不支持NetworkPolicies(网络策略)，也不支持加密。

Romana不再维护，因此我们决定将其从基准测试中剔除。

WeaveNet现在同时支持Ingress和Egress的NetworkPolicies！但性能要略低于之前的版本。

如果您想获得最佳性能，Calico仍需要手动定制MTU。Calico为安装CNI提供了两个新选项，无需专用ETCD存储：

• 将状态存储在Kubernetes API中作为数据存储区（集群<50个节点）
• 使用Typha代理将状态存储在Kubernetes API中，以减轻K8S API（集群> 50个节点）的压力

Calico宣布在Istio之上支持应用层策略(Application Layer Policy)，为应用层带来安全性。

Cilium现在支持加密！Cilium使用IPSec隧道提供加密，并为WeaveNet提供了加密网络的替代方案。但是，在启用加密的情况下，WeaveNet比Cilium更快。这是由于Cilium 1.4.2仅支持CBC加密，若使用GCM将会更好，但它将是1.5版本的Cilium的一部分。

由于嵌入了ETCD operator，因此Cilium现在更容易部署。

Cilium团队还通过降低内存消耗和CPU成本，努力减少CNI占用空间。但他们仍然比其他选手更重。

基准测试的上下文

基准测试是在通过Supermicro 10Gbit交换机连接的三台Supermicro裸机服务器上进行的。服务器通过DAC SFP +无源电缆直接连接到交换机，并在激活巨型帧（MTU 9000）的同一VLAN中设置。

Kubernetes 1.14.0​在Ubuntu 18.04 LTS上运行，运行Docker 18.09.2（此linux版本中的默认docker版本）。

为了提高可重复性，我们选择始终在第一个节点上设置master，在第二个服务器上设置基准测试的服务器部分，在第三个服务器上设置客户端部分。这是通过Kubernetes deployments中的NodeSelector实现的。

以下是我们将用于描述基准测试结果和解释的表情图：

为基准测试选择CNI

这个基准测试仅仅关注那些入选kubernetes正式文档：“create a single master cluster with kubeadm”中的CNI列表。在提到的9个CNI中，我们只测试其中的6个，不包括那些我们无法轻松安装和/或不通过以下文档开箱即用的工具（Romana，Contiv-VPP和JuniperContrail / TungstenFabric）

以下是我们将要比较的CNI列表：

• Calico v3.6
• Canal v3.6（事实上，Flannel用于网络+ Calico用于防火墙）
• Cilium 1.4.2
• Flannel 0.11.0
• Kube-router 0.2.5
• WeaveNet 2.5.1

安装

CNI越容易设置，我们对其第一印象就越好。所有参与基准测试的CNI都很容易设置（一个或两个命令行）。

如前所述，服务器和交换机都配置了Jumbo帧激活（通过将MTU设置为9000）。我们非常感谢CNI可以自动发现要使用的MTU，具体取决于适配器。事实上，Cilium和Flannel是唯一能够正确自动检测MTU的选手。大多数其他CNI在GitHub中引发了启用MTU自动检测的问题，但是现在，我们需要通过修改Calico，Canal和Kube-router的ConfigMap或WeaveNet的ENV var来手动修复它。

也许您想知道错误的MTU会产生什么影响？这里有一个图表，显示WeaveNet与默认MTU和WeaveNet与Jumbo帧之间的区别：

那么，既然我们知道MTU对性能非常重要，那么这些CNI如何自动检测MTU：

正如我们在上图中看到的，我们必须对Calico，Canal，Kube-router和WeaveNet应用一些MTU调整以获得最佳性能。Cilium和Flannel能够自行正确地自动检测MTU，确保开箱即用的最佳性能。

安全

在比较这些CNI的安全性时，我们谈论两件事：它们加密通信的能力，以及它们对Kubernetes网络策略的实现（根据实际测试，而不是来自他们的文档）。

只有两个CNI可以实现加密通信：Cilium和WeaveNet。通过将加密密码设置为CNI的ENV变量可以来启用WeaveNet加密。WeaveNet文档有点令人困惑，但这很容易做到。Cilium加密是通过创建Kubernetes Secrets和daemonSet修改的命令设置的（比WeaveNet复杂一点，但是Cilium有很棒的文档记录了它）。

在网络策略实现方面，通过实施Ingress和Egress规则，Calico，Canal，Cilium和WeaveNet是最好的控制面板。Kube-router实际上只实现了Ingress规则。

Flannel没有实现网络策略。

以下是结果摘要：

性能

该基准测试显示每次测试的三次运行（至少）的平均带宽。我们正在测试TCP和UDP性能（使用iperf3），真实应用程序，如HTTP（使用Nginx和curl），或FTP（使用vsftpd和curl），最后是使用SCP协议进行应用程序加密的行为（使用OpenSSH服务器和客户端）。

对于所有测试，我们还在裸机节点（绿色条）上运行基准测试，以比较CNI与本机网络性能的有效性。为了与我们的基准比例保持一致，我们在图表上使用以下颜色：

• 黄色=非常好
• 橙色=好
• 蓝色=一般
• 红色=差

因为我们不关注错误配置的CNI的性能，所以我们只会显示MTU调整的CNI基准测试结果。（NOTA BENE：如果激活加密，Cilium无法正确计算MTU，因此您必须在v1.4中手动将MTU降低到8900.下一版1.5将自动适应。）

结果如下：

每个CNI都在TCP基准测试中表现良好。由于加密成本，启用加密的CNI远远落后于其他CNI。

同样，在UDP基准测试中，所有CNI都表现良好。加密的CNI现在彼此非常接近。Cilium落后于其竞争对手，但事实上，它仅略高于裸机结果的2,3％，这是公平的。我们应该记住的是，Cilium和Flannel都是唯一能够正确自动检测MTU的CNI，从而提供了开箱即用的结果。

真实世界的应用程序怎么样？使用HTTP基准测试，我们可以看到全局性能略低于TCP测试。即使HTTP支持TCP，在TCP基准测试中，iperf3配置为避免任何“TCP慢启动”副作用，这可以有效地影响HTTP基准测试。这里的每个选手的表现都相当不错，Kube-router有明显的优势，WeaveNet在这项测试中表现非常糟糕，比裸机少了约20％。Cilium加密和WeaveNet加密现在都远远落后于裸机性能。

使用FTP，另一个TCP支持的协议，结果更加复杂。虽然Flannel和Kube-router的表现非常好，但是Calico，Canal和Cilium稍稍落后，在裸机速度下约为10％。WeaveNet与裸机性能相差甚远，差距为17>％。无论如何，WeaveNet的加密版本比Cilium加密的性能高出约40％。

通过SCP，我们可以清楚地看到SSH协议的加密成本。大多数CNI表现良好，但WeaveNet再次落后于其他人。当然，由于双重加密成本（SSH加密+ CNI加密）。

以下是性能摘要总结：

资源消耗

现在让我们比较这些CNI在负载很重的情况下处理所带来的资源消耗如何（在TCP 10Gbit传输期间）。在性能测试中，我们将CNI与裸金属（绿色条）进行比较。对于资源消耗测试，我们还显示了没有任何CNI设置的新闲置Kubernetes（紫色条）的消耗。然后我们可以计算出CNI真正消耗的开销。

让我们从内存方面开始吧。以下是传输期间以MB为单位的平均节点RAM使用率（无缓冲区/缓存）。

Flannel和Kube-router表现非常好，只有大约50MB的内存占用，其次是Calico和Canal，70MB。WeaveNet的消费量明显高于其竞争对手，资源占用约为130MB。凭借400MB的内存占用，Cilium具有最高的基准内存消耗。

现在，让我们检查CPU消耗。警告：图形单位不是百分比，而是permil。因此裸金属的38 permil实际上是3.8％。结果如下：

Calico，Canal，Flannel和Kube-router都非常高效的CPU使用，与没有CNI的kubernetes相比，开销仅多出2％。远远落后于WeaveNet，开销约为5％，然后是Cilium，CPU开销超过7％。

以下是资源消耗的摘要：

摘要

以下是所有结果的汇总概述：

结论

最后一部分是主观的，并传达了我自己对结果的解释。请记住，此基准测试仅在一个非常小的集群（3个节点）上测试单个连接中的吞吐速度。它不反映大型集群（> 50个节点）的网络行为，也没有多少连接并发。

如果你在相应的场景中，我建议使用以下CNI：

• 您的群集中有低资源节点（只有几GB的RAM，几个核心）并且您不需要安全功能，请使用Flannel。它是我们测试过的最精简的CNI之一。此外，它与大量架构兼容（amd64，arm，arm64等）。它是唯一一个能够正确自动检测MTU的CNI，和Cilium一起，因此您无需配置任何内容即可使其正常工作。Kube-router也很好，但标准较低，需要您手动设置MTU。
• 出于安全原因，您需要加密网络，请使用WeaveNet。如果您使用巨型帧并通过在环境变量中提供密码来激活加密，请不要忘记设置MTU大小。但话说回过来，忘掉性能，这就是加密的代价。
• 对于其他常见用法，我会推荐Calico。这种CNI广泛用于许多kubernetes部署工具（Kops，Kubespray，Rancher等）。就像WeaveNet一样，如果您使用的是巨型帧，请不要忘记在ConfigMap中设置MTU。事实证明，它在资源消耗，性能和安全性方面具有多用途和高效性。

最后但并非最不重要的，我建议你关注Cilium的工作。他们的团队非常活跃，他们正在努力提高他们的CNI（功能，资源节约，性能，安全性，多集群跨越……），他们的路线图听起来非常有趣。

我的网课“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

微信赞赏：

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