проверьте, существует ли DNS-запись для этого домена
У меня есть следующий входной файл манифеста:
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
namespace: fsm
name: fsm
labels:
app: fsm
annotations:
kubernetes.io/ingress.class: nginx
nginx.ingress.kubernetes.io/rewrite-target: /$2
cert-manager.io/issuer: "letsencrypt-staging"
spec:
tls:
- hosts:
- k8s-cluster.int
secretName: quickstart-example-tls
rules:
- host: k8s-cluster.int
http:
paths:
- path: /fsm(/|$)(.*)
backend:
serviceName: fsm
servicePort: 8081
Я работаю с VMware с Vsphere. У меня нет такого домена, как www.google.com, только DNS-имя k8s-cluster и домен .int (внутри моей компании). Когда я пытаюсь сгенерировать сертификат, я получаю эту ошибку:"msg"="error waiting for authorization" "error"="acme: authorization error for k8s-cluster.int: 400 urn:ietf:params:acme:error:dns: DNS problem: NXDOMAIN looking up A for k8s-cluster.int - check that a DNS record exists for this domain" "dnsName"="k8s-cluster.int" "resource_kind"="Challenge" "resource_name"="quickstart-example-tls-w7vj9-4141989927-3312743172" "resource_namespace"="fsm" "resource_version"="v1" "type"="HTTP-01"
Может ли эта проблема возникнуть из-за того, что k8s-cluster.int находится внутри интрасети? Если я сверну k8s-cluster.int
<html>
<head><title>308 Permanent Redirect</title></head>
<body>
<center><h1>308 Permanent Redirect</h1></center>
<hr><center>nginx/1.19.1</center>
</body>
</html>
Итак, я думаю, что DNS работает.
1 ответ
Вы пытались использовать ACME, именно его использует Let's Encrypt. Протокол ACME, по сути, представляет собой автоматическую проверку домена DNS и дает вам сертификаты с «проверкой домена». Он проверяет, действительно ли записи DNS с запрошенными именами указывают на запрашивающий сервер (или находятся под контролем запрашивающего сервера), что «доказывает», что серверу разрешено иметь такой сертификат.
Это означает, что проверка домена возможна только для доменных имен, находящихся в глобальном дереве DNS. Вы используете суффикс «.int», которого нет в глобальном дереве DNS (или он существует, но ваше имя не существует или принадлежит вам). Это не то, что можно было бы «подтвердить доменом» с помощью ACME.
Поэтому вы не можете создавать сертификаты ACME для этого имени. Извини.
Ваши варианты:
- создайте экземпляр своего собственного «внутреннего» центра сертификации, доверьте его корневые сертификаты на каждой задействованной машине, а затем сгенерируйте с его помощью сертификаты. Это может быть, например, служба сертификации MS AD. Это потребует некоторой работы по созданию экземпляров и поддержке ЦС, но вы сможете продолжать использовать «.int»;
- используйте поддомен глобально зарегистрированного домена, т.е. измените суффикс «.int» на что-то вроде «.int.example.com», где example.com — это ваш купленный и делегированный домен. Тогда вы можете, например, настроить какой-нибудь обратный прокси-сервер и указать все ваши «внутренние» имена на публичный адрес этого прокси в глобальном DNS, чтобы иметь возможность использовать ACME для ваших «внутренних» хостов.
После многих лет опыта работы сетевым инженером я остановился на втором варианте. Я никогда не использую «отдельные частные внутренние» имена, такие как «.int», «.local», «.lan» и т. д. для внутренних служб, даже если я знаю, что не собираюсь связывать их с «внешним миром», даже если они физически отключены от Интернета. Я всегда использую что-то, происходящее от моих глобальных доменных имен. Это сэкономило мне много работы. И когда я иногда встречаю сеть, где используются эти «отдельные» имена, почти всегда есть какие-то грязные причуды для решения непонятных задач, которые были бы не нужны, если бы использовались глобальные имена.