/ cc @vishh @rjnagal @vmarmol

Сейчас мы можем установить разумное значение по умолчанию. Хотим ли мы, чтобы это было выставлено как ручка?
в спецификации, или мы предпочитаем переключатель «низкий / высокий»? Единственное преимущество
переключение заключается в том, что мы можем избежать слишком большого количества рабочих мест с высокой стоимостью посадки
на той же машине.

Пт, 23 января 2015 г., в 00:19, Брайан Грант [email protected]
написал:

/ cc @vishh https://github.com/vishh @rjnagal
https://github.com/rjnagal @vmarmol https://github.com/vmarmol

-
Ответьте на это письмо напрямую или просмотрите его на GitHub
https://github.com/GoogleCloudPlatform/kubernetes/issues/3595#issuecomment -71160651
.

Есть ли в наши дни недостатки установки высоких лимитов по умолчанию? я
не могу точно сказать, какие ошибки мы исправили внутри, которые могли не иметь
были приняты вверх по течению, особенно в отношении таких вещей, как учет memcg
структур ядра.

Пт, 23 января 2015 г., в 00:29, Rohit Jnagal [email protected]
написал:

Сейчас мы можем установить разумное значение по умолчанию. Хотим ли мы, чтобы это было выставлено как ручка?
в спецификации, или мы предпочитаем переключатель «низкий / высокий»? Единственное преимущество
переключение заключается в том, что мы можем избежать слишком большого количества рабочих мест с высокой стоимостью посадки
на той же машине.

Пт, 23 января 2015 г., в 00:19, Брайан Грант [email protected]
написал:

/ cc @vishh https://github.com/vishh @rjnagal
https://github.com/rjnagal @vmarmol https://github.com/vmarmol

Ответьте на это письмо напрямую или просмотрите его на GitHub
<
https://github.com/GoogleCloudPlatform/kubernetes/issues/3595#issuecomment-71160651>

.

Ответьте на это письмо напрямую или просмотрите его на GitHub
https://github.com/GoogleCloudPlatform/kubernetes/issues/3595#issuecomment -71161877
.

+1 к переключению, помещая это в спецификацию, IMO перебор.

Если есть переключатель «несколько» против «многих», каждый выберет «много». Мы
нужно понять и задокументировать, почему "несколько" - лучший выбор для большинства
time, и подумайте, как ограничить тех, кто использует "many".

Пт, 23 января 2015 г., в 9:39, Виктор Мармол [email protected]
написал:

+1 к переключению, помещая это в спецификацию, IMO перебор.

Ответьте на это письмо напрямую или просмотрите его на GitHub
https://github.com/GoogleCloudPlatform/kubernetes/issues/3595#issuecomment -71231707
.

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

Пт, 23 января 2015 г., в 9:56, Тим Хокин [email protected]
написал:

Если есть переключатель «несколько» против «многих», каждый выберет «много». Мы
нужно понять и задокументировать, почему "несколько" - лучший выбор для большинства
time, и подумайте, как ограничить тех, кто использует "many".

Пт, 23 января 2015 г., в 9:39, Виктор Мармол [email protected]
написал:

+1 к переключению, помещая это в спецификацию, IMO перебор.

Ответьте на это письмо напрямую или просмотрите его на GitHub
<
https://github.com/GoogleCloudPlatform/kubernetes/issues/3595#issuecomment -71231707

.

-
Ответьте на это письмо напрямую или просмотрите его на GitHub
https://github.com/GoogleCloudPlatform/kubernetes/issues/3595#issuecomment -71234393
.

Один из способов ограничить "многие" - это принять во внимание глобальную машину
ограничения и используйте его при планировании.
Я не думаю, что у нас есть или планируется добавлять возможности для пользователей.

Пт, 23 января 2015 г., 10:25, Виш Каннан [email protected]
написал:

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

Пт, 23 января 2015 г., в 9:56, Тим Хокин [email protected]
написал:

Если есть переключатель «несколько» против «многих», каждый выберет «много». Мы
нужно понять и задокументировать, почему "несколько" - лучший выбор для большинства
в
time, и подумайте, как ограничить тех, кто использует "many".

Пт, 23 января 2015 г., в 9:39, Виктор Мармол [email protected]

написал:

+1 к переключению, помещая это в спецификацию, IMO перебор.

Ответьте на это письмо напрямую или просмотрите его на GitHub
<

https://github.com/GoogleCloudPlatform/kubernetes/issues/3595#issuecomment -71231707

.

-
Ответьте на это письмо напрямую или просмотрите его на GitHub
<
https://github.com/GoogleCloudPlatform/kubernetes/issues/3595#issuecomment-71234393>

.

-
Ответьте на это письмо напрямую или просмотрите его на GitHub
https://github.com/GoogleCloudPlatform/kubernetes/issues/3595#issuecomment -71239201
.

Для нашего проекта мы будем использовать как «несколько», так и «много». Нижний предел будет для наших рабочих контейнеров (без подключения к сети), а верхний предел будет для наших контейнеров хранения (с отслеживанием состояния).

+1 для переключения, но что именно означает несколько и много?
Также каковы последствия для планирования?

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

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

Для больших и малых значений мы можем начать с типичного linux max для ресурса такого же большого размера и типичного значения по умолчанию, равного немногим.

@ bgrant0607 какую модель вы

Я не знаю, нужно ли нам отслеживать эти значения в планировщике. Они больше для предотвращения DoS-атак, чем для выделения ограниченного ресурса.

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

В чем обратная сторона простого отображения числовых параметров?

Я согласен, что мы должны выбирать разумные, скромные значения по умолчанию.

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

Пт, 6 марта 2015 г., 21:13, Брайан Грант [email protected]
написал:

