Вариант для распечатки		Пред. тема | След. тема
Форум Разговоры, обсуждение новостей
Изначальное сообщение		[ Отслеживать ]

"В Kubernetes 1.13 устранена критическая уязвимость, позволяю..."	+/–
Сообщение от opennews (??), 05-Дек-18, 12:19
Состоялся (https://kubernetes.io/blog/2018/12/03/kubernetes-1-13-releas.../) релиз платформы оркестровки контейнеров Kubernetes 1.13 (http://kubernetes.io/), позволяющей как единым целым управлять кластером Linux-контейнеров, созданных с использованием таких инструментариев как Docker и rkt. В новой версии устранена критическая уязвимость (https://github.com/kubernetes/kubernetes/issues/71411) (CVE-2018-1002105 (https://security-tracker.debian.org/tracker/CVE-2018-1002105)) в реализации API, которая позволяет (https://access.redhat.com/security/vulnerabilities/3716411) любому пользователю получить полный контроль за кластером изолированных контейнеров. Проблема также устранена (https://groups.google.com/forum/m/#!topic/kubernetes-announc...) в обновлениях 1.10.11, 1.11.5 и 1.12.3. Для совершения атаки достаточно отправить через API специально оформленный запрос определения доступных бэкентов (discovery-запрос). Из-за ошибки данный тип запросов позволяет использовать сервер API (kube-apiserver) в качестве посредника для подсоединения к любому бэкенду и перенаправить на бэкенд любые запросы, используя соединение, установленное с сервером API.  Соответственно, перенаправляемые через подобное соединения запросы будут обработаны бэкендом как внутренние запросы от сервера API с использование параметров аутентификации сервера API. По умолчанию все аутентифицированные и неаутентифицированные пользователи Kubernetes имеют возможность отправки через API discovery-запросов, которых достаточно для совершения атаки. Таким образом, любой непривилегированный пользователь Kubernetes, имеющий доступ к API, может получить полный контроль за всей инфраструктурой, например, отправив запрос exec для выполнения своего кода на хосте. Кроме получения контроля за инфраструктурой Kubernetes уязвимость также может применяться для целевых атак на клиентов через манипуляцию размещёнными в облаке клиентскими сервисами. Проблема проявляется во всех версиях Kubernetes, начиная с релиза 1.0. Всем администраторам Kubernetes рекомендуется срочно обновить свои системы до актуальных выпусков, а также провести аудит системных логов на предмет возможной вредоносной активности. В качестве обходного метода защиты от атак со стороны неавторизированных пользователей можно запретить анонимный доступ к API при помощи опции "--anonymous-auth=false" и отозвать права на выполнение операций exec/attach/portforward. Отдельно отмечается, что в логах Kubernetes атака с использованием неавторизированных запросов никак не фиксируется, поэтому определить была ли компрометация можно лишь по косвенным признакам. Основные (https://coreos.com/blog/whats-new-kubernetes-113) новшества (https://github.com/kubernetes/kubernetes/blob/master/CHANGEL...) Kubernetes 1.13: -  Стабилизирован интерфейс CSI (Container Storage Interface), позволяющий стандартизировать плагины для поддержки различных систем хранения. CSI предоставляет единый интерфейс для выделения места, прикрепления и монтирования хранилищ, дающий возможнсть поставлять плагины для интеграции с различными службами хранения без необходимости внесения изменений в кодовую базу Kubernetes; -  По умолчанию задействован DNS-сервер CoreDNS (https://www.opennet.dev/opennews/art.shtml?num=47674), развиваемый под эгидой организации Linux Foundation. CoreDNS написан на языке Go и примечателен гибкой архитектурой на базе подключаемых плагинов. Например, через плагины реализованы такие специфичные функции, как обнаружение сервисов Kubernetes, накопление метрик для системы мониторинга Prometheus и интеграция с системой хранения конфигурации etcd; -  Стабилизирован kubeadm (https://kubernetes.io/docs/reference/setup-tools/kubeadm/kub.../), упрощённый интерфейс для управления кластером Kubernetes, позволяющий выполнять такие операции как создание и развёртывание кластера на имеющемся оборудовании, настройка базовых компонентов Kubernete, подключение и удаление узлов, выполнение операций обновления;-  Экспериментальный интерфейс для создания плагинов для интеграции со сторонними системами мониторинга;-  Стабилизирован сервис Kubelet Device Plugin Registration, предоставляющий средства для доступа к Kubelet из плагинов; -  Стабилизирован планировщик распределения контейнеров TAVS (Topology Aware Volume Scheduling), учитывающий топологию разделов Pod (учитывает ограничения, установленные для узлов и зон); -  Перешли на стадию бета-тестирвоания APIServer DryRun, команда Kubectl Diff и возможность использования локальных (raw) блочных устройств в качестве хранилищ постоянных данных (Persistent Volume Source). Напомним, что код Kubernetes написан на языке Go и распространяется (http://github.com/kubernetes/kubernetes) под лицензией Apache 2.0. Проект изначально был создан компанией Google, но затем переведён на независимую площадку, курируемую организацией Linux Foundation. Платформа позиционируется как развиваемое сообществом универсальное решение, не привязанное к отдельным системам и способное работать с любыми приложениями в любых облачных окружениях. Предоставляются функции для развёртывания и управления инфраструктурой, такие как ведение базы DNS, балансировка нагрузки, распределение контейнеров по узлам кластера (миграция контейнеров в зависимости от изменения нагрузки и потребностей в сервисах), проверка работоспособности на уровне приложений, управление аккаунтами, обновление и динамическое масштабирование работающего кластера, без его остановки. Возможно развёртывание групп контейнеров с выполнением операций обновлений и отмены изменений сразу для всей группы, а также  логическое разбиение кластера на части с  разделением ресурсов. Имеется поддержка динамической миграции приложений, для хранения данных которых могут применяться как локальные хранилища, так и сетевые системы хранения. URL: https://www.redhat.com/en/blog/kubernetes-privilege-escalati... Новость: https://www.opennet.dev/opennews/art.shtml?num=49722
Ответить | Правка | Cообщить модератору

Сообщения по теме

[Сортировка по времени | RSS]

3. "В Kubernetes 1.13 устранена критическая уязвимость, позволяю..."	+9 +/–
Сообщение от A.Stahl (ok), 05-Дек-18, 12:25
>Kubernetes Что-то про эту штуку пишут куда ни плюнь. Какие-то семинары, съезды, конференции. Баги теперь ещё. Это какой-то злобный маркетинг?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	4. "В Kubernetes 1.13 устранена критическая уязвимость, позволяю..."	+9 +/–
	Сообщение от Аноним (4), 05-Дек-18, 12:27
	С разморозкой, сношают мозги уже не первый год.
	Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

	6. "В Kubernetes 1.13 устранена критическая уязвимость, позволяю..."	+5 +/–
	Сообщение от Stax (ok), 05-Дек-18, 13:09
	Нет, просто она затыкает целый набор потребностей, а все альтернативы сильно уступают. Вот прямо сильно-сильно. Поэтому в жизни по факту можно встретить только k8s и docker swarm, но последнее обычно поднимается исключительно от нежелания разбираться с k8s (а самый его большой недостаток - он сложный и требует много всего для нормальной эксплуатации! Ну и далеко не все реализовано, что хотелось бы). Так что использовать k8s приходится практически безальтернативно, при этом многие хитрые вещи и интеграции требуют немалых усилий - вот и вылезают "семинары, съезды, конференции".
	Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

	16. "В Kubernetes 1.13 устранена критическая уязвимость, позволяю..."	+/–
	Сообщение от Аноним (16), 05-Дек-18, 15:48
	Подскажите, как они в сравнении с hashicorp nomad?
	Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

	20. "В Kubernetes 1.13 устранена критическая уязвимость, позволяю..."	+/–
	Сообщение от Stax (ok), 05-Дек-18, 16:25
	> Подскажите, как они в сравнении с hashicorp nomad? Какой ужас )) Без понятия. Почитайте https://www.reddit.com/r/devops/comments/6o4ryf/nomad_vs_kub.../ или https://dev-ops-notes.ru/cloud/c%D1%80%D0.../
	Ответить | Правка | ^ к родителю #16 | Наверх | Cообщить модератору

	54. "В Kubernetes 1.13 устранена критическая уязвимость, позволяю..."	+/–
	Сообщение от Аноним (16), 06-Дек-18, 12:46
	Товарищи уже объяснили: Nomad взяли из-за нежелания разбираться с k8s, из-за простоты его настройки и тесной интеграции с consul и vault, которые уже и без номада использовались на проекте. Пока что результатом довольны. Лично мне понравилась возможность генерить конфиги, которые будут использоваться в контейнере, из шаблона, в котором данные (переменные) берутся напрямую из консула и/или из волта. Есть внятная веб-морда.
	Ответить | Правка | ^ к родителю #20 | Наверх | Cообщить модератору

	55. "В Kubernetes 1.13 устранена критическая уязвимость, позволяю..."	+/–
	Сообщение от Аноним (16), 06-Дек-18, 12:47
	И да, Swarm всех этих плюшек не имеет.
	Ответить | Правка | ^ к родителю #54 | Наверх | Cообщить модератору

	19. "В Kubernetes 1.13 устранена критическая уязвимость, позволяю..."	+1 +/–
	Сообщение от username (??), 05-Дек-18, 16:13
	Если авс то можно впихнуть ECS и вздохнуть хоть там.
	Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

	24. "В Kubernetes 1.13 устранена критическая уязвимость, позволяю..."	+/–
	Сообщение от freehck (ok), 05-Дек-18, 16:55
	Поддерживаю. Если у Вас 100+ контейнеров, то k8s маст хэв. Если меньше, то можно в принципе не заморачиваться. Я для малых проектов вообще поднимаю простой докер с фланелью и деплою контейнеры через ansible.
	Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

	38. "В Kubernetes 1.13 устранена критическая уязвимость, позволяю..."	+/–
	Сообщение от Michael Shigorin (ok), 05-Дек-18, 23:38
	100++, справляемся без дырок на дырках. :)
	Ответить | Правка | ^ к родителю #24 | Наверх | Cообщить модератору

	51. "В Kubernetes 1.13 устранена критическая уязвимость, позволяю..."	+1 +/–
	Сообщение от freehck (ok), 06-Дек-18, 11:08
	> 100++, справляемся без дырок на дырках. :) Чувак, то, что и без k8s можно справляться при большом количестве контейнеров -- я не спорю. Я говорю, что при таких объёмах использование k8s уже оправдано, и с ним всё-таки легче и удобнее.
	Ответить | Правка | ^ к родителю #38 | Наверх | Cообщить модератору

	59. "В Kubernetes 1.13 устранена критическая уязвимость, позволяю..."	+/–
	Сообщение от SysA (?), 06-Дек-18, 18:06
	Вообще-то альтернатива есть - Serverless!
	Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

	32. "В Kubernetes 1.13 устранена критическая уязвимость, позволяю..."	+3 +/–
	Сообщение от SubGun (ok), 05-Дек-18, 22:22
	> Что-то про эту штуку пишут куда ни плюнь. Какие-то семинары, съезды, конференции. Баги теперь ещё. > Это какой-то злобный маркетинг? Ну надо же ее как-то продать. И желательно подороже. Поэтому ее чуть ли не с первых версий форсили, как готовую к продакшн. Хотя большинству эта штука нафиг не нужна.
	Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

	35. "В Kubernetes 1.13 устранена критическая уязвимость, позволяю..."	+/–
	Сообщение от ГабенВульвович (?), 05-Дек-18, 22:36
	Это такой себе клаудстэк контейнерной и микросервис-эры, который позволяет автоматизировать кластеризацию/фэйловер/конфигурацию контейнеров и служб, основанных на них.
	Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

	50. "В Kubernetes 1.13 устранена критическая уязвимость, позволяю..."	+/–
	Сообщение от Dmitry77 (ok), 06-Дек-18, 09:15
	У нас порядка 50 отдельных проектов. Можно на каждый с проект по отдельному серверу. Но обычно не требуется такие мощьностию  А в kubernates кластер можно их все запихать и не морочиться с распределением по машинам. Ещё есть прикольная штука- helm. это  package  manager для серверных приложение.
	Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

