Я собираюсь сделать это простым и спросить, есть ли способ узнать, какой модуль имеет активное соединение с конечной точкой, такой как конечная точка базы данных?
Мой кластер содержит несколько сотен пространств имен, и мой провайдер базы данных только что сказал мне, что максимальное количество подключений почти достигнуто, и я хочу точно определить модули, которые одновременно используют несколько подключений к нашей конечной точке базы данных.
Я вижу из своего кластера базы данных, что соединения поступают с IP-адреса моего узла кластера ... но он не говорит, какие модули ... а у меня довольно много модулей ...
Спасибо за помощь
Вы правы, мне нужно больше мониторинга, но эти соединения не совсем интуитивно понятны.
Вы уже пробовали способ получения этой статистики, предложенный Рико? Я старался точно следовать им, шаг за шагом, и у меня это не сработало.
netstat не вернул какое-либо установленное соединение с нашей конечной точкой базы данных ... так что ... это тоже не сработало

Самый простой способ - запустить netstat на всех ваших узлах Kubernetes:
$ netstat -tunaple | grep ESTABLISHED | grep <ip address of db provider>
Последний столбец - это столбец PID/Program name, и это программа, которая выполняется в контейнере (с другим внутренним PID контейнера) в вашем модуле на этом конкретном узле. Есть много разных способов узнать, что это за контейнер / под. Например,
# Loop through all containers on the node with
$ docker top <container-id>
Затем после того, как вы найдете идентификатор контейнера, если вы просмотрите все свои поды:
$ kubectl get pod <pod-id> -o=yaml
А статус можно узнать, например:
status:
conditions:
- lastProbeTime: null
lastTransitionTime: 2018-11-09T23:01:36Z
status: "True"
type: Initialized
- lastProbeTime: null
lastTransitionTime: 2018-11-09T23:01:38Z
status: "True"
type: Ready
- lastProbeTime: null
lastTransitionTime: 2018-11-09T23:01:38Z
status: "True"
type: ContainersReady
- lastProbeTime: null
lastTransitionTime: 2018-11-09T23:01:36Z
status: "True"
type: PodScheduled
containerStatuses:
- containerID: docker://f64425b3cd0da74a323440bcb03d8f2cd95d3d9b834f8ca5c43220eb5306005d
Каждый контейнер использует свое собственное сетевое пространство имен, поэтому для проверки сетевого подключения внутри пространства имен контейнера вам необходимо запустить команду внутри этого пространства имен.
К счастью, все контейнеры в модуле используют одно и то же сетевое пространство имен, поэтому вы можете добавить в модуль небольшой дополнительный контейнер, который печатается в журнале открытых подключений.
В качестве альтернативы вы можете запустить команду netstat внутри модуля (если она есть в файловой системе модуля):
kubectl get pods | grep Running | awk '{ print $1 }' | xargs -I % sh -c 'echo == Pod %; kubectl exec -ti % -- netstat -tunaple' >netstat.txt
# or
kubectl get pods | grep Running | awk '{ print $1 }' | xargs -I % sh -c 'echo == Pod %; kubectl exec -ti % -- netstat -tunaple | grep ESTABLISHED' >netstat.txt
После этого у вас на диске будет файл (netstat.txt) со всей информацией о подключениях в подах.
Третий способ - это самый сложный. Вам нужно найти идентификатор контейнера с помощью docker ps и выполнить следующую команду, чтобы получить PID
$ pid = "$(docker inspect -f '{{.State.Pid}}' "container_name | Uuid")"
Затем вам нужно создать именованное пространство имен: (вы можете использовать любое имя или имя_контейнера / Uuid / Pod_Name в качестве замены namespace_name)
sudo mkdir -p /var/run/netns
sudo ln -sf /proc/$pid/ns/net "/var/run/netns/namespace_name"
Теперь вы можете запускать команды в этом пространстве имен:
sudo ip netns exec "namespace_name" netstat -tunaple | grep ESTABLISHED
Вам нужно сделать это для каждого модуля на каждом узле. Таким образом, может быть полезно устранять неполадки в определенных контейнерах, но для вашей задачи требуется дополнительная автоматизация.
Возможно, вам будет полезно установить Istio в свой кластер. Он имеет несколько интересных функций, упомянутых в этом отвечать
Вот еще один способ получить все соединения контейнеров на узле с помощью докера: stackoverflow.com/questions/37171909/…
вам нужно централизованное решение для мониторинга таких подключений и множества других вещей, вы должны увидеть эти вещи до того, как DB вам скажет об этом.