Я не знаю, нужно ли нам отслеживать эти значения в планировщике. Они есть
больше для предотвращения DoS-атак, чем для выделения ограниченного ресурса.

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

В чем обратная сторона простого отображения числовых параметров?

Я согласен, что мы должны выбирать разумные, скромные значения по умолчанию.

-
Ответьте на это письмо напрямую или просмотрите его на GitHub
https://github.com/GoogleCloudPlatform/kubernetes/issues/3595#issuecomment -77674200
.

Re. Политики, определяемые администратором, см. https://github.com/docker/docker/issues/11187

@ bgrant0607 : Это то, что мы можем рассмотреть для версии 1.1?

Мы можем, но у меня, вероятно, будет 0 пропускной способности, чтобы подумать об этом в следующем месяце.

cc @erictune

Функция Docker rlimit основана на процессах, а не на cgroup (конечно, в восходящем ядре еще нет cgroup rlimit). Это означает

• Ограничение применяется к корневому процессу контейнера, и все дочерние процессы наследуют его.
• Нет контроля над тем, сколько дочерних процессов
• Процессы для docker exec не наследуют тот же предел

Исходя из вышеизложенного, я не думаю, что есть очень полезная функция или, по крайней мере, нелегкая в использовании функция для определения и управления.

Где это стоит? это доступно через какой-нибудь конфиг?

@ shaylevi2 : Посмотрите предыдущий комментарий. Текущая реализация Docker - не то, что нам нужно.

Мне постоянно задают вопросы в этой области, так что, возможно, было бы полезно указать где-нибудь в документации, объясняющую, почему она еще не поддерживается. Печатая это, я признаю, что странно писать что-то о том, почему мы чего-то не делаем, но предыдущий комментарий @ dchen1107 полезен.

@thockin @ bgrant0607 похоже, что это не будет решаться? Это определенно проблема как для elasticsearch, так и для cassandra, работающих на K8s. Что рекомендуется делать, чтобы получить удовольствие от RLIMIT_MEMLOCK?

cc @ kubernetes / сиг-узел-функции-запросы

Эти приложения также требуют огромных страниц?

В пятницу, 10 июня 2016 г., Брайан Грант [email protected] написал:

cc @ kubernetes / сиг-узел
https://github.com/orgs/kubernetes/teams/sig-node

-
Вы получили это, потому что прокомментировали.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/kubernetes/kubernetes/issues/3595#issuecomment -225110348,
или отключить поток
https://github.com/notifications/unsubscribe/AF8dbBznwyW6cJLD6lE_BJ-g02POtQ06ks5qKQ9CgaJpZM4DT0Ae
.

Ага Кассандра и Эластик - jemalloc для Кассандры

Redis также использует jemalloc

Так что справедливо будет сказать, что вам нужны обе функции, поддерживаемые на узле?

В субботу, 11 июня 2016 г., Крис Лав [email protected] написал:

Redis также использует jemalloc

-
Вы получили это, потому что прокомментировали.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/kubernetes/kubernetes/issues/3595#issuecomment -225398637,
или отключить поток
https://github.com/notifications/unsubscribe/AF8dbD-544FTawGiqk5W_oa2rEbXMAxIks5qKzqwgaJpZM4DT0Ae
.

:) Большое хочу :)

Jvm огромные страницы с jemalloc и redis находятся на C с jemalloc

Неужели для этого нужен привилегированный режим? Я думаю, что мы на самом деле на уровне ядра / докера, а не k8s

Разрешите это .. Github разрешил мне редактировать на мобильном устройстве ...

@rjnagal Есть ли более свежие RFC для контрольной группы ограничения ядра?

http://thread.gmane.org/gmane.linux.kernel.cgroups/12687

каков статус этого?
Чтобы запустить сайт nginx с высокой посещаемостью, мне нужно увеличить количество открытых файлов.
По умолчанию значение равно

ulimit -n
4096

Конфигурация nginx для увеличения количества открытых файлов:

worker_rlimit_nofile 10240;

Однако при запуске я вижу это в error.log

[alert] 78#78: setrlimit(RLIMIT_NOFILE, 10240) failed (1: Operation not permitted)

При запуске докера я бы установил ulimit для решения этой проблемы, например

--ulimit nofile=262144:262144 

Как это сделать в кубернетах?

@mingfang вы пробовали привилегированный режим?

@chrislovecnm hugepages design doc, над которым работает @sjenning, возможно, вы сможете подробнее рассказать о сценариях использования ES и Cassandra ... они также очень актуальны для RH, поскольку мы используем их в продуктах.

Вчера мы с ним обсуждали ulimits для memlock, а также нам может понадобиться пространство имен vm.hugetlb_shm_group в ядре. Очень похожие варианты использования. Имеет смысл объединить все эти цели в одну проектную документацию, и мы соответствующим образом поэтапно реализуем реализацию.

Мне сложно понять, почему комментарий

@tmandry какие функции вам нужны?

@tmandry - проблема в том, что ограничения на процесс не очень полезны для
изоляционные цели. Я признаю, что есть несколько применений, но все аспекты API
требует затрат на разработку, тестирование, поддержку, документирование и понимание, поэтому
нам нужно уравновесить это. Какие пределы вас интересуют?

Во вторник, 29 ноября 2016 г., в 1:44, Виш Каннан [email protected]
написал:

@tmandry https://github.com/tmandry какие функции вам нужны?

-
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/kubernetes/kubernetes/issues/3595#issuecomment-263523310 ,
или отключить поток
https://github.com/notifications/unsubscribe-auth/AFVgVGU4TPedAysc0zbdccNHzBWeb9Cpks5rC_P6gaJpZM4DT0Ae
.

На мой взгляд, независимо от того, полезно ли устанавливать ограничение для каждого процесса, есть факт: многим людям необходимо увеличить дескрипторы файлов или другие ограничения, чтобы их процессы работали в некоторых сценариях. Примерами могут быть серверы или прокси с множеством одновременных подключений (это ситуация для меня и других людей, которые уже комментировали здесь).

Я за то, чтобы пользователь мог выбирать собственные значения. Я согласен с комментарием @ bgrant0607 о том, что предопределенный набор уровней не переносится, и я также думаю, что нет ничего против того, чтобы позволить пользователю настраивать числовые значения (если пользователь хочет увеличить предел дескриптора файла, он хочет этого, потому что он знает, что это средства). Я также считаю, что это проще реализовать в Kubernetes, чем думать о том, как мы можем определить эти уровни, настроить их и так далее.

Более того, с моей точки зрения, пользователь, скорее всего, ожидает, что сможет настроить ограничения своего процесса в контейнере, как он это делает в виртуальной машине. Это степень контроля, достигаемая с помощью пользовательских значений.

Еще одна вещь, которую может быть интересно рассмотреть: я думаю, имеет смысл иметь возможность ограничивать ограничения, которые пользователь может устанавливать с помощью политик безопасности Pod.

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

Мне нужна эта функция, чтобы решить проблему
https://gitlab.com/gitlab-org/omnibus-gitlab/issues/1350

в docker run есть --ulimit
Могу ли я сделать это в кубернетах сейчас?

Согласован с ограничением fd, с этим я сталкивался несколько раз. В моем случае также важна возможность закрепления ядер путем повышения rtprio ulimit.

Справедливо. Повышение лимита отличается от изоляции ресурса.
rlimit больше подходит для одного, чем для другого.

22 декабря 2016 г., в 17:24, Тайлер Мандри [email protected]
написал:

Согласован с ограничением fd, с этим я сталкивался несколько раз. В моем
В этом случае возможность закрепления сердечников повышением rtprio ulimit также
важный.

-
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/kubernetes/kubernetes/issues/3595#issuecomment-268925649 ,
или отключить поток
https://github.com/notifications/unsubscribe-auth/AFVgVLJp09kWIdwGjVAnBbgeJAYfH-4pks5rKyLQgaJpZM4DT0Ae
.

Эта проблема в настоящее время делает невозможным запуск Elasticsearch в Kubernetes без снижения

[WARN ][bootstrap] Unable to lock JVM Memory: error=12,reason=Out of memory
[WARN ][bootstrap] This can result in part of the JVM being swapped out.
[WARN ][bootstrap] Increase RLIMIT_MEMLOCK, soft limit: 65536, hard limit: 65536

Мы вроде как обошли это, отредактировав сценарий ENTRYPOINT, доступный в официальном образе Docker Elasticsearch.

Установка вверху ...

#!/bin/bash

set -e

echo '1: Before ulimit'
ulimit -l
ulimit -l unlimited
ulimit -l
echo '2. After ulimit'

... дает нам ...

2017-01-13T09:00:36.117522472Z 1: Before ulimit
2017-01-13T09:00:36.117551488Z 64
2017-01-13T09:00:36.117569173Z unlimited
2017-01-13T09:00:36.117574588Z 2. After ulimit

Ох, чувак, я не понимал, что это все еще открыто.

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

/ cc @jbeda @luxas @vishh @philips

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

Ну, мы немного поработали и просто переопределили конфигурацию докеров: - /
Итак ... есть аварийный люк.

@timothysc, что именно мне нужно переопределить?

@itskingori в официальном образе Docker

@ hiscal2015 Предоставляя контейнеру дополнительные возможности ... вот так ... 👇

---
apiVersion: apps/v1beta1
kind: StatefulSet
spec:
  template:
    spec:
        - name: elasticsearch
          securityContext:
            capabilities:
              add:
                - IPC_LOCK
                - SYS_RESOURCE

@itskingori По-прежнему не повезло, вот мой Dockerfile:

FROM docker.elastic.co/elasticsearch/elasticsearch:5.2.0
ADD elasticsearch.yml /usr/share/elasticsearch/config/
USER root
RUN chown elasticsearch:elasticsearch config/elasticsearch.yml
RUN sed -i '2i\set -e\' /usr/share/elasticsearch/bin/es-docker
RUN sed -i '3i\ulimit -l unlimited\' /usr/share/elasticsearch/bin/es-docker
USER elasticsearch

А вот и мой ямл:

    spec:
      containers:
      - name: es-master
        securityContext:
          privileged: true
          capabilities:
            add:
              - IPC_LOCK
              - SYS_RESOURCE

И вот сообщение об ошибке:

3/20/2017 7:44:14 PMbin/es-docker: line 3: ulimit: max locked memory: cannot modify limit: Operation not permitted

Я что-то упускаю?

@ hiscal2015 Не могли бы вы отредактировать свой комментарий с помощью "тройной галочки", чтобы отформатировать вставленные файлы? Нравится:

dockerfile
[dockerfile идет сюда]
`` ''

ямл
[ямл идет сюда]
`` ''

Это поможет всем. Спасибо!

@ hiscal2015 Я не уверен, что вы пытаетесь сделать в своем Dockerfile ... кажется, что вы пытаетесь что-то делать на этапе сборки. Не могу следовать вашей идее и найти подход, который может сработать.

Я просто поделюсь тем, что мы сделали ... мы заменили изображение ENTRYPOINT (которое было docker-entrypoint.sh ), чтобы сначала выполнить то, что мы хотим. Нравится ...

FROM elasticsearch:2.4.3-alpine

COPY configs/elasticsearch.yml /usr/share/elasticsearch/config/elasticsearch.yml
COPY custom-entrypoint.sh /custom-entrypoint.sh

