kubernetes - 在k8s上的drone.io。 letsencrypt无法提供安全的连接

Question

我正在使用 Helm 在gke k8s上部署drone.io。如果我关闭了LetsEncrypt，则效果很好。但是我真的很想要https支持。

这是我的服务:

apiVersion: v1
kind: Service
metadata:
  name: {{ template "drone_ci.fullname" . }}-external
  labels:
    name: server
    app: {{ template "drone_ci.name" . }}
    chart: {{ .Chart.Name }}-{{ .Chart.Version | replace "+" "_" }}
    release: {{ .Release.Name }}
    heritage: {{ .Release.Service }}
spec:
  type: LoadBalancer
  loadBalancerIP:  {{ .Values.droneLoadBalancerIp}}
  ports:
    - name: http
      protocol: TCP
      port: 80
      targetPort: 8000
    - name: https
      protocol: TCP
      port: 443
      targetPort: 443
  selector:
    name: server

我为端口9000提供了另一项服务，因为仅无人机代理才需要。

我的无人机服务器部署模板如下所示:

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: {{ template "drone_ci_server.fullname" . }}
  labels:
    app: {{ template "drone_ci.name" . }}
    chart: {{ .Chart.Name }}-{{ .Chart.Version | replace "+" "_" }}
    release: {{ .Release.Name }}
    heritage: {{ .Release.Service }}
spec:
  replicas: 1
  template:
    metadata:
      labels:
        name: server
        app: {{ template "drone_ci.name" . }}
        release: {{ .Release.Name }}
    spec:
      containers:
      - name: server
        image: "{{ .Values.server.image.repository }}:{{ .Values.server.image.tag }}"
        imagePullPolicy: {{ .Values.server.image.pullPolicy }}
        env:
          - name: "DRONE_HOST"
            value: {{ .Values.droneHost }}
          - name: "DRONE_OPEN"
            value: "true"
          - name: "DRONE_GITLAB"
            value: "true"
          - name: DRONE_GITLAB_URL
            value: {{ .Values.droneGitlabUrl }}
          - name: DRONE_ADMIN
            value: {{ .Values.droneAdmin }}
          - name: DRONE_GITLAB_CLIENT
            valueFrom:
              secretKeyRef:
                name: {{ template "drone_ci.fullname" . }}
                key: DRONE_GITLAB_CLIENT
          - name: DRONE_GITLAB_SECRET
            valueFrom:
              secretKeyRef:
                name: {{ template "drone_ci.fullname" . }}
                key: DRONE_GITLAB_SECRET
          - name: DRONE_SECRET
            valueFrom:
              secretKeyRef:
                name: {{ template "drone_ci.fullname" . }}
                key: DRONE_SECRET
          - name: DRONE_LETS_ENCRYPT
            value: "true"
        volumeMounts:
        - mountPath: /var/lib/drone
          name: drone-lib-pv-storage
      volumes:
      - name: drone-lib-pv-storage
        persistentVolumeClaim:
          claimName: {{ template "drone_ci.fullname" . }}

当letsEncrypt为false时，我的网站可以正常工作，并且可以正确地连接到我的gitlab实例。当letsEncrypt为true时:

导航至Chrome中的无人机后，我看到“此站点无法提供安全的连接”。 ssllab't test告诉我:

No secure protocols supported - if you get this message, but you know that the site supports SSL, wait until the cache expires on its own, then try again, making sure the hostname you enter uses the "www" prefix (e.g., "www.ssllabs.com", not just "ssllabs.com").
no more data allowed for version 1 certificate - the certificate is invalid; it is declared as version 1, but uses extensions, which were introduced in version 3. Browsers might ignore this problem, but our parser is strict and refuses to proceed. We'll try to find a different parser to avoid this problem.
Failed to obtain certificate and Internal Error - errors of this type will often be reported for servers that use connection rate limits or block connections in response to unusual traffic. Problems of this type are very difficult to diagnose. If you have access to the server being tested, before reporting a problem to us, please check that there is no rate limiting or IDS in place.
NetScaler issues - some NetScaler versions appear to reject SSL handshakes that do not include certain suites or handshakes that use a few suites. If the test is failing and there is a NetScaler load balancer in place, that's most likely the reason.
Unexpected failure - our tests are designed to fail when unusual results are observed. This usually happens when there are multiple TLS servers behind the same IP address. In such cases we can't provide accurate results, which is why we fail.

查看我的pod日志，每次尝试通过chrome访问无人机时，我都会得到:

http: TLS handshake error from x.x.x.x:53938: acme/autocert: no supported challenge type found
http: TLS handshake error from y.y.y.y:53936: acme/autocert: missing certificate

我的无人机服务器镜像是:

image:
  repository: drone/drone
  tag: 0.8
  pullPolicy: Always

我想念什么或做错什么？

Answer 1

我建议您从LoadBalancer类型服务切换为常规服务，而应通过Ingress公开它。将Ingress与kube-lego耦合，您将获得很好的支持，可以通过琐碎的方式轻松地公开您想要的任何内容，让我们加密所使用域的集成，即使背后的软件没有内置对LE的支持。实际上，这就是我自己的drone.io实例的设置方式。

尽管这可能无法解决问题的根本原因，但可能需要更多调试信息，但这是一个完全可行且经过验证的解决方案:)

至于错误本身，从this code看来，除了tls-sni-01 / 02以外，无人机中没有其他挑战支持。除了群集级别的其他问题外，还有this issue和TLS-SNI已被LE禁用