SSH vs.Kubectl exec-kubectl exec

本文转载自微信公众号「新钛云服」，作者祝祥翻译。转载本文请联系新钛云服公众号。

让我们看一下打开远程shell的两种流行方法：ssh与kubectl exec。

下面，我们将只看“ kubectl exec”子命令及相关的命令。kubectl本身就是所有Kubernetes的瑞士军刀。。将所有这些与ssh进行比较就像将systemd与BSD init进行比较一样。

另外，我将使用“SSH”来表示“OpenSSH”，这是SSH协议实现的事实标准。但大多数讨论要点都适用于任何SSH实现。

Apples to Oranges

乍一看，这是一个奇怪的比较。

OpenSSH已经存在了二十年，远远早于云技术的诞生。它的设计是假设您要管理几台服务器，并正在仔细配置和调整它们的各个方面。SSH也已被用作SFTP和Ansible之类的传输层协议。

另一方面，kubectl诞生于云时代。它处理成千上万的远程机器(或容器)。kubectl exec只是其中的一小部分，用于在出现问题时进行调试。

但是，如果您如果仔细观则会发现：kubectl exec与ssh目的相同。它可以在远程计算机上运行程序，而不会给您本地终端带来麻烦，并尝试与各种终端功能集成在一起，从而使您感觉好像已将键盘和显示器插入了数据中心机架。

顺便说一句，让我们深入探讨它们的异同。

Authn/z

让我们从每个人最喜欢的主题开始：安全性。

TL; DR：SSH身份验证非常容易定制，但是大规模管理很麻烦。kubectl处理授权要好得多，但是身份验证通常是不透明的，很难调整。

注意：这里我们不会讨论身份验证方法的优缺点，这是另外一个话题，我们下次再讨论。

SSH协议

SSH支持多种身份验证选项：

基本密码
非对称加密密钥
- 以明文形式在磁盘上
- 在使用密码加密的磁盘上
- 使用硬件令牌(例如YubiKey)
证书(但不是X.509类型)链接到专用CA
- 上面有用于存储私钥的所有选项
通过GSS AP或PAM的可插拔外部身份验证
- 例如Active Directory，LDAP，OIDC等
2FA
基于本地的硬件令牌
- 或通过PAM使用TOTP(例如Google Authenticator)或Duo等进行关联

要对服务器进行身份验证，您可以获得非对称公钥或证书。默认情况下，SSH使用首次使用信任(TOFU)，因此作为预防措施，您可能希望在客户端计算机上管理?/.ssh/known_hosts。

作为用户，您可以选择所需的身份验证方法以及如何在两侧进行配置!

当涉及授权时，情况并不理想。授权粒度基本上是：“ 用户X可以登录到服务器Y ”，没有分组。您必须通过将用户的公共密钥写入?/.ssh/authorized_keys并为其创建本地UNIX用户，来配置用户可能分别登录的每个服务器。将CA与SSH证书一起使用可以帮助分发密钥。PAM管道也可以为您创建用户。无论如何，这将需要一些额外工作。

幸运的是，如果您愿意扩展工具，可以使用更高级别的软件来解决这些问题。

Kubectl

大多数时候，大家都会认为kubeconfig管理kubernetns中的所有凭证。当使用托管的Kubernetes平台，您甚至可能不会注意到平台后台会自动生成它。很少有人会直接修改kubeconfig内容，大多数情况下，您将使用云或身份验证提供程序生成的内容。

这是一个不错的用户体验，但下面有一些常见的问题点：

HTTP基本身份验证(用户名+密码为纯文本)
TLS客户端证书(磁盘上的私钥以纯文本格式)
不透明的令牌(在磁盘上以纯文本格式)
云提供商插件
- 这些被编译成 kubectl code itself
- 慢慢地逐步淘汰以减少Kubernetes代码依赖性
Exec插件
- 在每个请求上，执行一个外部二进制文件以获取承载令牌或TLS客户端密钥/证书
- 由云提供商使用，以与其定制的身份验证系统集成
- 如果您想要2FA，这可能是可行的方法

服务器使用TLS进行身份验证，通常在kubeconfig中嵌入一个私有CA。

这里的授权比SSH好得多!这里没有类似SSH的(例如每个pod)设计，因为Kubernetes pod是短暂的非持久的。

