如何在Bitbucket Pipelines中通过SSH堡垒机建立端口转发以访问GKE私有集群并执行kubectl命令？

我之前在CI环境里处理过几乎一模一样的场景，本地能正常跑但到了Bitbucket Pipelines就各种报错，核心原因是CI环境是**无头（无交互式终端）**的，和本地的终端环境差异导致SSH会话行为异常，下面给你几个经过验证的解决方案：

方案一：优化SSH命令参数，适配无头环境 #

直接调整gcloud compute ssh的参数，解决终端分配和连接超时问题，这是最直接的方法：

# 1. 先获取GKE集群凭证（确保kubectl知道要连哪个集群）
gcloud container clusters get-credentials dev-cluster --project client-dev --zone xxxx

# 2. 建立稳定的SSH隧道，关键参数解决报错
gcloud compute ssh dev-cluster-bastion --project client-dev --zone xxxx \
  --ssh-flag="-T" \
  --ssh-flag="-fN" \
  --ssh-flag="-L 8888:127.0.0.1:8888" \
  --ssh-flag="-o ServerAliveInterval=60" \
  --ssh-flag="-o ServerAliveCountMax=3" \
  --ssh-flag="-o StrictHostKeyChecking=no"

# 3. 等待隧道完全建立（CI环境里网络连接需要一点时间）
sleep 3

# 4. 通过代理执行kubectl命令
HTTPS_PROXY=http://localhost:8888 kubectl get pods

参数解释： #

• -T：明确禁止SSH请求伪终端，直接解决Pseudo-terminal will not be allocated because stdin is not a terminal报错
• -fN：让SSH后台运行且不执行远程命令，专注做端口转发
• ServerAliveInterval=60：每60秒发送一次心跳包，防止GCP防火墙/负载均衡因为闲置断开连接
• ServerAliveCountMax=3：允许连续3次心跳失败才断开，提升容错性
• StrictHostKeyChecking=no：跳过主机密钥检查（CI环境里每次都是新容器，没有预先配置known_hosts，生产环境如果有需求可以提前配置）

方案二：用nohup强制后台运行隧道 #

如果方案一还是出现连接重置，可以用nohup把SSH进程彻底后台化，避免CI环境的进程管理机制终止它：

gcloud container clusters get-credentials dev-cluster --project client-dev --zone xxxx

# 用nohup运行SSH命令，重定向输出到/dev/null避免日志干扰
nohup gcloud compute ssh dev-cluster-bastion --project client-dev --zone xxxx \
  --ssh-flag="-T" \
  --ssh-flag="-L 8888:127.0.0.1:8888" \
  --ssh-flag="-o ServerAliveInterval=60" > /dev/null 2>&1 &

sleep 5

HTTPS_PROXY=http://localhost:8888 kubectl get pods

额外检查点 #

如果还是失败，先排查这几个点：

• 堡垒机权限：确保堡垒机的IP在GKE集群的master防火墙规则允许访问的列表里
• CI环境工具版本：确认Bitbucket Pipelines里的gcloud和kubectl版本和本地一致，避免兼容性问题
• 隧道连通性：在执行kubectl前，用netstat -tulpn | grep 8888检查8888端口是否真的被监听

内容的提问来源于stack exchange，提问作者André Schild