#kubernetes #kubelet #kubernetes-dashboard #calico
#kubernetes #kubelet #kubernetes-панель управления #calico
Вопрос:
У меня есть кластер Kubernetes в vagrant (1.14.0) и установлен calico.
Я установил панель управления kubernetes. Когда я использую kubectl proxy для посещения панели мониторинга:
Error: 'dial tcp 192.168.1.4:8443: connect: connection refused'
Trying to reach: 'https://192.168.1.4:8443/'
Вот мои модули (панель управления часто перезапускается):
$ kubectl get pods -n kube-system
NAME READY STATUS RESTARTS AGE
calico-etcd-cj928 1/1 Running 0 11m
calico-node-4fnb6 1/1 Running 0 18m
calico-node-qjv7t 1/1 Running 0 20m
calico-policy-controller-b9b6749c6-29c44 1/1 Running 1 11m
coredns-fb8b8dccf-jjbhk 1/1 Running 0 20m
coredns-fb8b8dccf-jrc2l 1/1 Running 0 20m
etcd-k8s-master 1/1 Running 0 19m
kube-apiserver-k8s-master 1/1 Running 0 19m
kube-controller-manager-k8s-master 1/1 Running 0 19m
kube-proxy-8mrrr 1/1 Running 0 18m
kube-proxy-cdsr9 1/1 Running 0 20m
kube-scheduler-k8s-master 1/1 Running 0 19m
kubernetes-dashboard-5f7b999d65-nnztw 1/1 Running 3 2m11s
журналы модуля dasbhoard:
2019/03/30 14:36:21 Error while initializing connection to Kubernetes apiserver. This most likely means that the cluster is misconfigured (e.g., it has invalid apiserver certificates or service account's configuration) or the --apiserver-host param points to a server that does not exist. Reason: Get https://10.96.0.1:443/version: dial tcp 10.96.0.1:443: i/o timeout
Refer to our FAQ and wiki pages for more information: https://github.com/kubernetes/dashboard/wiki/FAQ
Я могу использовать telnet как с главного, так и с узлов до 10.96.0.1: 443.
Что настроено неправильно? Остальная часть кластера, похоже, работает нормально, хотя я вижу эти журналы в kubelet:
failed to load Kubelet config file /var/lib/kubelet/config.yaml, error failed to read kubelet config file "/var/lib/kubelet/config.yaml"
kubelet, похоже, отлично работает на главном сервере.
Кластер был создан с помощью этой команды:
kubeadm init --apiserver-advertise-address="192.168.50.10" --apiserver-cert-extra-sans="192.168.50.10" --node-name k8s-master --pod-network-cidr=192.168.0.0/16
Ответ №1:
вы должны определить свое имя хоста в /etc/hosts
#hostname
YOUR_HOSTNAME
#nano /etc/hosts
YOUR_IP HOSTNAME
если вы задали имя хоста в своем главном компьютере, но это не сработало, попробуйте
# systemctl stop kubelet
# systemctl stop docker
# iptables --flush
# iptables -tnat --flush
# systemctl start kubelet
# systemctl start docker
и вам следует установить панель управления, прежде чем присоединяться к рабочему узлу
и отключить брандмауэр
и вы можете проверить свою свободную оперативную память.
Комментарии:
1. добавление имени хоста сработало, можете ли вы объяснить, почему я должен был это сделать?
2. В kubernetes все определяется по имени, потому что когда модуль уничтожается, он получает другой IP, поэтому мы должны определить наше имя хоста, а шнуры просто работают с именем хоста, а не с IP, и если вы получите журнал своих шнуров до того, как увидите в нем ошибку
3. У меня все еще возникают проблемы с этим. Весь этот список прекрасен, за исключением того, что я уже присоединился к рабочим узлам. Есть идеи, как я все еще могу настроить панель мониторинга с подключенными рабочими узлами?
Ответ №2:
Исключить параметр — node-name из команды инициализации kubeadm
попробуйте эту команду
kubeadm init --apiserver-advertise-address=$(hostname -i) --apiserver-cert-extra-sans="192.168.50.10" --pod-network-cidr=192.168.0.0/16
Комментарии:
1. это не помогло :/
Ответ №3:
Для меня проблема заключалась в том, что мне нужно было создать сетевую политику, которая разрешала исходящий трафик к API kubernetes