Google Kubernetes部署.NET Core Socket服务CrashLoopBackOff及连接问题求助

你观测到的unable to fetch pod metrics是Kubernetes metrics-server的采集告警，和Pod重启没有直接关联。导致该问题的核心原因几乎都是存活探针配置异常：

• GKE默认的探针检测逻辑如果连续失败达到阈值，就会触发Pod重启，你遇到的5分钟重启周期完全匹配默认探针的检测周期规则。
• 你的.NET TCP服务启动正常但未处理K8s的探测请求，或者容器主进程被配置为后台运行，导致Kubelet判定服务异常。
• 修复步骤：
  • 首先确认容器启动命令为前台运行模式，.NET Core发布后的dll直接运行即可，不要添加后台托管参数，保证容器1号进程为服务主进程。
  • 在Deployment配置中添加TCP类型的存活、就绪探针，直接探测你服务监听的4200端口即可，配置参考：

livenessProbe:
  tcpSocket:
    port: 4200
  initialDelaySeconds: 15 # 服务启动后延迟15秒开始探测
  periodSeconds: 20 # 每20秒探测一次
  failureThreshold: 3 # 连续失败3次触发重启
readinessProbe:
  tcpSocket:
    port: 4200
  initialDelaySeconds: 5
  periodSeconds: 10

• 配置更新后重启工作负载，观测Pod重启状态即可。

需要逐层核对K8s和GCP的网络配置，避免漏配：

• 确认Pod层面已经正确暴露端口：Deployment的containers.ports配置中添加containerPort: 4200，协议指定为TCP。
• 确认Service配置符合公网访问要求：你需要创建LoadBalancer类型的Service（ClusterIP仅支持集群内部访问，NodePort需要绑定节点公网IP使用），Service配置中targetPort指向Pod的4200端口，port可自定义为4200，协议指定TCP。
• 确认GCP防火墙规则已经放行：GKE集群节点所在VPC的入方向防火墙规则，需要放通对应TCP端口的入流量，源地址可设置为你客户端的公网IP或者0.0.0.0/0。
• 确认客户端连接地址正确：使用LoadBalancer Service分配的公网IP + Service的port端口进行连接，不要直接连接PodIP或者节点内网IP。

内容的提问来源于stack exchange，提问作者burak akbal