Kubernetes通过RBAC本地处理授权。所有kubectl exec请求都通过Kubernetes API服务器进行传输，该服务器执行RBAC规则。它需要一些学习，从Internet复制粘贴的YAML并对其进行调整。但是，当您完成操作后，您可以说：“ 项目中的每个人都可以登录到默认的namespace(名称空间)，但是只有核心人员可以管理生产namespace(名称空间)* ”。

“最难”的部分是确保每个员工都拥有一个kubeconfig与您的RBAC规则相匹配的正确身份。幸运的是，SSO集成在大多数托管平台上都相当不错。

Shell UX

这个其实很接近。SSH和kubectl都处理终端颜色、转义代码、交互命令甚至窗口大小调整事件。SSH和kubectl在99%的CLI应用程序中应该都能很好地工作。

SSH确实增加了一些比较好的功能：

环境变量定制
- kubectl总是在启动时设置提供给容器的环境变量
- ssh主要依赖于系统登录shell的程序配置(但也可以通过PermitUserEnvironment或SendEnv/AcceptEnv接受用户的环境)
转义序列(不要与ANSI转义代码混淆)
- 超级方便，可以关闭挂起的SSH会话，而不必等待超时触发
下次使用ssh时可以尝试输入“～?”

Non-shell features

文件传输

ssh和kubectl都支持在您和服务器之间传输文件。

SSH协议

SSH有多种工具可以将其作为传输工具使用：

有内置的SCP和更新一点的SFTP
尽管需要独立安装，但还有一个更好的rsync工具
您甚至可以使用一些管道符进行文件的传输

KUBECTL

kubectl cp命令可以复制文件，但基本上是kubectl exec + tar的简单封装。而且，如果您要处理的容器尚未包含tar命令的话，那么就会很遗憾。

您可以使用挂载volume的方式去实现传输文件，但这在创建Pod时需要提前计划好，非常不方便。

Port forwarding

SSH协议

SSH具有非常灵活的端口转发支持：
本地端口转发(本地端口->服务器->任何位置)ssh -L 8080:example.com:80 server
远程端口转发(任何地方->服务器端口->本地端口)ssh -R 80:localhost:8080 server

动态端口转发(通过SOCKS5)ssh -D 1080 server

您可以通过它去实现各种转发需求!当然也可以在生产环境中留下后门...

KUBECTL

kubectl port-forward使您可以通过本地端口通信到Pod上的远程端口。这是SSH本地端口转发所不能实现的部分。

Jump hosts

SSH协议

使用SSH时，通常会设置跳转主机(也称为堡垒机)，通过对堡垒机权限的控制而实现访问的控制。

您确实需要手动设置它，适当地配置客户机和服务器，还需要考虑在该机上使用多租户。它会成为维护的负担。

KUBECTL

在Kubernetes中，API服务器实际上是您的“跳转主机”。

X11 forwarding

使用SSH，您可以图形化的管理远程应用程序：

user@local $ ssh -X server 
user@server % firefox

它就像一个远程桌面，但是您在服务器上启动的应用程序自然会融合到本地桌面中，而不是拥有嵌套的桌面。

性能

从用户角度来看，SSH和kubectl的性能都很好。您可能会感觉到一些卡顿，尤其是在网络不稳定的情况下，但是两者之间的速度都明显慢。

但是我仍然想获得一些实际参考数据，因此让我们运行一些人为的基准测试!

TL; DR：kubectl exec在建立连接时速度更快，但是SSH在发送/接收会话数据时速度更快。

以下结果并不准确，但仍代表了实际使用情况：在有无线网络连接的笔记本电脑上进行测试。

客户端是OpenSSH v8.3和kubectl v1.18。在Kubernetes方面，我使用的是一个基于busybox创建的简单容器kubectl run -it busybox --image=busybox。

本地服务器是OpenSSH v8.3和运行Kubernetes v1.18的minikube。

远程服务器是OpenSSH v8.2和GKE v1.14(相当老，是的)。两者都在同一区域的GCP上运行。

Login/setup latency

首先，让我们衡量一下建立会话所需的时间。

在这两种情况下，我将远程运行echo foo 100次，并使用hyperfine测量计时。结果测量了建立连接、执行authn/z、打开远程shell然后断开连接所需的时间。实际的echo command耗时<1ms，不应影响结果。

本地

$ hyperfine 'ssh localhost echo foo' 'kubectl exec -it busybox echo foo' -r 100 
Benchmark #1: ssh localhost echo foo 
  Time (mean ± σ):  156.2 ms ±  15.9 ms [User: 14.0 ms, System: 2.1 ms] 
  Range (min … max): 112.4 ms … 220.9 ms 100 runs 
 
 
