最新公告
  • 欢迎您光临悠哉网,本站秉承服务宗旨 履行“站长”责任,销售只是起点 服务永无止境!立即加入我们
  • SSH vs.Kubectl exec

    SSH vs.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,您可以图形化的管理远程应用程序:

    1. user@local $ ssh -X server 
    2. 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,不应影响结果。

    本地

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

    kubectl 最快,快37%!

    远程

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

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

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

    吞吐量

    原始数据吞吐量如何?

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

    本地

    1. $ hyperfine 'find . -type f | xargs cat | ssh localhost cat' 'find . -type f | xargs cat | kubectl exec -it busybox cat' -r 10 
    2. Benchmark #1: find . -type f | xargs cat | ssh localhost cat 
    3.   Time (mean ± σ):   5.457 s ±  0.167 s [User: 4.464 s, System: 1.259 s] 
    4.   Range (min … max): 5.202 s …  5.657 s 10 runs 
    5.  
    6.  
    7. Benchmark #2: find . -type f | xargs cat | kubectl exec -it busybox cat 
    8.   Time (mean ± σ):  27.628 s ±  1.725 s [User: 9.920 s, System: 7.203 s] 
    9.   Range (min … max): 25.044 s … 30.926 s 10 runs 
    10.  
    11.  
    12. Summary 
    13.   'find . -type f | xargs cat | ssh localhost cat' ran 
    14.  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。

    远程

    1. $ hyperfine 'find . -type f | xargs cat | ssh ubuntu cat' 'find . -type f | xargs cat | kubectl exec -it busybox cat' -r 10 
    2. Benchmark #1: find . -type f | xargs cat | ssh ubuntu cat 
    3.   Time (mean ± σ):  28.794 s ±  0.627 s [User: 10.525 s, System: 5.018 s] 
    4.   Range (min … max): 27.788 s … 29.921 s 10 runs 
    5.  
    6.  
    7. Benchmark #2: find . -type f | xargs cat | kubectl exec -it busybox cat 
    8.   Time (mean ± σ):  33.299 s ±  2.679 s [User: 10.831 s, System: 8.902 s] 
    9.   Range (min … max): 30.964 s … 40.292 s 10 runs 
    10.  
    11.  
    12. Summary 
    13.   'find . -type f | xargs cat | ssh ubuntu cat' ran 
    14.  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/

    1. 本站所有资源来源于用户上传和网络,如有侵权请邮件联系站长!
    2. 分享目的仅供大家学习和交流,您必须在下载后24小时内删除!
    3. 不得使用于非法商业用途,不得违反国家法律。否则后果自负!
    4. 本站提供的源码、模板、插件等等其他资源,都不包含技术服务请大家谅解!
    5. 如有链接无法下载、失效或广告,请联系管理员处理!
    6. 本站资源售价只是赞助,收取费用仅维持本站的日常运营所需!
    7. 如遇到加密压缩包,默认解压密码为"www.yoozai.net",如遇到无法解压的请联系管理员!
    悠哉网 » SSH vs.Kubectl exec

    常见问题FAQ

    免费下载或者VIP会员专享资源能否直接商用?
    本站所有资源版权均属于原作者所有,这里所提供资源均只能用于参考学习用,请勿直接商用。若由于商用引起版权纠纷,一切责任均由使用者承担。更多说明请参考 VIP介绍。
    提示下载完但解压或打开不了?
    最常见的情况是下载不完整: 可对比下载完压缩包的与网盘上的容量,若小于网盘提示的容量则是这个原因。这是浏览器下载的bug,建议用百度网盘软件或迅雷下载。若排除这种情况,可在对应资源底部留言,或 联络我们.。
    找不到素材资源介绍文章里的示例图片?
    对于PPT,KEY,Mockups,APP,网页模版等类型的素材,文章内用于介绍的图片通常并不包含在对应可供下载素材包内。这些相关商业图片需另外购买,且本站不负责(也没有办法)找到出处。 同样地一些字体文件也是这种情况,但部分素材会在素材包内有一份字体下载链接清单。
    悠哉网 WWW.YOOZAI.NET
    悠哉网,用户消费首选的网站,喜欢你就悠哉一下。

    发表评论

    • 702会员总数(位)
    • 5271资源总数(个)
    • 90本周发布(个)
    • 1 今日发布(个)
    • 214稳定运行(天)

    提供最优质的资源集合

    立即查看 了解详情