8. "В Kubernetes 1.13 устранена критическая уязвимость, позволяю..."	+3 +/–
Сообщение от Аноним (8), 05-Дек-18, 13:45
Судя по описанию проблемы и учитывая, что "проблема проявляется во всех версиях Kubernetes, начиная с релиза 1.0" - это не совсем обычная дыра безопасности от кривой реализации. Это проблема архитектуры, логики работы. Ее наличие красноречиво говорит о мозгах разработчиков. Потенциально опасный продукт. "О сколько нам открытий чудных..."
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	10. "В Kubernetes 1.13 устранена критическая уязвимость, позволяю..."	+2 +/–
	Сообщение от Аноним (10), 05-Дек-18, 14:21
	> Напомним, что код Kubernetes написан на языке Go
	Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

	11. "В Kubernetes 1.13 устранена критическая уязвимость, позволяю..."	–1 +/–
	Сообщение от анонзыы (?), 05-Дек-18, 14:43
	перепишите на D))) тут почитал книжку по D и...... понял что это такая смесь си++,питон и ява( тут не оч уверен). странный замес.))) пишите на нем))
	Ответить | Правка | ^ к родителю #10 | Наверх | Cообщить модератору

	15. "В Kubernetes 1.13 устранена критическая уязвимость, позволяю..."	+1 +/–
	Сообщение от Аноним (15), 05-Дек-18, 15:47
	D - огонь! Пишу на нём. Не хватает разрабов.
	Ответить | Правка | ^ к родителю #11 | Наверх | Cообщить модератору

	17. "В Kubernetes 1.13 устранена критическая уязвимость, позволяю..."	+/–
	Сообщение от Аноним (17), 05-Дек-18, 16:04
	А QMLный гуй из D использовать можно?
	Ответить | Правка | ^ к родителю #15 | Наверх | Cообщить модератору

	18. "В Kubernetes 1.13 устранена критическая уязвимость, позволяю..."	+/–
	Сообщение от Аноним (17), 05-Дек-18, 16:06
	Наверное, имелось ввиду, что на типа безопасных языках тоже уязвимости случаются.
	Ответить | Правка | ^ к родителю #11 | Наверх | Cообщить модератору

	41. "В Kubernetes 1.13 устранена критическая уязвимость, позволяю..."	+1 +/–
	Сообщение от анонзыы (?), 05-Дек-18, 23:54
	программы пишут люди. естественно накосячить могут все. и что самое главное ни в одной программе их может и не быть, но появись они вместе создадут глюк или дыру в системе. это же известный факт. и никакой язык не может быть абсолютно безопасным. через тот же питон вызови в шелл "rm -rf /" ))) ну это утрирую , но принцип понятен. и нет абсолютно плохих языков или хороших. есть кривые руки)) и не подходящее применение( не своя стезя).
	Ответить | Правка | ^ к родителю #18 | Наверх | Cообщить модератору

	36. "В Kubernetes 1.13 устранена критическая уязвимость, позволяю..."	+1 +/–
	Сообщение от vedronim (?), 05-Дек-18, 23:23
	>> Напомним, что код Kubernetes написан на языке Go Написали бы на си, все было бы по другому.
	Ответить | Правка | ^ к родителю #10 | Наверх | Cообщить модератору

	64. "В Kubernetes 1.13 устранена критическая уязвимость, позволяю..."	+/–
	Сообщение от InuYasha (?), 07-Дек-18, 14:11
	В параллельной stable-вселенной они и написаны на Си. А у нас testing-вселенная, так что, живём как живём... :(
	Ответить | Правка | ^ к родителю #36 | Наверх | Cообщить модератору

14. "В Kubernetes 1.13 устранена критическая уязвимость, позволяю..."	+1 +/–
Сообщение от hellobillyboy (?), 05-Дек-18, 15:43
> Проблема проявляется во всех версиях Kubernetes, начиная с релиза 1.0 т.е. больше 3х лет https://github.com/kubernetes/kubernetes/tags?after=v0.21.3 очень ынтерпрайзно
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	21. "В Kubernetes 1.13 устранена критическая уязвимость, позволяю..."	+/–
	Сообщение от Аноним (21), 05-Дек-18, 16:27
	Так не выставляй api и dash задницей на мороз и будет нормально, как будто в другом софте таких багов никогда не было
	Ответить | Правка | ^ к родителю #14 | Наверх | Cообщить модератору

22. "В Kubernetes 1.13 устранена критическая уязвимость, позволяю..."	+2 +/–
Сообщение от Аноним (22), 05-Дек-18, 16:31
>уязвимость, позволяющая поднять свои привилегии Ну так свои же :) Расходимся.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	43. "В Kubernetes 1.13 устранена критическая уязвимость, позволяю..."	+/–
	Сообщение от анонзыы (?), 06-Дек-18, 00:20
	не поешь и поднять не сможешь))) брысь за редактор код писать)))
	Ответить | Правка | ^ к родителю #22 | Наверх | Cообщить модератору

