Google 托管 SSL 证书卡在 FAILED_NOT_VISIBLE
Google Managed SSL Certificate Stuck on FAILED_NOT_VISIBLE
我正在尝试使用 GKE 配置 HTTPS/Layer 7 负载均衡器。我正在关注 SSL certificates overview and GKE Ingress for HTTP(S) Load Balancing.
我的配置。已经工作了一段时间。我想测试 Google 的托管服务。
到目前为止我是这样设置的:
k8s/staging/staging-ssl.yml
:
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
name: my-staging-lb-ingress
annotations:
kubernetes.io/ingress.global-static-ip-name: "my-staging-global"
ingress.gcp.kubernetes.io/pre-shared-cert: "staging-google-managed-ssl"
kubernetes.io/ingress.allow-http: "false"
spec:
rules:
- host: staging.my-app.no
http:
paths:
- path: /*
backend:
serviceName: my-svc
servicePort: 3001
gcloud compute addresses list
#=>
NAME REGION ADDRESS STATUS
my-staging-global 35.244.160.NNN RESERVED
host staging.my-app.no
#=>
35.244.160.NNN
但卡在 FAILED_NOT_VISIBLE
:
gcloud beta compute ssl-certificates describe staging-google-managed-ssl
#=>
creationTimestamp: '2018-12-20T04:59:39.450-08:00'
id: 'NNNN'
kind: compute#sslCertificate
managed:
domainStatus:
staging.my-app.no: FAILED_NOT_VISIBLE
domains:
- staging.my-app.no
status: PROVISIONING
name: staging-google-managed-ssl
selfLink: https://www.googleapis.com/compute/beta/projects/my-project/global/sslCertificates/staging-google-managed-ssl
type: MANAGED
知道如何进一步修复或调试这个问题吗?
我在 post 开头链接的文档中找到了一个部分
将 SSL 证书资源与目标代理相关联:
Use the following gcloud command to associate SSL certificate resources with a target proxy, whether the SSL certificates are self-managed or Google-managed.
gcloud compute target-https-proxies create [NAME] \
--url-map=[URL_MAP] \
--ssl-certificates=[SSL_CERTIFICATE1][,[SSL_CERTIFICATE2], [SSL_CERTIFICATE3],...]
当我在 k8s/staging/staging-ssl.yml
中有此行时是否有必要?
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
annotations:
. . .
ingress.gcp.kubernetes.io/pre-shared-cert: "staging-google-managed-ssl"
. . .
根据您提供的以下 documentation,这应该对您有所帮助:
The status FAILED_NOT_VISIBLE indicates that certificate provisioning failed for a domain because of a problem with DNS or the load balancing configuration. Make sure that DNS is configured so that the certificate's domain resolves to the IP address of the load balancer.
staging.my-app.no
的 A 资源记录的 TTL(生存时间)是多少?
使用,例如,
dig +nocmd +noall +answer staging.my-app.no
想办法。
在我的例子中,将 TTL 从 60 秒增加到 7200 让 domainStatus
最终到达 ACTIVE
。
事实证明,我错误地对生产环境做了一些更改,而对暂存环境做了一些更改。当我弄清楚并遵循指南时,一切都按预期进行。 :-)
我将此留给可能最终遇到与我相同情况的任何人。我需要从自我管理的证书迁移到 google 管理的证书。
我确实按照指南创建了 google 管理的证书,并希望在将证书应用到我的 Kubernetes ingress 之前看到它被激活(以避免停机的可能性)
事实证明,如 docs 所述,
the target proxy must reference the Google-managed certificate
resource
因此应用 kubectl apply -f ingress-conf.yaml
的配置使负载均衡器使用新创建的证书,该证书在不久后(大约 15 分钟)变得活跃
除了其他答案之外,在从自我管理证书迁移到 google 管理证书时,我必须:
- 使用
kubernetes.io/ingress.allow-http: true
为我的入口服务启用 http
- 将现有的 SSL 证书 运行 保留在原始入口服务中,直到新的托管证书处于活动状态
我还有一个过期的原始 SSL 证书,但我不确定这是否重要。
在我的例子中,我需要更改健康检查并将其指向正确的端点(nginx-ingress 上的 /healthz),并且在健康检查返回 true 后,我必须确保托管证书是在与gce-入口。这两件事做完后总算是通过了,不然还是报同样的错误。 "FAILED_NOT_VISIBLE"
我遇到了同样的问题。
我通过重新查看文档修复了它。
FAILED_NOT_VISIBLE
Certificate provisioning failed for the domain. Either of the following might be the issue:
The domain's DNS record doesn't resolve to the IP address of the Google Cloud load balancer. To resolve this issue, update the DNS records to point to your load balancer's IP address.
The SSL certificate isn't attached to the load balancer's target proxy. To resolve this issue, update your load balancer configuration.
Google Cloud continues to try to provision the certificate while the managed status is PROVISIONING.
因为我的负载均衡器支持 cloudflare。默认情况下,cloudflare 启用了 cdn 代理,我需要先在 Google 验证 DNS 后禁用它,证书状态更改为活动。
在查看此处的答案后对我有用的方法(我使用负载均衡器,但 IMO 这对所有情况都是正确的):
- 如果一段时间过去了,这个证书对你不起作用(它可能会永久消失,需要时间来证明)-我创建了一个新的并替换了它在负载均衡器中(只需对其进行编辑)
- 确保证书在创建几分钟后正在使用
- 确保 DNS 指向您的服务。 您的配置在使用 http 时有效!! - 这是最好和最安全的方法(如果您刚刚移动了一个域 - 请确保在检查它时您到达了正确的 IP)
- 创建新证书后或如果问题得到解决 - 您的域将变为绿色但您仍然需要等待(可能需要一个小时或更长时间)
就我而言,在工作中。我们大量利用托管证书,以便为开发人员和 QA 提供动态环境。因此,我们经常配置和删除托管证书。这意味着我们也在生成和删除托管证书时更新 Ingress 资源。
我们发现,即使您从此注释中删除托管证书的引用:
networking.gke.io/managed-certificates: <list>
Ingress 似乎随机 不会从 LoadBalancer 中删除关联的 ssl 证书。
ingress.gcp.kubernetes.io/pre-shared-cert: <list>
因此,删除托管证书时。入口将以某种方式“卡住”,无法提供新的托管证书。因此,新的托管证书会在一段时间后从 PROVISIONING 状态过渡到 FAILED_NOT_VISIBLE 状态
到目前为止,我们找到的唯一解决方案是,如果新证书在 30 分钟后未获得提供。我们将检查注释 ingress.gcp.kubernetes.io/pre-shared-cert 是否包含不再存在的 ssl 证书。
您可以使用以下命令检查现有的 ssl 证书
gcloud compute ssl-certificates list
如果碰巧一个不再存在的 ssl 证书仍然在注释中徘徊。然后,我们将手动从 ingress.gcp.kubernetes.io/pre-shared-cert 注释中删除不必要的 ssl 证书。
应用更新后的配置后,大约 5 分钟后,处于 FAILED_NOT_VISIBLE 状态的新托管证书应已提供并处于 ACTIVE 状态。
我最近遇到了这个问题。您需要检查您的A Record是否正确指向了Ingress静态IP。
如果您使用的是 Cloudflare 之类的服务,请禁用 Cloudflare 代理设置,以便对域执行 ping 操作会给出 Ingress 的实际 IP。这将在 10 到 15 分钟内正确创建 Google 托管 SSL 证书。
证书启动后,您可以再次启用 Cloudflare 代理设置。
我正在尝试使用 GKE 配置 HTTPS/Layer 7 负载均衡器。我正在关注 SSL certificates overview and GKE Ingress for HTTP(S) Load Balancing.
我的配置。已经工作了一段时间。我想测试 Google 的托管服务。
到目前为止我是这样设置的:
k8s/staging/staging-ssl.yml
:
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
name: my-staging-lb-ingress
annotations:
kubernetes.io/ingress.global-static-ip-name: "my-staging-global"
ingress.gcp.kubernetes.io/pre-shared-cert: "staging-google-managed-ssl"
kubernetes.io/ingress.allow-http: "false"
spec:
rules:
- host: staging.my-app.no
http:
paths:
- path: /*
backend:
serviceName: my-svc
servicePort: 3001
gcloud compute addresses list
#=>
NAME REGION ADDRESS STATUS
my-staging-global 35.244.160.NNN RESERVED
host staging.my-app.no
#=>
35.244.160.NNN
但卡在 FAILED_NOT_VISIBLE
:
gcloud beta compute ssl-certificates describe staging-google-managed-ssl
#=>
creationTimestamp: '2018-12-20T04:59:39.450-08:00'
id: 'NNNN'
kind: compute#sslCertificate
managed:
domainStatus:
staging.my-app.no: FAILED_NOT_VISIBLE
domains:
- staging.my-app.no
status: PROVISIONING
name: staging-google-managed-ssl
selfLink: https://www.googleapis.com/compute/beta/projects/my-project/global/sslCertificates/staging-google-managed-ssl
type: MANAGED
知道如何进一步修复或调试这个问题吗?
我在 post 开头链接的文档中找到了一个部分 将 SSL 证书资源与目标代理相关联:
Use the following gcloud command to associate SSL certificate resources with a target proxy, whether the SSL certificates are self-managed or Google-managed.
gcloud compute target-https-proxies create [NAME] \
--url-map=[URL_MAP] \
--ssl-certificates=[SSL_CERTIFICATE1][,[SSL_CERTIFICATE2], [SSL_CERTIFICATE3],...]
当我在 k8s/staging/staging-ssl.yml
中有此行时是否有必要?
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
annotations:
. . .
ingress.gcp.kubernetes.io/pre-shared-cert: "staging-google-managed-ssl"
. . .
根据您提供的以下 documentation,这应该对您有所帮助:
The status FAILED_NOT_VISIBLE indicates that certificate provisioning failed for a domain because of a problem with DNS or the load balancing configuration. Make sure that DNS is configured so that the certificate's domain resolves to the IP address of the load balancer.
staging.my-app.no
的 A 资源记录的 TTL(生存时间)是多少?
使用,例如,
dig +nocmd +noall +answer staging.my-app.no
想办法。
在我的例子中,将 TTL 从 60 秒增加到 7200 让 domainStatus
最终到达 ACTIVE
。
事实证明,我错误地对生产环境做了一些更改,而对暂存环境做了一些更改。当我弄清楚并遵循指南时,一切都按预期进行。 :-)
我将此留给可能最终遇到与我相同情况的任何人。我需要从自我管理的证书迁移到 google 管理的证书。
我确实按照指南创建了 google 管理的证书,并希望在将证书应用到我的 Kubernetes ingress 之前看到它被激活(以避免停机的可能性)
事实证明,如 docs 所述,
the target proxy must reference the Google-managed certificate resource
因此应用 kubectl apply -f ingress-conf.yaml
的配置使负载均衡器使用新创建的证书,该证书在不久后(大约 15 分钟)变得活跃
除了其他答案之外,在从自我管理证书迁移到 google 管理证书时,我必须:
- 使用
kubernetes.io/ingress.allow-http: true
为我的入口服务启用 http
- 将现有的 SSL 证书 运行 保留在原始入口服务中,直到新的托管证书处于活动状态
我还有一个过期的原始 SSL 证书,但我不确定这是否重要。
在我的例子中,我需要更改健康检查并将其指向正确的端点(nginx-ingress 上的 /healthz),并且在健康检查返回 true 后,我必须确保托管证书是在与gce-入口。这两件事做完后总算是通过了,不然还是报同样的错误。 "FAILED_NOT_VISIBLE"
我遇到了同样的问题。 我通过重新查看文档修复了它。
FAILED_NOT_VISIBLE
Certificate provisioning failed for the domain. Either of the following might be the issue:
The domain's DNS record doesn't resolve to the IP address of the Google Cloud load balancer. To resolve this issue, update the DNS records to point to your load balancer's IP address.
The SSL certificate isn't attached to the load balancer's target proxy. To resolve this issue, update your load balancer configuration.
Google Cloud continues to try to provision the certificate while the managed status is PROVISIONING.
因为我的负载均衡器支持 cloudflare。默认情况下,cloudflare 启用了 cdn 代理,我需要先在 Google 验证 DNS 后禁用它,证书状态更改为活动。
在查看此处的答案后对我有用的方法(我使用负载均衡器,但 IMO 这对所有情况都是正确的):
- 如果一段时间过去了,这个证书对你不起作用(它可能会永久消失,需要时间来证明)-我创建了一个新的并替换了它在负载均衡器中(只需对其进行编辑)
- 确保证书在创建几分钟后正在使用
- 确保 DNS 指向您的服务。 您的配置在使用 http 时有效!! - 这是最好和最安全的方法(如果您刚刚移动了一个域 - 请确保在检查它时您到达了正确的 IP)
- 创建新证书后或如果问题得到解决 - 您的域将变为绿色但您仍然需要等待(可能需要一个小时或更长时间)
就我而言,在工作中。我们大量利用托管证书,以便为开发人员和 QA 提供动态环境。因此,我们经常配置和删除托管证书。这意味着我们也在生成和删除托管证书时更新 Ingress 资源。
我们发现,即使您从此注释中删除托管证书的引用:
networking.gke.io/managed-certificates: <list>
Ingress 似乎随机 不会从 LoadBalancer 中删除关联的 ssl 证书。
ingress.gcp.kubernetes.io/pre-shared-cert: <list>
因此,删除托管证书时。入口将以某种方式“卡住”,无法提供新的托管证书。因此,新的托管证书会在一段时间后从 PROVISIONING 状态过渡到 FAILED_NOT_VISIBLE 状态
到目前为止,我们找到的唯一解决方案是,如果新证书在 30 分钟后未获得提供。我们将检查注释 ingress.gcp.kubernetes.io/pre-shared-cert 是否包含不再存在的 ssl 证书。
您可以使用以下命令检查现有的 ssl 证书
gcloud compute ssl-certificates list
如果碰巧一个不再存在的 ssl 证书仍然在注释中徘徊。然后,我们将手动从 ingress.gcp.kubernetes.io/pre-shared-cert 注释中删除不必要的 ssl 证书。
应用更新后的配置后,大约 5 分钟后,处于 FAILED_NOT_VISIBLE 状态的新托管证书应已提供并处于 ACTIVE 状态。
我最近遇到了这个问题。您需要检查您的A Record是否正确指向了Ingress静态IP。
如果您使用的是 Cloudflare 之类的服务,请禁用 Cloudflare 代理设置,以便对域执行 ping 操作会给出 Ingress 的实际 IP。这将在 10 到 15 分钟内正确创建 Google 托管 SSL 证书。
证书启动后,您可以再次启用 Cloudflare 代理设置。