web-dev-qa-db-ja.com

Googleが管理するSSL証明書がFAILED_NOT_VISIBLEでスタックする

GKEでhttpsロードバランサーを構成しようとしています。私は次のとおりです： https://cloud.google.com/load-balancing/docs/ssl-certificates および https://cloud.google.com/kubernetes-engine/ docs/concepts/ingress

私の設定は、Let's Encryptの証明書を使用してしばらくの間機能していました。しかし、証明書を常に更新するのは面倒なので、Googleのマネージドサービスをテストしたかったのです。

これは私がこれまでに設定した方法ですが、FAILED_NOT_VISIBLE。これをさらに修正またはデバッグする方法についてのアイデアはありますか？

k8s/staging/staging-ssl.yml

  7 apiVersion: extensions/v1beta1
  8 kind: Ingress
  9 metadata:
 10   name: my-staging-lb-ingress
 11   annotations:
 12     kubernetes.io/ingress.global-static-ip-name: "my-staging-global"
 13     ingress.gcp.kubernetes.io/pre-shared-cert: "staging-google-managed-ssl"
 14     kubernetes.io/ingress.allow-http: "false"
 15 spec:
 16   rules:
 17   - Host: staging.my-app.no
 18     http:
 19       paths:
 20       - path: /*
 21         backend:
 22           serviceName: my-svc
 23           servicePort: 3001

予約済みIP

$ 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

$ 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

投稿の最初にリンクしたドキュメントのセクションを見つけましたSSL証明書リソースをターゲットプロキシに関連付ける：

次のgcloudコマンドを使用して、SSL証明書が自己管理またはGoogle管理のいずれであっても、SSL証明書リソースをターゲットプロキシに関連付けます。

gcloud compute target-https-proxies create [NAME] \
    --url-map=[URL_MAP] \
    --ssl-certificates=[SSL_CERTIFICATE1][,[SSL_CERTIFICATE2],[SSL_CERTIFICATE3],...]

Ingressの設定にこの行があるときに必要ですか？

13 ingress.gcp.kubernetes.io/pre-shared-cert: "staging-google-managed-ssl"

sslgoogle-cloud-platformgoogle-kubernetes-enginegke-networking
6
martins

実稼働環境にいくつかの変更を誤って行い、ステージングに他の変更を加えたことが判明しました。私がそれを理解し、ガイドに従ったとき、すべてが期待どおりに機能しました。 :-)

1
martins

staging.my-app.noのAリソースレコードのTTL（存続時間））とは何ですか？

Dig +nocmd +noall +answer staging.my-app.no

を解決する。

私の場合、TTLを60秒から7200に増やすと、domainStatusがACTIVEに到着します。

1
renew

私と同じ状況に陥る可能性のある人のためにこれを残しています。自己管理証明書からGoogle管理証明書に移行する必要がありました。

私はガイドに従ってGoogle管理証明書を作成しましたが、証明書をKubernetesイングレスに適用する前にアクティブ化されることを期待していました（ダウンタイムの可能性を避けるため）

docs で述べられているように、

ターゲットプロキシはGoogle管理の証明書リソースを参照する必要があります

そのため、kubectl apply -f ingress-conf.yamlを使用して構成を適用すると、ロードバランサーが新しく作成された証明書を使用するようになり、その後すぐにアクティブになりました（15分程度）

0
Nicolò Gasparini