标签：Kubectl kubectl exec cat vs SSH ms ssh
本文转载自微信公众号「新钛云服」，作者祝祥 翻译 。转载本文请联系新钛云服公众号。
让我们看一下打开远程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/
【编辑推荐】
【责任编辑：武晓燕 TEL：（010）68476606】
标签：Kubectl,kubectl,exec,cat,vs,SSH,ms,ssh 来源： https://blog.51cto.com/14887308/2531695
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。