Сертификат Google, управляемый SSL, застрял на FAILED_NOT_VISIBLE
Я пытаюсь настроить балансировщик нагрузки https на GKE. Я следую: 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 / постановка / постановка-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
ssl-сертификаты бета-вычисления $ gcloud описывают 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-сертификатов с целевым прокси, независимо от того, являются ли SSL-сертификаты самоуправляемыми или управляемыми Google.
gcloud compute target-https-proxies create [NAME] \
--url-map=[URL_MAP] \
--ssl-certificates=[SSL_CERTIFICATE1][,[SSL_CERTIFICATE2],[SSL_CERTIFICATE3],...]
Это необходимо, когда у меня есть эта строка в моем Ingress config?
13 ingress.gcp.kubernetes.io/pre-shared-cert: "staging-google-managed-ssl"
13 ответов
Я столкнулся с этой проблемой недавно. Вам необходимо проверить, правильно ли ваша запись A указывает на статический IP-адрес Ingress.
Если вы используете такую службу, как Cloudflare, отключите настройку прокси Cloudflare, чтобы пинг в домен выдавал фактический IP-адрес Ingress. ЭТО правильно создаст сертификат SSL, управляемый Google, за 10–15 минут.
Как только сертификат будет поднят, вы можете снова включить настройку прокси Cloudflare.
Я оставляю это для всех, кто может оказаться в той же ситуации, что и я. Мне нужно было перейти с самоуправляемого сертификата на управляемый Google.
Я создал сертификат, управляемый Google, следуя руководству, и ожидал, что он будет активирован, прежде чем применять сертификат к моему входу в Kubernetes (чтобы избежать простоя)
Оказывается, как указано в документах,
целевой прокси-сервер должен ссылаться на ресурс сертификата, управляемый Google.
Итак, применяя конфигурацию с kubectl apply -f ingress-conf.yaml заставил балансировщик нагрузки использовать вновь созданный сертификат, который стал активным вскоре после (примерно 15 минут)
Что сработало для меня после проверки ответов здесь (я работал с балансировщиком нагрузки, но IMO это верно для всех случаев):
- Если прошло какое-то время, этот сертификат не будет работать для вас (он может быть удален навсегда, и потребуется время, чтобы это показать) - я создал новый и заменил его в Load Balancer (просто отредактируйте его)
- Убедитесь, что сертификат используется через несколько минут после его создания.
- Убедитесь, что DNS указывает на вашу службу. И что ваша конфигурация работает при использовании http !! - Это лучший и безопасный способ (также, если вы только что переместили домен - убедитесь, что при его проверке вы попадаете на правильный IP-адрес)
- После создания нового сертификата или если проблема была устранена - ваш домен станет зеленым, но вам все равно нужно подождать (это может занять час или больше)
В моем случае на работе. Мы активно используем управляемый сертификат, чтобы обеспечить динамическую среду для разработчиков и QA. В результате мы довольно часто предоставляем и удаляем управляемый сертификат. Это означает, что мы также обновляем ресурс Ingress по мере создания и удаления управляемого сертификата.
Мы выяснили, что даже если вы удалите ссылку на управляемый сертификат из этой аннотации:
networking.gke.io/managed-certificates: <list>
Похоже, что случайным образом Ingress не удаляет связанные ssl-сертификаты из LoadBalancer.
ingress.gcp.kubernetes.io/pre-shared-cert: <list>
В результате при удалении управляемого сертификата. Вход будет «застрять» таким образом, что новый управляемый сертификат не сможет быть предоставлен. Таким образом, новый управляемых ceritifcate будет через некоторое время перехода от Provisioning состояния в FAILED_NOT_VISIBLE состоянии
Единственное решение, которое мы нашли до сих пор, заключается в том, что если новый сертификат не будет предоставлен через 30 минут. Мы проверим, содержит ли аннотация ingress.gcp.kubernetes.io/pre-shared-cert ssl-сертификат, который больше не существует.
Вы можете проверить существующий ssl-сертификат с помощью команды ниже
gcloud compute ssl-certificates list
Если случится так, что один ssl-сертификат, который больше не существует, все еще висит в аннотации. Затем мы вручную удалим ненужный ssl-сертификат из аннотации ingress.gcp.kubernetes.io/pre-shared-cert .
После применения обновленной конфигурации, в течение 5 минут, новый управляемый сертификат , который был в FAILED_NOT_VISIBLE состоянии должно быть предусмотрено и в ACTIVE состоянии.
Согласно следующей документации, которую вы предоставили, это должно вам помочь:
Состояние FAILED_NOT_VISIBLE указывает на то, что подготовка домена не удалась для домена из-за проблемы с DNS или конфигурации балансировки нагрузки. Убедитесь, что DNS настроен так, что домен сертификата разрешается в IP-адрес балансировщика нагрузки.
В дополнение к другим ответам при переходе с самоуправляемых сертификатов на управляемые Google мне пришлось:
- Включить http для моей службы входящего трафика с помощью
kubernetes.io/ingress.allow-http: true - Оставьте существующий сертификат SSL работающим в исходной службе входящего трафика, пока новый управляемый сертификат не станет активным.
У меня также был исходный сертификат SSL с истекшим сроком действия, хотя я не уверен, что это имело значение.
Как уже указывал Митци /questions/28146612/sertifikat-google-upravlyaemyij-ssl-zastryal-na-failednotvisible/57385644#57385644
Это то, что сработало для меня
- Создать сертификат с субдоменами/доменами
- Должен добавить балансировщик нагрузки (я ждал, когда он станет активным, но только когда вы добавите, он станет активным !!)
- Добавить статический IP в качестве записи для доменов/субдоменов
Сработало за 5 мин
Что такое TTL (время жизни) для записи ресурса A для staging.my-app.no? Используйте, например,
dig +nocmd +noall +answer staging.my-app.no
чтобы понять это.
В моем случае увеличение TTL с 60 секунд до 7200 domainStatus наконец прибыть в ACTIVE,
В моем случае мне нужно было изменить проверку работоспособности и указать ее на правильную конечную точку ( /healthz на nginx-ingress), и после того, как healtcheck вернул значение true, я должен был убедиться, что управляемый сертификат был создан в том же пространстве имен, что и gce-ingress. После того, как эти две вещи были выполнены, все, наконец, прошло, иначе я получил ту же ошибку. "FAILED_NOT_VISIBLE"
У меня была эта проблема в течение нескольких дней. Несмотря на то, что полное доменное имя в общедоступной зоне DNS Google Cloud правильно разрешено к IP-адресу балансировщика нагрузки HTTPS, созданный сертификат завершился с ошибкой FAILED_NOT_VISIBLE. В конце концов я решил проблему, так как мой домен был настроен в Google Domains с DNSSEC, но имел неправильную запись DNSSEC при указании на общедоступную зону DNS Google Cloud. Конфигурацию DNSSEC можно проверить с помощью https://dnsviz.net/
У меня такая же проблема. Но моя проблема была в развертывании. я побежал
kubectl describe ingress [INGRESS-NAME] -n [NAMESPACE]
Результат показывает ошибку вresources.timeoutsecдля развертывания. Допустимые значения должны быть меньше 300 сек. Мое первоначальное значение было выше этого. я уменьшилreadinessProbe.timeoutSecondsна меньшее число. Через 30 минут был сгенерирован SSL-сертификат и подтвержден субдомен.
Я встретил ту же проблему. Я исправил это, повторно просмотрев документацию.
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 включен прокси cdn, и мне нужно сначала отключить его после того, как DNS проверил Google, состояние сертификата изменилось на активное.
Оказывается, я ошибочно внес некоторые изменения в производственную среду и другие в постановку. Все работало, как ожидалось, когда я понял это и следовал руководству.:-)