Если нужен graceful restart, то вместо отстрела, просто снимаете все лейблы с пода. Он ещё запущен, принимает запросы от пользователей, но для kube-proxy и для kube-scheduler он уже не видим. Первый снимет с него трафик, а второй запустит новый под где-нибудь. Через несколько секунд нагрузка на под упадёт до нуля, и его можно уже прибить. Собственно, rolling restart ровно это и делает. Только он делает это со всеми подами, которые у вас есть в кластере, а вы можете сделать это только с теми, которые вам нужно перенести на другие машины.
Тогда всё гораздо проще делается. Когда ваша логика решает разгрузить машину, она просто отстреливает «лишние» поды на ней. Replication controller у вас должен быть настроен с политикой LeastRequestedPriority, чтобы новые поды направлялись на наименее загруженные машины.
Я правильно понимаю, что вы хотите делать utilization based scheduling? Т.е. если нагрузка на конкретную ноду стала неприемлемо большой, то вы хотите раскидывать контейнеры на другие ноды?
Мне решение #1 кажется наиболее подходящим к философии Kubernetes. Единственное, если вы хотите ограничить нагрузку на машину, чтобы она потребляла на 30% меньше ресурсов, а не отключить её совсем, то вместо unschedulable лучше уменьшить лимит CPU и RAM (поле Capacity).
Это в планах. Предполагается, что можно будет задать ACL, какой под может с каким связываться по сети. Это решит много проблем с безопасностью прямо на уровне сети.
Вопросы, поднятые в топике, на мой взгляд, резонны. Единственное, что проблема не только и не столько в докере, сколько это вообще вопрос доверия в интернете. Мы устанавливаем пакеты из бинарных дистрибутивов, устанавливаем ОС, загружаясь с образа, скачанного из интернета, устанавливаем всякие плагины (Flash, например), взятые из интернета, бинарные драйверы видеокарт, скачанные с сайтов производителей. Даже если всё это подписано какими-то подписями, знаем ли мы этих людей, доверяем ли мы им? Даже собирая Linux from scratch, мы используем бинарник компилятора, загруженное ядро операционки. Есть ли гарантия, что они не встроят в компилируемый код бэкдор? Здравствуй, паранойя.
Если честно, я не знаю, как вести себя в условиях недоверенной среды. Не доверять всем — слишком дорого. Я могу написать свой компилятор C, провести аудит всего кода, который используется в продакшне, но это настолько огромная задача, что не хватит жизни. Для себя я использую такую формулу: если уж использовать чужие решения, то только те, которыми пользуется максимально большое число людей (популярные дистрибутивы, популярные пакеты, в докерхабе — только базовые контейнеры от самого докерхаба), чтобы минимизировать риски. А всё остальное писать самому.
Логовница может 1. сдохнуть и потерять часть логов, 2. не справляться с потоком логов от многих машин и, опять же, терять их. Лучше логи писать локально на диск, а потом неторопливо их высасывать в хранилище.
Ага. А ещё удобно тестовую версию системы поднимать. Говоришь — хочу вот точно такую базу данных, в неё, пожалуйста, вчерашний бэкап с продакшна, ещё нужны такие же сервисы, как в продакшне, только с новой версией. И всё само поднимается, связывается друг с другом, и готово к тестированию. Потом прибить всё одной командой, чтобы ресурсы не ело.
Сбор логов — это отдельная задача. Надо настроить nginx (и все другие контейнеры) писать логи на stderr, потом их нужно чем-то собирать со всего кластера и уметь по ним поиск делать. Говорят, Fluentd + Elasticsearch хорошо работают.
1. Это решается на этапе scheduling'а. Kubernetes не отправит два пода, которым нужен один и тот же внешний порт, на одну машину. Если на машине порт занят чем-то другим (не подом), то под будет висеть в статусе Pending, пока порт не освободится и он не сможет стартовать.
2. Вы можете запустить одну единственную ноду с nginx, и настроить ваш домен, чтобы он указывал на её IP-адрес. Тогда Cloudflare не нужен. Всё просто работает. Cloudflare — это полезное дополнение, чтобы фронтенд не был единой точкой отказа. Это собственно и не только к Kubernetes относится, а вообще к любой системе, которая претендует на отказоустойчивость.
Kubernetes, сам по себе, не решает проблему связи с пользователем.
Очень даже решает. Вы можете запустить Pod с опцией hostNetwork: true. В результате порты будут доступны не на виртуальном динамическом IP, а снаружи. Конфиг выглядит примерно так:
Тут важны два момента. Во-первых, мы ограничиваем, на каких нодах запускать nginx (только на тех, которые мы пометили как frontend=true), а во-вторых, порты 80 и 443 будут доступны снаружи (hostNetwork: true).
Потом можно снаружи какой-нибудь Cloudflare прицепить, чтобы внешний трафик проксировал на эти машины, и получится нормальный отказоустойчивый фронтенд.
Предполагается делать это так. Вы ставите на все машины кластера GlusterFS, который поддерживает нужный уровень избыточности данных. Затем, когда контейнер запускается, у него создаётся volume, «смонтированный» в один из каталогов GlusterFS. В результате, все инстансы вашего приложения имеют доступ к одной и той же файловой системе без лишних телодвижений.
Проблема серьёзная, и она не только прошивок касается. В электронике разработчики передирают typical applications, даже не удосужившись подобрать номиналы под параметры конкретного устройства. В веб- и десктоп-программировании — одна копипаста со stackoverflow. С распространением IoT чудеса нас ждут — полностью согласен. Статьи в «Хакере» про взлом унитазов будут — это точно.
Актуально. Выделение памяти в куче использует системный вызов sbrk, который просто сдвигает доступный приложению предел адресов. Т.е. если malloc не смог найти свободный кусок памяти в куче, он её отращивает через sbrk. А когда процесс полезет в ту память первый раз, ядро поймает page fault и отмапит физическую память на эти адреса. Если при этом не найдётся свободной памяти и не удастся выгнать кого-нибудь из памяти, то включится страшный oom killer и будет искать, кого бы принести в жертву. Это уже другая история.
в Гугле есть негативная корреляция между победами человека на олимпиадах для программистов и его успехами в работе
Я не думаю, что это специфика Гугла. И корреляция, скорее всего, вызвана тем, что на работу берут или перспективных новичков (спортивное программирование — способ оценить перспективность), или уже опытных экспертов. По итогам работы часть новичков уходит, а профессионалы по большей части остаются — они в этом плане более предсказуемы. В итоге — такая странная корреляция, которая наводит на ложный вывод, что «олимпиадность» мешает карьере. Я уверен, что если сравнить новичков-не-олимпиадников и новичков-олимпиадников, или опытных-не-олимпиадников и опытных-олимпиадников, там всё будет наоборот.
По поводу п. 1. Для ноды достаточно просто писать расширения, чтобы разгрузить основной поток и выполнять тяжёлые вычисления на c++ в отдельных потоках.
Про LeastRequestedPriority тут — github.com/GoogleCloudPlatform/kubernetes/blob/master/plugin/pkg/scheduler/algorithmprovider/defaults/defaults.go#L65
Документацию человеческую, насколько я знаю, не написали ещё.
Если честно, я не знаю, как вести себя в условиях недоверенной среды. Не доверять всем — слишком дорого. Я могу написать свой компилятор C, провести аудит всего кода, который используется в продакшне, но это настолько огромная задача, что не хватит жизни. Для себя я использую такую формулу: если уж использовать чужие решения, то только те, которыми пользуется максимально большое число людей (популярные дистрибутивы, популярные пакеты, в докерхабе — только базовые контейнеры от самого докерхаба), чтобы минимизировать риски. А всё остальное писать самому.
2. Вы можете запустить одну единственную ноду с nginx, и настроить ваш домен, чтобы он указывал на её IP-адрес. Тогда Cloudflare не нужен. Всё просто работает. Cloudflare — это полезное дополнение, чтобы фронтенд не был единой точкой отказа. Это собственно и не только к Kubernetes относится, а вообще к любой системе, которая претендует на отказоустойчивость.
Тут важны два момента. Во-первых, мы ограничиваем, на каких нодах запускать nginx (только на тех, которые мы пометили как frontend=true), а во-вторых, порты 80 и 443 будут доступны снаружи (hostNetwork: true).
Потом можно снаружи какой-нибудь Cloudflare прицепить, чтобы внешний трафик проксировал на эти машины, и получится нормальный отказоустойчивый фронтенд.