VOLUME /usr/share/elasticsearch/data

ENTRYPOINT ["/custom-entrypoint.sh"]
CMD ["elasticsearch"]

Где custom-entrypoint.sh - это ...

#!/bin/bash

set -e

ulimit -l unlimited

exec /docker-entrypoint.sh "$@"

Идея состоит в том, что custom-entrypoint.sh будет запускаться при запуске контейнера, а означает, что ulimit -l unlimited будет запускаться перед командой для запуска Elasticsearch (что мы и хотим).

Когда мы начали пытаться запустить ES 5.0, мы тоже столкнулись с этой проблемой. Были
запуск init-контейнера для подготовки узла. Я не смог получить ulimit
внутри работающего контейнера для выполнения работы, поэтому я написал этого парня:
https://github.com/samsung-cnct/set_max_map_count он требует, чтобы / proc был
монтируется только в контейнер инициализации, что вызывает у меня беспокойство, но это
работает.

Пример использования этого здесь:
https://github.com/samsung-cnct/elasticsearch-kubernetes/blob/master/es.yaml

примечание: это было для того, чтобы во всем разобраться. мы работали на k8s v1.4. В
диаграмма, основанная на том, что работает для 1.5+ и находится здесь:
https://github.com/samsung-cnct/k2-charts/tree/master/elasticsearch

В среду, 22 марта 2017 г., в 9:12, itskingori [email protected]
написал:

@ hiscal2015 https://github.com/hiscal2015 Я не уверен, что вы
пытаетесь сделать в своем Dockerfile ... кажется, вы пытаетесь что-то сделать
на этапе сборки. Не могу следовать вашей идее и найти подход, который
Работа.

Я просто поделюсь тем, что мы сделали ... мы заменили изображение ENTRYPOINT
(это был docker-entrypoint.sh), чтобы сначала запустить то, что мы хотим. Нравится ...

ИЗ elas ticsearch: 2.4.3-альпийский
Копировать конфигурации / elasticsearch.yml /usr/share/elasticsearch/config/elasticsearch.ymlCOPY custom-entrypoint.sh /custom-entrypoint.sh
ТОМ / usr / share / elasticsearch / data
ENTRYPOINT ["/custom-entrypoint.sh" ]CMD [" elasticsearch "]

Где custom-entrypoint.sh ...

! / bin / bash

set -e
ulimit -l без ограничений
exec /docker-entrypoint.sh "$ @"

Идея в том, что custom-entrypoint.sh будет запускаться при запуске контейнера.
while означает, что ulimit -l unlimited будет запускаться перед командой для запуска
Elasticsearch (это то, что мы хотим).

-
Вы получаете это, потому что подписаны на эту ветку.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/kubernetes/kubernetes/issues/3595#issuecomment-288451522 ,
или отключить поток
https://github.com/notifications/unsubscribe-auth/AApXmgWmIp6DCoyU4UQ6mJxBP9qhHrK5ks5roUiIgaJpZM4DT0Ae
.

pid cgroup https://www.kernel.org/doc/Documentation/cgroup-v1/pids.txt позволяет ограничить количество процессов в cgroup, что очень важно, чтобы избежать "бомб" вилки. docker, похоже, добавил поддержку с версии 1.11: https://github.com/docker/docker/pull/18697
Можем ли мы выставить pids-limit в спецификации контейнера pod k8s.

Вместо того, чтобы у каждого были свои собственные хаки и пользовательские точки входа, просто чтобы установить rlimit, мне также нравится +1, мы позволяем пользователям устанавливать его через API k8s. Над этим вообще работают?

Над этим вообще работают?

Нет, но я думаю, что хотел бы поставить это в очередь для @ kubernetes / sig-cluster-lifecycle-feature-requests b / c, это напрямую повлияет на них.

cc @ kow3ns @jagosan

@itskingori - Я потратил немало времени, пытаясь заставить мемлок работать с elasticsearch в кубернетах. Благодаря вам я смог все сдвинуть с мертвой точки .

Я бы действительно предпочел, чтобы кубернеты изначально поддерживали ulimits.

Если вас интересует настройка кластера elasticsearch на k8s, который запрашивает ulimit -l unlimited я делюсь им со всеми вами.

https://github.com/cesargomezvela/elasticsearch

Загляните внутрь файла docker/run.sh .

# allow for memlock if enabled
if [ "$MEMORY_LOCK" == "true" ]; then
    ulimit -l unlimited
fi

Вас также могут заинтересовать следующие строки, которые находятся внутри файла kubernetes/elasticsearch-master.yaml

spec:
  replicas: 3
  template:
    metadata:
      annotations:
        pod.alpha.kubernetes.io/init-containers: '[
          {
            "name":"init-sysctl",
            "image":"busybox:1.27.2",
            "imagePullPolicy":"IfNotPresent",
            "command":[
              "sysctl",
              "-w",
              "vm.max_map_count=262144"
            ],
            "securityContext":{
                "privileged":true
            }
          }
        ]'
...
        securityContext:
          privileged: true

@timothysc @tnachen @ bgrant0607 @cesargomezvela @gdmello Значит, с securityContext/privileged/true и / или capabilities/add/SYS_RESOURCE запущенным в контейнере, теперь можно запустить ulimit, верно? Остался ли еще элемент TODO в этом выпуске?

например, хотим ли мы разрешить авторам модулей явно указывать ограничения? (например, запросы / ограничения процессора / памяти?) без необходимости увеличивать их возможности / привилегии?

Примечания:

• https://github.com/containerd/containerd/blob/master/oci/spec_unix.go#L89
• https://github.com/18F/kubernetes-broker/commit/9669df29c0b16b13e922c5723f174d7e44533874
• https://github.com/moby/moby/search?utf8=%E2%9C%93&q=POSIXRlimit&type=
• https://github.com/opencontainers/runtime-spec/search?utf8=%E2%9C%93&q=rlimit&type=

