GKE配置Google托管SSL证书握手失败及重复证书问题

• 你混淆了GKE上两类Google托管SSL证书的资源体系：通过gcloud命令创建的是Compute Engine层面的全局托管证书，而集群中部署的ManagedCertificate是Kubernetes自定义资源（CR），二者属于独立的资源平面，不会自动关联复用。
• Ingress注解配置存在冲突，是自动生成临时证书的直接原因：
  • ingress.gcp.kubernetes.io/pre-shared-cert注解仅识别Compute Engine层面创建的证书资源名
  • networking.gke.io/managed-certificates注解仅识别同命名空间下的Kubernetes ManagedCertificate类型CR资源
    你将gcloud创建的全局证书名managed-cert同时填入两个注解字段后，Ingress控制器无法在K8s资源层找到名为managed-cert的ManagedCertificate CR，就会自动生成mcrt-前缀的临时托管证书，尝试为Ingress配置的域名签发证书。
• HTTPS握手失败的直接原因：目前关联到负载均衡器HTTPS监听器的两个证书（你手动创建的全局证书、控制器自动生成的临时证书）都处于PROVISIONING未签发状态，监听器没有可用的有效证书完成TLS协商，因此curl访问时返回sslv3 alert handshake failure。

你可以根据自己的使用习惯二选一方案，不要混用两套证书体系即可。

方案1：复用已通过gcloud创建的全局托管证书 #

1. 清理冲突资源
   • 删除test命名空间下重复创建的ManagedCertificateCR资源，避免控制器重复识别
   • 编辑GCE Ingress资源，修正注解配置：
     • 清空networking.gke.io/managed-certificates注解的取值，不要将GCE层面的证书名填入该字段
     • 仅保留ingress.gcp.kubernetes.io/pre-shared-cert: "managed-cert"注解，明确指定使用你提前创建的全局托管证书
2. 等待配置收敛
   • 注解修改完成后，Ingress控制器会自动删除之前自动生成的mcrt-前缀临时证书
   • 执行gcloud compute ssl-certificates list观察managed-cert的状态，等待其从PROVISIONING变为ACTIVE：Google托管证书的签发依赖负载均衡器目标代理配置完成、域名解析正确指向负载均衡器IP，整个过程通常需要10-30分钟，期间不要反复修改Ingress配置避免触发控制器重复调谐
   • 证书状态变为ACTIVE后，再等待5-10分钟等待负载均衡器配置全量下发，即可通过HTTPS正常访问域名。

方案2：使用K8s原生ManagedCertificate资源 #

1. 清理冲突资源
   • 执行gcloud compute ssl-certificates delete managed-cert删除你之前手动创建的全局托管证书
   • 编辑GCE Ingress资源，修正注解配置：
     • 清空ingress.gcp.kubernetes.io/pre-shared-cert注解的取值
     • 仅保留networking.gke.io/managed-certificates: "<你在test命名空间下创建的ManagedCertificate资源名>"注解，明确指定使用K8s层管理的托管证书
2. 等待配置收敛
   • 控制器会自动清理之前生成的mcrt-前缀临时证书，为你指定的ManagedCertificate资源对应签发证书
   • 执行kubectl get managedcertificates -n test观察对应资源的状态，等待其Status字段变为Active后，再等待负载均衡器配置下发完成即可正常访问HTTPS。

• 两类证书注解禁止混用，填错资源类型必然触发控制器自动生成临时证书，导致配置冲突
• 托管证书处于PROVISIONING状态时，负载均衡器HTTPS监听器未加载有效证书，此时测试HTTPS访问必然出现握手失败，无需反复排查客户端或应用层配置
• GKE 1.22版本的GCE Ingress控制器不支持跨资源平面关联证书，不会自动将GCE层的全局证书与K8s层同名CR做绑定。

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