Проблемы с пониманием вывода dmesg на узлах с кластером Kubernetes на виртуальных машинах ESX - PullRequest
0 голосов
/ 21 января 2020

Я настроил тестовый кластер Kubernetes, работающий на виртуальных машинах на ESX, благодаря kubespray. В файле конфигурации я сказал Kubespray настроить мой кластер с ситцом в виде CNI с CIDR по умолчанию.

Когда я получаю доступ к виртуальной машине с помощью vSphere или запускаю команду dmesg на своих виртуальных машинах, у меня есть этот вывод на моем ведущем устройстве:

[2866556.027837] IPVS: rr: TCP 10.233.13.12:443 - no destination available
[2866556.857464] IPVS: rr: TCP 10.233.13.12:443 - no destination available
[2866557.029471] IPVS: rr: TCP 10.233.13.12:443 - no destination available
[2866688.881160] IPVS: __ip_vs_del_service: enter
[2866689.018851] IPVS: __ip_vs_del_service: enter
[2866689.023030] IPVS: __ip_vs_del_service: enter
[2866689.188072] IPVS: __ip_vs_del_service: enter
[2866689.416153] IPVS: __ip_vs_del_service: enter
[2866689.420334] IPVS: __ip_vs_del_service: enter
[2866692.005599] IPVS: __ip_vs_del_service: enter
[2866692.010260] IPVS: __ip_vs_del_service: enter
[2866692.257045] IPVS: __ip_vs_del_service: enter
[2866692.265034] IPVS: __ip_vs_del_service: enter
[2866692.267455] IPVS: __ip_vs_del_service: enter
[2866692.267493] IPVS: __ip_vs_del_service: enter
[2866916.815472] IPVS: rr: TCP 10.233.49.127:443 - no destination available
[2866916.820841] IPVS: rr: TCP 10.233.49.127:443 - no destination available
[2866916.823418] IPVS: rr: TCP 10.233.49.127:443 - no destination available
[2866916.824167] IPVS: rr: TCP 10.233.49.127:443 - no destination available
[2866916.826243] IPVS: rr: TCP 10.233.49.127:443 - no destination available

и этот вывод на моем работнике

[1207664.350374] IPVS: rr: TCP 10.233.3.61:8080 - no destination available
[1207664.422584] IPVS: rr: TCP 10.233.3.61:8080 - no destination available
[1207667.108560] net_ratelimit: 13 callbacks suppressed
[1207667.108567] IPVS: rr: TCP 10.233.3.61:8080 - no destination available
[1207667.217235] IPVS: rr: TCP 10.233.3.61:8080 - no destination available
[1207667.274593] IPVS: rr: TCP 10.233.3.61:8080 - no destination available
[1207667.331658] IPVS: rr: TCP 10.233.3.61:8080 - no destination available
[1207668.218597] IPVS: rr: TCP 10.233.3.61:8080 - no destination available
[1207668.334613] IPVS: rr: TCP 10.233.3.61:8080 - no destination available
[1207675.500914] IPVS: rr: TCP 10.233.49.141:8086 - no destination available
[1207676.502566] IPVS: rr: TCP 10.233.49.141:8086 - no destination available
[1207676.628377] IPVS: rr: TCP 10.233.49.141:8086 - no destination available
[1208009.456587] blk_update_request: I/O error, dev fd0, sector 0
[1208009.924355] blk_update_request: I/O error, dev fd0, sector 0
[1208058.699578] blk_update_request: I/O error, dev fd0, sector 0
[1208240.706522] IPVS: Creating netns size=2048 id=289
[1208241.432437] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
[1208241.445496] IPv6: ADDRCONF(NETDEV_UP): cali6ef7aa1f11f: link is not ready
[1208241.447406] IPv6: ADDRCONF(NETDEV_CHANGE): cali6ef7aa1f11f: link becomes ready
[1208241.447469] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready

Мне действительно трудно понять эти журналы. Кажется, он связан с ситцом для сообщения с IPVS : rr, и каждый IP-адрес соответствует IP-адресу службы в кластере. Но я не настроил ни одного узла в моем файле инвентаризации под [calico-rr], так как он является дополнительным, и он здесь для улучшения связи BGP между большими кластерами.

[all]
m1 ansible_host=x.x.x.x ip=x.x.x.x
m2 ansible_host=x.x.x.x ip=x.x.x.x
w1 ansible_host=x.x.x.x ip=x.x.x.x
w2 ansible_host=x.x.x.x ip=x.x.x.x
w3 ansible_host=x.x.x.x ip=x.x.x.x

[kube-master]
m1
m2

[etcd]
m1
m2
w1

[kube-node]
w1
w2
w3

[calico-rr]

[k8s-cluster:children]
kube-master
kube-node
calico-rr

Насколько я понял, это вывод это появляется во время настройки новых модулей и служб, когда я применяю файлы yaml для установки linkerd. Это связано с проверкой готовности? Сообщения появляются, пока сервис / модули не готовы?

Реальная проблема в том, что эти журналы спамят консоль на vSphere, и я действительно не знаю, как от них избавиться.

Я искал дополнительную информацию о других потоках, но то, что я нашел, не очень помогло.

ОБНОВЛЕНИЕ:

У меня есть больше информации об ошибках IPVS: rr. https://kubernetes.io/blog/2018/07/09/ipvs-based-in-cluster-load-balancing-deep-dive/ Он связан с балансировкой нагрузки IPVS, используемой kube-proxy.

Но я до сих пор не знаю, как не сохранять эти журналы на моей консоли ESX через vSphere.

ОБНОВЛЕНИЕ 2:

для установки Kubernetes с Kubespray, я просто следовал приведенному ниже руководству и изменил файл инвентаризации, как описано выше.

ОС VM: Centos 7.7 1908

Версия Kubernetes: 1.16.3

Версия Kubespray: выпуск-2.12

Руководство по началу работы с Kubespray: https://github.com/kubernetes-sigs/kubespray/blob/master/docs/getting-started.md

...