Лично я считаю хорошей идеей разрешить авторам модулей устанавливать явные ограничения без ограничения возможностей или привилегий по следующим причинам:

• Возможность SYS_RESOURCE может позволить приложениям выполнять операции, которые вы, возможно, не хотите разрешать. Это еще более верно для привилегированных контейнеров.
• Хотя некоторые приложения действительно требуют установки ограничений самостоятельно (поскольку они или их сценарии запуска предназначены для этого), в других случаях вы можете захотеть настроить их во время создания модуля и не позволять приложению изменять их во время выполнения (для из соображений безопасности, из соображений контроля ресурсов в общественных средах ...).

Другая проблема с ulimit в точке входа заключается в том, что вы не можете изменить жесткий лимит как некорневой, и вы также не можете сделать это через sudo . Обычно в Linux вы делаете это через /etc/security/limits.conf но докер игнорирует это, поэтому вам придется использовать root как пользователя по умолчанию.

Если вы ищете изображение elasticsearch с ulimit в точке входа и elasticsearch, запущенный от пользователя elasticsearch стесняйтесь использовать / fork https://github.com/wodby/elasticsearch

@ kubernetes / sig-node-feature-requests Так можно ли нам сделать что-нибудь только для докеров? Я не могу сказать, могут ли другие реализации CRI легко поддерживать эту функцию. (cc @timothysc @tnachen @ bgrant0607)

Есть еще много аргументов, почему это необходимо, на https://github.com/moby/moby/issues/4717 и объединено в https://github.com/moby/moby/pull/9437; Все, что должен сделать K8s, - это разрешить передавать эти аргументы контейнеру, который он запускает. Почему здесь даже обсуждается поддержка cgroups? Это было решено на уровне контейнера. Все, что вам нужно сделать, это позволить передать дополнительный аргумент и позволить всем людям, которые создают уродливый сценарий-оболочку + привилегированные обходные пути, наконец, сделать правильную вещь и просто передать аргумент, как они хотели сделать, и был доступен для них. последние 3 года!

@kesor абсолютно честный. Я копаю старые проблемы, подобные этой, и пытаюсь понять, что мы можем сделать. да, точно передать аргументы докеру легко, но нужно выяснить, можно ли что-то сделать для других реализаций CRI.

@kesor @csandanov @palonsoro @cesargomezvela @gdmello - У вас есть время, чтобы надрать шину # 58904 и высказать свое мнение?

Максимальные ограничения файлов сложны, и IMO (теоретически) ограничения устанавливаются на нескольких уровнях (контейнер, демон докеров на узле, сам узел и весь путь до уровня хранения / файловой системы).

@dims Следует ли дополнительно проводить проверку на уровне PV? Пример. Что делать, если на уровне контейнера мы устанавливаем лимит в 1M, а пользователь решает использовать EFS в качестве PV, где ограничения на максимальное количество файлов не могут быть настроены, а лимит низкий?

@dims после того, как я увидел вашу разницу, какое время прибытия для этого docker run --ulimit в кубернетах? Есть ли это в дорожной карте Kubernetes?

Проблемы устаревают после 90 дней бездействия.
Отметьте проблему как новую с помощью /remove-lifecycle stale .
Устаревшие выпуски гниют после дополнительных 30 дней бездействия и в конечном итоге закрываются.

Если сейчас можно безопасно закрыть эту проблему, сделайте это с помощью /close .

Отправьте отзыв в sig-testing, kubernetes / test-infra и / или fejta .
/ жизненный цикл устаревший

/ remove-жизненный цикл устаревший

Есть ли какие-нибудь планы по этому поводу?
Мы запускаем образ докера
Я пытался добавить

args:
    - "--ulimit memlock=10000000:10000000"

с участием

 securityContext:
     privileged: true
     capabilities:
         add:
             - IPC_LOCK
             - SYS_RESOURCE

в соответствии со спецификацией набора состояний, но это не сработало.

@arturalbov мы делаем что-то подобное с elasticsearch / cassandra, просто создаем собственное изображение с альтернативным сценарием точки входа, например:

#!/bin/bash

# Set memlock limit to unlimited
ulimit -l unlimited

# Call original entrypoint script
exec /usr/local/bin/docker-entrypoint.sh "${@}"

затем предоставьте те же возможности, которые вы упомянули ( privileged не требуется):

 securityContext:
     capabilities:
         add:
             - IPC_LOCK
             - SYS_RESOURCE

@eyalzek Спасибо! Оно работает

@arturalbov мы делаем что-то подобное с elasticsearch / cassandra, просто создаем собственное изображение с альтернативным сценарием точки входа, например:

#!/bin/bash

# Set memlock limit to unlimited
ulimit -l unlimited

# Call original entrypoint script
exec /usr/local/bin/docker-entrypoint.sh "${@}"

затем предоставьте те же возможности, которые вы упомянули ( privileged не требуется):

 securityContext:
     capabilities:
         add:
             - IPC_LOCK
             - SYS_RESOURCE

Не могли бы вы помочь мне понять, как заставить это работать с k8s?

@rewt Привет конечно
Я создал файл custom-entrypoint.sh (он должен вызывать исходный сценарий точки входа, вы можете узнать, как его вызвать в исходном Dockerfile необходимого образа). Для меня (и в основном) это выглядит так:

#!/bin/bash

# Set memlock limit
ulimit -l 33554432

# Call original entrypoint script
exec /docker-entrypoint.sh "${@}"

Затем я создал Dockerfile для создания собственного образа elassandra. Это выглядит так:

FROM strapdata/elassandra:5.5.0.20