23. "В Kubernetes 1.13 устранена критическая уязвимость, позволяю..."	–1 +/–
Сообщение от Vitaliy Blats (?), 05-Дек-18, 16:51
Что можно такого пихать в эти контейнеры, чего нельзя размещать под хостом, а раз уж необходимо, почему оно не может работать под нормальным KVM ? [сообщение отредактировано модератором]
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	25. "В Kubernetes 1.13 устранена критическая уязвимость, позволяю..."	+7 +/–
	Сообщение от Stax (ok), 05-Дек-18, 18:21
	> Что можно такого пихать в эти контейнеры, чего нельзя размещать под хостом, > а раз уж необходимо, почему оно не может работать под нормальным > KVM ? Дык набирают хипстеров-разработчиков, и дальше оказывается, что они не готовы тратить время на то, чтобы обеспечить запуск их компонента в чем-либо, кроме последней убунте, в которой они его пишут. И не имеют желания разбираться с чем-то еще, потому что сложно, непонятно, не те версии и тд и тп. И у администратора и других разработчиков тоже нет времени и желания обеспечивать, чтобы эти компоненты работали под чем-то еще. В какой-то момент приходится признать, что выгонять разработчиков не вариант, научить делать нормально нереально, а дяденьки, который за них приведет код в состояние, в котором этим можно будет как-то управляемо менеджить нет. И приходится дать каждому разработчику свою песочницу, которую он уже сам себе делает для каждого компонента как ему нравится - с вкривь и вкось мешаниной из распаковки тарболлов / make install, pip и npm и прочим, с условияем, что за это отвечает сам разработчик. Потому что иначе он не умеет и учиться нормально не собирается, а стороннему человеку поддерживать эту кашу невозможно. К счастью, можно заставить разработчика описать всю эту кашу разок в Dockerfile к каждому проекту и под угрозой увольнения заставить поддерживать хотя бы свои Dockerfile'ы к своим проектам. А дальше встает вопрос, как с этим жить. Виртуалки не вариант, потому что во-первых слишком тяжеловесные для такого применения, во-вторых нормально не скриптуются на таком уровне (не vagrant же брать, гвоздями приколоченному к virtualbox, у которого 50% функциональности отлетает при использовании libvirt плагина? И cloud-init тут тоже не спасает). Поэтому - от полного развала всего и вся спасает только docker. А дальше встают вопросы - как этот ворох контейнеров менеджить, раскидывать по машинкам с точки зрения оптимизации ресурсов, поднимать упавшие, масштабировать нужное число копий, устанавливать сетевые и прочие взаимодействия. Ну и приходим к kubernetes. Каким образом KVM-то поможет? А kubernetes узлы можно при желании запускать в KVM, а не на голом железе. Правда, кроме как для dev или тестирования в этом смысла не очень много.
	Ответить | Правка | ^ к родителю #23 | Наверх | Cообщить модератору

	26. "В Kubernetes 1.13 устранена критическая уязвимость, позволяю..."	+1 +/–
	Сообщение от Аноним (26), 05-Дек-18, 18:46
	спасибо за коммент. Мне многое стало понятно про хипстеров и зачем нужны контейнеры. Спасибо!
	Ответить | Правка | ^ к родителю #25 | Наверх | Cообщить модератору

	28. "В Kubernetes 1.13 устранена критическая уязвимость, позволяю..."	+1 +/–
	Сообщение от Анонимус2 (?), 05-Дек-18, 19:05
	Предлагаю описать как не используя динамическую инфраструктуру поднять новый тестовый стенд из сотни разных сервисов. Потом сделать то же самое, но с каким-нибудь openstack. А когда через полгода надоест пытаться это сделать - подумать что может дать докер для этого.
	Ответить | Правка | ^ к родителю #26 | Наверх | Cообщить модератору

	29. "В Kubernetes 1.13 устранена критическая уязвимость, позволяю..."	+/–
	Сообщение от Аноним (29), 05-Дек-18, 19:46
	> Предлагаю Спасибо, что подыграли. Выше так и написали, что те, кто сами решать возникающие проблемы не хотят, просто переваливают всё на докер. А если серьёзно, то конкретно в вашей ситуации докер, может, и нужен. Но в 99% интернет-блогов докер используется именно так, как описал аноним выше: чтобы пользователь вместо установки какой-то софтины просто брал контейнер, куда запрятана целая операционка. И я опускаю вопрос о том, ЗАЧЕМ вам тестовый стенд из сотни серверов, и почему на тех задачах, которые вы с его использованием решаете, вы не можете заработать сумму, достаточную для более грамотной организацию процесса.
	Ответить | Правка | ^ к родителю #28 | Наверх | Cообщить модератору

	34. "В Kubernetes 1.13 устранена критическая уязвимость, позволяю..."	+2 +/–
	Сообщение от Stax (ok), 05-Дек-18, 22:33
	> Спасибо, что подыграли. Выше так и написали, что те, кто сами решать возникающие проблемы не хотят, просто переваливают всё на докер. Ну так дело, в целом, не в решении проблем и не в переваливании на докер. Докер просто замечательный инструмент, чтобы делегировать ответственность за окружение приложения от админа к разработчику. Потому что даже если все не настолько ужасно, как я написал в примере выше, проблема того, что разработчик хочет чего-то, а у админа нет времени / желания разбираться / объяснять, что так глобально нельзя, а можно максимум в небольшой песочнице - возникает. И докер это хороший способ убрать эту проблему. Убрали - и больше разработчику не нужно чуть что, ходить на поклон к админу и согласовывать окружение. Это офигенно ускоряет процесс от разработки до выкатывания. Опять же, это возможность иметь CI, где разработчик может без каких-либо проблем менять продакшен окружение (правкой Dockerfile) в любой момент, когда это требуется. Ну а использование докера в продакшене очень быстро приводит к внедрению k8s. Ибо если не он, то что?
	Ответить | Правка | ^ к родителю #29 | Наверх | Cообщить модератору

	39. "В Kubernetes 1.13 устранена критическая уязвимость, позволяю..."	–1 +/–
	Сообщение от Michael Shigorin (ok), 05-Дек-18, 23:43
	> ...а у админа нет времени / желания разбираться / объяснять, что так > глобально нельзя, а можно максимум в небольшой песочнице - возникает. Голые cgroups -- это _не_ песочница; так, авоська для удобствия. > И докер это хороший способ убрать эту проблему. Убрали - и больше > разработчику не нужно чуть что ходить на поклон к админу > и согласовывать окружение. ...и не только разработчику ;-]
	Ответить | Правка | ^ к родителю #34 | Наверх | Cообщить модератору

	49. "В Kubernetes 1.13 устранена критическая уязвимость, позволяю..."	+/–
	Сообщение от лютый лютик_ (?), 06-Дек-18, 09:10
	>чтобы делегировать ответственность за окружение приложения от админа к разработчику А не сильно жирно разрабам решать на чём прод будет крутиться? Если в конторе прод на CentOS/RHEL, то тестовое окружение должно быть на Центосе. На десктопе пусть себе абанту ставит. И зачем в данной схеме докер? Вообще, проблема совместимости сильно раздута, для сишников это может и актуально, а всяким жаберам, питонщикам да JSникам плюс минус пара версий ни роялит.
	Ответить | Правка | ^ к родителю #34 | Наверх | Cообщить модератору

	56. "В Kubernetes 1.13 устранена критическая уязвимость, позволяю..."	+/–
	Сообщение от Аноним (16), 06-Дек-18, 13:33
	Вот простой пример из реальной жизни: у разработчиков Федора, на продакшене CentOS. Баги у первых не воспроизводятся, но присутствуют на центосе из-за разных версий зависимостей (версии системных либ, и, вы будете удивлены, проект на питоне, но проблема всё же во внешних непитоновых зависимостях). Как тут девелопить и дебажить? Юзать центос на десктопе как-то никто не хочет, да и админы, ответственные за рабочие станции, говорят что это плохая идея. Поднимать целую VM не вижу смысла, тем более, это неудобно даже с тем же "упрощающим разработку" Vagrant – не ясно как синхронизировать рабочий каталог в две стороны, да так, чтобы файлы оставались доступными из хоста когда VM остановлена. Доцкер эту проблему успешно решает. Во время разработки каталог с кодом монтируется волюмом в контейнер и позволяет делать то что нам нужно (бесшовная двусторонняя синхронизация без задержек, т.к. по сути это mount в пределах локальной ФС). Во время сбокри имиджа волюм не используется, а производится чистый git clone всего из репы, куда выкладывается уже готовый код. Имидж собираем сами из того же центоса. А коль уж у нас есть самособранный имидж, куда мы самостоятельно прописали зависимости, и он по максимуму воспроизводит окружение, которое уже есть на проде (который пока ещё без всяких контейнеров), то почему бы эти имиджи не выкатывать сразу на прод вместо ручной установки и настройки всего? Ведь это и так приходится делать во время разработки, почему бы не использовать уже однажды настроенное. Само собой, это позволит оттестировать на машине разработчика не только обновление нашего приложения, а и системного окружения. Из приятных бонусов это даёт возможность развернуть несколько инстансов для разных нужд (один исполняет только внутренние задачи, другой обслуживает клиентов по http, третий тоже и т.д.) одинаково легко хоть на одной машине, хоть на разных, благо отдельно стоящая БД это позволяет. Так можно было и раньше используя несколько обычных машинок (физических или VM) и какой-нибудь Ansible, но тут профит в том, что контейнер стартует моментально после скачивания имиджа, и не надо ждать пока yum всё поставит. Если машин много, то надо ждать установки и переконфигурации каждой, а в случае с контейнерами достаточно дождаться скачивания имиджа и пересоздания контейнера на нём. При использовании инкрементальных обновлений (т.е. слоёв, базирующихся на предыдущем выкаченном имидже) это происходит очень быстро. Насчёт оверхеда – его мало в плане цпу и памяти, ведь не используется виртуализация и своё ядро (и да, в плане изоляции это минус). В плане дискового оверхеда – если грамотно собирать имиджи (правильно формировать слои), то он получается небольшой благодаря переиспользованию нижележащих слоёв (если есть три имиджа, которые базируются на четвёртом, то на диске окажется лишь один экземпляр четвёртого).
	Ответить | Правка | ^ к родителю #49 | Наверх | Cообщить модератору

	57. "В Kubernetes 1.13 устранена критическая уязвимость, позволяю..."	+/–
	Сообщение от Аноним (16), 06-Дек-18, 13:37
	> Во время сбокри имиджа волюм не используется Имеется в виду "во время сборки для CI или продакшена", т.е. не во время разработки.
	Ответить | Правка | ^ к родителю #56 | Наверх | Cообщить модератору

	63. "В Kubernetes 1.13 устранена критическая уязвимость, позволяю..."	+/–
	Сообщение от лютый лютик_ (?), 07-Дек-18, 08:23
	>у разработчиков Федора,на продакшене CentOS. >Баги у первых не воспроизводятся, но присутствуют >на центосе из-за разных версий зависимостей Я так и не понял. В каких-то центосовых либах якобы  баги, а в федоре нет (что уже звучит фантастично). Девки ваши соберут свою прожку с либами от федоры и выкатят в прод? Ну в пень, это не решение проблемы. А если докер им нужен только для "более удобного дебага с центосовыми либами, сидя в федоре", то спрашивается, а зачем потом тащить этот ваш доцкер дальше машины девы? То что доцкер решает какие-то проблемы никто не спорит, плохо то, что он привносит другие проблемы плюс оверхед _в разработку_. У меня есть на виду один фанатик. Иногда на банальных вещах стопорится на день. Чего-то там пересобирает, ковыряет, перенастраивает. И в целом, от докерофилов много блабла про удобство работы и плюшки и тд, а по факту, из официальной yum репы софт обновляется как часы, а докерный софт дева висит месяцами протухший. Ну работает же.
	Ответить | Правка | ^ к родителю #56 | Наверх | Cообщить модератору

	52. "В Kubernetes 1.13 устранена критическая уязвимость, позволяю..."	+1 +/–
	Сообщение от Crazy Alex (ok), 06-Дек-18, 12:44
	Я бы по-другому сказал - докер - это способ разделить софт на компоненты с явно указанными зависимостями.  Нужен какой-то порт открытый - пропиши, нужен доступ куда-то на диск - пропиши, и так далее. В общем, естественное следствие массового увеличения сложности софта и способ борьбы с ней. То есть не "у кого-то нет желания разбираться", а совершенно закономерное повышение уровня, которое началось с того, что нумерованным ячейкам памяти стали присваивать имена, а инструкции писать символьными обозначениями.
	Ответить | Правка | ^ к родителю #34 | Наверх | Cообщить модератору

	58. "В Kubernetes 1.13 устранена критическая уязвимость, позволяю..."	+/–
	Сообщение от Аноним (58), 06-Дек-18, 17:22
	> Ну а использование докера в продакшене очень быстро приводит к внедрению k8s. > Ибо если не он, то что? Соглашусь. Докер, конечно классный инструмент, но заставляет очень быстро деградировать. Причем, как админов, так и разработчиков. Пример его полезности с точки зрения админа - мне недавно надо было поднять несколько кибан разных версий, для разных кластеров эластики. И один общий контейнер для эласталерта. Докер - отлично подошел. Городить это на виртуалках я бы задолбался, к тому же это лишние сущности. Пример полезности  с точки зрения разработчика - дев окружения, но крайней мере в веб разработке. Запушили, проект оттестировался, собрался и можно легко посмотреть результат. Пример вреда докера - разработчики и новоиспеченные девопсы пытаются абсолютно все завернуть в докер. Файлшаринг(20Гб) для мелкого проекта на виртулке - это больше не по девопсовски, завернем его еще и контейнер, а хранилку маунтом прокинем. Дикость? Я считаю да. Наш новоявленный девопс считает, что только так и надо устанавливать по. Я кстати так и не понял, как использование докера связано с k8s? На мой взгляд, возможности kubernetes для большинства задач избыточны, swarm'а хватит.
	Ответить | Правка | ^ к родителю #34 | Наверх | Cообщить модератору

	60. "В Kubernetes 1.13 устранена критическая уязвимость, позволяю..."	+/–
	Сообщение от SysA (?), 06-Дек-18, 18:20
	Вообще-то в Докер-контейнере нет ОС! Потому-то они и такие маленькие... и это их основное преимущество перед КВМ и пр.
	Ответить | Правка | ^ к родителю #29 | Наверх | Cообщить модератору

	31. "В Kubernetes 1.13 устранена критическая уязвимость, позволяю..."	–1 +/–
	Сообщение от КГБ СССР (?), 05-Дек-18, 22:15
	Переводя на общепонятный русский, необходимость в контейнерной изоляции вызвана к жизни единственно низким уровнем квалификации молодой поросли эм… клавиатурных работников?
	Ответить | Правка | ^ к родителю #25 | Наверх | Cообщить модератору

	33. "В Kubernetes 1.13 устранена критическая уязвимость, позволяю..."	+/–
	Сообщение от Аноним (33), 05-Дек-18, 22:28
	Истинно так.
	Ответить | Правка | ^ к родителю #31 | Наверх | Cообщить модератору

	37. "В Kubernetes 1.13 устранена критическая уязвимость, позволяю..."	–1 +/–
	Сообщение от vedronim (?), 05-Дек-18, 23:29
	> Переводя на общепонятный русский, необходимость в контейнерной изоляции вызвана к жизни > единственно низким уровнем квалификации молодой поросли эм… клавиатурных работников? Нет. Причина в фрагментации линукса. Васяны, делающие свои дистры почему то надеются, что под них тут же начнут все подстраиваться.
	Ответить | Правка | ^ к родителю #31 | Наверх | Cообщить модератору

	40. "В Kubernetes 1.13 устранена критическая уязвимость, позволяю..."	–3 +/–
	Сообщение от Michael Shigorin (ok), 05-Дек-18, 23:45
	Есть формальная логика, есть женская -- но вот по продемонстрированной выше "васяны, делающие свои дистры" вдруг сцементировались и выкатили контейнеры. Мне одному кажется, что эта логика не тянет даже на такое название?
	Ответить | Правка | ^ к родителю #37 | Наверх | Cообщить модератору

	42. "В Kubernetes 1.13 устранена критическая уязвимость, позволяю..."	+1 +/–
	Сообщение от Борщдрайвен бигдата (?), 05-Дек-18, 23:55
	Нет. Вернее, не только. Ещё точнее: если бы k8s возник _только_ по вышеуказаной причине, то его бы никто не продал, будь этим кем-то сам гугл.
	Ответить | Правка | ^ к родителю #31 | Наверх | Cообщить модератору

	46. "В Kubernetes 1.13 устранена критическая уязвимость, позволяю..."	+1 +/–
	Сообщение от cutlass (?), 06-Дек-18, 05:58
	На разработчиков проще всего свалить все проблемы. Это слишком близоруко.
	Ответить | Правка | ^ к родителю #31 | Наверх | Cообщить модератору

	47. "В Kubernetes 1.13 устранена критическая уязвимость, позволяю..."	+1 +/–
	Сообщение от КГБ СССР (?), 06-Дек-18, 08:11
	> На разработчиков проще всего свалить все проблемы. Это слишком близоруко. Прости, если сможешь, Леннарт. Я был политически и морально близорук.
	Ответить | Правка | ^ к родителю #46 | Наверх | Cообщить модератору

	48. "В Kubernetes 1.13 устранена критическая уязвимость, позволяю..."	+/–
	Сообщение от cutlass (?), 06-Дек-18, 08:47
	Молодец! Осталось поработать над ошибками.
	Ответить | Правка | ^ к родителю #47 | Наверх | Cообщить модератору

	53. "В Kubernetes 1.13 устранена критическая уязвимость, позволяю..."	+/–
	Сообщение от Crazy Alex (ok), 06-Дек-18, 12:46
	Нет. Причина, как и всегда - в усложнении массово применяемого софта (включая условия его использования) и необходимости сохранять при этом хоть как-то разумные бюджеты на его написание и поддержку.
	Ответить | Правка | ^ к родителю #31 | Наверх | Cообщить модератору

	61. "В Kubernetes 1.13 устранена критическая уязвимость, позволяю..."	+/–
	Сообщение от SysA (?), 06-Дек-18, 18:23
	Не только и не столько... Суть в модульности и масштабируемости. И, как побочный эффект, - упрощение системы.
	Ответить | Правка | ^ к родителю #53 | Наверх | Cообщить модератору

	44. "В Kubernetes 1.13 устранена критическая уязвимость, позволяю..."	+/–
	Сообщение от Онаним (?), 06-Дек-18, 00:49
	> В какой-то момент приходится признать ... что лучше закрыться, а не корчить из себя эффективного менеджера целой компании ... (это по итогам: что выгонять разработчиков не вариант, научить делать нормально нереально, а дяденьки, который за них приведет код в состояние, в котором этим можно будет как-то управляемо менеджить нет)
	Ответить | Правка | ^ к родителю #25 | Наверх | Cообщить модератору

	45. "В Kubernetes 1.13 устранена критическая уязвимость, позволяю..."	+1 +/–
	Сообщение от Аноним (45), 06-Дек-18, 01:36
	>а дяденьки, который за них приведет код в состояние, в котором этим можно будет как-то управляемо менеджить нет. Здравствуйте, я тот самый дяденька, который заставляет их приводить код в состояние, в котором его можно хоть как-то управляемо менеджить. Спрашивайте свои вопросы.
	Ответить | Правка | ^ к родителю #25 | Наверх | Cообщить модератору

27. "В Kubernetes 1.13 устранена критическая уязвимость, позволяю..."	+1 +/–
Сообщение от Аноним (27), 05-Дек-18, 18:52
https://gitlab.freedesktop.org/polkit/polkit/issues/74 PolicyKit: Users with UID greater than INT_MAX can execute any systemctl command
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

30. "В Kubernetes 1.13 устранена критическая уязвимость, позволяю..."	+3 +/–
Сообщение от Онаним (?), 05-Дек-18, 20:47
Девопсненько.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема