Комментарии 19
Внезапно, в гиперконвергентных средах контейнеры выполняются в виртуальных машинах. Садитесь - два)
Потому что PaaS слой того же OpenStack позволяет организовать очень гибкие инфраструктуры с ограниченной областью отказа и гибким управлением ресурсами.
И это очень прагматично: лучше иметь простой хост с ограниченным набором ПО, в котором крутятся VM со всяким трэшугаром, чем крутить это в хосте, пусть даже в контейнере. И именно поэтому многие крутят Cluster per client для k8s, а не namespace per client.
Ну во-первых - далеко не всё можно и нужно контейнеризировать
Во-вторых если нужно контейнеризировать не всё, и у нас всё-равно есть виртуализация - логично и контейнеры посадить в ВМки, а не городить отдельно кластер на физике для них
Вот это: "вы не хотите тратить человеческий ресурс на администрирование инфраструктуры" и наличие K8S это противоположенные установки. Вы серьезно считаете что Kubernetes не нуждается в ресурсе на администрирование?
Главный вопрос к вам - что с неконтейнезируемой частью инфраструктуры? Скажем, сервисы в контейнерах. Но сервисам нужна БД. Кафка. Прометей (с его хранилищем) и т.п. вещи, которые не имеет смысла держать в контейнерах. Как решается эта проблема? В статье об этом ни слова.
Лично у нас неконтейнеризируемая часть и не в контейнерах. Те же СУБД в контейнерах просто нерационально держать как минимум из-за скорости. Тут вопрос в том, что для разных задач подходят разные решения. Мы и не утверждаем - что контейнеры это панацея от всего! Но для ряда задач они оптимальны.
Я так много сталкиваюсь с заявлениями, что какое то ПО (чаще СУБД) не имеет смысла держать в контейнерах, что СУБД из-за контейнеризации с какой то другой скоростью работают. У меня когнитивный диссонанс, могут ли авторы этих высказываний технически аргументировать свои слова?
Вот например: есть у меня кубер кластер, 3 мастера на ВМ, 15 воркеров на ВМ, я добавляю ещё 12 нод аппаратные сервера и добавляю на них метку "СУБД", потом ставлю оператор для СУБД, в толерейшены прописываю, что СУБД запускать на нодах с меткой "СУБД", указываю игнорирование сигрупс, физический диск напрямую доступен контейнеру, сетка построена на MPLS например. В итоге получается, что на аппаратном сервере оператор из куба заводит СУБД, настраивает там репликацию и всё что читателю в голову придёт. Зайдя на сервер я увижу что у меня есть несколько дополнительных сервисов супервайзинга (кублет, крио) и процессы моей СУБД.
Альтернатива: всё что делает оператор СУБД я сделаю руками и запущу СУБД на аппаратном сервере не в контейнере. Зайдя на сервер я увижу процессы СУБД (системные демоны опустим). Вопрос, одинаковая ли будет производительность СУБД в обоих случаях и если нет, то почему? Я убеждён, что производительность будет одинаковая, т.к. окружение отличаться будет только наличием парочки других неймспейсов у процессов СУБД и парой дополнительных демонов (работа которых будет незметна, на уровне погрешности измерений).
А что с безопасностью контейнеров по сравнению с безопасностью виртуальных машин? Например, почему я должен (или НЕ должен) хотеть держать несколько контейнеров на одном хосте, если это увеличивает поверхность атаки на хост? И уязвимость с поднятием привилегий и выполнением произвольного кода в одном из сервисов угрожает всему хосту и данным из других контейнеров?
Или я несу чушь и такой исход не возможен? Сам не знаю, хотелось бы послушать более опытных товарищей.
В целом нормально там с безопасностью, если всё хорошо настроить.
Но! Нужен гораздо более грамотный инженер, а не студент-копипастер терраформовских конфигов, чтобы безопасность была на уровне. Внешняя простота K8S скрывает под собой весьма сложные сущности, которые надо хорошо понимать, чтобы обеспечить хотя-бы приемлемую безопасность.
А такой инженер стоит больших денег... Что в результате может съесть всю экономию на разрабах.
Контейнеры Docker ни при каких условиях нельзя сравнивать с виртуальными машинами. Это, как иногда говорят, сравнение "длинного и зелёного" - т.е. разные вещи принципиально.
Заголовок вызывающий, конечно. Но первый же абзац ставит все на свои места. По моему опыту, контейнеризация и ВМ для разработчика - это малая часть их применения. И очень часто применяются обе системы вместе.
Контейнеризация всего и вся поощряет раздолбайство и подход "фигак-фигак и в продакшн":
Надежность. Если контейнер, содержащий функцию вашего проекта «упадет», Kubernetes его просто автоматически перезапустит
...а если таких контейнеров набралось много , то забивание на мониторинг уже не вызывает тревоги, что внутри что-то не ладно. "И так сойдёт" становится линией поведения.
На выходе армия клепальщиков кода "на отвали" и продукты с никаким качеством. Неплохая технология, одна из многих, начинает успешно развращать разработчиков и пока про неё плодятся такие статьи "всех убьёт, круто!" ситуация к лучшему меняться не начнёт.
Я так много сталкиваюсь с заявлениями, что какое то ПО (чаще СУБД) не имеет смысла держать в контейнерах ...
... одинаковая ли будет производительность СУБД в обоих случаях и если нет, то почему?
Не надо не Stateless вещи в контейнеры. Дело совсем не в performance.
... не нужно писать подробные инструкции по развертыванию сервисов на других серверах и думать об операционной системе.
Я не хочу думать, у меня лапки. Думать нужно всегда. И понимать, что там под капотом, тоже.
Раньше делил системы по разным виртуалкам. Сейчас беру у провайдера виртуалки и в них запускаю в докере сервисы)
т.е. если говорить о заголовке статьи, то просто сферы использования немного сместились.
Мелочь проще делить по контейнерам, но для этой мелочи раздавать оборудование все равно лучше не напрямую, а через виртуалки.
Контейнеры обеспечивают виртуализацию на уровне OS
этот автор бездарен, несите нового
Почему контейнеры «убьют» виртуальные машины?