COPY custom-entrypoint.sh /custom-entrypoint.sh

ENTRYPOINT ["/custom-entrypoint.sh"]
CMD ["bin/cassandra"]

Поместите эти файлы в ту же папку и просто создайте собственный образ с помощью команды docker build . Затем вы можете развернуть его в своем личном репозитории Docker Hub, чтобы использовать его в k8s в облаке. Итак, после того, как у вас есть собственное изображение, вы можете использовать его в определении спецификации модуля с добавлением возможностей контекста безопасности, как указано в вашей цитате.

Вот пример StatefulSet, который я использовал.
А вот и пример построения кастомного изображения .

Это тоже требуется?

securityContext:
возможности:
Добавить:
- IPC_LOCK
- SYS_RESOURCE

20 сентября 2018 г. в 13:20 Артур Альбов [email protected]
написал:

@rewt https://github.com/rewt Привет, конечно
Я создал файл custom-entrypoint.sh (он должен вызывать исходную точку входа
скрипт, вы можете узнать, как его вызвать в исходном Dockerfile
необходимое изображение). Для меня (и в основном) это выглядит так:

! / bin / bash

Установить предел блокировки

ulimit -l 33554432

Вызов оригинального скрипта точки входа

exec /docker-entrypoint.sh "$ {@}"

Затем я создал Dockerfile для создания собственного образа elassandra. Это выглядит как
что:

ОТ strapdata / e lassandra: 5.5.0.20

КОПИРОВАТЬ custom-entrypoint.sh /custom-entrypoint.sh

ENTRYPOINT ["/custom-entrypoint.sh"]
CMD ["bin / cassandra"]

Поместите эти файлы в ту же папку и просто создайте собственный образ с помощью докера.
команда сборки. Затем вы можете развернуть его в своем личном репозитории Docker Hub.
чтобы использовать его в k8s в облаке. Итак, после того, как у вас есть собственное изображение
вы можете использовать его в определении спецификации модуля с добавлением контекста безопасности
возможности, как указано в вашей цитате.

Вот пример
https://github.com/cybercongress/cybernode/blob/master/kubernetes-definitions/search/elassandra.yaml
StatefulSet, который я использовал.
А вот пример построения кастомного изображения
https://github.com/cybercongress/cybernode/tree/master/docker/elassandra
.

-
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/kubernetes/kubernetes/issues/3595#issuecomment-423263977 ,
или отключить поток
https://github.com/notifications/unsubscribe-auth/ACWZzrZTKmWf08qUMB3HlFF5zFJ_WG5Oks5uc85qgaJpZM4DT0Ae
.

@rewt да, просто посмотрите на пример StatefulSet

@rewt да, просто посмотрите на пример StatefulSet

что содержит "/docker-entrypoint.sh"? Я разместил команду оболочки, но ulimit -l не изменился.

@rewt да, просто посмотрите на пример StatefulSet

что содержит "/docker-entrypoint.sh"? Я разместил команду оболочки, но ulimit -l не изменился.

Это просто оригинальный сценарий точки входа для изображения elassandra

@rewt да, просто посмотрите на пример StatefulSet

что содержит "/docker-entrypoint.sh"? Я разместил команду оболочки, но ulimit -l не изменился.

Это просто оригинальный сценарий точки входа для изображения elassandra

Можете ли вы сказать мне, изменилось ли ваше значение для ulimit -l?

@arturalbov мы делаем что-то подобное с elasticsearch / cassandra, просто создаем собственное изображение с альтернативным сценарием точки входа, например:

#!/bin/bash

# Set memlock limit to unlimited
ulimit -l unlimited

# Call original entrypoint script
exec /usr/local/bin/docker-entrypoint.sh "${@}"

... извините за тупость, но может кто-нибудь объяснить, почему популярные изображения, такие как casandra / elasticsearch, не делают это уже как часть своего сценария точки входа?

Кроме того, по какой причине это нельзя было просто запустить как часть Dockerfile, как здесь? https://github.com/imyoungyang/docker-swarm-elasticsearch/blob/master/Dockerfile#L12

@jamesdh, потому что эта строка в Dockerfile не влияет на контейнер, работающий на основе этого образа. ulimit - это свойство запущенного процесса, вы не можете установить его до того, как процесс действительно будет запущен, и его эффект будет применяться только к этому процессу и его дочерним элементам. В случае вашего примера в Dockerfile - команда будет применяться только к этой единственной строке №12 и не будет иметь никакого эффекта на любую другую строку, которая появится позже в этом файле, или на возможный контейнер, созданный из образа, основанного на этот Dockerfile.

@jamesdh также, Docker, как родительский процесс - может изменять пределы своих дочерних процессов (запущенных контейнеров), и во многих случаях, когда дочернему элементу необходимо изменить свои ограничения, для этого нет достаточных разрешений. Вот почему для K8s важно разрешить администраторам передавать эти параметры команде docker run . Просто потому, что в большинстве случаев это невозможно сделать из работающего контейнера.

Для меня критически важно установить ulimit -n для всех контейнеров на определенных узлах в моем кластере. Есть ли документация, как это сделать?

долгосрочная проблема (примечание для себя)

Я задокументировал свой опыт здесь -
https://github.com/helm/charts/issues/8348 и с тех пор переехали из Пирес
в диаграмму Helm, так как были некоторые проблемы с установкой плагинов на мастер
узлы.

Чт, 25 октября 2018 г., 8:58 Джошуа Остер-Моррис <
[email protected]> написал:

Для меня критически важно установить ulimit -n для всех
контейнеры на определенных узлах в моем кластере. Есть ли документация по
как это сделать?

