本文转载自微信公众号「新钛云服」，作者祝祥 翻译 。转载本文请联系新钛云服公众号。
让我们看一下打开远程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等进行关联
作为用户，您可以选择所需的身份验证方法以及如何在两侧进行配置!
当涉及授权时，情况并不理想。授权粒度基本上是：“ 用户X可以登录到服务器Y ”，没有分组。您必须通过将用户的公共密钥写入?/.ssh/authorized_keys并为其创建本地UNIX用户，来配置用户可能分别登录的每个服务器。将CA与SSH证书一起使用可以帮助分发密钥。PAM管道也可以为您创建用户。无论如何，这将需要一些额外工作。
幸运的是，如果您愿意扩展工具，可以使用更高级别的软件来解决这些问题。
Kubectl
大多数时候，大家都会认为kubeconfig管理kubernetns中的所有凭证。当使用托管的Kubernetes平台，您甚至可能不会注意到平台后台会自动生成它。很少有人会直接修改kubeconfig内容，大多数情况下，您将使用云或身份验证提供程序生成的内容。
这是一个不错的用户体验，但下面有一些常见的问题点：
- HTTP基本身份验证(用户名+密码为纯文本)
- TLS客户端证书(磁盘上的私钥以纯文本格式)
- 不透明的令牌(在磁盘上以纯文本格式)
- 云提供商插件
- 这些被编译成 kubectl code itself
- 慢慢地逐步淘汰以减少Kubernetes代码依赖性
- Exec插件
- 在每个请求上，执行一个外部二进制文件以获取承载令牌或TLS客户端密钥/证书
- 由云提供商使用，以与其定制的身份验证系统集成
- 如果您想要2FA，这可能是可行的方法
这里的授权比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时可以尝试输入“～?”
文件传输
ssh和kubectl都支持在您和服务器之间传输文件。
SSH协议
SSH有多种工具可以将其作为传输工具使用：
- 有内置的SCP和更新一点的SFTP
- 尽管需要独立安装，但还有一个更好的rsync工具
- 您甚至可以使用一些管道符进行文件的传输
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
您可以通过它去实现各种转发需求!当然也可以在生产环境中留下后门...
KUBECTL
kubectl port-forward使您可以通过本地端口通信到Pod上的远程端口。这是SSH本地端口转发所不能实现的部分。
Jump hosts
SSH协议
使用SSH时，通常会设置跳转主机(也称为堡垒机)，通过对堡垒机权限的控制而实现访问的控制。
您确实需要手动设置它，适当地配置客户机和服务器，还需要考虑在该机上使用多租户。它会成为维护的负担。
KUBECTL
在Kubernetes中，API服务器实际上是您的“跳转主机”。
X11 forwarding
使用SSH，您可以图形化的管理远程应用程序：
它就像一个远程桌面，但是您在服务器上启动的应用程序自然会融合到本地桌面中，而不是拥有嵌套的桌面。
性能
从用户角度来看，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，不应影响结果。
本地
kubectl 最快，快37%!
远程
如果我们把网络加入其中呢?
再一次kubectl获得最佳：速度提高55%!
吞吐量
原始数据吞吐量如何?
我将通过OpenSSH发送约32MB的数据，并在远端将其回显。
本地
好吧，这很有趣。SSH通过发送数据的速度快约5倍!
SSH需要大约5.45s，大约6000 KB/s。
kubectl 大约需要27.62s，大约1200 KB/s。
远程
SSH仍然更快，但仅提高了约16%。
结论
SSH和kubectl之间有很多相似之处，它们都有各自的优点和缺点。虽然SSH在架构上是一成不变的，但是在管理一些机器时，高级软件可以从Kubernetes那里学到一些关于集中配置的东西。SSH还可以借用kubeconfig中的凭证管理方法(即“将所有客户机凭据和服务器信息放入一个可以复制的文件中”)。
kubectl可以改善其no-shell功能，例如端口转发和文件传输。它原始数据吞吐量也不足，这使其无法成为像SSH这样的传输层协议。实际上，这些工具是互补的，可以用于不同的任务，而不是仅仅使用其中一个。希望这篇文章对您有所帮助!
原文：https://gravitational.com/blog/ssh-vs-kubectl/