添加外部IP后仍无法SSH连接GKE私有集群节点，求排查方案

Yep, firewall rules are almost certainly playing a role here—let’s break down the step-by-step troubleshooting to get your SSH access working:

1. Verify GKE’s Default SSH Firewall Rule Exists #

GKE automatically creates a firewall rule when you spin up a cluster to allow SSH access to nodes. This rule is typically named gke-<your-cluster-name>-<random-hash>-ssh.

To check if it’s still present, run this command:

gcloud compute firewall-rules list --filter="name~gke-.*-ssh"

If the rule is missing, you’ll need to recreate it. The key settings for this rule should be:

• Target tags: Matches the node tags for your cluster (usually gke-<cluster-name>-<hash>-node)
• Source ranges: Includes your authorized network (or the public IP you’re connecting from)
• Allowed ports: tcp:22

2. Validate Firewall Rule Target Tags & Source Ranges #

Even if the rule exists, double-check two critical details:

• Target tags: Ensure the rule’s targetTags matches the tags assigned to your nodes. You can check node tags with:

  gcloud compute instances describe gke-private-cluster-nodename --format="value(tags.items)"
  

• Source ranges: Confirm your current public IP (or the cluster’s authorized network) is listed in the rule’s sourceRanges. If not, update the rule to include it:

  gcloud compute firewall-rules update gke-<cluster-name>-<hash>-ssh --source-ranges="your-public-ip/32,authorized-network-cidr"
  

3. Check for Typos in Your SSH Command #

Wait a second—your command gcloud compute ssh gke-private-cluster targets the cluster name, not the specific node. You need to use the actual node name (like gke-private-cluster-nodename) instead:

gcloud compute ssh gke-private-cluster-nodename

Using the cluster name here would explain a timeout, since there’s no VM with that exact name.

4. Confirm the External IP is Properly Attached #

Make sure the external IP you added is actually associated with the node. Run this to verify:

gcloud compute instances describe gke-private-cluster-nodename --format="value(networkInterfaces.accessConfigs.natIP)"

If no IP is returned, re-run the add-access-config command to ensure it was applied correctly.

5. Inspect Node-Level Firewall (iptables) #

In rare cases, the node’s internal iptables rules might be blocking port 22. If you can access the node from within the cluster (e.g., via a pod with host network access), run:

iptables -L INPUT | grep ssh

You should see a line allowing tcp dpt:22 from your source IP or authorized network. If not, you’ll need to adjust the iptables rules or check if any custom scripts/plugins modified them.

6. Verify SSH Daemon is Running on the Node #

Again, if you can access the node internally, check if the SSH service is active:

systemctl status sshd

If it’s stopped, start it with systemctl start sshd and check the logs (journalctl -u sshd) for any errors that might explain why it’s not running.

内容的提问来源于stack exchange，提问作者Calle Engene