Как бы мне этого ни хотелось, бюджет у go-team не бесконечный — все фичи не реализуешь. Я думаю, если напишете такой оптимизатор, вам только спасибо скажут.
Вообще, я бы не был так категоричен — есть разные мнения на этот счёт. Хотя и я лично тоже считаю, что новые приложения нужно разрабатывать так, как вы говорите (микросервисы, по максимуму стейтлесс, нормальные API), но… Если у вас уже есть легаси-приложения, которые уже работают на обычных серверах, то даже ради одного только self-recovery их имеет смысл запихать в контейнеры и положить в облако.
Смотрите, никто не говорит, что Kubernetes — само совершенство и решает все проблемы в мире. Ему ещё развиваться и развиваться — спору нет. Однако тех фич, которые уже есть, достаточно, чтобы строить надёжные сервисы из обычного софта.
Точнее так. Те проблемы, которые сейчас Kubernetes не решает (такие, как диагностика сбойного железа), в мире без Kubernetes всё равно вам как-то решать надо — дополнительный софт для мониторинга ставить, скажем. Вы их можете точно так же и в мире с Kubernetes решать. Тот же самый дополнительный софт будет обнаруживать умирающие диски, а дальше вам надо просто сказать Kubernetes drain node и отправить машину в ремонт. Какую-то часть задач (и очень большую) Kubernetes успешно решает.
Kube proxy давно уже не юзер-спейс — он настраивает iptables на машине для проброса трафика напрямую на бэкенды. Точнее, он до сих пор умеет юзер-спейс делать, но его надо явно просить об этом. По умолчанию — iptables. Там с сетью другая история — поскольку на каждый под выделяется отдельный IP, то нужна маршрутизация для этих адресов. Если у вас своя физическая сеть и адресов до фига и не жалко, то можно просто выделить на каждую ноду свою подсеть, из которой будут IP выделяться, и использовать обычную маршрутизацию, а если нет, то надо IPVS городить. Что именно и как в GCE/GKE устроено — я не знаю.
Про Docker я не в курсе, что там с лицензиями. Будет совсем плохо, реализуют поддержку чего-нибудь другого. Не вижу архитектурных препятствий.
На самом деле, если использовать GKE, вся эта сложность от вас скрывается платформой. И сеть, и диски просто работают. Я вообще за Kubernetes сейчас топлю не потому что в гугле работаю, а потому что как пользователь реально перенёс свои проекты и вообще забыл как страшный сон про дыры в безопасности, плановые остановки для накатывания обновлений, отказывающее железо и прочую боль.
Кроме шуток, это действительно мечта ops-команды. Архитектура Kubernetes позволяет обновлять вот такие ключевые компоненты инфраструктуры вообще без даунтайма.
Даже если у вас очень дешёвый сетап и нет резервного кластера, на который можно переключить нагрузку на время обслуживания, проблемы при обновлении Kubernetes не фатальны. Можно даже пристрелить все управляющие компоненты Kubernetes разом, а ваши приложения продолжат работать. Даже если новая версия etcd+kubernetes не встанет по какой-то причине, можно опять всё потушить, восстановить etcd из бэкапа, вернуть предыдущие версии и продолжить работу с того же места, как было до апдейта.
Блин, люди, 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), или можете плавно изменять трафик, например, обратно пропорционально загрузке конкретного инстанса?
Все американцы, которых я знаю (а я с ними каждый день общаюсь в большом количестве), говорят «раутер». Даже если это не соответствует норме языка, в таких случаях норму меняют, чтобы она соответствовала общепринятому употреблению.
У меня картинки почему-то не грузятся из приложения, не могу посмотреть ваши комменты со ссылками на словарь.
Но могу ответственно сообщить, что рутер — это британский вариант. Американский — раутер. Но и то, по звучанию их звуки не мапятся на русские один к одному. Их «а» в слове раутер — нечто среднее между русскими «а» и «о». Ближе к «а», правда. Как в слове cow.
Точнее так. Те проблемы, которые сейчас Kubernetes не решает (такие, как диагностика сбойного железа), в мире без Kubernetes всё равно вам как-то решать надо — дополнительный софт для мониторинга ставить, скажем. Вы их можете точно так же и в мире с Kubernetes решать. Тот же самый дополнительный софт будет обнаруживать умирающие диски, а дальше вам надо просто сказать Kubernetes drain node и отправить машину в ремонт. Какую-то часть задач (и очень большую) Kubernetes успешно решает.
Kube proxy давно уже не юзер-спейс — он настраивает iptables на машине для проброса трафика напрямую на бэкенды. Точнее, он до сих пор умеет юзер-спейс делать, но его надо явно просить об этом. По умолчанию — iptables. Там с сетью другая история — поскольку на каждый под выделяется отдельный IP, то нужна маршрутизация для этих адресов. Если у вас своя физическая сеть и адресов до фига и не жалко, то можно просто выделить на каждую ноду свою подсеть, из которой будут IP выделяться, и использовать обычную маршрутизацию, а если нет, то надо IPVS городить. Что именно и как в GCE/GKE устроено — я не знаю.
Про Docker я не в курсе, что там с лицензиями. Будет совсем плохо, реализуют поддержку чего-нибудь другого. Не вижу архитектурных препятствий.
На самом деле, если использовать GKE, вся эта сложность от вас скрывается платформой. И сеть, и диски просто работают. Я вообще за Kubernetes сейчас топлю не потому что в гугле работаю, а потому что как пользователь реально перенёс свои проекты и вообще забыл как страшный сон про дыры в безопасности, плановые остановки для накатывания обновлений, отказывающее железо и прочую боль.
Даже если у вас очень дешёвый сетап и нет резервного кластера, на который можно переключить нагрузку на время обслуживания, проблемы при обновлении Kubernetes не фатальны. Можно даже пристрелить все управляющие компоненты Kubernetes разом, а ваши приложения продолжат работать. Даже если новая версия etcd+kubernetes не встанет по какой-то причине, можно опять всё потушить, восстановить etcd из бэкапа, вернуть предыдущие версии и продолжить работу с того же места, как было до апдейта.
Новизна Kubernetes в том, что можно взять любое обычное приложение, которое никто никогда в жизни не планировал для жизни в облаке, которое представления не имеет о том, что такое service discovery, failover, high availability, балансировка нагрузки, изоляция, мониторинг, облачные логи, zero-downtime system maintenance, canarying, rollbacks, и без всякой модификации, при помощи одного только манифеста получить все эти свойства разом.
Если использовать Google Container Engine (это Kubernetes, который мы предоставляем как сервис), то запуск сервисов вообще превращается в fire and forget. Машины умирают, диски отказывают, обновляется системный софт, а ваши приложения остаются железобетонно доступными. И для этого вообще ничего не надо делать (счета оплачивать разве что). Что очень важно, у вас при этом не образуется vendor lock. В любой момент можно переехать на инфраструктуру другого облака или на своё железо.
Я потихоньку перетаскиваю все свои личные проекты в GKE. И по опыту могу сказать, что один раз пишешь Dockerfile, манифест, и всё — можно вообще забыть про их существование.
Справедливости ради, в статье много умолчаний, которые истинны для Гугла, но могут отличаться в других компаниях.
Но могу ответственно сообщить, что рутер — это британский вариант. Американский — раутер. Но и то, по звучанию их звуки не мапятся на русские один к одному. Их «а» в слове раутер — нечто среднее между русскими «а» и «о». Ближе к «а», правда. Как в слове cow.