我有以下入口清单文件:
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
我正在使用 Vsphere 的 VMware。我没有像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 位于内网?如果我 curl 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 为该名称生成证书。抱歉。
您的选择是:
- 实例化您自己的“内部” CA,让其根证书在每台相关机器上都受信任,然后使用它生成证书。例如,这可能是 MS AD 认证服务。这将需要一些工作来实例化和支持 CA,但您将能够继续使用“.int”;
- 使用全球注册域名的子域名,即,将您的“.int”后缀更改为“.int.example.com”之类的内容,其中 example.com 是您购买和委托的域名。然后,您可以设置一些反向代理,并将所有“内部”名称指向全球 DNS 中该代理的公共地址,以便能够将 ACME 用于您的“内部”主机。
经过多年的网络工程师经验,我最终选择了第二种选择。我从不使用“分离的私有内部”名称(如“.int”、“.local”、“.lan”等)来提供内部服务,即使我知道我不会将它们与“外部世界”连接起来,即使它们在物理上与互联网断开连接。我总是使用源自我拥有的全球域名的东西。这为我节省了很多工作。当我有时遇到使用这些“分离”名称的网络时,几乎总是有一些肮脏的怪癖来解决模糊的问题,如果他们使用全球名称,则不需要这些问题。