Comments 28
Почему куб такой сложный? Потому что это по сути целая операционная система для деплоя приложений, которая пытается абстрагировать вообще все детали нижележащих облаков или железок: https://buttondown.email/nelhage/archive/two-reasons-kubernetes-is-so-complex/
странный дизайн - грабли при траблшутинге: Kubernetes events will disappear after one hour
Его делают люди, которые похоже не умеют в линуксы. Вот ставим например официальный deb пакет c kubectl. А там внезапно только один бинарник kubectl! man страниц нет, bash-completion нет. Они там с Луны свалились?
Не думаю, что пакеты для дистров собирают разработчики кубера...
Пакет с их вебсайта https://kubernetes.io/docs/tasks/tools/install-kubectl-linux/#install-using-native-package-management
И при этом ниже на веб сайте пишут, что нужно сплясать вприсядку чтобы bash-completion получить. Вот видимо прямо те же люди, которые пакет собирают.
Уважаемые, можете, пожалуйста, объяснить – как вообще инженерное сообщество могло принять в качестве стандарта подобный инструмент, обладающим таким количеством косяков и нелогичных моментов?
Регулярно вижу статьи о том, как сложно понять причины падения кубера, причины падения подов, причины неработоспособности скейлинга, причины чего бы то ни было.
Каковы прогнозы - оно будет когда-нибудь просто работать? Это наше будущее или надо ждать перерождения? 8 лет вроде уже проекту.
А вы думаете весь софт - это идеально написанный и вылизанный код? Сейчас "Эра MVP", всё что изобретается - лишь бы работало хоть как-нибудь. Добавляем сюда модный CICD, когда вчерашний админы вдруг начинают свою работу автоматизировать, и получаем тонну говнософта, который автоматизирует другой говнософт. Примерно тоже самое происзошло и с frontend-ом и его сборщиками. Вот руки у людей добрались и до кубера.
когда вчерашний админы вдруг начинают свою работу автоматизировать
Почему вдруг? Считаете, что доставка приложения до окружений должна обязательно быть ручной?
"Вдруг" - потому что раньше обходились bash-скриптами, а потом резко (вдруг) все начали создавать целую кучу инструментов. Так и появился зоопарк для зоопарка систем и программ. Когда всё это видишь, то понимаешь, что всё это создавалось в спешке, очень разными людьми, для очень разных задач, и почему-то это всё как-то работает вместе.
То ли дело тонны writeonly bash-скриптов.
Come on, кубер сделали бесплатным для того, что бы вы помучались с ним, и пришли в гугл клауд, где "все тот же кубер, только не глючит"
Ну предложите полновесную альтернативу кубу?)
Понимание как траблшутить куба придет с опытом. Сама по себе система большая и сложная, много нюансов, тонна доки, высокий порог вхождения. Как результат, не всегда глубокие и полноценные компетенции у тех, кто деплоит приложения не соблюдая хорошие практики, например, в ограничении ресурсов или что-то ломает не правильной конфигурацией; аналогично у тех, кто пытается это потом чинить могут быть недостаточный опыт и навыки в администрировании куба и с разбегу может ничего не получаться.
Кажется это нормально и куб в прод надо выбирать командам с четким пониманием зачем он и для чего, точно зная, что он им нужен и, разумеется, обладая компетенциями в его обслуживании или полагаясь на хорошие менедж решения и внешние команды, оказывающие помощь в администрировании куба.
Зависит от понимания "полновесной". Я признаюсь, у меня в основном опыт работы с .NET поверх on-premise серверов или виртуальных машин в облаках. Я не знаком с ситуацией когда есть простаивающие мощности и необходимо жонглировать контейнерами между серверами. Обычно наоборот, требуется выжать максимум из имеющихся серверов, для чего стараешься точно знать:
Сколько экземпляров сервисов обслуживает запросы пользователей, чтобы планировать допустимую нагрузку для системы целиком, ведь там позади могут быть полуживые внутренние системы плевавшие на твой автоскейлинг.
Характер потребления ресурсов сервисами, чтобы знать какие можно разместить на каких группах серверов рядом, а какие необходимо держать отдельно, ведь дело не в реакции на показатели, а понимании как себя ведёт именно этот кусок системы.
Для настройки серверов и раскатки сервисов использовались Configuration-as-a-Code, PS-скрипты и PS DSC, Bash скрипты, различные джобберы типа Jenkins/TeamCity/TFS ради визуализации. Хотя справедливости ради пользовал Octopus Deploy также, он тот ещё комбайн, но можно и без него. Главное, ты точно знаешь чем будет занят конкретный сервер или группа серверов, а уж инструменты были плюс-минус одинаковые судя по рассказам.
Если говорить про эффективное распределение ресурсов по дата-центру, с перемешиванием десятков-сотен экземпляров сервисов на десятках-сотнях серверов:
Разве встроенные AWS ECS и Azure App Service не дают необходимого функционала раскатки контейнеров? Они же созданы ради этого, имеют встроенный скейлинг, управление количеством экземпляров.
Вы абсолютно правы, большинство людей не должны деплоить в кубер. Есть милион более простых инструментов. С гораздо меньшим количеством функций. Но для 99% веб серверов или backed систем работающих по event bus это отличные решения.
Проблема кубера его пихают иногда куда не надо.
Например когда я говорю про без альтернативность кубера - я имею ввиду что мне нужно запустить 100 веб сервисом с 3мя разными подходами к autoscale.
А ещё я хочу запускать spark и flink и ml в одной платформе. Что бы тот же autoscale переимпользовать, но с нюансами.
А ещё я хочу иметь общий инструмент для security и network policy apply для все своих сервисом, compute engine, kafka и ml framework. Да да у нас отдельная команда secops, которая пишет opa security policy для 50 других команд.
А ещё я хочу общий инструмент что бы все выше перечисленые Тулы можно было запускать на spot. Или легко добавлять управление ebs/ssd в некоторые сервисом, но не во все.
А ещё я лично, люблю экзотические юзкейзы автоматизировать. Например у на 70 кластеров кафки в каждом не меньше 60 нод. И полностью автоматическая система rebalance/backup/ scale/alert/disk extension.
А ещё я забыл про service discovery. Есть милион альтернатив, но я хочу что бы оно с моими сетями интегрировалось, а не везде consul/zookeeper пихать. Что не так уж просто.
Вот и подумайте сколько всего мы раньше писали и костыли в том числе на terraform и chef/puppet/ansible/etc. И как потом сделать на этих технологиях сранный rolling upgrade сложной системе, что бы не больше 5 инстансов было в перезапуска.
А я не говорю про drain and shutdown, если hardvare/vm degradate случился.
Но и это не все, главное теперь есть чёткий протокол/api между developer которые пишут код и реализовуют gracefull shutdown, restart, exactly once guarantee, ha в своём коде и ops которые управляют сетями, дисками, load balancers, security permissions и прочее.
И да я не девопс, я разработчик и меня не раз бесило что я не могу нормально backup автоматический сделать или не знаю какой timeout на sigkill.
Рискну предположить, что примерно так же, как Chrome захватил рынок браузеров: огромные ресурсы на первоначальное продвижение. Клиенты хотят модный кубер, хотя они "винчестер от парабеллума" отличить не могут.
С другой стороны, на этом прям целая отрась выросла: где раньше нужна была пара админов, теперь целый отдел девопсов или managed решение от <выберите любого обачного провайдера>, все довольны :)
Я деплоил и маленькие, и большие проекты при помощи и Capistrano, и голого Ansible, и Ansible+Docker, и docker-compose, и Swarm был, и скрипты самописные были, и скриптовый клей для всего сразу был.
Kubernetes сложно, сразу пирог из абстракций, много движущихся частей, но, несмотря на всю сложность, это лучшее из всего что я использовал для развертывания бизнес-приложений. Haters gonna hate, но даже если убрать весь хайп, данная система решает проблему развертываний в разные окружения + Day-2 operations элегантнее всего. Да, такая махина и элегантнее всего. Всё так уныло в мире автоматического развертывания. Альтернативой на проект из ~10 сервисов может быть большой отдел "админов", руками накликивающие в UI условных Tomcat/JBoss. Или же обслуживающих ещё более монструозную какую-нибудь закрытую "платформу развертывания".
С Kubernetes будет достаточно пары компетентных инженеров. Даже для суровых энтерпрайзных Java-приложений. Спасибо Red Hat.
Высокий порог входа k8s, отладка операторов, отладка сети внутри, отладка крэша подов. Ох, это должно было быть приключение на 20 минут, а не на 2 недели...
Инструмент который создаёт больше проблем чем решает должен или эволюционировать, или умереть
2 дня было убито на поиски причины. Один под который имел подключение к rabbitmq завис в состоянии terminating. Удалён был по команде "k delete pod -force". Под благополучно удалился. Через 2 дня мы заметили что из реббита куда-то начали пропадать сообщения. В реббите в списке подключенных клиентов был один ip адрес который не принадлежал ни одному поду, и вообще при попытках выяснить что это за айпишник кубернетис не показывал ни один ресурс который бы его использовал. Long story short - оказывается кубернетис сам под как ресурс прибил, а вот контейнер в сломаном состоянии остался висеть и кушать сообщения из канала(реббит был в самом кластере), но при этом к базе которая была ресурсом облака он соеденине потерял и не мог эти сообщения нормально запроцессить. Выяснить что за фигня происходит удалось только тогда когда я додумался зайти в шелл на всех нодах и выполнить docker ps где я и увидел этот контейнер.
CrashLoopBackOff? А NullPointerException и вообще любые сообщения об ошибках людей тоже раздражают?
На Reddit обсудили, что больше всего раздражает в Kubernetes