GKE上Spring Cloud架构Kubernetes集群Ingress故障及HTTPS配置咨询

• 核心原因：GCP默认的GCE Ingress控制器仅支持对接NodePort类型的后端Service，你当前配置的后端loadbalancer-service是LoadBalancer类型，不符合GCE Ingress的转发规则要求，导致流量无法正常路由到Zuul服务，返回404错误。
• 次要匹配问题：你当前配置的path: /*是Nginx Ingress的通配写法，GCE Ingress的ImplementationSpecific类型路径匹配规则对该写法的兼容度有限，若未正确指定请求的Host头为project.test.com、或者域名未解析到Ingress的公网IP，也会触发404报错。

1. 将loadbalancer-service的类型从LoadBalancer修改为NodePort，Ingress本身会提供公网流量入口，无需额外为Zuul创建LoadBalancer类型服务，同时还能减少公网IP资源占用。
2. 调整Ingress的路径配置，适配GCE Ingress的匹配规则，修改后的Ingress参考配置如下：

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: project-ingress
  annotations:
    kubernetes.io/ingress.class: "gce"
spec:
  rules:
  - host: project.test.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: loadbalancer-service # 已修改为NodePort类型
            port:
              number: 8765

你可以直接将已有证书制作为Kubernetes TLS类型的Secret，再挂载到Ingress配置中即可，步骤如下：

1. 执行kubectl命令创建Secret，替换为你本地的证书、私钥文件路径以及对应命名空间：
   kubectl create secret tls project-tls-secret --cert=./your_cert.crt --key=./your_private.key -n <your-namespace>
2. 在Ingress配置中添加tls字段关联创建好的Secret，最终完整配置如下：

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: project-ingress
  annotations:
    kubernetes.io/ingress.class: "gce"
spec:
  tls:
  - hosts:
    - project.test.com
    secretName: project-tls-secret
  rules:
  - host: project.test.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: loadbalancer-service
            port:
              number: 8765

配置下发后等待GCE Ingress生效，即可通过HTTPS协议访问project.test.com对应的服务。

• 架构轻量化优化：可以逐步替换Eureka为Kubernetes原生的Service发现能力，无需额外运维服务发现组件；Zuul网关也可以替换为K8s生态的Ingress Nginx、APISIX等网关产品，整合流量管控、认证、限流能力，减少Spring Cloud组件的运维成本。
• 可观测性优化：除了现有Zipkin分布式追踪外，对接GKE原生的Cloud Operations（原Stackdriver）服务，统一收集集群、Pod、应用的日志和监控指标，降低排障难度。
• 安全管控优化：配置Kubernetes网络策略，限制Eureka、Zipkin等内部服务仅允许指定命名空间的业务Pod访问，避免内部组件暴露；长期可以对接GCP Certificate Manager实现证书自动续期，无需手动更新证书。
• 高可用优化：为Eureka、Zuul、Zipkin等核心组件配置多副本部署，同时添加Pod反亲和策略，避免多个副本调度到同一节点，提升服务可用性。

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