Istio: Ingress для ACME-вызова не работает (503) - PullRequest
1 голос
/ 16 апреля 2019

Мы запускаем Istio 1.1.3 на узлах кластера 1.12.5-gke.10.

Мы используем certmanager для управления нашими зашифрованными сертификатами.

apiVersion: certmanager.k8s.io/v1alpha1
kind: Certificate
metadata:
  name: certs.ourdomain.nl
  namespace: istio-system
spec:
  secretName: certs.ourdomain.nl
  newBefore: 360h # 15d
  commonName: operations.ourdomain.nl
  dnsNames:
    - operations.ourdomain.nl
  issuerRef:
    name: letsencrypt
    kind: ClusterIssuer
  acme:
    config:
      - http01:
          ingressClass: istio
        domains:
        - operations.ourdomain.nl

Следующая вещь, которую мы видим, это серверная часть acme, развернутая служба (nodeport и ingress). Вход (сгенерированный автоматически) выглядит так:

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  annotations:
    kubernetes.io/ingress.class: istio
  generateName: cm-acme-http-solver-
  generation: 1
  labels:
    certmanager.k8s.io/acme-http-domain: "1734084804"
    certmanager.k8s.io/acme-http-token: "1476005735"
  name: cm-acme-http-solver-69vzw
  namespace: istio-system
  ownerReferences:
  - apiVersion: certmanager.k8s.io/v1alpha1
    blockOwnerDeletion: true
    controller: true
    kind: Certificate
    name: certs.ourdomain.nl
    uid: 751011d2-4fc8-11e9-b20e-42010aa40101
spec:
  rules:
  - host: operations.ourdomain.nl
    http:
      paths:
      - backend:
          serviceName: cm-acme-http-solver-fzk8q
          servicePort: 8089
        path: /.well-known/acme-challenge/dnrcr-LRRMdXhBaUefjqpHQx8ytYuk-feEfXu9gW-Ck
status:
  loadBalancer: {}

Тем не менее, когда мы пытаемся получить доступ к URL-адресу.

У нас есть балансировщик нагрузки для istio:

apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
  labels:
    app: istio-ingress
    chart: gateways-1.1.0
    heritage: Tiller
    istio: ingress
    release: istio
  name: istio-ingress
  namespace: istio-system
spec:
  selector:
    app: istio-ingress
  servers:
  - hosts:
    - operations.ourdomain.nl
    #port:
    #  name: http
    #  number: 80
    #  protocol: HTTP
    #tls:
    #  httpsRedirect: true
  - hosts:
    - operations.ourdomain.nl
    port:
      name: https
      number: 443
      protocol: HTTPS
    tls:
      credentialName: certs.ourdomain.nl
      mode: SIMPLE
      privateKey: sds
     serverCertificate: sds

Эта интересная статья дает хорошее представление о том, как acme-вызов должен работать. В целях тестирования мы удалили порт 80 и перенаправили на https в нашем пользовательском шлюзе. Мы добавили автоматически сгенерированный шлюз k8s, прослушивающий только порт 80.

Istio должен создать виртуальный сервис для acme-challenge. Это, кажется, происходит, потому что теперь, когда мы запрашиваем URL-адрес acme-challenge, мы получаем ошибку 503: восходящее соединение или отключение / сброс перед заголовками. Я полагаю, что это означает, что запрос поступает на шлюз и соответствует виртуальной службе, но нет модуля службы / исправного модуля, на который можно было бы перенаправить трафик.

Мы видим некоторые интересные записи в istio-pilot:

«ProxyStatus»: {«endpoint_no_pod»: { «См-акме-HTTP-решатель-l5j2g.istio-system.svc.cluster.local»: {«Message»: «10.16.57.248»}

Я дважды проверил, и у службы, упомянутой выше, есть модуль, который он предоставляет. Поэтому я не уверен, относится ли эта строка к этой проблеме.

В капсулах, вызывающих акме, нет коляски istio-sidecar. Может ли это быть проблемой? Если так: почему это очевидно работает для других

...