Есть ли способ определить, к какому хосту etcd обращается аписервер kubernetes? - PullRequest
Новая
       107

Есть ли способ определить, к какому хосту etcd обращается аписервер kubernetes?

0 голосов
/ 15 мая 2018

Только apiserver общается напрямую с etcd.В кластере etcd много хостов.Я хотел бы видеть, к какому хосту etcd обращается аписервер.Это может отличаться для каждого ресурса API, такого как Pod или Node.Я предпочитаю видеть информацию о хосте etcd для каждого запроса.

В частности, kubernetes 1.6.13 и etcd 3.1.14 с использованием магазина v3.

Я пробовал:

  1. Включить клиент etcd и вход в систему grpcсервер api kubernetnes.

    Я думаю, что grpc регистрирует только непредвиденные события.Аналогично для etcd clientv3.Мне не удалось получить информацию о стороне соединения etcd.

  2. Включить ведение журнала отладки http2 с помощью GODEBUG=http2debug=2 на сервере api

    К моему удивлению, журналы отладки http2напечатать много информации о каждом запросе, но я не смог найти информацию об удаленной конечной точке.Я все еще скептически отношусь к этому, я могу пропустить упоминание в файлах журнала.Не совсем уверен.

  3. Отладка журналов на стороне etcd.

    Включение журналов отладки с помощью Включение ведения журнала отладки печатает только о доступах к хранилищу v2.Для v3 store можно использовать конечную точку http://<host>2379/debug/requests, но это не доступно в моей версии etcd 3.1.14.

  4. Я еще не пробовал использовать GODEBUG=http2debug=2 на стороне etcd.Может быть, в логах http2 на etcd есть информация, которая мне нужна.

  5. tcpdump или tcpflow

    Подключение apiserver <-> etcd зашифровано.Покажут ли они мне URL запроса?Я думаю Я не видел эту информацию в дампах.

  6. Человек в середине атакует соединение apiserver <-> etcd с mitmproxy ,Я не думаю, что это должно быть так сложно.

Надеюсь, я упустил супер очевидный и простой способ сделать это.

Обновление:

Об использовании lsof подходов:

Используя lsof, мы можем перечислить соединения с информацией о конечных точкахв одно времяЯ не думаю, что в выводе lsof достаточно информации для получения информации о конечной точке для каждого запроса.Apiserver открывает множество соединений с etcd.Глядя на код, это наблюдение выглядит разумным для меня.См. NewStorage в здесь 

$ sudo lsof -p 20816 | grep :2379  | wc -l
130

Соединения выглядят следующим образом

$ sudo lsof - 

p 20816 | grep :2379  | head -n 5
hyperkube 20816 root    3u     IPv4 58093240        0t0        TCP compute-master7001.dsv31.boxdc.net:36360->compute-etcd7001.dsv31.boxdc.net:2379 (ESTABLISHED)
hyperkube 20816 root    5u     IPv4 58085987        0t0        TCP compute-master7001.dsv31.boxdc.net:26005->compute-etcd7002.dsv31.boxdc.net:2379 (ESTABLISHED)
hyperkube 20816 root    6u     IPv4 58085988        0t0        TCP compute-master7001.dsv31.boxdc.net:55650->compute-etcd7003.dsv31.boxdc.net:2379 (ESTABLISHED)
hyperkube 20816 root    7u     IPv4 58102030        0t0        TCP compute-master7001.dsv31.boxdc.net:36366->compute-etcd7001.dsv31.boxdc.net:2379 (ESTABLISHED)
hyperkube 20816 root    8u     IPv4 58085990        0t0        TCP compute-master7001.dsv31.boxdc.net:55654->compute-etcd7003.dsv31.boxdc.net:2379 (ESTABLISHED)
........

Глядя на это, яне может знать, какой etcd используется для каждого запроса между apiserver и etcd.

Обновление:

Я думаю, что в коде клиента etcdv3, который поставляется с kubernetes 1.6.13, функция grpc.Balancer.Get возвращает адрес конечной точки, используемый для каждогозапрос GRCP.Я думаю можно добавить распечатку журнала здесь и сделать так, чтобы apiserver регистрировал адрес etcd для каждого запроса.

1 Ответ

0 голосов
/ 16 мая 2018

Найти пид аписервер

ps aux | grep apiserver

Затем используйте lsof, чтобы увидеть соединения с открытым сокетом

lsof -p $PID | grep :2379

...