tcp 10.0.2.15:6443: getsockopt: соединение отказано на виртуальных машинах Debian 9 - PullRequest
0 голосов
/ 22 февраля 2019

Я новичок в kubernetes и пытаюсь настроить свой тестовый кластер с одним главным и двумя рабочими узлами на виртуальных машинах Debian 9.до сих пор я установил kubectl, kubeadm и kubelet на всех трех узлах вместе со всеми основными требованиями.Я также установил Docker версии 17.03.

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

   root@Minion1:~# kubeadm join 10.0.2.15:6443 --token kd2o6a.aklftqmvp55m87uf --discovery-token-ca-cert-hash sha256:29bc80e3c298e68077468f00472ae9944597f68374122a2d92e3713262bcf160
    [preflight] Running pre-flight checks.
        [WARNING FileExisting-crictl]: crictl not found in system path
    Suggestion: go get github.com/kubernetes-incubator/cri-tools/cmd/crictl
    [discovery] Trying to connect to API Server "10.0.2.15:6443"
    [discovery] Created cluster-info discovery client, requesting info from "https://10.0.2.15:6443"
[discovery] Failed to request cluster info, will try again: [Get https://10.0.2.15:6443/api/v1/namespaces/kube-public/configmaps/cluster-info: dial tcp 10.0.2.15:6443: getsockopt: connection refused]

Вот результат шага инициализации kubeadm:

 root@Master:/home/kube# kubeadm init
[init] Using Kubernetes version: v1.10.13
[init] Using Authorization modes: [Node RBAC]
[preflight] Running pre-flight checks.
[WARNING FileExisting-crictl]: crictl not found in system path
Suggestion: go get [github.com/kubernetes-incubator/cri-tools/cmd/crictl](http://github.com/kubernetes-incubator/cri-tools/cmd/crictl)
[preflight] Starting the kubelet service
[certificates] Generated ca certificate and key.
[certificates] Generated apiserver certificate and key.
[certificates] apiserver serving cert is signed for DNS names [master kubernetes kubernetes.default kubernetes.default.svc kubernetes.default.svc.cluster.local] and IPs [10.96.0.1 10.0.2.15]
[certificates] Generated apiserver-kubelet-client certificate and key.
[certificates] Generated sa key and public key.
[certificates] Generated front-proxy-ca certificate and key.
[certificates] Generated front-proxy-client certificate and key.
[certificates] Generated etcd/ca certificate and key.
[certificates] Generated etcd/server certificate and key.
[certificates] etcd/server serving cert is signed for DNS names [localhost] and IPs [127.0.0.1]
[certificates] Generated etcd/peer certificate and key.
[certificates] etcd/peer serving cert is signed for DNS names [master] and IPs [10.0.2.15]
[certificates] Generated etcd/healthcheck-client certificate and key.
[certificates] Generated apiserver-etcd-client certificate and key.
[certificates] Valid certificates and keys now exist in "/etc/kubernetes/pki"
[kubeconfig] Wrote KubeConfig file to disk: "/etc/kubernetes/admin.conf"
[kubeconfig] Wrote KubeConfig file to disk: "/etc/kubernetes/kubelet.conf"
[kubeconfig] Wrote KubeConfig file to disk: "/etc/kubernetes/controller-manager.conf"
[kubeconfig] Wrote KubeConfig file to disk: "/etc/kubernetes/scheduler.conf"
[controlplane] Wrote Static Pod manifest for component kube-apiserver to "/etc/kubernetes/manifests/kube-apiserver.yaml"
[controlplane] Wrote Static Pod manifest for component kube-controller-manager to "/etc/kubernetes/manifests/kube-controller-manager.yaml"
[controlplane] Wrote Static Pod manifest for component kube-scheduler to "/etc/kubernetes/manifests/kube-scheduler.yaml"
[etcd] Wrote Static Pod manifest for a local etcd instance to "/etc/kubernetes/manifests/etcd.yaml"
[init] Waiting for the kubelet to boot up the control plane as Static Pods from directory "/etc/kubernetes/manifests".
[init] This might take a minute or longer if the control plane images have to be pulled.
[apiclient] All control plane components are healthy after 24.505250 seconds
[uploadconfig] Storing the configuration used in ConfigMap "kubeadm-config" in the "kube-system" Namespace
[markmaster] Will mark node master as master by adding a label and a taint
[markmaster] Master master tainted and labelled with key/value: [node-role.kubernetes.io/master=](http://node-role.kubernetes.io/master=)""
[bootstraptoken] Using token: kd2o6a.aklftqmvp55m87uf
[bootstraptoken] Configured RBAC rules to allow Node Bootstrap tokens to post CSRs in order for nodes to get long term certificate credentials
[bootstraptoken] Configured RBAC rules to allow the csrapprover controller automatically approve CSRs from a Node Bootstrap Token
[bootstraptoken] Configured RBAC rules to allow certificate rotation for all node client certificates in the cluster
[bootstraptoken] Creating the "cluster-info" ConfigMap in the "kube-public" namespace
[addons] Applied essential addon: kube-dns
[addons] Applied essential addon: kube-proxy

Your Kubernetes master has initialized successfully!

To start using your cluster, you need to run the following as a regular user:

mkdir -p $HOME/.kube
sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
sudo chown $(id -u):$(id -g) $HOME/.kube/config

You should now deploy a pod network to the cluster.
Run "kubectl apply -f [podnetwork].yaml" with one of the options listed at:
https://kubernetes.io/docs/concepts/cluster-administration/addons/

You can now join any number of machines by running the following on each node
as root:

kubeadm join [10.0.2.15:6443](http://10.0.2.15:6443) --token kd2o6a.aklftqmvp55m87uf --discovery-token-ca-cert-hash sha256:29bc80e3c298e68077468f00472ae9944597f68374122a2d92e3713262bcf160

ТакжеНа главном узле я не могу запускать какие-либо команды kubectl, используя пользователя root, но я могу использовать их с другим пользователем ... Это нормально?

Вот проверки сетевого подключения между главным и рабочим узлом.

root@Minion1:~# ping 10.0.2.15
PING 10.0.2.15 (10.0.2.15) 56(84) bytes of data.
64 bytes from 10.0.2.15: icmp_seq=1 ttl=64 time=0.068 ms
64 bytes from 10.0.2.15: icmp_seq=2 ttl=64 time=0.091 ms
64 bytes from 10.0.2.15: icmp_seq=3 ttl=64 time=0.094 ms
^C
--- 10.0.2.15 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2033ms
rtt min/avg/max/mdev = 0.068/0.084/0.094/0.013 ms


root@Master:/home/kube# netstat -ntplu | grep 6443
tcp6       0      0 :::6443                 :::*                    LISTEN      21075/kube-apiserve

Как я могу присоединиться к своим рабочим узлам для мастеринга?Есть ли что-нибудь, что я могу устранить, чтобы избавиться от этой проблемы.

Спасибо за помощь ..

Ответы [ 2 ]

0 голосов
/ 25 февраля 2019

Вы не включили сетевое подключение в свой пост.Вы просто пингуете с рабочего узла на мастер-узел.Пожалуйста, проверьте это Документация , чтобы увидеть необходимые открытые порты между главным и рабочим узлами и настроить их на брандмауэре.Вы можете устранить неполадки с клиентом telnet , например

telnet [host] [port]

или с nc

nc -vz [host] [port]
0 голосов
/ 22 февраля 2019

Установите go binaries и выполните приведенную ниже команду для загрузки crictl

go get github.com/kubernetes-incubator/cri-tools/cmd/crictl
...