Benchmark #2: kubectl exec -it busybox echo foo 
  Time (mean ± σ):  113.9 ms ±  16.1 ms [User: 72.4 ms, System: 12.7 ms] 
  Range (min … max): 95.8 ms … 157.2 ms 100 runs 
 
 
Summary 
  'kubectl exec -it busybox echo foo' ran 
 1.37 ± 0.24 times faster than 'ssh localhost echo foo'

kubectl 最快，快37%!

远程

如果我们把网络加入其中呢?

$ hyperfine 'ssh ubuntu echo foo' 'kubectl exec -it busybox echo foo' -r 100 
Benchmark #1: ssh ubuntu echo foo 
  Time (mean ± σ):  689.1 ms ±  42.6 ms [User: 41.1 ms, System: 6.1 ms] 
  Range (min … max): 653.6 ms … 1022.0 ms 100 runs 
 
 
Benchmark #2: kubectl exec -it busybox echo foo 
  Time (mean ± σ):  445.7 ms ±  45.3 ms [User: 130.1 ms, System: 31.2 ms] 
  Range (min … max): 372.3 ms … 655.2 ms 100 runs 
 
 
Summary 
  'kubectl exec -it busybox echo foo' ran 
 1.55 ± 0.18 times faster than 'ssh ubuntu echo foo'

再一次kubectl获得最佳：速度提高55%!

吞吐量

原始数据吞吐量如何?

我将通过OpenSSH发送约32MB的数据，并在远端将其回显。

本地

$ hyperfine 'find . -type f | xargs cat | ssh localhost cat' 'find . -type f | xargs cat | kubectl exec -it busybox cat' -r 10 
Benchmark #1: find . -type f | xargs cat | ssh localhost cat 
  Time (mean ± σ):   5.457 s ±  0.167 s [User: 4.464 s, System: 1.259 s] 
  Range (min … max): 5.202 s …  5.657 s 10 runs 
 
 
Benchmark #2: find . -type f | xargs cat | kubectl exec -it busybox cat 
  Time (mean ± σ):  27.628 s ±  1.725 s [User: 9.920 s, System: 7.203 s] 
  Range (min … max): 25.044 s … 30.926 s 10 runs 
 
 
Summary 
  'find . -type f | xargs cat | ssh localhost cat' ran 
 5.06 ± 0.35 times faster than 'find . -type f | xargs cat | kubectl exec -it busybox cat'

好吧，这很有趣。SSH通过发送数据的速度快约5倍!

SSH需要大约5.45s，大约6000 KB/s。

kubectl 大约需要27.62s，大约1200 KB/s。

远程

$ hyperfine 'find . -type f | xargs cat | ssh ubuntu cat' 'find . -type f | xargs cat | kubectl exec -it busybox cat' -r 10 
Benchmark #1: find . -type f | xargs cat | ssh ubuntu cat 
  Time (mean ± σ):  28.794 s ±  0.627 s [User: 10.525 s, System: 5.018 s] 
  Range (min … max): 27.788 s … 29.921 s 10 runs 
 
 
Benchmark #2: find . -type f | xargs cat | kubectl exec -it busybox cat 
  Time (mean ± σ):  33.299 s ±  2.679 s [User: 10.831 s, System: 8.902 s] 
  Range (min … max): 30.964 s … 40.292 s 10 runs 
 
 
Summary 
  'find . -type f | xargs cat | ssh ubuntu cat' ran 
 1.16 ± 0.10 times faster than 'find . -type f | xargs cat | kubectl exec -it busybox cat'

SSH仍然更快，但仅提高了约16%。

结论

SSH和kubectl之间有很多相似之处，它们都有各自的优点和缺点。虽然SSH在架构上是一成不变的，但是在管理一些机器时，高级软件可以从Kubernetes那里学到一些关于集中配置的东西。SSH还可以借用kubeconfig中的凭证管理方法(即“将所有客户机凭据和服务器信息放入一个可以复制的文件中”)。

kubectl可以改善其no-shell功能，例如端口转发和文件传输。它原始数据吞吐量也不足，这使其无法成为像SSH这样的传输层协议。实际上，这些工具是互补的，可以用于不同的任务，而不是仅仅使用其中一个。希望这篇文章对您有所帮助!

原文：https://gravitational.com/blog/ssh-vs-kubectl/