Запуск 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, будут очень благодарны.
Заранее спасибо
Я обнаружил, что проблема была на самом деле в диспетчере контроллера. Я указал --master = в командной строке, которая переопределяла значение в файле конфигурации диспетчера контроллеров. Удалено это, перезапущены функции диспетчера контроллеров kube-dns, как и ожидалось. Ошибка проверки при очевидном разговоре с сервером api была отвлекающим маневром.