如何在我的kubernetes服务中使用Cert经理letsencrypt？

Question

我有4份yaml文件

1. Deployment.yaml
2. Service.yaml
3. Ingress.yaml
4. issuer.yaml

我想在我的认证服务中使用letsencrypt。但不起作用。

当我过去确定入口有效或发行人正在工作时，两者都完成了！

kubectl get ing

kubectl get issuer

但当我跑的时候

kubectl get cert

在2天内不能读取证书。如下所示：

它造成的问题如下。认证是不绑定的，mandrakee.xyz.Mandrakee.xyz看起来还不安全！如何使我的网站安全通过证书经理？Deployment.yaml：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: echo-deployment
spec:
  replicas: 1
  selector:
    matchLabels:
      app: echo-server
  template:
    metadata:
      labels:
        app: echo-server
    spec:
      containers:
      - name: httpapi-host
        image: jmalloc/echo-server
        imagePullPolicy: Always
        resources:
          requests:
            memory: "128Mi"
            cpu: "500m"
        ports:
        - containerPort: 80                                     

Service.yaml：

apiVersion: v1
kind: Service
metadata:
  name: echo-service
spec:
  ports:
    - name: http-port
      port: 80
      targetPort: 8080
  selector:
    app: echo-server

Ingress.yaml：

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
    kubernetes.io/ingress.class: ambassador
    cert-manager.io/issuer: letsencrypt-prod
  name: test-ingress
spec:
  tls:
    - hosts:
        - mandrakee.xyz
      secretName: letsencrypt-prod 
  rules:
  - host: mandrakee.xyz
    http:
      paths:
      - backend:
          service:
            name: echo-service
            port: 
              number: 80
        path: /
        pathType: Prefix

issuer.yaml：

apiVersion: cert-manager.io/v1
kind: Issuer
metadata:
  name: letsencrypt-prod
spec:
  acme:
    email: ykaratoprak@sphereinc.com
    server: https://acme-v02.api.letsencrypt.org/directory
    privateKeySecretRef:
      name: letsencrypt-prod
    solvers:
    - dns01:
        digitalocean:
          tokenSecretRef:
            name: digitalocean-dns
            key: ce28952b5b4e33ea7d98de190f3148a7cc82d31f030bde966ad13b22c1abc524

Answer 1

如果您已经正确地设置了您的发行者，您已经向我们保证，您将在您的名称空间中看到一个属于cert管理器的荚。这将创建一个pod，以验证请求证书的服务器是否解析为DNS记录。

在您的案例中，您需要将DNS指向您的入口。

如果成功地完成了这一任务，那么下一个调试阶段就是验证443和80都可以解决。由Cert Manager创建的验证Pod使用端口80验证通信。人们犯的一个常见错误是，假设他们将只对ssl使用端口443，而出于安全原因而禁用80，以便稍后发现如果没有端口80，letsencrypt无法验证主机名。

否则，常见的情况是证书管理器安装在名称空间cert-manager中，因此您应该检查管理器的日志。这将提供有限数量的日志，有时难以找到解决问题的方法。

要查找直接错误，cert管理器在您部署的名称空间中生成的结荚是一个很好的焦点。

我将运行的一个测试是使用80和443设置入口，如果您在浏览器中使用域，您应该在端口443上得到一些无效的kubernetes通用证书响应，而只是在端口80上“找不到”。如果这是成功的，它排除了我前面提到的限制。