-
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/kubernetes/kubernetes/issues/3595#issuecomment-433039816 ,
или отключить поток
https://github.com/notifications/unsubscribe-auth/ACWZzo7_NsnhDwVRPnofQI7SHjPrgwAVks5uobV6gaJpZM4DT0Ae
.

@rewt Я не могу заставить ваше решение (https://github.com/rewt/elasticsearch-mlock) работать, потому что ulimit не может сделать это как пользователь без полномочий root, а elastic не будет работать как root. K8s, похоже, не уважает файл /etc/security/limits.conf хоста (или изображение - что имеет смысл), поэтому я не могу найти способ сделать это правильно для эластичного. У нас есть своп, поэтому это вообще проблема.

Тебе следует:

1. Создать новый файл докеров
2. Добавьте код в определение контейнера, чтобы разрешить выполнение ulimit

https://github.com/rewt/elasticsearch-mlock

Вт, 25 октября 2018 г., в 12:16 tobymiller1 [email protected]
написал:

@rewt https://github.com/rewt Я не могу заставить ваше решение работать,
потому что ulimit не может сделать это как пользователь без полномочий root, а elastic не будет работать как
корень. K8s, похоже, не уважает файл /etc/security/limits.conf
хост (или изображение - что имеет смысл), поэтому я не могу найти способ получить это
право на резинку. У нас есть своп, поэтому это вообще проблема.

-
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/kubernetes/kubernetes/issues/3595#issuecomment-433113534 ,
или отключить поток
https://github.com/notifications/unsubscribe-auth/ACWZzj1f_fv4HQ7Ov3jJC5ibE1RAxs0gks5uoePOgaJpZM4DT0Ae
.

@rewt Это ваша точка 2, с которой я

securityContext:
  privileged: true
    capabilities:
      add:
      - IPC_LOCK
      - SYS_RESOURCE

Я что-то упускаю?

Я обнаружил, что размещение кода securityContext очень специфично и
описанное размещение в ссылке выше. Я разместил следующее:

    - name: ES_JAVA_OPTS
      value: "-Djava.net.preferIPv4Stack=true -Xms{{

.Values.data.heapSize}} -Xmx {{.Values.data.heapSize}} "
{{- диапазон $ ключ, $ значение: = .Values.cluster.env}}
- имя: {{$ key}}
значение: {{$ значение | Цитировать }}
{{- конец }}

начать новый код

    securityContext:
      capabilities:
        add:
          - IPC_LOCK
          - SYS_RESOURCE

закончить новый код

    image: "{{ .Values.image.repository }}:{{ .Values.image.tag }}"

Вт, 25 октября 2018 г., в 12:26 tobymiller1 [email protected]
написал:

Это ваша точка 2, с которой я борюсь. У меня точно такой же
dockerfile, как и вы (эластичный 5, но я сомневаюсь, что это проблема), и у меня есть
следующее в моем определении модуля:

    securityContext:
      privileged: true
      capabilities:
        add:
        - IPC_LOCK
        - SYS_RESOURCE

Я что-то упускаю?

-
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/kubernetes/kubernetes/issues/3595#issuecomment-433117265 ,
или отключить поток
https://github.com/notifications/unsubscribe-auth/ACWZzkx0BCrpQ0UyQP94iaBnfwgncLmAks5uoeZFgaJpZM4DT0Ae
.

@rewt Спасибо за вашу помощь. Это конфигурация, которая у меня есть, но, похоже, она не позволяет ulimit действовать как не root таким образом, и я не понимаю, почему это должно быть. Я не хочу зацикливаться на этой теме - думаю, мы поищем альтернативное решение.

не можете ли вы передать -e JAVA_OPTS = "- Xmx4096m" с помощью sudo docker run -d --privileged --restart = except-Stop --net = host -v / etc / kubernetes: / etc / kubernetes -v / var / run: / var / run -e JAVA_OPTS = "- Xmx4096m"
rancher / rancher- agent: v2.1.1 ........ Я почти уверен, что это помогает

@ tobymiller1 в решении от @rewt, чтобы оно действительно работало, вам нужно добавить строфу USER root к Dockerfile , а затем перейти к пользователю nobody (или какому-либо другому) после выполнения команды ulimit -l unlimited в альтернативной оболочке.

@ tobymiller1 Если вы хотите иметь возможность запускать образ как пользователь без полномочий root в kubernetes, вы можете использовать setcap непосредственно в исполняемом файле. RUN setcap cap_ipc_lock=+ep ./your_exe && setcap cap_sys_resource=+ep ./your_exe

Чтобы получить эту команду, вам понадобится пакет libcap , установленный в alpine. Добавьте эту строку, прежде чем переключаться на своего ограниченного пользователя.

В LInux возможности теряются, когда UID изменяется с 0 (root) на ненулевой (ваш ограниченный пользователь)

Do other stuff RUN setcap cap_ipc_lock=+ep ./your_exe && setcap cap_sys_resource=+ep ./your_exe USER your_limited_user
Исполняемый файл теперь может изменять ограничения пользователя и блокировать память.

Также следует отметить, что aufs НЕ поддерживает возможности, так как не поддерживает расширенные атрибуты. Вы должны использовать другую FS, например overlay2. Убедитесь, что ваш провайдер Kubernetes не использует aufs.

@jasongerard Только что попробовал ваше решение, но не работает, я что-то пропустил?

Я использую Alpine в качестве базового образа и хочу запустить "ulimit -l unlimited" в entrypoint.sh пользователем esuser без полномочий root. Мой кластер Kubernetes работает на Ubuntu 16.04 и использует overlay2 FS.

RUN apk add --no-cache libcap && setcap cap_ipc_lock=+ep /entrypoint.sh && setcap cap_sys_resource=+ep /entrypoint.sh
USER esuser

