Комментарии 37
НЛО прилетело и опубликовало эту надпись здесь
Любой апгрейд чего-либо требует резервной копии в продакшене. И что?
Кроме шуток, это действительно мечта ops-команды. Архитектура Kubernetes позволяет обновлять вот такие ключевые компоненты инфраструктуры вообще без даунтайма.
Даже если у вас очень дешёвый сетап и нет резервного кластера, на который можно переключить нагрузку на время обслуживания, проблемы при обновлении Kubernetes не фатальны. Можно даже пристрелить все управляющие компоненты Kubernetes разом, а ваши приложения продолжат работать. Даже если новая версия etcd+kubernetes не встанет по какой-то причине, можно опять всё потушить, восстановить etcd из бэкапа, вернуть предыдущие версии и продолжить работу с того же места, как было до апдейта.
Даже если у вас очень дешёвый сетап и нет резервного кластера, на который можно переключить нагрузку на время обслуживания, проблемы при обновлении Kubernetes не фатальны. Можно даже пристрелить все управляющие компоненты Kubernetes разом, а ваши приложения продолжат работать. Даже если новая версия etcd+kubernetes не встанет по какой-то причине, можно опять всё потушить, восстановить etcd из бэкапа, вернуть предыдущие версии и продолжить работу с того же места, как было до апдейта.
Миграция мажорных версий во многих приложениях непростая и сложная процедура. А если вы бэкапы не делает при миграциях, то это только пока.
НЛО прилетело и опубликовало эту надпись здесь
в Mesos взаимная совместимость как минимум +-3 мажорных версии.
Они выпустили только 1.4.0, или вы каждую минорную в 0.x.y считаете за мажорную, когда оно нестабильно в рамках semantic versioning? http://mesos.apache.org/documentation/latest/upgrades/ смотрели? Там про совместимость есть хорошая табличка.
Да, и что такое "взаимная совместимость"? Forward+Backward?
НЛО прилетело и опубликовало эту надпись здесь
Совместимость в рамках 1.x — это абсолютно нормально с точки зрения semantic versioning.
Бэкап etcd они крайне рекомендуют, т. к. происходит миграция между etcd2 и etcd3, т. е. между мажорными версиями. Проект etcd, скорее всего, рекомендует то же самое, что логично при миграции между сильно разными бэкендами хранения в etcd.
Зачем нужен Kubernetes и почему он больше, чем PaaS?
Так зачем же он нужен, и почему он больше чем PaaS, особенно при том что:
Kubernetes не предлагает никаких встроенных служб для обмена сообщениями, обработки данных, СУБД и т.п.
Kubernetes не имеет своего магазина с готовыми сервисами для деплоя в один клик.
Kubernetes не деплоит исходный код и не собирает приложения. Процессы непрерывной интеграции (CI) поддерживаются, но их реализация оставлена для других инструментов.
Аналогично для систем журналирования и мониторинга.
Из вашей статьи не понятно.
Вы точно всё прочитали? Жирным даже выделено:
Или вот: «в Kubernetes первичен универсальный, абстрактный подход». И вот: «платформа является модульной и предлагает пользователям самим выбирать конкретные решения для тех или иных задач». И в конце пример со стандартной библиотекой и фундаментом…
Предназначение Kubernetes как платформы — предоставить базовую, абстрактную платформу как услугу (Platform as a Service, PaaS), сохранив гибкость в выборе конкретных компонентов этой PaaS.
Или вот: «в Kubernetes первичен универсальный, абстрактный подход». И вот: «платформа является модульной и предлагает пользователям самим выбирать конкретные решения для тех или иных задач». И в конце пример со стандартной библиотекой и фундаментом…
Да, точно. Более того — уже пару лет использую Kubernetes в проде, но тем не менее ничего не понял.
Краткая суть, которую хотели здесь донести: основное предназначение k8s — предоставить всё необходимое для построения/обеспечения функций PaaS на её основе (а не только то, что нужно в каком-то одном конкретном или нескольких применениях — уж для этого существуют разные PaaS с более специализированным набором фич).
Если у вас есть реальный опыт и ваш вопрос не был самоцелью, поделитесь, пожалуйста, личным видением этого вопроса — тем более, если он сильно отличается или сильно более понятен. Всем на пользу пойдёт.
Если у вас есть реальный опыт и ваш вопрос не был самоцелью, поделитесь, пожалуйста, личным видением этого вопроса — тем более, если он сильно отличается или сильно более понятен. Всем на пользу пойдёт.
Блин, люди, Kubernetes — это game changer. Но статья с таким названием обязана хоть что-то рассказать про то, какие реальные преимущества получат пользователи, а не просто общие слова из презентации для бизнес-менеджеров.
Новизна Kubernetes в том, что можно взять любое обычное приложение, которое никто никогда в жизни не планировал для жизни в облаке, которое представления не имеет о том, что такое service discovery, failover, high availability, балансировка нагрузки, изоляция, мониторинг, облачные логи, zero-downtime system maintenance, canarying, rollbacks, и без всякой модификации, при помощи одного только манифеста получить все эти свойства разом.
Если использовать Google Container Engine (это Kubernetes, который мы предоставляем как сервис), то запуск сервисов вообще превращается в fire and forget. Машины умирают, диски отказывают, обновляется системный софт, а ваши приложения остаются железобетонно доступными. И для этого вообще ничего не надо делать (счета оплачивать разве что). Что очень важно, у вас при этом не образуется vendor lock. В любой момент можно переехать на инфраструктуру другого облака или на своё железо.
Я потихоньку перетаскиваю все свои личные проекты в GKE. И по опыту могу сказать, что один раз пишешь Dockerfile, манифест, и всё — можно вообще забыть про их существование.
Новизна Kubernetes в том, что можно взять любое обычное приложение, которое никто никогда в жизни не планировал для жизни в облаке, которое представления не имеет о том, что такое service discovery, failover, high availability, балансировка нагрузки, изоляция, мониторинг, облачные логи, zero-downtime system maintenance, canarying, rollbacks, и без всякой модификации, при помощи одного только манифеста получить все эти свойства разом.
Если использовать Google Container Engine (это Kubernetes, который мы предоставляем как сервис), то запуск сервисов вообще превращается в fire and forget. Машины умирают, диски отказывают, обновляется системный софт, а ваши приложения остаются железобетонно доступными. И для этого вообще ничего не надо делать (счета оплачивать разве что). Что очень важно, у вас при этом не образуется vendor lock. В любой момент можно переехать на инфраструктуру другого облака или на своё железо.
Я потихоньку перетаскиваю все свои личные проекты в GKE. И по опыту могу сказать, что один раз пишешь Dockerfile, манифест, и всё — можно вообще забыть про их существование.
НЛО прилетело и опубликовало эту надпись здесь
Смотрите, никто не говорит, что Kubernetes — само совершенство и решает все проблемы в мире. Ему ещё развиваться и развиваться — спору нет. Однако тех фич, которые уже есть, достаточно, чтобы строить надёжные сервисы из обычного софта.
Точнее так. Те проблемы, которые сейчас Kubernetes не решает (такие, как диагностика сбойного железа), в мире без Kubernetes всё равно вам как-то решать надо — дополнительный софт для мониторинга ставить, скажем. Вы их можете точно так же и в мире с Kubernetes решать. Тот же самый дополнительный софт будет обнаруживать умирающие диски, а дальше вам надо просто сказать Kubernetes drain node и отправить машину в ремонт. Какую-то часть задач (и очень большую) Kubernetes успешно решает.
Kube proxy давно уже не юзер-спейс — он настраивает iptables на машине для проброса трафика напрямую на бэкенды. Точнее, он до сих пор умеет юзер-спейс делать, но его надо явно просить об этом. По умолчанию — iptables. Там с сетью другая история — поскольку на каждый под выделяется отдельный IP, то нужна маршрутизация для этих адресов. Если у вас своя физическая сеть и адресов до фига и не жалко, то можно просто выделить на каждую ноду свою подсеть, из которой будут IP выделяться, и использовать обычную маршрутизацию, а если нет, то надо IPVS городить. Что именно и как в GCE/GKE устроено — я не знаю.
Про Docker я не в курсе, что там с лицензиями. Будет совсем плохо, реализуют поддержку чего-нибудь другого. Не вижу архитектурных препятствий.
На самом деле, если использовать GKE, вся эта сложность от вас скрывается платформой. И сеть, и диски просто работают. Я вообще за Kubernetes сейчас топлю не потому что в гугле работаю, а потому что как пользователь реально перенёс свои проекты и вообще забыл как страшный сон про дыры в безопасности, плановые остановки для накатывания обновлений, отказывающее железо и прочую боль.
Точнее так. Те проблемы, которые сейчас Kubernetes не решает (такие, как диагностика сбойного железа), в мире без Kubernetes всё равно вам как-то решать надо — дополнительный софт для мониторинга ставить, скажем. Вы их можете точно так же и в мире с Kubernetes решать. Тот же самый дополнительный софт будет обнаруживать умирающие диски, а дальше вам надо просто сказать Kubernetes drain node и отправить машину в ремонт. Какую-то часть задач (и очень большую) Kubernetes успешно решает.
Kube proxy давно уже не юзер-спейс — он настраивает iptables на машине для проброса трафика напрямую на бэкенды. Точнее, он до сих пор умеет юзер-спейс делать, но его надо явно просить об этом. По умолчанию — iptables. Там с сетью другая история — поскольку на каждый под выделяется отдельный IP, то нужна маршрутизация для этих адресов. Если у вас своя физическая сеть и адресов до фига и не жалко, то можно просто выделить на каждую ноду свою подсеть, из которой будут IP выделяться, и использовать обычную маршрутизацию, а если нет, то надо IPVS городить. Что именно и как в GCE/GKE устроено — я не знаю.
Про Docker я не в курсе, что там с лицензиями. Будет совсем плохо, реализуют поддержку чего-нибудь другого. Не вижу архитектурных препятствий.
На самом деле, если использовать GKE, вся эта сложность от вас скрывается платформой. И сеть, и диски просто работают. Я вообще за Kubernetes сейчас топлю не потому что в гугле работаю, а потому что как пользователь реально перенёс свои проекты и вообще забыл как страшный сон про дыры в безопасности, плановые остановки для накатывания обновлений, отказывающее железо и прочую боль.
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
Про eBay я находил упоминания Mesos от 2014 года, а с 2015 гуглится уже Kubernetes. Здесь пишут так (кстати, прямо в пику утверждений о зрелости проектов :-)):
А вот достаточно свежее (2017 год), что всё-таки k8s.
At the time eBay started searching for an answer, Docker Swarm had yet to emerge, Mesos was a young open source code project (later supported and productized through the firm Mesosphere) and Kubernetes was just emerging from Google's halls. Early in 2016, having played the field, eBay settled on Kubernetes as the most mature option.
А вот достаточно свежее (2017 год), что всё-таки k8s.
> Кстати, по eBay, не все так однозначно:
github.com/apache/mesos/blob/master/docs/powered-by-mesos.md
mesos или mesos/marathon? Если же говорить исключительно о первом — то это ж ведь не то же самое, что и кубернетис.
github.com/apache/mesos/blob/master/docs/powered-by-mesos.md
mesos или mesos/marathon? Если же говорить исключительно о первом — то это ж ведь не то же самое, что и кубернетис.
Kubernetes это уже скорее средний бизнес, мелкому/стартапам это оверкилл. Вот прямо в данный момент, например, думаю о том чтоб переезжать с docker cloud на kubernetes, из-за роста компании/софта.
Не подскажите где можно найти Mesos как сервис?
Наверное, стартапам рисковать можно :)
Не подскажите где можно найти Mesos как сервис?
Спасибо за полезный комментарий. Конкретные фичи, которые предлагает k8s, очень кратко описаны в докладе (на него ссылка в конце статьи). А для больших подробностей планируем цикл, потому что в одну статью это не уложишь.
> Новизна Kubernetes в том, что можно взять любое обычное приложение, которое никто никогда в жизни не планировал для жизни в облаке
Нет. В контейнерах должно работать одно приложение, стейтлесс, да еще и по размеру не большое. Если же у вас контейнеры с приложением по 2ГБ — то это уже совсем не то. Да еще и нормальное АПИ должно быть у компонентов. Т.е. контейнеры и Кубернетис в принципе не для таких гигантов как Друпал и т.п.
Нет. В контейнерах должно работать одно приложение, стейтлесс, да еще и по размеру не большое. Если же у вас контейнеры с приложением по 2ГБ — то это уже совсем не то. Да еще и нормальное АПИ должно быть у компонентов. Т.е. контейнеры и Кубернетис в принципе не для таких гигантов как Друпал и т.п.
Вообще, я бы не был так категоричен — есть разные мнения на этот счёт. Хотя и я лично тоже считаю, что новые приложения нужно разрабатывать так, как вы говорите (микросервисы, по максимуму стейтлесс, нормальные API), но… Если у вас уже есть легаси-приложения, которые уже работают на обычных серверах, то даже ради одного только self-recovery их имеет смысл запихать в контейнеры и положить в облако.
Легаси апликейшен пусть работает там где работает. 20 ГБ контейнеры с какими-то Маджентами — это не разговор вообще.
> то даже ради одного только self-recovery их имеет смысл запихать в контейнеры и положить в облако.
Может нужно посмотреть какой-то селф рекавери на чем-то традиционном? Ну в плане зачем Кубернетис, если можно пересоздавать виртуалку или какой-нибудь контейнер LXC/OpenVZ в чем-то типа Proxmox?
> то даже ради одного только self-recovery их имеет смысл запихать в контейнеры и положить в облако.
Может нужно посмотреть какой-то селф рекавери на чем-то традиционном? Ну в плане зачем Кубернетис, если можно пересоздавать виртуалку или какой-нибудь контейнер LXC/OpenVZ в чем-то типа Proxmox?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Зачем нужен Kubernetes и почему он больше, чем PaaS?