Kube dns не будет подключаться к процессу Kubernetes api

Запуск kubernetes v1.10.0 amd kube-dns с использованием контейнера gcr.io/google_containers/k8s-dns-kube-dns-amd64:1.14.8

При запуске контейнера kube-dns в журнале записывается следующее:

I0610 06:47:06.051414       1 round_trippers.go:398] curl -k -v -XGET  -H "User-Agent: kube-dns/1.14.10 (linux/amd64)" -H "Authorization: Bearer eyJhbGciOiJSUzI1NiIsInR5cCI6Ikp... rest of barer token" -H "Accept: application/vnd.kubernetes.protobuf, */*" https://172.17.0.1:443/api/v1/services?resourceVersion=0
`E0610 06:47:05.058513       1 reflector.go:201] k8s.io/dns/pkg/dns/dns.go:189: Failed to list *v1.Endpoints: Get https://172.17.0.1:443/api/v1/endpoints?resourceVersion=0: x509: certificate signed by unknown authority (possibly because of "crypto/rsa: verification error" while trying to verify candidate authority certificate "10.16.23.40")`

10.16.23.40 - это "реальный" адрес моего мастера, 172.17.0.1 - служебный адрес мастера.

У меня есть самоподписанный сертификат на apiserver, который по понятным причинам вызывает обычные ошибки проверки при доступе с помощью curl (из команды строка ничего), без -k. Однако вывод kube-dns, похоже, подразумевает, что используется -k, хотя я не могу найти доказательств того, что curl действительно существует в контейнере, что наводит меня на мысль, что двоичный curl на самом деле не вызывается, но команда curl просто вывод в «помощь». Существование toCurl в round_trippers.go, кажется, подтверждает эту теорию.

Глядя на результат, да, сертификат является самоподписанным, и, следовательно, «подписанный неизвестным органом власти» имеет определенный смысл, но если он выполняет вызов с помощью -k (или любого другого его эквивалента в коде), тогда это не должно быть проблемой.

Вот некоторые соответствующие строки в сертификате:

Subject: C=UK, ST=Blah, L=Blah, O=system:nodes, OU=Blah, CN=10.16.23.40

И

X509v3 Subject Alternative Name: 
                DNS:kubernetes, DNS:kubernetes.default, DNS:kubernetes.default.svc, DNS:kubernetes.default.svc.cluster, DNS:kubernetes.default.svc.cluster.local, DNS:cluster.local, DNS:k8s.blah.net, IP Address:10.16.23.40, IP Address:172.17.0.1

Естественно все остальное, что необходимо доступ к apiserver (например, kubectl) выполняется без проблем и без каких-либо ошибок проверки.

Любые указания о том, как заставить kube-dns разговаривать с apiserver, были бы весьма признательны.

Заранее спасибо