Получено такое сообщение об ошибке:
/entrypoint.sh: line 21: ulimit: max locked memory: cannot modify limit: Operation not permitted

@ wahaha2001 вы вызываете setcap в сценарии оболочки. Для вызываемого исполняемого файла требуется возможность. В случае сценария, какой бы исполняемый файл ни был в вашем '#!' понадобится возможность.

@jasongerard , спасибо за быстрый ответ. Я использую #! / Bin / bash в entrypoint.sh, поэтому я изменил его на:

RUN apk add --no-cache libcap && setcap cap_ipc_lock=+ep /bin/bash && setcap cap_sys_resource=+ep /bin/bash
USER esuser

Но все равно получаю ту же ошибку :(

@ wahaha2001 Вам все равно нужно будет добавить возможность IPC_LOCK для вашего модуля.

apiVersion: v1
kind: Pod
metadata:
  name: somename
spec:
  containers:
  - name: somename
    image: somename:latest
    securityContext:
      runAsNonRoot: true
      runAsUser: 1000
      capabilities:
        add: ["IPC_LOCK"]
  restartPolicy: Never

Поместите это сюда, чтобы потом снова найти: https://do-db2.lkml.org/lkml/2011/6/19/170

@arturalbov мы делаем что-то подобное с elasticsearch / cassandra, просто создаем собственное изображение с альтернативным сценарием точки входа, например:

#!/bin/bash

# Set memlock limit to unlimited
ulimit -l unlimited

# Call original entrypoint script
exec /usr/local/bin/docker-entrypoint.sh "${@}"

затем предоставьте те же возможности, которые вы упомянули ( privileged не требуется):

 securityContext:
     capabilities:
         add:
             - IPC_LOCK
             - SYS_RESOURCE

Это работает, только если мы используем root для запуска приложения. Любое решение для пользователей без полномочий root?

@manojtr см. мои комментарии выше о работе без

@jasongerard Я пробовал standard_init_linux.go:207: exec user process caused "operation not permitted" когда просто создаю докер, используя

docker build -t elasticsearch-2.4.6:dev --rm -f image/Dockerfile.v2 image

RUN setcap cap_ipc_lock=+ep /bin/bash && setcap cap_sys_resource=+ep /bin/bash

USER elasticsearch
CMD ["/bin/bash", "bin/es-docker"]

В случае с Elasticsearch изменение rlimit / блокирующей памяти вызывает беспокойство только в том случае, если вы не можете отключить подкачку , верно? Обмен AFAIK отключен на узлах Kubernetes , так что это не должно быть проблемой, верно?

Кстати, для Кассандры я пробовал следующее:

      initContainers:
      - name: increase-memlock-ulimit
        image: busybox
        command: ["sh", "-c", "ulimit -l unlimited"]
        securityContext:
          privileged: true

с участием

      securityContext:
        capabilities:
          add:
            - IPC_LOCK
            - SYS_RESOURCE

но он не работает, я все еще вижу ошибки о RLIMIT_MEMLOCK а значение внутри контейнера не изменяется на неограниченное ...

@guitmz Я не верю, что initContainer будет работать. В этом случае вы устанавливаете ulimit для _этого_ контейнера, а не для модуля в целом.

Ниже приведены ссылки на пример файла Dockerfile и pod.yaml для успешного запуска процесса без полномочий root с возможностью изменения ulimit. Обратите внимание, что процесс в этом примере изменяет ulimit с помощью системного вызова.

Dockerfile: https://github.com/jasongerard/mlockex/blob/master/Dockerfile
pod.yaml: https://github.com/jasongerard/mlockex/blob/master/pod.yaml

Проблемы устаревают после 90 дней бездействия.
Отметьте проблему как новую с помощью /remove-lifecycle stale .
Устаревшие выпуски гниют после дополнительных 30 дней бездействия и в конечном итоге закрываются.

Если сейчас можно безопасно закрыть эту проблему, сделайте это с помощью /close .

Отправьте отзыв в sig-testing, kubernetes / test-infra и / или fejta .
/ жизненный цикл устаревший

Можем ли мы удалить устаревшего бота для этой проблемы?

/ remove-жизненный цикл устаревший

Проблемы устаревают после 90 дней бездействия.
Отметьте проблему как новую с помощью /remove-lifecycle stale .
Устаревшие выпуски гниют после дополнительных 30 дней бездействия и в конечном итоге закрываются.

Если сейчас можно безопасно закрыть эту проблему, сделайте это с помощью /close .

Отправьте отзыв в sig-testing, kubernetes / test-infra и / или fejta .
/ жизненный цикл устаревший

/ remove-жизненный цикл устаревший

Контекст: работа подгруппы по архитектуре сигнатур для поиска технического долга
Категория: Готовность предприятия
Причина: интерес сообщества, люди пробуют обходные пути, полезно для корпоративных рабочих нагрузок, улучшает принятие на предприятии.

Проблемы устаревают после 90 дней бездействия.
Отметьте проблему как новую с помощью /remove-lifecycle stale .
Устаревшие выпуски гниют после дополнительных 30 дней бездействия и в конечном итоге закрываются.

Если сейчас можно безопасно закрыть эту проблему, сделайте это с помощью /close .

Отправьте отзыв в sig-testing, kubernetes / test-infra и / или fejta .
/ жизненный цикл устаревший

/ remove-жизненный цикл устаревший

+1

/ cc

+1

+1

+1

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

Я также хотел бы проголосовать за эту проблему, было бы действительно хорошо, если бы эта функция была доступна из коробки в Kubernetes вместо использования обходных путей и / или хаков.

Загляните в это сегодня в контексте EKS Fargate, где я не могу легко переопределить настройки ulimit Docker. Определенно был бы признателен за поддержку конфигурации Kubernetes для этого.

+1

+1