kubectl:服务器错误:当前未打开SSH隧道 [英] kubectl: Error from server: No SSH tunnels currently open
问题描述
我正在Google Container Engine上运行一些容器.
一天一切都很好，第二天我再也不能attach到我的容器了.或exec或任何其他docker命令.
I'm running some containers on Google Container Engine.
One day everything was fine, and the next day I can't attach to my containers anymore. Or exec, or any other docker command.
我删除了吊舱，并实例化了新吊舱，但无济于事. 然后，我删除了该节点并等待创建一个新节点，并且部署了Pod，也无济于事.
I deleted the pods and let new ones be instanced, didn't help. Then I deleted the node and waited for a new one to be created and the pods deployed, didn't help either.
$ kubectl attach www-controller-dev-xxxxx
Error from server: No SSH tunnels currently open. Were the targets able to accept an ssh-key for user "gke-xxxxxxxxxxxxxxxxxxxxxxxx"?
我还能尝试什么?
在删除集群并重新创建集群后，问题可能已经开始，但是我不确定.以前做过，这从来都不是问题.
The problem might have started after I've deleted the cluster and recreated it, but I can't be sure. Did that before and it never was a problem.
推荐答案
像attach这样的命令依赖于集群的主节点能够与节点对话 在集群中.但是，因为母版不在同一个Compute中 引擎网络作为您群集的节点，我们依靠SSH隧道来启用安全性 交流.
Commands like attach rely on the cluster's master being able to talk to the nodes in the cluster. However, because the master isn't in the same Compute Engine network as your cluster's nodes, we rely on SSH tunnels to enable secure communication.
Container Engine将SSH公钥放入您的Compute Engine项目中 元数据.所有Compute Engine虚拟机使用 Google提供的图片会定期检查其项目的通用元数据 及其实例的元数据(用于SSH密钥)添加到VM的列表中 授权用户.容器引擎还向您的计算添加了防火墙规则 引擎网络，允许从主机的IP地址到每个节点的SSH访问 在集群中.
Container Engine puts an SSH public key in your Compute Engine project metadata. All Compute Engine VMs using Google-provided images regularly check their project's common metadata and their instance's metadata for SSH keys to add to the VM's list of authorized users. Container Engine also adds a firewall rule to your Compute Engine network allowing SSH access from the master's IP address to each node in the cluster.
如果kubectl附加(或日志，exec和端口转发)不起作用，则可能是因为主服务器无法打开到节点的SSH隧道.到 确定潜在的问题是什么，您应该检查这些潜在问题 原因:
If kubectl attach (or logs, exec, and port-forward) doesn't work, it's likely that it's because the master is unable to open SSH tunnels to the nodes. To determine what the underlying problem is, you should check for these potential causes:
-
集群没有任何节点.
The cluster doesn't have any nodes.
如果您已将群集中的节点数缩减为零，则使用SSH 隧道不起作用.
If you've scaled down the number of nodes in your cluster to zero, SSH tunnels won't work.
要解决此问题， 调整集群大小 至少有一个节点.
To fix it, resize your cluster to have at least one node.
群集中的豆荚处于终止状态并被阻止 从集群中删除不再存在的节点.
Pods in the cluster have gotten stuck in a terminating state and prevented nodes that no longer exist from being removed from the cluster.
这是一个仅会影响Kubernetes 1.1版的问题，但可能会 是由于反复调整群集大小而导致的.
This is an issue that should only affect Kubernetes version 1.1, but could be caused by repeated resizing of the cluster down and up.
要解决此问题， 删除吊舱 处于终止状态已超过几分钟的状态. 然后将旧节点从主机的API中删除并替换 通过新节点.
To fix it, delete the pods that have been in a terminating state for more than a few minutes. The old nodes will then be removed from the master's API and replaced by the new nodes.
您的网络的防火墙规则不允许通过SSH访问主服务器.
Your network's firewall rules don't allow for SSH access to the master.
所有Compute Engine网络都是使用称为以下规则的防火墙规则创建的 "default-allow-ssh"，允许从所有IP地址进行SSH访问(要求 有效的私钥，当然).容器引擎还插入SSH规则 对于形式为"gke --- ssh"的每个群集 允许通过SSH从群集的主IP专门访问 集群的节点.如果这些规则都不存在，则主服务器将是 无法打开SSH隧道.
All Compute Engine networks are created with a firewall rule called "default-allow-ssh" that allows SSH access from all IP addresses (requiring a valid private key, of course). Container Engine also inserts an SSH rule for each cluster of the form "gke---ssh" that allows SSH access specifically from the cluster's master IP to the cluster's nodes. If neither of these rules exists, then the master will be unable to open SSH tunnels.
要解决此问题， 重新添加防火墙规则 允许使用来自所有群集节点上的标签的VM来访问VM. 主机的IP地址.
To fix it, re-add a firewall rule allowing access to VMs with the tag that's on all the cluster's nodes from the master's IP address.
您的项目的sshKeys通用元数据条目已满.
Your project's common metadata entry for sshKeys is full.
如果项目的名为"sshKeys"的元数据条目接近32KiB大小
限制，则Container Engine无法添加自己的SSH密钥来允许它
打开SSH隧道.您可以通过运行查看项目的元数据
gcloud compute project-info describe [--project=PROJECT]，然后检查
sshKeys列表的长度.
If the project's metadata entry named "sshKeys" is close to the 32KiB size
limit, then Container Engine isn't able to add its own SSH key to let it
open SSH tunnels. You can see your project's metadata by running
gcloud compute project-info describe [--project=PROJECT], then check the
length of the list of sshKeys.
要解决此问题， 删除一些SSH密钥 不再需要.
To fix it, delete some of the SSH keys that are no longer needed.
您已在虚拟机中的VM上使用键"sshKeys"设置了元数据字段. 集群.
You have set a metadata field with the key "sshKeys" on the VMs in the cluster.
VM上的节点代理更喜欢按实例使用sshKeys而不是项目范围的SSH密钥，
因此，如果您专门在群集节点上设置了任何SSH密钥，则
节点将不会使用项目元数据中的master的SSH密钥.
要检查，请运行gcloud compute instances describe <VM-name>并查找
元数据中的"sshKeys"字段.
The node agent on VMs prefers per-instance sshKeys to project-wide SSH keys,
so if you've set any SSH keys specifically on the cluster's nodes, then the
master's SSH key in the project metadata won't be respected by the nodes.
To check, run gcloud compute instances describe <VM-name> and look for
an "sshKeys" field in the metadata.
要解决此问题， 删除每个实例的SSH密钥 从实例元数据中获取.
To fix it, delete the per-instance SSH keys from the instance metadata.
值得注意的是，正确的功能并不需要这些功能 集群的功能.如果您希望保持群集的网络锁定 从所有外部访问开始，这都很好.请注意 这样的功能将无法使用.
It's worth noting that these features are not required for the correct functioning of the cluster. If you prefer to keep your cluster's network locked down from all outside access, that's perfectly fine. Just be aware that features like these won't work as a result.
这篇关于kubectl:服务器错误:当前未打开SSH隧道的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
