CoreDNS никогда не запускается в моем кластере RPi Kubernetes

#docker #kubernetes #dns #raspberry-pi #weave

#docker #kubernetes #dns #raspberry-pi #переплетение

Вопрос:

Я пытался настроить кластер из 4 Raspberry Pi 4s для запуска Kubernetes, следуя старому руководству. Я уже делал это один раз, успешно. Но после переезда и некоторых других изменений я решил воссоздать кластер со свежими установками Raspberry Pi OS и последней версии kubeadm (1.19) и т. Д. Единственное исключение заключается в том, что я использую Weave 2.6.5 вместо latest в этом комментарии, поскольку, похоже, новейшая версия Weave не работает на Pis — что я подтвердил сам.

К сожалению, после совершенно новых, свежих установок всего, кажется, что модули CoreDNS никогда не появятся. Weave.net подошел успешно. Но CoreDNS никогда не запускается. Вот список моих запущенных модулей:

 $ k get pods -n kube-system
NAME                                   READY   STATUS    RESTARTS   AGE
coredns-f9fd979d6-6jlq7                0/1     Running   0          6m4s
coredns-f9fd979d6-qqnzw                0/1     Running   0          6m5s
etcd-k8s-master-1                      1/1     Running   0          24m
kube-apiserver-k8s-master-1            1/1     Running   0          24m
kube-controller-manager-k8s-master-1   1/1     Running   2          24m
kube-proxy-dq62m                       1/1     Running   0          24m
kube-scheduler-k8s-master-1            1/1     Running   2          24m
weave-net-qb7t7                        2/2     Running   0          17m
  

Также немного странно, что kube-controller-manager и kube-scheduler периодически перезагружаются, но мне интересно, не связано ли это с тем фактом, что DNS никогда не появляется? В любом случае, вот образец журналов pod для контейнеров DNS:

 $ k logs -n kube-system pod/coredns-f9fd979d6-6jlq7
.:53
[INFO] plugin/reload: Running configuration MD5 = db32ca3650231d74073ff4cf814959a7
CoreDNS-1.7.0
linux/arm, go1.14.4, f59c03d
[INFO] plugin/ready: Still waiting on: "kubernetes"
[INFO] plugin/ready: Still waiting on: "kubernetes"
I1027 17:22:37.977315       1 trace.go:116] Trace[1427131847]: "Reflector ListAndWatch" name:pkg/mod/k8s.io/client-go@v0.18.3/tools/cache/reflector.go:125 (started: 2020-10-27 17:22:07.975379387  0000 UTC m= 0.092116055) (total time: 30.00156301s):
Trace[1427131847]: [30.00156301s] [30.00156301s] END
I1027 17:22:37.977301       1 trace.go:116] Trace[2019727887]: "Reflector ListAndWatch" name:pkg/mod/k8s.io/client-go@v0.18.3/tools/cache/reflector.go:125 (started: 2020-10-27 17:22:07.976078211  0000 UTC m= 0.092814546) (total time: 30.000710725s):
Trace[2019727887]: [30.000710725s] [30.000710725s] END
E1027 17:22:37.977433       1 reflector.go:178] pkg/mod/k8s.io/client-go@v0.18.3/tools/cache/reflector.go:125: Failed to list *v1.Namespace: Get "https://10.96.0.1:443/api/v1/namespaces?limit=500amp;resourceVersion=0": dial tcp 10.96.0.1:443: i/o timeout
E1027 17:22:37.977471       1 reflector.go:178] pkg/mod/k8s.io/client-go@v0.18.3/tools/cache/reflector.go:125: Failed to list *v1.Service: Get "https://10.96.0.1:443/api/v1/services?limit=500amp;resourceVersion=0": dial tcp 10.96.0.1:443: i/o timeout
I1027 17:22:37.978491       1 trace.go:116] Trace[911902081]: "Reflector ListAndWatch" name:pkg/mod/k8s.io/client-go@v0.18.3/tools/cache/reflector.go:125 (started: 2020-10-27 17:22:07.97561805  0000 UTC m= 0.092354423) (total time: 30.002742659s):
Trace[911902081]: [30.002742659s] [30.002742659s] END
E1027 17:22:37.978535       1 reflector.go:178] pkg/mod/k8s.io/client-go@v0.18.3/tools/cache/reflector.go:125: Failed to list *v1.Endpoints: Get "https://10.96.0.1:443/api/v1/endpoints?limit=500amp;resourceVersion=0": dial tcp 10.96.0.1:443: i/o timeout
[INFO] plugin/ready: Still waiting on: "kubernetes"
[INFO] plugin/ready: Still waiting on: "kubernetes"
  

Как разработчик приложений, я использовал Kubernetes и люблю его. Но я должен признаться, когда я вникаю в суть того, что он делает (читай: когда он не работает), я чувствую, что теряюсь. Локальный IP-адрес моего Pi — 192.168.1.194. Фактически все локальные IP-адреса находятся в диапазоне 192.168.x.x. Итак, почему кажется, что он пытается получить доступ к 10.96.0.1, а затем получить тайм-аут ввода-вывода? Это нормально? Это просто часть внутренних компонентов сети Docker, например, поддельный IP-адрес, сопоставленный с системой Docker или что-то в этом роде?

И что еще более важно, что мне может понадобиться сделать, чтобы заставить DNS работать? Естественно, я могу все исправить с консоли, поэтому DNS работает на Pi. Ранее во время настройки я также выполнял следующие команды:

 sudo iptables -P FORWARD ACCEPT
sudo ufw allow 8080
sudo ufw allow 16443
sudo ufw allow ssh
sudo ufw default allow routed
sudo ufw enable
  

По моему опыту, этих нескольких команд было достаточно, чтобы «отключить» DNS от работы, но, к сожалению, на этот раз этого кажется недостаточно, поскольку контейнеры CoreDNS никогда не бывают полностью готовы.

Я рад предоставить любые дополнительные сообщения журнала, которые могут быть полезны.

Комментарии:

1. Какой сетевой плагин вы используете? Как вы раскручиваете кластер k8s? похоже, 10.96.0.1 — это ваш IP-адрес сервера kube-apiserver. Вам нужна внутренняя DNS-система K8s для правильного обнаружения служб и так далее. Попробуйте: curl 10.96.0.1:443/version с ваших узлов — Вы использовали: —bind-address или —advertise-address во время установки? Проверьте журналы модуля kube-apiserver!

2. Как упоминалось выше, я использую weave-net 2.6.5 в качестве сетевого плагина. И я установил сам Kubernetes, просто установив kubeadm, а затем запустив инициализацию kubeadm. В первой ссылке , которой я поделился, есть более обширный список команд, которые я запускал. Я уверен, что я не использовал ни один из двух упомянутых вами аргументов (bind-address или advertise-address), и на самом деле я даже не уверен, к чему это аргументы? Похоже, они не являются аргументами для инициализации kubeadm.

Ответ №1:

Я понял это… Я манекен. Я разрешил порт 16443 через брандмауэр (ufw), но я должен был разрешить 6443. Открытие этого порта все исправило.