本文转载自微信公众号《新钛云服务》，朱翔译。转载本文请联系新钛云服务公众号。让我们看一下打开远程shell的两种流行方式：ssh和kubectlexec。下面，我们将只看“kubectlexec”子命令和相关命令。kubectl本身就是Kubernetes的瑞士军刀。.将所有这些与ssh进行比较就像将systemd与BSDinit进行比较。另外，我将使用“SSH”表示“OpenSSH”，它是SSH协议实现的实际标准。但大多数讨论点适用于任何SSH实现。乍一看，苹果与橙子是一种奇怪的比较。OpenSSH已经存在了二十年，远早于云技术的诞生。它的设计假定您正在管理多台服务器并仔细配置和调整它们的各个方面。SSH也被用作SFTP和Ansible之类的传输层协议。另一方面，kub??ectl诞生于云时代。它处理数以千计的远程机器（或容器）。kubectlexec只是其中的一小部分，用于在出现问题时进行调试。但是，如果你仔细看，你会发现kubectlexec和ssh的作用是一样的。它无需本地终端即可在远程计算机上运行程序，并尝试与各种终端功能集成，让您感觉就像将键盘和显示器插入数据中心机架一样。顺便说一句，让我们深入了解它们的异同。Authn/z让我们从大家最喜欢的话题开始：安全。TL;DR：SSH身份验证很容易定制，但大规模管理起来很麻烦。kubectl可以更好地处理授权，但身份验证通常不透明且难以调整。注意：这里不讨论认证方式的优缺点，那是另外一个话题，下次再讨论。SSH协议SSH支持多种身份验证选项：磁盘上使用硬件令牌（例如YubiKey）以明文形式存储的基本密码非对称加密密钥在使用密码证书（但不是X.509类型）加密的磁盘上链接到私有有所有CA上用于存储私钥的选项通过GSSAP或PAM（例如ActiveDirectory、LDAP、OIDC等）的可插入外部身份验证2FA基于本地的硬件令牌或使用TOTP（例如Google身份验证器）或Duo等通过PAM进行关联进行身份验证服务器，您将获得一个非对称公钥或证书。默认情况下，SSH使用首次使用信任(TOFU)，因此作为预防措施，您可能希望在客户端计算机上管理~/.ssh/known_hosts。作为用户，你可以选择你想要的认证方式，以及如何在两边进行配置！在授权方面，它并不理想。授权粒度基本上是：“用户X可以登录服务器Y”，没有分组。您必须通过将用户的公钥写入~/.ssh/authorized_keys并为其创建本地UNIX用户来配置用户可以单独登录的每个服务器。使用带有SSH证书的CA可以帮助分发密钥。PAM管道还可以为您创建用户。无论如何，这将需要一些额外的工作。幸运的是，如果您愿意扩展您的工具，可以使用更高级别的软件来解决这些问题。kubectl大多数时候，大家认为kubeconfig管理着kubernetns中的所有凭据。使用托管Kubernetes平台时，您甚至可能没有注意到它是在平台后端自动生成的。您很少会直接修改kubeconfig内容，大多数时候您会使用由云或身份验证提供商生成的内容。这是一个很好的用户体验，但这里有一些常见的问题点：HTTP基本身份验证（纯文本用户名+密码）TLS客户端证书（纯文本磁盘上的私钥）不透明令牌（纯文本磁盘上）云提供商插件这些被编译成kubectl代码本身逐渐淘汰以减少Kubernetes代码依赖性执行插件在每个请求上执行外部二进制文件以获取承载令牌或TLS客户端云提供商使用密钥/证书与他们的自定义身份验证系统集成如果你想要2FA，这可能是要走的路服务器使用TLS进行身份验证，通常在kubeconfig中嵌入私有CA。这里的授权比SSH好多了！这里没有类似SSH的（例如每个pod）设计，因为Kubernetespod是短暂的非持久性的。Kubernetes通过RBAC在本地处理授权。所有kubectlexec请求都通过执行RBAC规则的KubernetesAPI服务器进行路由。这需要一些学习，从互联网上复制粘贴YAML并对其进行调整。但是当你完成后，你可以说：“项目中的每个人都可以登录默认命名空间，但只有核心人员才能管理生产命名空间*”。“最难”的部分是确保每个工作人员都有一个kubeconfig，其身份正确且符合您的RBAC规则。幸运的是，SSO集成在大多数托管平台上都非常好。ShellUX实际上非常接近。SSH和kubectl都处理终端颜色、转义码、交互式命令甚至窗口调整大小事件。SSH和kubectl应该可以很好地处理99%的CLI应用程序。SSH确实增加了一些不错的特性：环境变量自定义kubectl总是在启动时设置提供给容器的环境变量ssh主要依赖于系统登录shell的程序配置（但也可以通过PermitUserEnvironment或SendEnv/AcceptEnv接受用户的环境）escape序列（不要与ANSI转义码混淆）非常方便地关闭挂起的SSH会话，而无需等待超时触发，下次您可以尝试键入“~？”非shell特性文件传输ssh和kubectl都支持在你和服务器之间传输文件。SSH协议SSH有多种工具可以作为传输工具：有内置的SCP和更新的SFTP虽然需要单独安装，但是有更好的rsync工具你甚至可以使用一些管道字符用于文件传输的KUBECTLkubectlcp命令可以复制文件，但它基本上是kubectlexec+tar的简单包装器。而且，很遗憾，如果您正在处理的容器尚未包含tar命令。可以使用挂载volume的方式传输文件，但这需要在创建Pod时提前规划好，非常不方便。端口转发SSH协议SSH有非常灵活的端口转发支持：本地端口转发（本地端口->服务器->任何地方）ssh-L8080:example.com:80服务器远程端口转发（任何地方->服务器端口->本地端口）ssh-R80:localhost:8080server动态端口转发（通过SOCKS5）ssh-D1080server可以用它来实现各种转发需求！当然，你也可以在生产环境留下后门……KUBECTLkubectlport-forward允许你通过本地端口与pod上的远程端口进行通信。这是SSH本地端口转发做不到的部分。JumphostsSSH协议在使用SSH时，通常会设置一个跳转主机（也称堡垒主机），通过控制堡垒主机的权限来实现访问控制。你真的需要手动设置它，适当地配置客户端和服务器，还要考虑在机器上使用多租户。它可能成为维护负担。KUBECTL在Kubernetes中，API服务器实际上是您的“跳转主机”。X11转发使用SSH，可以图形化管理远程应用：user@local$ssh-Xserveruser@server%firefox就像远程桌面，但是你在服务器上启动的应用会自然地合并到本地桌面，而不是嵌套台式机。性能从用户的角度来看，SSH和kubectl的性能都非常好。您可能会遇到一些卡顿，尤其是在网络不稳定的情况下，但两者之间的速度明显较慢。但我仍然想获得一些真实的参考数据，所以让我们运行一些人为的基准测试吧！TL;DR：kubectlexec在建立连接时速度更快，但SSH在发送/接收会话数据时速度更快。以下结果并不准确，但仍代表实际使用情况：在具有无线网络连接的笔记本电脑上测试。客户端是OpenSSHv8.3和kubectlv1.18。在Kubernetes方面，我使用了一个构建在busyboxkubectlrun-itbusybox--image=busybox之上的简单容器。本地服务器是OpenSSHv8.3和运行Kubernetesv1.18的minikube。远程服务器是OpenSSHv8.2和GKEv1.14（很旧，是的）。两者都在同一区域的GCP上运行。登录/设置延迟首先，让我们测量建立会话所需的时间。在这两种情况下，我都会远程运行echofoo100次并使用hyperfine来测量时间。结果测量了建立连接、执行authn/z、打开远程shell然后断开连接所需的时间。实际的echo命令需要<1ms，应该不会影响结果。Local$hyperfine'sshlocalhosttechofoo''kubectlexec-itbusyboxechofoo'-r100Benchmark#1:sshlocalhosttechofooTime(mean±σ):156.2ms±15.9ms[User:14.0ms,System:2.1ms]Range(min…max):112.4ms…220.9ms100runsBenchmark#2:kubectlexec-itbusyboxechofooTime(mean±σ):113.9ms±16.1ms[User:72.4ms,System:12.7ms]Range(min...max):95.8ms...157.2ms100runsSummary'kubectlexec-itbusyboxechofoo'ran1.37±0.24倍于'sshlocalhosttechofoo'kubectl是最快的，快了37%！远程如果我们给它加上网络呢？$hyperfine'sshubuntuechofoo''kubectlexec-itbusyboxechofoo'-r100Benchmark#1:sshubuntuechofooTime(mean±σ):689.1ms±42.6ms[User:41.1ms,System:6.1ms]Range(min...max):653.6ms。..1022.0ms100runsBenchmark#2:kubectlexec-itbusyboxechofooTime(mean±σ):445.7ms±45.3ms[User:130.1ms,System:31.2ms]Range(min...max):372.3ms...655.2ms100runsSummary'kubectlexec-itbusyboxechofoo'ran1.55±0.18倍快han'sshubuntuechofoo'再次成为kubectl的最佳选择：快55%！吞吐量原始数据吞吐量如何？我通过OpenSSH发送大约32MB的数据，并在远端本地回显它$hyperfine'find.-typef|xargscat|sshlocalhostcat''find.-typef|xargscat|kubectlexec-itbusyboxcat'-r10Benchmark#1:find.-typef|xargscat|sshlocalhostcatTime(mean±σ):5.457s±0.167s[User:4.464s,System:1.259s]Range(min...max):5.202s...5.657s10runsBenchmark#2:find.-typef|xargscat|kubectlexec-itbusyboxcatTime(mean±σ):27.628s±1.725s[User:9.920s,System:7.203s]Range(min...max):25.044s...30.926s10runsSummary'find.-typef|xargscat|sshlocalhostcat'ran5.06±0.35timesfasterthan'find.-typef|xargscat|kubectlexec-itbusyboxcat'嗯，这很有趣。通过发送数据，SSH大约快5倍！SSH大约需要5.45s，也就是大约6000KB/s。kubectl大约需要27.62s，也就是大约1200KB/s。远程$hyperfine'find.-typef|xargscat|sshubuntucat''find.-typef|xargscat|kubectlexec-itbusyboxcat'-r10Benchmark#1:find.-typef|xargscat|sshubuntucatTime(mean±σ):28.794s±0.627s[User:10.525s,System:5.018s]Range(min...max):27.788s...29.921s10runsBenchmark#2:find.-typef|xargscat|kubectlexec-itbusyboxcatTime(mean±σ):33.299s±2.679s[用户：10.831s，系统：8.902s]范围（最小...最大）：30.964s...40.292s10runsSummary'find.-typef|xargscat|sshubuntucat'ran1.16±0.10timesfasterthan'find.-typef|xargscat|kubectlexec-itbusyboxcat'SSH还是更快Faster，但只快了16%左右。结语SSH和kubectl有很多相似之处，也各有优缺点。虽然SSH在架构上是不可变的，但高级软件可以在管理几台机器时从Kubernetes那里学到一些关于集中配置的知识。SSH还可以借鉴kubeconfig的凭证管理方法（即“将所有客户端凭证和服务器信息放入一个可以复制的文件中”）。kubectl可以改进其无外壳功能，例如端口转发和文件传输。它还缺乏原始数据吞吐量，这使其无法成为像SSH这样的传输层协议。事实上，这些工具是互补的，可以用于不同的任务，而不是只使用其中的一个。希望本文对您有所帮助！原文：https://gravitational.com/blog/ssh-vs-kubectl/
