本文转载自微信公众号「新钛云服」，作者祝祥 翻译 。转载本文请联系新钛云服公众号。
让我们看一下打开远程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/
