в Кубернетесе нарушена связь между серверами - PullRequest
Новая
       53

в Кубернетесе нарушена связь между серверами

0 голосов
/ 23 октября 2019

У меня есть собственный 5-ти узловый кластер, работающий на голом металле, и я использую Calico. Кластер работал 22 дня, но внезапно перестал работать. Изучив проблему, я обнаружил, что служба связи с модулем не работает, пока все компоненты работают, и kubectl работает без проблем.

Изнутри кластера (компонент A), если я пытаюсь свернуть другой компонент(bridge) с его IP-адресом он работает: 

$ curl -vvv http://10.4.130.184:9998
* Rebuilt URL to: http://10.4.130.184:9998/
*   Trying 10.4.130.184...
* TCP_NODELAY set
* Connected to 10.4.130.184 (10.4.130.184) port 9998 (#0)
> GET / HTTP/1.1
> Host: 10.4.130.184:9998
> User-Agent: curl/7.58.0
> Accept: */*
> 
< HTTP/1.1 200 OK
< X-Powered-By: Express
< Accept-Ranges: bytes
< Cache-Control: public, max-age=0
< Last-Modified: Mon, 08 Apr 2019 14:06:42 GMT
< ETag: W/"179-169fd45c550"
< Content-Type: text/html; charset=UTF-8
< Content-Length: 377
< Date: Wed, 23 Oct 2019 09:56:35 GMT
< Connection: keep-alive
< 
<!doctype html>
<html lang="en">
<head>
    <meta charset="utf-8" />
    <meta http-equiv="X-UA-Compatible" content="IE=edge,chrome=1" />

    <title>Bridge</title>

    <meta content='width=device-width, initial-scale=1.0, maximum-scale=1.0, user-scalable=0' name='viewport' />
    <meta name="viewport" content="width=device-width" />
</head>
<body>
    <h1>Bridge</h1>
</body>

</html>
* Connection #0 to host 10.4.130.184 left intact

ns поиск службы также работает (он разрешается для IP-адреса службы): 

$ nslookup bridge
Server:    10.5.0.10
Address 1: 10.5.0.10 kube-dns.kube-system.svc.k8s.local

Name:      bridge
Address 1: 10.5.160.50 bridge.170.svc.k8s.local

Но услуга длясвязь с модулем прервана, и когда я в большинстве случаев (60-70%) поворачиваюсь к имени службы, он зависает: 

$ curl -vvv http://bridge:9998
* Rebuilt URL to: http://bridge:9998/
* Could not resolve host: bridge
* Closing connection 0
curl: (6) Could not resolve host: bridge

Когда я проверяю конечные точки этой службы, я вижу, что IP-адресэтот модуль есть: 

$ kubectl get ep -n 170 bridge
NAME     ENDPOINTS                                               AGE
bridge   10.4.130.184:9226,10.4.130.184:9998,10.4.130.184:9226   11d

Но, как я уже сказал, curl (и любой другой метод), использующий имя службы, не работает. И это описание службы: 

$ kubectl describe svc -n 170 bridge
Name:              bridge
Namespace:         170
Labels:            io.kompose.service=bridge
Annotations:       Process: bridge
Selector:          io.kompose.service=bridge
Type:              ClusterIP
IP:                10.5.160.50
Port:              9998  9998/TCP
TargetPort:        9998/TCP
Endpoints:         10.4.130.184:9998
Port:              9226  9226/TCP
TargetPort:        9226/TCP
Endpoints:         10.4.130.184:9226
Port:              9226-udp  9226/UDP
TargetPort:        9226/UDP
Endpoints:         10.4.130.184:9226
Session Affinity:  None
Events:            <none>

Эта проблема не ограничивается только этим компонентом, и это относится ко всем компонентам.

Я перезапустил CoreDNS (удалил его модули)но это все то же самое. Я сталкивался с этой проблемой раньше, и в прошлый раз я думал, что это связано с Weavenet, который я использовал, и мне нужен был кластер, поэтому я сорвал кластер и перестроил его с помощью Calico, но теперь я уверен, что это не связано с CNI иэто что-то еще.

Среда : - Версия Kubernetes (используйте kubectl version): 

Client Version: version.Info{Major:"1", Minor:"14", GitVersion:"v1.14.1", GitCommit:"b7394102d6ef778017f2ca4046abbaa23b88c290", GitTreeState:"clean", BuildDate:"2019-04-08T17:11:31Z", GoVersion:"go1.12.1", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"16", GitVersion:"v1.16.0", GitCommit:"2bd9643cee5b3b3a5ecbd3af49d09018f0773c77", GitTreeState:"clean", BuildDate:"2019-09-18T14:27:17Z", GoVersion:"go1.12.9", Compiler:"gc", Platform:"linux/amd64"}

  • Конфигурация поставщика облачных вычислений или аппаратного обеспечения: Это простоМеталлический кластер из 5 узлов, 1 мастер и 4 рабочих. Все узлы работают под управлением Ubuntu 18.04 и подключаются к одной подсети.

  • ОС (например: cat /etc/os-release): 

NAME="Ubuntu"
VERSION="18.04.2 LTS (Bionic Beaver)"
ID=ubuntu
ID_LIKE=debian
PRETTY_NAME="Ubuntu 18.04.2 LTS"
VERSION_ID="18.04"
HOME_URL="https://www.ubuntu.com/"
SUPPORT_URL="https://help.ubuntu.com/"
BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/"
PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy"
VERSION_CODENAME=bionic
UBUNTU_CODENAME=bionic
  • Ядро (например, uname -a): 
Linux serflex-argus-1 4.15.0-55-generic #60-Ubuntu SMP Tue Jul 2 18:22:20 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

  • Установочные инструменты: Kubeadm

  • Сетевой плагин и версия(если это ошибка, связанная с сетью): Calico "cniVersion": "0.3.1"

Обновление

После удаления всех проблем с модулями kube-proxy показалась проблемапредстоит решить, но я все еще хотел бы знать, что вызвало эту проблему. Кстати, я не увидел ни одной ошибки в логах kube-proxy.

...