Как получить доступ из одного контейнера в другой контейнер stdout и stderr внутри модуля Kubernetes

У меня есть Pod с двумя контейнерами.

apiVersion: v1
kind: Pod
metadata:
  name: test
spec:
  containers:
  - name: my-container
    image: google/my-container:v1
  - name: third-party
    image:  google/third-party:v1

Один контейнер — это мой образ, а второй — сторонний образ, который я не могу контролировать своим stdout/stderr.
Мне нужно, чтобы my-container обращался к журналам, записанным в стороннем контейнере.
Внутри «my- container" я хочу собрать весь stdout и stderr из "стороннего" контейнера, добавить некоторые метаданные и записать их своим логгером.

Я не могу использовать привилегированный контейнер с VolumeMounts.

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

 containers:
  - name: my-container
    image: google/my-container:v1
    volumeMounts:
    - name: varlog
      mountPath: /var/log

  - name: third-party
    image:  google/third-party:v1 
    stdout: /var/log/stdout
    stderr: /var/log/stderr

 volumes:
  - name: varlog
    emptyDir: {}

kubernetes openshift logging fluentd
person nassi.harel    schedule 17.07.2019    source источник
comment
Вы читали это? kubernetes.io/docs/concepts/cluster -администрирование/регистрация/   -  person OneCricketeer    schedule 18.07.2019
comment
Да, но это не мой случай.   -  person nassi.harel    schedule 18.07.2019
comment
Я не совсем понимаю вопрос. Если ваш сторонний контейнер регистрируется в stdout/stderr, как и любой другой контейнер, то почему вы не можете получить его журналы с помощью любого драйвера ведения журнала, который работает с этими другими контейнерами?   -  person OneCricketeer    schedule 18.07.2019

Ответы (3)


arrow_upward
0
arrow_downward

Поскольку контейнеры внутри модуля используют один и тот же уровень сохраняемости, вы можете подключить #creating-a-pod-that-runs-two-containers" rel="nofollow noreferrer">Общий том, чтобы сделать эти данные доступными для обоих.

Для вашей конкретной цели вам потребуется зарегистрировать оба потока (stderr и stdout) в файлах тома. Затем вам нужно экспортировать их из основного контейнера в любой драйвер ведения журнала, который вы используете в своем кластере.

Однако в спецификациях нет конкретной инструкции для записи этих выходных данных в файл.

person yyyyahir    schedule 17.07.2019
comment
Сторонний контейнер — это не мой образ, я не могу контролировать расположение файлов stdout и stderr. - person nassi.harel; 17.07.2019
comment
Вероятно, вы можете использовать fluentd, как указано в моем ответе. - person Malathi; 18.07.2019
comment
Я не хочу полагаться на fluentd, мне нужно, чтобы мой процесс обращался к журналам другого контейнера. - person nassi.harel; 18.07.2019
comment
Определите, ожидаете ли вы файлы журнала или stdout, stderr. Во-первых, вам нужно знать расположение файлов журнала и директиву mountPath в обоих контейнерах для общего тома. Во втором случае оба потока захватываются через драйвер ведения журнала, доступ к которому можно получить через kubectl logs или через файлы ротации журналов внутри узла. - person yyyyahir; 18.07.2019
comment
Я ожидаю stdout/stderr, я думаю, что буду использовать подход совместного использования пространства имен процессов между контейнерами в поде. Использование хвоста в /proc/PID/fd1в стороннем контейнере. kubernetes.io/docs/tasks/configure-pod-container / - person nassi.harel; 18.07.2019

arrow_upward
0
arrow_downward

На основе драйвера ведения журналов, указанного для Docker, Docker отслеживает логи контейнеров. Драйвер ведения журнала по умолчанию для докера — json-file, который перенаправляет журналы контейнера stdout и stderr в папку /var/log/containers на хост-компьютере, на котором работает докер.

В случае kubernetes журналы будут доступны в папке рабочих узлов /var/log/containers.

Вероятно, вы ищете fluentd daemonset, который создает набор демонов, который запускается на каждом рабочем узле, а затем поможет вам перенести журналы в s3, cloudwatch или Elastic search. Есть много раковин, оснащенных fluentd. Вы можете использовать тот, который соответствует вашим потребностям. Надеюсь, это то, что вы хотите сделать со своим my-container.

person Malathi    schedule 18.07.2019
comment
Спасибо, нет, это не так, я уже использую fluentd для сбора всех логов со всех контейнеров. В my-контейнере мне нужен доступ к логам, написанным в сторонних - person nassi.harel; 18.07.2019
comment
Стороннее приложение не работает как контейнер в вашем кластере kubernetes? - person Malathi; 18.07.2019
comment
Вы имели в виду наш * ? - person Malathi; 18.07.2019
comment
Да, он работает как контейнер в нашем кластере kubernetes. - person nassi.harel; 18.07.2019
comment
Тогда почему не проводила? Вы упомянули, что программа пишет в stdout/stderr. Это файл, а не stdout/stderr? - person Malathi; 18.07.2019
comment
Внутри my-container я хочу собрать все stdout и stderr из стороннего контейнера, добавить метаданные и записать их своим логгером. - person nassi.harel; 18.07.2019
comment
Я не хочу полагаться на fluentd, мне нужно, чтобы мой процесс обращался к журналам другого контейнера. - person nassi.harel; 18.07.2019
comment
В этом случае вы можете использовать volumeMount для my-container со значением hostPath как /var/log/containers. Затем отслеживайте файл для стороннего контейнера в папке из моего контейнера и выполняйте обработку, а затем отправляйте журналы туда, куда хотите. - person Malathi; 18.07.2019
comment
Для этого мне нужно быть в привилегированном положении: true, чего я не могу сделать (например, openshift). Он также не защищен. - person nassi.harel; 18.07.2019

arrow_upward
0
arrow_downward

Кажется, я понял ваше требование. Я наткнулся на Logspout: https://github.com/gliderlabs/logspout

Do

$ docker pull gliderlabs/logspout:latest

а затем запустите контейнер, например,

$ docker run \
--volume=/var/run/docker.sock:/var/run/docker.sock \
gliderlabs/logspout \
raw://192.168.10.10:5000

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

Проверьте ссылку выше для деталей.

person rAhulD    schedule 06.02.2020