Мы запускаем 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. Может ли это быть проблемой? Если так: почему это очевидно работает для других